With infrastructure as code (IaC), you can treat infrastructure like code and apply the same software development practices and processes to your cloud environments as you would to regular application code. For example, you can do Static Application Security Testing (SAST) on IaC. The benefits were discussed in a previous blog post so we will not cover them here, but rather recap two of the key benefits. IaC enables you to rapidly deploy cloud environments and makes your infrastructure more manageable. The shift left security approach (discussed in another blog post) reduces risks and eliminates security issues early in the development cycle. In this post, we want to deep dive into security testing tools for IaC. We will look at the different security testing methodologies for IaC.
Comparing IaC Security Testing with Application Security Testing
In the world of application security testing, SAST analyzes source code to find security vulnerabilities that make your applications susceptible to attack. We are beginning to see similar SAST tools for IaC. These tools analyze source IaC to find security violations that can inadvertently expose your cloud infrastructure. Example tools are Checkov, tfsec, AWS CloudFormation Guard, and HashiCorp Sentinel to name a few.
A common critique of static analysis is that they produce many false positives. In other words, they flag issues that are not true issues or issues that are not interesting enough to resolve. SAST tools for IaC are no exception. When we evaluated these tools, we found them to be extremely noisy (more about this later).
To complement SAST in application security testing, dynamic application security testing (DAST) was created. It is another testing methodology that identifies security flaws in applications using runtime analysis. SAST tools are not going to find runtime errors so this is where DAST tools come into the picture. Therefore, it is reasonable to anticipate a different testing approach to address the shortcomings of SAST tools for IaC. We need the ability to catch true security issues at build time without interrupting delivery unnecessarily.
Introducing Cloudrail, an augmented static analysis tool for IaC
We recently released Cloudrail, the industry’s first augmented static analysis tool for IaC, to address the pitfall of SAST tools for IaC. The best way to describe this new approach is to contrast that with a SAST tool for IaC.
SAST for IaC
|Augmented SAST for IaC (Cloudrail)|
Scans source IaC (e.g. Terraform, AWS CloudFormation, Azure Resource Manager templates, etc.)
|Scans both the source IaC files and the live cloud environments|
|Finds security violations early in the development life cycle.|
Finds security violations early in the development life cycle but it can potentially be used to assess the cloud environment after deployment.
|Produces many false positives. |
For example, it will alert about a security group with SSH being open to the Internet even if it’s not used, or it may be used in a scenario where exposure to Internet traffic is not possible.
This forces developers to add many exceptions in their code to reduce the noise.
Drastic decrease in false positives vs SAST tools through context analysis.
Cloudrail analyzes the relationships between the resources in the IaC files, as well as their relationships with resources already provisioned in the cloud.
For example, before highlighting a security group as a potential issue, it will review whether it is in use, what subnet(s) it’s used in, their NACLs, their routing to the Internet, etc., to determine if there is any exposure that needs to be addressed.
Essentially, it employs the same logic a human would to determine how severe a specific violation is.
|Similar to SAST tools for applications, these tools cannot catch runtime issues. They only factor the build state with a partial view, specific to the sub-section of the environment. These tools cannot discover environment-related issues, as a result many security issues can be overlooked.|
Cloudrail evaluates the “build state” and the “run state.” It takes the IaC file and overlays its snapshot of the live environment to build a full picture of how the environment will look like after the IaC contents are applied.
For example, Cloudrail can detect a resource being indirectly exposed by another resource (read this blog post for more information). This allows Cloudrail to catch complex security issues completely hidden from SAST.
|Simple to use and fast to run.|
A much more comprehensive approach when you have to factor the live cloud environment so the evaluation takes longer to run and with more resources.
|Unable to provide insight with respect to the severity and priority of security issues because SAST tools for IaC do not have visibility to the production cloud environment.|
With augmented analysis, Cloudrail gives you more granular abilities around deciding the severity and priority of issues.
For example, you can easily set a data store to encrypt in AWS if you haven’t provisioned it yet. If you have, the cost to change it after the fact is very high (read this cloud encryption post).
The fact that Cloudrail can see whether the data store is already running in production (or not) enables it to appropriately increase (or decrease) the priority. If the data store has not been provisioned, Cloudrail will set the priority to high knowing that it is cheap to fix now. This level of insight can end up saving you a lot of time and yet not possible with SAST tools.
Cloudrail’s Relationship Database
Although we describe Cloudrail as an augmented “SAST” tool for IaC, Cloudrail uses a very different technique from a SAST tool for applications. Instead Cloudrail builds a relationship database among cloud resources.
Cloudrail understands security groups are attached to resources and they are related to subnets. Subnets are related to network access control lists and in turn, they are related to routing tables. Routing tables are associated with Internet gateways. Effectively, Cloudrail compiles a rich source of intelligence that can calculate the blast radius of a planned configuration change before it is implemented. Before you implement a configuration change in your environment, Cloudrail asks a “what if” question.
- What if you change the configuration of a security group? What resources will be impacted? Are there any resources that will be exposed? Are there other security controls in place such as network access control list that will have no impact on the change?
- What if you deploy a RDS database in a subnet, are there other resources within the same subnet that can indirectly expose the database to the public? Could attackers move laterally and access the RDS database that is restricted?
By asking these questions, Cloudrail uses the blast radius concept to consider the amount of damage that could be caused by a configuration change. This prevents misconfigurations from happening in your environment.
Minimizing risks by adopting Indeni Cloudrail for IaC
Both types of testing tools for IaC come with their advantages and disadvantages. SAST tools are limited in scope and they can be very noisy, but they are fast to run. An augmented SAST tool understands the cloud resources relationships and performs in-depth analysis to minimize the blast radius. It may take longer to run but it is a lot more intelligent than a SAST tool.