Hooded Hacker Concept Image

Spotting Hackers at the Pace of XDR – From Alerts to Incidents

Extended Detection and Response (XDR) technology is gaining traction within enterprises. But how can organizations handle the increased volume of alerts XDR systems produce? In this Expert Insight*, Samuel Jones, Vice President of Product Management at Stellar Cyber, discusses how embracing incident-based systems can reduce the analyst burden of XDR technology, enabling companies to spot and respond to attacks more quickly.


Extended Detection and Response (XDR) systems cover the entire compute/network infrastructure, so they generate more alerts than security systems that focus on one area, such as endpoints, firewalls or servers. The challenge is knowing what to do with these alerts to enhance analyst productivity. After all, analysts can only deal with one alert at a time, and it often seems that they spend their days playing Whack-a-Mole with them. Moreover, there’s no time to consider alerts in the context of the overall infrastructure to spot complex attacks that trigger a host of alerts.

Samuel Jones is the VP of Product Management at Stellar Cyber

Recently, some security vendors have introduced the concept of “security incidents.” Incidents contain two or more alerts that correlate to a particular attack, and ideally each incident should show all the alerts triggered by the attack so analysts can quickly know where to look to study and remediate the attack. Incident-based attack reporting significantly reduces the number of indicators an analyst must pursue, and the best incident-based systems not only group alerts but prioritize them within each incident and then prioritize each incident by the level of severity. This way, instead of having to investigate each alert (and there can be thousands of them every day), analysts can focus on the incidents and component alerts that are most likely to harm the company’s infrastructure.

You might also like: Futility or Fruition? Rethinking Common Approaches to Cybersecurity

Naturally, there’s some AI involved in deciding how to group alerts by incidents, and in prioritizing alerts and incidents to direct analyst efforts. But AI is only as useful as the data being used to train it. The data comes from server logs, network scans, firewall logs, endpoint scans and other sources. To be effective, the data from these different sources must be normalized into one format before it can be understood by an AI engine. 

And beyond deciding which alerts belong to an incident and prioritizing them, AI (in the form of Graph ML) can further identify attacks by creating diagrams that show incidents and the component alerts. Such graphs show the progression of an attack and point to specific targets so analysts can quickly respond.

So, if incident-based information piques your interest, you should look for the following capabilities:

  • Data from all sources should be normalized at ingestion
  • Appropriate alerts should be collected into incidents
  • Alerts within incidents should be prioritized in order of risk
  • Incidents should be prioritized in order of risk
  • Graphs should map out the alerts in the overall system to show the progression of each attack incident.

(*) Disclosure: This article was sponsored by Stellar Cyber. For more information on how Security Ledger works with its sponsors and sponsored content on Security Ledger, check out our About Security Ledger page on sponsorships and sponsor relations.

2 Comments

  1. Pingback: As Mobile Fraud Rises, The Password Persists – Raymond Tec

  2. Pingback: Spotting Hackers at the Pace of XDR – From Alerts to Incidents | Ad Blocker Testing

We want to hear your thoughts! Leave a reply.

This site uses Akismet to reduce spam. Learn how your comment data is processed.