deobfuscate: XDR

Extending Your Visibility and Your Alerts

Extended Detection and Response Platforms, or XDR, is a technology that was coined by Palo Alto Networks CTO, Nir Zuk, in 2018. At the time, XDR was developed based on their TRAPS endpoint protection platform (EPP). Since then, Gartner has described the technology as the following:

A SaaS-based, vendor-specific, security threat detection and incident response tool that natively integrates multiple security products into a cohesive security operations system.”

As with any technology evolution, XDR spins off the Endpoint Detection and Response (EDR) toolset by adding a layer of analytics on top of additional datasets that form and aggregate information into a singular ‘friction zone’. There is a lot of technical garbage to unpack with that statement, but basically, dump all your logs into one place (as long as it meets the data model requirements) and perform some telemetry and analytics upon them to define when bad stuff happens.

How Does XDR Work?

XDR works in a simplistic architecture, as depicted in this image I mustered together. Here we can depict that a variety of data can be fed into the Data Lake which XDR sits on top of. XDR then performs analytics and telemetry. A good XDR is going to do ‘data stitching’ which is another unique term. This process essentially takes the correlation searches we are used to the next level, where we identify two or more unique data sources, say endpoint and network, then translate transactions between them that are relational. These can be as simple as recording timestamps or joining based on something like a DNS record, to more complex methods that involved trained AI/Machine Learning models to predict and detect these datasets and stitch them together when they are related to the same transaction.

What does data stitching accomplish? It fills in the blank for us. Traditional investigations that leverage EDR, NDR, SIEM, and other toolsets tend to have us build the story manually. We have to work on gathering data from different tools, or different datasets/models in our SIEM, then slowly aggregate the data through manual analytics and storytelling until we reach the point of conclusion in our investigation. This stitching process instead allows us to circumvent some of that manual story building we have to perform, so we can more efficiently reach a root cause. This ultimately leads to lower MTTResp and MTTReso, because the tool is doing some of this lifting for us.

In addition, XDR should be aggregating our alerts for us. This works in a similar manner as data stitching, but essentially your XDR shouldn’t just be plastering you with alerts. Instead, these alerts should be effectively fed to you via some time of aggregating method. Whether they are joined together under an incident pane for you to work with or some other means, we shouldn’t just look at a list of alerts and go off chasing them into the night. What this does is reduce clutter, and feed all related alerts, usually a chain or sequence of events that XDR detects, into a single pane of glass that allows us to operate more efficiently. Even better XDR tools will build casualty chains for you and map out to the MITRE ATT&CK Framework. Again, this results in a lower MTTREsp and MTTReso.

What XDR Is

XDR, in summary, is a cornerstone between SIEMs and EDRs. The reason is that they aggregate data for us to a singular ‘data lake’, then perform some level of correlation upon that data to present to consumers. Their design is simplistic and displaces your old EDR/EPP tool in favor of a more integrated solution. The effect of this is to reduce tool bloat, have a more uniform approach to incident response, and improve visibility and telemetry across your security stack, and across your enterprise no matter the vendor sticker (usually). XDR operates under the premise of displacing your current EPP or enterprise antivirus solution by providing a baselayer prevention capability, then building EDR functions on top of it so that it becomes a holistic solution. All XDRs, for better or for worse, are EDR tools first.

As we expand the scope though and introduce network visibility, XDR can also displace Network Detection and Response (NDR) tools, or at least integrate with firewalls and other platforms to pull in network data. This level of integration gives us the ability to pull together stories within a single platform, allowing us to more easily pivot between our datasets rather than fumbling around with a complex search trying to manually piece together a timeline and actions on objectives.

Finally, XDR can incorporate some seriously strong User and Entity Behavior Analytics (UEBA). The reason being is when you give a tool all the visibility in the world, you have a wonderful dataset for statistical, pattern, and behavioral analysis. What this gives us is an immensely powerful system that allows us to define what is and isn’t normal and detect it faster so that we can resolve it sooner.

