What is Mean Time to Report? (MTTR)
When it comes to cybersecurity incident response, we’re likely familiar with the concept of Mean Time to Detect or Discover (MTTD). How long does it take you, your team, managed service provider, etc. to detect a problem? This is an important metric. The quicker the detection time, the better your chances of minimizing any damage.
But what about the mean time to report an incident?
The concept of time to report is quite simple. This is the amount of time between incident detection and when it is reported to the incident response team. This team could be internal or a partner/provider.
Why Mean Time to Report Matters
The time it takes to discover an incident is critically important, but the time to report is just as critical. What good are detections that are not addressed in a timely manner? The reporting phase is what initiates our most important phase of IR – the response!
Often, we see a business discover a potential incident early in the week. They attempt to resolve the incident on their own without engaging their partner. Then, (finally) as the weekend approaches, they report the issue to their incident response team.
In most cases, this delay can compound any issues. Let’s discuss the potential problems with not reporting the incident to the response team as soon as possible.
Challenges Caused by Delayed Reporting
Lost or Corrupted Artifacts
When the appropriate response protocol is not followed, we often see that mistakes are made. This can all too often result in artifacts becoming corrupted. Unintentional as this may be, it happens nonetheless and complicates recovery efforts.
There is also a risk of losing certain artifacts altogether. Logs disappear quickly if not properly backed up. This allows attackers more time to cover their tracks.
Lateral Movement
The longer without a response, the longer the attacker has had to further their persistence and move laterally through your network. We often see that when folks attempt to resolve a detection without engaging the IR team, the focus is very localized.
Typically, if you discover an attacker on one system, it is very likely they have established persistence elsewhere in your infrastructure.
Rules and Regulations
Depending on the data you host, you may be out of compliance with your organization’s regulatory requirements. CCPA and GDPR, for example, have very specific regulations on how and how quickly possible incidents must be reported. Other regulations are following suit as well, and this will become the standard for everyone as our collective information security approach evolves.
Ultimately, our goal is to reduce the time it takes to resolve a possible incident. Detection, response, and reporting are three elements that affect this effort. The longer the time to resolve, the more financial and reputation impact observed.
What Causes a Delay in Reporting?
“We Can Fix It Ourselves.”
Report it anyway! A good IR partner will recognize this and give you the assurance you are completing the proper steps. Or they will recognize this is a more significant problem than you realize and assist with a proper response.
Underestimating the Incident
Perhaps you’re right and it’s not a big deal. You’re always better off playing it safe anyway. At the very least, have your IR partner confirm the severity of the incident for you.
In the case that the incident is more serious than it appears, you’ll already have engaged the right team and can respond swiftly—reducing the time to resolve, and ultimately any damage.
Fear of Retribution
This is a culture issue. Proper development of your incident response plan and training all key staff on both its usage and overall importance can help reduce these concerns. No one should fear reporting a security incident.
Saving Face
Sometimes folks fear they will be blamed for an incident because of another responsibility that was missed. It’s better to be the employee that identified and reported the incident – which assisted in a quick response – than the employee that tried to sweep it under the rug. Especially if it’s going to more-than-likely lead to a ransom attack.
Nothing of Value in the Environment
Even though you didn’t experience an incident on a critical network, it’s still a good idea to report the incident and handle it as though it were more serious. There’s always the risk that the threat runs deeper than it seems at first glance.
For example, in the manufacturing industry, a compromised shop floor may not be all that serious, so there’s a temptation to simply rebuild and move on, but the best course of action is still to engage your incident response team and be sure that no further action is necessary.
After all, a security incident doesn’t have to be catastrophic in nature to cause significant setbacks. Even partial downtime during a rebuild can compromise a business’s ability to function as expected. This can jeopardize deadlines and client relationships, creating a ripple effect felt throughout the entire organization.
So What Should You Do?
If you don’t already have an incident response plan in place, implementing one should be at the top of your list. Additionally, be sure that there is a clear protocol for what to do in an incident of any magnitude, not just an all-out ransomware attack. Implement an incident response team with clearly defined roles to assess and manage any incidents that may occur, and ensure that they understand when to report an incident and why.
It is also crucial to remove any stigma around reporting an incident. Be clear with your staff that reporting is far more important than who may or may not be responsible for an incident. If your team believes there may be repercussions if they report an incident, the chance of a swift response and recovery plummet.
Closing Thoughts
Mean time to report is a critical metric to consider in incident response. While the time it takes to detect is important, there is a direct correlation between a speedy report (and response) and the minimization of impact on the victim organization.
Swift reporting is key to quickly executing your incident response plan, and engaging the proper partners is crucial in orchestrating a successful recovery. So, when in doubt, it’s always better to be safe than sorry.
If you have any questions about the contents of this article, or if we can be of assistance, don’t hesitate to reach out to us. We’re always happy to help in any way that we can.