Enterprise Network Security Good news: The media and entertainment company you work for has decided to acquire a media streaming company to complement the business. That means there’s a nee

Date updated: April 6, 2022

Withdrawn NIST Technical Series Publication

Warning Notice

The attached publication has been withdrawn (archived), and is provided solely for historical purposes. It may have been superseded by another publication (indicated below).

Withdrawn Publication

Series/Number NIST Special Publication 800-40 Rev. 3 Title Guide to Enterprise Patch Management Technologies Publication Date(s) July 2013 Withdrawal Date April 6, 2022 Withdrawal Note SP 800-40 Rev. 3 is superseded in its entirety by the publication of SP 800-40

Rev. 4.

Superseding Publication(s) (if applicable)

The attached publication has been superseded by the following publication(s):

Series/Number NIST Special Publication 800-40 Rev. 4 Title Guide to Enterprise Patch Management Planning: Preventive Maintenance for

Technology Author(s) Murugiah Souppaya; Karen Scarfone Publication Date(s) April 2022 URL/DOI https://doi.org/10.6028/NIST.SP.800-40r4

Additional Information (if applicable)

Contact Computer Security Division (Information Technology Laboratory) Latest revision of the attached publication

Related Information https://csrc.nist.gov/publications/detail/sp/800-40/rev-4/final Withdrawal Announcement Link

NIST Special Publication 800-40 Revision 3

Guide to Enterprise Patch Management Technologies

Murugiah Souppaya Karen Scarfone

C O M P U T E R S E C U R I T Y

NIST Special Publication 800-40 Revision 3

Guide to Enterprise Patch Management Technologies

Murugiah Souppaya

Computer Security Division Information Technology Laboratory

Karen Scarfone

Scarfone Cybersecurity Clifton, VA

July 2013

U.S. Department of Commerce

Penny Pritzker, Secretary

National Institute of Standards and Technology Patrick D. Gallagher, Under Secretary of Commerce for Standards and Technology and Director

ii

Authority

This publication has been developed by NIST to further its statutory responsibilities under the Federal Information Security Management Act (FISMA), Public Law (P.L.) 107-347. NIST is responsible for developing information security standards and guidelines, including minimum requirements for Federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate Federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), Securing Agency Information Systems, as analyzed in Circular A- 130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in Circular A-130, Appendix III, Security of Federal Automated Information Resources.

Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on Federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other Federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.

National Institute of Standards and Technology Special Publication 800-40 Revision 3 Natl. Inst. Stand. Technol. Spec. Publ. 800-40 Rev. 3, 26 pages (July 2013)

http://dx.doi.org/10.6028/NIST.SP.800-40r3 CODEN: NSPUE2

Comments on this publication may be submitted to:

National Institute of Standards and Technology Attn: Computer Security Division, Information Technology Laboratory

100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930

Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose.

There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by Federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, Federal agencies may wish to closely follow the development of these new publications by NIST.

Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. All NIST Computer Security Division publications, other than the ones noted above, are available at http://csrc.nist.gov/publications.

iii

Reports on Computer Systems Technology

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in Federal information systems. The Special Publication 800-series reports on ITL’s research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations.

Abstract

Patch management is the process for identifying, acquiring, installing, and verifying patches for products and systems. Patches correct security and functionality problems in software and firmware. There are several challenges that complicate patch management. If organizations do not overcome these challenges, they will be unable to patch systems effectively and efficiently, leading to easily preventable compromises. This publication is designed to assist organizations in understanding the basics of enterprise patch management technologies. It explains the importance of patch management and examines the challenges inherent in performing patch management. This publication also provides an overview of enterprise patch management technologies and briefly discusses metrics for measuring the technologies’ effectiveness and for comparing the relative importance of patches.

Keywords

information security; patch management; remediation; software patches; vulnerability management

iv

Acknowledgments

The authors, Murugiah Souppaya of the National Institute of Standards and Technology (NIST) and Karen Scarfone of Scarfone Cybersecurity, wish to thank their colleagues who reviewed drafts of this document and contributed to its technical content, particularly Peter Mell of NIST.

Acknowledgments, Version 2

