Security practitioners know the importance of detection and response activities. Some have jokingly said the significance of a topic can be measured in how many acronyms it has.
Detection and response has plenty:
- managed detection and response (MDR)
- network detection and response (NDR)
- endpoint detection and response (EDR)
- extended detection and response (XDR)
Given how critical cloud implementation is, it's no surprise cloud detection and response (CDR) has emerged.
But what is this new detection and response category? And how should organizations evaluate it?
What is cloud detection and response?
As an emerging term, CDR can relate to a couple different things. A cursory search for CDR reveals two main uses:
- detection and response to security-relevant events that target cloud workloads and services; and
- detection and response supported by cloud-based tools.
In this article, CDR serves as an extension of detection and response to cover assets, including workloads and services used, in the cloud through on-premises or cloud-based products.
Cloud detection and response questions to consider
Note, CDR is a work in progress. Not every practitioner or vendor embraces cloud detection and response as its own product or as a functional or operational category yet. If your organization is considering CDR, here are five key aspects to help navigate the space.
1. Where, why and how do you need it?
Much of the conversation around CDR originates from vendor marketing. Because it is an emerging category, it's important not to get blindered by a vendor's approach and let them influence future thinking.
Instead, start from the problem that needs solving and work outward. Bring the problem to the marketplace to look for solutions. This will help you find the true answer to the problem rather than just what someone wants to sell to you.
2. Which approach is optimal for you?
Detection and response in the cloud has multiple approaches. One strategy is analyzing logging and monitoring information from cloud providers to locate attacker activity. Another is to use an agent on IaaS workloads to gather operational information about specific workloads and their internal state.
The first approach has the advantage of being usable in services beyond IaaS, such as PaaS. A disadvantage is that logging formats are often vendor aligned. The second approach has the advantage of getting a lot of information from any given workload that's portable between cloud service providers (CSPs). A disadvantage is that it only works in an IaaS context.
Bottom line: Where the capability is needed influences which approach -- or fusion of both -- is best for your organization.
3. When do you need a CDR-like product?
The cloud requires some differences in how to approach detection and response. However, CDR being so nascent has two major implications:
- New players can emerge that target exactly this problem.
- Existing vendors can expand into the space.
Would it make sense to buy a new CDR product when your existing MDR or EDR might offer it in a future extension of its product set? Will cloud security posture management vendors incorporate CDR capabilities into their product offerings? Might CSPs extend capabilities in AWS GuardDuty or Microsoft Defender for Cloud, for example, to provide similar services?
These possibilities could happen over a short time or not at all. It therefore matters what your time frame is, which means thinking about CDR in the context of a multiyear strategy versus something you pick up on the way home.
4. What's the roadmap for your existing providers?
It's almost a guarantee that existing detection and response vendors have a plan to optimize for the cloud. A few are in the "install our agent on cloud workload" phase, but serious players have a story to tell about how to get the most of their service in the cloud.
Have a conversation with existing providers about their plans before purchasing a new niche product. It's not a given that existing providers can support your company quickly or thoroughly enough, but it never hurts to ask what their timeline is to make an informed decision.
5. How will you operationalize?
Think through how to operationalize detection and response into your existing capability. If you have an incident response function or security operations center, it might mean giving existing teams another window to check -- but things are seldom that easy. Think about how to tie together information from existing platforms, on-premises data sources and more with information from the cloud.
Discuss with operations teams and cloud architects about how changes will be implemented. After all, cloud workloads may be ephemeral -- e.g., generated from infrastructure-as-code scripts such as Terraform -- in a way that on-premises hosts are not. This means effecting permanent remediation on a workload may need to happen differently than it would on premises. Discuss how this will happen with the stakeholder and operational teams with that requisite oversight.