The Importance of Infrastructure as Code Security Scanning
The problem with using Infrastructure as Code without security testing
Today, most, if not all companies are seeing the value in deploying infrastructure through Infrastructure as Code (IAC), whether it be Terraform, AWS CDK or Cloudformation, Azure RM Templates, or others. However, I’m willing to bet that not all organizations are implementing or even thinking about adding any security testing for their IAC code. Cloud misconfigurations are becoming a common root cause for breaches by malicious entities. Public S3 Buckets and Compute Instances with open firewalls to the entire internet are just a couple examples of permissive configurations that an engineer can deploy out. These misconfigurations can cost your company up to the trillions in US Dollars if you aren’t careful¹.
You may have seen my previous article about the importance of auto-remediation in Google Cloud and how auto-remediation can help you detect and respond to misconfigurations that pass through your security gates. In this post, I’m going to take a step back and talk about the importance of adding security to your IAC development lifecycle to help prevent misconfigurations before they get deployed to your cloud environment.
How can we scan Infrastructure as Code for misconfigurations?
There are many tools, from open source, freemium, and paid, that can help you scan your IAC templates for unwanted configurations. Some examples are Aquasec’s tfsec, Snyk IAC, Palo Alto Bridgecrew’s Checkov, Checkmarx’s KICS, datree, and Hashicorp’s Sentinel which comes with the Terraform Cloud/Enterprise package. All these tools can enable us to prevent IAC misconfigurations.
To get started, keep in mind the workflow below which shows a pretty simple way we can deploy IAC end to end in our cloud before adding security in the mix. We’ll talk about three different areas in the end to end workflow of where we can integrate security testing. We’ll also be using this repo for examples in the different areas.
Scanning source code locally in a workstation (CLI, IDE, etc.)
Let’s start with scanning source code locally. As a security organization, our job is to reduce as many security vulnerabilities as possible. One way is to enable the engineers who work with IAC that will be deployed. If we take a look at the workflow above, it starts with the engineer. We can help to enable the engineers by giving them tools that can scan their IAC right from their workstation. Aquasec’s tfsec is a good example for testing IAC using a command line interface (CLI). Having a tool that can scan IAC locally can enable the engineer to run on demand, self-service scans. By empowering the engineers with self-service tools like tfsec, the security team can also benefit from this by potentially getting less security misconfigurations committed to the Source Code Management (SCM) tool.
Here is an example output of tfsec running against that example Terraform repo locally in my workstation’s CLI.
Tfsec does a good job of showing what Terraform resources can potentially violate security policies. In the example above, we can see that tfsec picked up the cloudsql instance that isn’t configured to require SSL and it is granted public internet access. Those are just some controls that security teams wouldn’t necessarily want. These tools also give some good information about what these findings mean as well as give examples of how to secure the resource.
With this example completed we can point out in the workflow where we can implement our first layer of defense as shown below.
Scanning source code directly from your SCM (Github, Bitbucket, Gitlab, etc.)
There are tools available like Snyk which can integrate with your SCM tools. Now, Snyk isn’t just a tool for IAC, it can be used to scan application code and artifact and container registries. Snyk can also integrate into continuous integration tools, and IDEs like VSCode or Sublime. Below is a snippet of what SCM tools Snyk can integrate into.
Using our example repo that contains vulnerable Terraform code, below are the results from a Snyk IAC scan where Snyk shows that our Google Cloud SQL instance doesn’t have SSL enforced nor does it have IAM configured. Snyk also does a good job of showing the impact of this configuration and how we can resolve it.
Integrating SCM directly to IAC scanning tools like Snyk is beneficial to securing your development lifecycle. Scanning your SCM adds an additional layer of security and can catch code that Engineers may not be scanning via their local workstation/CLI. With this addition, we can now see our second layer of defense in the workflow.
Scanning through build steps in your orchestrator (Github, Jenkins, Cloudbuild, etc.)
We’ve now covered two areas in the end to end workflow of how we can implement security testing for IAC. Let’s talk about one more place where we can add security tests before IAC gets deployed to your cloud.
If we look at the workflow for deploying IAC, there isn’t anything automatically checking the Terraform code in the deployment pipeline to see if there are configurations that we don’t approve of. Assuming there are no preventative controls in your cloud environment, in this case Google Cloud Organization policies, this current flow could still allow an engineer to deploy a compute instance with permissive firewalls or publicly accessible storage buckets. I’m sure we don’t want that.
This is where we can add a tool like tfsec or Snyk as a build step to scan terraform for configurations we don’t want. The flow below shows how adding a step to scan Infrastructure as code can prevent misconfigurations before it gets deployed out. If the code being deployed has violations we can create a step to fail the build and alert the necessary teams with the necessary info pulled from the build logs.
Let’s use Github Actions as our example orchestrator against our vulnerable IAC code. We’ll be using Snyk and tfsec to scan our IAC in Github Actions. Snyk and tfsec both do a great job with documenting examples for Github Actions. As shown below, you can see that the build step failed due to catching errors during the deployment pipeline.
You could take it one step further and add alerting for failed builds due to violations like these.
So now we can add that third layer of defense into your IAC development lifecycle. These layers are essential to secure IAC development as they provide security and peace of mind to ensure that misconfigurations are being caught before deployment to your technical landscape.
So… why is this important?
Implementing security steps early on in your development like the ones mentioned above can help you prevent misconfigurations from being deployed into your technical landscape. Cloud misconfigurations have cost companies extensive financial and reputational damage. One example is data exfiltration, which is one common breach that is possible potentially due to misconfigurations. A malicious user can get access to data that could contain private identifiable information or other highly confidential company information. Which could then hurt the company and others who are involved.
Terraform is only one example of what fits in the Infrastructure as Code domain. There are others like Azure RM, AWS Cloudformation or CDK, Helm Charts, dockerfiles… the list can go on. Adding security gates into your IAC development lifecycle allows you to harden your workflow to have an additional security layer which can help prevent misconfigurations and breaches into your organization.
A couple of things to note
This solution works best when you have governance around how your IAC is deployed. If there is no centralized way of deploying your IAC, then there isn’t much of a way to ensure that these layers of defenses are being appended to deployments into your landscape. It is crucial that your organization centralizes the method on how you deploy your IAC so that you can start enforcing these controls.
If you’re interested in adding more security into your development lifecycle, I recommend reading more into DevSecOps and shifting security left to the developers. This concept brings thought to enable the developers and engineers who work hands on keyboard with the code that goes into your cloud and infrastructure. Implementing security at the early stages of development can help benefit the organization and potentially keep yourself safe from malicious breaches. It might just save you from a costly breach too.
About Don
Don is a Security Manager at Accenture, focused around Application Security, Cloud Security, and DevSecOps. He’s taken on roles with Fortune 100 firms to run cloud and application security assessments, while also implementing security testing and controls around the client’s ecosystem. Interested in deploying this out to your environment? Let’s connect!
Disclaimer:
My postings reflect my own views and do not necessarily represent the views of my employer, Accenture. The information in this blog post is general in nature and does not take into account the specific needs of your IT ecosystem and network, which may vary and require unique action. You should independently assess your specific needs in deciding to use any of the tools mentioned. tfsec and Snyk, etc. tools are not an Accenture tool. Accenture makes no representation that it has vetted or otherwise endorses these tools and Accenture disclaims any liability for their use, effectiveness or any disruption or loss arising from use of these tools.
Originally published at https://www.linkedin.com.
