Peter A Clarke

The National Institute of Standards and Technology (“NIST”) releases excellent guides in relation to all manner of technology.  It is particularly helpful in providing processes to improve cyber security and deal with data breaches.

Last week the NIST through its  National Cybersecurity Center of Excellence (NCCoE) released

• Special Publication (SP) 800-40 Revision 4, Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology and
• SP 1800-31, Improving Enterprise Patching for General IT Systems: Utilizing Existing Tools and Performing Processes in Better Ways.

The focus of both guides highlights the importance of timely and appropriate patching so as to enable  organisations to have an adequate cybersecurity system.

Patching is a form of preventive maintenance of computing technologies.  It helps prevent compromises, data breaches, operational disruptions, and criminal acts.

SP 800 – 40

SP 800-40 Revision 4 recommends that leadership at all levels of an organization, along with business/mission owners and security/technology management teams, should jointly create an enterprise strategy that simplifies and sets up processes for patching.

Enterprise patch management is the process of identifying, prioritizing, acquiring, installing, and verifying the installation of patches, updates, and upgrades throughout an organization.

The publication refers to four types of risk responses :

1. Accept: Accept the risk from vulnerable software as is, such as by relying on existing security controls to prevent vulnerability exploitation or by determining that the potential impact is low enough that no additional action is
2. Mitigate: Reduce the risk by eliminating the vulnerabilities (e.g., patching the vulnerable software, disabling a vulnerable feature, or upgrading to a newer software version without the vulnerabilities) and/or deploying additional security controls to reduce vulnerability exploitation (e.g., using firewalls and network segmentation to isolate vulnerable assets, thus reducing the attack surface).
3. Transfer: Reduce the risk by sharing some of the consequences with another party, such as by purchasing cybersecurity insurance or by replacing conventional software installations with software-as-a-service (SaaS) usage where the SaaS vendor/managed service provider takes care of patching.
4. Avoid: Ensure that the risk does not occur by eliminating the attack surface, such as by uninstalling the vulnerable software, decommissioning assets with the vulnerabilities, or disabling computing capabilities in assets that can function without

Installing a patch or update or upgrading software to a newer version without the vulnerabilities are the only forms of risk response that can completely eliminate the vulnerabilities without removing functionality.

The basic software vulnerability management life cycle which applies to all risk response approaches.

1. Know when new software vulnerabilities affect the organization’s assets, including applications, operating systems, and firmware. This involves knowing what assets the organisation uses and which software and software versions those assets run down to the level of packages and libraries, as well as keeping track of new vulnerabilities in that software.
2. Plan the risk response. This involves assessing the risk the vulnerability poses to the organization, choosing which form of risk response (or combination of forms) to use, and deciding how to implement the risk response.
3. Execute the risk This will vary depending on the nature of the selected risk response, but common phases include the following:

• • Prepare the risk response. This encompasses any preparatory activities, such as acquiring, validating, and testing patches for the vulnerable software; deploying additional security controls to safeguard the vulnerable software; or acquiring a replacement for a legacy asset that cannot be patched. It might also include scheduling the risk response and coordinating deployment plans with enterprise change management, business units, and others.
  • Implement the risk response. Examples of this include distributing and installing a patch, purchasing cybersecurity insurance, deploying additional security controls, and changing asset configurations and state (e.g., software reset and platform reboot). Any issues that occur during implementation should be resolved.
    
  • Verify the risk response. This step involves ensuring that the implementation has been completed For patching, this means confirming that the patch is installed and has takeneffect. For deploying additional security controls, ensure they are functioning as intended. For risk avoidance, verify that vulnerable assets were decommissioned or replaced.
  • Continuously monitor the risk response. Make sure that the risk response continues to be in place: no one uninstalls the patch, deactivates the additional security controls, lets the cybersecurity insurance lapse, or restarts the decommissioned

As obvious as it sounds it is appropriate to to establish processes and steps for preparing to deploy a patch including:

• Prioritise the atch may be a higher priority to deploy than others because its deployment would reduce cybersecurity risk more than other patches would. Another patch may be a lower priority because it addresses a low-risk vulnerability on a small number of low-importance assets.
• Scheduling patch deployment. Many organizations schedule patch deployments as part of their enterprise change management
• Acquiring the patch. Patches may be downloaded from the internet, built internally by developers or system administrators, or provided through removable
• Validating the patch. A patch’s authenticity and integrity should be confirmed, preferably by automated means, before the patch is tested or installed. The patch could have been acquired from a rogue source or tampered with in transit or after
• Test the patch. A patch may be tested before deployment. This is intended to reduce operational risk by identifying problems with a patch before placing it into production. Testing may be performed manually or through automated methods

In deplying the patch  common steps include:

• Distribute the patch. Distributing the patch to the assets that need to have it installed can be organization-controlled (and occur automatically, manually, or as scheduled) or vendor-controlled, such as delivered from the cloud.
• Validate the patch. Aa patch’s authenticity and integrity should be confirmed before installation, preferably through automated means.
• Install the patch. Installation can occur  automatically or manually when directed to do so by a user, administrator, vendor, or tool.  It can occur as a result of other software being installed or updated or through the replacement of removable media used by an asset. Some installations require administrator privileges, such as installing firmware patches for a system basic input/output system (BIOS) and some patch installations require user participation or cooperation.
• Change software configuration and state. In some cases, making a patch take effect necessitates implementing changes
• Resolve any issues. Installing a patch may cause side effects to occur, like inadvertently altering existing security configuration settings or adding new settings, and these side effects can inadvertently create a new security problem while fixing the original one. Patch installation can also cause operational issues that may necessitate uninstalling the patch, reverting to the previous version of the software, or restoring the software or asset.

