Security Visualized
Library

Detection and response

SIEM compared with XDR

A SIEM ingests, normalises, correlates and retains events from any source you can get logs out of; XDR takes a narrower set of telemetry from sensors its own vendor operates, reasons about it in more depth, and can take action on the host.

What is being compared

The two subjects

Both are one scene apart, not two architectures apart — which is why the diagram below is a single scene with each subject's claim on it marked, rather than two pictures to hold in your head at once.

  • Security information and event management (SIEM)

    Marked "only in Security information and event management (SIEM)" in the delta below.

    A vendor-neutral collection, correlation and retention platform. It will take logs from anything that emits them, and keeps them long after the alert.

    No entry of its own yet

  • Extended detection and response (XDR)

    Marked "only in Extended detection and response (XDR)" in the delta below.

    A narrower, deeper platform built on sensors its vendor operates, able to pull richer context from them and to act on the host without a human step.

    No entry of its own yet

Architecture diagram

One detection pipeline, two ways of ending it

The same estate emits telemetry to one correlation and triage point, which raises a case for an analyst. The retention archive, the compliance reporting that reads it, and the third-party and legacy sources feeding it belong to the SIEM alone. The playbook that contains a host without waiting for a person, and the deeper reach back into the sensor, belong to XDR alone.

Step 1 / 5Collect from everything that will talk

Architectural planes

Annotations

The same architecture, read top to bottom

  1. External network

    UNTRUSTEDNot controlled and not trusted; anyone may be present on it

    Adversary

    • AdversaryAdversaryPhished user, then harvested credentials

    Reaches this boundary

    • BlockedAdversary stopped at Endpoint agentHost isolated, so the session is cut

  2. Endpoint estate

    MANAGEDOperated or administered on the enterprise's behalf

    User workstation · Server workload · Endpoint agent

    • DeviceUser workstationWhere the attachment was opened
    • DeviceServer workloadReached by credential reuse
    • Security controlEndpoint agent
      • Process, file and network events
      • Detection logic on the host
      • Host isolation
      • Process termination

    Reaches this boundary

    • RequestCorrelation and analytics to Endpoint agentLive query pushed to the sensor
    • RequestAutomated response playbook to Endpoint agentIsolate the host, with no human step
    • RequestSecurity analyst to Endpoint agentContainment carried out in another console
    • AttackAdversary to User workstationMalicious attachment opened by the user
    • AttackAdversary to Server workloadCredential reuse against a server

    Within this boundary

    • TelemetryUser workstation to Endpoint agentProcess, file and network events
    • TelemetryServer workload to Endpoint agentService and authentication events
    • RequestEndpoint agent to Server workloadProcess terminated on the host

  3. Network and cloud services

    MANAGEDOperated or administered on the enterprise's behalf

    Network firewall · Identity provider

    • API or gatewayNetwork firewallConnection and block records
    • Identity providerIdentity providerSign-on, second factor and risk events

  4. Third-party SaaS

    THIRD PARTYOperated by another organisation under its own terms

    Third-party SaaS audit log

    • Data storeThird-party SaaS audit logAdministrative trail from another supplier

  5. Legacy on-premises systems

    INTERNALOperated by the enterprise itself

    Legacy business application

    • ApplicationLegacy business applicationSyslog only, and no agent will run on it

  6. Analysis platform

    MANAGEDOperated or administered on the enterprise's behalf

    Automated response playbook

    • Security controlAutomated response playbookVendor-supplied containment actions
    • Correlation and triage
      MANAGEDOperated or administered on the enterprise's behalf

      Correlation and analytics · Triage

      • Security controlCorrelation and analytics
        • Normalise events to one shape
        • Correlate across sources
        • Score against detection content
        • Assemble the case evidence
      • Policy decisionTriageContain, escalate, gather more, or close
    • Retention and reporting
      MANAGEDOperated or administered on the enterprise's behalf

      Long-term event archive · Compliance reporting

      • Data storeLong-term event archiveNormalised events kept for the retention period
      • Security controlCompliance reportingControl testing and audit evidence

    Reaches this boundary

    • TelemetryEndpoint agent to Correlation and analyticsHost detections and raw events
    • TelemetryNetwork firewall to Correlation and analyticsConnection and block records
    • TelemetryIdentity provider to Correlation and analyticsSign-on outcomes and risk signals
    • TelemetryThird-party SaaS audit log to Correlation and analyticsAdministrative trail from a third party
    • TelemetryLegacy business application to Correlation and analyticsSyslog from a system no sensor covers
    • ContextEndpoint agent to TriageFull process ancestry, supplied on demand
    • RequestSecurity analyst to Long-term event archiveHunting and late-starting investigations

    Within this boundary

    • RequestCorrelation and analytics to TriageCorrelated case with its evidence
    • RequestTriage to Automated response playbookContainment selected from the verdict
    • RequestCorrelation and analytics to Long-term event archiveNormalised events kept for the full period
    • RequestLong-term event archive to Compliance reportingEvidence for audit and control testing

  7. Security operations centre

    INTERNALOperated by the enterprise itself

    Security analyst

    • PersonSecurity analystThe judgement neither product supplies

    Reaches this boundary

    • RequestTriage to Security analystEscalated for human judgement

