DevOps and the continuous integration/continuous deployment (CI/CD) pipeline are revolutionizing application development, test, and cloud delivery, enabling developers to write the application code and define the cloud infrastructure. But where is cloud security?
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.
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.
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 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.
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:
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:
Implementing secure and compliant IaC is a cornerstone to aligning DevOps, security, and compliance to achieve the following benefits:
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.
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.
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.
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.
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.
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).
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:
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.