Special Publication 800-61
`
`Revision 2
`
`Computer Security
`
`Incident Handling Guide
`
`Recommendations of the National Institute
`of Standards and Technology
`
`Paul Cichonski
`Tom Millar
`Tim Grance
`Karen Scarfone
`
`http://dx.doi.org/10.6028/NIST.SP.800-61r2
`
`WIZ, Inc. EXHIBIT - 1025
`WIZ, Inc. v. Orca Security LTD.
`
`

`

`
`
`NIST Special Publication 800-61
`
`Revision 2
`
`
`
`Computer Security Incident Handling
`Guide
`
`Recommendations of the National
`Institute of Standards and Technology
`
`Paul Cichonski
`Computer Security Division
`Information Technology Laboratory
`National Institute of Standards and Technology
`Gaithersburg, MD
`
`Tom Millar
`United States Computer Emergency Readiness Team
`National Cyber Security Division
`Department of Homeland Security
`
`Tim Grance
`Computer Security Division
`Information Technology Laboratory
`National Institute of Standards and Technology
`Gaithersburg, MD
`
`Karen Scarfone
`Scarfone Cybersecurity
`
`
`C O M P U T E R S E C U R I T Y
`
`
`
`
`
`August 2012
`
`
`
`
`
`
`U.S. Department of Commerce
`
`Rebecca Blank, Acting Secretary
`
`
`National Institute of Standards and Technology
`
`Patrick D. Gallagher,
` Under Secretary of Commerce for Standards and Technology
` and Director
`
`

`

`COMPUTER SECURITY INCIDENT HANDLING GUIDE
`
`
`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.
`
`
`
`
`
`
`
`
`ii
`
`

`

`COMPUTER SECURITY INCIDENT HANDLING GUIDE
`
`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-61 Revision 2
`Natl. Inst. Stand. Technol. Spec. Publ. 800-61 Revision 2, 79 pages (Aug. 2012)
`CODEN: NSPUE2
`
`
`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 publications, other than the ones noted above, are available at
`
`http://csrc.nist.gov/publications.
`
`
`
`
`
`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
`
`
`
`iii
`
`

`

`COMPUTER SECURITY INCIDENT HANDLING GUIDE
`
`Abstract
`
`Computer security incident response has become an important component of information technology (IT)
`programs. Because performing incident response effectively is a complex undertaking, establishing a
`successful incident response capability requires substantial planning and resources. This publication
`assists organizations in establishing computer security incident response capabilities and handling
`incidents efficiently and effectively. This publication provides guidelines for incident handling,
`particularly for analyzing incident-related data and determining the appropriate response to each incident.
`The guidelines can be followed independently of particular hardware platforms, operating systems,
`protocols, or applications.
`
`
`
`Keywords
`
`computer security incident; incident handling; incident response; information security
`
`
`
`
`
`iv
`
`