Legend

Participants

  • PersonSomeone making a request, and the identity they assertCircle with a person mark
  • DeviceAn endpoint the request is made from, with its own postureRounded rectangle with an inset panel
  • ApplicationAn application that serves or holds dataRounded rectangle with a panel stacked behind it
  • Identity providerThe authority that asserts who is askingHexagon marked ID
  • API or gatewayA network endpoint that terminates or forwards connectionsCapsule marked API
  • Data storeWhere data restsCylinder
  • Security controlA protective control, and the control plane's own observationRounded octagon with a check mark
  • AdversaryA hostile party attempting somethingDiamond marked with an exclamation mark
  • Policy decisionWhere policy is evaluated and one verdict is reachedDiamond with a split-path mark on its trailing point

Relationships

  • RequestTraffic asking to reach a destinationSolid line. Filled arrowhead.
  • TelemetryEvents reported onward for observation — observation, not controlDotted line. Small open arrowhead.
  • ContextA signal that informs a decision without carrying the request itselfDash-dot line. Open chevron.
  • AttackAn attempt made by an adversaryShort-dashed heavy line. Barbed open arrowhead.
  • BlockedAn attempt terminated by the control the line starts fromHeavy line that stops short of its target. Perpendicular bar, and deliberately no arrowhead: the attempt did not arrive.

Boundaries

  • Internal boundaryOperated by the enterprise itselfSolid outline. Badge reads INTERNAL.
  • Managed boundaryOperated or administered on the enterprise's behalfDashed outline with a subtle wash. Badge reads MANAGED.
  • Third party boundaryOperated by another organisation under its own termsDash-dot outline. Badge reads THIRD PARTY.
  • Untrusted boundaryNot controlled and not trusted; anyone may be present on itDotted outline with a hatched leading corner. Badge reads UNTRUSTED.

Text alternative

The request, step by step

  1. Collect from everything that will talk

    Hosts report through an agent, and the firewall and identity provider report directly. A third-party audit log and a legacy application also arrive, but only where the platform accepts arbitrary sources rather than its own vendor's sensors.

    • Telemetry: User workstation to Endpoint agent, “Process, file and network events”
    • Telemetry: Server workload to Endpoint agent, “Service and authentication events”
    • Telemetry: Endpoint agent to Correlation and analytics, “Host detections and raw events”
    • Telemetry: Network firewall to Correlation and analytics, “Connection and block records”
    • Telemetry: Identity provider to Correlation and analytics, “Sign-on outcomes and risk signals”
    • Telemetry: Third-party SaaS audit log to Correlation and analytics, “Administrative trail from a third party”
    • Telemetry: Legacy business application to Correlation and analytics, “Syslog from a system no sensor covers”

    Emphasised at this step: Correlation and analytics.

  2. Correlate, then decide what it is

    Events are normalised to a common shape, correlated across sources, scored against detection content and assembled into a case. Triage then decides whether to contain, escalate, gather more or close it.

    • Request: Correlation and analytics to Triage, “Correlated case with its evidence”
    • Request: Triage to Security analyst, “Escalated for human judgement”

    Emphasised at this step: Triage.

  3. Reach back into the sensor for depth

    Where the platform owns the sensor, it can ask the host for a full process ancestry and run a live query rather than working from whatever the source chose to log. A collector that only receives events cannot ask a follow-up question.

    • Context: Endpoint agent to Triage, “Full process ancestry, supplied on demand”
    • Request: Correlation and analytics to Endpoint agent, “Live query pushed to the sensor”

    Emphasised at this step: Endpoint agent.

  4. Contain the host, by playbook or by hand

    A playbook can isolate the host through the same agent that detected the behaviour, with no console change. Otherwise an analyst carries out the same action somewhere else, and the delay is the handoff rather than the capability.

    • Request: Triage to Automated response playbook, “Containment selected from the verdict”
    • Request: Automated response playbook to Endpoint agent, “Isolate the host, with no human step”
    • Request: Security analyst to Endpoint agent, “Containment carried out in another console”
    • Request: Endpoint agent to Server workload, “Process terminated on the host”

    Emphasised at this step: Automated response playbook.

  5. Retain what the investigation will need later

    Normalised events are kept for the full retention period, read by compliance reporting for control testing, and queried by analysts for hunting and for investigations that begin months after the events they are about.

    • Request: Correlation and analytics to Long-term event archive, “Normalised events kept for the full period”
    • Request: Long-term event archive to Compliance reporting, “Evidence for audit and control testing”
    • Request: Security analyst to Long-term event archive, “Hunting and late-starting investigations”

    Emphasised at this step: Long-term event archive.