Theoretically, as XDR grows, so too won’t the ability to ingest more and more data from a variety of sources. This means more robust analytics across the board, but this will take some time to flesh out as it is still mostly in its infancy, relatively speaking. This also includes the expansion of SOAR capabilities within the platform, and more direct actions in our environments, including management of assets (think hardware and software inventory, disk encryption, data loss prevention, firewire wall enforcement, etc), forensic analysis, vulnerability management, and a slew of other tools and functions that can make XDR become its own thing.

What XDR Isn’t

In its current state, XDR does not replace your SIEM. As we progress and follow along with the ‘modern SOC’ model that constantly changes with each new revolution/evolution of technology, SIEM will continue to be a staple for the foreseeable future. This is because we need somewhere to store, retain, and utilize logs for a prolonged period, with many organizations opting beyond minimum standards of twelve-month retention, and moving towards eighteen to twenty-four-month retention. XDR is a great technology, and many vendors allow for the scaling of their ‘data lake’ to consume a virtually infinite amount of logs, however, it isn’t cost-effective yet to allow XDR to assume this role, and you’ll be spending exuberant amounts of money to retain data. Instead, many XDR platforms, even if they’re SaaS-based, are allowing the offloading of data, usually for an additional fee, to a SIEM resource that can retain data for longer and for cheaper. I don’t expect this to remain this way forever, but until vendors learn to reduce cost or allow on-prem deployments that let end users define consumption and retention costs more directly, we will see this model be used.

XDR also isn’t a replacement for many of the tools that specialize and function specifically to manage something like DLP, UEBA, etc, unless that platform explicitly has a feature set that performs that functionality. This is vital to note, as XDR likes to do a lot of things and thus has become a mile-wide and inch-deep tool for many functions beyond bridging EDR and SIEM gaps together. No one tool is perfect for every job, so don’t overcompensate XDRs functions to meet the needs that another tool can do better.

XDR and the SOC

XDR is a SOC tool, first and foremost, but as its capabilities sprawl and feature creep, it quickly devolves into needing multiple teams to manage. This makes deployments in enterprise-sized environments complex, but not impossible. Establishing a process to test and integrate technology should be something that comes naturally to big organizations, and if not, I just feel sorry for the team that’s gotta fumble that deployment.

What XDR does introduce for the SOC, however, is a very robust tool that gives analysts and engineers the ability to work directly with data while also reducing the amount of time they have to spend messing with the data. What I mean by that is a good solution will make it easy and present what it knows directly to you, without having to chase it around. And when you need to work with that data, it is malleable and not stuck in a format or hidden in a place that can’t easily be retrieved from. This is where XDRs merge into the SIEM space. Usually, you get at least thirty days of data retention in your data lake, so you can work with the data on the spot and without issue, or worst case, it’s offloaded to a SIEM or you bought extra retention in the cloud. This also allows for XDR to build most casualty chains very well for you because it has access to that data as well, painting a beautiful story for you. Even when it doesn’t, and your due diligence pulls out additional information and connects more dots to find a bigger breach, XDR helps you achieve that visibility, even if the analytics didn’t detect it.

Ultimately, this technology is arguably a must-acquire for the vast majority of organizations looking to beef up their defense game with a toolset designed to reduce the burden of manual investigations and having analysts run around on wild goose chases to locate data, assemble it, and produce a story that leads to an accurate representation of what actually happened. In addition, it’s just a darn good way to prevent a large portion of the easily catchable attacks that would otherwise leave you exposed and hacked. Even better, XDR is Zero-Trust ‘certified’ 99% of the time, so using it can help enforce zero trust in your organization.

On a final note for my technical people out there, I highly recommend some additional reading material for you to review on what would be a good XDR platform to run, simply by checking out the MITRE ATT&CK testing results that put the brightest minds in cyber threat research against the best the cyber defense industry has to offer.