I like MTTR; it’s versatile, forward looking and easy to understand. It’s a great measurement and changer of behaviour. It applies to several security problems and I propose we can make is more powerful.

If you’re applying Mean Time To Remediate to vulnerabilities, do you start the TTR (Time To Remediate) from the moment your learn of the vulnerability or the moment the patch becomes available. If you’re using a vulnerability scanning tool it can be either. It all depends when the scanners signature are updated to detect that vulnerability. Usually it happens in the following sequence:

1. Vulnerability announced and patch announced simultaneously (because responsible disclosure);
2. Followed quickly by the scanning vendors updating their signatures; and
3. The vulnerabilities are detected in your environment the next time the scan runs (which could be tomorrow or several days from now).

Usually the gap between #1 and #2 is narrow, a day or two in my experience; and if you scan the next day that gap is not a big deal. However, consider a scenario when the gap between #1 and #2 is wider or perhaps even the vulnerability is announced well before the patch is released (0-day). Do we start TTR when the vulnerability is announced? When the patch is available? or when we can detect it in our environment?

Only starting the timer when we know how to fix skips over the problem that we remain vulnerable for all the preceding time. The same may apply for only starting the timer when we can detect its presence; first because we were vulnerable before we could detect and second because one tends to have some knowledge about what’s in the environment. So the timer should start from the moment the vulnerability was known.

But to who was the vulnerability known? Some vulnerabilities are discovered and used long before they’re disclosed. It’s rare but 0-day are not unheard of. We’re limited by what we know, but if the flaw was present in the system for a long time before being fixed, lack of knowledge does not immunise anyone.

During the Solarwinds breach Microsoft made recommendations to mitigate the impact of the breach. Would these mitigations, which were all industry standard practices, have prevented compromise? If so, that implies that it is possible to inadvertatently mitigate a serious security threat by following common practice and establishing as layered defenses. The Canadian Centre for Cyber Security recommended: “Follow recommended industry best practices for hardening of enterprise systems”.

So what happens if retroactively update our TTR/MTTR calculations to start the moment we became vulnerable and not the moment we knew we were vulnerable? Can we determine, retroactively, if our layered security, our other defenses, protected us even if we weren’t patched (or whatever the appropriate mitigation is)?

What if we applied that that thinking to other areas requiring mitigation? What if we retroactively evaluated how long an audit deficiency had existed? or some other issue? Such a change would probably unduely penalize if used a primary measure. However using a retroactively enhanced MTTR could a great change driver towards layered security or towards addressing deficiencies before they came into existence via secure design and similar practices.