Attempts shown, and where each one stops

  • Adversary attempts:

    • Attack: Adversary to User workstation, “Malicious attachment opened by the user”
    • Attack: Adversary to Server workload, “Credential reuse against a server”
    • Terminated here by Endpoint agent — “Host isolated, so the session is cut”. The line stops short and takes a bar, not an arrowhead.

Annotations

  1. The source that decides the architecture

    Relationship — Telemetry: Legacy business application to Correlation and analytics, “Syslog from a system no sensor covers”

    A system that emits syslog and will never host an agent is either in scope or invisible. A collector that accepts arbitrary sources can take it after somebody writes a parser; a sensor-native platform cannot, and the console gives no sign that anything is missing.

  2. Why this line is short

    Relationship — Request: Automated response playbook to Endpoint agent, “Isolate the host, with no human step”

    Detection and containment happen inside one product, through the agent that raised the alarm. That is the integration advantage, and it exists because a single supplier owns both ends, which is also the definition of the lock-in.

  3. What actually terminated the intrusion

    Relationship — Blocked: Adversary stopped at Endpoint agent, “Host isolated, so the session is cut”

    The agent, not the analytics. Both designs end here; they differ in how many minutes and how many human steps come first. Neither reaches this point at all if nobody has agreed in advance what may be isolated without asking.

  4. Retention is a separate requirement wearing the same badge

    Component “Long-term event archive”

    Keeping normalised events for years serves audit, control testing and investigations that start late. It is a storage and evidence obligation rather than a detection one, and it is usually why a SIEM stays in place after a faster tool arrives.

  5. Normalisation is both the value and the loss

    Component “Correlation and analytics”

    Forcing every source into one shape is what makes cross-domain correlation possible, and it discards whatever did not fit the schema. Depth and breadth pull against each other here, which is the real reason estates end up running both kinds of platform.

  6. Another supplier's audit trail

    Boundary “Third-party SaaS” (third party)

    Administrative activity in a third-party service is often the only record of a configuration change that mattered. Whether it can be ingested at all depends on the platform's willingness to accept sources it does not operate.

  7. Neither product creates a response capability

    Boundary “Security operations centre” (internal)

    An alert with nobody rostered to read it, and a containment action nobody is permitted to take, are the same as no detection. Tooling changes how quickly a decision can be executed; it does not supply the decision, the rota or the mandate.

The delta

What each one adds, and what they share

Computed from the claims each subject makes on the one scene above, not drawn separately. Every box and every path in that diagram is claimed by all of these designs or by exactly one of them, and the bands below are that partition.

35 elements in the scene · 20 shared · 10 in SIEM · 5 in XDR

Shared by both designs

9 boxes · 11 paths

