Computer Security Incident Handling Guide

2y ago
11 Views
2 Downloads
1.23 MB
79 Pages
Last View : 4m ago
Last Download : 2m ago
Upload by : Lilly Andre
Transcription

Special Publication 800-61Revision 2Computer SecurityIncident Handling GuideRecommendations of the National Instituteof Standards and TechnologyPaul CichonskiTom MillarTim GranceKaren Scarfone

NIST Special Publication 800-61Revision 2Computer Security Incident HandlingGuideRecommendations of the NationalInstitute of Standards and TechnologyPaul CichonskiComputer Security DivisionInformation Technology LaboratoryNational Institute of Standards and TechnologyGaithersburg, MDTom MillarUnited States Computer Emergency Readiness TeamNational Cyber Security DivisionDepartment of Homeland SecurityTim GranceComputer Security DivisionInformation Technology LaboratoryNational Institute of Standards and TechnologyGaithersburg, MDKaren ScarfoneScarfone CybersecurityC O M P U T E RS E C U R I T YAugust 2012U.S. Department of CommerceRebecca Blank, Acting SecretaryNational Institute of Standards and TechnologyPatrick D. Gallagher,Under Secretary of Commerce for Standards and Technologyand Director

COMPUTER SECURITY INCIDENT HANDLING GUIDEReports 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 analyses to advance the development and productive use ofinformation 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 thannational security-related information in Federal information systems. The Special Publication 800-seriesreports on ITL’s research, guidelines, and outreach efforts in information system security, and itscollaborative activities with industry, government, and academic organizations.ii

COMPUTER SECURITY INCIDENT HANDLING GUIDEAuthorityThis publication has been developed by NIST to further its statutory responsibilities under the FederalInformation Security Management Act (FISMA), Public Law (P.L.) 107-347. NIST is responsible fordeveloping information security standards and guidelines, including minimum requirements for Federalinformation systems, but such standards and guidelines shall not apply to national security systemswithout the express approval of appropriate Federal officials exercising policy authority over suchsystems. 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 A130, 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 mandatoryand binding on Federal agencies by the Secretary of Commerce under statutory authority. Nor shouldthese guidelines be interpreted as altering or superseding the existing authorities of the Secretary ofCommerce, Director of the OMB, or any other Federal official. This publication may be used bynongovernmental 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 2Natl. Inst. Stand. Technol. Spec. Publ. 800-61 Revision 2, 79 pages (Aug. 2012)CODEN: NSPUE2Certain commercial entities, equipment, or materials may be identified in this document in order to describe anexperimental procedure or concept adequately. Such identification is not intended to imply recommendation orendorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily thebest available for the purpose.There may be references in this publication to other publications currently under development by NIST inaccordance with its assigned statutory responsibilities. The information in this publication, including conceptsand methodologies, may be used by Federal agencies even before the completion of such companionpublications. Thus, until each publication is completed, current requirements, guidelines, and procedures, wherethey exist, remain operative. For planning and transition purposes, Federal agencies may wish to closely followthe development of these new publications by NIST.Organizations are encouraged to review all draft publications during public comment periods and providefeedback to NIST. All NIST publications, other than the ones noted above, are available athttp://csrc.nist.gov/publications.Comments on this publication may be submitted to:National Institute of Standards and TechnologyAttn: Computer Security Division, Information Technology Laboratory100 Bureau Drive (Mail Stop 8930), Gaithersburg, MD 20899-8930iii

COMPUTER SECURITY INCIDENT HANDLING GUIDEAbstractComputer security incident response has become an important component of information technology (IT)programs. Because performing incident response effectively is a complex undertaking, establishing asuccessful incident response capability requires substantial planning and resources. This publicationassists organizations in establishing computer security incident response capabilities and handlingincidents 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.Keywordscomputer security incident; incident handling; incident response; information securityiv

COMPUTER SECURITY INCIDENT HANDLING GUIDEAcknowledgmentsThe 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 John Banghart of NIST; Brian Allen, Mark Austin,Brian DeWyngaert, Andrew Fuller, Chris Hallenbeck, Sharon Kim, Mischel Kwon, Lee Rock, RichardStruse, and Randy Vickers of US-CERT; and Marcos Osorno of the Johns Hopkins University AppliedPhysics Laboratory. A special acknowledgment goes to Brent Logan of US-CERT for his graphicsassistance. 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 Sharingand Analysis Center [REN-ISAC]), as well as representatives of the Blue Glacier Management Group, theCenters for Disease Control and Prevention, the Department of Energy, the Department of State, and theFederal Aviation Administration for their particularly valuable comments and suggestions.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.v

