Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Computer Security Incident Handling Guide, Lecture notes of Network and System Administration

Computer Security Incident Handling Guide

Typology: Lecture notes

2016/2017

Uploaded on 09/26/2017

Davison.Demo
Davison.Demo 🇬🇧

4

(2)

1 document

1 / 79

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
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
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c
pf1d
pf1e
pf1f
pf20
pf21
pf22
pf23
pf24
pf25
pf26
pf27
pf28
pf29
pf2a
pf2b
pf2c
pf2d
pf2e
pf2f
pf30
pf31
pf32
pf33
pf34
pf35
pf36
pf37
pf38
pf39
pf3a
pf3b
pf3c
pf3d
pf3e
pf3f
pf40
pf41
pf42
pf43
pf44
pf45
pf46
pf47
pf48
pf49
pf4a
pf4b
pf4c
pf4d
pf4e
pf4f

Partial preview of the text

Download Computer Security Incident Handling Guide and more Lecture notes Network and System Administration in PDF only on Docsity!

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

NIST Special Publication 800- 61 Revision 2

Computer Security Incident Handling

Guide

Recommendations of the National

Institute of Standards and Technology

Paul Cichonski Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD

Tom Millar United States Computer Emergency Readiness Team National Cyber Security Division Department of Homeland Security

Tim Grance Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD

Karen Scarfone Scarfone Cybersecurity

C O M P U T E R S E C U R I T Y

August 2012

U.S. Department of Commerce

Rebecca Blank, Acting Secretary

National Institute of Standards and Technology

Patrick D. Gallagher, Under Secretary of Commerce for Standards and Technology and Director

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

Comments on this publication may be submitted to:

National Institute of Standards and Technology Attn: Computer Security Division, Information Technology Laboratory 100 Bureau Drive (Mail Stop 8930), Gaithersburg, MD 20899-

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.

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

