XDR, What am I Missing?

At the root, it's not difficult to understand the premise. For years, AV was adequate to protect workstations and servers, constantly battling back against the latest attempted malware attacks, but threat actors evolved, and it became increasingly obvious that we needed more than just traditional AV, hence "next-gen" AV was born, largely dispensing with dependencies upon specific malware signatures and instead relying on process evaluation to classify malicious code and prevent harm. That was pretty good until threat actors evolved (<---note common theme).

Along came Endpoint Detection and Response, riding on the coattails of the behavior analysis that next-gen AV ushered in, EDR further enhanced capabilities by leaning on FIM and UEBA to recognize entire IOCs and kill chains that AV simply couldn't. It also began to offer some countermeasures in terms of response offerings like endpoint isolation, and now various SOAR capabilities. Meanwhile, security practitioners recognized that while EDR was quickly becoming as necessary as AV had been for years, that endpoint information alone really needed to be correlated with other security data to be most effective.

All of this happened at a time where the future of SIEM seemed a bit up in the air, mostly because the cost of running one internally (~5 FTEs for a 24x7x365 SOC), plus the cost of the tool priced it out of reach for many organizations. It is also noteworthy that internal SIEM implementations, in places that don't have a very large SecOPs team to care for and feed them, typically end up in at the inevitable maturity level of "I think we are close to getting it to do what we need". Spoiler alert: They probably aren't. Internal SIEM implementations are often a series of False Summits.

Enter XDR, the idea that EDR providers can go beyond the Endpoint and provide the ability for their SaaS platforms to ingest additional data beyond just endpoint. Thus, we get the variable "X" stuck onto the front of the abbreviation to indicate that "we do more than just Endpoint". And here we get into the crux of the current issue in the market. XDR doesn't really have a common definition or minimum set of requirements. You need only bring in at least one more set of telemetry beyond endpoint.

"X" implies Extended, so you know that you have to be getting more than just endpoint telemetry, but that's about all you can say based on the term "XDR" alone. Go try to line up features and capabilities between "XDR" providers and you will find that they are all different. That begs the question, how should I evaluate XDR to understand what capabilities matter? I think that question completely depends on your approach to evaluation.

Typically, XDR evaluation starts with research and demos and then decisions are made based on how it looks when demonstrated, possibly a few questions that are thought of during the demo and then requests for quote, etc. Often there are no initial success criteria identified going into the evaluations and the choice is largely made based on the team's impressions and opinions formed during the demo/POC time period. Sometimes likability of the sales team doing the demonstration can play a role, etc.

I like to take a more "pessimistic" approach to evaluation. What I mean by that is I certainly want to dig into the primary features such as:

• Is pricing a la carte or all inclusive?
• What APIs are available for direct tool/SaaS integration for the other pieces of my operational and security stack (both on prem and SaaS)?
• For things that are not directly integrated, can I ship logs from them and if so, can I do custom alerting based on those logs? Do you charge for additional data ingestion separately?
• What endpoint agent(s) does it integrate with and does that integration include making use of the Response capabilities of my agent directly or will we have to manage it through its native portal?
• How many endpoint agents will I have to deploy and manage if I choose this solution?
• If the solution is managed, are your SOCs 24x7 or do you provide support via follow the sun method?
• What regular reporting do I have via the dashboard or canned reports that I can use to manage my environment and demonstrate value to my stakeholders?
• How do you alert and how do you build escalation profiles around that alerting?

And the list goes on.

While walking through all of the primary features and portal and reporting, etc. is important, asking some "pessimistic" questions is often telling. I make sure to ask questions that revolve around how my security team can work with the XDR provider and tools provided when the inevitable breach occurs. So, in addition to the "normal" questions consider these:

• Does your platform allow me to collect alerts and other telemetry into a single place for investigating incidents? This matters because a single threat actor infiltration can generate mountains of related data and if your only recourse is to talk to the SOC (internal or external) on an alert by alert basis, your ability to perform efficient containment and eviction will be compromised. You need the entire picture and an easy way to organize and track it. Make them walk you through the process when you have an incident and show you how the platform supports the investigation, containment and eradication.
• Does your platform have a way to submit tickets to your team for help when needed, either from a platform use perspective or from a need for investigative help in understanding the alerts that I'm seeing?This matters because communication during security incidents is a key piece to effective resolution. If you don't have a direct way to interact with the team, you will find it very hard to get answers that you need.
• Where will my primary SOC be, and will I ever be handed off to an entirely different SOC if we get to the end of a shift?This matters because shift changes in the same 24x7 SOC benefit from direct handoff of current incidents and tend to not suffer loss of investigation momentum. On the other hand, being handed off between time zones to entirely different teams can be problematic. Now let's ratchet up the importance of this in a case where the prior two questions were not answered satisfactorily. I would have no consolidated view into my investigation, no SOC tickets to refer to, and really no way to clearly communicate to this "new" team what I was dealing with. Think about the number of SOC switches you might be subjected to during an already stressful time, if things go really well and you only need them for a day or two. Now extend that to a week, and so on.

In summary, when evaluating XDR providers, please note that your mileage may vary on what they are capable of monitoring and at what costs. Look for wholistic, open platforms that provide extensive integration capabilities and flexibility. The goal is to get as close to single pane of glass as possible while not sacrificing efficacy (as defined by your success criteria).

And while it is good to go through demos and POCs, do so with established criteria that articulates what the organization needs from an XDR platform. Finally, while developing those criteria, and your questions, do NOT completely focus on all the shiny portal views and things that you might spend most of your time seeing day to day (when things are fine). Most of those are adequate. Instead, once verifying that the portal is adequate, and the solution will meet your technical criteria, spend a lot of time forcing the vendor to walk you through the processes for incident response and fully understand what the platform will do and how the interaction will flow when things are at their worst. Include all communication and investigation support and processes in your consideration.

Most of these platforms will be just fine so long as everything is fine in the environment and you are just working through normal events here and there, reconciling them, making necessary changes and mostly keeping a clean slate. However, when a full-blown incident occurs is when you really need the right tools at your disposal, with the right visibility to support the effort. The last thing that you need in the middle of an incident response is the realization that the "X" in your "XDR" solution is more variable than you expected!