Review of the publication NIST SP 800-40 "Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology"

Ruslan Rakhmetov, Security Vision

As we wrote in one of our earlier publications, a vulnerability is a flaw in the creation/configuration/use of a software and hardware tool or information system that can negatively impact the cybersecurity of an IT asset, with attackers exploiting vulnerabilities in the asset itself or in its defences to carry out malicious activities. The list of vulnerabilities is constantly growing, for example, the CVE (Common Vulnerabilities and Exposures) registry of MITRE at the end of January 2022 documented almost 170 thousand vulnerabilities, among which there are truly devastating ones, the exploitation of which can lead to the takeover of the entire IT infrastructure.

The primary way to protect against exploitation of known vulnerabilities is to build a patch management process, which is described in NIST SP 800-40 Rev. 4 (Draft) ‘Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology’.

So, Draft Revision 4 of NIST SP 800-40 defines the process of installing updates (patching) as the action of applying changes to installed software (applications, operating systems, firmware) that fix security/functionality issues or introduce new functionality. Enterprise update management is defined as the process of identifying, prioritising, receiving, installing, and verifying that security updates, upgrades, or updates are installed correctly across the organisation. Information assets such as IT/OT systems, IoT devices, mobile devices, and cloud, virtualised and containerised infrastructures are considered within the scope of NIST SP 800-40. In order to improve and operationalise the efficiency of the update management process, IT and IS managers, together with company management and business system owners, should develop a corporate strategy for proactive patch management that removes a potential problem (vulnerability exploitation) in a controlled manner, despite established biases (the ‘it works - don't touch it’ approach) and the risks of business process downtime (to install an update, reboot the OS after the update has been installed, or if the update has broken the functionality of the solution). At the same time, the document recognises the fact that not all updates really eliminate vulnerabilities or extend the necessary protective functionality (just remember the release of incorrect updates for Windows, which violate the basic functionality of the OS, followed by the emergency release of ‘patch for patch’), and also mentions cases when the update itself may contain new vulnerabilities, either accidentally or intentionally (for example, as part of a ‘supply chain’ attack, i.e. an attack on the supply chain).

From a risk management perspective, the handling of vulnerability-related cyber risks can be realised in the following ways:

1. Acceptance: conscious awareness of unpatched vulnerabilities, use of imposed defences, expected damage from vulnerability exploitation is low enough for no additional IS measures to be taken.

2. Minimisation: reducing cyber risk by eliminating the vulnerability (e.g. installing a software security update, disabling a vulnerable component, upgrading to a current version without vulnerabilities) and/or applying additional protective measures to reduce the likelihood of exploitation (e.g. applying ‘virtual patching’ on a Web Application Firewall or IPS system, network restriction of access from/to a vulnerable asset to reduce the potential attack surface). Consider the following limitations: the vulnerability and exploit for it appeared before the patch was released (e.g., in a 0-day attack or if the vendor did not respond properly); the vendor no longer supports the outdated software/solution or the licence to receive updates has expired; business processes do not allow downtime due to the update installation, business applications need to be tested after the software installation or employees need to be trained on the updated version; patch installation is delayed due to the availability of higher-priority updates; pro

3. Transfer: using cyber insurance services or SaaS (Software-as-a-Service, software-as-a-service) solutions.

4. Avoidance: eliminating the attack surface by removing vulnerable software, disabling a vulnerable component, decommissioning a vulnerable device.

The software vulnerability management lifecycle according to NIST SP 800-40 consists of the following steps:

1. Asset management and learning about new vulnerabilities: an understanding of which IT assets are being used and for what purposes, with the exact version and build of a particular application/utility/package/library, is required, and information about vulnerabilities in those software components should be continuously obtained and processed.

2. Vulnerability exploitation cyber risk response planning: selecting one or more ways to handle the cyber risk of vulnerability exploitation (acceptance, minimisation, transfer, avoidance).

3. Responding to the cyber risk of vulnerability exploitation:

3.1 Preparing for patch deployment: prioritising the patch (depending on the level of criticality of the vulnerability it closes), planning for patch deployment (as part of the corporate change management procedure, i.e. change management), obtaining the patch (download, media delivery, in-house development), testing the patch (checking the integrity and absence of unauthorised changes made), testing (to identify problems during/after patch deployment before large-scale deployment).

3.2 Patch installation: patch delivery (automatically via update/software delivery systems, manually, scheduled, by vendor in case of cloud-based solutions); patch verification (integrity, content integrity); patch installation (automatically or manually, with or without user involvement, with or without administrative authority, as a result of installing another product update); software configuration and state changes (e.g. device reboot, software restart, service restart, manual activation of new security options); software configuration and state changes (e.g. device reboot, software restart, service restart, manual activation of new security options).

3.3 Verification of the installed update: assessment of the success of the installation; verification that the associated vulnerability has been resolved.

3.4 Monitor installed updates: verify that the update was not uninstalled/uninstalled by the user or attacker; verify that the old vulnerable version of the software was not automatically restored from the backup; analyse the behaviour of the updated software/solution to identify signs of a supply chain attack.

NIST SP 800-40 also provides practical guidance for developing a corporate vulnerability management plan:

1. Reduce the number of installations of potentially vulnerable software.

Reducing the number of installations of potentially vulnerable software and consequently minimising the need to install updates can consist of the following:

1.1 Use of secure software configuration procedures (hardening): application of the principle of least authority and minimum required functionality with disabling redundant components that are not required for solving business tasks.

1.2 Use software/solutions that are less likely to contain vulnerabilities. 1.3.

1.3 Engage with experienced vendors who are less likely to allow vulnerabilities to appear in their products.

1.4 Use provided services instead of traditional software wherever possible.

1.5 Use a technology stack or platforms that are less likely to contain vulnerabilities (e.g., using containers instead of traditional OSes).

2. IT Asset Inventory.

It is recommended to perform IT asset inventory using automation tools to identify new IT assets and obtain up-to-date information on them. At the same time, the results of IT asset inventory should contain data on technical and business characteristics of the assets to provide context for the use of a particular software. IT asset data may include:

• platform type (IT/OT/IoT/cloud/container/virtual machine);
  
• the administering entity (IT administrator, vendor, business end-user);
  
• the asset's management mechanism (hypervisor, container manager, endpoint management system);
  
• data about the asset's network connectivity (internet access, ports and protocols used);
  
• the antimalware protection systems used;
  
• the primary user of the asset or related services (including privileges);
  
• the role and criticality of the asset for the company (the business task being performed);
  
• regulatory requirements for remediating vulnerabilities on the asset;
  
• restrictions on installing updates (e.g., only the vendor can install a patch);
  
• business requirements for the availability of the asset (e.g., a reboot is possible once a quarter at a pre-agreed time interval).

3 Define scenarios for responding to the cyber risk of vulnerability exploitation.

Scenarios for responding to the cyber risk of vulnerability exploitation may include:

3.1. Scheduled update: installing updates in accordance with the update plan, in the absence of evidence of vulnerability exploitation by attackers.

3.2. Emergency update: urgent installation of an update when there are recorded attempts to exploit vulnerabilities covered by the update; if an attack has already occurred, the installation of an update may be part of the cyber incident response process.

3.3 Emergency ‘workaround’: urgent actions (changing OS settings, registry edits, reconfiguring software configuration) to minimise the risk of vulnerability exploitation until the patch is available or until it can be installed.

3.4 Non-updatable IT assets: limiting network access/functionality of an asset for which updates cannot be installed (due to critical requirements for continuous operation of the asset, software/solution obsolescence, lack of technical support from the vendor). 4.

4. consolidate assets into service groups.

IT assets should be grouped into maintenance groups according to inventory data and defined scenarios for responding to the cyber risk of vulnerability exploitation. A maintenance group is a set of assets with similar inventory characteristics that have the same maintenance needs (patch and workaround constraints) for each of the cyber vulnerability response scenarios.

5. Develop maintenance plans for each maintenance group.

5.1 Maintenance plan for the ‘Scheduled Update’ scenario: a small group of assets should be identified to be updated first, for testing and feedback, with a sample of users and services from different business units; after a successful test, the update can be applied to the remaining assets. That said, in large infrastructures, there may be multiple test groups, for example, distributed in the proportion of 5%/20%/75%. At the same time, you should not delay the installation of scheduled updates: you can set an installation deadline, after which the update will be forcibly applied to the device, or temporarily block network access to an unupdated device.

5.2 Service Plan for the ‘Emergency Update’ scenario: If an emergency update is required, you should also select a group of test assets, install and test the update on them as soon as possible, and then roll out the update to all assets.

5.3 Maintenance plan for the ‘Emergency workaround’ scenario: consider in advance how the emergency workaround will be applied, e.g. by centrally disabling vulnerable components, isolating assets, automatically changing OS settings, making registry edits, reconfiguring software. At the same time, a procedure for rolling back emergency changes made after an official patch is released should be considered for successful implementation.

5.4 Maintenance plan for the ‘Non-upgradable IT Assets’ scenario: Consider ways to protect non-upgradable assets, such as applying network micro-segmentation, inclusion in virtual VLANs with restricted network access, limiting functionality, maximising hardening. Measures should also be continuously reviewed to assess their effectiveness, and cost/benefit analyses should be conducted to correlate the cost of protecting non-renewable assets with their business benefits.

6. Select performance metrics for the renewal management process.

NIST SP 800-40 suggests using inventory data (including information on the criticality of IT assets) and data from vulnerability risk assessment systems (e.g., CVSS) to develop metrics that reflect the importance of each vulnerability and patch to an organisation's infrastructure. The relationship between asset criticality (3 gradations) and vulnerability hazard (4 gradations) can be used as an example of metric development.

7. Evaluate technical support for software/solutions during procurement.

When procuring software/solutions, the vendor's level of technical support should be assessed using a questionnaire that includes questions about plans to release updates for the software/solution, regularity of patch provisioning, period of planned security update provisioning, method of handling vulnerability data, provision of emergency patches/workarounds, information about the impact of vendor updates on the IT asset as a whole.