vi

  • Executive Summary Table of Contents
    1. Introduction
    • 1.1 Authority
    • 1.2 Purpose and Scope
    • 1.3 Audience
    • 1.4 Document Structure
    1. Organizing a Computer Security Incident Response Capability
    • 2.1 Events and Incidents
    • 2.2 Need for Incident Response
    • 2.3 Incident Response Policy, Plan, and Procedure Creation
      • 2.3.1 Policy Elements.............................................................................................
      • 2.3.2 Plan Elements
      • 2.3.3 Procedure Elements......................................................................................
      • 2.3.4 Sharing Information With Outside Parties
    • 2.4 Incident Response Team Structure
      • 2.4.1 Team Models ...............................................................................................
      • 2.4.2 Team Model Selection..................................................................................
      • 2.4.3 Incident Response Personnel.......................................................................
      • 2.4.4 Dependencies within Organizations .............................................................
    • 2.5 Incident Response Team Services
    • 2.6 Recommendations
    1. Handling an Incident .......................................................................................................
    • 3.1 Preparation..............................................................................................................
      • 3.1.1 Preparing to Handle Incidents ......................................................................
      • 3.1.2 Preventing Incidents.....................................................................................
    • 3.2 Detection and Analysis
      • 3.2.1 Attack Vectors ..............................................................................................
      • 3.2.2 Signs of an Incident ......................................................................................
      • 3.2.3 Sources of Precursors and Indicators...........................................................
      • 3.2.4 Incident Analysis ..........................................................................................
      • 3.2.5 Incident Documentation................................................................................
      • 3.2.6 Incident Prioritization ....................................................................................
      • 3.2.7 Incident Notification ......................................................................................
    • 3.3 Containment, Eradication, and Recovery.................................................................
      • 3.3.1 Choosing a Containment Strategy ................................................................
      • 3.3.2 Evidence Gathering and Handling ................................................................
      • 3.3.3 Identifying the Attacking Hosts .....................................................................
      • 3.3.4 Eradication and Recovery ............................................................................
    • 3.4 Post-Incident Activity
      • 3.4.1 Lessons Learned..........................................................................................
      • 3.4.2 Using Collected Incident Data ......................................................................
      • 3.4.3 Evidence Retention ......................................................................................
    • 3.5 Incident Handling Checklist
    • 3.6 Recommendations
    1. Coordination and Information Sharing ..........................................................................
    • 4.1 Coordination vii
      • 4.1.1 Coordination Relationships ..........................................................................
      • 4.1.2 Sharing Agreements and Reporting Requirements ......................................
    • 4.2 Information Sharing Techniques
      • 4.2.1 Ad Hoc .........................................................................................................
      • 4.2.2 Partially Automated ......................................................................................
      • 4.2.3 Security Considerations ...............................................................................
    • 4.3 Granular Information Sharing
      • 4.3.1 Business Impact Information ........................................................................
      • 4.3.2 Technical Information ...................................................................................
    • 4.4 Recommendations
  • Appendix A— Incident Handling Scenarios .......................................................................... List of Appendices
    • A.1 Scenario Questions
    • A.2 Scenarios
  • Appendix B— Incident-Related Data Elements .....................................................................
    • B.1 Basic Data Elements
    • B.2 Incident Handler Data Elements
  • Appendix C— Glossary ..........................................................................................................
  • Appendix D— Acronyms ........................................................................................................
  • Appendix E— Resources........................................................................................................
  • Appendix F— Frequently Asked Questions ..........................................................................
  • Appendix G— Crisis Handling Steps .....................................................................................
  • Appendix H— Change Log .....................................................................................................
  • Figure 2-1. Communications with Outside Parties ..................................................................... List of Figures
  • Figure 3-1. Incident Response Life Cycle ..................................................................................
  • Figure 3-2. Incident Response Life Cycle (Detection and Analysis)...........................................
  • Figure 3-3. Incident Response Life Cycle (Containment, Eradication, and Recovery) ...............
  • Figure 3-4. Incident Response Life Cycle (Post-Incident Activity) ..............................................
  • Figure 4-1. Incident Response Coordination .............................................................................

Executive Summary

Computer security incident response has become an important component of information technology (IT) programs. Cybersecurity-related attacks have become not only more numerous and diverse but also more damaging and disruptive. New types of security-related incidents emerge frequently. Preventive activities based on the results of risk assessments can lower the number of incidents, but not all incidents can be prevented. An incident response capability is therefore necessary for rapidly detecting incidents, minimizing loss and destruction, mitigating the weaknesses that were exploited, and restoring IT services. To that end, this publication provides guidelines for incident handling, particularly for analyzing incident- related data and determining the appropriate response to each incident. The guidelines can be followed independently of particular hardware platforms, operating systems, protocols, or applications.

Because performing incident response effectively is a complex undertaking, establishing a successful incident response capability requires substantial planning and resources. Continually monitoring for attacks is essential. Establishing clear procedures for prioritizing the handling of incidents is critical, as is implementing effective methods of collecting, analyzing, and reporting data. It is also vital to build relationships and establish suitable means of communication with other internal groups (e.g., human resources, legal) and with external groups (e.g., other incident response teams, law enforcement).

This publication assists organizations in establishing computer security incident response capabilities and handling incidents efficiently and effectively. This revision of the publication, Revision 2, updates material throughout the publication to reflect the changes in attacks and incidents. Understanding threats and identifying modern attacks in their early stages is key to preventing subsequent compromises, and proactively sharing information among organizations regarding the signs of these attacks is an increasingly effective way to identify them.

Implementing the following requirements and recommendations should facilitate efficient and effective incident response for Federal departments and agencies.

Organizations must create, provision, and operate a formal incident response capability. Federal law requires Federal agencies to report incidents to the United States Computer Emergency Readiness Team (US-CERT) office within the Department of Homeland Security (DHS).

