Cloud security has long been focused squarely on the cloud runtime environment to keep infrastructure free of misconfiguration vulnerabilities that can open the door to hackers and lead to data leaks and breaches. It is reasonable considering most (if not all) cloud-based security incidents result from customer mistakes in the form of cloud resource misconfiguration. Gartner calls this Cloud Security Posture Management, or CSPM. 

While the nature of cloud risk remains unchanged (it's still predominantly misconfiguration), where our cloud security efforts are focused is changing, and it’s changing fast. The adoption of infrastructure as code (IaC) tools such as Terraform and AWS CloudFormation introduces the risk of deploying misconfiguration efficiently at scale. However, it also presents us with the opportunity to eliminate misconfigurations in the development phase, pre-deployment — which wasn’t previously possible.

Because of Iac, we can now shift left on cloud security. 

Infrastructure as code is now mainstream (and IaC security is growing)

Fugue recently partnered with Sonatype to commission a survey of 300 cloud professionals (i.e., DevOps, engineers, security), and what we found is that 90% of cloud teams using have at least some IaC in place, and its adoption is widespread from startups and large enterprises. 

Because most are operating with compliance and internal security policies, most are focusing some effort on getting their IaC secure (although 27% aim to catch misconfiguration once infrastructure is deployed). 33% manually review IaC templates for security issues, which can be slow, error-prone, and time-intensive.

What’s clear from our survey is that teams are devoting a significant amount of engineering time to ensure IaC is free of misconfiguration vulnerabilities and compliance issues. Half of those surveyed invest 50 or more engineering hours per week in securing IaC. Challenges teams face with cloud and infrastructure as code security include hiring and retaining experts (cited by 36%), training (35%), and using different tools and policies for IaC and cloud runtime security (45%). 

To bring efficiency to IaC security, teams are adopting open source IaC checking tools. Open Policy Agent (OPA), an open standard for policy as code sponsored by the Cloud Native Computing Foundation (CNCF), has gained prominence for many cloud use cases, including IaC checks. Regula is an IaC policy engine that leverages OPA to check Terraform and AWS CloudFormation templates, comes with hundreds of pre-built policies, and provides devleoper tooling to develop custom rules using OPA's Rego language. 

Many cloud misconfigurations can be caught using IaC checks

Cloud teams are experiencing a variety of dangerous misconfigurations, and our survey found that, for the first time, Identity and Access Management (IAM) is the most common (cited by 41%). Cloud IAM resources effectively serve as a new network, and IAM misconfiguration has played an increasing role in cloud breaches over the past few years as attackers use it to discover resources, move laterally, and access data for extraction.

In most cases, the misconfigurations cited can be caught pre-deployment with effective security checks on IaC. Doing so drastically decreases cloud risk, and fixing issues in IaC is generally faster and less expensive than fixing them in the cloud runtime. Half of the teams we surveyed experience 50 or more misconfiguration events per day in their cloud environment. Catching many of those in development can save time and headaches.  

But not all cloud misconfigurations can be caught with IaC checks

It’s critical to note that not all cloud vulnerabilities can be caught in development with IaC checks. Identifying cloud misconfiguration requires the full context of an environment, and IaC templates typically only encompass some part of the environment. A resource configuration may be perfectly safe in one context and extremely dangerous in another. 

Another reason security checks on IaC can’t provide total protection from cloud misconfiguration risk is that cloud drift occurs — a lot. It’s rare that IaC is used to provision an entire cloud environment, and modifications to environments are frequently made outside of IaC and CI/CD pipelines. Therefore, unlike application security, where runtime mutation is more uncommon, continuous cloud runtime monitoring is essential for cloud security. 

Finally, orphaned resources were cited as a problem by 26% of respondents. These are resources that have been forgotten and left unmonitored and unpatched. They can provide hackers with entry points to an environment and have played a role in many recent cloud data breaches. Orphaned resources are an obvious example of the kind of vulnerability that can’t be addressed with IaC security. 

About IaC and the software development lifecycle (SDLC) for cloud infrastructure

The software development lifecycle (SDLC) is a concept in computer science dating back to the 1950s and has evolved quite a bit over the years and includes different approaches, such as waterfall and agile. Regardless of the specific approach taken, the SDLC concept is designed to produce higher-quality software in the shortest amount of time. Stackify has a nice article on the SDLC. 

Since the introduction of Infrastructure as a Service (IaaS) public cloud offerings such as Amazon Web Services (AWS), cloud infrastructure has also had its SDLC — but with some key phases missing. There were requirements, design, architecture, and deployment phases, but it lacked a true development phase because the primary means of provisioning infrastructure was the cloud providers’ console interfaces — which involves a lot of pointing and clicking. Testing was typically performed on live cloud environments — unit tests on dev environments, and integration tests on test or staging environments. 

With IaC, cloud ops now look a lot more like a true SDLC, and it’s sometimes referred to as the cloud development lifecycle (CDLC). Considering cloud infrastructure is 100% software that can be programmed, IaC is a natural fit. We can now express our cloud infrastructure as code (or, more specifically, configuration files) and provision/modify/destroy cloud environments programmatically. IaC has brought scalability, consistency, and predictability to cloud infrastructure ops. It also means we can test infrastructure for adherence to compliance and security policies earlier in the SDLC, pre-deployment.

Here’s a simplified diagram of the cloud infrastructure SDLC, with its corresponding security checks:

Different teams are generally concerned with different phases of the cloud SDLC:

• Cloud engineers (often DevOps) use IaC to develop and deploy cloud infrastructure, often in CI/CD pipelines.
• Security teams monitor cloud environments for vulnerabilities.
• Compliance teams manage compliance audits of cloud environments

With the right cloud security platform and policy framework, all teams can better work together using the same policies at every stage of the cloud infrastructure SDLC. Considering 38% said that cloud security is a cause of friction between teams, and 96% say having a single policy framework that works for IaC and the cloud runtime would be valuable, consider this when selecting cloud security solutions.