WhatDR or What Detection Domain Needs Its Own Tools?
This is the blog where I really (briefly) miss my analyst life and my “awesome+” peers like Augusto and Anna. It relies on ideas and comments from my past collaborators … and my current ones. And, yes, this blog was inspired by a hallways conversation at a conference that took place more than a year ago :-(
So, the question:
When and where do you need “<domain>DR” tool for its own technology domain?
Bear with me for a moment as we ponder this mystery.
Everybody knows EDR, some know NDR, a few ramble about XDR. We also have ITDR emerging (IMHO, ITDR is a bastard half-brother of UEBA). We talk of CDR for cloud. Some vendors tried to create DDR (for data). I almost forgot MDR (Gemini helpfully reminded me), but this is different (because service aka “rent a human”). There was once a clown who tried making VMDR (OMG, this is the dumbest, as it makes no sense whatsoever). ADR for Application Detection and Response is probably coming, because ASPM is here already (this eBPF observability stuff may yet lead to more odd-duck *DRs or RASP 2.0… but I digress). And, gods, please, no AI-DR…
At the same time, you can send Zeek data into a SIEM (“poor person’s NDR”), you can send sysmon there too (“poor person’s EDR”), you can load up on cloud logs to recreate some form of CDR too.
So when do we need its own ?DR?
?DR Examples
Let’s go bottom up, a natural way to think for me. Examples!
First, EDR is a very clear case. We needed EDR because endpoint detection and response cannot be reduced to logs. Good EDRs observe all sorts of activities (kernel this and that, live memory, DLLs coming and going, etc). EDR delivers solid 1st party telemetry closely coupled to detections running off that. “Sysmon into SIEM” is a very poor EDR imitation indeed (but, yes, it is still useful in many cases)
Second, DDR probably should not exist as data is not really a technology domain. DLP has long been used for visibility, and its iffy reputation notwithstanding, ultimately delivers on data movement detection, investigation and response (VMDR too stupid to discuss, so I won’t).
Third, sadly, a lot of cases fit in the gray zone. CDR for cloud, ITDR for identity (or: for IAM) and many others, real and imagined (like ADR for applications or KDR for containers) have decent arguments pro and con. You can go pretty deep down that rabbit hole (and we will… below): microservices DR? SaaS DR (this almost exists)? SAP DR? AI or LLM DR? Kontainer DR? IoT/OT DR?
So when is a new “something DR” technology appropriate for a domain?
Let’s try to rephrase this a bit, and not lose the idea: when do we use a broad, general-purpose tool (this is most likely a SIEM) to detect threats to that domain? When do we need a special tool? When do we need both?
Before we go deeper, let’s touch on one more dimension: ?DR implies D + R, which in practice serves the needs of detection, investigation and response. In the past, we had technologies that were frankly just “D” (say, NIDS or even ancient HIDS) or just “R” (fewer of them around, maybe some forensics tools or early “EDR” with strong “R” and weak “D”). Today some emerging CDR tools are “more D” while others are “more R.” (and Gartner is cooking CIRA which in my mind is a very “R” heavy CDR.)
?DR, SIEM or Both
In many scenarios, our question (“do we need a separate ?DR?”) manifests as the choice between a narrow, focused, dedicated single domain detection/response technology, such as Network IDS in the old days and something like NDR today, and a broad scope platform that today is called SIEM (or XDR if you are into that sort of thing). And let’s not forget the case of “both”, that is brilliantly described by Augusto here.
Regarding “both”, let’s have one more detour. There is a percentage of security people that I encountered during my travels, who question that this debate even exists. These people tend to relegate SIEM to post-processing of alerts and do not consider it to be an effective detection technology on its own. Indeed, if you think of SIEM as pure alert management rather than alert creation and investigation, this debate disappears and you always reach for a focused detection tool if you have a detection problem. My view is that while SIEM/SOAR works for alert management, a modern SIEM is also an effective detection tool.
There is a lot more to both, BTW. For example, some people detect via EDR but then investigate via SIEM that has both EDR data and sysmon logs with a much longer retention time. Or, they detect on a SIEM and then investigate by looking at raw packets in NDR. This blog does not invalidate any of this, it just seeks to determine the right niches where separate D&R technology is necessary or advisable…
Decision Dimensions
Let’s think of some dimensions to include.
- Need telemetry that is never available in logs for detection/response -> ?DR
- Need telemetry that is practically rarely logged for detection/response -> ?DR, probably
- Need context data that SIEM cannot access for detection -> ?DR
- Covers domain that is practically rarely connected to a SIEM -> ?DR, probably
- Detections need to happen close to a source and in near-real time (e.g. for ephemeral systems) -> ?DR, probably
- Detection development needs deep domain knowledge that SIEM vendors do not have and won’t develop -> maybe ?DR
- Detection in this domain need context or logs from another domain to work -> SIEM
I have a strong sense that these aren’t all of them and many key dimensions are still missing. By the way, the above probably all speak to the detection needs, but perhaps not to the relevant ?DR technology viability in the real world and not to market viability for such tools.
Decision Simulation
Let’s try to simulate this decision for a hypothetical example I just invented, KDR for Kontainers. Yay or nay?
So, which side are you on? Got better examples? What else am I missing here?
Related blogs:
