| MTTR Term | Definition |
|---|---|
 |
The NIST Cybersecurity Framework (CSF) describes the response phase of an intrusion as the actions taken after indications of compromise have been analyzed and “declared” to be a genuine incident. The response includes execution of a response plan, triage, analysis, escalation, communication, mitigation, and ultimately containment and/or eradication.
The Time to Respond measures how long it took to go from detection to completing the steps in the Response phase of an intrusion. Essentially, this measurement shows how quickly the organization was able to stop the damage once an intrusion was detected. The Mean Time to Respond is the average of all the Time to Respond across all intrusions that are being measured. The formula is:
MTTRespond = (sum of time to respond for all incidents) / number of incidents
This does not mean the victim has completely recovered from the intrusion, as there will still be Recovery tasks to complete before achieving a full restoration of the organization’s functionality. |
 |
NIST defines Mean Time to Recovery as “a metric that tracks the average amount of time that it takes to recover from a product or system failure.”
The point at which this metric ends is fairly straightforward: It’s when the system or product has been recovered. But it’s an open question about when the clock starts. Some definitions start from the moment the initial compromise occurs. Others indicate that it begins once response is complete and final recovery begins. Organizations may find one definition or another works best for them; what matters is that the definition of “recovery” is clear and that it’s applied consistently.
If an organization decides that the time to Recovery begins once the Response is complete, then they are measuring only the Recovery phase of NIST’s CSF. The formula for this metric is:
MTTRecovery = (sum of time to recovery for all incidents) / number of incidents |
 |
NIST does not provide a definition of this metric. Like the Mean Time to Recovery, there’s a logical ending point of mean time to resolve. The incident response process ends after a lessons-learned phase and a debrief on how the response went and what could be improved. It seems reasonable to say that the resolution ends once this debrief is done. But where does the timer start?
This metric can begin at either the time of initial compromise or when the compromise was first detected. Organizations should select the one that aligns with their capabilities to detect and investigate intrusions. The most accurate may be from the time of the initial compromise, but it may not be possible to reliably determine when an intrusion occurred. Ideally, organizations want to improve their detections as well as their resolutions, and this more expansive definition highlights the value of discovering incidents as early as possible in the cyber kill chain.
If the Time to Resolve is measured from initial compromise to the completion of lessons learned, then it creates a metric for the entire scope of the intrusion. Its formula is:
MTTResolve = (sum of time to resolve for all incidents) / number of incidents |
These metrics can be visualized by putting them on a timeline of an intrusion. The graphic below includes another metric: Mean Time to Detect (MTTD). By laying these metrics out next to each other, it is easier to see what they measure and how they interact with each other.
Mean Time to Detect flows into the Mean Time to Respond, which moves next into Mean Time to Recovery. The Mean Time to Resolve measures the entire scope of an incident, including learning from the incident.
| Factors | Context |
|---|---|
 |
In some ways, having effective procedures and the authority to perform them is the most difficult category for organizations to address. Teams with different responsibilities and priorities have to work out how an incident will be handled, when a step can be taken, and who will execute it. For example, deciding when to take a business system offline to prevent an attacker from moving to other systems is going to be a difficult, and potentially contentious, discussion. Even smaller-scale decisions, like whether security will have any access to affected systems, can be very involved. The system owner doesn’t want security to take an action without understanding the impact it could have, and security wants to contain the adversary as quickly as possible. These objectives may come into conflict. |
 |
Preparation for an incident also has a major impact on MTTR. An organization can implement tools, define procedures, and create meaningful metrics, but there still can be serious impacts from an intrusion if any stakeholders have not learned and practiced their roles. Security operations center (SOC) teams need to know how to triage alerts and how to escalate them appropriately. Incident responders need to be well-versed in using tools to restrict adversary movement and contain their actions. System owners need to understand what is required to stop an intrusion and why security might ask for procedures to be exercised.
Organizations need to practice responding to incidents in ways that familiarize their teams with procedures, and the simulations should induce some stress so that responders can become more capable of acting under pressure. |
 |
Without sufficient visibility into its systems, an organization may not detect an intrusion or may not know when they actually resolved it. Maintaining adequate visibility is an ongoing effort, since networks, applications, systems, and other technology resources are rarely static. Organizations should regularly assess what they are able to see in their environments and what they can’t see. |
The best tools for reducing MTTR
Endpoint detection and response (EDR), security information and event management (SIEM), and network detection and response (NDR) systems are some of the best tools to help organizations reduce MTTR in all its definitions. These tools allow SOCs, incident responders, and threat hunters to identify and respond to the actions of adversaries when used effectively and actively.
EDR gives detailed information about what is executing on compromised hosts, what accounts were used, what files were dropped, and where they are stored. SIEM aggregates security and event information into a single place for defenders to analyze.
NDR gives these teams the ability to see all traffic between hosts, whether those hosts are managed by EDR or not. It allows incident responders to see what hosts a known compromised host was interacting with to determine the extent of an adversary’s control and the full extent of the incident. These technologies provide critical information that can be combined to provide a comprehensive view of what occurred during an intrusion, if it is still occurring, and where it is happening. Together they form the SOC Visibility Triad and give SOC operators the ability to respond effectively to intrusions.
It is not enough to simply purchase these technologies, they must make investments in their procedures to get the most out of their tools. These include building automation to improve speed and efficiency and make use of each platform’s machine learning capabilities to respond to changing adversary behaviors. They must also take advantage of integrations between platforms to rapidly respond to adversaries' actions. SOCs should also be testing AI capabilities to improve their current workflows and preparing for the impact that AI tools will have in the future.
Book a demo
We’re proud to protect some of the most sensitive, mission-critical enterprises and government agencies in the world. Learn how Corelight’s Open NDR Platform can help your organization tackle cybersecurity risk.
