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:
`Title:
`
`
`Publication Date(s):
`Withdrawal Date:
`Withdrawal Note:
`
`
`NIST Special Publication 800-40 Version 2.0
`
`Creating a Patch and Vulnerability Management Program
`
`
`November 2005
`
`July 2013
`
`SP 800-40 is superseded by the publication of
`SP 800-40 Revision 3 (July 2013).
`
`
`Superseding Publication(s)
`The attached publication has been superseded by the following publication(s):
`
`Series/Number:
`Title:
`
`
`NIST Special Publication 800-40 Revision 3
`
`Guide to Enterprise Patch Management Technologies
`
`Author(s):
`
`
`Murugiah Souppaya, Karen Scarfone
`
`Publication Date(s):
`URL/DOI:
`
`
`July 2013
`
`http://dx.doi.org/10.6028/NIST.SP.800-40r3
`
`Additional Information (if applicable)
`Contact:
`
`Computer Security Division (Information Technology Lab)
`Latest revision of the
`
`SP 800-40 Revision 3 (as of June 19, 2015)
`attached publication:
`Related information:
`
`
`http://csrc.nist.gov/
`
`Withdrawal
`announcement (link):
`
`
`SP 800-40 Version 2 provides basic guidance on establishing patch
`management programs, and guidance to organizations with legacy needs.
`
`
`Date updated: June (cid:1006)(cid:1007), 2015
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1038
`Page 1 of 76
`
`

`

`Special Publication 800-40
`Version 2.0
`
`Creating a Patch and
`Vulnerability Management
`Program
`
`Recommendations of the National Institute of
`Standards and Technology (NIST)
`
`Peter Mell
`Tiffany Bergeron
`David Henning
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1038
`Page 2 of 76
`
`

`

`NIST Special Publication 800-40
`Version 2.0
`
`Creating a Patch and Vulnerability
`Management Program
`
`Recommendations of the National
`Institute of Standards and Technology
`
`Peter Mell
`Tiffany Bergeron
`David Henning
`
`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
`
`November 2005
`
`U.S. Department of Commerce
`
`Carlos M. Gutierrez, Secretary
`
`Technology Administration
`
`Michelle O'Neill, Acting Under Secretary of Commerce
`for Technology
`
`National Institute of Standards and Technology
`
`William A. Jeffrey, Director
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1038
`Page 3 of 76
`
`

`

`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1038
`Page 4 of 76
`
`

`

`CREATING A PATCH AND VULNERABILITY MANAGEMENT PROGRAM
`
`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 Version 2.0
`Natl. Inst. Stand. Technol. Spec. Publ. 800-40 Ver. 2.0, 75 pages (November 2005)
`
`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 the
`National Institute of Standards and Technology, nor is it intended to imply that the
`entities, materials, or equipment are necessarily the best available for the purpose.
`
`iii
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1038
`Page 5 of 76
`
`

`

`CREATING A PATCH AND VULNERABILITY MANAGEMENT PROGRAM
`
`Acknowledgments
`
`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.
`
`iv
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1038
`Page 6 of 76
`
`

