NIST SP 800-61, Computer Security Incident Handling Guide
Special Publication 800-61Revision 2 (Draft)Computer SecurityIncident Handling Guide(Draft)Recommendations of the National Instituteof Standards and TechnologyPaul CichonskiTom MillarTim GranceKaren Scarfone
NIST Special Publication 800-61Revision 2 (Draft)Computer Security Incident HandlingGuide (Draft)Recommendations of the NationalInstitute of Standards and TechnologyPaul CichonskiTom MillarTim GranceKaren ScarfoneC O M P U T E RS E C U R I T YComputer Security DivisionInformation Technology LaboratoryNational Institute of Standards and TechnologyGaithersburg, MD 20899-8930January 2012U.S. Department of CommerceJohn Bryson, SecretaryNational Institute of Standards and TechnologyPatrick D. Gallagher,Under Secretary for Standards and Technologyand Director
COMPUTER SECURITY INCIDENT HANDLING GUIDE (DRAFT)Reports on Computer Systems TechnologyThe 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’smeasurement and standards infrastructure. ITL develops tests, test methods, reference data, proof ofconcept implementations, and technical analysis to advance the development and productive use ofinformation technology. ITL’s responsibilities include the development of technical, physical,administrative, and management standards and guidelines for the cost-effective security and privacy ofsensitive unclassified information in Federal computer systems. This Special Publication 800-seriesreports on ITL’s research, guidance, and outreach efforts in computer security and its collaborativeactivities with industry, government, and academic organizations.NIST Special Publication 800-61 Revision 2 (Draft)63 pages (Jan. 2012)Certain commercial entities, equipment, or materials may be identified in thisdocument in order to describe an experimental procedure or concept adequately.Such identification is not intended to imply recommendation or endorsement by theNational Institute of Standards and Technology, nor is it intended to imply that theentities, materials, or equipment are necessarily the best available for the purpose.ii
COMPUTER SECURITY INCIDENT HANDLING GUIDE (DRAFT)AcknowledgmentsThe authors, Paul Cichonski of the National Institute of Standards and Technology (NIST), Tom Millar ofthe United States Computer Emergency Readiness Team (US-CERT), Tim Grance of NIST, and KarenScarfone of Scarfone Cybersecurity wish to thank their colleagues who reviewed drafts of this documentand contributed to its technical content, including Mark Austin, Brian DeWyngaert, Andrew Fuller, ChrisHallenbeck, Sharon Kim, and Lee Rock of US-CERT, and Marcos Osorno of the Johns HopkinsUniversity Applied Physics Laboratory. A special acknowledgment goes to Brent Logan of US-CERT forhis graphics assistance.The authors would also like to acknowledge the individuals that contributed to the previous versions ofthe publication. A special thanks goes to Brian Kim of Booz Allen Hamilton, who co-authored theoriginal 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, GaryStoneburner, 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, RonRitchey, and Marc Stevens of Booz Allen Hamilton for their keen and insightful assistance throughout thedevelopment of the document, as well as Ron Banerjee and Gene Schultz for their work on a preliminarydraft 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 FargoBank), 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), RobinRuefle (CERT /CC), Gene Schultz (Lawrence Berkeley National Laboratory), Michael Smith (USCERT), 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 valuablecomments and suggestions.iii
COMPUTER SECURITY INCIDENT HANDLING GUIDE (DRAFT)Table of ContentsExecutive Summary . 11.Introduction . 41.11.21.31.42.Organizing A Computer Security Incident Response Capability . 62.12.22.32.42.52.63.Authority . 4Purpose and Scope . 4Audience . 4Document Structure . 4Events and Incidents . 6Need for Incident Response . 6Incident Response Policy, Plan, and Procedure Creation . 72.3.1 Policy Elements. 72.3.2 Plan Elements . 82.3.3 Procedure Elements. 82.3.4 Sharing Information With Outside Parties . 9Incident Response Team Structure . 122.4.1 Team Models .122.4.2 Team Model Selection.132.4.3 Incident Response Personnel.152.4.4 Dependencies Within Organizations.16Incident Response Team Services . 17Recommendations . 18Handling an Incident .193.13.23.33.43.53.6Preparation. 193.1.1 Preparing to Handle Incidents .193.1.2 Preventing Incidents.21Detection and Analysis . 223.2.1 Incident Categories .223.2.2 Signs of an Incident .233.2.3 Sources of Precursors and Indicators.243.2.4 Incident Analysis .253.2.5 Incident Documentation.283.2.6 Incident Prioritization .293.2.7 Incident Notification .31Containment, Eradication, and Recovery. 323.3.1 Choosing a Containment Strategy .323.3.2 Evidence Gathering and Handling .333.3.3 Identifying the Attacking Hosts .343.3.4 Eradication and Recovery .34Post-Incident Activity . 353.4.1 Lessons Learned.353.4.2 Using Collected Incident Data .363.4.3 Evidence Retention .38Incident Handling Checklist . 39Recommendations . 39iv
COMPUTER SECURITY INCIDENT HANDLING GUIDE (DRAFT)List of AppendicesAppendix A— Incident Handling Scenarios .42A.1 Scenario Questions . 42A.2 Scenarios . 43Appendix B— Incident-Related Data Elements .48B.1 Basic Data Elements . 48B.2 Incident Handler Data Elements . 49Appendix C— Glossary .50Appendix D— Acronyms .51Appendix E— Resources.53Appendix F— Frequently Asked Questions .54Appendix G— Crisis Handling Steps .56Appendix H— Change Log .57List of FiguresFigure 2-1. Communications with Outside Parties . 9Figure 3-1. Incident Response Life Cycle .19Figure 3-2. Incident Response Life Cycle (Detection and Analysis).22Figure 3-3. Incident Response Life Cycle (Containment, Eradication, and Recovery) .32Figure 3-4. Incident Response Life Cycle (Post-Incident Activity) .35List of TablesTable 3-1. Tools and Resources for Incident Handlers .20Table 3-2. Common Sources of Precursors and Indicators .24Table 3-3. Functional Impact Categories .30Table 3-4. Information Impact Categories .30Table 3-5. Recoverability Effort Categories .30Table 3-6. Incident Handling Checklist .39v
COMPUTER SECURITY INCIDENT HANDLING GUIDE (DRAFT)Executive SummaryComputer security incident response has become an important component of information technology (IT)programs. Security-related threats have become not only more numerous and diverse but also moredamaging and disruptive. New types of security-related incidents emerge frequently. Preventativeactivities based on the results of risk assessments can lower the number of incidents, but not all incidentscan 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 computingservices. To that end, this publication provides guidelines for incident handling, particularly for analyzingincident-related data and determining the appropriate response to each incident. The guidelines can befollowed independently of particular hardware platforms, operating systems, protocols, or applications.Because performing incident response effectively is a complex undertaking, establishing a successfulincident response capability requires substantial planning and resources. Continually monitoring threatsthrough intrusion detection and prevention systems (IDPSs) and other mechanisms is essential.Establishing clear procedures for prioritizing the handling of incidents is critical, as is implementingeffective methods of collecting, analyzing, and reporting data. It is also vital to build relationships andestablish suitable means of communication with other internal groups (e.g., human resources, legal) andwith external groups (e.g., other incident response teams, law enforcement).This publication seeks to help both established and newly formed incident response teams. Thispublication assists organizations in establishing computer security incident response capabilities andhandling incidents efficiently and effectively. This revision of the publication, Revision 2, updatesmaterial throughout the publication to reflect the changes in threats and incidents. Unlike most threatsseveral years ago, which tended to be short-lived and easy to notice, many of today’s threats are morestealthy, specifically designed to quietly, slowly spread to other hosts, gathering information overextended periods of time and eventually leading to exfiltration of sensitive data and other negativeimpacts. Identifying these threats in their early stages is key to preventing subsequent compromises, andsharing information among organizations regarding the signs of these threats is an increasingly effectiveway to identify them.Implementing the following requirements and recommendations should facilitate efficient and effectiveincident response for Federal departments and agencies.Organizations must create, provision, and operate a formal incident response capability. Federallaw requires Federal agencies to report incidents to the United States Computer EmergencyReadiness Team (US-CERT) office within the Department of Homeland Security.The Federal Information Security Management Act (FISMA) requires Federal agencies to establishincident response capabilities. Each Federal civilian agency must designate a primary and secondary pointof contact (POC) with US-CERT and report all incidents consistent with the agency’s incident responsepolicy. Each agency is responsible for determining how to fulfill these requirements.Establishing an incident response capability should include the following actions: Creating an incident response policy and plan Developing procedures for performing incident handling and reporting Setting guidelines for communicating with outside parties regarding incidents Selecting a team structure and staffing model1
COMPUTER SECURITY INCIDENT HANDLING GUIDE (DRAFT) Establishing relationships between the incident response team and other groups, both internal (e.g.,legal department) and external (e.g., law enforcement agencies) Determining what services the incident response team should provide Staffing and training the incident response team.Organizations should reduce the frequency of incidents by effectively securing networks, systems,and applications.Preventing problems is 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 areinsufficient, high volumes of incidents may occur. This could overwhelm the resources and capacity forresponse, which would result in delayed or incomplete recovery and possibly more extensive damage andlonger periods of service and data unavailability. Incident handling can be performed more effectively iforganizations complement their incident response capability with adequate resources to actively maintainthe security of networks, systems, and applications.Organizations should document their guidelines for interactions with other organizations regardingincidents.During incident handling, the organization will need to communicate with outside parties, such as otherincident response teams, law enforcement, the media, vendors, and external victims. Because thesecommunications often need to occur quickly, organizations should predetermine communicationguidelines so that only the appropriate information is shared with the right parties.Organizations should prepare generally to handle any type of incident and more specifically tohandle common incident types.Incidents can occur in countless ways, so it is infeasible to develop step-by-step instructions for handlingevery incident. This publication defines several incident categories, based on common methods of attack;these categories are not comprehensive nor intended to provide definitive classification for incidents, butrather to be used as a basis for defining more specific handling procedures. The categories are: External/Removable Media: An attack executed from removable media or a peripheral device. Attrition: An attack that employs brute force methods to compromise, degrade, or destroy systems,networks, or services. Web: An attack executed from a website or web-based application. Email: An attack executed via an email message or attachment. Improper Usage: Any incident resulting from violation of an organization’s acceptable usagepolicies by an authorized user, excluding the above categories. Loss or Theft of Equipment: The loss or theft of a computing device or media used by theorganization, such as a laptop or smartphone. Other: An attack that does not fit into any of the other categories.Organizations should emphasize the importance of incident detection and analysis throughout theorganization.2
COMPUTER SECURITY INCIDENT HANDLING GUIDE (DRAFT)In an organization, millions of possible signs of incidents may occur each day, recorded mainly bylogging and computer security software. Automation is needed to perform an initial analysis of the dataand select events of interest for human review. Event correlation software can be of great value inautomating the analysis process. However, the effectiveness of the process depends on the quality of thedata that goes into it. Organizations should establish logging standards and procedures to ensure thatadequate information is collected by logs and security software and that the data is reviewed regularly.Organizations should create written guidelines for prioritizing inciden
NIST Special Publication 800-61 Revision 2 (Draft) Computer Security Incident Handling Guide (Draft) Recommendations of the National Institute of Standards and Technology Paul Cichonski Tom Millar Tim Grance Karen Scarfone C O M
2.1 NIST SP 800-18 4 2.2 NIST SP 800-30 4 2.3 NIST SP 800-34 4 2.4 NIST SP 800-37 4 2.5 NIST SP 800-39 5 2.6 NIST SP 800-53 5 2.7 NIST SP 800-53A 5 2.8 NIST SP 800-55 5 2.9 NIST SP 800-60 5 2.10 NIST SP 800-61 6 2.11 NIST SP 800-70 6 2.12 NIST SP 800-137 6 3 CERT-RMM Crosswalk of NIST 800-Series Special Publications 7
NIST SP 800-30 – Risk Assessment NIST SP 800-37 – Risk Management Framework NIST SP 800-39 – Risk Management NIST SP 800-53 – Recommended Security Controls NIST SP 800-53A – Security Control Assessment NIST SP 800-59 – National Security Systems NIST SP 800-60 – Security Category Mapping NIST
NIST Risk Management Framework 1. Categorize information system (NIST SP 800-60) 2. Select security controls (NIST SP 800-53) 3. Implement security controls (NIST SP 800-160) 4. Assess security controls (NIST SP 800-53A) 5. Authorize information system (NIST SP 800-37) 6. Monitor security controls (NIST SP 800-137) Source: NIST CSRC, http .
Source: 9th Annual API Cybersecurity Conference & Expo November 11-12, 2014 - Houston, TX. 11 Industry Standards and Committee Initiatives WIB M2784-X-10 API 1164 ISA 99/IEC 62443 NIST SP 800-82 NIST SP 800-12 NIST SP 800-53 NIST SP 800-53A NIST SP 800-39 NIST SP 800-37 NIST SP 800-30 NIST SP 800-34 ISO 27001,2 ISO 27005 ISO 31000
Apr 08, 2020 · Email sec-cert@nist.gov Background: NIST Special Publication (SP) 800-53 Feb 2005 NIST SP 800-53, Recommended Security Controls for Federal Information Systems, originally published Nov 2001 NIST SP 800-26, Security Self-Assessment Guide for IT Systems, published Dec 2006 NIST SP 800-53, Rev. 1 published July 2008 NIST SP 800-53A, Guide for
Mar 01, 2018 · ISO 27799-2008 7.11 ISO/IEC 27002:2005 14.1.2 ISO/IEC 27002:2013 17.1.1 MARS-E v2 PM-8 NIST Cybersecurity Framework ID.BE-2 NIST Cybersecurity Framework ID.BE-4 NIST Cybersecurity Framework ID.RA-3 NIST Cybersecurity Framework ID.RA-4 NIST Cybersecurity Framework ID.RA-5 NIST Cybersecurity Framework ID.RM-3 NIST SP 800-53
NIST 800-53 Compliance Controls 1 NIST 800-53 Compliance Controls The following control families represent a portion of special publication NIST 800-53 revision 4. This guide is intended to aid McAfee, its partners, and its customers, in aligning to the NIST 800-53 controls with McAfee
Is this Software Security? FISMA NIST 800-53 NIST 800-53A NIST 800-37 NIST 800-64 NIST 800-115 DISA STIG Application Security DoDI 8510.01 (DIACAP) HSPD-7 H
