Explain the procedures for an incident response

Submit A Plan Including The Eight Basic Elements Of An Incident Response Plan, And Procedures For Sharing Information With Outside Parties. See The Oregon State Incident Response Template As A Sample, But All Work Should Be Original.

In the Case Document, one of the security gap analyses indicated a high number of laptop thefts and a high number of security incidents. Because of this recent increase in theft and security incidents, the CISO asks you to develop an incident response plan. Submit a plan including the eight basic elements of an incident response plan, and procedures for sharing information with outside parties. See the Oregon state incident response template as a sample, but all work should be original.

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

karenw
Typewritten Text
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

karenw
Typewritten Text
http://dx.doi.org/10.6028/NIST.SP.800-61r2
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.

karenw
Typewritten Text
http://dx.doi.org/10.6028/NIST.SP.800-61r2
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 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.

COMPUTER SECURITY INCIDENT HANDLING GUIDE

3

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.

COMPUTER SECURITY INCIDENT HANDLING GUIDE

4

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.

COMPUTER SECURITY INCIDENT HANDLING GUIDE

5

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

COMPUTER SECURITY INCIDENT HANDLING GUIDE

6

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 performed effectively, efficiently, and consistently, and so that the team is empowered to do what needs

to be done. The plan, policies, and procedures should reflect the team’s interactions with other teams

within the organization as well as with outside parties, such as law enforcement, the media, and other

incident response organizations. This section provides not only guidelines that should be helpful to

organizations that are establishing incident response capabilities, but also advice on maintaining and

enhancing existing capabilities.

2.1 Events and Incidents

An event is any observable occurrence in a system or network. Events include a user connecting to a file

share, a server receiving a request for a web page, a user sending email, and a firewall blocking a

connection attempt. Adverse events are events with a negative consequence, such as system crashes,

packet floods, unauthorized use of system privileges, unauthorized access to sensitive data, and execution

of malware that destroys data. This guide addresses only adverse events that are computer security-

related, not those caused by natural disasters, power failures, etc.

A computer security incident is a violation or imminent threat of violation 1 of computer security policies,

acceptable use policies, or standard security practices. Examples of incidents 2 are:

 An attacker commands a botnet to send high volumes of connection requests to a web server, causing it to crash.

 Users are tricked into opening a “quarterly report” sent via email that is actually malware; running the tool has infected their computers and established connections with an external host.

 An attacker obtains sensitive data and threatens that the details will be released publicly if the organization does not pay a designated sum of money.

 A user provides or exposes sensitive information to others through peer-to-peer file sharing services.

2.2 Need for Incident Response

Attacks frequently compromise personal and business data, and it is critical to respond quickly and

effectively when security breaches occur. The concept of computer security incident response has become

widely accepted and implemented. One of the benefits of having an incident response capability is that it

supports responding to incidents systematically (i.e., following a consistent incident handling

methodology) so that the appropriate actions are taken. Incident response helps personnel to minimize

loss or theft of information and disruption of services caused by incidents. Another benefit of incident

response is the ability to use information gained during incident handling to better prepare for handling

1 An “imminent threat of violation” refers to a situation in which the organization has a factual basis for believing that a

specific incident is about to occur. For example, the antivirus software maintainers may receive a bulletin from the software

vendor, warning them of new malware that is rapidly spreading across the Internet. 2 For the remainder of this document, the terms “incident” and “computer security incident” are interchangeable.

COMPUTER SECURITY INCIDENT HANDLING GUIDE

7

future incidents and to provide stronger protection for systems and data. An incident response capability

also helps with dealing properly with legal issues that may arise during incidents.

Besides the business reasons to establish an incident response capability, Federal departments and

agencies must comply with law, regulations, and policy directing a coordinated, effective defense against

information security threats. Chief among these are the following:

 OMB’s Circular No. A-130, Appendix III, 3 released in 2000, which directs Federal agencies to

“ensure that there is a capability to provide help to users when a security incident occurs in the system

and to share information concerning common vulnerabilities and threats. This capability shall share

information with other organizations … and should assist the agency in pursuing appropriate legal

action, consistent with Department of Justice guidance.”

 FISMA (from 2002), 4 which requires agencies to have “procedures for detecting, reporting, and

responding to security incidents” and establishes a centralized Federal information security incident

center, in part to:

– “Provide timely technical assistance to operators of agency information systems … including guidance on detecting and handling information security incidents …

– Compile and analyze information about incidents that threaten information security …

– Inform operators of agency information systems about current and potential information security threats, and vulnerabilities … .”

 Federal Information Processing Standards (FIPS) 200, Minimum Security Requirements for Federal Information and Information Systems

5 , March 2006, which specifies minimum security requirements

for Federal information and information systems, including incident response. The specific

requirements are defined in NIST Special Publication (SP) 800-53, Recommended Security Controls

for Federal Information Systems and Organizations.

 OMB Memorandum M-07-16, Safeguarding Against and Responding to the Breach of Personally Identifiable Information

6 , May 2007, which provides guidance on reporting security incidents that

involve PII.

2.3 Incident Response Policy, Plan, and Procedure Creation

This section discusses policies, plans, and procedures related to incident response, with an emphasis on

interactions with outside parties.