COMPUTER SECURITY INCIDENT HANDLING GUIDETable of ContentsExecutive Summary . 11.Introduction . 41.11.21.31.42.Organizing a Computer Security Incident Response Capability . 62.12.22.32.42.52.63.Events 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 . 132.4.1 Team Models .132.4.2 Team Model Selection.142.4.3 Incident Response Personnel.162.4.4 Dependencies within Organizations .17Incident Response Team Services . 18Recommendations . 19Handling an Incident .213.13.23.33.43.53.64.Authority . 4Purpose and Scope . 4Audience . 4Document Structure . 4Preparation. 213.1.1 Preparing to Handle Incidents .213.1.2 Preventing Incidents.23Detection and Analysis . 253.2.1 Attack Vectors .253.2.2 Signs of an Incident .263.2.3 Sources of Precursors and Indicators.273.2.4 Incident Analysis .283.2.5 Incident Documentation.303.2.6 Incident Prioritization .323.2.7 Incident Notification .33Containment, Eradication, and Recovery. 353.3.1 Choosing a Containment Strategy .353.3.2 Evidence Gathering and Handling .363.3.3 Identifying the Attacking Hosts .373.3.4 Eradication and Recovery .37Post-Incident Activity . 383.4.1 Lessons Learned.383.4.2 Using Collected Incident Data .393.4.3 Evidence Retention .41Incident Handling Checklist . 42Recommendations . 42Coordination and Information Sharing .45vi

COMPUTER SECURITY INCIDENT HANDLING GUIDE4.14.24.34.4Coordination . 454.1.1 Coordination Relationships .464.1.2 Sharing Agreements and Reporting Requirements .47Information Sharing Techniques . 484.2.1 Ad Hoc .484.2.2 Partially Automated .484.2.3 Security Considerations .49Granular Information Sharing . 494.3.1 Business Impact Information .494.3.2 Technical Information .50Recommendations . 51List of AppendicesAppendix A— Incident Handling Scenarios .52A.1 Scenario Questions . 52A.2 Scenarios . 53Appendix B— Incident-Related Data Elements .58B.1 Basic Data Elements . 58B.2 Incident Handler Data Elements . 59Appendix C— Glossary .60Appendix D— Acronyms .61Appendix E— Resources.63Appendix F— Frequently Asked Questions .65Appendix G— Crisis Handling Steps .68Appendix H— Change Log .69List of FiguresFigure 2-1. Communications with Outside Parties .10Figure 3-1. Incident Response Life Cycle .21Figure 3-2. Incident Response Life Cycle (Detection and Analysis).25Figure 3-3. Incident Response Life Cycle (Containment, Eradication, and Recovery) .35Figure 3-4. Incident Response Life Cycle (Post-Incident Activity) .38Figure 4-1. Incident Response Coordination .46vii

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

COMPUTER SECURITY INCIDENT HANDLING GUIDEExecutive SummaryComputer 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 moredamaging and disruptive. New types of security-related incidents emerge frequently. Preventive activitiesbased on the results of risk assessments can lower the number of incidents, but not all incidents can beprevented. 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 incidentrelated data and determining the appropriate response to each incident. The guidelines can be followedindependently 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 forattacks is essential. Establishing clear procedures for prioritizing the handling of incidents is critical, as isimplementing effective methods of collecting, analyzing, and reporting data. It is also vital to buildrelationships and establish suitable means of communication with other internal

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 w

Related Documents:

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.

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.

Incident handling requires people, process and technology. 36 Security Operation Centers Well-Defined Methodology ISO/IEC 27035:2011 Information technology -- Security techniques -- Information security incident management ards ENISA Good Practice Guide for Incident Management NIST SP 800-61 Rev. 2 Computer Security Incident Handling Guide

COMPUTER SECURITY INCIDENT DEFINITION "Any real or suspected adverse event in relation to the security of computer system or computer networks" - . Source: CERT/CC Incident Handling Life Cycle in CERT/CC "Handbook for Computer Incident Response Teams (CIRTs) Other IDS Hotline/Helpdesk Call Center Email Triage Information

security SANS Computer Security Incident Handling Step -by-Step Guide "an adverse event in an information system and/or network, or the threat of the occurrence of such an event" NIST Computer Security Incident Handling Guide "a violation or imminent threat of violation of computer security policies, acceptable use

Incident Management Process Map 1. Incident Management Process Map 1. Incident Management Description and Goals 9. Incident Management Description and Goals 9. Description 9. Description 9. Goals 9. Goals 9. Incident Management RACI Information 10. Incident Management RACI Information 10. Incident Management Associated Artifacts Information 24

NIST SP 800-61 «Computer security incident handling guide» represents the collection of the best practices in the field of construction of processes of reaction to computer security incidents [3]. However IS incident is wider than computer security incidents. The group of software and technical incidents, including computer

CIRT - Computer Incident Response Team IHT - Incident Handling Team IRC - Incident Response Center or Incident Response Capability . Stakeholders, roles and responsibilities (i.e. who will take part in it) Resource, financial and quality plans (i.e. how it will be achieved) .