The authors, Peter Mell of NIST, Tiffany Bergeron of The MITRE Corporation, and David Henning of Hughes Network Systems, LLC, wish to express their thanks to Rob Pate of the United States Computer Emergency Readiness Team (US-CERT) for providing support for this publication. In addition, the authors would like to thank Miles Tracy of the U.S. Federal Reserve System, who co-authored the original version of the publication and provided significant input for this version, and Tanyette Miller of Booz Allen Hamilton, who put together the patching resources found in the appendices. The authors would also like to express their thanks to Timothy Grance of NIST, Manuel Costa and Todd Wittbold of The MITRE Corporation, Matthew Baum of the Corporation for National and Community Service, and Karen Kent of Booz Allen Hamilton for their insightful reviews, and to representatives from Department of Health and Human Services, Department of State, Environmental Protection Agency, Federal Reserve Board, and PatchAdvisor for their particularly valuable comments and suggestions.

Trademark Information

Microsoft and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and other countries.

All other names are registered trademarks or trademarks of their respective companies.

v

Table of Contents Executive Summary …………………………………………………………………………………………………..vi 1. Introduction ………………………………………………………………………………………………………. 1

1.1 Document Purpose and Scope ………………………………………………………………………. 1 1.2 Audience ……………………………………………………………………………………………………. 1 1.3 Document Structure …………………………………………………………………………………….. 1

2. The Importance of Patch Management ………………………………………………………………… 2

3. The Challenges of Patch Management ………………………………………………………………… 3

3.1 Timing, Prioritization, and Testing…………………………………………………………………… 3 3.2 Patch Management Configuration ………………………………………………………………….. 4 3.3 Alternative Host Architectures ……………………………………………………………………….. 5 3.4 Other Challenges ………………………………………………………………………………………… 6

3.4.1 Software Inventory Management …………………………………………………………. 6 3.4.2 Resource Overload …………………………………………………………………………… 6 3.4.3 Installation Side Effects ……………………………………………………………………… 6 3.4.4 Patch Implementation Verification ……………………………………………………….. 6 3.4.5 Application Whitelisting ……………………………………………………………………… 7

4. Enterprise Patch Management Technologies……………………………………………………….. 8

4.1 Components and Architecture ……………………………………………………………………….. 8 4.1.1 Agent-Based ……………………………………………………………………………………. 8 4.1.2 Agentless Scanning ………………………………………………………………………….. 8 4.1.3 Passive Network Monitoring ……………………………………………………………….. 9 4.1.4 Comparison of Techniques ………………………………………………………………… 9

4.2 Security Capabilities …………………………………………………………………………………….. 9 4.2.1 Inventory Management Capabilities …………………………………………………….10 4.2.2 Patch Management Capabilities ………………………………………………………….10 4.2.3 Other Capabilities ……………………………………………………………………………..10

4.3 Management Capabilities ……………………………………………………………………………. 10 4.3.1 Technology Security ………………………………………………………………………….10 4.3.2 Phased Deployment ………………………………………………………………………….11 4.3.3 Usability and Availability …………………………………………………………………….11

5. Metrics ……………………………………………………………………………………………………………..12

List of Appendices Appendix A— Security Content Automation Protocol (SCAP) Tutorial …………………………14

Appendix B— Summary of Recommendations …………………………………………………………..16

Appendix C— Acronyms and Abbreviations ………………………………………………………………18

GUIDE TO ENTERPRISE PATCH MANAGEMENT TECHNOLOGIES

vi

Executive Summary

Patch management is the process for identifying, acquiring, installing, and verifying patches for products and systems. Patches correct security and functionality problems in software and firmware. From a security perspective, patches are most often of interest because they are mitigating software flaw vulnerabilities; applying patches to eliminate these vulnerabilities significantly reduces the opportunities for exploitation. Patches serve other purposes than just fixing software flaws; they can also add new features to software and firmware, including security capabilities.

There are several challenges that complicate patch management. Organizations that do not overcome these challenges will be unable to patch systems effectively and efficiently, leading to compromises that were easily preventable. Organizations that can minimize the time they spend dealing with patching can use those resources for addressing other security concerns. Already many organizations have largely operationalized their patch management, making it more of a core IT function than a part of security. However, it is still important for all organizations to carefully consider patch management in the context of security because patch management is so important to achieving and maintaining sound security.

This publication is designed to assist organizations in understanding the basics of enterprise patch management technologies. It explains the importance of patch management and examines the challenges inherent in performing patch management. The publication also provides an overview of enterprise patch management technologies and briefly discusses metrics for measuring the technologies’ effectiveness and for comparing the relative importance of patches.

