When analyzing major cloud breaches, which happen so distressingly often, it’s easy to be drawn toward grand narratives of dastardly deeds committed by unscrupulous masterminds feverishly developing sinister plots. But even whilst all that happens, it’s also true that many dangers have humble origins—and these evolving cloud infrastructure misconfigurations can cause just as much damage. In fact, seemingly harmless changes and sophisticated intrusion strategies make for a potent mix.
Our Summer 2020 State of DevSecOps research report shines a spotlight on an often-neglected issue: cloud infrastructure misconfigurations, made intentionally or inadvertently. To be sure, more malicious efforts also factor in the mix—but to develop effective defenses, understanding common mistakes and associated risks is critical.
So what is it about cloud infrastructure configuration practices that create exposures like this?
First, let’s acknowledge that most organizations don’t take cloud security lightly—they build multi-layered defenses into cloud platforms, deploy a revolving mix of point solutions, and generally allocate significant resources to this issue. And yet we see an endless parade of horror stories, with breaches that severely hurt the brand and the bottom line. And on a regular basis, it’s getting worse
Great advances, hidden dangers
Here’s the foundation issue: The broad adoption of cloud native infrastructure has brought along numerous other advances—think serverless, containers, service mesh and more. These technologies surely give enterprises more power and sophistication to deliver enhanced innovation. However, they also involve multiple management interfaces, significantly increasing the risk of manual errors. Hybrid and multi-cloud deployments add to the complexity. And despite all those security policies and tools, privileged users still have the freedom to make changes to cloud infrastructure configurations in runtime. Each little change drives the code further from the intended compliance and security posture established during development; even seemingly legitimate shifts could introduce risks.
The new State of DevSecOps research drills down into these potential risks and identifies specific concerns that are largely overlooked.
First, the report finds that misconfigured cloud storage services are commonplace in 93 percent of cloud deployments analyzed, and the majority of deployments have at least one network exposure with a security group left exposed. Just for context, these two practices alone help account for at least 200 breaches and 30 billion record exposures in just the last two years.
Another mushrooming problem has to do with the fact that whilst corporations regularly deploy sophisticated tools to prevent intrusions, some fairly fundamental best practices are missed. For example, solutions such as HashiCorp Vault and AWS Key Management Service (KMS) are widely available and can be easily deployed to protect credentials. However, our research found hardcoded private keys in nearly three-quarters, 72 percent, of the deployments analyzed.
Specifically, there were unprotected credentials stored in container configuration files in half of all deployments. That’s a big problem by any definition— 84 percent of organizations now use containers. Nor are these keys limited to relatively mundane areas. The research shows that 41 percent of organizations have high privileges associated with the hardcoded keys. This suggests a breach involving these keys could potentially expose all associated resources. By no coincidence at all, hardcoded keys are verified to have contributed to numerous cloud breaches.
And then there’s the ultimate problems: Network exposures stemming from misconfigured routing rules. In every deployment analyzed, 100 percent, there were altered routing rules exposing private subnets with sensitive resources, such as databases, to the Internet -- this is the most dangerous weakness of all.
Harmless changes bring big risks
Previous reports in this series have uncovered the scale of the problems associated with allowing users to make changes to cloud native infrastructure in runtime—in fact, 90 percent of companies studied enabled this core weakness. Going a level deeper reveals the top risks: Security groups were created or modified in 100 percent of deployments; IAM policy changes were made in 82 percent of deployments; and resource deletion occurred in 23 percent of deployments (provisioned through Infrastructure as Code, or IaC, and then deleted without updating the code).
Securing the code
These problems are all serious, and potentially create exposures. However, they are also largely avoidable.
First, we confront the reality that even the most stringent security controls to detect exposures are only implemented in runtime; and only a tiny minority of the issues detected, perhaps 4 percent, are actually addressed.
The critical fix here is to embed policy guardrails throughout the development lifecycle. It begins with identifying and resolving risks during development and ensuring that cloud native infrastructure is provisioned securely from the start. The best way to achieve this goal is to embrace IaC to programmatically define the infrastructure and assess risk. In fact, IaC should become the single source of truth.
Risk assessment includes two distinct elements:
- Policy as Code: Detect best practice violations such as unencrypted data or SSH ports open to the Internet
- Security as Code: Perform threat modeling to identify potential breach paths and determine the blast radius of a breach
However, automated detection of risks paired with a manual approach to remediation can cause alert fatigue—that’s partly why so many issues don’t get addressed. Codifying remediation into development pipelines (that’s Remediation as Code) represents the only scalable approach to ensuring that detected risks are effectively addressed. This feature alone can make a huge difference, raising the number of risks addressed from the single digits to 80 percent.
Once a secure baseline has been established through IaC and infrastructure is provisioned, continuous monitoring for resource or configuration changes (that’s Drift as Code) is vital. If changes are legitimate, the original configuration scripts or IaC must be updated to reflect and maintain the change if the infrastructure is redeployed. If the change introduces risk, the change must be reverted.
In sum, at a time when cloud technologies are more prevalent—and during a global pandemic, more critical—than ever, the market at large clearly needs newer approaches to cloud security. The Accurics Summer 2020 State of DevSecOps report helps uncover numerous risks that don’t get the attention they deserve, and reveals the possible path forward.
Om Moolchandani, co-founder & CTO, Accurics