Securing infrastructure as code: Perils and best practices

As organizations embrace cloud computing, the rate of infrastructure-as-code (IaC) adoption continues to rise. As with many new technologies, security is often bolted onto IaC or forgotten entirely. Securing IaC is important. Here’s how to best do so and the risks of neglecting this critical security activity.

What is infrastructure as code?

Traditional ways of deploying infrastructure involved procurement processes, physical infrastructure, long wait times, and server racks. Even with the advent of cloud computing, initial methods of managing infrastructure involved “click-ops”, as it is called, or manually going into the cloud service provider’s (CSP’s) console and instantiating infrastructure directly. This approach is inefficient, error prone, and doesn’t scale when dealing with enterprise cloud environments.

IaC changes this paradigm by allowing for the codification and programmatic management of infrastructure, much like you would do with traditional application code. This means you can use practices such as source control, versioning, re-use, portability, drift detection, and automation.

Popular IaC versions include CSP-specific flavors of IaC such as AWS’s Cloudformation or Azure’s Blueprints. There are also popular third-party IaC options with HashiCorp’s Terraform being the most popular with over 100 million downloads. The benefits of a third-party IaC is that it can be used across multiple CSP environments.

With ease, speed comes risk

For all the benefits of IaC, there are perils that you must be aware of to avoid introducing unnecessary risk into your cloud environments. Quickly provisioning IaC templates means potentially quickly introducing insecure configurations and risks across enterprises. The same can be said for taking advantage of publicly available IaC templates. These templates can and often do contain deviations from security best practices or insecure configurations.

Palo Alto’s Unit 42’s Cloud Threat Report: Spring 2020 uncovered many alarming findings. Despite the ability to enforce security through IaC, organizations often did not do it. Nearly 50% of CloudFormation templates examined had potentially vulnerable configurations. They also identified that nearly 22% of all Terraform configuration files examined also had at least one insecure configuration.

Research conducted by IaC security firm BridgeCrew analyzed over 15,000 Terraform files and identified nearly 50% of them included misconfigurations that could expose organizations’ data or compromise workloads. There were over 10 million downloads of those files. 

As these studies show, while organizations are maximizing their use of IaC, they often do so without vetting templates for security misconfigurations and vulnerabilities. This includes both internally developed IaC templates and those taken from public repositories. Exercise caution when using existing IaC templates, either from public or internal repositories, and vet them for misconfigurations and vulnerabilities.

Given that most cloud data breaches are the result of customer misconfigurations, shouldn’t we be injecting more security rigor into the quick and dynamic provisioning of IaC that has the potential to replicate misconfigurations at scale?

Security best practices for infrastructure as code 

Since IaC is used in the same fashion as other code mechanisms, you can integrate it into similar structures and workflows. This means it can be stored in source code management (SCM) repositories, integrated into continuous integration/continuous deployment (CI/CD) pipelines, and scanned in runtime.

There are many IaC scanning tools to explore. Some of the popular open-source options include Terrascan, Checkov, and TFLint. Each can scan cloud infrastructure templates against thousands of policies aligned with myriad compliance frameworks for both compliance violations and insecure configurations that introduce vulnerabilities.

The IaC scanning platform from Accurics, for example, allows you to scan IaC templates such as Azure Blueprints, AWS Cloudformation Templates and Kubernetes YAML manifests to ensure that vulnerable configurations or misconfigurations are not introduced to your environments. Accurics contains over 1,500 policies across 10 standards such as CIS Benchmarks, SOC2, PCI DSS and HIPAA.

Accurics

This includes scanning these templates when they are first created and stored in SCM repositories, which ensures vulnerabilities or compliance deviations are brought to the attention of the IaC authors quickly for remediation.

IaC templates can also be scanned as part of CI/CD pipelines with various control gates to ensure that they are not promoted to runtime environments and introduce undesirable risk to an organization’s cloud environment. This helps validate that any infrastructure being provisioned in the environment doesn’t introduce vulnerabilities. It also helps ensure that anything provisioned aligns with applicable organizational and industry compliance frameworks.

Lastly, there is a need to implement continuous cloud posture management (CSPM) to ensure that previously “known good” IaC templates that were allowed to provision and execute haven’t deviated and insecure or non-compliant changes haven’t been manually introduced. This is where you must ensure you are continuously scanning your runtime environments to monitor for these sorts of scenarios and risks. When drifts and violations are detected, you can work toward implementing remediation-as-code to restore your environment to a previously reviewed and authorized state.

It is also important to scan the SCM repositories of IaC periodically as new compliance and security checks are added to the tooling that may not have existed when the IaC templates were initially committed. This helps uncover previously unknown findings that may now exist.

First steps to IaC governance

Organizations can begin the path of implementing IaC governance by determining items such as what forms of IaC are being used in their environment, by whom, where, and how these templates are being created, stored, and executed. Then security teams can begin to introduce some rigor using tools such as those mentioned above to begin integrating into existing workflows, discovering vulnerabilities and compliance deviations, and providing quick feedback for remediations to IaC authors.

As with anything in security, it is important to integrate with existing workflows and methods to avoid becoming a bottleneck. You want to introduce “healthy” friction to developer workflows to ensure that productivity is not unnecessarily impacted by vulnerabilities and compliance concerns are addressed, while still allowing teams to operate at a speed of relevance for stakeholders and customers.

As organizations increasingly adopt cloud computing, shift to DevOps/DevSecOps approaches, and seek to increase velocity and dynamic capabilities, IaC adoption will continue to climb. If security leverages the practices and tools discussed, they can help facilitate this adoption securely, while ensuring their organization doesn’t rapidly introduce unwarranted risk and even exploitation of cloud environments.