Infrastructure as Code Security Requires Programmatic Controls

Empower develops with a programmatic approach to security. Here's what you need to know.

The concept of shifting security as far left into development as possible is not new, and it is fairly easy to see the benefits: when you catch issues earlier in the software development lifecycle (SDLC) you reduce your exposure before runtime. Yet, when it comes to cloud infrastructure security, detecting misconfigurations typically only happens at runtime. When you consider the mechanics, this approach doesn’t make a lot of sense. And it is also very expensive to resolve issues this late in the software development lifecycle.

These days, cloud infrastructure is being programmatically defined — through Infrastructure as Code (IaC) — using tech like Terraform, Kubernetes or Helm Charts, and misconfigurations are often introduced in the process. Leaving misconfigurations unaddressed at this critical point in the SDLC not only creates security technical debt, it can also increase risk. If a breach path is present as a result of the misconfiguration, the entire organization and its customer data may be left up for grabs by threat actors.

In the last two years alone, we’ve seen more than 200 cloud breaches that exposed more than 30 billion records as a result of cloud infrastructure misconfigurations. What’s more, these breaches have occurred within organizations that have significant investments in cloud security. It’s evident that, as an industry, we need to rethink cloud security architecture.

Cloud infrastructure security needs to be programmatic

Developers are no longer responsible only for the applications that they develop. Increasingly, they are taking on an architectural role in what the software infrastructure looks like, and programmatically defining that infrastructure through code. It stands to reason that if developers are taking a programmatic approach to define infrastructure, then they will need a programmatic approach to security which supports their efforts.

A programmatic approach empowers developers to detect and fix cloud infrastructure misconfigurations during development to establish a secure posture, and enables organizations to maintain the posture in runtime without slowing down development velocity.

What does a programmatic approach to IaC security entail?

In December 2020, the Kubernetes Product Security Committee disclosed a vulnerability that affects all versions of Kubernetes. The vulnerability (CVE-2020-8554) has the potential to allow an attacker to intercept traffic in a multitenant cluster by exploiting the features of LoadBalancer or ClusterIP service types. Attackers may be able to implement a “man in the middle” attack, and the only mitigation is to restrict access to the exploitable features. When we consider the application of programmatic infrastructure security, Policy as Code (PaC) can help in this scenario. Through PaC, DevOps engineers have the ability to define policies that assess Infrastructure as Code for compliance or security best practice violations, like those defined through Open Policy Agent (OPA). In the case of CVE-2020-8554, where ClusterIP and LoadBalancer services are vulnerable to attack, PaC can be used to ensure that no ClusterIP service that contains an externalIP spec is allowed to be created.

Policy as Code is the foundation of a programmatic approach to IaC security, but it only offers an alert mechanism for detecting compliance or security best practice violations — it doesn’t help to prioritize risk, and may add to alert fatigue for developers. While all vulnerabilities and misconfigurations need to be addressed, some pose a higher risk than others because they enable a breach path, and they need to be prioritized in the remediation queue. This is where Security as Code comes in, as it enables developers to programmatically conduct threat modeling to understand which vulnerabilities create a breach path through an exposed component.

With programmatic detection and prioritization comes a need for programmatic remediation as well, which is where Remediation as Code comes into play. The reality is that developers are not security experts, and while there are great efforts to ensure that developers have the security training they need to securely provision cloud infrastructure, they also need to be able to resolve risk without hindering development. In an ideal world, the IaC with secure configurations can be generated and sent to developers as a pull request. Then all they need to do is review the code and merge it into their main branch.

Enabling developers to programmatically detect and fix misconfigurations in IaC during development dramatically improves security posture. These same policies need to be enforced during the CI/CD process as a final checkpoint and block builds with any remaining critical misconfigurations until the development team is able to correct them. Additionally, these misconfigurations can be overridden with secure defaults (self-healing) to prevent security from hindering development velocity.

Extending security posture from development into runtime

Even if a secure posture is established through IaC during development, the reality is that configuration changes to cloud infrastructure do occur in runtime, causing the configuration to drift away from what was defined through IaC. This introduces a whole host of operational and security challenges, and a programmatic approach is required to address them.

Each configuration change in runtime needs to be detected (Drift as Code) and assessed for risk using the same Policy as Code and threat models (Security as Code) that were assessed during development. If a configuration change doesn’t introduce risk – like increasing the memory configuration of a compute instance – a pull request (Remediation as Code) with the updated configuration needs to be sent to development to update the IaC, bringing it inline with the configuration in runtime and eliminating drift.

However, if a configuration change introduces risk – like opening an SSH port up to the internet – the cloud infrastructure should be redeployed using the configurations defined in the IaC to eliminate the risky configuration drift. This means that you are always able to rely on the IaC as the single source of truth.