Organizations should implement the following recommendations to improve the effectiveness and efficiency of their enterprise patch management technologies.

Organizations should deploy enterprise patch management tools using a phased approach.

This approach allows process and user communication issues to be addressed with a small group before deploying the patch application universally. Most organizations deploy patch management tools first to standardized desktop systems and single-platform server farms of similarly configured servers. Once this has been accomplished, organizations should address the more difficult issue of integrating multiplatform environments, nonstandard desktop systems, legacy computers, and computers with unusual configurations. Manual methods may need to be used for operating systems and applications not supported by automated patching tools, as well as some computers with unusual configurations.

Organizations should reduce the risks associated with enterprise patch management tools through the application of standard security techniques that should be used when deploying any enterprise- wide application.

Deploying enterprise patch management tools within an enterprise can create additional security risks for an organization; however, a much greater risk is faced by organizations that do not effectively patch their systems. Such tools usually increase security far more than they decrease security, especially when the tools contain built-in security measures to protect against security risks and threats. Risk associated with these tools include patches being altered, credentials being misused, vulnerabilities in the tools being exploited, and entities monitoring tool communications to identify vulnerabilities. Examples of possible countermeasures to these risks include keeping the patching solution components tightly secured and up- to-date, encrypting network communications, verifying the integrity of patches before installing them, and testing patches before deployment.

GUIDE TO ENTERPRISE PATCH MANAGEMENT TECHNOLOGIES

vii

Organizations should balance their security needs with their needs for usability and availability.

For example, installing a patch may “break” other applications; this can best be addressed by testing patches before deployment. Another example is that forcing application restarts, operating system reboots, and other host state changes is disruptive and could cause loss of data or services. Again, organizations need to balance the need to get patches applied with the need to support operations. A final example, particularly important for mobile devices, is the acquisition of updates over low-bandwidth or metered connections; it may be technically or financially infeasible to download large patches over such connections. Organizations should make provisions for ensuring that their enterprise patching solution works for mobile hosts and other hosts used on low-bandwidth or metered networks.

GUIDE TO ENTERPRISE PATCH MANAGEMENT TECHNOLOGIES

1

1. Introduction

1.1 Document Purpose and Scope

This publication is designed to assist organizations in understanding the basics of enterprise patch management technologies. This publication is based on the assumption that the organization has a mature patch management capability and is focused on increasing its automation level. Organizations that are seeking more basic guidance on establishing patch management programs or have legacy needs that cannot be met with current enterprise patch management technologies should, in addition to reading this publication, also consult the previous complementary version, NIST SP 800-40 Version 2, Creating a Patch and Vulnerability Management Program.1

1.2 Audience

This document has been created for security managers, engineers, administrators, and others who are responsible for acquiring, testing, prioritizing, implementing, and verifying security patches. Auditors and others who need to assess the security of systems may also find this publication useful.

1.3 Document Structure

This document is organized into the following sections and appendices:

• Section 2 explains the importance of patch management.

• Section 3 examines the challenges inherent in performing patch management.

• Section 4 provides an overview of enterprise patch management technologies.

• Section 5 briefly discusses possible metrics for measuring the effectiveness of patch management technologies and for comparing the relative importance of patches.

• Appendix A provides a tutorial on the Security Content Automation Protocol (SCAP) and its role in enterprise patch management.

• Appendix B provides a summary of the main recommendations made throughout the publication.

• Appendix C defines selected acronyms and other abbreviations for the document.

1 http://csrc.nist.gov/publications/nistpubs/800-40-Ver2/SP800-40v2.pdf

GUIDE TO ENTERPRISE PATCH MANAGEMENT TECHNOLOGIES

2

2. The Importance of Patch Management

Patch management is the process for identifying, acquiring, installing, and verifying patches for products and systems. Patches correct security and functionality problems in software and firmware. From a security perspective, patches are most often of interest because they are mitigating software flaw vulnerabilities; applying patches to eliminate these vulnerabilities significantly reduces the opportunities for exploitation. Also, patches are usually the most effective way to mitigate software flaw vulnerabilities, and are often the only fully effective solution. Sometimes there are alternatives to patches, such as temporary workarounds involving software or security control reconfiguration, but these workarounds often negatively impact functionality.

