NIST approach to patch and vulnerability management By Babby Boss NIST had released Special Publication 800-40 Version

2.0 in November 2005 as guidance on creating a security patch and vulnerability management program and testing its effectiveness. The document contains useful information for those who are responsible for applying patches and deploying solutions. Timely patching of security issues is critical to maintaining the operational availability, confidentiality, and integrity of IT assets. Due to attackers motivation to target known vulnerabilities, and increased frequency of patches released by the software developers, the main concern is to ensure that all applicable patches are timely deployed throughout the organization. As soon as a patch is released, attackers do their best to understand its functionality, identify the vulnerability, and develop and release exploit code. Thus, the time immediately after the patch release is critical because most organizations take longer time in obtaining, testing, and deploying a patch and till then IT assets remain exploitable. To avoid such a situation, the document recommends that: Organizations should create a Patch and Vulnerability Group (PVG) for identification and distribution of patches. The PVG should be comprised of personnel with sufficient knowledge of vulnerability and patch management, system administration, intrusion detection, firewall management, operating systems and applications most used within the organization. The workload of remediation testing and implementation should be transferred from local administrators to the PVG. It would help save money by eliminating duplication of effort and by enabling automated solutions, thereby avoiding expensive manual installations. In case, automated patch management tools are not used, the PVG should closely work with the system administrators and other operations personnel to implement the patch and vulnerability management program throughout the organization. The organization may need several such PVGs depending upon its size and geographical presence. These PVGs could work together in association with each other or could perform their functions in a hierarchical manner under the aegis of a top-level PVG. Typically a PVG should focus on following tasks:
Sr. 1. Task Prepare IT asset inventory Description The PVG should utilize existing inventories of the organizations IT assets to gain knowledge about the hardware and software configuration.

Typically for every IT asset, it would be prudent to collect information about Asset name, Asset tag, Asset owner, Asset administrator, Physical location, Firmware version, Network interfaces, IP address, Ethernet address, Operating System version, Application software, Microprocessor, RAM, Disk space, CD/DVD, Wireless interface, USB interface, etc. The PVG may be required to maintain a manual inventory of IT assets missing in the existing inventories. 2. Monitor for emerging threats, vulnerabilities, and remediation The PVG should continuously monitor vendor web sites and mailing lists, third-party web sites, third-party mailing lists and newsgroups, vulnerability scanners, vulnerability databases, enterprise patch management tools, and other notification tools for emerging threats, vulnerabilities, and remediation information. The PVG should consider each threat and its potential impact when setting priorities for an effective patch process. This evaluation would determine the significance of the threat or vulnerability, existence, extent, and spread of malware, and the risks involved with remediation. Although enterprise patch management tools usually supply a remediation database, still the PVG may need to manually maintain a separate database for IT assets not supported by the patch management tool. The document recommends that: The downloaded patches should be checked against their cryptographic checksums, Pretty Good Privacy (PGP) signatures, or digital certificates for authenticity purpose. Patches should go through a malware scan. Patches and configuration modifications should be tested on non-production systems. Patches should be installed in proper order, because of probable inter-dependencies. Patches should be tested on a selection of systems that accurately represent the configuration of the deployed systems. The PVG should learn about others' experiences about installing or using the patch. If any problem occurs, the PVG should do a cost/benefit analysis. If the remediation is not critical, the PVG may wait until the vendor releases a newer patch that corrects the major issues. Also, the ability to undo or uninstall a patch should be considered.

3.

Prioritize vulnerabilities addressing

4.

Create remediation database

5.

Carry out remediation testing

6.

Deploy vulnerability remediation

PVG should install security patch, adjust configuration of application or security control to block attack vectors and reduce threat of exploitation, and remove unnecessary software or vulnerable services. PVG will prefer to deploy patches using enterprise patch management tools. However, in some cases, the PVG may need to disseminate information regarding vulnerability and remediation directly to local administrators. Information dissemination through e-mail lists and patch distribution through an internal secured website are suggested in case automated patching tools are not used. Automated patching tools allow an administrator to update thousands of IT assets through a single console. Deployment is quite easy in case of homogeneous platforms, with standardized desktop systems and similarly configured servers. These days, a number of applications offer automatic update feature that works in conjunction with the vendors website. This feature is helpful in minimizing the level of effort required to identify, distribute, and install patches. However, to avoid any interference with the existing configuration management process, the organization may setup a local update distribution system so that applications get updates from the local network instead of from the Internet. The remediation success should be verified to confirm that remediation have been conducted appropriately, to avoid any probable security incident or unplanned downtime. This can be done by verifying intended changes in files or configuration settings, by scanning the host with a vulnerability scanner, by reviewing patch logs, and by performing exploit tests. The PVG should guide administrators on how to apply vulnerability remediation.

