Published on August 25th, 2020 📆 | 5348 Views ⚑0
Infrastructure as code’s security risks and rewards
It’s intriguing to analyze how risk changes to reflect new technologies and processes. Security practitioners know most technologies do not affect risk solely in one direction. For example, they might introduce new risks, while helping mitigate old ones, or they might increase risk for some organizations, while decreasing it for others. It takes a skilled practitioner to understand this. The ability to optimize risk reduction, while simultaneously minimizing new risks, separates passable security professionals from the truly great ones.
Infrastructure as code, or IaC, is a relatively new approach that follows this pattern. With IaC, practitioners can harness possible risk reduction, while minimizing potential new risks. However, IaC poses a new source of risk to organizations when it is adopted in a slipshod fashion without appropriate attention paid to security. But, if security is top of mind, IaC represents perhaps the single greatest source of risk reduction for certain types of operational technology risk.
To start, it is important for security and IT professionals to understand what IaC is and then delve into IaC security implications.
Understanding infrastructure as code
In the past, organizations had physical data centers and infrastructure that took the form of physical hardware. Today, most infrastructure organizations deploy is not physical hardware, but OS deployments that take the form of virtualized OS instances, cloud workloads and containers.
Fielding a new OS image can be accomplished in two ways. First, there is the old-fashioned way, which involves individually installing and configuring each one. This can become a significant challenge — creating 1,000 or 50,000 manually would take months.
The second, more sound approach involves defining a configuration in advance that specifies exactly what is required and using a tool to do the heavy lifting of creating the VM, installing the OS and deploying it. For example, organizations can create a configuration file or script that lays out the configuration and then use the tool to provision and deploy what is specified in the script. This second approach is IaC in a nutshell.
Benefits of infrastructure as code
IaC is advantageous because the configuration is defined in a single file, thus it becomes much more like software. This enables the configuration file to be shared with others and to be updated as needed. It can be put under source control to keep track of versions.
Additionally, IaC enables organizations to minimize drift between workload configuration. It is understood that servers develop their own “personalities” as the underlying OS and applications are updated and as configuration is tweaked over time. IaC enables IT teams to rapidly build, rebuild and field new workloads in a consistent and timely manner. Finally, IaC works well with DevOps because of how easily it can plug in to automated deployment approaches.
IaC security concepts and impacts
After understanding what IaC is and its benefits, it is important to look at its security and risk effects and how infosec practitioners can evaluate the risk optimization tradeoffs for their organization.
It is important to explore IaC in broader terms because there is a wide variety of tools that support it. These include provisioning tools, such as Terraform; orchestration tools, such as AWS CloudFormation and Azure Resource Manager; and configuration management tools, such as Chef and Puppet. Automation tools, such as Ansible, and container-focused tools, such as Docker — which uses YAML to define running configuration — are also available. The unique technicalities of each of these tools that support IaC are complex.
Focusing on high-level IaC concepts leaves plenty to evaluate. Here are three major IaC security effects IT leaders should consider before implementing this approach at their organization.
1. Provides consistency in hardening
One of IaC’s most significant security advantages is the ability to ensure consistency across deployed workloads. Since it is used everywhere, defined configurations can be tailored to best achieve the security configuration goals outlined by the organization. Because it is automated, workloads are trusted to be hardened appropriately, and any hardening done will be in place everywhere it is needed.
This feature does introduce the potential new risk that a misconfiguration or error in the configuration ensures near-universal propagation of that issue. Just as there are bugs in software, it is possible to make mistakes in defining configurations. Similarly, just as some coding issues may introduce security problems, so can IaC configuration issues as well. To avoid this, security teams must ensure configurations are hardened and hardening steps are included in defined configurations.
Incorporating automated scanning tools can also help security practitioners understand where potential misconfigurations or other vulnerabilities are and update configuration definitions as quickly as possible in response.
2. Addresses human error with automation
Another IaC security advantage is a reduction of potential human error that is often to blame for misconfigurations and other security issues. Because the deployment is automated without human intervention, there is less opportunity for individual administrators to make configuration changes that introduce security issues.
The downside to automation, however, is its potential to exacerbate sprawl. As security professionals know, cloud sprawl can occur when workloads are fielded without a plan for eventual decommissioning. An automated approach to deployment means more surface for potential unused instances. To maximize secure outcomes from this, ensure the method of inventorying or tagging is strong and, if possible, automated as well.
3. Reduces need for privileged accounts
Another IaC security advantage is how it reduces the population of individuals requiring privileged credentials. Since deployment and configuration are automated, there is less opportunity and need for privileged account use because less human intervention is required to bring the resource online in the first place.
However, under some circumstances, automated elements can make it easier for secrets, such as API keys, privileged credential information or cryptographic keys, to find their way into production in unexpected ways. Security leaders should explicitly test for unexpected privileged accounts, as well as ensure the methods by which secrets are stored and deployed.
As with anything, determining IaC security implications will depend on how it is used to either bolster or undermine the organization’s security posture. The challenge for infosec practitioners is to maximize the upside, while minimizing the downside. Understanding the importance of this balance is the first step on the journey to using IaC as a tool in the security toolbox.