The introduction of new technologies and processes can often be disruptive and perceived as having a negative impact on an agency. And the introduction of infrastructure as code (IaC) has had that reception as cybersecurity teams within the Department of Defense evaluate whether it will be a help or a hindrance for the agency. In this interview with Ben Stokes, a professional services manager at Checkmarx, Ryan Schradin, the managing editor of GovDevSecOpsHub explores the challenges and opportunities IaC brings to the table.
Last month, ICIT sponsored an online panel discussion featuring a number of application development and cybersecurity experts from across industry, the federal government, and the Department of Defense. This panel discussion focused on two new security vectors that have arisen as application development practices and technologies have evolved – infrastructure as code (IaC) and APIs.
During that discussion, panelists painted IaC as a technology that could either improve or hinder security – depending on how securely IaC modules are built. They discussed how – when untested and not secure – IaC can effectively spawn new vulnerabilities across the entire enterprise. However, they also stated that hardened IaC modules, built deliberately with security in mind, could make agencies more secure.
To learn more about the ways IaC can be helpful, or harmful, to an agency, we spoke with Ben Stokes, a professional services manager at Checkmarx.
During our discussion, we explored why agencies sometimes build insecure or vulnerable IaC, and the steps necessary to create a hardened IaC module. We discussed the organizational changes and technologies that can help agencies build secure infrastructure. Finally, we were introduced to KICS, a new tool from Checkmarx, that can scan IaC source code to ensure that it’s secure.
Here is what Ben told us:
GovDevSecOpsHub (GDSOH): At a recent panel discussion, Nick Sinai said that IaC is something that could, “…actually make life even worse for [agencies].” How and why can IaC create security vulnerabilities for developers and government agencies? How can the automation inherent in IaC make those vulnerabilities even worse or more pervasive?
Ben Stokes: Infrastructure is difficult. It is not easy now, and it has never been easy. However, Infrastructure-as-Code (IaC) can sometimes make it look easy. Perception is everything. Thinking that IaC is easy can lead to the misconception that IaC does not require maintenance, or care and feeding.
In performance engineering, we refer to a three-step process for building software: “Make it work, make it right, and make it fast.” In IaC, the process should be slightly different: “Make it work, make it right, and make it secure.”
Deploying IaC and an application quickly might seem impressive, however, it does not benefit an agency when applications are quickly deployed on insecure infrastructure. When a developer deploys a solution quickly, the assumption is they used some sort of module. But what is in that module? What is it doing? And what decisions did the module author make? Are those the right decisions for your organization? How is it determined if the decisions are correct? What are the repercussions if the threat model is different?
If a developer simply utilizes an off-the-shelf module, there is a high probability that they just created a new vulnerability. Chances are there is something in that module, and the IaC it provisioned, that is not correct for the agency. This is how vulnerabilities get built into IaC.
“INFRASTRUCTURE IS DIFFICULT. IT IS NOT EASY NOW, AND IT HAS NEVER BEEN EASY…THINKING THAT IAC IS EASY CAN LEAD TO THE MISCONCEPTION THAT IAC DOES NOT REQUIRE MAINTENANCE, OR CARE AND FEEDING.”
With the automation inherent in IaC, a single misconfiguration within the infrastructure can spread vulnerabilities quickly throughout the enterprise. Developers need to be careful to not create IaC that introduces vulnerabilities across the organization.
GDSOH: There’s another side of that coin, however. Some of the other panelists with Nick, including Carrie Lee of the Department of Veterans Affairs, talked about how IaC – if done securely – can be used to push secure infrastructure provisioning, standards, and controls across the organization. How is that possible and why would that be a positive thing?
Ben Stokes: To get those benefits, organizations need to work diligently and deliberately to build secure IaC. Organizations need to take the extra step to document the posture of the module they created to provision that IaC, documenting its intended environment, the standard it has been hardened to, and the tests conducted to ensure that it is hardened to that standard.
Agencies that are deliberate, and put in the extra work, will be rewarded with a hardened IaC asset. Whether a cloud formation template, or a Terraform module, a hardened IaC asset can deploy multiple instances of the desired infrastructure very quickly and securely.
That asset can pay dividends across the organization.
“WITH THE AUTOMATION INHERENT IN IAC, A SINGLE MISCONFIGURATION WITHIN THE INFRASTRUCTURE CAN SPREAD VULNERABILITIES QUICKLY THROUGHOUT THE ENTERPRISE.”
The agency will gain automatic parity between production and deployment environments because both are built to the same specifications. That parity is valuable because differences in those environments can cause issue reports from the software.
A hardened IaC asset will also help the agency with disaster recovery (DR) scenarios. Keeping an additional hot site is costly. Agencies that have put in the time and work to develop a hardened IaC module can use it to recover into another region easily and quickly. If an agency does not have a hot site, recovery will only take as long it takes for the IaC to get up and running at another location.
GDSOH: Ultimately, it sounds like IaC done well can make an organization more secure, and IaC done poorly can make it MUCH less secure. So, what cultural or procedural changes can organizations implement to ensure they are doing it correctly?
Ben Stokes: Because of the automation inherent in IaC, an agency’s IaC is going to be spread across the enterprise and amplified. If the infrastructure is built securely, the agency will have good infrastructure across the board.
I think culturally and procedurally, IaC is code and must be treated like code. It cannot be treated like infrastructure, which has a dedicated team that manages it.
Code is written by developers who have a very specialized skill set and little experience with infrastructure. That can create problems because domain knowledge is necessary to write IaC. Developers need domain knowledge of their platform – whether it is AWS, Azure, etc. They also need knowledge of traditional IT concepts around networking and network layout, so that when they design a software-defined network, it is correct and functional.
“AGENCIES THAT ARE DELIBERATE, AND PUT IN THE EXTRA WORK, WILL BE REWARDED WITH A HARDENED IAC ASSET…[THAT] CAN DEPLOY MULTIPLE INSTANCES OF THE DESIRED INFRASTRUCTURE VERY QUICKLY AND SECURELY.”
There is really no substitute for having expertise in the above areas. However, like any other type of code, they require testing and good tooling. Code reviews are also required. Unfortunately, the expertise needed is scarce, while time is limited. Good tooling is invaluable. KICS is such a tool, because it can conduct automated IaC code review at scale.
Organizational leaders need to understand that if they want infrastructure as code, they will need to invest in tools and empower and train their developers to use those tools. These actions will ensure a culture that creates tested artifacts that can then be reused.
GDSOH: What tools and technologies exist that can guarantee or ensure that IaC is secure before it leaves an entire organization vulnerable? How do these tools work?
Ben Stokes: A lot of IaC vulnerabilities materialize as security misconfigurations. Security misconfiguration has been an OWASP top 10 vulnerability since its inception.
These types of vulnerabilities are usually hard to detect. Configuration relies on context, and context is hard to integrate into testing.
Many of the tools that are used today – things like server scans built into cloud platforms – are scanning for settings and configurations that are incorrect. However, they have long feedback-loops. Developers must run the test on provisioned infrastructure, get a report, and then go remediate the problem. That process can take a long time, and it must be run on infrastructure that has been already provisioned and configured.
The Checkmarx Keep Infrastructure as Code Secure (KICS) solution delivers a shorter feedback loop for IaC testing.
KICS works by testing the source code, making it quick and easy, and allowing users to get started early in the process. Unlike the server scanning built into cloud platforms, users do not need their whole system up and running to do a scan. Users can start scanning their source code for vulnerabilities before they deploy the infrastructure.
GDSOH: The IaC security solution that Checkmarx has introduced is an open-source tool. Why is this something Checkmarx has committed to offering as an open-source solution at no charge to the user?
Ben Stokes: That is correct, KICS is available at no cost. Basically, Checkmarx is following an open-source model that is common across the industry – making the tool available at no cost, and having support and updates offered through the community.
Within Checkmarx, there are security researchers who are always hunting for new vulnerabilities and using their research to improve the detection capability within Checkmarx products. That is true for KICS, as well. However, there is also a great deal of expertise in security research that is not in-house at Checkmarx. Funneling that expertise into KICS is very valuable. Since KICS is on GitHub, anybody who wants to submit a query to KICS can do so.
That’s one of the benefits of open-source solutions. Being open-source, there is an established community already searching for new security issues and submitting new queries. That community acts like a high tide, which lifts all boats.
GDSOH: For anyone interested in getting access to KICS, what do they have to do? Where do they have to go?
Ben Stokes: It is easy! KICS is available online where interested individuals can access documentation and a download for the binary.
If you would like to see KICS in action, click HERE to download the solution at no cost.
This story was originally published on GovDevSecOpsHub on July 20, 2021.