With the rise of cloud-native technologies such as Infrastructure as Code, microservices, and containers, the responsibility for security is rapidly shifting in the direction of engineering and DevOps teams. Because they have more control of broader infrastructure and the processes and systems used to provision and manage it, engineers are becoming even more accountable for infrastructure security. This trend should be a strong consideration, as good DevSecOps makes application deployments, operations, and service monitoring easier, and more secure. In particular, developers will be responsible for securing the Infrastructure as Code that they built, and DevOps engineers will be responsible for making it as seamless as possible.

Infrastructure as Code (IaC) has changed the way teams build and manage infrastructure, and it’s also changed the way they secure it. But for all its scalability, consistency, and manageability benefits, IaC comes with its own challenges. One of these challenges is making sure all deployed IaC is secure — without any disruption to release velocity.

IaC refers to the technology and processes used to manage and provision infrastructure with software instead of manual operations. Whether used to provision on-prem or cloud resources, IaC tools and processes allow engineers to consistently and reliably build, deploy, and manage infrastructure using code templates and automated build processes.

IaC frameworks can be imperative, which define the steps needed to reach a desired outcome, or declarative, which define the desired state of the final outcome and the automation platform ultimately takes the steps to achieve it. The most common IaC tools are Terraform from HashiCorp, AWS CloudFormation, and Azure Resource Manager. More than any other framework, Terraform, which is completely open source, has made IaC limitlessly customizable and multi-cloud, thus paving the way for the surrounding IaC ecosystem.

IaC allows infrastructure to be stored, version-controlled, and audited just like any other application code. Because of its transient nature, however, IaC requires extensive build processes to provision code into running resources. 

Figure 1: Infrastructure as Code across the development lifecycle

Because there can be a disconnect between running resources and the IaC templates that provisioned them, visibility is paramount. Ensuring that development teams have visibility across and within their codebase and delivery processes through to runtime ensures that immutability is maintained. That means that all changes to infrastructure are made at the source code via IaC templates rather than cloud consoles or scripts manipulating deployed resources. 

Terraform uses HCL, a domain-specific language by HashiCorp, to define infrastructure with code, which you can check into version control or store in S3 buckets.

For instance, the following template defines a single EC2 instance as:

module "ec2_instance" {
  source  = "terraform-aws-modules/ec2-instance/aws"
  version = "~> 3.0"

  name = "single-instance"

  ami                    = "ami-ebd02392"
  instance_type          = "t2.micro"
  key_name               = "user1"
  monitoring             = true
  vpc_security_group_ids = ["sg-12345678"]
  subnet_id              = "subnet-eddcdzz4"

  tags = {
    Terraform   = "true"
    Environment = "dev"
  }
}

This EC2 instance can be provisioned on AWS using the Terraform CLI. 

Challenges of IaC

As with any emerging technology, IaC comes with its own set of drawbacks, mostly related to the lack of cohesive awareness and added complexity. There is undoubtedly a learning curve to adopting IaC, which is at odds with manual infrastructure provisioning by design. Replacing established processes and technologies can be disruptive.

Because it can run in parallel to manual cloud orchestration, implementing IaC without full visibility and collaboration can lead to confusion as to how and where resources are provisioned and managed. When fully embraced, its immutable nature means that instead of troubleshooting and fixing deployed running resources, you simply update the IaC template re-provision them.

When manual changes are made to IaC-provisioned resources, you lose immutability and introduce the risk of damaged services or unexpected behaviors. Further, if the manual change was a misconfiguration remediation, that fix will be overwritten the next time the IaC is provisioned, leaving security with repetitive work. As is the case when adding any new technology to already complex infrastructure stacks, IaC can also introduce security risks.

Key security risks that IaC introduces are:

• Infrastructure has grown across a hybrid-cloud environment with deployments in both on-premise and multi-cloud environments. The ability to efficiently manage security across these complex deployments while keeping operations costs in check is essential.
• Fewer resources are available to manage the environment as many organizations face cost pressures. This issue causes major setbacks: As the infrastructure grows, the resources to manage it shrink or stay the same.
• An evolving threat landscape challenges organizations because it is both relentless and seemingly one step ahead. Company data and intellectual property are more vulnerable than ever with more complex and layered cloud-native stacks.