2.3.1 Policy Elements

Policy governing incident response is highly individualized to the organization. However, most policies

include the same key elements:

 Statement of management commitment

 Purpose and objectives of the policy

3 http://www.whitehouse.gov/omb/circulars/a130/a130trans4.html

4 http://csrc.nist.gov/drivers/documents/FISMA-final.pdf

5 http://csrc.nist.gov/publications/PubsFIPS.html

6 http://www.whitehouse.gov/omb/memoranda/fy2007/m07-16.pdf

http://www.whitehouse.gov/omb/circulars/a130/a130trans4.html
http://csrc.nist.gov/drivers/documents/FISMA-final.pdf
http://csrc.nist.gov/publications/PubsFIPS.html
http://www.whitehouse.gov/omb/memoranda/fy2007/m07-16.pdf
COMPUTER SECURITY INCIDENT HANDLING GUIDE

8

 Scope of the policy (to whom and what it applies and under what circumstances)

 Definition of computer security incidents and related terms

 Organizational structure and definition of roles, responsibilities, and levels of authority; should include the authority of the incident response team to confiscate or disconnect equipment and to

monitor suspicious activity, the requirements for reporting certain types of incidents, the requirements

and guidelines for external communications and information sharing (e.g., what can be shared with

whom, when, and over what channels), and the handoff and escalation points in the incident

management process

 Prioritization or severity ratings of incidents

 Performance measures (as discussed in Section 3.4.2)

 Reporting and contact forms.

2.3.2 Plan Elements

Organizations should have a formal, focused, and coordinated approach to responding to incidents,

including an incident response plan that provides the roadmap for implementing the incident response

capability. Each organization needs a plan that meets its unique requirements, which relates to the

organization’s mission, size, structure, and functions. The plan should lay out the necessary resources and

management support. The incident response plan should include the following elements:

 Mission

 Strategies and goals

 Senior management approval

 Organizational approach to incident response

 How the incident response team will communicate with the rest of the organization and with other organizations

 Metrics for measuring the incident response capability and its effectiveness

 Roadmap for maturing the incident response capability

 How the program fits into the overall organization.

The organization’s mission, strategies, and goals for incident response should help in determining the

structure of its incident response capability. The incident response program structure should also be

discussed within the plan. Section 2.4.1 discusses the types of structures.

Once an organization develops a plan and gains management approval, the organization should

implement the plan and review it at least annually to ensure the organization is following the roadmap for

maturing the capability and fulfilling their goals for incident response.

2.3.3 Procedure Elements

Procedures should be based on the incident response policy and plan. Standard operating procedures

(SOPs) are a delineation of the specific technical processes, techniques, checklists, and forms used by the

incident response team. SOPs should be reasonably comprehensive and detailed to ensure that the

COMPUTER SECURITY INCIDENT HANDLING GUIDE

9

priorities of the organization are reflected in response operations. In addition, following standardized

responses should minimize errors, particularly those that might be caused by stressful incident handling

situations. SOPs should be tested to validate their accuracy and usefulness, then distributed to all team

members. Training should be provided for SOP users; the SOP documents can be used as an instructional

tool. Suggested SOP elements are presented throughout Section 3.

2.3.4 Sharing Information With Outside Parties

Organizations often need to communicate with outside parties regarding an incident, and they should do

so whenever appropriate, such as contacting law enforcement, fielding media inquiries, and seeking

external expertise. Another example is discussing incidents with other involved parties, such as Internet

service providers (ISPs), the vendor of vulnerable software, or other incident response teams.

Organizations may also proactively share relevant incident indicator information with peers to improve

detection and analysis of incidents. The incident response team should discuss information sharing with

the organization’s public affairs office, legal department, and management before an incident occurs to

establish policies and procedures regarding information sharing. Otherwise, sensitive information

regarding incidents may be provided to unauthorized parties, potentially leading to additional disruption

and financial loss. The team should document all contacts and communications with outside parties for

liability and evidentiary purposes.

The following sections provide guidelines on communicating with several types of outside parties, as

depicted in Figure 2-1. The double-headed arrows indicate that either party may initiate communications.

See Section 4 for additional information on communicating with outside parties, and see Section 2.4 for a

discussion of communications involving incident response outsourcers.

COMPUTER SECURITY INCIDENT HANDLING GUIDE

10

Figure 2-1. Communications with Outside Parties

2.3.4.1 The Media

The incident handling team should establish media communications procedures that comply with the

organization’s policies on media interaction and information disclosure. 7 For discussing incidents with the

media, organizations often find it beneficial to designate a single point of contact (POC) and at least one

backup contact. The following actions are recommended for preparing these designated contacts and

should also be considered for preparing others who may be communicating with the media:

 Conduct training sessions on interacting with the media regarding incidents, which should include the importance of not revealing sensitive information, such as technical details of countermeasures that

could assist other attackers, and the positive aspects of communicating important information to the

public fully and effectively.

 Establish procedures to brief media contacts on the issues and sensitivities regarding a particular incident before discussing it with the media.

7 For example, an organization may want members of its public affairs office and legal department to participate in all

incident discussions with the media.

COMPUTER SECURITY INCIDENT HANDLING GUIDE

