Computer Security Incident Handling Guide Recommendati

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
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
Patrick D. Gallagher,
Under Secretary of Commerce for Standards and Technology
and Director
karenw
Typewritten Text
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.

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

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:
reporting
etting guidelines for communicating with outside parties
regarding incidents

between the incident response team and other
groups, both internal (e.g., legal department) and external (e.g.,
law enforcement agencies)
provide
2
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:
removable media (e.g., flash drive, CD) or a
peripheral device.
mploys brute force methods to
compromise, degrade, or destroy systems,
networks, or services.
-based
application.
attachment.
cident resulting from violation of an
organization’s acceptable usage
policies by an authorized user, excluding the above categories.
device or media used by the
organization, such as a laptop or smartphone.
categories.

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.
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:
possible incident response team
structures, and highlights other groups within an organization
that may participate in incident
handling.
provides advice for performing incident
handling more effectively, particularly incident detection and
analysis.
need for incident response
coordination and information sharing.

5
questions for use in incident response tabletop
discussions.
s lists of suggested data fields to collect
for each incident.
respectively.
planning and performing incident response.
covers frequently asked questions about incident
response.
computer security incident-related crisis.
since the previous revision.
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:
connection requests to a web server, causing
it to crash.
rt” sent via
email that is actually malware; running the

tool has infected their computers and established connections
with an external host.
details will be released publicly if the
organization does not pay a designated sum of money.
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.
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:
-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.”
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 … .”
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.
-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:

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://www.whitehouse.gov/omb/memoranda/fy2007/m07-16.pdf
8
what circumstances)
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
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:

roach to incident response
rest of the organization and with other
organizations
effectiveness
ident response capability
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
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.
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:

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.
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.
11
that communications with the media are
consistent and up-to-date.
l procedures for handling media
inquiries.
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/
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 l ikely
that others are experiencing similar issues,
and the trusted introducer can ensure that any such patterns are
identified and taken into consideration.
from its ISP in blocking a major network-
based attack or tracing its origin.
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 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.
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.
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/

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:
team handles incidents throughout the
organization. This model is effective for small organizati ons
and for organizations with minimal
geographic diversity in terms of computing resources.
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.

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
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:
response work, with limited technical and

administrative support from contractors.
ganization 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.
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:
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.
-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 emergenc y 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.
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

15
reducing the amount of administrative work that team members
are responsible for performing, can
be a significant boost to morale.
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.
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:
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.
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.
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.
-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.
16
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.
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.
-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:
17
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.
such as creating educational materials,
conducting security awareness workshops, and performing
research.

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.
e
uninterrupted time off work (e.g.,
vacations).
to help less experienced staff learn
incident handling.
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:
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.
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).
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.
18
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.
and impact of an incident, a need may
exist to inform the media and, by extension, the public.

incident, the human resources
department may be involved—for example, in assisting with
disciplinary proceedings.
ions 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.
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:
irst 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.
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.
cation 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/
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.
sponse 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.
Organizations should be prepared to respond

quickly and effectively when computer security defenses are
breached. FISMA requires Federal
agencies to establish incident response capabilities.
policy is the foundation of the incident
response program. It defines which events are considered
incidents, establishes the organizatio nal
structure for incident response, defines roles and
responsibilities, and lists the requirements for
reporting incidents, among other items.
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.
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.

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

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
20
also needed for effective incident handling. Necessary training
should be provided to all team
members.
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.
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.
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
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:
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
-call information for other teams within the organization,
including escalation information

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
status, etc.
-hour
support and onsite communications
team members, within the organization
and with external parties; for Federal agencies, software must
use a FIPS-validated encryption
algorithm
20
permanent war room is not necessary or
practical, the team should create a procedure for procuring a
temporary war room when needed
sensitive materials
Incident Analysis Hardware and Software:
21
and/or backup devices to create disk images, preserve log files,

and
save other relevant incident data
packets, and writing reports
the virtualized equivalents, which
may be used for many purposes, such as restoring backups and
trying out malware
from non-networked systems
l analyzers to capture and analyze
network traffic
used to gather evidence from systems
-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.
23
Incident Analysis Resources:
ports
detection and antivirus products
database servers
application activity
22
to speed incident analysis, verification, and eradication
Incident Mitigation Software:

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.
Each incident handler should have access to at least two
computing devices (e.g., laptops). One, such as
the one from the jump kit, should be used to perform packet
sniffing, malware analysis, and all other
actions that risk contaminating the laptop that performs them.
This laptop should be scrubbed and all
software reinstalled before it is used for another incident. Note
that because this laptop is special purpose,

