Mean Time To Respond (MTTR) is a classic cyber metric that many believe is a top way to track the effectiveness of a cyber operations program. As the name implies, Mean Time To Respond (MTTR) is the average time it takes your organization to respond to cyber threats. In a ransomware and data extortion world, minimizing MTTR to minimize threat impact is a top priority of cyber leaders and executive boards.
However, chances are your MTTR isn’t as good as it can be. Here are three things we have seen when looking at MTTR measurement challenges.
1. MTTR isn't being calculated correctly
How should it be calculated? The simplest and best answer is MTTR is the time between when an attack occurs and when some action is taken to stop the threat. Unfortunately, that’s often not what’s being reported to cyber leaders. Instead, many MTTRs start the clock when an alert was generated (see point 2), or when the analyst begins their investigation. This is especially common in reporting from an MSSP or MDR. The net effect is that your MTTR looks better than it actually is. This not only misrepresents the effectiveness of your cyber program, but it also robs your organization of opportunities to optimize cyber capability.
The figure above shows the major toll gates involved in identifying and stopping a cyber attack. Optimizing threat detection and alert triage are discussed below in points 2 and 3.
2. Alerts are late getting to your SOC
Alerts take longer than you think to get to your SOC… a lot longer.
Most alerts you rely on to inform your SOC are generated by Boolean logic rules. These rules are deployed in tools such as an EDR, SIEM, or other specialized cyber monitoring tech. In an effort by tool vendors to minimize resource utilization, their rules are almost always run on a schedule that looks back over a period of time. It’s not uncommon for rules, especially those aligned to identity-based attacks, to only run once every 24 hours, meaning it could take an average of 12 hours before your SOC is notified of threat activity.
As discussed in point 1, this time is often excluded from MTTR, meaning you might think your MTTR is 2 hours, when it’s really could be 14 hours or more. While this 12 hour difference is large, it represents a larger opportunity for a company to show improvement, especially when discussing new tools to implement. For instance, a client of Salem reduced their MTTR from 1 hour to 15 minutes while using Salem. This 75% reduction in MTTR was huge and allowed the client team to show a more accurate return on investment for new cyber tools to the leadership team. If the number had been mispresented, the client team would have show poorer performance, potentially impacting future investment abilities.
For an effective SOC, optimizing rule-run schedules may be the single biggest impact to reduced MTTR for minimal cost and effort. Other factors can also cause alerting to become delayed, including background processes and automation used to move alerts between systems. In real world examples, we’ve observed delays of up to 25 minutes simply moving alerts from a detection tool to a ticketing system.
3. Alert prioritization is not accurate
The most common reason for less-than-optimal MTTR is the time it takes to triage a cyber alert and recognize it represents a real threat. There are many avenues for optimization in SOC processes and analyst training. The one we focus on is prioritization. Are your analysts spending time on the right alerts? Most alert prioritization models are nothing more than outdated hocus-pocus junk. “I look at my crucial and high severity alerts” is a common refrain. But little intelligence goes into setting alert severities. Most often they are an indicator of how rare an event is and less about how likely that particular alert is to represent a threat. AI intelligence and expert systems can help identify what your team needs to run fast on, and what they can ignore.