`

`CREATING A PATCH AND VULNERABILITY MANAGEMENT PROGRAM
`
`Table of Contents
`
`2.
`
`Executive Summary..............................................................................................................ES-1
`1.
`Introduction ......................................................................................................................1-1
`1.1 Authority...................................................................................................................1-1
`1.2 Purpose and Scope .................................................................................................1-1
`1.3 Audience ..................................................................................................................1-1
`1.4 Background Information...........................................................................................1-1
`1.5 Document Structure .................................................................................................1-3
`Patch and Vulnerability Management Process .............................................................2-1
`2.1 Recommended Process...........................................................................................2-1
`2.1.1 The Patch and Vulnerability Group...............................................................2-1
`2.1.2 System Administrators..................................................................................2-3
`2.2 Creating a System Inventory....................................................................................2-3
`2.2.1 IT Inventory...................................................................................................2-3
`2.2.2 Grouping and Prioritizing Information Technology Resources .....................2-5
`2.2.3 Use of the IT Inventory and Scope of Related Duties ..................................2-6
`2.3 Monitoring for Vulnerabilities, Remediations, and Threats ......................................2-7
`2.3.1 Types of Security Concerns .........................................................................2-7
`2.3.2 Monitoring Vulnerabilities, Remediations, and Threats ................................2-7
`2.4 Prioritizing Vulnerability Remediation ......................................................................2-8
`2.5 Creating an Organization-Specific Remediation Database......................................2-9
`2.6 Testing Remediations ..............................................................................................2-9
`2.7 Deploying Vulnerability Remediations ...................................................................2-11
`2.8 Distributing Vulnerability and Remediation Information to Administrators .............2-12
`2.9 Verifying Remediation............................................................................................2-13
`2.9.1 Performing Vulnerability Scanning .............................................................2-13
`2.9.2 Reviewing Patch Logs ................................................................................2-14
`2.9.3 Checking Patch Levels ...............................................................................2-15
`2.10 Vulnerability Remediation Training ........................................................................2-15
`2.11 Recommendations .................................................................................................2-15
`Security Metrics for Patch and Vulnerability Management..........................................3-1
`3.1
`Implementing Security Metrics with NIST SP 800-55 ..............................................3-1
`3.2 Metrics Development ...............................................................................................3-1
`3.2.1 Types of Patch and Vulnerability Metrics .....................................................3-1
`3.2.2 Targeting Metrics Towards Program Maturity ..............................................3-5
`3.2.3 Patch and Vulnerability Metrics Table ..........................................................3-7
`3.2.4 Documenting and Standardizing Metrics......................................................3-7
`3.2.5 Performance Targets and Cost Effectiveness ..............................................3-7
`3.3 Metrics Program Implementation .............................................................................3-8
`3.3.1 Starting From Scratch...................................................................................3-8
`3.3.2 False Positives and False Negatives............................................................3-8
`3.4 Recommendations ...................................................................................................3-8
`Patch and Vulnerability Management Issues ................................................................4-1
`4.1 Enterprise Patching Solutions..................................................................................4-1
`4.1.1 Types of Patching Solutions .........................................................................4-1
`4.1.2 Security Risks...............................................................................................4-3
`
`3.
`
`4.
`
`v
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1038
`Page 7 of 76
`
`

`

`CREATING A PATCH AND VULNERABILITY MANAGEMENT PROGRAM
`
`4.1.3 Integrated Software Inventory Capabilities...................................................4-4
`4.1.4 Integrated Vulnerability Scanning Capabilities .............................................4-4
`4.1.5 Deployment Strategies .................................................................................4-5
`4.2 Reducing the Need to Patch Through Smart Purchasing ........................................4-5
`4.3 Using Standardized Configurations .........................................................................4-6
`4.4 Patching After a Security Compromise ....................................................................4-7
`4.5 Recommendations ...................................................................................................4-7
`5. United States Government Patching and Vulnerability Resources ............................5-1
`5.1 US-CERT National Cyber Alert System...................................................................5-1
`5.2 Common Vulnerabilities and Exposures Standard ..................................................5-1
`5.3 National Vulnerability Database...............................................................................5-2
`5.4 US-CERT Vulnerability Notes Database..................................................................5-2
`5.5 Open Vulnerability Assessment Language ..............................................................5-2
`5.6 Recommendations ...................................................................................................5-2
`6. Conclusion and Summary of Major Recommendations...............................................6-1
`
`List of Appendices
`
`Appendix A— Acronyms........................................................................................................ A-1
`Appendix B— Glossary .......................................................................................................... B-1
`Appendix C— Patch and Vulnerability Resource Types..................................................... C-1
`C.1 Vendor Web Sites and Mailing Lists ....................................................................... C-1
`C.2 Third-Party Web Sites............................................................................................. C-2
`C.3 Third-Party Mailing Lists and Newsgroups ............................................................. C-2
`C.4 Vulnerability Scanners ............................................................................................ C-3
`C.5 Vulnerability Databases .......................................................................................... C-4
`C.6 Enterprise Patch Management Tools...................................................................... C-4
`C.7 Other Notification Tools .......................................................................................... C-5
`Appendix D— Patch and Vulnerability Resources .............................................................. D-1
`Appendix E— Index ................................................................................................................ E-1
`
`Figure 3-1. Maturity Levels for System Metrics.........................................................................3-6
`
`List of Figures
`
`Table 3-1. Patch and Vulnerability Metrics ...............................................................................3-7
`
`List of Tables
`
`vi
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1038
`Page 8 of 76
`
`

`