11

 Maintain a statement of the current status of the incident so that communications with the media are consistent and up-to-date.

 Remind all staff of the general procedures for handling media inquiries.

 Hold mock interviews and press conferences during incident handling exercises. The following are examples of questions to ask the media contact:

– Who attacked you? Why?

– When did it happen? How did it happen? Did this happen because you have poor security practices?

– How widespread is this incident? What steps are you taking to determine what happened and to prevent future occurrences?

– What is the impact of this incident? Was any personally identifiable information (PII) exposed? What is the estimated cost of this incident?

2.3.4.2 Law Enforcement

One reason that many security-related incidents do not result in convictions is that some organizations do

not properly contact law enforcement. Several levels of law enforcement are available to investigate

incidents: for example, within the United States, Federal investigatory agencies (e.g., the Federal Bureau

of Investigation [FBI] and the U.S. Secret Service), district attorney offices, state law enforcement, and

local (e.g., county) law enforcement. Law enforcement agencies in other countries may also be involved,

such as for attacks launched from or directed at locations outside the US. In addition, agencies have an

Office of Inspector General (OIG) for investigation of violation of the law within each agency. The

incident response team should become acquainted with its various law enforcement representatives before

an incident occurs to discuss conditions under which incidents should be reported to them, how the

reporting should be performed, what evidence should be collected, and how it should be collected.

Law enforcement should be contacted through designated individuals in a manner consistent with the

requirements of the law and the organization’s procedures. Many organizations prefer to appoint one

incident response team member as the primary POC with law enforcement. This person should be familiar

with the reporting procedures for all relevant law enforcement agencies and well prepared to recommend

which agency, if any, should be contacted. Note that the organization typically should not contact

multiple agencies because doing so might result in jurisdictional conflicts. The incident response team

should understand what the potential jurisdictional issues are (e.g., physical location—an organization

based in one state has a server located in a second state attacked from a system in a third state, being used

remotely by an attacker in a fourth state).

2.3.4.3 Incident Reporting Organizations

FISMA requires Federal agencies to report incidents to the United States Computer Emergency Readiness

Team (US-CERT), 8 which is a governmentwide incident response organization that assists Federal

civilian agencies in their incident handling efforts. US-CERT does not replace existing agency response

teams; rather, it augments the efforts of Federal civilian agencies by serving as a focal point for dealing

with incidents. US-CERT analyzes the agency-provided information to identify trends and indicators of

attacks; these are easier to discern when reviewing data from many organizations than when reviewing

the data of a single organization.

8 http://www.us-cert.gov/

http://www.us-cert.gov/
COMPUTER SECURITY INCIDENT HANDLING GUIDE

12

Each agency must designate a primary and secondary POC with US-CERT and report all incidents

consistent with the agency’s incident response policy. Organizations should create a policy that states

who is designated to report incidents and how the incidents should be reported. Requirements, categories,

and timeframes for reporting incidents to US-CERT are on the US-CERT website. 9 All Federal agencies

must ensure that their incident response procedures adhere to US-CERT’s reporting requirements and that

the procedures are followed properly.

All organizations are encouraged to report incidents to their appropriate CSIRTs. If an organization does

not have its own CSIRT to contact, it can report incidents to other organizations, including Information

Sharing and Analysis Centers (ISACs). One of the functions of these industry-specific private sector

groups is to share important computer security-related information among their members. Several ISACs

have been formed for industry sectors such as Communications, Electric Sector, Financial Services,

Information Technology, and Research and Education. 10

2.3.4.4 Other Outside Parties

An organization may want to discuss incidents with other groups, including those listed below. When

reaching out to these external parties, an organization may want to work through US-CERT or its ISAC,

as a “trusted introducer” to broker the relationship. It is likely that others are experiencing similar issues,

and the trusted introducer can ensure that any such patterns are identified and taken into consideration.

 Organization’s ISP. An organization may need assistance from its ISP in blocking a major network- based attack or tracing its origin.

 Owners of Attacking Addresses. If attacks are originating from an external organization’s IP address space, incident handlers may want to talk to the designated security contacts for the

organization to alert them to the activity or to ask them to collect evidence. It is highly recommended

to coordinate such communications with US-CERT or an ISAC.

 Software Vendors. Incident handlers may want to speak to a software vendor about suspicious activity. This contact could include questions regarding the significance of certain log entries or

known false positives for certain intrusion detection signatures, where minimal information regarding

the incident may need to be revealed. More information may need to be provided in some cases—for

example, if a server appears to have been compromised through an unknown software vulnerability.

Software vendors may also provide information on known threats (e.g., new attacks) to help

organizations understand the current threat environment.

 Other Incident Response Teams. An organization may experience an incident that is similar to ones handled by other teams; proactively sharing information can facilitate more effective and efficient

incident handling (e.g., providing advance warning, increasing preparedness, developing situational

awareness). Groups such as the Forum of Incident Response and Security Teams (FIRST) 11

, the

Government Forum of Incident Response and Security Teams (GFIRST) 12

, and the Anti-Phishing

Working Group (APWG) 13

are not incident response teams, but they promote information sharing

among incident response teams.

 Affected External Parties. An incident may affect external parties directly—for example, an outside organization may contact the organization and claim that one of the organization’s users is attacking