`

`COMPUTER SECURITY INCIDENT HANDLING GUIDE
`
`Acknowledgments
`
`The authors, Paul Cichonski of the National Institute of Standards and Technology (NIST), Tom Millar of
`the United States Computer Emergency Readiness Team (US-CERT), Tim Grance of NIST, and Karen
`Scarfone of Scarfone Cybersecurity wish to thank their colleagues who reviewed drafts of this document
`and contributed to its technical content, including John Banghart of NIST; Brian Allen, Mark Austin,
`Brian DeWyngaert, Andrew Fuller, Chris Hallenbeck, Sharon Kim, Mischel Kwon, Lee Rock, Richard
`Struse, and Randy Vickers of US-CERT; and Marcos Osorno of the Johns Hopkins University Applied
`Physics Laboratory. A special acknowledgment goes to Brent Logan of US-CERT for his graphics
`assistance. The authors would also like to thank security experts Simon Burson, Anton Chuvakin
`(Gartner), Fred Cohen (Fred Cohen & Associates), Mariano M. del Rio (SIClabs), Jake Evans (Tripwire),
`Walter Houser (SRA), Panos Kampanakis (Cisco), Kathleen Moriarty (EMC), David Schwalenberg
`(National Security Agency), and Wes Young (Research and Education Networking Information Sharing
`and Analysis Center [REN-ISAC]), as well as representatives of the Blue Glacier Management Group, the
`Centers for Disease Control and Prevention, the Department of Energy, the Department of State, and the
`Federal Aviation Administration for their particularly valuable comments and suggestions.
`
`The authors would also like to acknowledge the individuals that contributed to the previous versions of
`the publication. A special thanks goes to Brian Kim of Booz Allen Hamilton, who co-authored the
`original version; to Kelly Masone of Blue Glacier Management Group, who co-authored the first revision;
`and also to Rick Ayers, Chad Bloomquist, Vincent Hu, Peter Mell, Scott Rose, Murugiah Souppaya, Gary
`Stoneburner, and John Wack of NIST; Don Benack and Mike Witt of US-CERT; and Debra Banning,
`Pete Coleman, Alexis Feringa, Tracee Glass, Kevin Kuhlkin, Bryan Laird, Chris Manteuffel, Ron
`Ritchey, and Marc Stevens of Booz Allen Hamilton for their keen and insightful assistance throughout the
`development of the document, as well as Ron Banerjee and Gene Schultz for their work on a preliminary
`draft of the document. The authors would also like to express their thanks to security experts Tom Baxter
`(NASA), Mark Bruhn (Indiana University), Brian Carrier (CERIAS, Purdue University), Eoghan Casey,
`Johnny Davis, Jr. (Department of Veterans Affairs), Jim Duncan (BB&T), Dean Farrington (Wells Fargo
`Bank), John Hale (University of Tulsa), Georgia Killcrece (CERT®/CC), Barbara Laswell (CERT®/CC),
`Pascal Meunier (CERIAS, Purdue University), Jeff Murphy (University of Buffalo), Todd O’Boyle
`(MITRE), Marc Rogers (CERIAS, Purdue University), Steve Romig (Ohio State University), Robin
`Ruefle (CERT®/CC), Gene Schultz (Lawrence Berkeley National Laboratory), Michael Smith (US-
`CERT), Holt Sorenson, Eugene Spafford (CERIAS, Purdue University), Ken van Wyk, and Mark Zajicek
`(CERT®/CC), as well as representatives of the Department of the Treasury, for their particularly valuable
`comments and suggestions.
`
`
`
`v
`
`

`

`COMPUTER SECURITY INCIDENT HANDLING GUIDE
`
`Table of Contents
`
`Executive Summary ................................................................................................................. 1
`
`1.
`
`Introduction ...................................................................................................................... 4
`
`1.1 Authority .................................................................................................................... 4
`1.2 Purpose and Scope ................................................................................................... 4
`1.3 Audience ................................................................................................................... 4
`1.4 Document Structure .................................................................................................. 4
`
`2. Organizing a Computer Security Incident Response Capability ................................... 6
`
`2.1 Events and Incidents ................................................................................................. 6
`2.2 Need for Incident Response ...................................................................................... 6
`2.3
`Incident Response Policy, Plan, and Procedure Creation .......................................... 7
`2.3.1 Policy Elements............................................................................................. 7
`2.3.2 Plan Elements ............................................................................................... 8
`2.3.3 Procedure Elements ...................................................................................... 8
`2.3.4 Sharing Information With Outside Parties ...................................................... 9
`Incident Response Team Structure ......................................................................... 13
`2.4.1 Team Models ...............................................................................................13
`2.4.2 Team Model Selection..................................................................................14
`2.4.3
`Incident Response Personnel .......................................................................16
`2.4.4 Dependencies within Organizations .............................................................17
`Incident Response Team Services .......................................................................... 18
`2.5
`2.6 Recommendations .................................................................................................. 19
`
`2.4
`
`3. Handling an Incident .......................................................................................................21
`
`3.1 Preparation .............................................................................................................. 21
`3.1.1 Preparing to Handle Incidents ......................................................................21
`3.1.2 Preventing Incidents .....................................................................................23
`3.2 Detection and Analysis ............................................................................................ 25
`3.2.1 Attack Vectors ..............................................................................................25
`3.2.2 Signs of an Incident ......................................................................................26
`3.2.3 Sources of Precursors and Indicators ...........................................................27
`3.2.4
`Incident Analysis ..........................................................................................28
`3.2.5
`Incident Documentation ................................................................................30
`3.2.6
`Incident Prioritization ....................................................................................32
`3.2.7
`Incident Notification ......................................................................................33
`3.3 Containment, Eradication, and Recovery................................................................. 35
`3.3.1 Choosing a Containment Strategy ................................................................35
`3.3.2 Evidence Gathering and Handling ................................................................36
`3.3.3
`Identifying the Attacking Hosts .....................................................................37
`3.3.4 Eradication and Recovery ............................................................................37
`3.4 Post-Incident Activity ............................................................................................... 38
`3.4.1 Lessons Learned ..........................................................................................38
`3.4.2 Using Collected Incident Data ......................................................................39
`3.4.3 Evidence Retention ......................................................................................41
`Incident Handling Checklist ..................................................................................... 42
`3.5
`3.6 Recommendations .................................................................................................. 42
`
`4. Coordination and Information Sharing ..........................................................................45
`
`vi
`
`

