Why investing in IaC security should be top of mind for DevOps and security teams

Defining IaC

Embracing DevOps is all about improving the speed and efficiency of delivering software, and as cloud technologies verge more and more into the software realm, DevOps and IaC go hand in hand. All the scalability and flexibility that cloud-native environments have to offer are made better by IaC.

IaC enables you to manage your cloud infrastructure the same way you do applications, services, and other code you rely on. It eliminates manual configurations, as well as the development of one-off scripts that you would typically need to make adjustments to your infrastructure. Instead, it allows the infrastructure to be managed just like you would any code.

As a result, it enables your infrastructure to fit into your CI/CD provisioning practices and keep up with all the changing demands put on dynamic cloud-native environments.

We think it’s also the secret to cloud security.

The security problem and opportunity

As with any emerging technology, however, security isn’t as top of mind as it should be. We’ve found that nearly 1 in 2 infrastructure as code modules contains misconfigurations (as we found in our recent State of Open Source Terraform Security report).

It’s not that surprising, either. Because IaC doesn’t present itself as an immediate risk or attack surface at first glance, it hasn’t quite caught the attention of security teams.

Almost universally, IaC falls under the purview of engineering and DevOps, leaving security teams to keep their attention focused on more traditional cloud security posture management solutions. Up until recently, those solutions have been concerned with monitoring cloud resources already in production where the risk is more immediately addressable. For example, a publicly exposed S3 bucket is more of an immediate risk than code that could result in exposed buckets if the right protective layers aren’t in place. Or is it?

At the same time, we’re asking more and more from developers, many of whom admit have not been adequately prepared to take on security (as revealed in this global DevSecOps Skills survey).

It’s also becoming more and more difficult for DevOps teams to keep up with expanding cloud footprints and the diversifying mix of technologies being used in these environments. It’s increasingly difficult for organizations to answer questions like:

• What configuration languages are being used across teams?
• Are new cloud services adhering to all appropriate security and compliance policies?
• What templates are developers using to write cloud infrastructure?
• Is everything verified and vetted for security before going into production?

For many of those questions, it’s hard to say who exactly should have the answer. Therein lies the problem.

The risk of turning a blind eye to infrastructure as code

Developing and managing all this infrastructure at scale is complex, and security and DevOps teams on their own don’t possess the know-how, access, or tools they need to take on security.

As a result, it’s easy for security measures to be missed and cloud resources to be incorrectly configured. For example, it is common for engineers and developers to:

• Use default configurations that haven’t been optimized for security.
• Not enable logging, which makes it difficult to troubleshoot or assemble an audit trail.
• Use unencrypted databases that leave data vulnerable to corruption and exfiltration.
• Deploy insecure protocols (e.g., not using HTTPs or TLS).
• Leverage vulnerable microservices.

(For a more in-depth look at some of these mistakes, check out my recent Open Security Summit workshop.)

The problem is that inadvertent misconfiguration due to human error introduces risks that can leave your infrastructure—and your business—exposed. But we aren’t telling you anything you don’t know. So what can you do?

Investing in IaC security

Incorporating IaC security into your software development can transform your infrastructure security posture by:

• Promoting transparency and immutability of your cloud resources
• Preventing bad configurations upstream that cause a reactive rather than proactive culture.
• Improving costs and efficiencies through prevention

At Bridgecrew, we believe that as cloud orchestration moves left, security needs to move that way too and to do that, you need not only to invest in the tooling but in the processes and culture along the way.

Tooling

To help security and DevOps teams protect their cloud-native infrastructure, infrastructure-as-code static analysis tools (including our own open-source tool, Checkov) have emerged. They scan for common issues by extrapolating cloud security and compliance best practices to the infrastructure-as-code layer to find existing issues.

Process

But scanning every so often isn’t enough. As is the case for any software testing and assurance, it needs to be embedded into everyday workflows for it to be effective and used by developers. Adding IaC policy governance to your existing tests as part of every build via your CI/CD pipelines is a great way to start. At the very least, you should know what you’re deploying, but ideally, your setup should be designed to block deploys if any of your IaC policy checks fail.

Culture

This is a software problem, but it’s also a people problem. To systematically fix and prevent issues within your infrastructure code, you need to ensure that it aligns with your teams’ goals and motivations. For security, that may mean prioritizing compliance. For DevOps, that may mean prioritizing efficiency and scalability. The good news is, you can do both while prioritizing security!

The transformation to a proactive, transparent, and efficient DevSecOps strategy takes time, but investing in that transformation will help you establish and maintain a scalable, compliant security posture. With the right tooling, processes, and culture, you’ll save time and resources while doing it.