The Five Main Uses of Policy-as-Code (So far)

I was chatting with someone about Policy-as-Code, and what it was good for. I listed off three things, but then while I was talking to him, I realized that there were five that came to mind.

1. Infrastructure-as-Code Hygiene

2. Zero Trust Architecture Implementation

3. Security Access Disintermediation

4. Compliance Facilitation

5. Distributed Rules Engines

Infrastructure-as-Code Hygiene

Hygiene in this case means: ensuring that IaC documents are properly built, that they use the correct images, that they have the right size, that they have the correct security features enabled, the inappropriate features disabled, etc.

This was one of the early uses of Policy-as-Code, and it is still a significant use case of PaC systems.

The biggest benefits of this go to large, complex organizations that are transitioning to the cloud, or that are struggling with manual approval processes for IaC documents.

Zero Trust Architecture Implementation

Zero Trust Architectures are implemented as a form of ‘defense in depth’, where every system in the organization has layers of protection. Enterprise applications and microservices are one of the more challenging targets for Zero Trust protection, for a variety of reasons. 1) The applications are maintained by teams which are often juggling priorities, and systemic security is often considered a low priority. 2) Microservices often have intense performance requirements. 3) Legacy systems can be difficult to update to use modern security practices.

Policy-as-Code solutions can help mitigate all of these concerns, so this is an area of growing interest in the security space.

Security Access Disintermediation

This is a fancy way of saying “The security team is responsible for application security, not the development team”.

For many greenfield applications and services, one of the first things that the development team is obliged to implement is the access system — evaluating which users are allowed to do what. One of the powerful strategic uses of Policy-as-Code is to introduce it at the beginning of the project, essentially pushing the responsibility for all access-related tasks to the security team.

Using Policy-as-Code for access allows the development team to focus on the “business” logic, and allows the security team to focus on the “security” logic, on their own timeframes, with their own release schedules.

Compliance Facilitation

Compliance is often an onerous, thankless task. In most organizations, it’s a grudgingly accepted chore to implement compliance restrictions. And the audits are often even worse, requiring developers to spend many unproductive hours “proving” the compliance of their applications to auditors.

Policy-as-Code can help here, a lot. By using PaC for access, the audit team can understand the rules by spending time with the security team, rather than the development team. In addition, if the PaC solution has a good decision audit log, that also can be reviewed by the audit team with the help of the security team, rather than having to have the developers attempt to explain how everything fits together.

Distributed Rules Engines

Rules Engines were designed to allow business people to build and maintain business decisions, independent of the application logic. The goal here is that the developers focus on getting the application running, stable and robust; while the business people focus on implementing the ‘business logic’ in a separate roadmap, using their own timeframe (similar to security disintermediation above).

Policy-as-Code solutions often include a programming language, a test framework, a data section and can be located in small agents alongside distributed (or edge-based) applications. These are key ingredients for a rules engine.

Some rules-based solutions that require real-time performance, or need to be highly available, or both. In those cases, using a PaC solution for implementing business rules can be a good idea.

Other Potential Usages

Governance-as-Code

GaC is a more recent concept, seeking to generalize the governance of IaC documents, into something bigger. However, IMO, that’s really a Policy-as-Code solution with more assertive marketing.

Cloud Access

The various cloud systems have their own way of managing authorization & access (IAM, etc). But sometimes role-based permissions are insufficient. In those cases, if there is a way to use serverless functions (Lambda, Cloud Functions, etc), it is straightforward to having those serverless functions call Policy-as-Code decision points to provide a richer access decision model.

Other Articles

Thanks!

Thank you for taking the time to read this far. If you have comments, suggestions or just want to talk about this stuff more, please feel free to contact me: johnbr@paclabs.io