Let’s ponder the space between Detection (D) and Response (R):
D <aim your mind here!> R
Do you see it clearly now? Where does DETECTION end and RESPONSE begins? What is this space between them?
As more organizations finally give their detection controls the attention they deserve, the critically important space between D and R comes to their attention as well. After all, you will detect way more interesting stuff than you will actually trigger a formal incident response (IR) process over. Furthermore, some of the recent examples really drive this point home….
So, detection gives you alerts, indications, ambiguous end user reports, other weak signals about possible attacker activities, mixed in with copious amounts of noise (sorry, $VENDOR, if you truthfully claim “no false positives”, this means that your “false negatives” i.e. missed attacks are through the roof). On the other hand, response – such as formally declaring an incident – requires clarity and not ambiguity, as the CIRT team is imbued with their super-powers during the actual live response. How and when you transition from D to R really matters.
There is no single name for the space between detection and response. I often use the term “triage” or “alert triage”, but I also admit this usage is not standard. Still, this between-D-and-R stage is what enables you to actually stop the attacker before the damage is done. Yes, D and R on their own are critical, but the link between them is even more critical! If your SOC and CIRT (at the higher end of the organizational security maturity) work really well – but not together – the chance that the attacker will WIN and you will LOSE is still very high, despite all the technology investments.
The activities that (IMHO) sit between D and R include:
- qualifying various security alerts
- gathering additional data from endpoints, network traffic, etc
- deciding which user reports matter more and may indicate a real incident
- enriching and prioritizing other signals that may lead to the incident declaration
- scoping the impact of any potential incident
There you have it – now mind the gap [between D and R]!
Blog posts related to triage process:
The Gartner Blog Network provides an opportunity for Gartner analysts to test ideas and move research forward. Because the content posted by Gartner analysts on this site does not undergo our standard editorial review, all comments or opinions expressed hereunder are those of the individual contributors and do not represent the views of Gartner, Inc. or its management.
Comments are closed
6 Comments
May use the OODA loop to fill the gap. OODA = Observe, Orient, Decide, Act. I see Detect correspond to Observe and Response correspond to Act.
So the Orient and Decide stages are missing.
https://en.wikipedia.org/wiki/OODA_loop
Indeed, that is a good model for this!
I see there is a comment posted by Euler Global Consulting. Am unable to see the comment. Does one need special access to see others’ comments?
That’s because this system groups inbound links from other blogs as comments…..
Anton — I have read most of your public articles on EDR. Thanks for sharing your insights.
I can use some help in understanding the boundary between AV, NGAV, and EDR. Can you help? Since you’ve coined the term EDR (and maybe, NGAV too), you are the best person to ask.
AVs and NGAVs technically speaking ‘detect’ malware. That would imply they should be in EDR. But if I understood correctly you do place AVs within EDR. In such case, there must be a good reason.
Could you expand on your thought on the boundaries between AV, NGAV, and EDR as it pertains to detecting/preventing malware?
Thanks..
That is a BIG question, actually. Where does EDR end and “NGAV” (not an accepted abbreviation) begins? Typically we draw the line on PREVENTION….but is rapid remediation = prevention?