Anton and The Great XDR Debate, Part 2
As you recall from “Anton and The Great XDR Debate, Part 1”, there are several conflicting definitions of XDR today. As you also recall, I never really voted for any of the choices in the post.
While some of you dismiss XDR as the work of excessively excitable marketing people (hey … some vendor launched “XDR prevention”, no way, right?), perhaps there is a way to think about it from a different perspective.
What if we don’t look at XDR from either EDR or SIEM angle, but we look at it from first principles? Namely, what kind of detection and response toolset would you like to have in your life?
Before we go further, I wanted to share a personal story about my first encounter with XDR. When I was an analyst, many vendors showed me their tools and some claimed “XDR.” In most cases, my instinctive reaction was to argue with them, because I very clearly saw “SIEM” (or pieces of SIEM) in what they showed me …
Admittedly, my thinking has been colored by SIEM since 2002 when I joined my first SIEM vendor (a SIM vendor, to be precise). I did tend to treat every technology that analyzes log files and perhaps other similar telemetry as a SIEM. In light of this, it was very hard for me to see anything as “real” XDR and coincidentally see any merit in XDR idea as such. Note that it also made it very easy for me to first latch onto the “XDR is improved EDR” route, which I later abandoned …
However, why don’t we reset the perspective?! For this, we need to imagine the world without SIEM. Imagine this technology was never born (as SIM and SEM) back in the murky — but not cloudy — 1990s…
What then? Anybody would be free to invent a technology to analyze security telemetry (logs, endpoint traces, traffic) and call it whatever they want. Perhaps somebody will have invented CLA (Compliance Log Analysis) or SEC (Security Event Correlation) or perhaps SDS (Security Data Science) or SILS (Security and IT Log Search)?
Now, in this alternative world, what if you set out to invent the best technology to analyze various types of telemetry for threat detection and response (rather than to reinvent SIEM)? Let’s say you want to collect data from existing logs, collect traffic metadata and also make your own telemetry on the endpoint. Then you want to analyze the data, come up with conclusions, guide humans to proper security outcomes and occasionally automate the responses. You also want the tool to offer “out of the box” value as well as customizations/programmability. Finally, why don’t we call this technology we set out to invent “XDR”, just for fun?!
Imagine if we don’t have to relieve SIEM history and be biased by SIEM’s past as log retention and compliance reporting of the mid-2000s, as well as alert management technology of the early 2000s. Imagine we are doing the work today for today’s use cases and today’s threats. Imagine what you would build if you don’t have to fear the analysts poking fingers at you and saying “Ha, what a SIEM you got here, buddy?!”
What would we do differently? Wait for Part 3 for some of the answers.
Related blog posts:
- “Anton and The Great XDR Debate, Part 1”
- “What Is “SIEM+” Or “Can We Have A Cyber Defense Platform?””
- “A Practical Path from EDR to XDR — How to Do It?”
- “Modern SIEM Mysteries”
- “SIEM Modernization? Is That a Thing?” (Cloud Security Podcast, episode 10)
Anton and The Great XDR Debate, Part 2 was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.
*** This is a Security Bloggers Network syndicated blog from Stories by Anton Chuvakin on Medium authored by Anton Chuvakin. Read the original post at: https://medium.com/anton-on-security/anton-and-the-great-xdr-debate-part-2-b05a3cd26ffa?source=rss-11065c9e943e------2