`

`COMPUTER SECURITY INCIDENT HANDLING GUIDE
`
`4.2
`
`4.1 Coordination ............................................................................................................ 45
`4.1.1 Coordination Relationships ..........................................................................46
`4.1.2 Sharing Agreements and Reporting Requirements ......................................47
`Information Sharing Techniques .............................................................................. 48
`4.2.1 Ad Hoc .........................................................................................................48
`4.2.2 Partially Automated ......................................................................................48
`4.2.3 Security Considerations ...............................................................................49
`4.3 Granular Information Sharing .................................................................................. 49
`4.3.1 Business Impact Information ........................................................................49
`4.3.2 Technical Information ...................................................................................50
`4.4 Recommendations .................................................................................................. 51
`
`
`List of Appendices
`
`Appendix A— Incident Handling Scenarios ..........................................................................52
`
`A.1 Scenario Questions ................................................................................................. 52
`A.2 Scenarios ................................................................................................................ 53
`
`Appendix B— Incident-Related Data Elements .....................................................................58
`
`B.1 Basic Data Elements ............................................................................................... 58
`B.2
`Incident Handler Data Elements .............................................................................. 59
`
`Appendix C— Glossary ..........................................................................................................60
`
`Appendix D— Acronyms ........................................................................................................61
`
`Appendix E— Resources........................................................................................................63
`
`Appendix F— Frequently Asked Questions ..........................................................................65
`
`Appendix G— Crisis Handling Steps .....................................................................................68
`
`Appendix H— Change Log .....................................................................................................69
`
`
`
`
`
`List of Figures
`
`Figure 2-1. Communications with Outside Parties .....................................................................10
`
`Figure 3-1. Incident Response Life Cycle ..................................................................................21
`
`Figure 3-2. Incident Response Life Cycle (Detection and Analysis) ...........................................25
`
`Figure 3-3. Incident Response Life Cycle (Containment, Eradication, and Recovery) ...............35
`
`Figure 3-4. Incident Response Life Cycle (Post-Incident Activity) ..............................................38
`
`Figure 4-1. Incident Response Coordination .............................................................................46
`
`
`
`
`
`
`vii
`
`

`

`COMPUTER SECURITY INCIDENT HANDLING GUIDE
`
`
`
`List of Tables
`
`Table 3-1. Common Sources of Precursors and Indicators .......................................................27
`
`Table 3-2. Functional Impact Categories ...................................................................................33
`
`Table 3-3. Information Impact Categories .................................................................................33
`
`Table 3-4. Recoverability Effort Categories ...............................................................................33
`
`Table 3-5. Incident Handling Checklist ......................................................................................42
`
`Table 4-1. Coordination Relationships ......................................................................................47
`
`viii
`
`

`

