Computer Security

Incident Handling Guide

Recommendations of the National Institute of Standards and Technology

Paul Cichonski Tom Millar Tim Grance Karen Scarfone

Special Publication 800-61

Revision 2

http://dx.doi.org/10.6028/NIST.SP.800-61r2

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

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 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.

COMPUTER SECURITY INCIDENT HANDLING GUIDE

iii

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

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 publications, other than the ones noted above, are available at

http://csrc.nist.gov/publications.

COMPUTER SECURITY INCIDENT HANDLING GUIDE

iv

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

COMPUTER SECURITY INCIDENT HANDLING GUIDE

v

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.

COMPUTER SECURITY INCIDENT HANDLING GUIDE

vi

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

2.4 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

2.5 Incident Response Team Services ……………………………………………………………….. 18 2.6 Recommendations …………………………………………………………………………………….. 19

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

3.5 Incident Handling Checklist …………………………………………………………………………. 42 3.6 Recommendations …………………………………………………………………………………….. 42

4. Coordination and Information Sharing ………………………………………………………………..45

COMPUTER SECURITY INCIDENT HANDLING GUIDE

vii

4.1 Coordination ……………………………………………………………………………………………… 45 4.1.1 Coordination Relationships ………………………………………………………………..46 4.1.2 Sharing Agreements and Reporting Requirements ………………………………..47

4.2 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

COMPUTER SECURITY INCIDENT HANDLING GUIDE

viii

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

COMPUTER SECURITY INCIDENT HANDLING GUIDE

1

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

COMPUTER SECURITY INCIDENT HANDLING GUIDE

2

 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 co

Related Tags