The adoption of infrastructure as code (IaC) practices to help automate and accelerate IT operations has really taken hold in recent years — even more so during the pandemic.

With IaC, organizations are moving away from a model where humans are required to make manual changes in order to configure and deploy application infrastructure, both on-premises and more often than not, in the cloud. IaC offers the promise of automation and repeatable predictable patterns for software infrastructure deployment. There are multiple popular models and services used today for enabling an IaC approach, including Terraform, Chef, Puppet, Ansible, SaltStack, and AWS CloudFormations.

While the approach has many benefits, traditional security approaches typically slow down the software development life cycle and can evaporate the benefits of using IaC. That's why there is a real need for organizations to take a "security as code" (SaC) approach to fully recognize the benefits of automation that composable, repeatable, and fully auditable infrastructure can provide.

IaC Requires A New Security Approach
Simply put, securing automation code is critical because in many cases it literally runs our businesses. IaC systems are automatically deploying resources and applications. A vulnerability or a misconfiguration in an IaC workflow could have a cascading impact, across multiple workloads and deployments that could enable a potential attacker to cause a lot of damage. IaC is very powerful, so when mistakes happen, they happen fast, and exponentially.

One of the challenges with securing automated workflows is there can often be multiple paths into a system or service for executing an action. There could also well be multiple people from different parts of the organization that have access to the various entry points for IaC. Adding further complexity is that some organizations might not be effectively communicating about objectives and required changes across a distributed organization.

Core Security Principles
A primary foundation for securing infrastructure created and managed by IAC templates is by first establishing a source of truth for configuration. There needs to be a codified version of configuration, usually in a Git software repository, that defines the desired state of configuration. It's an approach that some refer to as GitOps, which helps to enable IaC. With a defined source of truth, it's time to implement access, audit, and review processes.

Define a Single, Secure Path to Production
To fully secure IaC, there also must be a well-defined single path to production, so that all stakeholders in the organization, including developers, operations, and security are involved.

Defining the path to production is often about breaking down silos within the company and focusing on cross-team collaboration. More often than not in the past, developers have viewed security as a blocker and not as an enabler. The security-as-code approach can help to change that mindset by working with developers in a language they understand: code.

A key concept that we have seen work well is the use of guardrails, rather than gates, as part of the SaC process. Rather than implementing a gate, where code cannot pass through unless it is approved by security, a guardrail keeps code within certain defined boundaries, that limits risk.

Guardrails can help developers and organizations to focus on speed, in a way without sacrificing security.

Security as Code in Practice
How does it actually work to improve security? The reality is that with continuous visibility you can ensure correctness, alert and then correct any divergence in a repeatable, auditable, secured approach.

Here's just one example where this approach can help. The issue of unsecured cloud storage buckets, often on Amazon S3, is one that is well documented and has been reported on extensively at Dark Reading and other places. The SaC model can help to effectively eliminate that risk.

By running continuous compliance assessments of cloud environments, an organization can be alerted whenever an S3 bucket has been inadvertently provisioned with public read or write access. An administrator can then go to the Git repository where the configuration code for the IaC service is defined and make the required change to eliminate the risk. After the change has been committed, it can get through the approval process, and once accepted, the IaC pipeline can execute the code to remediate the issue across all deployments. The entire process is logged and auditable as well.

Mistakes happen, and vulnerabilities seem to come from new places all the time. But with the SaC approach, it is possible to codify and enforce a secure state of application configuration deployment that limits risk.