Demystifying XDR

 

These tools worked quite well in their respective silos in dealing with very specific scenarios. A firewall can detect suspicious traffic. An endpoint system will shut down a potentially malicious file. Email filtering can attempt to keep out phishing attempts. And your DLP (Data Loss Prevention) solution prevents invaluable intellectual property from being sent outside of the company.

 

The problem lies in the fact that none of these systems interact with one another. Not only that, more often than not, they are administered across different teams who likely don’t interact as often as they should – and certainly not in real time.

 

Along comes the System Information and Event Management (SIEM) solution. By ingesting logs from all of these divergent log sources; normalizing them to a like-for-like format; and then correlating them against one another; these systems are able to detect threats in near real time across different technologies and vendors.

 

The system can be operated by a single team and can detect events across platforms. However, SIEMs require substantial care and feeding – particularly in relation to log source ingestion, use case creation, and, most of all, tuning. They have also (historically) lacked the ability to respond to threats in real time, providing only a detection capacity.

 

Now we have Extended Detection and Response (XDR) which Gartner describes as follows: “a SaaS-based, vendor-specific, security threat detection and incident response tool that natively integrates multiple security products into a cohesive security operations system that unifies all licensed components.”

 

This entails a vendor offering a number of different, essential solutions, that report into – and can be controlled from – a centralized console. This is similar to a SIEM in as far as differing solutions being viewed within a single pane of glass, but different in that the systems being viewed can be interacted with directly.

 

For instance, a vendor may offer a cloud solution as well as firewall and endpoint solutions. All of these would report into their own centralized console, where vendor-provided detection content is applied to allow for focused analytics. This is advantageous as a single vendor is supporting all of these products, and ensures that their integration is incredibly streamlined.

 

Finally, an XDR solution will have the ability to take action – that is to respond to a detected threat. Suspicious traffic on a firewall? That can be blocked. Malware on a user machine? This can be isolated. These types of actions can be done either automatically, or with the intervention of security personnel and present a massive advantage in time to respond to ongoing threats.

 

Whereas a Security Operation Center (SOC) would have to validate the data, review with appropriate groups, and determine who to contact to ‘push a change’ – a properly configured XDR solution will perform all of these activities automatically. This not only saves on overhead in relation to staffing, but it drastically reduces the time a potential threat actor may have within the network. This holds the obvious advantage of enabling a seamless integration between different products, all supported under a single vendor, operating in tandem. While all of this looks great on paper, there is a problem: supporting other products outside of the vendor portfolio. In the above example, the vendor supports cloud, firewall, and endpoints – but what about data loss prevention, user behavior analytics, east/west network traffic, domain controllers, etc.

 

This creates a gap in visibility that can present obvious security concerns. The solution is to integrate these devices into either a SIEM for monitoring, or to have them individually monitoring parts of the security stack on their own. Both solutions require additional investment in other technologies, training, and personnel.

 

So what is the answer? There is no magic bullet for security monitoring. While XDR is a very viable alternative to a SIEM solution, it does not do enough alone to cover the entire security stack. A modern SIEM can cover a huge swathe of supported devices natively, but requires a lot of tuning and care to remain relevant. So far as response functionality, most SIEMs now support response actions via API calls to the devices being monitored – as with XDR, these can be manual or automated. However, since these are not as streamlined as they would be in an XDR stack, they can get clunky and error prone if not properly configured and updated.

 

Your final choice is likely to come down to two areas: cost and staffing. If a customer has a great relationship with a particular vendor, and a team of people already trained and comfortable with their products, an XDR solution is likely the best choice. The user will realize cost savings by bundling products together under a single banner, as well as savings in training and staffing for already supported products.

 

If a customer does not want to be ‘vendor locked’, wants all of its data in the same place, and is comfortable training staff, then a SIEM is the likely best choice. This is especially true now that SIEM vendors are including response actions to their arsenal in response to the growing competition coming from XDR.