A Practical Path from EDR to XDR — How to Do It?
When I “invented” (well, not really invented, but defined) Endpoint Detection and Response (EDR) back in 2013 at Gartner, I did think of the EDR concept as “detection and response on the endpoint.” In other words, I saw the defining primacy of “detection and response” functionality and assumed that “endpoint” is simply the place where it happens in this particular case.
Next, real life barged in and EDR today — as it is well-known — has merged with other endpoint security technologies like, say, anti-malware. Hence, an EDR product today combines the sensing aspects of the original “ETDR” vision with a wide array of other functionality, all the way down to signature-based malware protection (for some products).
However, the role of EDR as an endpoint sensor is still hugely important — perhaps more important now than back in 2013. Why collect and analyze the endpoint telemetry today? To paraphrase an old saying, “because this is where the attackers are.” Just look at the ATT&CK matrix, most tactics and traces there are, in fact, endpoint-sourced. Hence, we need this data to detect, triage and investigate.
Moreover, EDR data belongs together with other security telemetry — yet it rarely gets combined and correlated. And while the vision of XDR — Extended Detection and Response (that is, extended beyond the endpoint) — implies that EDR and other security data will be used together, there are still plenty of silos.
For example, “here is our SIEM with logs, here is our EDR with endpoint data and over here we have an NDR with network traffic captures.” Sadly, often these tools will have different collection policies and retention settings (with EDR data often retained for a few days, maybe a month).
Why was this has been difficult to accomplish so far:
- A traditional SIEM may not handle it for a multitude of reasons like volume and types of data. Most organizations who own both a SIEM and an EDR will only centralize EDR alerts, not full endpoint telemetry, inside their SIEM. Even those that do, talk about challenges on actually getting value out of it (like shortage of good SIEM content that relies on EDR telemetry).
- An EDR tool may not save it either. Volume, costs and/or architecture limitations of an EDR product are among the reasons for this (this, sadly, applies to both cloud-backed and on-premise EDRs). And, even if an EDR tool does it, it will not help with systems that are not instrumented with EDR (either theoretically or operationally) or are affected by the attacker — it also won’t help with cloud services, SaaS, etc. Finally, EDR will not merge it with other data.
Well, we at Chronicle may have changed this! As some of you know, Chronicle has launched with a capability to collect EDR data and retain it for a year at no additional cost. Yes, you really can store EDR telemetry for a year and not pay for it — while gaining an ability to search it in under a second! Now, we are also announcing a deep partnership with Tanium where our platform will be used as their retention and analytics backend.
So, what can you do with this, operationally? This will help address the following broad use cases within security operations:
- Apply detection logic to enriched and correlated security telemetry, using EDR data, vulnerability data (not common for EDRs other than Tanium), asset context (from DNS and DHCP logs), etc
- Unlike within EDR itself, this detection logic will run over all data, not just what EDR knows.
- Pivot off endpoint data to network data and back
- Match EDR data to many types of threat intelligence, in real time and historically
- Look for rare and anomalous events visually
Response / Investigation
- Search EDR and other data in under one second, over any volume/time
- Retain EDR data for 1 year or more at fixed (not volume-dependent) cost — in a secure cloud location that cannot be touched by an attacker.
- Later, we’d be able to trigger some system remediations, subject to the usual constraints.
For example, Tanium data can be used in YARA-L rules that leverage process data, connections, system changes, etc.
All in all, in my view this makes both EDR data come to life and become more useful for a broad set of security ops use cases while also making Chronicle more aware of what actually happens on those endpoints, “where the attackers are.”
Related blog posts:
*** 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/a-practical-path-from-edr-to-xdr-how-to-do-it-77855c6d4f09?source=rss-11065c9e943e------2