What XDR Means for the Modern SOC
Analysts, SOC teams and security teams have been frustrated by the limitations of MSSPs for a long time. XDR represents the opportunity to approach security operations in a better way.
The old way of doing things was that the customer sent the MSSP alert data. The MSSP did stuff with it. It was a simple value proposition.
The reality was that the customer sends the MSSP a ton of garbage. The MSSP can barely sort out anything useful from what customers send them. That means security teams find the most incidents from users calling in and saying, “My machine is behaving weirdly,” rather than from the actual MSSP monitoring program.
The status quo is not working. And what that status quo has been doing is putting eyes on the glass where the human meets the data in a raw log format. We’ve got to change where human meets data to be effective. The data is going to continue to grow exponentially. We need to find the right interface point. That’s going to be where we’ve put enough intelligence, analytics and processing into that data so that it’s meaningful to a human investigator. Right now, humans operate at the alert or event layer. We need to be operating at the situation layer. There are a manageable number of security situations that occur if we only knew they were happening.
Slashing through the security stack
Today we announced the capabilities and availability of the Respond Analyst XDR Engine, the industry’s first vendor-agnostic XDR. That means security teams can leverage the tools they already have today, providing integration across their various security products (including best-of-breed solutions from Crowdstrike and Palo Alto Networks) into one platform with little effort.
First, a little background. Gartner has said XDR is an outgrowth of EDR. I don’t agree with that. And frankly, the R part of XDR is not entirely accurate. People are not doing invasive remediation actions on systems. They certainly aren’t doing them on production servers. Their CIO and CSO would fire everybody involved in that decision – and rightly so. Where they’re differentiating is on the D part of XDR. And the R part, the response, is what is possible via integration with a SOAR and downstream acceleration of response actions. The X part of XDR is saying we need to solve the detection problem. Currently, that’s human monitoring, which is not working. So, algorithms, math, and machine learning are the way forward.
Digging into the data
But some tools do work better.
Using a data science-driven approach and the large amount of historical customer data we have means we can see which tools are responsible for the best and most detections, and which work together more effectively. Digging into the data is the future of the world, and we are the ones doing it. If you don’t have data science, you can only have opinions based on limited experiences.
Our XDR uses Bayesian reasoning and advanced mathematics to deliver a much richer way to think about the data. It takes exactly how a human would do long-tail, deep investigative analysis, and puts it into the software. It ingests data from your diversified sensor suites from all your vendors, integrates it, analyzes it, and effectively detects incidents that are likely worth investigating.
We can do this algorithmically because as all of our customers resolve incidents in their UI, they give us automatic feedback on that incident before it clears. To incident clear their queue, they’ve got to give us feedback, and we plow that feedback back into supervised machine learning. This approach to crowdsourcing supervised machine learning across our entire customer base means everybody benefits from everyone’s data. It’s a win-win for the entire industry.
How the Respond Analyst XDR Engine delivers value
SOC analysts are probably the biggest winners in this scenario. Analysts, at the end of the day, are detectives. They’re trying to piece together the storyline of an attack by looking at the evidence. But the evidence is overwhelming. It’s got tons of examples; there’s tons of nuance. How do you stitch those things together? How do you connect the dots? Typically, we use SIEMs to do it, but they can only correlate a small number of things.
SOARs can do some form of enrichment, but again, you have to put a lot of development time and maintenance into making them work. And most companies are using SOARs more for gathering additional context than for downstream incident response acceleration.
The Respond Analyst XDR Engine is the only XDR solution that provides insight into how security controls are working. Our XDR Engine provides the flexibility to use data science models that work out-of-the-box with the tools already in the environment to extend detection and response depth. This means there are no playbooks, coding, or maintenance necessary. It frees analysts from the console to become a more detective and effective team and to perform higher-value security functions.
Ultimately, our vendor-agnostic approach to XDR enables you to have data to determine which are the vendors and tools you will want in your kit. And that lets you choose best-of-breed tools. When you do invest in a tool that doesn’t wind up delivering value, you can remove it and choose the thing that’s working – and you’ll have data to support that decision.