`CREATING A PATCH AND VULNERABILITY MANAGEMENT PROGRAM
`
`Executive Summary
`
`Patch and vulnerability management is a security practice designed to proactively prevent the exploitation
`of IT vulnerabilities that exist within an organization. The expected result is to reduce the time and
`money spent dealing with vulnerabilities and exploitation of those vulnerabilities. Proactively managing
`vulnerabilities of systems will reduce or eliminate the potential for exploitation and involve considerably
`less time and effort than responding after an exploitation has occurred.
`
`Patches are additional pieces of code developed to address problems (commonly called “bugs”) in
`software. Patches enable additional functionality or address security flaws within a program.
`Vulnerabilities are flaws that can be exploited by a malicious entity to gain greater access or privileges
`than it is authorized to have on a computer system. Not all vulnerabilities have related patches; thus,
`system administrators must not only be aware of applicable vulnerabilities and available patches, but also
`other methods of remediation (e.g., device or network configuration changes, employee training) that
`limit the exposure of systems to vulnerabilities.
`
`This document provides guidance on creating a security patch and vulnerability management program and
`testing the effectiveness of that program. The primary audience is security managers who are responsible
`for designing and implementing the program. However, this document also contains information useful
`to system administrators and operations personnel who are responsible for applying patches and
`deploying solutions (i.e., information related to testing patches and enterprise patching software).
`
`Timely patching of security issues is generally recognized as critical to maintaining the operational
`availability, confidentiality, and integrity of information technology (IT) systems. However, failure to
`keep operating system and application software patched is one of the most common issues identified by
`security and 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 and ensure proper deployment in
`a timely manner. Most major attacks in the past few years have targeted known vulnerabilities for which
`patches existed before the outbreaks. Indeed, the moment a patch is released, attackers make a concerted
`effort to reverse engineer the patch swiftly (measured in days or even hours), identify the vulnerability,
`and develop and release exploit code. Thus, the time immediately after the release of a patch is ironically
`a particularly vulnerable moment for most organizations due to the time lag in obtaining, testing, and
`deploying a patch.
`
`To help address this growing problem, it is recommended that all organizations have a systematic,
`accountable, and documented process for managing exposure to vulnerabilities through the timely
`deployment of patches. This document describes the principles and methodologies organizations can use
`to accomplish this. Organizations should be aware that applying patches and mitigating vulnerabilities is
`not a straightforward process, even in organizations that utilize a formal patch and vulnerability
`management process. To help with the operational issues related to patch application, this document
`covers areas such as prioritizing, obtaining, testing, and applying patches. It also discusses testing the
`effectiveness of the patching program and suggests a variety of metrics for that purpose.
`
`NIST recommends that Federal agencies implement the following recommendations to assist in patch and
`vulnerability management. Personnel responsible for these duties should read the corresponding sections
`of the document to ensure they have an adequate understanding of important related issues.
`
`ES-1
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1038
`Page 9 of 76
`
`

`

`CREATING A PATCH AND VULNERABILITY MANAGEMENT PROGRAM
`
`Organizations should create a patch and vulnerability group (PVG) to facilitate the identification
`and distribution of patches within the organization.
`
`The PVG should be specially tasked to implement the patch and vulnerability management program
`throughout the organization. The PVG is the central point for vulnerability remediation efforts, such as
`OS and application patching and configuration changes. Since the PVG needs to work actively with local
`administrators, large organizations may need to have several PVGs; they could work together or be
`structured hierarchically with an authoritative top-level PVG. The duties of a PVG should include the
`following:
`
`1.
`
`Inventory the organization’s IT resources to determine which hardware equipment, operating
`systems, and software applications are used within the organization.
`
`2. Monitor security sources for vulnerability announcements, patch and non-patch remediations, and
`emerging threats that correspond to the software within the PVG’s system inventory.
`
`3. Prioritize the order in which the organization addresses remediating vulnerabilities.
`
`4. Create a database of remediations that need to be applied to the organization.
`
`5. Conduct testing of patches and non-patch remediations on IT devices that use standardized
`configurations.
`
`6. Oversee vulnerability remediation.
`
`7. Distribute vulnerability and remediation information to local administrators.
`
`8. Perform automated deployment of patches to IT devices using enterprise patch management
`tools.
`
`9. Configure automatic update of applications whenever possible and appropriate.
`
`10. Verify vulnerability remediation through network and host vulnerability scanning.
`
`11. Train administrators on how to apply vulnerability remediations.
`
`Organizations should use automated patch management tools to expedite the distribution of
`patches to systems.
`
`Widespread manual patching of computers is becoming ineffective as the number of patches that need to
`be installed grows and as attackers continue to develop exploit code more rapidly. While patching and
`vulnerability monitoring can often appear an overwhelming task, consistent mitigation of organizational
`vulnerabilities can be achieved through a tested and integrated patching process that makes efficient use
`of automated patching technology. Enterprise patch management tools allow the PVG, or a group they
`work closely with, to automatically push patches out to many computers quickly. All moderate to large
`organizations should be using enterprise patch management tools for the majority of their computers.
`Even small organizations should be migrating to some form of automated patching tool.
`
`Organizations should deploy enterprise patch management tools using a phased approach.
`
`Implementing patch management tools in phases allows process and user communication issues to be
`addressed with a small group before deploying the patch application universally. Most organizations
`
`ES-2
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1038
`Page 10 of 76
`
`