Claimed by Security information and event management (SIEM) and Extended detection and response (XDR) alike. This is the larger part of the scene, and saying so is part of the answer: two things worth comparing usually agree about most of the architecture, and a comparison that hides the agreement makes the difference look bigger than it is.

  • Adversary Adversary — Phished user, then harvested credentials Shared by both designs.
  • User workstation Device — Where the attachment was opened Shared by both designs.
  • Server workload Device — Reached by credential reuse Shared by both designs.
  • Endpoint agent Security control Shared by both designs.
  • Network firewall API or gateway — Connection and block records Shared by both designs.
  • Identity provider Identity provider — Sign-on, second factor and risk events Shared by both designs.
  • Correlation and analytics Security control Shared by both designs.
  • Triage Policy decision — Contain, escalate, gather more, or close Shared by both designs.
  • Security analyst Person — The judgement neither product supplies Shared by both designs.
  • User workstation to Endpoint agent Telemetry — Process, file and network events Shared by both designs.
  • Server workload to Endpoint agent Telemetry — Service and authentication events Shared by both designs.
  • Endpoint agent to Correlation and analytics Telemetry — Host detections and raw events Shared by both designs.
  • Network firewall to Correlation and analytics Telemetry — Connection and block records Shared by both designs.
  • Identity provider to Correlation and analytics Telemetry — Sign-on outcomes and risk signals Shared by both designs.
  • Correlation and analytics to Triage Request — Correlated case with its evidence Shared by both designs.
  • Triage to Security analyst Request — Escalated for human judgement Shared by both designs.
  • Endpoint agent to Server workload Request — Process terminated on the host Shared by both designs.
  • Adversary to User workstation Attack — Malicious attachment opened by the user Shared by both designs.
  • Adversary to Server workload Attack — Credential reuse against a server Shared by both designs.
  • Endpoint agent to Adversary Blocked — Host isolated, so the session is cut Shared by both designs.

Only in Security information and event management (SIEM)

4 boxes · 6 paths

Present when the scene is read as Security information and event management (SIEM), and absent when it is read as Extended detection and response (XDR). 4 boxes and 6 paths.

  • Third-party SaaS audit log Data store — Administrative trail from another supplier Only in Security information and event management (SIEM).
  • Legacy business application Application — Syslog only, and no agent will run on it Only in Security information and event management (SIEM).
  • Long-term event archive Data store — Normalised events kept for the retention period Only in Security information and event management (SIEM).
  • Compliance reporting Security control — Control testing and audit evidence Only in Security information and event management (SIEM).
  • Third-party SaaS audit log to Correlation and analytics Telemetry — Administrative trail from a third party Only in Security information and event management (SIEM).
  • Legacy business application to Correlation and analytics Telemetry — Syslog from a system no sensor covers Only in Security information and event management (SIEM).
  • Security analyst to Endpoint agent Request — Containment carried out in another console Only in Security information and event management (SIEM).
  • Correlation and analytics to Long-term event archive Request — Normalised events kept for the full period Only in Security information and event management (SIEM).
  • Long-term event archive to Compliance reporting Request — Evidence for audit and control testing Only in Security information and event management (SIEM).
  • Security analyst to Long-term event archive Request — Hunting and late-starting investigations Only in Security information and event management (SIEM).

Only in Extended detection and response (XDR)

1 box · 4 paths

1 box belongs to Extended detection and response (XDR) alone, and 4 paths do. Most of this difference is therefore in the connections rather than in the parts, which is what it looks like when an advantage is behavioural: there is little to add to the scene, and a great deal to change about how it moves.

  • Automated response playbook Security control — Vendor-supplied containment actions Only in Extended detection and response (XDR).
  • Endpoint agent to Triage Context — Full process ancestry, supplied on demand Only in Extended detection and response (XDR).
  • Correlation and analytics to Endpoint agent Request — Live query pushed to the sensor Only in Extended detection and response (XDR).
  • Triage to Automated response playbook Request — Containment selected from the verdict Only in Extended detection and response (XDR).
  • Automated response playbook to Endpoint agent Request — Isolate the host, with no human step Only in Extended detection and response (XDR).

Dimension by dimension

How each behaves, on each axis that matters

