Using MDR to reduce alert fatigue
MDR services are configured to assume threats are already present and to hunt for them. Alerts are simply fragments of data that might indicate this.- Article authored by Kunal Chowdhury on .
MDR services are configured to assume threats are already present and to hunt for them. Alerts are simply fragments of data that might indicate this.- Article authored by Kunal Chowdhury on .
Alerts are the basic unit of information for cybersecurity defense which are used by security teams to make critical real-time decisions. Every security layer or product can generate alerts, essentially a way to tell a human operator that some threshold or policy has been breached.
Without them, defenders would be blind, forced back to security based on static, restrictive policies or assumptions.
This, unfortunately, is where the problems often start. In the last 25 years, the number of individual systems that comprise cybersecurity defense has expanded rapidly to include endpoint anti-malware, a range of network monitoring tools, and multiple datacenter and cloud applications. In addition, the sophistication of these tools has increased, allowing an ever-greater level of monitoring for malware and suspect connections.
Beset by too much of a good thing, the volume and diversity of alerts have grown beyond the ability of security teams to manually process them, at which point staff must sift the good alerts from the false alarms and noise. Solving this problem has given rise to a range of higher-level centralized management systems such as security information and event management (SIEM) which classify and prioritize alerts so that defenders aren’t overwhelmed.
Centralization was a good step – putting log and alerting data in one place where it can be processed by specialists. But, ironically, because the SIEM system still absorbs large numbers of alerts – thousands in one day for a larger network - it hasn’t solved the background issue of overload.
Typically, in-house teams might investigate a third of alerts as being significant, with another third dismissed as false alarms. That leaves up to a third they fail to get to at all. Even among the genuine alerts, not all will be equally important, for example, routine malware compared to the beginning of a ransomware attack on a single computer.
Is there a way out of this altering dead end?
Two problems that make detection and alert handling harder are the inherent complexity of managing security systems under real-world conditions and the fact that security is often configured through poorly integrated silos. This slows response times and lowers their reliability. Adding enough security layers and keeping them up to date is also prohibitively expensive.
To address these issues, a new more integrated approach has emerged in recent years, that of managed detection and response (MDR). In theory, MDR can be in-house but is more often a third-party service that integrates numerous security layers into a single threat detection and response system that is available 24x7.
This can either extend the capabilities of an in-house SoC or in some cases replace parts of it entirely. Using an MDR as a service allows organizations to access advanced capabilities without having to invest heavily upfront or spend months retooling their operation. The different components include endpoint detection and response (EDR), the layer that produces alerts related to endpoint devices; network traffic analysis, and intrusion detection, and the SIEM layer which correlates alerts from these layers. Importantly, MDR integrates this with other layers such as threat intelligence, incident repose, vulnerability management, as well as using analytics to gain a broader picture of the network’s security state.
However, compelling the advantages of using an MDR service might sound, its effectiveness always depends on its ability to process alerts. To a lot of customers, this will sound like the basic alerting provided by traditional managed security service providers (MSSPs), but an MDR service provider will always go deeper and offer more sophisticated response services.
MDR services are configured to assume threats are already present and to hunt for them. Alerts are simply fragments of data that might indicate this. Once a threat has been identified, a well-configured MDR should always be able to follow its kill chain to the point at which it entered the network, implementing containment when it finds it. Much of this is automated but the manual response is always an important element of MDR alert processing.
The ultimate purpose of an MDR service isn’t simply to sift good alerts from bad ones but to act upon them before they do damage or waylay already overloaded in-house IT teams. A good example of this is remotely recovering infected endpoints to a pre-attack state. This would normally be time-consuming and sometimes complex for an in-house team to achieve with tools that are not optimized for the task.
In summary:
Thank you for visiting our website!
We value your engagement and would love to hear your thoughts. Don't forget to leave a comment below to share your feedback, opinions, or questions.
We believe in fostering an interactive and inclusive community, and your comments play a crucial role in creating that environment.