`

`CREATING A PATCH AND VULNERABILITY MANAGEMENT PROGRAM
`
`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; examples include embedded systems, industrial control systems, medical
`devices, and experimental systems. For such computers, there should be a written and implemented
`procedure for the manual patching process, and the PVG should coordinate local administrator efforts.
`
`Organizations should assess and mitigate the risks associated with deploying enterprise patch
`management tools.
`
`Although enterprise patch management tools can be very effective at reducing risk, they can also create
`additional security risks for an organization. For example, an attacker could break into the central patch
`management computer and use the enterprise patch management tool as a way to distribute malicious
`code efficiently. Organizations should partially mitigate these risks through the application of standard
`security techniques that should be used when deploying any enterprise-wide application.
`
`Organizations should consider using standardized configurations for IT resources.
`
`Having standardized configurations within the IT enterprise will reduce the labor related to patch and
`vulnerability management. Organizations with standardized configurations will find it much easier and
`less costly to implement a patch and vulnerability management program. Also, the PVG may not be able
`to test patches adequately if IT devices use nonstandard configurations. Enterprise patch management
`tools may be ineffective if deployed within an environment where every IT device is configured uniquely,
`because the side effects of the various patches on the different configurations will be unknown.
`Comprehensive patch and vulnerability management is almost impossible within large organizations that
`do not deploy standard configurations. Organizations should focus standardization efforts on the types of
`IT resources that make up a significant portion of their IT resources. NIST Special Publication 800-70,
`Security Configuration Checklists Program for IT Products—Guidance for Checklists Users and
`Developers, provides guidance on creating and using security configuration checklists, which are helpful
`tools for standardization.
`
`Organizations should consistently measure the effectiveness of their patch and vulnerability
`management program and apply corrective actions as necessary.
`
`Patch and vulnerability metrics fall into three categories: susceptibility to attack, mitigation response
`time, and cost, which includes a metric for the business impact of program failures. The emphasis on
`patch and vulnerability metrics being taken for a system or IT security program should reflect the patch
`and vulnerability management maturity level. For example, attack susceptibility metrics such as the
`number of patches, vulnerabilities, and network services per system are generally more useful for a
`program with a low maturity level than a high maturity level. Organizations should document what
`metrics will be taken for each system and the details of each of those metrics. Realistic performance
`targets for each metric should be communicated to system owners and system security officers. Once
`these targets have been achieved, more ambitious targets can be set. It is important to carefully raise the
`bar on patch and vulnerability security to avoid overwhelming system security officers and system
`administrators.
`
`ES-3
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1038
`Page 11 of 76
`
`

`

`CREATING A PATCH AND VULNERABILITY MANAGEMENT PROGRAM
`
`This page has been left blank intentionally.
`
`ES-4
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1038
`Page 12 of 76
`
`

`