The Federal Information Security Management Act (FISMA) requires Federal agencies to establish incident response capabilities. Each Federal civilian agency must designate a primary and secondary point of contact (POC) with US-CERT and report all incidents consistent with the agency’s incident response policy. Each agency is responsible for determining how to fulfill these requirements.

Establishing an incident response capability should include the following actions:

 Creating an incident response policy and plan

 Developing procedures for performing incident handling and reporting

 Setting guidelines for communicating with outside parties regarding incidents

 Selecting a team structure and staffing model

 Establishing relationships and lines of communication between the incident response team and other groups, both internal (e.g., legal department) and external (e.g., law enforcement agencies)

 Determining what services the incident response team should provide

 Staffing and training the incident response team.

Organizations should reduce the frequency of incidents by effectively securing networks, systems, and applications.

Preventing problems is often less costly and more effective than reacting to them after they occur. Thus, incident prevention is an important complement to an incident response capability. If security controls are insufficient, high volumes of incidents may occur. This could overwhelm the resources and capacity for response, which would result in delayed or incomplete recovery and possibly more extensive damage and longer periods of service and data unavailability. Incident handling can be performed more effectively if organizations complement their incident response capability with adequate resources to actively maintain the security of networks, systems, and applications. This includes training IT staff on complying with the organization’s security standards and making users aware of policies and procedures regarding appropriate use of networks, systems, and applications.

Organizations should document their guidelines for interactions with other organizations regarding incidents.

During incident handling, the organization will need to communicate with outside parties, such as other incident response teams, law enforcement, the media, vendors, and victim organizations. Because these communications often need to occur quickly, organizations should predetermine communication guidelines so that only the appropriate information is shared with the right parties.

Organizations should be generally prepared to handle any incident but should focus on being prepared to handle incidents that use common attack vectors.

Incidents can occur in countless ways, so it is infeasible to develop step-by-step instructions for handling every incident. This publication defines several types of incidents, based on common attack vectors; these categories are not intended to provide definitive classification for incidents, but rather to be used as a basis for defining more specific handling procedures. Different types of incidents merit different response strategies. The attack vectors are:

External/Removable Media: An attack executed from removable media (e.g., flash drive, CD) or a peripheral device.

Attrition: An attack that employs brute force methods to compromise, degrade, or destroy systems, networks, or services.

Web: An attack executed from a website or web-based application.

Email: An attack executed via an email message or attachment.

Improper Usage: Any incident resulting from violation of an organization’s acceptable usage policies by an authorized user, excluding the above categories.

Loss or Theft of Equipment: The loss or theft of a computing device or media used by the organization, such as a laptop or smartphone.

Other: An attack that does not fit into any of the other categories.

1. Introduction

1.1 Authority

The National Institute of Standards and Technology (NIST) developed this document in furtherance of its statutory responsibilities under the Federal Information Security Management Act (FISMA) of 2002, Public Law 107-347.

NIST is responsible for developing standards and guidelines, including minimum requirements, for providing adequate information security for all agency operations and assets, but such standards and guidelines shall not apply to national security systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), “Securing Agency Information Systems,” as analyzed in A-130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in A-130, Appendix III.

This guideline has been prepared for use by Federal agencies. It may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright, though attribution is desired.

Nothing in this document should be taken to contradict standards and guidelines made mandatory and binding on Federal agencies by the Secretary of Commerce under statutory authority, nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other Federal official.

1.2 Purpose and Scope

This publication seeks to assist organizations in mitigating the risks from computer security incidents by providing practical guidelines on responding to incidents effectively and efficiently. It includes guidelines on establishing an effective incident response program, but the primary focus of the document is detecting, analyzing, prioritizing, and handling incidents. Organizations are encouraged to tailor the recommended guidelines and solutions to meet their specific security and mission requirements.

1.3 Audience

This document has been created for computer security incident response teams (CSIRTs), system and network administrators, security staff, technical support staff, chief information security officers (CISOs), chief information officers (CIOs), computer security program managers, and others who are responsible for preparing for, or responding to, security incidents.

