Back to perspectives
What is covered:
- Brief XDR overview
- What functionality is real today versus what is promised
- Opportunity for Innovation: Root Cause Analysis
Brief XDR overview
In the last year or so, Extended Detection and Response or XDR has rapidly gained more attention and adoption. Gartner predicts that XDR spending will increase 96% by 2024, which is serious growth.
It’s understandable why XDR has come into favor as most CISOs will tell you that one of their biggest challenges is dealing with the monstrosity of alerts coming out of their existing security platforms. XDR has been marketed as a silver bullet to not only extend visibility of security tools (hence the X in XDR), but also condense and simplify alert prioritization through a single framework.
TrendMicro and Crowdstrike both have great explainer articles on XDR (linked here and here). As a visual person, the graphics that go along with their articles were a helpful way for me to wrap my brain around XDR technology.
The origins of XDR started with network detection and response (NDR) which enabled security teams to understand what is happening on their network and understand the types of attacks occurring there. Later, endpoint detection and response (EDR) emerged which was higher fidelity in uncovering attacks because it had an agent on the endpoint itself. Additionally, the network became more encrypted which made it harder for NDRs to have strong visibility.
Some people say XDR is just EDR enriched with data from other services (cloud resources, sensitive identities, unmanaged data). Some people will say combining NDR and EDR you can create new detections. Realistically, there is probably single digit overlap in things that come out of NDR and EDR, so if you’re treating XDR as EDR++ you’re missing things from the network that EDR wouldn’t see at all.
All in all, XDR’s strongest functionality is really allowing teams to find the needle in the haystack which is much needed. In a world where the SOC is overwhelmed with alerts, it’s helpful to have this “single pane of glass” that takes a risk-based approach and tells you what to deal with. Unfortunately beyond that, XDRs have not delivered on the promise to reduce the number of security alerts by finding overlap or even by simplifying the security team’s response workflow to problems.
What is real today vs. What is promised
Through conversations with security leaders, it seems the area of XDR that disappoints the most is Remediation.
XDR solutions have under-delivered on the automation piece. In an ideal world, the XDR platform would look at everything a security team could be doing, narrow it down to the highest priority action items, and then go out to perform the fixes. Platforms today are using ML to continually improve the “narrow it down” piece, but fall short on the response (“perform the fixes”) piece.
For example, customers complain XDRs can’t reliably perform relatively simple responses like quarantining a workstation with malware or blackholing an IP address on a firewall.
This may be because today, vendors stick a SOAR product on top of XDR and leverage existing playbooks for simple automations. It’s unclear how much time that portion of automations save.
Over the coming years, we can expect XDR to become better at automating more and more remediations. This will likely be the “low hanging fruit” remediations but any saved time is a win for SOC teams.
Ultimately, for more complex issues it is hard to see a world where technology is trusted to perform those remediations. There are huge consequences to a “fix” causing a problem, so we are far from machines being trusted to implement changes without human intervention. Everyone would like these automations to alleviate the burden of security workforce shortages, but the process for remediation is often complex and manual even with XDR.
Opportunity for Innovation: Root Cause Analysis
For security teams overwhelmed with tons of alerts from existing tools, getting to the root cause issues can drastically increase efficiency. In security, it’s often the case that the same root cause problem is triggering alerts from many different places.
Since XDR aggregates security data from multiple sources, one would hope that the platform could take advantage of the increased visibility and use ML to couple alerts from different tools together. Unfortunately, XDR functionality is not particularly strong when it comes to investigating the root cause issue. Most applications of ML in XDR today are focused purely on the prioritization of alerts rather than reduction through root cause analysis.
Some of the most exciting innovations in security in the future will be around developing models to find root cause issues quicker. The platforms that have the best chance of solving this are the ones that aggregate data from multiple security tools (better data beats better models). In an on-prem world, SIEMs pieced together data from disparate tools and had strong correlation engines for root cause analysis. In a cloud/hybrid/microservices environment, SIEMs that are built for the on-prem world are at a disadvantage and don’t always have the context necessary to do the best correlation. In the future, it may be the case that neither XDRs nor SIEMs have enough context to successfully explain most of the root cause issues.
XDRs and SIEMs may aggregate all of the security data, but is it in the right format? Is it usable? Specifically, both systems lack information on the existing configurations of resources. Without this context, it’s impossible for a security platform to understand how alerts may be related to each other. In a microservices world, configurations are changing by the minute if not by the second, so securing the system autonomously becomes significantly more difficult.
Startups and innovators that leverage graph databases to better understand microservices architecture are best positioned to perform root cause analysis in the future. Graph databases have picked up popularity in security as visualization layers, but there is an opportunity to leverage the technology to change how security data is captured and utilized. The models sitting on top of data stored in a graph format will be most powerful at solving the problem of root cause analysis and ultimately autonomous security. Lightspin has a great article here on how using graph databases to understand asset context in security is fundamentally different from the status quo in security. Similarly, two Costanoa portfolio companies have leveraged graph based analytics to solve challenges in enterprise authorization (SGNL) and data security (Cyberhaven). Cyberhaven has a blog post on the power of graph analytics for data protection.
Conclusion
In summary, I’m excited about the future of autonomous security but believe data needs to be captured and queried differently in order to make large improvements from where we are today. Thinking about building graph-based approaches to security or autonomous security? Please reach out to me at mckenzie@costanoavc.com or DM me on Twitter @McK_Parks.
