Understanding Infrastructure-as-Code Risks in the Cloud

Infrastructure as code (IaC) has gained rapid popularity for its ability to automate the management and provisioning of IT infrastructure by replacing manual processes with machine-readable configuration (definitions) files that contain specifications that are simple to edit, maintain, and distribute.

This approach is especially appealing and efficient when standing up and modifying infrastructure-as-a-service (IaaS) instances in cloud application environments.

But, like any technology, these gains aren’t without some pain. One of the most formidable tasks is dealing with IaC management and security. While it’s now incredibly fast and convenient to propagate changes across multiple production environments, errors and vulnerabilities can also spread like wildfire. This includes misconfigurations and incorrect default settings, all of which can potentially expose sensitive data, intellectual property (IP), and trade secrets.

As a result, it’s wise to establish a framework — including the right strategy and technology tools — that can identify misconfigurations, fix incorrect values, and automate the sometimes-daunting process of checking IaC.

Cracking the Code on IaC

One of the things that makes infrastructure-as-code so appealing is the ability to automate infrastructure deployment processes as part of the development life cycle. This practice is usually referred to as creating a CI/CD pipeline — continuous development and continuous deployment. Manually provisioning, configuring, and managing systems is a time-consuming and error-prone task. IaC is an essential component for automating these processes. With the click of a button, it’s possible to set up, delete, or make widespread changes to an existing environment across multiple cloud platforms using APIs

It’s also possible to gain visibility into all these changes. So, if it is necessary to roll back a system to a particular date or configuration, the task is reasonably easy to manage. Because IaC typically has built-in support for things like declarative and imperative language, filters, and rules and settings, it’s possible to create a standard deployable configuration file that tells a cloud provider exactly what resource to provision.

Eliminating manual processes doesn’t prevent problems. IaC environments remain vulnerable to configuration errors. In many cases, IaC definition files mitigate the risk of introducing security misconfigurations due to human errors such as applying the wrong user access policy or important security settings. However, when human-made mistakes happen, they will affect all resources that are using the same definition files and may impact thousands of resources.

In fact, it’s remarkably easy to miss configuration issues in IaC, especially when a large and complex cloud infrastructure is provisioned. And once the problem exists in the production environment it’s usually a lot more difficult and time-consuming to fix. As a result, organizations should implement a shift-left approach to IaC security that’s designed to fix issues directly when code is written or modified.

Finding the Fix

Addressing the problem involves scanning new IaC files for errors and fixing them before they are released to production, as well as discovering misconfigurations already deployed in cloud environments and modifying the IaC files. This requires following a clearly defined three-step process:

• Identify the misconfigurations. This “hygiene” starts with state and resource aware scanning of configuration files to identify errors or policy violations that need to be fixed. These processes should scan the cloud runtime environment and take into account the plan and state outcomes. Once problems have been identified, it’s critical to fix code for all files that touch the cloud environment. In some cases, thousands of configuration files might exist.
• Create a staging environment for testing. One of the big advantages of IaC is that you can quickly create many instances of your entire infrastructure, it’s simple to create a staging environment and a production environment. Once the review process is complete in the staging environment, transferring it to a live setting is a process that takes place at the push of a button.
• Inspect an IaC environment before provisioning to production so that it aligns with security policies. The inspection process should include a review that ensures that a policy is correctly translated into a control, and the control is correctly embedded in the configuration file. For example, an organization might check to see that any sensitive data isn’t stored in clear text or secrets are not exposed. It’s critical to conduct a thorough review so that a new setting or configuration doesn’t introduce a new issue.
• Add the correct values. The next step is to fix the actual problem. This may be something as straightforward as encrypting a database that was previously unencrypted or something as complicated as changing a specific setting in all the virtual machines or storage devices in a particular region or country. Once this analysis is complete, it’s possible to update configuration files or create new ones.
• Deploy the new or updated code. After you have made the necessary changes, it’s time to push out the new or updated configuration files. While IaC makes this task much easier, it’s important to ensure that the update is going to the right place and that it will be deployed as intended, as part of a managed CI/CD process.

While IaC provides huge advances for deploying and managing today’s highly complex cloud and IT environments, it does not address security issues and configuration errors that will inevitably occur. However, with the right processes, procedures, and tools it’s possible to automate the detection and remediation of security risk in even the largest IaC deployments.