Infrastructure as Code presents an incredible opportunity to embed consistent and scalable cloud security coverage. IaC security refers to addressing cloud configuration issues in IaC rather than deployed cloud resources. Because IaC does not represent infrastructure itself, IaC security is a means to an end. It ensures that IaC is configured in such a way that it will provision secure resources. IaC security is a proactive approach to cloud security which, historically, has addressed configured cloud resources in runtime. If IaC is in use, this reactive approach introduces risk and redundancy where cloud security issues are concerned.

Cloud security issues, commonly referred to as misconfigurations, are often related to securing access to critical services and customer data. Each cloud and resource type has its own set of security best practices, commonly referred to as policies, and corresponding compliance benchmarks, and IaC is a programmatic way to identify violations against those policies. Organizations may also enforce their own policies unique to their infrastructure and business requirements.

How IaC Security Works

Much like static analysis of application code, the most basic form of IaC security is being able to scan IaC to identify misconfigurations. Scanning IaC involves checking templates, files, modules, and their variables against known policies. Policy violations occur when proper settings are either missing variables or the values are incorrectly set.

Because each cloud and resource type has its own security standards, there are hundreds — and sometimes thousands — of policies that may be relevant to your stack. Relying on developers to keep track of those policies is impossible, which is why automation is the best way to gain total coverage across cloud environments. By automating IaC scans, organizations save time and provide coverage not possible through manual work alone. There are a few open-source tools such as Open Policy Agent (OPA) and Bridgecrew’s Checkov that enable anyone to scan IaC files or directories against known policies.

