NIST SP 800-40 Rev. 4

Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology — April 2022.

How it reaches ATT&CK

via NIST's own control list

The publication cites no ATT&CK technique. Its appendix does name the eight SP 800-53 Rev. 5 controls “most important for enterprise patch management planning”, and CTID maps 800-53 controls to techniques. Those two published lists are the whole bridge: nothing below is this site’s judgement. Counts are live; a zero means CTID maps no technique to that control.

Four risk responses

Patching is one way to mitigate. Until a response is chosen, the organisation has accepted the risk by default.

Accept
Rely on existing controls, or judge the impact low enough that nothing more is needed. The default for any software until a response is chosen.
Mitigate
Remove the vulnerability (patch, update, upgrade, disable the feature) and/or add controls that make exploitation harder, such as segmentation.
Transfer
Share the consequences with another party: cyber insurance, or moving to SaaS where the provider patches.
Avoid
Remove the attack surface: uninstall the software, decommission the asset, or disable the capability.

Vulnerability management life cycle

1Know
Know when new vulnerabilities affect your assets — which requires knowing the assets, their software and versions down to packages, and following vulnerability feeds.
2Plan
Assess the risk, choose the response (or combination), and decide how to carry it out.
3Execute
Prepare (acquire, validate, test, schedule) → implement (deploy, install, reconfigure) → verify it took effect → continuously monitor that it stays in place.

Risk response scenarios and their maintenance plans

Decided in advance, per maintenance group, so a new vulnerability needs a lookup rather than a meeting. For the two emergency scenarios the publication points to CISA’s Known Exploited Vulnerabilities catalogue, which BOD 22-01 gives US federal agencies two weeks to remediate.

1Routine patching
WhenPatches on a regular release cycle, not elevated to emergency. Most patching; most often postponed.
PlanPhased deployment: canary assets first, then expand. Flexible install window with forced installation after a grace period.
2Emergency patchingKEV list ↗
WhenA severe vulnerability, or one being actively exploited. May be part of incident response.
PlanThe routine approach on an accelerated schedule: minutes-to-hours of canary checks, then deployment within hours or days.
3Emergency mitigationKEV list ↗
WhenThe same crisis, but no usable patch yet — or the patch is flawed, disruptive or compromised.
PlanPre-planned, automatable mitigations (disable functionality, isolate the asset), each with a schedule for replacing it by the permanent fix and removing it.
4Unpatchable assets
WhenEnd-of-life software, assets that cannot take updates, or assets that must run uninterrupted.
PlanPre-approved long-term mitigations per maintenance group (micro-segmentation, software-defined perimeters per SP 800-207), plus targeted mitigations for specific vulnerabilities; reassess risk and cost-benefit periodically.

Example maintenance groups

NIST’s own six illustrations. An asset that cannot be patched is not an exception — it belongs to a group with its own plan, like the legacy OT row.

Group	Software to patch	Outage restrictions	Existing mitigations	Impact if compromised
Mobile workforce laptops for standard end users	Firmware, operating systems, client applications	Tolerant to downtime	Endpoint security controls on the laptops	Moderate
On-premises datacenter (servers, network equipment, storage)	Firmware, operating systems, server applications	Scheduled outage windows for all non-emergency situations	Network-based access restriction plus on-asset controls	High
Legacy OT assets	None — no longer supported, cannot be patched	Scheduled outage windows for all non-emergency situations	Network isolation, physical security controls	High
Smartphones for the mobile workforce	Operating systems and mobile apps	Tolerant to downtime	Mobile device security controls	Moderate
On-premises servers for automated software testing	Firmware, server OSs, virtualization, guest OSs, server and client applications	Usually tolerant to downtime	Network-based access restriction plus on-asset controls	Moderate
Containers with customer-facing applications in the public cloud	Container operating systems, application modules	Highly tolerant to downtime	Controls on the container operating system	High

Principles

Problems are inevitable; be prepared for them
Plan to handle the occasional bad patch instead of delaying every patch for fear of one.
Simplify decision making
Decide responses in advance per group and scenario; per-vulnerability risk assessment does not scale.
Rely on automation
The volume of assets, software and patches — and emergencies — cannot be handled by hand.
Start improvements now
Some changes take years; others can start today.

Recommendations

3.1Reduce patching-related disruptions
3.2Inventory your software and assets
3.3Define risk response scenarios
3.4Assign each asset to a maintenance group
3.5Define maintenance plans for each maintenance group
3.6Choose actionable enterprise-level patching metrics
3.7Consider software maintenance in procurement

Actionable metrics (§3.6)

Single-number metrics such as "90% of assets patched" are not actionable: they say nothing about which assets and which vulnerabilities make up the other 10%.

Rows: Vulnerability importance (low · medium · high · critical)

Columns: Asset importance (low · moderate · high)

Each cell: % patched by the maintenance plan’s deadline · mean time to patch · median time to patch

NIST’s table uses illustrative numbers, so only its shape is shown. For building a measurement programme, see SP 800-55 Vol. 1 & 2.

Procurement questions (§3.7)

Will you release updates for this software to address vulnerabilities?
How many patches, updates and upgrades per year, how quickly per vulnerability, bundled or separate, how many emergencies?
For how many years will you correct vulnerabilities in it?
Regular schedule, as needed, or both — and what schedule?
Do you have a vulnerability disclosure and incident response programme, and how transparent are you?
When a vulnerability is public but unpatched, how should customers protect themselves — will you ship an emergency mitigation?
How disruptive is patching: restart the software, reboot the asset?
How do you test patches, how often do they cause significant issues, and can they be rolled back?

CSF subcategories named in the appendix

These are CSF 1.1 identifiers, listed as published. They are not translated to CSF 2.0 here: NIST’s 1.1 → 2.0 mapping is many-to-many, so a translation would be this site’s choice. The CSF 2.0 crosswalk to ATT&CK is on NIST CSF v2.

ID.AM-1Physical devices and systems within the organization are inventoried
ID.AM-2Software platforms and applications within the organization are inventoried
ID.AM-4External information systems are catalogued
ID.AM-5Resources are prioritized based on their classification, criticality, and business value
ID.BE-3Priorities for organizational mission, objectives, and activities are established and communicated
ID.BE-5Resilience requirements to support delivery of critical services are established for all operating states
ID.GV-3Legal and regulatory requirements regarding cybersecurity are understood and managed
ID.RA-5Threats, vulnerabilities, likelihoods, and impacts are used to determine risk
ID.RA-6Risk responses are identified and prioritized
ID.SC-1Cyber supply chain risk management processes are identified, established, assessed, managed, and agreed to by organizational stakeholders
PR.IP-1A baseline configuration of information technology/industrial control systems is created and maintained
PR.IP-3Configuration change control processes are in place
PR.IP-12A vulnerability management plan is developed and implemented

Source

Murugiah Souppaya, Karen Scarfone, Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology, NIST SP 800-40 Rev. 4 (April 2022). A US Government work; section text is paraphrased, control and subcategory titles are quoted. Implementation companion: SP 1800-31, Improving Enterprise Patching for General IT Systems. Control-to-technique mappings: MITRE Center for Threat-Informed Defense. Not affiliated with or endorsed by NIST.