XDR Requires SOAR In Enterprise Environments

Do you trust your Endpoint Detection and Response (EDR) Vendor to modify your network infrastructure? …I’ll hold your beer while you think about it.

“Your Scientists Were So Preoccupied With Whether They Could…”

EDR is an interesting place to begin exploration into what automated response capabilities we should expect from Extended Detection and Response (XDR), especially as there’s so much discussion around XDR having evolved from EDR. In terms of response capabilities, EDR started with the ability to blocklist executables and kill processes. From there, we started to see network isolation capabilities and then eventually full on shell capabilities to script your own response actions. What’s interesting about this evolution is that we went from killing processes and deleting files, basic endpoint protection capabilities, to live response and pushing down executable scripts very quickly. Response actions just aren’t that differentiable. In my last EDR Wave I ended up scoring about everyone the same for response capabilities and the most differentiated capability in the evaluation was Microsoft who even offered an “undo” button. But riddle me this Batman… why would you need that and would it even work?

Actions Have Consequences and Infrastructure is Complex

What’s interesting about the evolution of response capabilities with EDR is that they were executing in a single control plane (on endpoints) where there was an agent installed (homogenous environment), and they very quickly built a SOAR-lite capability. The reality of the situation is that security professionals could only get themselves in a limited amount of trouble with EDR response actions, changes were contained to the systems they were changing. It’s important to understand the following points around allowing security personnel to make infrastructure changes, before a rookie mistake takes your company offline faster than a ransomware operator:

• Native XDR is More About Having a Platform Than Requiring One. Once you hit enterprise scale, there’s no such thing as a homogenous, single-vendor environment. Believe me I wish this wasn’t the case. There’s nothing I’d love more than to have everyone buy all our stuff so I could turn off my laptop and go live in one of those tropical huts on stilts. The reality is that as organizations get bigger, there’s more and more creep. There’s products that came in through acquisition, there’s products that your predecessor selected, there’s product diversity as a byproduct of being a multinational with somewhat autonomous regional management… you don’t get to choose your own adventure. Interoperability must be a core tenet of XDR.
• Orchestrated Change Control Provides Security The Ability To Break Glass. Two critical components of change control are authorization and auditability. When I conducted my EDR Wave in 2020, only one participant didn’t generate an audit log of response actions, so you have to assume auditability is table stakes… but what about authorization? What about the sanity check of having someone who is responsible for managing the architecture looking over your shoulder and saying, “yep, that’s ok to do and not going to cause an outage.” The key is to have not just auditable processes, but orchestrated and audited processes, to safely increase the agility of your security operations team.
• Orchestration Itself Is A Necessary, But Not Sufficient Solution. The industry as a whole has started to recognize that to scale the future of security operations, and stop our adversaries who are now automating against us, we need the entirety of SOAR capabilities to sit on top of the analytics we are getting from XDR solutions. Smaller XDR vendors simply aren’t going to have the engineering capability to build market competitive XDR and SOAR capabilities, so expect a lot of discussion of orchestration capabilities as part of their XDR solution that will be unable to compete head to head with a dedicated XDR and SOAR capability.

In The End, We’re Not Far From The Original Vision for EDR

Endpoints are incredibly complex state machines. There will be arguments made that because execution happens on the endpoint that limiting response actions to the endpoint (which already exist through EDR) and/or disabling users is the correct method of responding to eliminate a threat. The challenge is that every application executing on an endpoint represents its own complex state machine to the extent that killing a process is largely impossible to “undo,” so we’ve basically exhausted what can be done on an endpoint.

Part of the magic that makes XDR such a phenomenal next step in threat detection is the byproduct of stitching a multitude of telemetry sources together, to enable a singular view of your infrastructure. By stitching telemetry together, you’re able to run better analytics and obviate the need for a lot of the tuning that goes into SIEM management. With this benefit comes added complexity. The ability to manage firewall rulesets based on network architecture isn’t something you should expect from an EDR vendor, as most organizations require firewall management software to deploy and optimize their firewall rules. EDR type response is critical for XDR, but I’d expect these response actions to be exposed via API so your SOAR can take advantage of the control point. But before we start trying to build SOAR capabilities into our XDR platforms, doesn’t it just make sense to keep XDR vendors focused on developing the best detection capabilities money can buy when we already have dedicated enterprise level capabilities for orchestration, automation and response with SOAR?

This eventually leads to an interesting conversation I had with Dr. Anton Chuvakin at RSA last year (2020) about the Network Detection and Response (NDR) acronym and how much I didn’t like it because there was no actual response capability. His response was that in his original vision for EDR, the response was investigation, not response actions. In understanding the requirements of the enterprise security operations center (SOC), we should take a moment and instead of asking whether response actions can reside within XDR, instead ask the question — should they?