If your cloud environment were compromised right now, would you know?
For many organizations, the answer, unfortunately, is no. Cloud-native attacks are on the rise, and prominent examples like the breaches at CapitalOne, Uber, CircleCI, and Ubiquiti have recently captured the attention of the security community. Detecting and responding to cyber threats is the job of the security operations team. But what is it about cloud security operations that’s so uniquely challenging?
Instead of users and machines, SecOps teams have to keep track of hundreds of services: IAM roles, managed databases, object stores, serverless functions, and more. All these entities constantly scale up and down, interact in complex ways, and generate massive amounts of telemetry.
But cloud security tools today have a CSPM heritage, and this focus on static scanning leaves critical gaps in real-time threat coverage. SecOps tools, like SIEM and SOAR, are intentionally general-purpose, requiring SecOps teams to spend weeks, months, or even years to build out custom use cases for every cloud threat.
What is Cloud Detection and Response (CDR)?
Cloud Detection and Response is a new category of security tools that are designed to help security operations teams detect and stop cloud attackers. In a sentence, CDR tools combine log analytics with data from cloud service provider APIs and third-party integrations to provide real-time visibility, threat detection, and response functionality in the cloud environment.
What Are the Key Capabilities of CDR Tools?
Cloud detection and response tools have four key capabilities:
Breach Readiness: proper detection and response starts before an incident occurs. CDR tools provide continuous telemetry monitoring to ensure that organizations have the visibility they need to detect threats when they inevitably occur
Comprehensive Detection: cloud threat detection shouldn’t be a multi-year project to write custom rules in a SIEM. CDR tools provide out-of-the-box coverage for cloud threats across the identity, data, network, and compute planes.
Efficient Alert Triage and Response: CDR tools fuse context from cloud telemetry, cloud-native APIs, and third-party integrations like CI/CD systems, ticketing systems, identity providers, and more to enrich alerts and automate investigation. Instead of running query after query in a SIEM, analysts have all the data they need at their fingertips to quickly get to the bottom of an emerging threat.
Cloud-Native Containment: CDR enables analysts to take action directly from the platform, providing recommendations and automation to enable threat containment and remediation. CDR tools can contain the emerging threat, preventing it from turning into a major incident and allowing for subsequent remediation through a SOAR.
Example Use Case: Insider Threat leads to Data Exfiltration
An insider threat scenario is one of the most common, and one of the most potentially devastating, cyber attacks. In an insider attack, an actor with valid credentials, typically a disgruntled employee or vendor, misuses their access to harm the organization.
Effectively countering an insider attack in the cloud requires a deep understanding of cloud identity. To detect when an insider is acting maliciously, organizations need to understand the historical behavior patterns of that insider identity: what cloud services do they usually interact with? What times of day are they most active? What accounts are they typically using? This information is very difficult to surface automatically. But CDR is purpose-built for this use case.
The recent sentencing of a Ubiquiti engineer in that company’s highly-publicized 2021 data breach presents an interesting case study. In that breach, a Ubiquiti employee used his internal credentials to exfiltrate sensitive company intellectual property, then tried to extort the company for almost $2 million. The resulting fallout erased over $4 billion from Ubiquiti’s market value.
What Happened?
The sentencing memo details how the insider carried out the attack and exfiltrated data. Using his own valid credentials, the engineer accessed a highly-privileged AWS access key and conducted reconnaissance of the company’s confidential GitHub repositories. He then masked his identity with an anonymizing VPN and used the access key to exfiltrate sensitive source code.
What happened next was even more interesting: the insider covered his tracks. For example, he modified retention policies to ensure critical logs were deleted. He even modified forensic artifacts, manually renaming AWS sessions to shift blame to other Ubiquiti employees. As a result, when the company was alerted to the incident, it found that its investigation and response capabilities were severely limited.
Why Was This So Challenging?
This was a uniquely cloud attack: the insider used legitimate cloud services and entities for malicious purposes, then destroyed cloud-native evidence that could be used to respond. In particular, there were two main challenges to responding to this attack:
Critical logs were not collected or not monitored in real time. This enabled the attacker to manipulate evidence needed for investigation
The attacker had valid credentials, and all of his malicious actions looked legitimate on the surface. Detecting the threat would have required behavioral analysis to understand that, for example, privileged accessed keys were being used from unusual locations, at unusual times, for unusual activity
Understanding the malicious nature of the threat required both real-time visibility and much deeper context for the cloud environment, which security operations tools not built-for-cloud are not designed to provide.
If you’re interested in learning more about cloud detection and response, make sure to download our comprehensive guide or contact our team! We’d love to hear from you.