Archived NIST Technical Series Publication
Total Page：16
File Type：pdf, Size：1020Kb
Archived NIST Technical Series Publication The attached publication has been archived (withdrawn), and is provided solely for historical purposes. It may have been superseded by another publication (indicated below). Archived Publication Series/Number: NIST Special Publication 800-40 Title: Procedures for Handling Security Patches Publication Date(s): August 2002 Withdrawal Date: November 2005 Withdrawal Note: SP 800-40 is superseded in its entirety by the publication of SP 800-40 Version 2.0 (November 2005). Superseding Publication(s) The attached publication has been superseded by the following publication(s): Series/Number: NIST Special Publication 800-40 Version 2.0 Title: Creating a Patch and Vulnerability Management Program Author(s): Peter Mell, Tiffany Bergeron, David Henning Publication Date(s): November 2005 URL/DOI: http://dx.doi.org/10.6028/NIST.SP.800-40ver2 Additional Information (if applicable) Contact: Computer Security Division (Information Technology Lab) Latest revision of the SP 800-40 Revision 3 (as of August 7, 2015) attached publication: Related information: http://csrc.nist.gov/ Withdrawal SP 800-40 Version 2 provides basic guidance on establishing patch announcement (link): management programs, and guidance to organizations with legacy needs. Date updated: ƵŐƵƐƚϳ, 2015 NIST Special Publication 800-40 Procedures for Handling Security Patches Recommendations of the National Institute of Standards and Technology Peter Mell and Miles C. Tracy NIST Special Publication 800-40 Procedures for Handling Security Patches Recommendations of the National Institute of Standards and Technology Peter Mell and Miles C. Tracy C O M P U T E R S E C U R I T Y Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930 August 2002 U.S. Department of Commerce Donald L. Evans, Secretary Technology Administration Phillip J. Bond, Under Secretary for Technology National Institute of Standards and Technology Arden L. Bement, Jr., Director ii 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 analysis to advance the development and productive use of information technology. ITL’s responsibilities include the development of technical, physical, administrative, and management standards and guidelines for the cost-effective security and privacy of sensitive unclassified information in Federal computer systems. This Special Publication 800-series reports on ITL’s research, guidance, and outreach efforts in computer security and its collaborative activities with industry, government, and academic organizations. National Institute of Standards and Technology Special Publication 800-40 Natl. Inst. Stand. Technol. Spec. Publ. 800-40, xx pages (Mon. 2002) CODEN: XXXXX 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 endorsem ent by the National Institute of Standards and Technology, nor is it intended to imply that the entities, materials, or equipment are necessarily the best av ailable for the purpose. U.S. GOVERNMENT PRINTING OFFICE WASHINGTON: 2002 For sale by the Superintendent of Documents, U.S. Government Printing Office Internet: bookstore.gpo.gov — Phone: (202) 512-1800 — Fax: (202) 512-2250 Mail: Stop SSOP, Washington, DC 20402-0001 iii Executive Summary Timely patching is critical to maintain the operational availability, confidentiality, and integrity of information technology (IT) systems. However, failure to keep operating system and application software patched is the most common mistake made by IT professionals. New patches are released daily, and it is often difficult for even experienced system administrators to keep abreast of all the new patches. Vulnerabilities are weaknesses in software that can be exploited by a malicious entity to gain greater access and/or permission than it is authorized to have on a computer. Not all vulnerabilities have related patches; thus, system administrators must not only be aware of vulnerabilities and patches, but also mitigate “unpatched” vulnerabilities through other methods (e.g. workarounds, firewalls, and router access control lists). To help address this growing problem, we recommend that organizations have an explicit and documented patching and vulnerability policy and a systematic, accountable, and documented process for handling patches. This document provides principles and methodologies for accomplishing this. One of several possible techniques is through the creation of a patch and vulnerability group (PVG). This group would facilitate the identification and distribution of patches within the organization. Its duties should include: 1. Creating an organizational hardware and software inventory 2. Identifying newly discovered vulnerabilities and security patches 3. Prioritizing patch application 4. Creating an organization-specific patch database 5. Testing patches for functionality and security (to the degree that resources allow) 6. Distributing patch and vulnerability information to local administrators 7. Verifying patch installation through network and host vulnerability scanning 8. Training system administrators in the use of vulnerability databases 9. Deploying patches automatically (when applicable) 10. Configure Automatic Update of Applications (when applicable). If organizations use the PVG approach, this would not diminish the responsibility of all systems administrators to patch the systems under their control. Each systems administrator would: 1. Apply patches identified by the PVG 2. Test patches on the specific target systems 3. Identify patches and vulnerabilities associated with software not monitored by the PVG Besides creating a PVG, organizations should be aware that applying patches and mitigating vulnerabilities is not always a straightforward process. To help with this, our document covers areas such as prioritizing patches, obtaining patches, testing patches, and applying patches. iv Acknowledgements The authors, Peter Mell of NIST and Miles Tracy of Booz Allen Hamilton (BAH) wish to express their thanks to Timothy Grance, John Wack, and Murugiah Souppaya of NIST and Alexis Feringa, Jennifer Tracy, Jonathan Holleran, Mark McLarnon, and Brian Kim of BAH for their research, technical support, and written contributions to this document. The authors would also like to express their thanks to all those who contributed input during the public comment period. v Applying Security Patches – Draft 3.0– 06/06/2002 Table of Contents 1. INTRODUCTION ............................................................................................................ 1 1.1 AUTHORITY ...................................................................................................................... 2 1.2 PURPOSE AND SCOPE........................................................................................................ 2 1.3 OBJECTIVE ........................................................................................................................ 3 1.4 AUDIENCE AND ASSUMPTIONS......................................................................................... 3 1.5 DOCUMENT STRUCTURE .................................................................................................. 3 2. CREATING AND IMPLEMENTING A PATCHING PROCESS.......................... 5 2.1 THE PATCH AND VULNERABILITY GROUP....................................................................... 5 2.2 SYSTEMS ADMINISTRATOR PATCHING RESPONSIBILITIES .............................................. 8 3. IDENTIFYING VULNERABILITIES AND APPLICABLE PATCHES ............ 10 3.1 VENDOR WEBSITES AND MAILING LISTS ...................................................................... 11 3.2 THIRD-PARTY WEBSITES ............................................................................................... 12 3.3 THIRD-PARTY MAILING LISTS AND NEWSGROUPS ....................................................... 13 3.4 VULNERABILITY SCANNERS........................................................................................... 14 3.5 VULNERABILITY DATABASES ........................................................................................ 16 3.6 OTHER NOTIFICATION TOOLS ........................................................................................ 17 4. GOVERNMENT VULNERABILITY IDENTIFICATION RESOURCES......... 19 4.1 CVE VULNERABILITY LIST............................................................................................ 19 4.2 NIST ICAT VULNERABILITY INDEX ............................................................................. 20 4.3 NATIONAL INFRASTRUCTURE PROTECTION CENTER .................................................... 21 4.4 CERT/CC....................................................................................................................... 23 4.5 FEDERAL COMPUTER INCIDENT RESPONSE CENTER (FEDCIRC)................................. 24 5. PATCHING PROCEDURES ....................................................................................... 26 5.1 PATCHING PRIORITIES ...................................................................................................