How Policy-as-Code can save you Time and Money
For people familiar with Policy-as-Code, the benefits in terms of security compliance are well-known. What might be less obvious is that an architecture that includes PaC can also reduce the need for (expensive) IT/Developer time in support of security requirements, and potentially reduce licensing costs as well. Here are some ways that Policy-as-Code can help:
Automating Infrastructure-as-Code Policy
Merging disparate IaC policy solutions
Reduce time required for compliance support
Reduce development time supporting security policy
Reduce cost of Zero Trust Architecture implementations
Automate Infrastructure-as-Code Approvals
Infrastructure-as-Code has been a revolution in how one thinks about managing servers, networks, storage, et al. Multiple companies have made massive fortunes from implementing and supporting IaC products and solutions.
Recently, there’s been a challenge — security compliance — that has tempered the movement. Allowing people to deploy unknown images in exotic ways on unsecured servers of arbitrary size is a recipe for disaster. This was one of the key early value propositions of Policy-as-Code — write logic that can validate the IaC documents conform to the official policies before the IaC documents are converted into actual infrastructure. This has both a security angle (better compliance with security rules and discipline) as well as a cost-reduction angle (managing the size and scope of new infrastructure deployments).
Manage your disparate Infrastructure-as-Code solutions in a consistent way
If you have a larger organization, you may be multiple IaC options in use. Each one typically has either a proprietary Policy-as-Code solution, or uses OPA (Open Policy Agent). But even the ones that use proprietary solutions can still be adapted to use OPA. And once you do that, you can centralize the various policy rules accross the different IaC implementations, and make them more consistent. This reduces the maintenance effort and it reduces the compliance effort. Also, these proprietary IaC-specific policy tools may require additional licensing costs. That cost can be avoided with open-source PaC solutions.
Reduce the time needed by the development team to support compliance
Most organizations have to deal with compliance obligations: SOC2, HIPAA, etc. These standards define policies that the organization must follow, and must be able to prove that they are following. For organizations with any type of internal software development or IT, this can be challenging to implement and time-consuming to maintain. Policy-as-Code can help here in several ways:
Policy-as-Code solutions often come with a set of pre-written policy rules for some of the most common compliance requirements, so developers don’t have to spend time implementing those rules.
Policy-as-Code solutions can intercept and augment legacy RBAC implementations, again with modest effort from the development team. This allows the security team to manage and update the security policies, without significant rework upon the legacy systems.
Policy-as-Code solutions centralize the decision history. This reduces the time developers have to sit with auditors to demonstrate that systems are compliant.
Separate Security Policy from Business Logic
Certain types of software, such as APIs and Microservices, have significant performance requirements. Using a centralized policy decision solution can be challenging, both for speed and single-point-of-failure reasons. For these reasons, many APIs and Microservices must embed the policy logic within their implementations. However, when the policy logic needs to change, it can be very challenging to get the development organization to prioritize those challenges.
Policy-as-Code solutions can help here. The PaC solutions can be attached to, or hosted with the APIs and Microservices. This avoids the performance and SPOF challenges of a centralized solution. It also excises the policy logic from the business implementation. This allows the development team to focus on business requirements, and allows the security team to focus on security requirements.
This, in turn, reduces the time the (expensive) development team needs to focus on security policy, and also allows the security team to implement policy changes in a timely manner.
Zero Trust Architecture
If your organization is implementing a Zero Trust solution, most of the well-known tools and products are proprietary and expensive. Many (but not all!) of the Policy Enforcement Point and Policy Decision Point components can be built using open-source Policy-as-Code solutions. Yes, you’ll need development time to integrate the PaC solution, but you’d almost certainly need that for proprietary solutions as well. And in the long term, you will have fewer license fees and less vendor lock-in.
Other Articles
Thanks
Thank you for taking the time to read this. If you have any feedback, suggestions or interesting challenges you’re facing, I would love to hear about them. I can be reached at: johnbr@paclabs.io