liveBook · Manning

Patch management

As explained in Data-Driven Cybersecurity

The process of identifying, prioritizing, testing, deploying, and tracking software updates that remediate defects or vulnerabilities.

Patch management is the process of testing and applying software changes in time to address defects and vulnerabilities while maintaining reliable components. Critical and high-severity vulnerabilities deserve particular attention. Older, unsupported software may instead require an upgrade or replacement. section 7.4.1 section 6.3.3

Make patching measurable and actionable:

  • Track patch compliance, the share of critical vulnerabilities resolved within the service-level agreement (SLA), and average time to patch against explicit targets. section 4.3.1 section 4.2.5
  • Coordinate with software vendors for timely updates, and test changes before implementation. section 6.3.3 section 7.4.1
  • When patching misses its target, consider automation and report the remaining risk rather than relying on the number of patches completed. section 4.3.1 section 6.3.3

Turn a missed target into a decision

An executive report shows 93% patch compliance against a 95% target and 85% of critical vulnerabilities resolved within their SLA against a 90% target. The actionable conclusion is to improve patch-management automation and monitor whether critical-vulnerability resolution reaches its target. section 4.3.1

Figure 6.6 On the left, the TechMed risk assessment dashboard before the risk management program is implemented. In this figure, the bottom metrics are displayed as a percentage to indicate the percentage of incidents that were within the predefined target of hours. For example, 40% of the incidents were detected within the 12-hour target detection time. On the right, the risk assessment dashboard after implementing the risk management program.

Compare the before-and-after risk dashboards: fewer critical and high vulnerabilities accompany a focused patch-management program, but 20 high vulnerabilities still need priority. section 6.3.3

A shorter patch time is progress, not completion: reducing the time to patch critical systems to 48 hours still leaves a 24-hour target unmet. Report both the improvement and the gap so resources can be directed toward faster, reliable patching. section 4.2.5

How Data-Driven Cybersecurity covers it

How deep it goes
Describes testing, implementation, vendor coordination, and target tracking without specifying a patch-testing protocol or automation implementation.
Examples
Uses executive patch-compliance and SLA targets alongside a before-and-after vulnerability dashboard.
What you can do after
Practice/perform prioritizing severe vulnerabilities, monitoring patch targets, and recommending action when performance falls short.
How it connects
Links patch management to vulnerability management, software maintenance, service-level agreements, and risk assessment.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Data-Driven Cybersecurity. The section links point to the parts of the book it draws on.