Shifting Cloud Security Left With Infrastructure as Code

Unfortunately, to date, security and compliance practices have been mainly reactive, as teams scramble to catch cloud infrastructure misconfigurations, risks, and compliance violations after provisioning or creation (i.e., “at runtime”).

Relying on runtime detection increases security and compliance risks significantly. It also drives down productivity, as developers have to spend their time addressing issues in the wrong place and the wrong time (more on this later). This reliance on runtime security also creates friction between developers and security professionals, making it more likely that developers will try to circumvent security altogether

Shifting cloud security left changes this dynamic completely, improving developer productivity and stopping security and compliance risks before runtime. Organizations can make this shift by integrating cloud security into the CI/CD process, and evaluating Infrastructure as Code (IaC) templates before a build for the same security and compliance issues that the organization now evaluates at runtime.

This shift left allows cloud security to scale and enables developers to be more productive (and really helps stop making security a four-letter word to developers). With this shift, security teams are presenting security risks in the right place and at the right time, while guiding how to resolve the specific risks through IaC templates. Developers are empowered to participate because decision-making on how to fix the problem is now at the level that has the most context. Empowering developers means they are more likely to participate, and this becomes a virtuous cycle through which even better cloud security is achieved and achieved at scale.

Cloud Security Risks in DevOps

DevOps is central to the cloud security life cycle because, in the self-service and automated world of cloud services, what developers do ultimately determines the success or failure of cloud security and compliance. Many organizations have been dealing with this fact by shifting security and compliance of application code left and into their CI/CD pipeline (e.g., using automated security tests, strict versioning control, and automated vulnerability scanners). This shift helps to address application code vulnerabilities, but what about the security and compliance of the underlying cloud infrastructure? There are four primary DevOps challenges to cloud security and compliance.

• Catching misconfigurations and risks too late. Most organizations are detecting risks and misconfigurations in the cloud at runtime instead of preventing them during the build process. This process is inefficient and ineffective and puts the organization at immediate risk.
• Developer productivity loss. Asking developers to resolve issues at runtime is the wrong time and place, and this creates a lot of inefficiencies. Additionally, runtime security issues are often ephemeral because they are actually generated by the IaC templates that contain the root issue, leading developers to burn cycles as they repeatedly address the same core fault.
• Developer and security misalignment. The productivity loss mentioned above creates friction between developers and security, ultimately leading to a loss of faith in security. This misalignment creates the possibility that developers will not participate fully in the security process, or will circumvent security completely.
• Dynamic environments. Every time developers create or provision new cloud services, these services most likely join existing environments. In isolation, the newly created resources may be secure and compliant, but in the context of the broader environment, there may be security and compliance challenges. The constantly changing world of cloud makes this a particularly tricky problem to solve. For example, a new Amazon EC2 instance connecting directly to a database server in the cardholder data environment (CDE) automatically becomes part of the CDE and thus is subject to PCI-DSS.

Security and Compliance Are Disconnected

These cloud security challenges exist because security and compliance are often on the outside looking in on the cloud infrastructure provisioning process. A release might have a simple misconfiguration (e.g., an open SSH or RDP port) that could lead to exposure of protected health or personal information, violating HIPAA or PCI-DSS compliance requirements. Catching these risks after provisioning (i.e., at runtime) puts the organization at considerable risk. The exposure continues while security and compliance isolate the problem, figure out who in Dev or Ops is responsible for remediation, engage the right person, and then ask that person to figure out how and where to perform the remediation. 

To address these DevOps challenges, organizations must take the same approach for cloud infrastructure provisioning as they have for application code provisioning by shifting security and compliance left. The enabler for this shift is IaC.

The Drive to IaC

The premise behind IaC is simple: write declarative statements that define the infrastructure necessary to run the code. So, rather than writing a ticket for operations to deploy compute, network, and storage, developers can write a JSON or YAML template that makes the creation of the infrastructure a shared, programmatic, and reproducible process. With IaC, developers can write programming code, test this code, and release it with the infrastructure that will run in a highly integrated process that the organization can automate as part of the CI/CD pipeline.

Developers use a wide array of IaC tools, including HashiCorp Terraform, AWS CloudFormation, Microsoft Azure Resource Manager, and Google Cloud Deployment Manager. These tools are quite powerful in that they give the ability to declare not just the storage, network, and compute assets but also additional services, including load balancers, monitoring, and security controls. 

IaC is the impetus for organizations to move cloud security and compliance from being reactive (at runtime) to being preventative (during development). The key is integrating the right controls with the proper guidance directly into the CI/CD pipeline. This integration facilitates delivering secure and compliant cloud infrastructure from the start. A rudimentary way of doing this is for security teams to create IaC templates for developers to use. Templates are a great first step, but addressing cloud security challenges requires a more integrated and dynamic approach.

Implementing Secure and Compliant IaC 

The essence of shifting cloud security and compliance left is integrating IaC feedback and guidance directly into the CI/CD tools (e.g., CircleCI, GitHub, Jenkins). For example, developers should be able to determine if the IaC template they are using will create security or compliance risks before building any infrastructure. Also, they must receive guidance on how to resolve these risks because developers are typically not security experts. Ideally, this guidance should be delivered to the developer immediately through the tools they choose to use. Developer tool integration is vitally essential because asking developers to change behavior reduces productivity and participation. 

