Anatomy of an XDR: how a modern security platform actually works

"XDR" is one of the most abused acronyms in security marketing: every vendor slaps it on whatever they sell. It stands for Extended Detection and Response, a term attributed to Nir Zuk of Palo Alto Networks and adopted by Gartner around 2018. Strip away the hype, though, and XDR is a precise promise: unify the telemetry of the whole environment - endpoint, network, identity, cloud, logs - detect threats by correlating across those silos, and respond, ideally automatically. The hard part is none of the individual pieces: it is making them into one. I know because I built one, Presidio, and this is the anatomy seen from the inside.

Where it comes from: SIEM, EDR and the silo problem

To understand XDR you need the history that precedes it. The SIEM (Security Information and Event Management) is the old backbone of the SOC: it collects logs from half the company and looks for suspicious patterns through correlation rules. The EDR (Endpoint Detection and Response) came later, bringing deep endpoint telemetry - processes, commands, connections - and the ability to react directly on the machine. The limit of both is the same: each sees a single slice. And a serious attack crosses the slices - a credential stolen on the endpoint, lateral movement on the network, an anomalous identity sign-in - where each individual event looks harmless, but the sequence is obvious if you put it together. XDR is the attempt to put those slices together. Gartner describes it with the "SOC visibility triad": logs (SIEM), endpoint (EDR) and network (NDR, Network Detection and Response), which together cover nearly every trace an attacker leaves.

The five layers of an XDR

Underneath the marketing, an XDR platform is a five-layer pipeline. Understanding them is the best way to evaluate one - or to build it.

1. Telemetry, the sources. Endpoint agents, network sensors, authentication and identity logs, cloud audit logs, application logs. The merciless rule of "garbage in, garbage out" applies: you can only detect what you collect, and a missing source is a permanent blind spot.

2. Ingestion and normalization. The layer that takes heterogeneous data and translates it into a common schema, so that a Windows event and a firewall event become comparable. It is the least flashy part, and it is where most of the engineering lives. There are standards built for exactly this: OCSF (Open Cybersecurity Schema Framework, launched in 2022 by AWS, Splunk and others) and Elastic's ECS.

3. Detection. This is where you decide what is suspicious, and three approaches coexist: rules (signatures of known behaviors), behavioral analytics (anomalies against a baseline) and matching against threat intelligence. The common language is MITRE ATT&CK, the knowledge base of the real techniques attackers use; portable rules are written in the Sigma format. And there is a principle that guides priorities, David Bianco's "Pyramid of Pain" (2013): detecting a hash or an IP barely annoys the attacker - they change them in a minute - while detecting their techniques forces them to rebuild from scratch.

4. Correlation and enrichment. This is the "X" in XDR: turning many low-signal events into one high-signal incident, joining the dots across different domains and adding context - threat intel (a platform like MISP), asset inventory, the identities involved. Without this layer you have a collection of alarms; with this layer you have a case.

5. Response. Two halves. Automation - the SOAR (Security Orchestration, Automation and Response): playbooks that isolate a machine, block an IP, disable an account in seconds. And the human work: case handling, investigation, decision. The practical rule is just one: automate the obvious, leave judgment to the human.

The common language: MITRE ATT&CK

If there is one thing to take away for evaluating any XDR, it is ATT&CK: a public matrix, maintained by MITRE, cataloguing the real tactics and techniques of attackers - not theoretical vulnerabilities, but "what an adversary actually does", step by step. Its value is twofold. It gives detection a shared language: a rule does not detect "this IP is bad", it detects "execution via obfuscated PowerShell", a precise technique. And it lets you measure coverage. The right question to ask any platform - bought or built - is not "how many alerts do you generate?", but "which ATT&CK techniques do you detect, and how do you measure it?".

Detection is engineering, not a product

The most common mistake is thinking detection is bought once and works forever. It does not: attackers adapt, rules age, and false positives bury the real signal - the alert fatigue I covered in the piece on cutting the noise in threat intelligence. This is why the discipline of detection engineering exists: detections written as code - versioned, tested and reviewed the way software is - portable Sigma rules, and validation through purple-teaming exercises, that is, simulated attacks to verify the detection actually fires. The real value of an XDR is not the dashboard: it is the detection content and its continuous maintenance.

The two metrics that matter: MTTD and MTTR

A security platform is measured by two numbers. MTTD (Mean Time To Detect), how long before an attack is seen, and MTTR (Mean Time To Respond), how long before it is stopped. Dwell time - the days an attacker stays inside undisturbed - has fallen over the years, as documented by Mandiant's M-Trends, but ransomware has compressed the useful window to a few hours. This is where automation changes everything: a SOAR playbook responds in seconds where a human would take hours. A platform that detects in days is theater; the target is minutes.

Bought, built or assembled

There are "all-in-one" commercial XDRs: fast to switch on, a single vendor to hold accountable - but with lock-in, costs that grow and black-box detection. The alternative is to assemble one from mature open source components, which today cover every layer. It is exactly how I built Presidio.

The point, again, is not the components - they are proven and documented everywhere. The engineering work, and the value, is in the integration: the bridges that make the SIEM talk to the SOAR, the SOAR to the case manager, threat intel to everything, so that a single event triggers a correlated, automated, documented response in seconds. Presidio's playbook for an SSH brute force, for example, correlates the event with threat intel, opens a case and can block the IP across the entire infrastructure - in one shot. Owning that integration is owning the platform.

Platform or dashboard? The test

The question that separates a real XDR from a colorful console is simple: does the system do the work, or do you do it by staring at graphs? A real XDR correlates across domains (it does not just collect), has measurable ATT&CK coverage, automates response (not just alerts), keeps a case and an audit trail, and is tuned down to few false positives. A dashboard shows you the data and leaves you to find the breach yourself.

A checklist to evaluate (or build) an XDR

• Sources: do you really cover endpoint, network, identity and cloud, or just one slice?
• Detection: is it mapped to MITRE ATT&CK, and is coverage measured?
• Correlation: is it cross-domain or only per-silo?
• Response: is there automation (SOAR), not just alarms?
• Workflow: is there case management and an audit trail of what was done?
• Metrics: are MTTD and MTTR measured and improving over time?
• Ownership: can you see, version and modify the detections, or are they a black box?

The takeaway

XDR is not a product to buy sight unseen: it is a capability - to see everywhere, correlate, respond fast, and improve over time. The acronym is what every vendor adds; the substance is in five layers that must work as one. Whether you buy it, assemble it or build it - I built it - the measure does not change: how fast you see an attack, how fast you stop it, and how much of the process does not depend on a human being awake at three in the morning.