it is likely to use software other than the standard enterprise
tools and configurations, and whenever
possible the incident handlers should be allowed to specify
basic technical requirements for these special-
purpose investigative laptops. In addition to an investigative
laptop, each incident handler should also
have a standard laptop, smart phone, or other computing device
for writing reports, reading email, and
performing other duties unrelated to the hands-on incident
analysis.
Exercises involving simulated incidents can also be very useful
for preparing staff for incident handling;
see NIST SP 800-84 for more information on exercises
23
and Appendix A for sample exercise scenarios.
3.1.2 Preventing Incidents
Keeping the number of incidents reasonably low is very
important to protect the business processes of the
organization. If security controls are insufficient, higher
volumes of incidents may occur, overwhelming
the incident response team. This can lead to slow and
incomplete responses, which translate to a larger
negative business impact (e.g., more extensive damage, longer
periods of service and data unavailability).

It is outside the scope of this document to provide specific
advice on securing networks, systems, and
applications. Although incident response teams are generally
not responsible for securing resources, they
can be advocates of sound security practices. An incident
response team may be able to identify problems
that the organization is otherwise not aware of; the team can
play a key role in risk assessment and
training by identifying gaps. Other documents already provide
advice on general security concepts and
22
The National Software Reference Library (NSRL) Project
maintains records of hashes of various files, including operating
system, application, and graphic image files. The hashes can be
downloaded from http://www.nsrl.nist.gov/.
23
Guide to Test, Training, and Exercise Programs for IT Plans
and Capabilities,
http://www.nsrl.nist.gov/

24
operating system and application-specific guidelines.
24
The following text, however, provides a brief
overview of some of the main recommended practices for
securing networks, systems, and applications:
ments of systems and
applications should determine what
risks are posed by combinations of threats and vulnerabilities.
25
This should include understanding the
applicable threats, including organization-specific threats. Each
risk should be prioritized, and the
risks can be mitigated, transferred, or accepted until a
reasonable overall level of risk is reached.
Another benefit of conducting risk assessments regularly is that
critical resources are identified,
allowing staff to emphasize monitori ng and response activities
for those resources.
26
using standard configurations. In addition
to keeping each host properly patched, hosts should be
configured to follow the principle of least

privilege—granting users only the privileges necessary for
performing their authorized tasks. Hosts
should have auditing enabled and should log significant
security-related events. The security of hosts
and their configurations should be continuously monitored.
27
Many organizations use Security
Content Automation Protocol (SCAP)
28
expressed operating system and application configuration
checklists to assist in securing hosts consistently and
effectively.
29
perimeter should be
configured to deny all activity that is not
expressly permitted. This includes securing all connection
points, such as virtual private networks
(VPNs) and dedicated connections to other organizations.
to detect and stop malware
should be deployed throughout the
organization. Malware protection should be deployed at the host
level (e.g., server and workstation
operating systems), the application server level (e.g., email
server, web proxies), and the application

client level (e.g., email clients, instant messaging clients).
30
policies and procedures regarding
appropriate use of networks, systems, and applications.
Applicable lessons learned from previous
incidents should also be shared with users so they can see how
their actions could affect the
organization. Improving user awareness regarding incidents
should reduce the frequency of incidents.
IT staff should be trained so that they can maintain their
networks, systems, and applications in
accordance with the organization’s security standards.
24
http://csrc.nist.gov/publications/PubsSPs.html provides links
to the NIST Special Publications on computer security, which
include documents on operating system and application security
baselines.
25
Guidelines on risk assessment are available in NIST SP 800-
30, Guide for Conducting Risk Assessments, at
http://csrc.nist.gov/publications/PubsSPs.html#800-30-Rev1.
26

