Policy as Code
As adoption of infrastructure as code gains momentum, more organizations can deploy faster, change faster, innovate faster… and introduce risk faster. Code-based automation offers game-changing speed and flexibility but often leaves security behind. Although infrastructure as code can reduce opportunities for human error, it can also replicate errors across the entire information ecosystem.
In a highly competitive technology landscape, speed to market is critical; security can’t be a source of friction or impede innovation or productivity. Modern security must integrate into the existing system development lifecycle. Policy as code makes that possible.
What is policy as code?
The term policy as code refers to high-level code that manages and automates security policies. The policies can be internal security guidelines for how to configure infrastructure, or they can be specific controls set by compliance frameworks such as PCI, SOC 2, or HIPAA.
Traditional security policies are captured in a document for humans to evaluate, interpret, and apply. With policy as code, each control is an automated verification that runs as part of the software development lifecycle.
Policy as code contains:
- Documentation on the policy
- Rationale for the policy
- Automated tests validating that an asset conforms to the policy
As a simplified example, suppose an organization wants to ensure that all of their applications communicate over transfer protocol TLS 1.3 or newer and use certain HTTP security headers.
Traditionally the organization’s Security team writes these requirements in a document, shares the document with developers, and counts on them to comply. The Security team might perform an annual audit that includes checking TLS versions and HTTP headers. If they find any noncompliant applications, Security includes them in the audit report and once again counts on the developers to comply with the policy.
Policy as code eliminates the gap between security policy and compliance. Security and DevOps work together to define and implement policy as code. Constant monitoring keeps Security in the know. Instead of an annual audit that triggers costly reengineering, policy as code provides continual auditing from the coding phase to deployment.
What’s the difference between infrastructure as code and policy as code?
Infrastructure as code is automation that changes the state of infrastructure. Policy as code validates that the infrastructure is compliant with a given policy.
You use infrastructure as code to perform tasks across your entire system, such as adjusting settings, installing software, or opening and closing ports. You use policy as code to continuously verify that your system follows security guidelines, even as you make changes.
As guidelines change within your organization, you can develop new policies (or update existing policies) and deploy them across your infrastructure before making changes to the infrastructure itself. This approach lets you immediately understand how your existing infrastructure measures against the policy. You can then use infrastructure as code to change your infrastructure to comply with the policy.
What are the benefits of policy as code?
With policy as code, your organization can:
- Continuously audit all business-critical infrastructure for compliance
- Collaborate and reduce friction between DevOps and Security teams
- Shift security left to save time and cost
- Track policy in version control just like your code
- Automatically customize policies for different environments
Policy as code provides continuous compliance
Policy as code integrates with every part of the DevOps lifecycle:
- Developers can scan images and manifests from their workstations during the build and test stages.
- As changes merge into the CI/CD pipeline, policy as code can identify vulnerabilities and compliance issues.
- At deployment time, automated scans can catch any security issues before they go to production.
- As policies change, continuous monitoring of deployed infrastructure flag existing assets that don’t comply.
Policy as code eliminates the painful experience of a manual audit. The results derived from running policy as code can show auditors how your system complies with set standards.
You choose how proactive to make your policy as code. A failing policy can trigger any type of response, including:
- Sending notifications to the right response team for further investigation
- Executing an end-to-end automation workflow to remediate the violation
- For the most serious issues, stopping a software build
Policy as code fosters collaboration
When implementing any kind of automation, DevOps, or DevSecOps practice, the biggest challenges arise not from technology, but from the cultural divide between the people and teams responsible for its implementation.
Not all security engineers write code, and not all software developers understand security and compliance. Policy as code provides opportunity for these two groups to collaborate: they work together to produce policy as code. This shared work fosters better cross-team connections and overall empathy within the organization. Policy as code also reduces the friction caused by traditional manual policy audits.
Policy as code helps you shift left
The term shift left is all about running code and tests as early (left, in a flow diagram) as possible in the software development lifecycle. There the risk is lower, as is the impact of failure. Finding compliance issues early saves cost and time.
With policy as code, developers can catch security issues in the earliest stages of development. Policies can execute in a local environment on the developer’s workstation before a developer merges changes into the main source code.
Once changes are merged into the code base, they’re tested in a pipeline, which assures that they meet coding and execution standards and—using policy as code—security guidelines.
Finally, despite strong pipelines, there are always possibilities for things to go wrong in production environments. Policy as code can monitor and validate the deployments as well.
Policy as code is versioned
The only constant in life is change.
Policies change. When policies are written as code, they can (and should) be stored in version control systems such as GitHub or GitLab.
Policies live alongside the codebase they are written to provide guardrails for. Version control systems are meant for collaborative software development; both developers and security teams can iterate on policies, providing an audit trail of:
- What changed
- Who changed it
- Why they changed it
- When they changed it
Version history captures all of this change over time.
Policy as code is customizable
When a security policy exists as a traditional document, it’s difficult to adapt that policy to the unique environments it’s meant to govern. This can lead to multiple versions of the same policy. For example, it might be acceptable to rotate API keys every 90 days in one environment, while in another, higher-security environment it’s important to rotate them every 30 days.
Policies as code offers flexibility with parameters that work like variables. The parameters provide a default value, but that value can differ based on circumstances you define. This lets you use the same policy in any environment, customized for the requirements of that environment.
Version history captures all of this change over time.
Mondoo makes policy as code easy
We built Mondoo to meet the challenges of integrating security into every stage of the software development lifecycle. Mondoo provides out-of-the-box policies for identifying security misconfigurations on-promise and in the cloud.
With Mondoo’s policy as code, security engineers can scan infrastructure assets on demand from their local workstations. Mondoo assesses risk and provides actionable results to fix vulnerabilities.
Mondoo host and container scans work continuously during run time, ensuring visibility into what’s running at any moment. As Mondoo discovers new vulnerabilities, it recommends the most important vulnerabilities to remediate first.
Mondoo scans easily integrate into the SDLC. They make security posture observable, and provide guardrails that prevent you from deploying vulnerabilities into your running environment.