Here's an example of leveraging Checkov to scan Terraform against a few policies. Once you’ve scanned your file or folder, you’ll see output such as this:

       _               _              
   ___| |__   ___  ___| | _______   __
  / __| '_ \ / _ \/ __| |/ / _ \ \ / /
 | (__| | | |  __/ (__|   < (_) \ V / 
  \___|_| |_|\___|\___|_|\_\___/ \_/  
                                      
By bridgecrew.io 

terraform scan results:

Passed checks: 2, Failed checks: 1, Skipped checks: 0

Check: CKV_AWS_19: "Ensure all data stored in the S3 bucket is securely encrypted at rest"
	PASSED for resource: aws_s3_bucket.foo-bucket
	File: /example.tf:1-25
Check: CKV_AWS_20: "S3 Bucket has an ACL defined which allows public READ access."
	PASSED for resource: aws_s3_bucket.foo-bucket
	File: /example.tf:1-25
Check: CKV_AWS_20: "S3 Bucket has an ACL defined which allows public READ access."
	FAILED for resource: aws_s3_bucket.foo-bucket
	File: /example.tf:1-25

             1 | resource "aws_s3_bucket" "foo-bucket" {
             2 | region = var.region
             3 | bucket = local.bucket_name
             4 | force_destroy = true
             5 |
             6 | tags = {
             7 | Name = "foo-${data.aws_caller_identity.current.account_id}"
             8 | }
             9 | versioning {
             10 | enabled = true
             11 | }
             12 | logging {
             13 | target_bucket = "${aws_s3_bucket.log_bucket.id}"
             14 | target_prefix = "log/"
             15 | }
             16 | server_side_encryption_configuration {
             17 | rule {
             18 | apply_server_side_encryption_by_default {
             19 | kms_master_key_id = "${aws_kms_key.mykey.arn}"
             20 | sse_algorithm = "aws:kms"
             21 | }
             22 | }
             23 | }
             24 | acl = "public-read"
             25 | } 

IaC security is incredibly valuable in that it puts the same flexibility and repeatability that IaC uses to provision resources into securing it. Code is inherently extendable — and applying the same methodology into cloud security is the best way to secure it consistently.

How you scan your IaC matters almost as much as when you scan it. On the one hand, the earlier misconfigurations are identified — for instance, in a developer’s IDE or via a pre-commit hook — the faster and cheaper it is to fix. Relying on individual contributors is a great way to exchange quick feedback, but a more collaborative approach is needed for comprehensive coverage. A common approach to getting collaborative and consistent IaC security feedback is to integrate it into a version control system (VCS) such as GitHub or GitLab. This way, when code is committed or pull/merge requests are created, scans are automatically kicked off and misconfigurations are surfaced right then and there. Giving timely feedback to developers — regardless of the stage or tool — is key to embracing IaC security.

Additionally, because IaC is more abstracted the further away it is from its runtime state, adding periodic checkpoints in the development lifecycle is best practice. Whether you’re surfacing IaC security feedback to your pull-request checks or a failing step in your CI/CD pipeline, IaC works best when it’s automated as part of everyday code reviews.

IaC is unique in that it creates a level of abstraction on top of reality — how cloud resources operate and are configured once they are released and running. That’s why any IaC security and monitoring strategy should be accompanied by runtime protection. To be alerted if and when changes are made to resources outside of the IaC template, creating cloud configuration drift, you have to have traceability between the code and cloud resources. This can be done by tagging resources in code with unique values using tools, such as open-source Yor, that get persisted to runtime. Trace tags — along with runtime monitoring — give you complete coverage and the ability to detect drift.

Figure 2: Infrastructure coverage from commit to post-release

Finding the right tooling to automate the identification of IaC issues is imperative and enforcing security policies continuously is just as important. The easiest way to make IaC security feedback actionable is to deliver fixes in a common language — code. Implementing IaC security not only equips developers with real solutions to their problems but helps set policies to govern infrastructure in the future. 

Why Is IaC Security Important?

As IaC adoption soars and infrastructure innovation speeds up, it’s becoming more important to understand the security risks and complexities involved with IaC. Because infrastructure best practices are constantly evolving, a set-it-and-forget-it approach won’t work. Obtaining updated and modern coverage is the best approach when it comes to IaC security.

IaC is designed to make cloud provisioning simpler, faster, and predictable. But in order for teams to recognize those benefits, the same philosophy must be applied to how they approach cloud security. IaC security is the answer to cloud security in IaC-forward environments. It is the only way to get consistent, scalable, and immutable security.

If security is not applied at the IaC layer, misconfigurations are inevitable. And when clouds are orchestrated by inherently misconfigured code, they’ll continue to be orchestrated and configured incorrectly in production. This causes a deluge of errors that security teams have to triage, prioritize, and assign to the right engineering teams. By the time misconfigurations make their way back to the teams responsible, they have likely already moved on from that code. This context switching takes much more time than if the issue was addressed at its inception.

The gap between security and engineering teams is also a breeding ground for risk. Between the time a misconfiguration is released, identified by traditional cloud security posture management (CSPM) tools, and fixed, a bad actor may have gained privileged access to proprietary code or sensitive data.

Enabling developers to address security issues across the development lifecycle increases consistency and allows you to take a more holistic approach to security. Security automation also reduces the risk of human errors, improving accuracy and reducing the risk and cost of breaches, if secured properly.

Adopt and Expand IaC Security Across Your Stack

Implementing IaC security does not happen instantly, and it is not an all-or-nothing task. Security automation is a journey. Each organization will start — and stop — at different points according to their needs and existing processes. Those needs will dictate the path that each organization takes. No matter where you are in your journey, even small security automation efforts can deliver a wide range of benefits. Determining your organization’s current stage will help you adopt the right tools and processes at the right time to make your automation journey more successful.

Whether your organization is just building a new cloud environment, already operating in the cloud with one or more cloud providers, or scaling your environment to meet increasing demand, you can take advantage of a two-phased approach to automate your cloud security processes using IaC. 

• Phase 1: Surface Feedback Early – Start by leveraging DevOps tools and processes built for automated testing and checkpoints such as your version control system (VCS). Be sure that IaC security feedback does not interfere with any work initially but is simply informational. At this point, it’s also a good idea to start encouraging individual developers to leverage IDE plugins and pre-commit hooks when working on IaC locally. This way, developers will get accustomed to the types of errors that will be flagged and you can fine-tune findings based on your organization’s unique goals and compliance needs. 
• Phase 2: Optimize Operations – Once you’ve started to surface IaC security findings early when feedback cycles are cheap, you’re ready to start operationalizing. Next, begin to incorporate IaC security feedback into Continuous Integration/Continuous Delivery (CI/CD) pipelines and start adding failing steps. Be sure to do this gradually and transparently so that when builds fail because of misconfigurations, everyone knows why and has the tools and context to address them. This should be a constant cycle of iteration and expansion to different apps and teams. 

Eliminating Alert Fatigue

Anyone who's been in the DevOps space is probably familiar with security alert fatigue. At the beginning of a DevOps transformation, engineers set up as many monitors as they can to catch issues before they happen or to understand when things start to go awry.

The next thing that happens is that their inbox gets flooded with these alerts, and suddenly, everything becomes less meaningful — no one is reacting to anything, which is essentially the same as not having any monitoring in the first place. Security alerting is similar. Security Operations Centers (SOCs) set up as many monitoring tools as possible to fulfill compliance requirements due to fear of falling victim to the next headline-making breach. But because many security monitoring tools are noisy and security teams are incredibly under-resourced, it’s easy for risks to go undetected or unaddressed. In both instances, finding the balance between making sure everything is captured and not overloading those responding to these issues is a challenge.

One way to quantify alert fatigue is to look at the number of alerts per person, and the frequency and timing of the alerts. Every time there's an alert, there are three possible outcomes: It's an actual problem that must get fixed, it's a false positive, or it's something that needs further investigation to determine if action is needed. In the latter two cases, the threshold is adjusted or the engineer receiving the alert decides that it's really doing nothing for the process and turns the alert off.

Surfacing IaC feedback is a process of continuously balancing the bandwidth of your team and the level risk you are willing to accept with striving for the strongest security posture as possible. That’s why it’s important to take the two-phased approach as outlined above. Start with addressing new misconfigurations and aim to reduce that number over time. Once developers have learned and implemented security best practices and new misconfigurations are under control, you’re ready to tackle the backlog of issues based on priority.

Context-Aware Visibility

As cloud-native technologies get even more complex, it’s important to make sure that your IaC strategy is connected to other security initiatives.

Cloud Security Posture Management and Cloud Workload Protection

As covered earlier, it’s important to maintain visibility into IaC templates and the resources they provision. The same goes for security. Throughout the build process, resources and workloads are deployed; they become more complex and connected. Thus, it’s important to have visibility into resources and workloads constantly in runtime.

Additionally, because IaC security is only looking at the code templates without regard to their running counterparts, you have no way to know if changes are made out of band without runtime visibility. This issue, known as drift, isn’t inherently a security issue but can cause problems the next time IaC is provisioned, undoing secure configurations and reintroducing misconfigurations.

Software Composition Analysis, SAST, and DAST

Infrastructure and applications are becoming more and more linked within cloud-native applications. Infrastructure is the foundation for which application code exists, so it’s important to start connecting the dots between the two from a security standpoint.

Being able to correlate misconfigurations and known vulnerabilities is crucial for strong threat modeling and will help developers and security teams prioritize issues based on real-world exploitability. Although a bit more mature, having visibility between signals generated from IaC security tools as well as SCA, SAST, and DAST tools will help cover all security gaps and streamline security and compliance operations.

People, Processes, and Platform

Organizations that automate extensively are better able to prevent security incidents and business disruptions. But implementing a successful IaC security automation strategy requires more than just tools — you also need to consider your people, processes, and platform. People are at the core of any business initiative. Participation within and across teams lets staff share ideas and collaborate more effectively.

The key to frictionless IaC security is collaboration and clear, documented processes. A well-designed and fully adopted process makes running and managing automated IaC security seamless.

Lastly, you may want to consider adopting a platform to support your IaC security strategy. Open-source tooling will provide you the insights for identifying misconfigurations, but there are many benefits to adopting a platform that supports IaC security. In contrast to having disparate open-source tools, a platform can serve as an integration layer between security teams, tools, and processes. A flexible, interoperable platform lets you:

• Integrate security into your existing DevOps systems, tools, and pipelines.
• Collect information from systems and direct it to predefined systems and locations quickly without manual intervention.
• Change and propagate configurations quickly from centralized interfaces. 
• Adopt a centralized repository to easily create, maintain, and access custom policies related to your Infrastructure as Code.
• Trigger automated fixes when misconfigurations are identified. Using a consistent automation platform and language across your organization can also improve communication and collaboration. 

When every solution in a security portfolio is run through the same platform, developers, operators, and security teams are on the same page, maximizing the overall efficiency for everyone.

Multi-cloud is the new reality for many organizations, whether chosen as a strategy or forced on them through another means, like customer preference, mergers and acquisitions, or government regulations. Forward-looking organizations have accepted that this reality will happen — or has already happened — to their organization. They’re making plans to intelligently manage multiple clouds and proactively put measures in place to ensure continued compliance. Luckily, many IaC frameworks are cloud agnostic.

Some of the risks they need to manage are technical like differences in authentication, for example, and authorization solutions, or how network routing and security are configured. Other risks are on the people side of the organization. A common risk, caused by excessive processes and procedures, can lead to fast-moving parts of the organization going a little rogue and becoming an IT headache.

Automation Is the New Baseline

Starting with a multi-cloud friendly IaC tool will save an immeasurable amount of time. Since automation is repeatable, there is less time cross-training new team members — whether it is a role as a security admin or a DevOps engineer. Terraform is the leading multi-cloud IaC framework.

Flexible Policies and Procedures

Use an automation framework to handle most of the implementation. This lets you have policies and procedures that are a little more flexible and allows for the differences between cloud implementations. You’re able to focus on the goal rather than the exact procedure.

Standardize Components as Much as Possible

Even though multiple clouds are in use, it is possible to minimize the number of technologies that are in play. This is done through standardization of as many of the core technologies as possible. Often this involves using third-party components. Whenever possible, stick to solutions that support multiple clouds. This may mean giving up a nice-to-have feature in the case of a very specific point solution. The consistency and efficiencies that are gained more than outweigh the benefits of any one nice-to-have feature.

Multi-Cloud Management for Compliance and Cost Tracking

In multi-cloud environments, it is paramount that insight into costs and security compliance are available on-demand to those that require the information. There is a category of tools that can perform one or both of these activities. They work closely with the largest hyperscale cloud providers to ensure the solutions are up to date. They include the latest security policy enhancements to ensure that when a policy is applied and validated it is as consistent as possible across all clouds in the mix.

Automating Repetitive Tasks

By automating repetitive tasks, such as firewall deployments and security policy updates, you can free up your security staff to work more effectively, improve security, and keep pace with deployments across one or more cloud environments. Companies turning to security automation are finding it: 

• Reduces manual effort and human error. 
• Scales security efforts to match cloud deployment needs. 
• Enforces consistent security controls across multi-cloud environments.
• Accelerates incident response and investigations.  
• Improves compliance with regulations. 

Generally speaking, the key IaC security takeaways are:

1. Automation and workflow – Integrate IaC security via IDEs, CLI, VCS, and/or CI/CD based on different team's needs and preferences.
2. Depth and breadth of policies – Cover all the frameworks you need, all security best practices, compliance benchmarks, etc.
3. Prioritization and remediation – Visibility is only valuable if you can take steps to implement the feedback efficiently.
4. The broader impact and context of IaC – Understand how it relates to the runtime cloud resources.

Find an IaC security platform that includes tools and capabilities to help you proactively secure cloud resources and minimize runtime alerts. Use a two-phased automation approach to minimize disruptions and expand coverage iteratively. Make sure all team members have the access and context they need to address IaC security issues themselves. Ultimately, the goal should be to streamline infrastructure security so that risk is minimized and release velocity is maintained.