Developers already have such an ecosystem in place for application security testing using static and dynamic application security testing (SAST/DAST) tools that integrate with their IDEs and CI/CD pipelines through APIs and webhooks. SAST is typically the first test point. It’s quick, though it only tests code at the component level. DAST is more accurate at catching real-world vulnerabilities because it examines the complete application, but it is slow and typically runs much later in the CI/CD process. Together, SAST and DAST catch many misconfigurations, vulnerabilities, and compliance faults before application code goes to production. 

Like SAST and DAST for application code, there are similar approaches to shifting cloud security left with IaC analysis:

• Static IaC analysis. Analyzes code in isolation, identifying risks, misconfigurations, and compliance faults only relevant to the IaC template itself. 
• Dynamic IaC analysis. Extends beyond the IaC template itself, evaluating any existing cloud environments and services that it will interoperate with or run on. For example, the dynamic analysis would detect that a properly configured server (that passed static analysis) still violates PCI-DSS requirements because the server is going into a CDE without a proper firewall. 

Integrating both static and dynamic analysis of IaC templates into CI/CD provides a holistic view of risk. However, delivering this new experience to developers requires the right security control plane to put guardrails separating what developers can and cannot do. What’s needed is tooling that accomplishes the following:

• Integrates into the CI/CD pipeline
• Supports multi-cloud infrastructures
• Provides both static and dynamic analysis
• Enforces the same policies during build and runtime
• Provides customizable enforcement levels (e.g., pass, warn, or fail) for these policies
• Delivers direct guidance to developers on how to resolve risks and faults

Bringing DevOps, Security, and Compliance Together

Implementing secure and compliant IaC is a cornerstone to aligning DevOps, security, and compliance to achieve the following benefits:

• Prevent cloud security risk. With direct CI/CD integration of IaC and the correct IaC tooling, the organization can now prevent misconfigurations, noncompliance, and security risks before runtime. This leftward cloud security shift helps to eliminate the opportunity for exploit. 
• Improve developer productivity. Implementing cloud security throughout CI/CD improves developers’ experience by surfacing these issues at the right time and in the right pipeline step. This integration radically enhances developer productivity by ensuring they can solve challenges efficiently and do so on a one-time basis, instead of running around in circles at runtime with ephemeral issues. Plus, integrated security guidance gives developers the recommendations they need to resolve problems quickly. 
• Strengthen security and compliance. Increasing developer productivity, involving the right teams at the right time, and ultimately delivering a better experience for everyone create a sense of ownership and shared responsibility. Developers become more likely to participate in the cloud security process. This virtuous cycle benefits everyone, from the developer to the security professional, to the organization at large. 

The First Step Left to Cloud Security 

Shifting your organization’s cloud security left starts with considering fundamental questions about your requirements, which can help you identify the right tool to use. 

What public clouds do you use? What public clouds might you use in the future?

Using multiple clouds requires complete and ongoing visibility of numerous cloud infrastructures to assess the impact of provisioning any service anywhere. Tooling that supports only your current cloud environment will raise all of the challenges discussed earlier as soon as you expand to another cloud. You should future-proof your approach to cloud security. 

How many IaC tools does your organization use (e.g., Terraform, CFT, ARM)? 

Using multiple IaC tools increases the drain on developer resources and complicates security and compliance jobs dramatically. Developers continually focus on limiting their toolsets to achieve maximum flexibility. Similarly, your organization should minimize the IaC tool suite.

What CI/CD orchestration tools does your organization use? 

Developers drive these tool decisions, so IaC security and compliance tools must work with any of them. Implementing IaC analysis with limited CI/CD pipeline tool support can hamstring an organization should developers adopt new CI/CD tools.

Do you need to apply the same policies preventively during the CI/CD pipeline and reactively at runtime?

Security and compliance actions must be enforceable throughout the CI/CD pipeline: preventive during the build phase and reactive during runtime. Organizations are at different stages of infrastructure provisioning maturity. Some are automating only a subset of infrastructure through the CI/CD pipeline, others are running CI/CDs with manual action, and still others are fully automating infrastructure provisioning. Regardless of maturity level, the organization’s security and compliance teams must be able to use the same policy definitions and enforcement mechanisms at any point, throughout the pipeline.

Do you need to apply scope so that policies refer to specific applications or logical groups?

Policy enforcement must be specific to the application and operating environment context. The same application running in a private cloud and a public cloud will require different levels of policy enforcement. Similarly, applications running in different public clouds may require unique policy enforcement (e.g., running an application with sensitive health data in a HIPAA-compliant cloud versus a general-purpose cloud).

Do you need customizable enforcement levels (e.g., pass, warn, or fail) per policy and policy scope?

Organizations are at different stages of policy enforcement automation. Some only want warnings, while others require automated action.

Finally, there are questions to ask as you evaluate tools that shift cloud security left:

• Does the tool support all the requirements you listed above? 
• Does it provide static and dynamic analysis for holistic protection?
• Does it provide preventive and runtime protection for full life cycle security and compliance?

Conclusion

Shifting cloud security left improves developer productivity and prevents misconfigurations and policy violations. A full lifecycle approach to cloud security (e.g., combining preventive and reactive) is a requirement for all organizations seeking to use cloud services to achieve innovation without the loss of control. To learn how your organization can shift left and implement full lifecycle cloud security, watch the demo for our cloud-native security platform InsightCloudSec.