Securing your Cloud Infrastructure with Infrastructure as Code Security

Securing your cloud infrastructure is by no means a simple task. To do that, you may use any sort of Cloud Security Posture Management (CSPM) tools. In short, these CSPM tools help you find and remediate vulnerabilities and misconfigurations in your production workloads. But what if you could avoid those vulnerabilities and misconfigurations from reaching your production workload in the first place?
In this article we will review how cloud infrastructures are provisioned, then understand the security hazards that come with these methods, and finally discuss how to mitigate those security hazards.

Cloud Infrastructure lifecycle

Cloud infrastructures are constantly changing. Whether you scale out, add a new functionality, or just replicate existing infrastructure in a different location, infrastructures change frequently, sometimes on a daily basis. These changes are typically automated with Infrastructure as Code (IaC), which lets you describe your infrastructure (such as compute units, storage, or other managed services) through code or computer readable configuration files. These files let you define how you want the cloud infrastructure to look like, including its resources, configuration, access controls etc. When you want to create such a piece of infrastructure, you just provide the IaC framework with that file, and you get that infra created for you automatically. This is useful for allowing those constant changes in workloads, but you could also describe an entire workload in such files, to allow easy creation, replication and recovery of your workloads. Then with a few clicks, you can spin up your cloud workloads.
In recent years, more and more companies are moving their workloads to the cloud. According to predictions in the industry, by the end of 2021 67% of all enterprise infrastructure will be cloud based. As a result of that flow to the cloud, IaC has been widely adopted in the last few years, and became a standard for managing cloud workloads and infrastructures for many companies.

The Hazards of IaC

IaC has changed the way we operate in the cloud - with just a few clicks anyone with very little IT knowledge can create resources in the cloud. The problem with that simplicity is that it is now very easy to create vulnerable and misconfigured cloud workloads.
In a recent report made by IBM it was found that 15% of the 524 data breaches surveyed in that report were initiated by a cloud misconfiguration, causing an average total cost of 3.86 million dollars per data breach. Furthermore, according to the State of Cloud Security 2021 Report 49% of organizations have more than 50 cloud misconfiguration incidents per day. Combine the above numbers, and you’ll get a very high security risk just from operating in the cloud.
To emphasize the point even more, it is enough to google “s3 data breach” to get a sense of the blast of data breaches involving Amazon's AWS Simple Cloud Storage (s3), all started when sensitive data stored in s3 was left open to the public internet.

It is true, not all cloud infrastructures are created by IaC, and even those that are created with IaC sometimes modified manually after deployment, but nevertheless, a significant number of the cloud data breaches could have been avoided if companies would have used an Infrastructure as Code security tool.

Infrastructure as Code Security

So how do we mitigate the risk of cloud misconfigurations? These misconfigurations can be easily found and fixed, at a minimal cost, if you integrate a Static Code Analysis tool for your Infrastructure as Code. Similar to SAST tools for code, these tools scan the IaC files to find vulnerabilities and misconfigurations in the definition of the infrastructure and help you remediate them. This happens before those misconfigurations reach production, thus significantly reducing the attack surface of the application, and improving the overall cloud security posture. More than that, since these tools can scan the files while they’re being written, the feedback is immediate, making the effort to fix the misconfigurations minimal.

This is yet another reason why you should Shift Left your security. If you properly plan your security strategy in a way that shifts left whenever possible, not only the attack surface dramatically reduces and the cloud security posture improves, but also costs tremendously reduce, due to the offloading of security related activities to the software development teams which then allows them to close the loop as early as possible.