Information on identifying critical resources is discussed in
FIPS 199, Standards for Security Categorization of Federal
Information and Information Systems, at
http://csrc.nist.gov/publications/PubsFIPS.html.
27
For more information on continuous monitoring, see NIST SP
800-137, Information Security Continuous Monitoring for
Federal Information Systems and Organizations
(http://csrc.nist.gov/publications/PubsSPs.html#800-137).
28
More information on SCAP is available from NIST SP 800-117
Revision 1, Guide to Adopting and Using the Security
Content Automation Protocol (SCAP) Version 1.2
(http://csrc.nist.gov/publications/PubsSPs.html#800-117).
29
NIST hosts a security checklists repository at
http://checklists.nist.gov/.
30
More information on malware prevention is available from
NIST SP 800-83, Guide to Malware Incident Prevention and
Handling (http://csrc.nist.gov/publications/PubsSPs.html#800-
83).
http://csrc.nist.gov/publications/PubsSPs.html
http://www.cisecurity.org/
http://www.cisecurity.org/
http://csrc.nist.gov/publications/PubsSPs.html#800-30-Rev1

http://checklists.nist.gov/
25
3.2 Detection and Analysis
Figure 3-2. Incident Response Life Cycle (Detection and
Analysis)
3.2.1 Attack Vectors
Incidents can occur in countless ways, so it is infeasible to
develop step-by-step instructions for handling
every incident. Organizations should be generally prepared to
handle any incident but should focus on
being prepared to handle incidents that use common attack
vectors. Different types of incidents merit
different response strategies. The attack vectors listed below are
not intended to provide definitive
classification for incidents; rather, they simply list common
methods of attack, which can be used as a
basis for defining more specific handling procedures.

removable media or a peripheral device—for
example, malicious code spreading onto a system from an
infected USB flash drive.
compromise, degrade, or destroy systems,
networks, or services (e.g., a DDoS intended to impair or deny
access to a service or application; a
brute force attack against an authentication mechanism, such as
passwords, CAPTCHAS, or digital
signatures).
-based
application—for example, a cross-site
scripting attack used to steal credentials or a redirect to a site
that exploits a browser vulnerability and
installs malware.
attachment—for example, exploit code disguised
as an attached document or a link to a malicious website in the
body of an email message.
ersonation: An attack involving replacement of something
benign with something malicious—
for example, spoofing, man in the middle attacks, rogue
wireless access points, and SQL injection
attacks all involve impersonation.
t resulting from violation of an
organization’s acceptable usage

policies by an authorized user, excluding the above categories;
for example, a user installs file sharing
software, leading to the loss of sensitive data; or a user
performs illegal activities on a system.
26
device or media used by the
organization, such as a laptop, smartphone, or authentication
token.
t does not fit into any of the other
categories.
This section focuses on recommended practices for handling any
type of incident. It is outside the scope
of this publication to give specific advice based on the attack
vectors; such guidelines would be provided
in separate publications addressing other incident handling
topics, such as NIST SP 800-83 on malware
incident prevention and handling.
3.2.2 Signs of an Incident
For many organizations, the most challenging part of the
incident response process is accurately detecting

and assessing possible incidents—determining whether an
incident has occurred and, if so, the type,
extent, and magnitude of the problem. What makes this so
challenging is a combination of three factors:
be detected through many different means,
with varying levels of detail and fidelity.
Automated detection capabilities include network-based and
host-based IDPSs, antivirus software,
and log analyzers. Incidents may also be detected through
manual means, such as problems reported
by users. Some incidents have overt signs that can be easily
detected, whereas others are almost
impossible to detect.
—
for example, it is not uncommon for an
organization to receive thousands or even millions of intrusion
detection sensor alerts per day. (See
Section 3.2.4 for information on analyzing such alerts.)
experience are necessary for proper and
efficient analysis of incident-related data.
Signs of an incident fall into one of two categories: precursors
and indicators. A precursor is a sign that
an incident may occur in the future. An indicator is a sign that
an incident may have occurred or may be

occurring now.
Most attacks do not have any identifiable or detectable
precursors from the target’s perspective. If
precursors are detected, the organization may have an
opportunity to prevent the incident by altering its
security posture to save a target from attack. At a minimum, the
organization could monitor activity
involving the target more closely. Examples of precursors are:
scanner
ploit that targets a vulnerability
of the organization’s mail server
organization.
While precursors are relatively rare, indicators are all too
common. Too many types of indicators exist to
exhaustively list them, but some examples are listed below:
overflow attempt occurs against a database
server.
infected with malware.
characters.

27
unfamiliar remote system.
emails with suspicious content.
typical network traffic flows.
3.2.3 Sources of Precursors and Indicators
Precursors and indicators are identified using many different
sources, with the most common being
computer security software alerts, logs, publicly available
information, and people. Table 3-2 lists
common sources of precursors and indicators for each category.
Table 3-1. Common Sources of Precursors and Indicators
Source Description
Alerts
IDPSs IDPS products identify suspicious events and record
pertinent data regarding them, including the

date and time the attack was detected, the type of attack, the
source and destination IP
addresses, and the username (if applicable and known). Most
IDPS products use attack
signatures to identify malicious activity; the signatures must be
kept up to date so that the
newest attacks can be detected. IDPS software often produces
false positives—alerts that
indicate malicious activity is occurring, when in fact there has
been none. Analysts should
manually validate IDPS alerts either by closely reviewing the
recorded supporting data or by
getting related data from other sources.
31
SIEMs Security Information and Event Management (SIEM)
products are similar to IDPS products, but
they generate alerts based on analysis of log data (see below).
Antivirus and
antispam
software
Antivirus software detects various forms of malware, generates
alerts, and prevents the malware
from infecting hosts. Current antivirus products are effective at
stopping many instances of
malware if their signatures are kept up to date. Antispam
software is used to detect spam and
prevent it from reaching users’ mailboxes. Spam may contain
malware, phishing attacks, and
other malicious content, so alerts from antispam software may
indicate attack attempts.

File integrity
checking
software
File integrity checking software can detect changes made to
important files during incidents. It
uses a hashing algorithm to obtain a cryptographic checksum for
each designated file. If the file
is altered and the checksum is recalculated, an extremely high
probability exists that the new
checksum will not match the old checksum. By regularly
recalculating checksums and comparing
them with previous values, changes to files can be detected.
Third-party
monitoring
services
Third parties offer a variety of subscription-based and free
monitoring services. An example is
fraud detection services that will notify an organization if its IP
addresses, domain names, etc.
are associated with current incident activity involving other
organizations. There are also free
real-time blacklists with similar information. Another example
of a third-party monitoring service
is a CSIRC notification list; these lists are often available only
to other incident response teams.
Logs
Operating
system,
service and
application

logs
Logs from operating systems, services, and applications
(particularly audit-related data) are
frequently of great value when an incident occurs, such as
recording which accounts were
accessed and what actions were performed. Organizations
should require a baseline level of
logging on all systems and a higher baseline level on critical
systems. Logs can be used for
analysis by correlating event information. Depending on the
event information, an alert can be
generated to indicate an incident. Section 3.2.4 discusses the
value of centralized logging.
Network
device logs
Logs from network devices such as firewalls and routers are not
typically a primary source of
precursors or indicators. Although these devices are usually
configured to log blocked
connection attempts, they provide little information about the
nature of the activity. Still, they can
be valuable in identifying network trends and in correlating
events detected by other devices.
31
See NIST SP 800-94, Guide to Intrusion Detection and
Prevention Systems, for additional information on IDPS
products. It
is available at
http://csrc.nist.gov/publications/PubsSPs.html#800-94.

28
Source Description
Network flows A network flow is a particular communication
session occurring between hosts. Routers and
other networking devices can provide network flow information,
which can be used to find
anomalous network activity caused by malware, data
exfiltration, and other malicious acts. There
are many standards for flow data formats, including NetFlow,
sFlow, and IPFIX.
Publicly Available Information
Information on
new
vulnerabilities
and exploits
Keeping up with new vulnerabilities and exploits can prevent
some incidents from occurring and
assist in detecting and analyzing new attacks. The National
Vulnerability Database (NVD)
contains information on vulnerabilities.
32
Organizations such as US-CERT
33

and CERT
®
/CC
periodically provide threat update information through
briefings, web postings, and mailing lists.
People
People from
within the
organization
Users, system administrators, network administrators, security
staff, and others from within the
organization may report signs of incidents. It is important to
validate all such reports. One
approach is to ask people who provide such information how
confident they are of the accuracy
of the information. Recording this estimate along with the
information provided can help
considerably during incident analysis, particularly when
conflicting data is discovered.
People from
other
organizations
Reports of incidents that originate externally should be taken
seriously. For example, the
organization might be contacted by a party claiming a system at
the organization is attacking its
systems. External users may also report other indicators, such as
a defaced web page or an
unavailable service. Other incident response teams also may

report incidents. It is important to
have mechanisms in place for external parties to report
indicators and for trained staff to monitor
those mechanisms carefully; this may be as simple as setting up
a phone number and email
address, configured to forward messages to the help desk.
3.2.4 Incident Analysis
Incident detection and analysis would be easy if every precursor
or indicator were guaranteed to be
accurate; unfortunately, this is not the case. For example, user -
provided indicators such as a complaint of
a server being unavailable are often incorrect. Intrusion
detection systems may produce false positives—
incorrect indicators. These examples demonstrate what makes
incident detection and analysis so difficult:
each indicator ideally should be evaluated to determine if it is
legitimate. Making matters worse, the total
number of indicators may be thousands or millions a day.
Finding the real security incidents that occurred
out of all the indicators can be a daunting task.
Even if an indicator is accurate, it does not necessarily mean
that an incident has occurred. Some
indicators, such as a server crash or modification of critical
files, could happen for several reasons other

Computer Security Incident Handling Guide Recommendati

Computer Security Incident Handling Guide Recommendati

Related slideshows

More Related Content

Computer Security Incident Handling Guide Recommendati