`COMPUTER SECURITY INCIDENT HANDLING GUIDE
`
`Executive Summary
`
`Computer security incident response has become an important component of information technology (IT)
`programs. Cybersecurity-related attacks have become not only more numerous and diverse but also more
`damaging and disruptive. New types of security-related incidents emerge frequently. Preventive activities
`based on the results of risk assessments can lower the number of incidents, but not all incidents can be
`prevented. An incident response capability is therefore necessary for rapidly detecting incidents,
`minimizing loss and destruction, mitigating the weaknesses that were exploited, and restoring IT services.
`To that end, this publication provides guidelines for incident handling, particularly for analyzing incident-
`related data and determining the appropriate response to each incident. The guidelines can be followed
`independently of particular hardware platforms, operating systems, protocols, or applications.
`
`Because performing incident response effectively is a complex undertaking, establishing a successful
`incident response capability requires substantial planning and resources. Continually monitoring for
`attacks is essential. Establishing clear procedures for prioritizing the handling of incidents is critical, as is
`implementing effective methods of collecting, analyzing, and reporting data. It is also vital to build
`relationships and establish suitable means of communication with other internal groups (e.g., human
`resources, legal) and with external groups (e.g., other incident response teams, law enforcement).
`
`This publication assists organizations in establishing computer security incident response capabilities and
`handling incidents efficiently and effectively. This revision of the publication, Revision 2, updates
`material throughout the publication to reflect the changes in attacks and incidents. Understanding threats
`and identifying modern attacks in their early stages is key to preventing subsequent compromises, and
`proactively sharing information among organizations regarding the signs of these attacks is an
`increasingly effective way to identify them.
`
`Implementing the following requirements and recommendations should facilitate efficient and effective
`incident response for Federal departments and agencies.
`
`Organizations must create, provision, and operate a formal incident response capability. Federal
`law requires Federal agencies to report incidents to the United States Computer Emergency
`Readiness Team (US-CERT) office within the Department of Homeland Security (DHS).
`
`The Federal Information Security Management Act (FISMA) requires Federal agencies to establish
`incident response capabilities. Each Federal civilian agency must designate a primary and secondary point
`of contact (POC) with US-CERT and report all incidents consistent with the agency’s incident response
`policy. Each agency is responsible for determining how to fulfill these requirements.
`
`Establishing an incident response capability should include the following actions:
`
` Creating an incident response policy and plan
`
` Developing procedures for performing incident handling and reporting
`
` Setting guidelines for communicating with outside parties regarding incidents
`
` Selecting a team structure and staffing model
`
` Establishing relationships and lines of communication between the incident response team and other
`groups, both internal (e.g., legal department) and external (e.g., law enforcement agencies)
`
` Determining what services the incident response team should provide
`
`1
`
`

`

`COMPUTER SECURITY INCIDENT HANDLING GUIDE
`
` Staffing and training the incident response team.
`
`Organizations should reduce the frequency of incidents by effectively securing networks, systems,
`and applications.
`
`Preventing problems is often less costly and more effective than reacting to them after they occur. Thus,
`incident prevention is an important complement to an incident response capability. If security controls are
`insufficient, high volumes of incidents may occur. This could overwhelm the resources and capacity for
`response, which would result in delayed or incomplete recovery and possibly more extensive damage and
`longer periods of service and data unavailability. Incident handling can be performed more effectively if
`organizations complement their incident response capability with adequate resources to actively maintain
`the security of networks, systems, and applications. This includes training IT staff on complying with the
`organization’s security standards and making users aware of policies and procedures regarding
`appropriate use of networks, systems, and applications.
`
`Organizations should document their guidelines for interactions with other organizations regarding
`incidents.
`
`During incident handling, the organization will need to communicate with outside parties, such as other
`incident response teams, law enforcement, the media, vendors, and victim organizations. Because these
`communications often need to occur quickly, organizations should predetermine communication
`guidelines so that only the appropriate information is shared with the right parties.
`
`Organizations should be generally prepared to handle any incident but should focus on being
`prepared to handle incidents that use common attack vectors.
`
`Incidents can occur in countless ways, so it is infeasible to develop step-by-step instructions for handling
`every incident. This publication defines several types of incidents, based on common attack vectors; these
`categories are not intended to provide definitive classification for incidents, but rather to be used as a
`basis for defining more specific handling procedures. Different types of incidents merit different response
`strategies. The attack vectors are:
`
` External/Removable Media: An attack executed from removable media (e.g., flash drive, CD) or a
`peripheral device.
`
` Attrition: An attack that employs brute force methods to compromise, degrade, or destroy systems,
`networks, or services.
`
` Web: An attack executed from a website or web-based application.
`
` Email: An attack executed via an email message or attachment.
`
` Improper Usage: Any incident resulting from violation of an organization’s acceptable usage
`policies by an authorized user, excluding the above categories.
`
` Loss or Theft of Equipment: The loss or theft of a computing device or media used by the
`organization, such as a laptop or smartphone.
`
` Other: An attack that does not fit into any of the other categories.
`
`2
`
`

