Managing incident alert overload – 3 critical ingredients

New research from Advanced Threat Analytics reveals that managed security services providers (MSSPs) are wasting significant resources processing and responding to useless security alerts.

The report found that nearly 45% of respondents investigate 10 or more alerts each day, with 64% saying it took at least 10 minutes to investigate each alert.  Indeed, some analysts reported that they spent more than five hours each day investigating alerts.  44% of respondents also reported a 50% or higher false-positive rate – which means many MSSPs could be wasting 50 minutes or more each day dealing with alerts which turn out to be meaningless.

Dedicating so much time and resource to chasing down false alarms isn’t just a waste of time and money, it also impacts on MSSPs’ security effectiveness, as their analysts’ attention is diverted away from real threats and could lead to breaches of customers’ networks – which undermines the provider’s business model.   Either that, or the volume of alerts may force MSSPs to hire more analysts to deal with the deluge of alerts, increasing their costs unnecessarily.

The missing ingredients

So, it’s clear that MSSPs’ incident management processes could be streamlined and improved, to help deal with the large numbers of alerts.  While MSSPs use an extensive range of tools, technologies and processes to help make their incident response as intelligent and effective as possible, many do not have automated processes to help them triage possible incidents, or understand what the real impact of these incidents could be on customers’ networks.

There are three essential ingredients missing which, if added to the mix, can help MSSPs deal with alert overload.

1. Business context
   The first missing ingredient is business context. Business context, in incident response, is all about connecting data regarding the security incident to the actual, real-life, business processes and applications that the incident may impact. If for example several servers are under attack, technical detail on which applications are impacted and which incidents should be prioritized for remediation will help respondents address incidents quickly, enabling them to weigh the security risks versus the operational risks of potential downtime. This will enable them to deal with critical incidents swiftly, limiting the cost of the incident and the potential impact it will have on the business.
2. Connectivity analysis
   Connectivity analysis gives respondents a deeper understanding of the potential impact of an incident, showing the scale of the security risk by indicating how far the attack could potentially spread. For example, if a server has been infected by malware, there are numerous actions it may take next; it might infect other systems on the network, it might try to exfiltrate data, and it may also attempt to download further malicious code from external addresses.
   The structure of the network and the location of the compromised machine will dictate the potential severity of these potential actions. If the server can connect to the internet, resolving the issue is high priority to avoid data breaches. If a perimeter firewall is blocking traffic from the server, however, the risk is probably less and it may be possible to designate the incident as a lower priority.
3. Visibility
   Respondents are often hampered by a lack of visibility into the network. Visibility tends to be better in traditional on-premise storage, server and networking environments, but as organizations move towards next-generation technologies such as cloud computing and virtualized environments, the view may be obscured. Blind spots on the network can delay investigation of incidents after the initial alert, so improving visibility can significantly impact remediation time.