1.4 Document Structure

The remainder of this document is organized into the following sections and appendices:

 Section 2 discusses the need for incident response, outlines possible incident response team structures, and highlights other groups within an organization that may participate in incident handling.

 Section 3 reviews the basic incident handling steps and provides advice for performing incident handling more effectively, particularly incident detection and analysis.

 Section 4 examines the need for incident response coordination and information sharing.

 Appendix A contains incident response scenarios and questions for use in incident response tabletop discussions.

 Appendix B provides lists of suggested data fields to collect for each incident.

 Appendices C and D contain a glossary and acronym list, respectively.

 Appendix E identifies resources that may be useful in planning and performing incident response.

 Appendix F covers frequently asked questions about incident response.

 Appendix G lists the major steps to follow when handling a computer security incident-related crisis.

 Appendix H contains a change log listing significant changes since the previous revision.

future incidents and to provide stronger protection for systems and data. An incident response capability also helps with dealing properly with legal issues that may arise during incidents.

Besides the business reasons to establish an incident response capability, Federal departments and agencies must comply with law, regulations, and policy directing a coordinated, effective defense against information security threats. Chief among these are the following:

 OMB’s Circular No. A-130, Appendix III,^3 released in 2000, which directs Federal agencies to “ensure that there is a capability to provide help to users when a security incident occurs in the system and to share information concerning common vulnerabilities and threats. This capability shall share information with other organizations … and should assist the agency in pursuing appropriate legal action, consistent with Department of Justice guidance.”

 FISMA (from 2002),^4 which requires agencies to have “procedures for detecting, reporting, and responding to security incidents” and establishes a centralized Federal information security incident center, in part to:

  • “Provide timely technical assistance to operators of agency information systems … including guidance on detecting and handling information security incidents …
  • Compile and analyze information about incidents that threaten information security …
  • Inform operators of agency information systems about current and potential information security threats, and vulnerabilities … .”

 Federal Information Processing Standards (FIPS) 200, Minimum Security Requirements for Federal Information and Information Systems^5 , March 2006, which specifies minimum security requirements for Federal information and information systems, including incident response. The specific requirements are defined in NIST Special Publication (SP) 800-53, Recommended Security Controls for Federal Information Systems and Organizations.

 OMB Memorandum M-07-16, Safeguarding Against and Responding to the Breach of Personally Identifiable Information^6 , May 2007, which provides guidance on reporting security incidents that involve PII.

2.3 Incident Response Policy, Plan, and Procedure Creation

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

2.3.1 Policy Elements

Policy governing incident response is highly individualized to the organization. However, most policies include the same key elements:

 Statement of management commitment

 Purpose and objectives of the policy

(^3) http://www.whitehouse.gov/omb/circulars/a130/a130trans4.html (^4) http://csrc.nist.gov/drivers/documents/FISMA-final.pdf (^5) http://csrc.nist.gov/publications/PubsFIPS.html (^6) http://www.whitehouse.gov/omb/memoranda/fy2007/m07-16.pdf

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

 Definition of computer security incidents and related terms

 Organizational structure and definition of roles, responsibilities, and levels of authority; should include the authority of the incident response team to confiscate or disconnect equipment and to monitor suspicious activity, the requirements for reporting certain types of incidents, the requirements and guidelines for external communications and information sharing (e.g., what can be shared with whom, when, and over what channels), and the handoff and escalation points in the incident management process

 Prioritization or severity ratings of incidents

 Performance measures (as discussed in Section 3.4.2)

 Reporting and contact forms.

2.3.2 Plan Elements

