DevSecOps: Risks and Best Practices
It is now more important than ever to understand cloud infrastructure configuration practices that are creating exposures. In the Summer 2020 edition of the State of DevSecOps report, we analyze top issues, glean lessons from past cloud breaches, and recommend DevSecOps practices that organizations should consider as they embrace cloud native infrastructure. In this blog, I’ll share some key observations and learnings.
New Types of Misconfigurations are Becoming Commonplace
Critical Breach Paths are Getting Buried in the Noise
While it is important to ensure that best practices are implemented across cloud native infrastructure during development, developers can quickly become inundated with alerts about policy violations. We performed threat modeling to determine which violations posed the highest risk and created potential breach paths in cloud deployments. Amongst the top culprits was overly permissive IAM policies that were being used by one or more highly sensitive resources in 89% of cloud deployments; a breach involving the IAM role would expose all of these resources. This issue was a key factor in the CenturyLink and Capital One breaches where millions of records were exposed.
Policy as Code should be implemented to ensure that best practices are employed in defining and managing cloud native infrastructure. However, Security as Code techniques that perform automated threat modeling are also necessary to identify the highest severity risks that create potential breach paths in cloud deployments.
Changes in Runtime are Leading to Risk Posture Drift
Earlier this year, Accurics’ researchers determined that 90% of organizations do allow users to make changes to cloud native infrastructure in runtime. That number remains largely unchanged today. The most common issue was changes to security groups which occurred in 100% of deployments. This implies that even if organizations exercise strong security hygiene when cloud native infrastructure is initially defined, changes in runtime will create exposures over time.
Organizations must invest in Drift as Code tools that detect resource and configuration changes from a secure baseline defined through IaC. Changes must be assessed for risk and reconciled with the baseline to establish the IaC as the single source of truth for risk posture.
Codifying Remediation Holds Tremendous Promise
Even though organizations are embracing tools to automatically detect risks, risk resolution remains a largely manual process. This results in alert fatigue and as a result only 6% of issues are remediated. A new practice known as Remediation as Code is emerging; once a risk is detected, the code to fix the issue is automatically generated and sent to the developer. The developer needs to simply review and accept the change. The results of this approach have been extremely encouraging: 80% of risks were addressed in the deployments that were assessed.
The key takeaway from the research is that the nature of cloud native infrastructure demands that security must be codified into development pipelines and enforced throughout the lifecycle. Policy checks and breach path detection should be codified across Infrastructure as Code (IaC) to identify risks before cloud infrastructure is provisioned. Remediation must be codified into the development pipelines in order to address the risks before cloud infrastructure is provisioned and establish a secure baseline.
Any new resources or configuration drifts in runtime from the baseline defined through IaC should be assessed for risk. For legitimate changes, the IaC baseline should be updated; changes that introduce risk should require the cloud infrastructure to be redeployed based on the baseline. This approach of codifying security across IaC and making it the single source of truth will enable organizations to achieve Immutable Security and prevent cloud infrastructure risk posture from drifting over time.
Read the Summer 2020 edition of the State of DevSecOps to take a deeper dive into the findings.