7.

Disseminate vulnerability and remediation information to administrators

8.

Deploy patches using automated tools

9.

Utilize automatic update features of appropriate applications

10.

Verify remediation

11.

Guide administrators on manual remediation efforts

Organizations should use automated patch management tools. With the increased frequency of patch release and explosive growth of exploit code, manual patch deployment has become an exercise of the past. The integration of patch management tools in the remediation process helps to achieve goal of easy, costeffective, and timely patching of vulnerable IT assets. Thus, the PVG should consider use of enterprise patch management tools for patch deployment.

Organizations should deploy enterprise patch management tools in a phased manner. Implementing patch management tools in a phased manner facilitates potential issues to be addressed early with a small group before full-scale patch deployment. It is recommended to deploy patch management tools first to standardized desktops and equally configured single-platform servers. After successful rollout in the first phase, the organizations should address the more complicated issue of integrating heterogeneous environments, non-standard desktops, legacy systems, and systems with unusual configurations. Despite wide scale use of patch management tools, the need to manually patch variety of IT assets may emerge. Manual methods may need to be used for software not supported by patch management tools, as well for systems with unusual configurations like embedded systems, and industrial control systems. For such systems, there should be a written and implemented procedure for the manual patching process, and the PVG should coordinate with local administrators.

Organizations should assess and mitigate the risks associated with deploying enterprise patch management tools. Enterprise patch management tools can create additional security risks for an organization due to their ability to deploy patches to a large number of IT assets. Once compromised, attackers can misuse these tools to distribute malicious code. Thus, as a primary measure, the organizations should apply standard security techniques to partially mitigate the inherent risks.

Organizations should consider using standardized configurations for IT assets. Maintaining standard configuration of IT assets reduces the patch and vulnerability management efforts. It is easier to manage standard configurations and less expensive to implement a patch and vulnerability management program. Further, those tasked with patch and vulnerability management may not adequately test patches if IT assets use nonstandard configurations. The ineffectiveness of enterprise patch management tools increases in proportion to the complexity of IT environment. If every IT asset is configured uniquely, the side effects of the various patches on the different configurations will be unknown. Organizations should focus standardization efforts on the types of IT assets that make up a significant portion of their IT resources.

Organizations should consistently measure the effectiveness of their patch and vulnerability management program and apply corrective actions as necessary. Implementing this patch and vulnerability management program is not enough, unless organizations continuously monitor its effectiveness. The measurement process helps to demonstrate the adequacy of in-place security controls, policies, and procedures. It also helps to justify security control investments and can be used in identifying necessary

corrective actions for deficient security controls. Variety of patch and vulnerability metrics, suggested in the document, fall into three categories: Susceptibility to attack, Mitigation response time, and Cost. The metrics are as follows.
Sr. 1. Metric category Susceptibility to attack Metric Number of Patches Description The number of patches needed is used to approximating an organizations susceptibility to attack, but its effectiveness is limited because a particular security patch may fix one or many vulnerabilities, and these vulnerabilities may be of varying levels of severity. Measuring the number of vulnerabilities that exist per system is a better measure of an organization's susceptibility to attack. Organizations should consider severity ratings of the vulnerabilities, and the measurement should yield the number of vulnerabilities at each severity level. Each network service indicates a potential set of vulnerabilities, and thus there is an enhanced security risk when systems run additional network services. This metric measures the length of time the PVG takes to learn about a new vulnerability or patch after it is publicly announced.

2.

Number of Vulnerabilities

3.

Number of Network Services Mitigation Response Time Response Time for Vulnerability and Patch Identification Response Time for Patch Application

4.

5.

This metric measures how long it takes to apply a patch to all relevant IT devices within the system. Timing should begin from the moment the PVG becomes aware of a patch. This measurement should be taken on patches where it is relatively easy for the PVG to verify patch installation. This metric applies in situations where vulnerability exists that must be mitigated but where there is no patch. In such cases the organization is forced to make apply compensating controls to protect the organization from exploitation of the vulnerability. When justifying the cost of the PVG to management, it is useful to estimate the amount of system

6.

Response Time for Emergency Configuration Changes Cost Cost of the Patch and

7.

Vulnerability Group 8. Cost of Enterprise Patch and Vulnerability Management Tools Cost of Program Failures

administration efforts that has been saved by centralizing certain functions within the PVG. This metric calculates the total cost of patching tools, vulnerability scanning tools, vulnerability web portals, vulnerability databases, and log analysis tools.

9.

This metric calculates the total cost of the business impact of all preventable security incidents, as well as all problems triggered by the patching process itself, such as a patch inadvertently breaking an application.