Organizations should have a formal, focused, and coordinated approach to responding to incidents, including an incident response plan that provides the roadmap for implementing the incident response capability. Each organization needs a plan that meets its unique requirements, which relates to the organization’s mission, size, structure, and functions. The plan should lay out the necessary resources and management support. The incident response plan should include the following elements:

 Mission

 Strategies and goals

 Senior management approval

 Organizational approach to incident response

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

 Metrics for measuring the incident response capability and its effectiveness

 Roadmap for maturing the incident response capability

 How the program fits into the overall organization.

The organization’s mission, strategies, and goals for incident response should help in determining the structure of its incident response capability. The incident response program structure should also be discussed within the plan. Section 2.4.1 discusses the types of structures.

Once an organization develops a plan and gains management approval, the organization should implement the plan and review it at least annually to ensure the organization is following the roadmap for maturing the capability and fulfilling their goals for incident response.

2.3.3 Procedure Elements

Procedures should be based on the incident response policy and plan. Standard operating procedures (SOPs) are a delineation of the specific technical processes, techniques, checklists, and forms used by the incident response team. SOPs should be reasonably comprehensive and detailed to ensure that the

Figure 2-1. Communications with Outside Parties

2.3.4.1 The Media

The incident handling team should establish media communications procedures that comply with the organization’s policies on media interaction and information disclosure.^7 For discussing incidents with the media, organizations often find it beneficial to designate a single point of contact (POC) and at least one backup contact. The following actions are recommended for preparing these designated contacts and should also be considered for preparing others who may be communicating with the media:

 Conduct training sessions on interacting with the media regarding incidents, which should include the importance of not revealing sensitive information, such as technical details of countermeasures that could assist other attackers, and the positive aspects of communicating important information to the public fully and effectively.

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

(^7) For example, an organization may want members of its public affairs office and legal department to participate in all incident discussions with the media.

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

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

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

  • Who attacked you? Why?
  • When did it happen? How did it happen? Did this happen because you have poor security practices?
  • How widespread is this incident? What steps are you taking to determine what happened and to prevent future occurrences?
  • What is the impact of this incident? Was any personally identifiable information (PII) exposed? What is the estimated cost of this incident?

2.3.4.2 Law Enforcement

One reason that many security-related incidents do not result in convictions is that some organizations do not properly contact law enforcement. Several levels of law enforcement are available to investigate incidents: for example, within the United States, Federal investigatory agencies (e.g., the Federal Bureau of Investigation [FBI] and the U.S. Secret Service), district attorney offices, state law enforcement, and local (e.g., county) law enforcement. Law enforcement agencies in other countries may also be involved, such as for attacks launched from or directed at locations outside the US. In addition, agencies have an Office of Inspector General (OIG) for investigation of violation of the law within each agency. The incident response team should become acquainted with its various law enforcement representatives before an incident occurs to discuss conditions under which incidents should be reported to them, how the reporting should be performed, what evidence should be collected, and how it should be collected.

Law enforcement should be contacted through designated individuals in a manner consistent with the requirements of the law and the organization’s procedures. Many organizations prefer to appoint one incident response team member as the primary POC with law enforcement. This person should be familiar with the reporting procedures for all relevant law enforcement agencies and well prepared to recommend which agency, if any, should be contacted. Note that the organization typically should not contact multiple agencies because doing so might result in jurisdictional conflicts. The incident response team should understand what the potential jurisdictional issues are (e.g., physical location—an organization based in one state has a server located in a second state attacked from a system in a third state, being used remotely by an attacker in a fourth state).

2.3.4.3 Incident Reporting Organizations

FISMA requires Federal agencies to report incidents to the United States Computer Emergency Readiness Team (US-CERT),^8 which is a governmentwide incident response organization that assists Federal civilian agencies in their incident handling efforts. US-CERT does not replace existing agency response teams; rather, it augments the efforts of Federal civilian agencies by serving as a focal point for dealing with incidents. US-CERT analyzes the agency-provided information to identify trends and indicators of attacks; these are easier to discern when reviewing data from many organizations than when reviewing the data of a single organization.

(^8) http://www.us-cert.gov/