7.8 Patch & Vulnerability Management

Key Takeaways

CISSP 7.8 is officially: Implement and support patch and vulnerability management.

The current ISC2 outline does not provide additional sub-bullets beneath this objective.

Vulnerability management and patch management are closely connected but are not the same activity.

Vulnerability management is the broader lifecycle of identifying, validating, prioritising, treating and tracking security weaknesses.

Patch management focuses on managing software and firmware updates.

Vulnerability management = manage the weakness. Patch management = manage the update.

A patch is one possible vulnerability treatment.

Some vulnerabilities can instead require configuration changes, compensating controls, isolation, replacement or formal risk acceptance.

Effective vulnerability management depends on effective asset management.

Unknown systems may remain outside vulnerability scanning and patch processes.

You cannot patch what you do not know exists.

Vulnerabilities may be discovered through scanners, vendor advisories, penetration tests, security assessments, threat intelligence, incidents and vulnerability-disclosure processes.

Automated vulnerability scanning is powerful but not infallible.

False positives can report vulnerabilities that do not exist.

False negatives can fail to report vulnerabilities that do exist.

Authenticated scanning can provide deeper visibility into installed software, patch levels and configuration.

Unauthenticated scanning can provide useful visibility into what an unauthenticated observer can see remotely.

Scan success should include validation of scanner coverage and authentication health.

Scan completed ≠ every asset assessed correctly.

CVE provides a common identifier for publicly disclosed vulnerabilities.

CVSS describes vulnerability severity characteristics.

CVSS scores range from 0.0 to 10.0.

CVE = which vulnerability? CVSS = how severe are its characteristics?

CVSS is not, by itself, an organisational risk score.

Risk prioritisation should consider additional context such as threat activity, exposure, asset criticality, data sensitivity and existing controls.

Current CVSS 4.0 includes Base, Threat, Environmental and Supplemental metric groups.

The CISA Known Exploited Vulnerabilities Catalog provides useful information about vulnerabilities known to have been exploited in the wild.

CVSS tells you severity. KEV adds exploitation context.

Highest CVSS should not automatically mean highest organisational priority.

A slightly lower-severity vulnerability that is actively exploited on an internet-facing critical asset may warrant more immediate treatment.

Vulnerability prioritisation should therefore be risk based.

Useful factors include severity, exploitation evidence, exposure, asset criticality, data sensitivity, privilege and compensating controls.

Vulnerability findings should have clear ownership.

Findings without ownership can remain unresolved even when technical detection works perfectly.

Vulnerability treatment can include patching, configuration changes, compensating controls, isolation, replacement, retirement or formal risk acceptance.

Mitigation and remediation should not be confused.

A patch can correct the underlying flaw.

A mitigation can reduce risk while leaving the underlying vulnerability present.

Patch = fix the flaw. Mitigation = reduce the risk.

Virtual patching can use controls such as WAF or IPS rules to block exploitation without changing the vulnerable software.

This can provide valuable temporary protection but does not mean the underlying vulnerability has disappeared.

NIST describes enterprise patch management as identifying, prioritising, acquiring, installing and verifying patches, updates and upgrades.

Operational programmes commonly add testing, approval, staged deployment and rollback planning around that lifecycle.

Identify → Prioritise → Acquire → Test → Deploy → Verify.

Patch testing helps identify compatibility, dependency, performance and availability problems before wide deployment.

Test environments should represent production sufficiently well to provide useful assurance.

Staged deployment can reduce the blast radius of a defective update.

A patch might first be tested in a laboratory environment, then deployed to a pilot group before broad production deployment.

Security teams must balance patch urgency against operational risk.

Excessively delaying an important patch extends the window in which an attacker may exploit the vulnerability.

Deploying an inadequately tested patch can create outages.

The objective is risk reduction - not simply fastest possible patching.

Emergency patching can be justified when waiting for a normal cycle creates unacceptable security exposure.

Emergency should mean accelerated governance rather than no governance.

When no patch exists, organisations should consider available temporary mitigations.

Those may include disabling vulnerable functionality, restricting network access, applying WAF or IPS controls, removing internet exposure and increasing monitoring.

No patch available ≠ no action possible.

Patching is also a technology change.

It therefore intersects with change-management activities such as approval, maintenance windows, rollback and post-change validation.

Rollback planning provides a recovery path when patch deployment causes unacceptable operational impact.

Patch installation should be verified.

A management console saying that deployment succeeded does not necessarily prove that the vulnerability is gone.

Some patches require a reboot or other activation step.

Rescanning or equivalent validation can provide evidence that remediation succeeded.

Patch applied ≠ vulnerability closed. Verify it.

Vulnerability-remediation targets should reflect organisational policy and risk.

There is no universal number of days that every organisation must use for every vulnerability.

Vulnerabilities that cannot be remediated within expected timelines should enter an appropriate exception or risk-treatment process.

Exceptions should document the reason, residual risk, compensating controls, approval and review or expiry date.

Formal acceptance of significant residual business risk should be performed by appropriately authorised ownership.

Security identifies and advises on risk. Appropriate business or risk ownership accepts it.

End-of-life and end-of-support technology creates particular vulnerability-management challenges.

Once vendor support ends, newly discovered vulnerabilities may never receive security patches.

Long-term treatment normally involves upgrading, replacing or decommissioning unsupported technology.

Isolation and compensating controls can reduce interim risk.

Fully patched unsupported system ≠ sustainably secure system.

Patch management should include more than desktop and server operating systems.

Applications, network devices, security appliances, firmware, hypervisors, storage, embedded systems and other technology may also require security updates.

Cloud environments use shared responsibility.

The provider may patch underlying infrastructure while the customer remains responsible for guest operating systems, applications or other layers depending on the service model.

Cloud changes patching responsibility. It does not eliminate patching responsibility.

Containerised and immutable environments may address vulnerabilities by updating a source image and redeploying workloads rather than patching long-lived running instances.

Updating only a running container while leaving the source image vulnerable allows the weakness to return.

Patch-management infrastructure itself requires strong protection.

These systems may have authority to distribute software across thousands of enterprise devices.

Patch sources should therefore be trusted and update integrity should be validated.

Patch infrastructure should use appropriate access control, logging and monitoring.

A patch-management system can become a highly privileged software supply chain.

Repeated vulnerabilities can indicate upstream process problems.

If new servers repeatedly appear with an old vulnerability, the root problem may be a vulnerable build template or automation process.

Fixing the source is more effective than endlessly remediating every new instance individually.

Vulnerability metrics should communicate risk and programme performance.

Useful measures can include asset coverage, scan health, vulnerability age, remediation time, overdue findings, patch compliance, exceptions and recurring vulnerabilities.

Patch-compliance percentages should be interpreted together with asset criticality.

Ninety-five percent compliance can hide significant risk if the remaining five percent consists of critical internet-facing systems.

Vulnerability age can expose weaknesses that a simple count does not.

A vulnerability that has remained unresolved for hundreds of days may indicate a deeper process or ownership failure.

Automation helps vulnerability management scale through discovery, scanning, prioritisation, ticketing, patch deployment and verification.

Automation should support accountable risk decisions rather than replace governance.

The most important operational principle is:

know your assets, continuously discover vulnerabilities, prioritise them according to real organisational risk, apply the most appropriate treatment and verify that the treatment actually worked.