9 http://www.us-cert.gov/federal/reportingRequirements.html

10 See the National Council of ISACs website at http://www.isaccouncil.org/ for a list of ISACs.

11 http://www.first.org/

12 GFIRST is specifically for Federal departments and agencies. (http://www.us-cert.gov/federal/gfirst.html)

13 http://www.antiphishing.org/

http://www.us-cert.gov/federal/reportingRequirements.html
http://www.isaccouncil.org/
http://www.first.org/
http://www.us-cert.gov/federal/gfirst.html
http://www.antiphishing.org/
COMPUTER SECURITY INCIDENT HANDLING GUIDE

13

it. Another way in which external parties may be affected is if an attacker gains access to sensitive

information regarding them, such as credit card information. In some jurisdictions, organizations are

required to notify all parties that are affected by such an incident. Regardless of the circumstances, it

is preferable for the organization to notify affected external parties of an incident before the media or

other external organizations do so. Handlers should be careful to give out only appropriate

information—the affected parties may request details about internal investigations that should not be

revealed publicly.

OMB Memorandum M-07-16, Safeguarding Against and Responding to the Breach of Personally

Identifiable Information, requires Federal agencies to develop and implement a breach notification

policy for personally identifiable information (PII). 14

Incident handlers should understand how their

incident handling actions should differ when a PII breach is suspected to have occurred, such as

notifying additional parties or notifying parties within a shorter timeframe. Specific recommendations

for PII breach notification policies are presented in OMB Memorandum M-07-16. Also, the National

Conference of State Legislatures has a list of state security breach notification laws. 15

2.4 Incident Response Team Structure

An incident response team should be available for anyone who discovers or suspects that an incident

involving the organization has occurred. One or more team members, depending on the magnitude of the

incident and availability of personnel, will then handle the incident. The incident handlers analyze the

incident data, determine the impact of the incident, and act appropriately to limit the damage and restore

normal services. The incident response team’s success depends on the participation and cooperation of

individuals throughout the organization. This section identifies such individuals, discusses incident

response team models, and provides advice on selecting an appropriate model.

2.4.1 Team Models

Possible structures for an incident response team include the following:

 Central Incident Response Team. A single incident response team handles incidents throughout the organization. This model is effective for small organizations and for organizations with minimal

geographic diversity in terms of computing resources.

 Distributed Incident Response Teams. The organization has multiple incident response teams, each responsible for a particular logical or physical segment of the organization. This model is effective for

large organizations (e.g., one team per division) and for organizations with major computing

resources at distant locations (e.g., one team per geographic region, one team per major facility).

However, the teams should be part of a single coordinated entity so that the incident response process

is consistent across the organization and information is shared among teams. This is particularly

important because multiple teams may see components of the same incident or may handle similar

incidents.

 Coordinating Team. An incident response team provides advice to other teams without having authority over those teams—for example, a departmentwide team may assist individual agencies’

teams. This model can be thought of as a CSIRT for CSIRTs. Because the focus of this document is

14

http://www.whitehouse.gov/omb/memoranda/fy2007/m07-16.pdf 15

http://www.ncsl.org/default.aspx?tabid=13489

http://www.whitehouse.gov/omb/memoranda/fy2007/m07-16.pdf
http://www.ncsl.org/default.aspx?tabid=13489
COMPUTER SECURITY INCIDENT HANDLING GUIDE

14

central and distributed CSIRTs, the coordinating team model is not addressed in detail in this

document. 16

Incident response teams can also use any of three staffing models:

 Employees. The organization performs all of its incident response work, with limited technical and administrative support from contractors.

 Partially Outsourced. The organization outsources portions of its incident response work. Section 2.4.2 discusses the major factors that should be considered with outsourcing. Although

incident response duties can be divided among the organization and one or more outsourcers in many

ways, a few arrangements have become commonplace:

– The most prevalent arrangement is for the organization to outsource 24-hours-a-day, 7-days-a- week (24/7) monitoring of intrusion detection sensors, firewalls, and other security devices to an

offsite managed security services provider (MSSP). The MSSP identifies and analyzes suspicious

activity and reports each detected incident to the organization’s incident response team.

– Some organizations perform basic incident response work in-house and call on contractors to assist with handling incidents, particularly those that are more serious or widespread.

 Fully Outsourced. The organization completely outsources its incident response work, typically to an onsite contractor. This model is most likely to be used when the organization needs a full-time,

onsite incident response team but does not have enough available, qualified employees. It is assumed

that the organization will have employees supervising and overseeing the outsourcer’s work.

2.4.2 Team Model Selection

When selecting appropriate structure and staffing models for an incident response team, organizations

should consider the following factors:

 The Need for 24/7 Availability. Most organizations need incident response staff to be available 24/7. This typically means that incident handlers can be contacted by phone, but it can also mean that an

onsite presence is required. Real-time availability is the best for incident response because the longer

an incident lasts, the more potential there is for damage and loss. Real-time contact is often needed

when working with other organizations—for example, tracing an attack back to its source.

 Full-Time Versus Part-Time Team Members. Organizations with limited funding, staffing, or incident response needs may have only part-time incident response team members, serving as more of

a virtual incident response team. In this case, the incident response team can be thought of as a

volunteer fire department. When an emergency occurs, the team members are contacted rapidly, and

those who can assist do so. An existing group such as the IT help desk can act as a first POC for

incident reporting. The help desk members can be trained to perform the initial investigation and data

gathering and then alert the incident response team if it appears that a serious incident has occurred.

 Employee Morale. Incident response work is very stressful, as are the on-call responsibilities of most team members. This combination makes it easy for incident response team members to become

overly stressed. Many organizations will also struggle to find willing, available, experienced, and

properly skilled people to participate, particularly in 24-hour support. Segregating roles, particularly

16

Information about the Coordinating team model, as well as extensive information on other team models, is available in a

CERT ®

/CC document titled Organizational Models for Computer Security Incident Response Teams (CSIRTs)

(http://www.cert.org/archive/pdf/03hb001.pdf).

http://www.cert.org/archive/pdf/03hb001.pdf
COMPUTER SECURITY INCIDENT HANDLING GUIDE

15

reducing the amount of administrative work that team members are responsible for performing, can

be a significant boost to morale.

 Cost. Cost is a major factor, especially if employees are required to be onsite 24/7. Organizations may fail to include incident response-specific costs in budgets, such as sufficient funding for training

and maintaining skills. Because the incident response team works with so many facets of IT, its

members need much broader knowledge than most IT staff members. They must also understand how

to use the tools of incident response, such as digital forensics software. Other costs that may be

overlooked are physical security for the team’s work areas and communications mechanisms.

 Staff Expertise. Incident handling requires specialized knowledge and experience in several technical areas; the breadth and depth of knowledge required varies based on the severity of the

organization’s risks. Outsourcers may possess deeper knowledge of intrusion detection, forensics,

vulnerabilities, exploits, and other aspects of security than employees of the organization. Also,

MSSPs may be able to correlate events among customers so that they can identify new threats more

quickly than any individual customer could. However, technical staff members within the

organization usually have much better knowledge of the organization’s environment than an

outsourcer would, which can be beneficial in identifying false positives associated with organization-

specific behavior and the criticality of targets. Section 2.4.3 contains additional information on

recommended team member skills.

When considering outsourcing, organizations should keep these issues in mind:

 Current and Future Quality of Work. Organizations should consider not only the current quality (breadth and depth) of the outsourcer’s work, but also efforts to ensure the quality of future work—

for example, minimizing turnover and burnout and providing a solid training program for new

employees. Organizations should think about how they could objectively assess the quality of the

outsourcer’s work.

 Division of Responsibilities. Organizations are often unwilling to give an outsourcer authority to make operational decisions for the environment (e.g., disconnecting a web server). It is important to

document the appropriate actions for these decision points. For example, one partially outsourced

model addresses this issue by having the outsourcer provide incident data to the organization’s

internal team, along with recommendations for further handling the incident. The internal team

ultimately makes the operational decisions, with the outsourcer continuing to provide support as

needed.

 Sensitive Information Revealed to the Contractor. Dividing incident response responsibilities and restricting access to sensitive information can limit this. For example, a contractor may determine

what user ID was used in an incident (e.g., ID 123456) but not know what person is associated with

the user ID. Employees can then take over the investigation. Non-disclosure agreements (NDAs) are

one possible option for protecting the disclosure of sensitive information.

 Lack of Organization-Specific Knowledge. Accurate analysis and prioritization of incidents are dependent on specific knowledge of the organization’s environment. The organization should provide

the outsourcer regularly updated documents that define what incidents it is concerned about, which

resources are critical, and what the level of response should be under various sets of circumstances.

The organization should also report all changes and updates made to its IT infrastructure, network

configuration, and systems. Otherwise, the contractor has to make a best guess as to how each

incident should be handled, inevitably leading to mishandled incidents and frustration on both sides.

Lack of organization-specific knowledge can also be a problem when incident response is not

outsourced if communications are weak among teams or if the organization simply does not collect

the necessary information.

COMPUTER SECURITY INCIDENT HANDLING GUIDE

16

 Lack of Correlation. Correlation among multiple data sources is very important. If the intrusion detection system records an attempted attack against a web server, but the outsourcer has no access to

the server’s logs, it may be unable to determine whether the attack was successful. To be efficient, the

outsourcer will require administrative privileges to critical systems and security device logs remotely

over a secure channel. This will increase administration costs, introduce additional access entry

points, and increase the risk of unauthorized disclosure of sensitive information.

 Handling Incidents at Multiple Locations. Effective incident response work often requires a physical presence at the organization’s facilities. If the outsourcer is offsite, consider where the

outsourcer is located, how quickly it can have an incident response team at any facility, and how

much this will cost. Consider onsite visits; perhaps there are certain facilities or areas where the

outsourcer should not be permitted to work.

 Maintaining Incident Response Skills In-House. Organizations that completely outsource incident response should strive to maintain basic incident response skills in-house. Situations may arise in

which the outsourcer is unavailable, so the organization should be prepared to perform its own

incident handling. The organization’s technical staff must also be able to understand the significance,

technical implications, and impact of the outsourcer’s recommendations.

2.4.3 Incident Response Personnel

A single employee, with one or more designated alternates, should be in charge of incident response. In a

fully outsourced model, this person oversees and evaluates the outsourcer’s work. All other models

generally have a team manager and one or more deputies who assumes authority in the absence of the

team manager. The managers typically perform a variety of tasks, including acting as a liaison with upper

management and other teams and organizations, defusing crisis situations, and ensuring that the team has

the necessary personnel, resources, and skills. Managers should be technically adept and have excellent

communication skills, particularly an ability to communicate to a range of audiences. Managers are

ultimately responsible for ensuring that incident response activities are performed properly.

In addition to the team manager and deputy, some teams also have a technical lead—a person with strong

technical skills and incident response experience who assumes oversight of and final responsibility for the

quality of the team’s technical work. The position of technical lead should not be confused with the

position of incident lead. Larger teams often assign an incident lead as the primary POC for handling a

specific incident; the incident lead is held accountable for the incident’s handling. Depending on the size

of the incident response team and the magnitude of the incident, the incident lead may not actually

perform any actual incident handling, but rather coordinate the handlers’ activities, gather information

from the handlers, provide incident updates to other groups, and ensure that the team’s needs are met.

Members of the incident response team should have excellent technical skills, such as system

administration, network administration, programming, technical support, or intrusion detection. Every

team member should have good problem solving skills and critical thinking abilities. It is not necessary

for every team member to be a technical expert—to a large degree, practical and funding considerations

will dictate this—but having at least one highly proficient person in each major area of technology (e.g.,

commonly attacked operating systems and applications) is a necessity. It may also be helpful to have

some team members specialize in particular technical areas, such as network intrusion detection, malware

analysis, or forensics. It is also often helpful to temporarily bring in technical specialists that aren’t

normally part of the team.

It is important to counteract staff burnout by providing opportunities for learning and growth. Suggestions

for building and maintaining skills are as follows:

COMPUTER SECURITY INCIDENT HANDLING GUIDE

17

 Budget enough funding to maintain, enhance, and expand proficiency in technical areas and security disciplines, as well as less technical topics such as the legal aspects of incident response. This should

include sending staff to conferences and encouraging or otherwise incentivizing participation in

conferences, ensuring the availability of technical references that promote deeper technical

understanding, and occasionally bringing in outside experts (e.g., contractors) with deep technical

knowledge in needed areas as funding permits.

 Give team members opportunities to perform other tasks, such as creating educational materials, conducting security awareness workshops, and performing research.

 Consider rotating staff members in and out of the incident response team, and participate in exchanges in which team members temporarily trade places with others (e.g., network administrators)

to gain new technical skills.

 Maintain sufficient staffing so that team members can have uninterrupted time off work (e.g., vacations).

 Create a mentoring program to enable senior technical staff to help less experienced staff learn incident handling.

 Develop incident handling scenarios and have the team members discuss how they would handle them. Appendix A contains a set of scenarios and a list of questions to be used during scenario

discussions.

Incident response team members should have other skills in addition to technical expertise. Teamwork

skills are of fundamental importance because cooperation and coordination are necessary for successful

incident response. Every team member should also have good communication skills. Speaking skills are

important because the team will interact with a wide variety of people, and writing skills are important

when team members are preparing advisories and procedures. Although not everyone within a team needs

to have strong writing and speaking skills, at least a few people within every team should possess them so

the team can represent itself well in front of others.

2.4.4 Dependencies within Organizations

It is important to identify other groups within the organization that may need to participate in incident

handling so that their cooperation can be solicited before it is needed. Every incident response team relies

on the expertise, judgment, and abilities of others, including:

 Management. Management establishes incident response policy, budget, and staffing. Ultimately, management is held responsible for coordinating incident response among various stakeholders,

minimizing damage, and reporting to Congress, OMB, the General Accounting Office (GAO), and

other parties.

 Information Assurance. Information security staff members may be needed during certain stages of incident handling (prevention, containment, eradication, and recovery)—for example, to alter network

security controls (e.g., firewall rulesets).

 IT Support. IT technical experts (e.g., system and network administrators) not only have the needed skills to assist but also usually have the best understanding of the technology they manage on a daily

basis. This understanding can ensure that the appropriate actions are taken for the affected system,

such as whether to disconnect an attacked system.

COMPUTER SECURITY INCIDENT HANDLING GUIDE

18

 Legal Department. Legal experts should review incident response plans, policies, and procedures to ensure their compliance with law and Federal guidance, including the right to privacy. In addition, the

guidance of the general counsel or legal department should be sought if there is reason to believe that

an incident may have legal ramifications, including evidence collection, prosecution of a suspect, or a

lawsuit, or if there may be a need for a memorandum of understanding (MOU) or other binding

agreements involving liability limitations for information sharing.

 Public Affairs and Media Relations. Depending on the nature and impact of an incident, a need may exist to inform the media and, by extension, the public.

 Human Resources. If an employee is suspected of causing an incident, the human resources department may be involved—for example, in assisting with disciplinary proceedings.

 Business Continuity Planning. Organizations should ensure that incident response policies and procedures and business continuity processes are in sync. Computer security incidents undermine the

business resilience of an organization. Business continuity planning professionals should be made

aware of incidents and their impacts so they can fine-tune business impact assessments, risk

assessments, and continuity of operations plans. Further, because business continuity planners have

extensive expertise in minimizing operational disruption during severe circumstances, they may be

valuable in planning responses to certain situations, such as denial of service (DoS) conditions.

 Physical Security and Facilities Management. Some computer security incidents occur through breaches of physical security or involve coordinated logical and physical attacks. The incident

response team also may need access to facilities during incident handling—for example, to acquire a

compromised workstation from a locked office.

2.5 Incident Response Team Services

The main focus of an incident response team is performing incident response, but it is fairly rare for a

team to perform incident response only. The following are examples of other services a team might offer:

 Intrusion Detection. The first tier of an incident response team often assumes responsibility for intrusion detection.

17 The team generally benefits because it should be poised to analyze incidents

more quickly and accurately, based on the knowledge it gains of intrusion detection technologies.

 Advisory Distribution. A team may issue advisories within the organization regarding new vulnerabilities and threats.

18 Automated methods should be used whenever appropriate to disseminate

information; for example, the National Vulnerability Database (NVD) provides information via XML

and RSS feeds when new vulnerabilities are added to it. 19

Advisories are often most necessary when

new threats are emerging, such as a high-profile social or political event (e.g., celebrity wedding) that

attackers are likely to leverage in their social engineering. Only one group within the organization

should distribute computer security advisories to avoid duplicated effort and conflicting information.

 Education and Awareness. Education and awareness are resource multipliers—the more the users and technical staff know about detecting, reporting, and responding to incidents, the less drain there

17

See NIST SP 800-94, Guide to Intrusion Detection and Prevention Systems (IDPS) for more information on IDPS

technologies. It is available at http://csrc.nist.gov/publications/PubsSPs.html#800-94. 18

Teams should word advisories so that they do not blame any person or organization for security issues. Teams should meet

with legal advisors to discuss the possible need for a disclaimer in advisories, stating that the team and organization has no

liability in regard to the accuracy of the advisory. This is most pertinent when advisories may be sent to contractors,

vendors, and other nonemployees who are users of the organization’s computing resources. 19

http://nvd.nist.gov/

http://csrc.nist.gov/publications/PubsSPs.html#800-94
http://nvd.nist.gov/
COMPUTER SECURITY INCIDENT HANDLING GUIDE

19

should be on the incident response team. This information can be communicated through many

means: workshops, websites, newsletters, posters, and even stickers on monitors and laptops.

 Information Sharing. Incident response teams often participate in information sharing groups, such as ISACs or regional partnerships. Accordingly, incident response teams often manage the

organization’s incident information sharing efforts, such as aggregating information related to

incidents and effectively sharing that information with other organizations, as well as ensuring that

pertinent information is shared within the enterprise.

2.6 Recommendations

The key recommendations presented in this section for organizing a computer security incident handling

capability are summarized below.

 Establish a formal incident response capability. Organizations should be prepared to respond quickly and effectively when computer security defenses are breached. FISMA requires Federal

agencies to establish incident response capabilities.

 Create an incident response policy. The incident response policy is the foundation of the incident response program. It defines which events are considered incidents, establishes the organizational

structure for incident response, defines roles and responsibilities, and lists the requirements for

reporting incidents, among other items.

 Develop an incident response plan based on the incident response policy. The incident response plan provides a roadmap for implementing an incident response program based on the organization’s

policy. The plan indicates both short- and long-term goals for the program, including metrics for

measuring the program. The incident response plan should also indicate how often incident handlers

should be trained and the requirements for incident handlers.

 Develop incident response procedures. The incident response procedures provide detailed steps for responding to an incident. The procedures should cover all the phases of the incident response

process. The procedures should be based on the incident response policy and plan.

 Establish policies and procedures regarding incident-related information sharing. The organization should communicate appropriate incident details with outside parties, such as the media,

law enforcement agencies, and incident reporting organizations. The incident response team should

discuss this with the organization’s public affairs office, legal department, and management to

establish policies and procedures regarding information sharing. The team should comply with

existing organization policy on interacting with the media and other outside parties.

 Provide pertinent information on incidents to the appropriate organization. Federal civilian agencies are required to report incidents to US-CERT; other organizations can contact US-CERT

and/or their ISAC. Reporting is beneficial because US-CERT and the ISACs use the reported data to

provide information to the reporting parties regarding new threats and incident trends.

 Consider the relevant factors when selecting an incident response team model. Organizations should carefully weigh the advantages and disadvantages of each possible team structure model and

staffing model in the context of the organization’s needs and available resources.

 Select people with appropriate skills for the incident response team. The credibility and proficiency of the team depend to a large extent on the technical skills and critical thinking abilities of

its members. Critical technical skills include system administration, network administration,

programming, technical support, and intrusion detection. Teamwork and communications skills are

COMPUTER SECURITY INCIDENT HANDLING GUIDE

20

also needed for effective incident handling. Necessary training should be provided to all team

members.

 Identify other groups within the organization that may need to participate in incident handling. Every incident response team relies on the expertise, judgment, and abilities of other teams, including

management, information assurance, IT support, legal, public affairs, and facilities management.

 Determine which services the team should offer. Although the main focus of the team is incident response, most teams perform additional functions. Examples include monitoring intrusion detection

sensors, distributing security advisories, and educating users on security.

COMPUTER SECURITY INCIDENT HANDLING GUIDE

21

3. Handling an Incident

The incident response process has several phases. The initial phase involves establishing and training an

incident response team, and acquiring the necessary tools and resources. During preparation, the

organization also attempts to limit the number of incidents that will occur by selecting and implementing

a set of controls based on the results of risk assessments. However, residual risk will inevitably persist

after controls are implemented. Detection of security breaches is thus necessary to alert the organization

whenever incidents occur. In keeping with the severity of the incident, the organization can mitigate the

impact of the incident by containing it and ultimately recovering from it. During this phase, activity often

cycles back to detection and analysis—for example, to see if additional hosts are infected by malware

while eradicating a malware incident. After the incident is adequately handled, the organization issues a

report that details the cause and cost of the incident and the steps the organization should take to prevent

future incidents. This section describes the major phases of the incident response process—preparation,

detection and analysis, containment, eradication and recovery, and post-incident activity—in detail.

Figure 3-1 illustrates the incident response life cycle.

Figure 3-1. Incident Response Life Cycle

3.1 Preparation

Incident response methodologies typically emphasize preparation—not only establishing an incident

response capability so that the organization is ready to respond to incidents, but also preventing incidents

by ensuring that systems, networks, and applications are sufficiently secure. Although the incident

response team is not typically responsible for incident prevention, it is fundamental to the success of

incident response programs. This section provides basic advice on preparing to handle incidents and on

preventing incidents.

3.1.1 Preparing to Handle Incidents

The lists below provide examples of tools and resources available that may be of value during incident

handling. These lists are intended to be a starting point for discussions about which tools and resources an

organization’s incident handlers need. For example, smartphones are one way to have resilient emergency

COMPUTER SECURITY INCIDENT HANDLING GUIDE

22

communication and coordination mechanisms. An organization should have multiple (separate and

different) communication and coordination mechanisms in case of failure of one mechanism.

Incident Handler Communications and Facilities:

 Contact information for team members and others within and outside the organization (primary and backup contacts), such as law enforcement and other incident response teams; information may

include phone numbers, email addresses, public encryption keys (in accordance with the encryption

software described below), and instructions for verifying the contact’s identity

 On-call information for other teams within the organization, including escalation information

 Incident reporting mechanisms, such as phone numbers, email addresses, online forms, and secure instant messaging systems that users can use to report suspected incidents; at least one mechanism

should permit people to report incidents anonymously

 Issue tracking system for tracking incident information, status, etc.

 Smartphones to be carried by team members for off-hour support and onsite communications

 Encryption software to be used for communications among team members, within the organization and with external parties; for Federal agencies, software must use a FIPS-validated encryption

algorithm 20

 War room for central communication and coordination; if a permanent war room is not necessary or practical, the team should create a procedure for procuring a temporary war room when needed

 Secure storage facility for securing evidence and other sensitive materials

Incident Analysis Hardware and Software:

 Digital forensic workstations 21

and/or backup devices to create disk images, preserve log files, and

save other relevant incident data

 Laptops for activities such as analyzing data, sniffing packets, and writing reports

 Spare workstations, servers, and networking equipment, or the virtualized equivalents, which may be used for many purposes, such as restoring backups and trying out malware

 Blank removable media

 Portable printer to print copies of log files and other evidence from non-networked systems

 Packet sniffers and protocol analyzers to capture and analyze network traffic

 Digital forensic software to analyze disk images

 Removable media with trusted versions of programs to be used to gather evidence from systems

 Evidence gathering accessories, including hard-bound notebooks, digital cameras, audio recorders, chain of custody forms, evidence storage bags and tags, and evidence tape, to preserve evidence for

possible legal actions

20

FIPS 140-2, Security Requirements for Cryptographic Modules, http://csrc.nist.gov/publications/PubsFIPS.html. 21

A digital forensic workstation is specially designed to assist incident handlers in acquiring and analyzing data. These

workstations typically contain a set of removable hard drives that can be used for evidence storage.

http://csrc.nist.gov/publications/PubsFIPS.html
COMPUTER SECURITY INCIDENT HANDLING GUIDE

23

Incident Analysis Resources:

 Port lists, including commonly used ports and Trojan horse ports

 Documentation for OSs, applications, protocols, and intrusion detection and antivirus products

 Network diagrams and lists of critical assets, such as database servers

 Current baselines of expected network, system, and application activity

 Cryptographic hashes of critical files 22

to speed incident analysis, verification, and eradication

Incident Mitigation Software:

 Access to images of clean OS and application installations for restoration and recovery purposes

Many incident response teams create a jump kit, which is a portable case that contains materials that may

be needed during an investigation. The jump kit should be ready to go at all times. Jump kits contain

many of the same items listed in the bulleted lists above. For example, each jump kit typically includes a

laptop, loaded with appropriate software (e.g., packet sniffers, digital forensics). Other important

materials include backup devices, blank media, and basic networking equipment and cables. Because the

purpose of having a jump kit is to facilitate faster responses, the team should avoid borrowing items from

the jump kit.