If we define XDR as a solution, SOCs can’t reach their ultimate destination because, as a solution, XDR can’t be a holistic approach
Extended Detection and Response (XDR) is the latest buzz word in the security industry and, as with any new technology development, in the early days there is a lot of confusion. Industry analysts each have their own definition. Meanwhile, security vendors are quickly jumping on the bandwagon, recasting their products as XDR solutions and spinning up their own definitions.
Here is the problem…XDR is a destination, not a solution. Let me explain.
Unpacking XDR
Let’s step back and consider that the primary objective of today’s security operations centers (SOCs) is to address the detection and response use case. But the challenge is that on average organizations have more than 45 different security tools that for the most part don’t talk to one another, and they have teams that don’t work together. The promise of XDR is to enable detection and response across the enterprise, which requires ALL tools and ALL teams working in concert. How do you go from your current state to reach this destination? The promise is there, but the operational reality looks very different if you try to approach XDR as a solution.
Industry analysts have started writing about XDR, with widely differing definitions. Some state that XDR is vendor-locked and a cloud-based solution. Other analysts say XDR solutions require and build off of Endpoint Detection and Response (EDR) solutions. And some also claim there are different variations of XDR solutions using terms like native, open and hybrid amongst others.
If the goal of XDR is to have detection and response across the infrastructure, across all attack vectors, should it be limited to only one vendor, only cloud? Yes, EDR is important for XDR, but so are SIEM, network detection and response and cloud security tools. Integrations with these tools, and others, are critical to truly have XDR. Does it matter what technology is the starting point? When we talk about XDR as a solution, it results in confusion.
An Architectural Approach
Going back to the challenge of SOC optimization. SOCs are trying to become more efficient and effective and to accelerate detection and response across the enterprise by getting their tools and teams working together. This cannot be achieved if you look at XDR as a solution. Instead, XDR must be a holistic, architectural approach. An XDR architecture needs to include tools across different vendors; systems that protect at various enforcement points across your surface area of attack; security technologies that are cloud based and on premise.
Over the past few years, we’ve seen a movement towards the construct of a single security architecture to accelerate detection and response. In 2016, John Oltisk of ESG defined and started using the term Security Operations and Analytics Platform Architecture (SOAPA) which includes a common distributed data service, a software services and integration layer, an analytics layer and a security operations platform layer. Today, Oltsik notes that “in ESG terms, XDR qualifies as a SOAPA.”
If we define XDR as a solution, SOCs can’t reach their ultimate destination because, as a solution, XDR can’t be a holistic approach. Organizations will end up with multiple XDRs from multiple vendors that still need to talk to one another, and security gaps will continue to exist for threat actors to exploit.
However, when XDR is defined as an architectural approach that enables organizations to put all the pieces together, the promise can become a reality. Teams can work together, using the tools they are comfortable with and extending their capabilities with additional, integrated solutions for an end-to-end approach. It doesn’t matter where an XDR platform architecture starts from, and full rip and replace is off the table. SOCs can chart their own course and reach their destination of accelerated detection and response across the enterprise.
What do others think?