`CREATING A PATCH AND VULNERABILITY MANAGEMENT PROGRAM
`
`1.
`
`Introduction
`
`1.1 Authority
`
`The National Institute of Standards and Technology (NIST) developed this document in furtherance of its
`statutory responsibilities under the Federal Information Security Management Act (FISMA) of 2002,
`Public Law 107-347.
`
`NIST is responsible for developing standards and guidelines, including minimum requirements, for
`providing adequate information security for all agency systems;1 but such standards and guidelines shall
`not apply to national security 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 A-130, Appendix IV: Analysis of Key Sections. Supplemental information is
`provided in A-130, Appendix III.
`
`This guideline has been prepared for use by Federal agencies. It may be used by nongovernmental
`organizations on a voluntary basis and is not subject to copyright, though attribution is desired.
`
`Nothing in this document should be taken to contradict 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.
`
`1.2 Purpose and Scope
`
`This publication is designed to assist organizations in implementing security patch and vulnerability
`remediation programs. It focuses on how to create an organizational process and test the effectiveness of
`the process. It also seeks to inform the reader about the technical solutions that are available for
`vulnerability remediation.
`
`1.3 Audience
`
`This document is intended to be used primarily by security managers responsible for designing and
`implementing security patch and vulnerability remediation programs. However, it also contains
`information of use to system administrators and security operations personnel who are responsible for
`applying patches and deploying solutions (e.g., information on testing patches and enterprise patching
`software).
`
`1.4 Background Information
`
`From July 2003 through June 2005, the average number of published computer vulnerabilities was 2513
`per year, or nearly seven each day.2 Even a small organization with a single server can expect to spend
`time reviewing a handful of critical patches per month. This stream of vulnerabilities has resulted in
`systems constantly being threatened by new attacks.
`
`1
`
`2
`
`The word “systems” refers to a set of information technology (IT) assets, processes, applications, and related IT resources
`that are under the same direct management and budgetary control; have the same function or mission objective; have
`essentially the same security needs; and reside in the same general operating environment. All IT systems are either of the
`type “General Support” or “Major Application” as specified by NIST Special Publication 800-18.
`The source for this information is the National Vulnerability Database, which is available at http://nvd.nist.gov/.
`
`1-1
`
`Code200, UAB v. Bright Data Ltd.
`Code 200's Exhibit 1038
`Page 13 of 76
`
`

`

`CREATING A PATCH AND VULNERABILITY MANAGEMENT PROGRAM
`
`The level of damage caused by an attack can be quite severe. A number of Internet worms (self-
`propagating code that exploits vulnerabilities over the Internet) such as Code Red, Nimda, Blaster, and
`MyDoom have been released in recent years. There are some common data points for these worm
`outbreaks. First, as the authors of worm code have gotten more sophisticated, the worms have been able
`to spread faster than their predecessors. Second, they each hit hundreds of thousands of computers
`worldwide. Most importantly, each one of them attacked a known vulnerability for which a patch or
`other mitigation steps had already been released.3 Each major outbreak was preventable.
`
`Benjamin Franklin once said that “an ounce of prevention equals a pound of cure.” Patch and
`vulnerability management is the “ounce of prevention” compared to the “pound of cure” that is incident
`response. The decision on how and when to mitigate via patching or other remediation methods should
`come from a comparison of time, resources, and money to be spent. For example, assume that a new
`computer worm is released that can spread rapidly and damage any workstation in the organization unless
`it is stopped. The potential cost to not mitigate is described by the following equation:
`
`Cost not to mitigate = W * T * R, where (W) is the number of workstations, (T) is the time spent
`fixing systems or lost in productivity, and (R) is the hourly rate of the time spent.4
`
`For an organization where there are 1000 computers to be fixed, each taking an average of 8 hours of
`downtime (4 hours for one worker to rebuild a system, plus 4 hours the computer owner is without a
`computer to do work) at a rate of $70/hour for wages and benefits:
`
`1000 computers * 8 hours * $70/hour = $560,000 to respond after an attack.
`
`Compare this to the cost of manual monitoring and prevention. Assume the vulnerability exploited by the
`worm and the corresponding patch are announced in advance of the worm being created. This has been
`accurate for exploits historically, as true zero day attacks are not frequent. Manually monitoring for new
`patches for a single workstation type takes as little as 10 minutes each day, or 60.8 hours/year. Applying
`a workstation patch generally takes no more than 10 minutes. This makes the cost equation:
`
`60.8 hours monitoring * $70/hour = $4,256 monitoring cost per year
`
`0.16 hours patching * 1,000 computers @ $70/hour = $11,200 to manually apply each patch
`
`Total cost to maintain the systems = $4,256 + $11,200/patch.
`
`For any single vulnerability for which a widespread worm will be created, manual monitoring and
`patching is much more cost-effective than responding to a worm infection. However, given that patches
`are constantly released, manual patching becomes prohibitively expensive unless the operating
`environment consists of only a few software packages (thus decreasing the total number of patches
`needed) or the organization relies on end users to patch their systems (thus distributing the patching
`workload, but also introducing a need for patch installation oversight). Since few organizations use a
`small number of software packages or can rely on end users to effectively patch systems, widespread
`manual patching is not a cost-effective organizational approach.5
`
`3
`
`4
`
`Since the late 1990’s, the length of time between the announcement of a new major vulnerability and the release of a new
`exploit has dropped from months to weeks or days.
`In addition to the costs identified through this formula, a security incident could also cause damage to an organization’s
`repu