Part 1: XDR and the Return of Stone Washed Jeans

XDR and the Return of Stone-Washed Jeans

Remember stone-washed jeans? Well, they are back in vogue! (I don’t know about you, but I hated stone-washed jeans then and still hate them now.)

History has a way of repeating itself, from politics to fashion—and now cybersecurity has found itself in this loop. So, how did we get here and where do we go from here?

Enter Extended Detection and Response (XDR)

If you are in the cybersecurity industry, then you know that XDR or eXtended Detection and Response is the new black (or is it?) and the most nebulously defined cyber acronym in quite some time, if not ever. Extend to what? To whom? How far does it extend?

XDR has quickly become the “panacea” for all things related to detection and response, and every vendor has jumped to add those three letters to its product. But what we all still can’t decide is what “XDR” actually means.

Some are steadfast that it must be “born out of the endpoint,” while others simply say it must provide at least three of some well know control capabilities (endpoint could be one of them) along with an analytics backend. There is also a debate on whether it pertains to a single vendor’s technologies (i.e., Native XDR) or if it “extends” across a larger, multi-vendor ecosystem (i.e., Hybrid or Open XDR)? Hell, the industry can’t even agree if it’s “hybrid” or “open,” as “open” sounds like it could be “open-source.” And while this religious debate continues, the bad guys continue to prey upon our environments with blatant disregard for the category of tools or technologies we use.

XDR: Native vs. Hybrid/Open

For our purposes, let’s quickly review what the definitions are as they stand. Everyone agrees, at a minimum, that XDR must bring telemetry from disparate technologies together. Native simply means that the entire ecosystem in which XDR operates is limited to tools from a specific vendor, while Hybrid or Open XDR is defined as one that interoperates with technology from any vendor and is agnostic.

Sometimes it makes me wonder how much time people who define “categories” within this space actually spent as security operators. Was security one of their several roles or were they dedicated to fighting the good fight every day on the front lines? Surely, they know that most organizations do not go “all in” on just one vendor’s products? You might use a cloud control product or endpoint software from the same firewall vendor but what about identity management? What about external-facing applications and the web application firewalls used to protect them? Or your Secure Edge provider? Or your DNS infrastructure?

This is the reality for most, so how much value, precisely, does Native XDR add to the security ecosystem? Are organizations expected to run multiple XDR platforms? That should make for some great conversations come budget time!

But we have been here before. Vendors have tried this “one platform to rule them all” approach before and failed. Let’s take McAfee, for instance. Starting with their endpoint flagship product, they branched out to hold all our logs with their acquisition of Nitro Security (2011), a SIEM; control our network with the purchase of Stonesoft (2013); and help us secure the cloud with their purchase of Skyhigh Networks (2017). The promise was to bring it all together with a common protocol called Threat Information Exchange (TIE), which, unfortunately, did not end well.

XDR Should Focus on the Security Operators

Environments are not homogeneous, and our solutions can’t be, either. Organizations need the ability to leverage best-of-breed capabilities to protect their brands and assets. Most of all, they need a “unifier” that gives them the flexibility to invest in what best fits their organizational needs. They need an XDR solution that allows them to easily plug and play across the various vendor solutions as their organization evolves.

In your day-to-day life, would you buy anything that is not compatible with the other technologies you have already invested your hard-earned money in? Would you use a Gmail account if your iPhone did not support it? You might buy Sonos because of what it offers, but you want it to work with Amazon Alexa if that is what you standardized on. Surely, you will not buy everything that is made only by Amazon but you want a standard platform to support anything you buy.

The freedom of choice, the flexibility and agility to leverage what you want, in your house, is what XDR is about. It’s what it must be about—because if it’s not, we have failed.

We’ve failed to clearly understand the problem of the practitioners on the front lines. What XDR should focus on is delivering a security operations platform that will make it easier for the operators to do their jobs efficiently. The principles behind the concept are not in question. XDR has the potential to fulfill an important promise as an architectural concept, but the categorization is confusing the market.

In my next blog, I‘ll dive deeper into why I think XDR is an architecture, not a category, and how this will impact the future of the SIEM.