DevSecOps: Risks and Best Practices
The recent breach attempt on Twilio was an indicator that attackers are crafting new ways to attack the cloud. While a misconfigured cloud storage service (S3 bucket) was involved, this incident was not about stealing sensitive data. Instead, attackers gained access to the javascript code for their TaskRouter SDK that allows Twilio customers to integrate incoming phone call routing. Since the cloud storage service was publicly writable, attackers modified the code. Although the change was non-malicious, the severity of the risk was a stark indicator that breaches are increasing in sophistication.
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
The research revealed that misconfigured cloud storage services are commonplace in 93% of the cloud deployments analyzed, and most also had at least one network exposure where a security group was left wide open. These issues have already contributed to more than 200 breaches over the past two years. However, new policy violations are starting to become commonplace such as storing hardcoded keys within environments – 72% of deployments had this issue; this was a key factor in the Imperva breach in 2019.
The notion of policy guardrails to enforce security best practices such as encrypting databases, rotating access keys, and implementing multi-factor authentication has existed for a while now. However, implementing these guardrails in runtime isn’t very effective. The adoption of Infrastructure as Code (IaC) enables organizations to codify policy checks earlier in the development lifecycle – a practice known as Policy as Code – to reduce risks from cloud infrastructure misconfigurations before it is provisioned.
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.
Key Takeaways
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.