`

`COMPUTER SECURITY INCIDENT HANDLING GUIDE
`
`Organizations should emphasize the importance of incident detection and analysis throughout the
`organization.
`
`In an organization, millions of possible signs of incidents may occur each day, recorded mainly by
`logging and computer security software. Automation is needed to perform an initial analysis of the data
`and select events of interest for human review. Event correlation software can be of great value in
`automating the analysis process. However, the effectiveness of the process depends on the quality of the
`data that goes into it. Organizations should establish logging standards and procedures to ensure that
`adequate information is collected by logs and security software and that the data is reviewed regularly.
`
`Organizations should create written guidelines for prioritizing incidents.
`
`Prioritizing the handling of individual incidents is a critical decision point in the incident response
`process. Effective information sharing can help an organization identify situations that are of greater
`severity and demand immediate attention. Incidents should be prioritized based on the relevant factors,
`such as the functional impact of the incident (e.g., current and likely future negative impact to business
`functions), the information impact of the incident (e.g., effect on the confidentiality, integrity, and
`availability of the organization’s information), and the recoverability from the incident (e.g., the time and
`types of resources that must be spent on recovering from the incident).
`
`Organizations should use the lessons learned process to gain value from incidents.
`
`After a major incident has been handled, the organization should hold a lessons learned meeting to review
`the effectiveness of the incident handling process and identify necessary improvements to existing
`security controls and practices. Lessons learned meetings can also be held periodically for lesser incidents
`as time and resources permit. The information accumulated from all lessons learned meetings should be
`used to identify and correct systemic weaknesses and deficiencies in policies and procedures. Follow-up
`reports generated for each resolved incident can be important not only for evidentiary purposes but also
`for reference in handling future incidents and in training new team members.
`
`
`
`3
`
`

`

`COMPUTER SECURITY INCIDENT HANDLING GUIDE
`
`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 operations and assets, 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 seeks to assist organizations in mitigating the risks from computer security incidents by
`providing practical guidelines on responding to incidents effectively and efficiently. It includes guidelines
`on establishing an effective incident response program, but the primary focus of the document is
`detecting, analyzing, prioritizing, and handling incidents. Organizations are encouraged to tailor the
`recommended guidelines and solutions to meet their specific security and mission requirements.
`
`1.3 Audience
`
`This document has been created for computer security incident response teams (CSIRTs), system and
`network administrators, security staff, technical support staff, chief information security officers (CISOs),
`chief information officers (CIOs), computer security program managers, and others who are responsible
`for preparing for, or responding to, security incidents.
`
`1.4 Document Structure
`
`The remainder of this document is organized into the following sections and appendices:
`
` Section 2 discusses the need for incident response, outlines possible incident response team
`structures, and highlights other groups within an organization that may participate in incident
`handling.
`
` Section 3 reviews the basic incident handling steps and provides advice for performing incident
`handling more effectively, particularly incident detection and analysis.
`
` Section 4 examines the need for incident response coordination and information sharing.
`
`4
`
`

`

`COMPUTER SECURITY INCIDENT HANDLING GUIDE
`
` Appendix A contains incident response scenarios and questions for use in incident response tabletop
`discussions.
`
` Appendix B provides lists of suggested data fields to collect for each incident.
`
` Appendices C and D contain a glossary and acronym list, respectively.
`
` Appendix E identifies resources that may be useful in planning and performing incident response.
`
` Appendix F covers frequently asked questions about incident response.
`
` Appendix G lists the major steps to follow when handling a computer security incident-related crisis.
`
` Appendix H contains a change log listing significant changes since the previous revision.
`
`5
`
`

`

`COMPUTER SECURITY INCIDENT HANDLING GUIDE
`
`2. Organizing a Computer Security Incident Response Capability
`
`Organizing an effective computer security incident response capability (CSIRC) involves several major
`decisions and actions. One of the first considerations should be to create an organization-specific
`definition of the term “incident” so that the scope of the term is clear. The organization should decide
`what services the incident response team should provide, consider which team structures and models can
`provide those services, and select and implement one or more incident response teams. Incident response
`plan, policy, and procedure creation is an important part of establishing a team, so that incident response
`is