Ditch The Cloud Security Labels to Nail Detection and Response

Today’s cloud security categories don’t do practitioners any favors when it comes to identifying the key requirements for detection and response in the cloud. This is because various detection and response capabilities cut across other cloud security categories like Kubernetes Security Posture Management (KSPM), Identity Threat Detection and Response (ITDR), Cloud Workload Protection (CWPP), Cloud Native Application Protection Platforms (CNAPP) and more.

But, despite a projected 95% of new application workloads being deployed on cloud-native platforms by 2025, 90% of organizations running containers and Kubernetes report recent breaches. Meanwhile, 95% of IT security leaders feel the skills gap is affecting their teams. With the rise of zero-day threats like the XZ Backdoor, shoring up the ability to detect and respond to cloud attacks has never been more important.

So how can you navigate the evolving threat landscape? The first step is to look beyond the traditional categories to understand what truly matters in detection and responding to cloud attacks.

What Do the Attacks Tell Us?

In February 2024, the Cybersecurity and Critical Infrastructure Agency CISA issued a warning about new tactics by SolarWinds attackers targeting cloud infrastructure and non-human identities. The Scarleteel attack of 2023 showcased how attackers exploit cloud environments, moving fluidly from workloads through Kubernetes to steal credentials and use valid programs for malicious purposes. In the entire attack killchain, only botnet installation and data exfiltration were clearly malicious.

In 2023, attacks like Dero, Monero, and RBAC-Buster exploited Kubernetes RBAC misconfigurations and gained anonymous authentication. The XZ Backdoor supply chain attack in March 2024 further emphasizes the rising threat that software supply chain attacks pose to cloud environments.

Together, these incidents underscore three criteria:

1. The need for robust detection and response strategies that address normal processes that are used in malicious ways, instead of just looking for overtly malicious activities in cloud environments.
2. The need to include identity as critical context for investigation and response.
3. Cloud Detection and Response (CDR) must detect software supply chain attacks.

What CDR Is Not

Categories overlap, there is no way around this. So, it is helpful to clearly delineate what CDR is not. First, a CDR tool is not a Security Information and Event Management (SIEM) solution. When was the last time you expected your SIEM tool to detect a zero day, in and of itself?

A CDR is also not a Security Operations Center (SOC), though they are 100% complementary. Your SOC will NEVER be focused exclusively on the cloud . . . while CDR provides the very nuanced, specific tactics and detection methods for the cloud. The purpose of your SOC is broader and takes into account cloud plus on-premises environments.

A CDR is also not a Cloud Native Application Protection Platform (CNAPP) or a Cloud Security Posture Management (CSPM) solution because those solutions can’t determine effective responses to cloud attacks. At best, a CNAPP combines real-time, signature-based runtime alerts with static Kubernetes and cloud configurations. And at best, this gives teams reactive detections to known attacks (that are easy to bypass), and inactionable configuration recommendations for ephemeral workloads. You can’t detect and respond to novel cloud attacks without real-time insight and signature-less, behavioral detection.

The categories tell us that a CDR is not a CNAPP, SIEM or SOC. A CDR requires real-time insight and technology that can detect zero days (aka not signatures).

Should a CDR Be Focused on Applications?

Cloud use-cases are broad, but top attention must go to applications, which are central to all cloud functions. With Kubernetes increasingly managing tasks like messaging and observability—showing a 211% usage increase from 2021 to 2022—security teams must prioritize adapting to cloud-native tools used in application development for effective cloud detection and response. There is probably room for the CDR capability to be further defined as CADR—Cloud Application Detection and Response.

The usage of the cloud tells us that a CDR must have the nuanced detection and response capabilities required for Kubernetes and cloud native environments.

Criteria for Detecting and Responding to Cloud Attacks

Now that we know what is in and out for effective CDR, what are some examples of actual technical criteria under each criteria?

What’s In:

• Techniques that can detect zero days; not signature-based
  • Detection goes beyond syscalls and attackers’ known techniques: Attacks that are completed within the application layer don’t make syscalls. For example, an attacker writing information to a different file than usual will have hidden among existing syscalls and gone undetected. Also, many times, a clustering of non-malicious syscalls might denote an issue, whereas looking at those syscalls individually will not show anything malicious.
• Applies to software supply chain attacks
  • Immediately search for a workload with a log4j vulnerability, or any other new Kubernetes 3rd party vulnerability, across running clusters: A software supply chain security attack could be caused by exploiting a zero day CVE, like log4j. It’s important to know where the CVE exists in your running workloads, not just in your pre-deployment code, because your running deployments should guide your priorities.
• Effective with Kubernetes and containers
  • Admission control policies that can limit both the RBAC policy factor as well as Kubernetes policy configurations: Admission control is the method by which response actions would stop malicious activities in a Kubernetes environment, so they are a critical requirement of any cloud detection and response solution.
• Includes Cloud Identity Context
  • Identity Risk score that takes into account usage: Identity risk score that includes context from actual usage and other relationships with runtime, the cloud, image CVEs and K8s misconfigurations
• Can determine valid processes used as part of a malicious campaign
  • Implements drift or anomaly detection: The lightest, easiest way to perform threat detection is via drift from a behavioral baseline of runtime behavior. Detecting drift between container images prior to deployment, and runtime behavior, compared to detecting drift from a baseline of ‘good’ in your environment, is hugely inefficient. Container images contain a fair amount of bloat, and many of the pieces in that bloat contain a vulnerable attack surface. Tying drift from a container image to what should be happening in runtime is not the right comparison (though immutability is appealing as a concept!).

What’s Out:

Conclusion

The truth is, there are more items, and more levels to dive when it comes to determining what is in and out of CDR. But by now, we should know that there is more than meets the eye when it comes to using tools in the classic categories of cloud security for detection and response. Navigating the cloud security landscape requires a clear understanding of what truly matters for effective detection and response.

To combat the evolving threat landscape, organizations must prioritize robust detection and response strategies that go beyond surface-level classifications. This includes focusing on real-time, signature-less detection techniques, understanding the critical role of identity context, and addressing software supply chain attacks (not just vulnerabilities in open source software). By cutting through the clutter of cloud security categories and honing in on these essential criteria, practitioners can better protect their cloud environments from sophisticated attacks and ensure a more secure future in the cloud.

About the Author

Jimmy Mesta is the Founder and Chief Technology Officer at RAD Security. He is responsible for the technological vision for the RAD Security platform. A veteran security engineering leader focused on building cloud-native security solutions, Jimmy has held various leadership positions with enterprises navigating the growth of cloud services and containerization. Previously, Jimmy was an independent consultant focused on building large-scale cloud security programs, delivering technical security training, producing research and securing some of the largest containerized environments in the world.

You can connect with Jimmy on Linkedin https://www.linkedin.com/in/jimmymesta/ or by visiting https://rad.security/.