SIEM or XDR? Yes

In my last blog, I asked where XDR fits into the SIEM-less conversation. To answer that, start with the endpoint. If every threat could be stopped there, there would be less need for detection and response products such as endpoint detection and response (EDR). But attackers got better at evading even the most robust endpoint security, for example by abusing dual-use tools in living-off-the-land (LOTL) attacks. That forced the industry to pivot toward a “collect data and analyze” approach, which is the entire premise behind EDR and where the SIEM-versus-XDR story begins.

From EDR to XDR

EDR effectively became a cloud-based store of endpoint data. To make that data actionable, a lot has to happen:

• Data must be correlated to surface threats and generate alerts.
• Alerts must be prioritized, triaged to confirm they are true positives, and managed.
• Actions must be taken to disrupt threats, with automation and playbooks for repeatable patterns.
• Data must be searchable as investigations progress, and reports must be generated.
• The system must integrate with IT service management (ITSM) tools to fit into operational processes.

Attackers also target multiple entry points and move laterally once inside. So, the industry rightly concluded that threat detection and response become far more insightful and effective when endpoint data is combined with data from other threat vectors and sources such as network, identity, cloud, and email. The result was a purpose-built, integrated system focused singularly on security outcomes rather than on the endpoint alone. EDR evolved into extended detection and response (XDR).

Same logs, two places, overlapping outcomes

If you have EDR, you most likely have a security team handling triage, investigation, and response, and very likely a SIEM as well.

At a minimum, a SIEM handles data ingestion, analytics, alert management, investigation, and response. If that sounds familiar, it is because that is exactly what XDR does. The SIEM is the original detection and response platform, the forerunner of every “DR” product, but it is neither cost-efficient nor easy to maintain. So why do organizations run both and pay twice? In most cases, the reasons are astonishingly simple:

• “If it ain’t broke, don’t fix it.”
• Other projects take priority, and taking this on would leave no one for anything else.
• Almost every auditor asks for a ‘SIEM’, and some may even use the word ‘SIEM’ as a generic term.
• The SIEM is an established budget line item (most likely due to the previous bullet).

To be fair, there is one legitimate reason XDR and the SIEM co-exist, and it is the endpoint. For a SIEM to fully overlap with XDR, there must, by definition, be an endpoint, and the SIEM depends on an agent to supply it. The industry differs on what that agent looks like. It could be a complete endpoint agent with superior built-in protection capabilities, or a detection-focused sidecar agent that runs alongside an incumbent protection solution and forwards alerts and telemetry to an XDR or a SIEM.

Is XDR really a SIEM by another name?

Yes, it is. EDR was essentially an endpoint-focused mini-SIEM, and XDR extended it into a security-focused SIEM. The industry rebuilt a tool that already existed but aimed it at security outcomes instead of overloading it with every use case imaginable. Unshackled from the ossified architecture of a traditional SIEM, XDR came out ahead.

What makes it better?

Most importantly, XDR ingests only the data used within the threat lifecycle, and it does so through out-of-the-box integrations. That data is pre-curated by the vendor’s security experts to produce specific security and operational outcomes, such as relevant detections or contextual information. XDR then gives your security team or SOC every capability it needs to triage, investigate, and respond. In a SIEM, by contrast, anything goes. As I covered in my “SIEM-less” blog, customers save data “just in case.” Here are a few real examples of what ends up in a SIEM:

version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status

from __future__ import unicode_literals

[DllImport("wtsapi32.dll", SetLastError = true, CharSet = CharSet.Unicode)]

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

Every one of those entries was ingested into a SIEM, and in SIEMs that charge by ingestion, every one of them may well have been paid for. None of it helps a security team detect, investigate, or respond to a threat. That is why curation matters. This is why it matters who does the curation. Who carries that operational burden?

Should you buy a SIEM or XDR?

Start with a few questions.

So, SIEM or XDR? Yes. XDR is a SIEM rebuilt for security outcomes, which means the real decision is about capabilities and economics. With your answers in hand, weigh the opportunity cost of each path: replace your SIEM, buy a SIEM-less SIEM, adopt XDR, or keep both and narrow the SIEM to non-cybersecurity use cases. Then balance that against your organization’s needs.

So, where does the agentic SOC fit into all of this? More on that in my next blog.