SIEM compared with XDR: how each subject behaves on each dimension of the comparison.
Dimension Security information and event management (SIEM) Extended detection and response (XDR)
What it will accept as a source Anything that produces a log: appliances, business applications, badge readers, mainframes, other vendors' security tools. Mostly the vendor's own sensors, plus whatever integrations it ships. A system with no supported connector is simply not in scope.
Depth of what it knows about an event As much as the source chose to log, normalised into a common shape, which flattens detail that did not fit the schema. It owns the sensor, so it can hold a full process ancestry and ask the host for more after the fact.
Ability to act Raises a case. Containment happens in another console, by a person, or through a separate automation platform you integrate and maintain. Can isolate a host or kill a process through the same agent that detected the behaviour, with no console change in between.
Retention and evidence Usually the system of record: years of normalised events, searchable for audit, control testing and investigations that start late. Retention is typically shorter and tuned to detection. It is rarely the place an auditor is sent for a two-year-old access trail.
Cost shape Driven by data volume and retention, so coverage and cost rise together and the tuning conversation is partly a budget conversation. Driven by protected assets, which is more predictable, and the platform decides what is worth keeping rather than you.
Effort to reach useful output Substantial: parsers, field mapping, content, tuning and ownership of every rule. An untuned deployment produces volume, not detection. Much lower at the start, because the detections come with the sensors, and correspondingly harder to inspect or modify later.
Coupling to a supplier Deliberately loose. Sources are replaceable, and the correlation content is yours, though it is written against your own schema. Tight, and that is the same property as the integration advantage. The detections work because one vendor owns both ends.
What happens when a source is unsupported Someone writes a parser. It is work, and it is possible, which is why odd estates keep a SIEM. It stays invisible, and the gap is easy to miss because the console still looks complete.
What neither one provides Analysts, an on-call rota, an agreed containment mandate and the authority to disconnect a director's laptop at 02:00. The same. Automated containment still needs a decision beforehand about what may be contained without asking, and who answers for it.

In full

The argument, at length

A SIEM and an XDR platform are usually described as alternatives, and are usually bought for different reasons. The SIEM’s defining property is that it will accept almost anything: appliances, business applications, other vendors’ security tools, systems old enough that syslog is the only interface. It normalises all of it to one shape so that events from different domains can be correlated, and it keeps the result long after any alert has been closed. In many organisations that retention is the real reason it exists — the detection content is genuinely useful, and the auditor still arrives asking for two years of access records.

XDR starts from the opposite end. It is built around sensors its own vendor operates, most often on endpoints and increasingly across identity and cloud services, and it trades breadth for depth. Because it owns the sensor, it can hold a complete process ancestry, ask the host a follow-up question after the fact, and act — isolating a machine or killing a process through the same agent that raised the alarm, with no console change and no handoff in between.

The trade is not subtle, and it should be named plainly: the integration advantage and the lock-in are the same property. Those detections work well because one supplier controls both the sensor and the analytics, which is exactly why the content is harder to inspect, harder to modify, and not portable when the contract is renegotiated. Meanwhile a source with no supported connector stays invisible, and it stays invisible quietly, because the console still looks complete. A SIEM’s equivalent weakness is inverted: it can take that source, but only after somebody writes the parser, tunes the content and owns the rule, and an untuned deployment produces volume rather than detection.

Neither product creates a response capability. Automated containment presupposes an agreed decision about what may be isolated without asking a human, and someone accountable when that decision is wrong at two in the morning. An alert nobody is rostered to read is not detection, whichever platform raised it. Most estates end up with both — depth where the sensors reach, breadth and retention for everything else — and the useful procurement question is not which one wins but which specific sources, techniques and retention obligations each one leaves uncovered.

Choosing

When each one is the right answer

Grouped by subject rather than interleaved, and every subject has cases of its own — required by the content model, because a comparison in which one side never wins is an argument dressed as a comparison.

Choose Security information and event management (SIEM) when

  • Retention, audit and a heterogeneous estate

    When evidence has to survive for years, when auditors ask for control testing across many systems, or when important sources are legacy or third-party, the vendor-neutral collector is the only tool that can answer.

  • Detections have to cross domains no single vendor owns

    Correlating a building-access record with a sign-on and a database query needs a platform that will accept all three, whoever supplied them.

Choose Extended detection and response (XDR) when

  • A small team that needs detections working this quarter

    Where the estate is mostly endpoints, identity and cloud from a supplier you already run, the sensor-native detections and one-click containment buy capability faster than any content-writing programme.

  • Containment speed is the binding constraint

    When the gap that hurts is the minutes between an alert and an isolated host, acting through the same agent that detected the behaviour removes the handoff that consumes those minutes.

Sources