MTTR and why its important

MTTR and why its important

Ok, lets talk about Rapid7's new Executive Risk View - one of the dashboards available in the new Cloud Risk Complete offer.?Specifically, lets look at the metrics provided and what business goals they might support...


MTTR - Mean Time to Remediation

This is not just a key indicator of a successful vulnerability management program (or rather reduction of MTTR over time), this is an indicator towards over all organisation health and resilience.??


MTTR is the length of time from which a vulnerability is discovered to when it is patched.?A low MTTR indicates that vulnerabilities are patched faster.??


Gartners Report "how to implement a risk-based vulnerability management methodology" published april 2023 cites 1,554 vulnerabilities exploited in 2021 vs 19,093 unexpoited vulns.?It also cites that the majority of these vulnerabilities had a CVSS rating of High or Meduim, and finally states the number of patched vs unpatched each year which was 17,741 and 2,906 respectivly.?The time taken for vulnerabilities to be exploited in 2021 was an average of 7.52 days vs the 5 year ago (2018) average time of 36.94 days is a significant improvement on the attackers side.??

*note - report originally published 2018, but has been updated for April 2023


What can we take from this????


That the vulnerability likely to cause you an issue is more likely to be a medium or a high vulnerability, and that attackers will potentially have an expoit ready in 7.52 days.?Why a high or medium??A theory is that orgs are better at patching critical vulns faster, and so it makes sense for threat actors to target high or medium level vulnerabilities as they will likely have a longer MTTR in the environment.??


How to reduce MTTR?

This is the part thats tricky, as different orgs have different resources and processes in place.?You will need to start identifying any key bottle necks in the remediation process e.g. how long does change control take??how long does it take to update and perform testing in the test environment??if these take time then why??is it a resource issue??is it that the team signing off the changes are overwhelmed??

I like to map out the relationships between Teams, Tooling, Assets, and KPIs in order to find areas of focus.??

No alt text provided for this image


What do I mean by this?

Well, lets say for example you have a security team and an operational team.?The operational team is the team that will actually carry out the task of patching, however their manager has the KPI of ensuring platform stability and facilitating new features.?These KPIs could potentially conflict.?Also look at feedback mechanisms - when security discover a vulnerability on critical infrastructure, how long does it take to scope the work and get the operations team to complete the work??Is there a ticketing system??How far down their list will this new task appear??Draw out the interactions, relationships and influences.?This will highlight some areas to focus on.??

No alt text provided for this image

This is just a very basic example of how to get going. An actual relationship map will be much more intricate. The key point here is that you will begin to discover the bottlenecks and inefficiencies within your vulnerability management program.

  • Are there relationships or feedback mechanisms you can shorten?
  • What KPIs could you align better to achieve security AND operational goals?
  • What would happen if you removed these barriers?
  • Are there also operational benefits to this improvement?


There are even some schools of thought that say patching should be the default and that change requests should go through to undo a patch!?You might think that this is crazy and that it would make business applications highly unstable, however orgs that chose to go down this route have other measures in place that mean they can quickly roll back or recover the environment without service interruption.?This has added benefits as it makes the organisation more resilient and agile when faced with other situations e.g. you will likely find that an org like this is much faster at recovering from a ransomware event with signinficantly less operational impact.?The book "Security Chaos Engineering by Kelly Shortridge" talks a lot about organisational resiliency and how it supports the goals of security and operations.


So, in summary a low MTTR is an excellent indicator of over all security health.?Concentrating on reducing MTTR over time is a great area for focus and will likely lead to operational improvements such as being more resilient.


要查看或添加评论,请登录

David Higgs的更多文章

社区洞察

其他会员也浏览了