The cyber security industry likes acronyms. There, I said it. In fact, if you can go a day as a cyber security professional without using one of the industry acronyms, I would say you were on vacation. In the wildness. Outside of cellular coverage. With your phone off. The reality is though, that they save us time when we are discussing concepts or technologies. Who wants to say “security information and event management” instead of “SIEM”?
The real challenge for the industry is when new acronyms begin to emerge. There is often a rush by organizations to claim and define them, and to showcase their unique “take” on the concept. This is what makes the industry great, but it can also make it very confusing. One such term – XDR – appears to be the next addition to the infosec lexicon. But it also seems to be a bit of a Rorschach test, with the definition changing based on the people talking about it.
XDR – What Does it Stand For?
One of the most crucial elements of an acronym is its expansion. This allows people to translate the individual letters into the full term. This is the first challenge with XDR, as the expansion depends on who you ask.
Some organizations define XDR as “eXtended Detection and Response,” but this isn’t universal. Other prominent organizations have expanded the term to mean “cross-layered detection and response.” That major industry players can’t seem to agree on a definition is something of a first.
Of course, because there is dispute about the expansion doesn’t mean that the XDR category isn’t important. It does, however, highlight that there seems to be confusion about it. The confusion doesn’t stop at the expansion though. Even the definition of XDR is a bit confusing.
The Definition of XDR
The next challenge with any new term, and XDR in particular, is its definition. Whether we are discussion Aristotelian philosophy or new technologies, it is important to define “what is it?” A good starting point for the definition is an organization like Gartner. They define XDR products as
“…a SaaS-based, vendor-specific, security threat detection and incident response tool that natively integrates multiple security products into a cohesive security operations system that unifies all licensed components…”
The challenge with such a definition is that it doesn’t provide a cut-and-dry definition. Rather, it lays out a few pre-requisites in that it must be SaaS-based and vendor specific. It also alludes to a “threat detection and incident response tool.” But, it doesn’t define what that tool is, per se. EDR? EPP? NIDS? By this definition, almost any security tool used for IR could fit that bill. The requirement also doesn’t say that the tool requires an “active” response component.
The definition also mentions that this tool also “…integrates multiple security products into a cohesive security operations system…” but doesn’t go beyond that in defining what tools they should be or how they should be integrated. This leads to the question what capabilities an XDR tool provides. While such a distinction may sound unimportant, I continue to see disagreements abound on social media. These instances see people arguing about what, at a minimum, constituted XDR. Some argued it should include CASB, IAM, or EPP. Others saw it as just EDR and SOAR.
These ongoing disagreements highlight that even the definition of the term XDR is in flux. Another interesting point is that many of those disagreeing never mentioned it had to be from the same vendor. This opens up the possibility that perhaps XDR is actually a capability rather than a specific technology.
Technology or Capability?
One of the most interesting discussions I could find on the topic of XDR related to whether it is a technology or a capability. Of course, taking the Gartner definition above would seem to state that it is a technology. After all, it must be both SaaS-based and vendor specific. But, if you remove those two elements, the concept of XDR seems to be more of a capability. For instance the consensus seems to say the necessary IR tool is EDR. The integration capability can be had through SOAR. Other log sources will likely need a SIEM. Beyond that, it will depend upon the technologies an organization has.
So, if an organization has EDR, SOAR, and SIEM, even from different vendors, and have integrated them, it would seem like they have a type of XDR. Now, they may not have the homogeneity that a single vendor provides. But at least in the spirit of the definition, it would seem that this should qualify as XDR.
If that is the case, then one could argue that XDR is more of a capability than a technology. Indeed, XDR might even be an end state for security operations centers (SOC) everywhere. A collection of security tools that pass data back and forth to make the analysts’ lives easier and response faster.
XDR is an interesting case study within the cyber security industry. The term, and indeed the acronym, appear to be in flux, with many trying to define it and mold it to their offerings. However, what is more interesting is that XDR might not be a specific technology at all. Instead, it could be a capability goalpost that security operations centers have been demanding for a decade or more. A goalpost that would see technologies and controls that are better able to communicate amongst themselves.
Too many products in the cyber security market are technological islands unto themselves. This is a huge problem with security operations teams as it means that analysts are often relegated to being a “human API.” The analysts act to pass data from one device to another. This type of inefficiency can lead to analyst burnout.
Now, not every vendor can provide a full XDR ecosystem. And that is, frankly, ok. But the push towards XDR is also going to push engineering teams to make their products more integrate-able.
That integration is going to be key to solving the problem SOCs and analysts have been complaining about. And it is going to make them better able to detect and hunt in their environments.
And that is going to be a cool future to live in…