Patches serve other purposes than just fixing software flaws; they can also add new features to software and firmware, including security capabilities. New features can also be added through upgrades, which bring software or firmware to a newer version in a much broader change than just applying a patch. Upgrades may also fix security and functionality problems in previous versions of software and firmware. Also, vendors often stop supporting older versions of their products, which includes no longer releasing patches to address new vulnerabilities, thus making older unsupported versions less secure over time. Upgrades are then necessary to get such products to a supported version that is patched and that has ongoing support for patching newly discovered vulnerabilities.

As Section 3 explains, there are several challenges that complicate patch management. Organizations that do not overcome these challenges will be unable to patch systems effectively and efficiently, leading to compromises that are easily preventable. Organizations that can minimize the time they spend dealing with patching can use those resources for addressing other security concerns. Already many organizations have largely operationalized their patch management, making it more of a core IT function than a part of security. However, it is still important for all organizations to carefully consider patch management in the context of security because patch management is so important to achieving and maintaining sound security.

Patch management is required by various security compliance frameworks, mandates, and other policies. For example, NIST Special Publication (SP) 800-532 requires the SI-2, Flaw Remediation security control, which includes installing security-relevant software and firmware patches, testing patches before installing them, and incorporating patches into the organization’s configuration management processes. Another example is the Payment Card Industry (PCI) Data Security Standard (DSS)3, which requires that the latest patches be installed and sets a maximum timeframe for installing the most critical patches.

2 http://csrc.nist.gov/publications/PubsSPs.html#800-53-rev4 3 https://www.pcisecuritystandards.org/security_standards/

GUIDE TO ENTERPRISE PATCH MANAGEMENT TECHNOLOGIES

3

3. The Challenges of Patch Management

This section briefly examines the challenges inherent in performing patch management. These are the challenges that the patch management technologies discussed in Section 4 are trying to solve.

3.1 Timing, Prioritization, and Testing

Timing, prioritization, and testing are intertwined issues for enterprise patch management. Ideally, an organization would deploy every new patch immediately to minimize the time that systems are vulnerable to the associated software flaws. However, in reality this is simply not possible because organizations have limited resources, which makes it necessary to prioritize which patches should be installed before other patches. Further complicating this is the significant risk of installing patches without first testing them, which could cause serious operational disruptions, potentially even more damaging than the corresponding security impact of not pushing the patches out. Unfortunately, testing patches consumes even more of an organization’s limited resources and makes patch prioritization even more important. For patch management, timing, prioritization, and testing are often in conflict.

Product vendors have responded to this conflict by improving the quality of their patches and bundling patches for their products. Instead of releasing dozens of patches one at a time over a period of three months, necessitating testing and patch deployment every few days, a vendor might release their patches in a single bundle once a quarter. This allows an organization to perform testing once and roll out patches once, which is far more efficient than testing and rolling out all the patches separately. It also reduces the need to prioritize patches—the organization just needs to prioritize the bundle instead of separately prioritizing each patch it contains. Vendors who bundle patches tend to release them monthly or quarterly, except for cases when an unpatched vulnerability is actively being exploited, in which case they usually issue the appropriate patch immediately instead of delaying it for the next bundle.

There is a downside to patch bundling; it lengthens the time from when a vulnerability is discovered to the time a patch for it becomes publicly available. If an attacker discovers the same vulnerability before the patch is released, the attacker may have a longer window of opportunity to exploit the vulnerability because of the intentional delay in releasing the patch. However, there are two mitigating factors here. One is that if exploitation is known to be occurring, the vendor is likely to release the patch immediately. The other factor is that patches may be installed more quickly if they are bundled than if they are all released separately. So operationally, bundling patches may effectively shrink the window of opportunity for vulnerabilities in some environments.

There are even more issues to consider with timing. The release of a patch may provide attackers with the information that they need to exploit the corresponding vulnerability (e.g., reverse engineer the vulnerability from the patch), meaning that a newly released patch might need to be applied immediately to avoid compromises. However, if a vulnerability is not being exploited yet, organizations should carefully weigh the security risks of not patching with the operational risks of patching without first performing thorough testing. In some operational environments, such as virtual hosts with snapshot capabilities enabled, it may be preferable to patch without testing as long as the organization is fully prepared to roll back the patches if they cause usability or functionality problems.

Another fundamental issue with timing is that to make a patch take effect, it may be necessary to force the implementation of