2

I was wondering if there are any general recommendations on maximum resolution times for vulnerabilities.

Consider a vulnerability/patch management process where a ticket is opened when a vulnerability is reported/detected. The ticket system sets a maximum resolution time based on details of the vulnerability, such as:

  • Criticality of the vulnerability—critical vulnerability result in a higher risk, thus organizations cannot afford to remain vulnerable for long,
  • Availability of a solution—vendor-reported vulnerabilities typically come with a solution in the form of a patch, while other cases may require a thorough (and potentially time-consuming) analysis.

If it is anticipated that a solution will not be available within the resolution time, mitigating measures need to be discussed. If the resolution time is exceeded, the ticket is escalated (resulting in an extension of the solution time and/or additional mitigating measures).

Are there any general recommendations on what the resolution times should be, or how to quantify them?

2

Quantifying the time to remediate is a function of the assessed risk. Risk is a function of impact and likelihood of the impact occurring. That's the general recommendation, and the organisation needs to work that out for itself.

A corporate policy helps define the default time for remedies to be applied based on the organisation's risk tolerance and the benefits of consistent operation. Each organisation has a different level of risk tolerance along with processes and procedures that need to be accounted for in the decision.

A few 3rd party standards organsiations issue guidance for what they think the current best practice is. They are not risk-informed, but rather an industry-expert opinion. Cyber Essentials from the UK's NCSC, for example, sets the timeframe for critical patches at between 14-30 days.

But once you decide that remedies need to be applied as soon as they are available, then the entire conversation shifts to what barriers and reasons for delays are acceptable to the organisation. That is a completely different conversation and is no longer a function of the vulnerability/patch/outside risk, but rather the operational realities and operational risks that the organisation wants to take on. And frankly, this becomes a much more useful and fruitful discussion.

If a remedy is available now, and it could be applied, why wait 14 days? There are tons of valid reasons to delay for 14 days, or even 40 days or longer. The real question is what types of delays are acceptable to the organisation? What needs to be accounted for in the remediation process? Are those delays actually valid or are they excuses and convenience?

So, I would flip your question around to assuming that remedies need to be applied as soon as the vulnerability is identified, with acceptable delays that account for unchangeable operational realities and operational risks that might outweigh the risks inherent in the vulnerability.

Or, if you just want a static number from experts, Cyber Essentials says 14 days for criticals and highs.

| improve this answer | |
  • I agree that there is no need to wait if a solution is available now. The core question is: if I cannot fix a vulnerability immediately, how much of a delay is acceptable before I need to mobilize additional resources to speed things up or implement temporary mitigating measures? – user149408 Sep 23 '19 at 13:36
  • As I said at the start, that's entirely up to a risk analysis. For example, a network-based vulnerability in an air-gapped system has a low risk. The costs of some remediations could cost more than the likely impact of the vulnerability being exploited. Some orgs insist on a patch test period for a certain length of time before applying to live critical systems, just in case the patch brings the system down. Short answer: assess the risk. – schroeder Sep 23 '19 at 13:46
  • 1
    @user149408 in addition to Schroeder's excellent answer, worth adding too that if a vulnerability is identified it may be possible to monitor it for signs of exploitation, or to be immediately mitigated temporarily - if it's in an image upload script for example, disable image uploading and you have much longer to roll out a fix – LTPCGO Sep 24 '19 at 4:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.