The principles the NIST want organisations to adopt in their enterprise patch management practices are:

• Problems are inevitable; be prepared for them. Risk responses, including patching, will never be perfect. Some may inadvertently cause operational problems, for example, but most will not. To improve enterprise patch management, organisations need to change their culture so that instead of fearing problems and thus delaying risk responses, personnel are prepared to address problems when they occur. The organization needs to become more resilient, and everyone in the organization needs to understand that problems caused by patching are a necessary inconvenience that helps prevent major
• Simplify decision making. Conducting a risk assessment of each new vulnerability in order to plan the optimal risk response for it is simply not feasible. Organizations do not have the time, resources, expertise, or tools to do so. Planning needs to be done in advance so that when a new vulnerability becomes known, a decision can quickly be made about how to respond to it.
• Rely on automation. There is no way that an organization can keep up with patching without automation because of the sheer number of assets, software installations, vulnerabilities, and patches. Automation is also needed for emergency situations, like patching a severe vulnerability that attackers are actively exploiting. Having automation in place gives an organization agility and scalability when it comes to its risk
• Start improvements Some of the changes that an organisation may need to make might take years to put in place, but that does not mean that other practices cannot be improved in the meantime.

Organisations should define the software vulnerability risk response scenarios they need to be prepared to handle. That includes:

• Routine patching. This is the standard procedure for patches that are on a regular release cycle and have not been elevated to emergency status. Most patching falls under this scenario. However, because routine patching does not have the urgency of emergency scenarios, and routine patch installation can interrupt operations (e.g., device reboots), it is often postponed and neglected. This provides many additional windows of opportunity for attackers. Delaying routine patching also makes emergency patching more difficult, time-consuming, and disruptive because of the need to first install previous patches that new patches depend upon
• Emergency patching. This is the procedure to address patching emergencies in a crisis situation, such as a severe vulnerability or a vulnerability being actively exploited. If one or more of the organization’s vulnerable assets have already been compromised, emergency patching may be part of incident response efforts. Emergency patching needs to be handled as efficiently as possible to prevent the imminent exploitation of vulnerable
• Emergency mitigation. This is the emergency procedure in a crisis situation, like those described above for the emergency patching scenario, to temporarily mitigate vulnerabilities before a patch is available. The mitigation can vary and may or may not need to be rolled back afterward. Emergency mitigations are sometimes needed because of issues with a patch. For example, a patch might be flawed and not actually correct a vulnerability, or a patch might inadvertently disrupt the operation of other software or A patch could even be compromised.
• Unpatchable assets. This is the implementation of isolation or other methods to mitigate the risk of systems that cannot be easily patched. This is typically required if routine patching is not able to accommodate these systems within a reasonable time frame. Examples of why an asset may be unpatchable include the vendor not providing patches (e.g., asset is at end-of-life, asset does not support updates) or an asset needing to run uninterrupted for an extended period of time because it provides mission-critical Unpatchable assets need to be included in risk response planning because a new vulnerability in an asset might necessitate a change in the methods needed to mitigate its risk.

Organizations should define a maintenance plan for each applicable risk response scenario. A maintenance plan defines the actions to be taken when a scenario occurs for a maintenance group, including the timeframes for beginning and ending each action, along with any other pertinent information. Along with the maintenance plans, organizations should define a risk assessment process for determining which plan should be used at any given time and for deciding when to switch from one plan to another as the understanding of risk changes.

NIST believes that what needs to change is the perception that an operational disruption caused by patching is harm that the organisation is doing to itself, while an operational disruption caused by a cybersecurity incident is harm caused by a third party. Disruptions from patching are largely controllable, while disruptions from incidents are largely uncontrollable. Disruptions from patching are also a necessary part of maintaining nearly all types of technology in order to avoid larger disruptions from incidents

SP 1800 – 31

SP 1800-31 builds upon SP 800-40 and provides more detailed guidance. At 206 pages it is very detailed and comprehensive.  It provides information on \how organisations can use commercial tools for routine and emergency patching situations, as well as implementing temporary alternatives to patching.

Patching is the act of applying a change to installed software – such as firmware, operating systems, or applications – that corrects security or functionality problems or adds new capabilities. Despite widespread recognition that patching is effective and attackers regularly exploit unpatched software, many organizations cannot or do not adequately patch. There are myriad reasons why, not the least of which are that it’s resource-intensive and that the act of patching can reduce system and service availability. Also, many organizations struggle to prioritize patches, test patches before deployment, and adhere to policies for how quickly patches are applied in different situations. To address these challenges, the NCCoE collaborated with cybersecurity technology providers to develop an example solution that addresses these challenges. This NIST Cybersecurity Practice Guide explains how tools can be used to implement the patching and inventory capabilities organizations need to handle both routine and emergency patching situations, as well as implement isolation methods or other emergency mitigations as alternatives to patching. It also explains recommended security practices for patch management systems themselves.