Computer Security Incident Response (NIST SP800-61r2)

Computer security incidents happen.  Why?  Because computer defense is reactive. Regardless of the expansive and proactive nature of any particular defensive team, the Computer Network Defense (CND) job must include Computer Security Incident Response.

A properly running CND team includes a Red Team subgroup of Attack and Exploitation experts. The Red Team actively looks for vulnerabilities in your network. However, that subgroup is dwarfed by the number of active attackers in the world.

So what should a CND team do?  The team should prepare for incident handling and response.  As it turns out, when it comes to incident handling and response, prior planning provides utmost performance.

1. History of the Internet

In the beginning was ARPA. And the Internet was with ARPA.  And the Internet was ARPA.  

History of the Internet

The Advanced Research Projects Agency (ARPA, later known as DARPA) network was established in 1969. ARPANET was developed with guaranteed delivery, high availability, multi connection, and multi path in mind. ARPANET was the precursor of what we now know as the Internet.

Internet expansion to universities

In the early and mid 1980s, NSF (the National Science Foundation) established a network of supercomputers at colleges and universities around the United States. NSFNET brought DARPANET to a more general and wide reaching audience, expanding the usefulness of the connected network to sharing tens of thousands of very high cost computer assets.

Robert Morris worm

In 1988, a young Cornell student named Robert Morris created an application intended to search the interconnected network for all computer assets, and report back what it could find out about each of the end nodes. The intent was to gauge the size of the “internet” by replicating the application to each of a particular computer’s peers using a sequence of weak passwords and services available universally known at the time. The application then called back to a central server to identify “node alive” status.

Unfortunately, Morris poorly crafted his application. Instead of replicating on peers forward, the application replicated on every peer of every site repeatedly. That is, if two peers were available to a particular node, each of those nodes would be infected by the originating source. What happened instead was that the targets infected their peers, and also reinfected the source node. Eventually every interconnected node reinfected to full saturation and was no longer able to respond resulting in a Denial of Service.

Even worse, when a network engineer or systems administrator rebooted the machine to regain access, the nearby computers would quickly reinfect the machine.  Recovery was not a simple task, and the Internet came to a screaming halt.

Morris made international history by this simple coding mistake. The infectious application became known as the Morris Worm.

Computer Emergency Response Team

At the time, DARPA and the Defense Department were positioning the Internet to provide a guaranteed delivery, always available information network.  The Morris Worm realize the vulnerability of the Internet, and DARPA’s response was to create the Computer Emergency Response Team (now known as CERT[tm]) hosted under the Software Engineering Institute (SEI) at Carnegie Mellon University.  The charter for CERT was to be a coordination center for computer network operations defenders in the United States and around the world.

2. NIST incident handling guide

NIST’s Computer Security Incident Handling Guide (NIST Special Publication 800-61r2) is an excellent source of how to organize and design a Computer Security Incident Response Capability.  Realize, it will take some time to digest the entire document.  You’ll have to forget some ideas you’ve likely held on to, and learn new techniques that have been proven in the art of incident response.

But why would you want to rewicker your incident handling policies, plans, and procedures?  This is a costly endeavor, no?  Well, yes, it is.  But it is going to help your organization prepare for incident response, will help in the process of incident response and recovery, and may even help in preventing an incident in the first place.

If your management is resistant to reviewing the policies, plans, and procedures in place, you might want to help them reconsider their position.  If you happen to work in an industry or at a company who is responsible to external validation, or maintaining information that requires response to incidents (read this: just about everyone, including those who handle SOX, PHI, PII, PCI, and nearly any other data), you might want to make sure your policies, plans, and procedures follow NIST or some other industry accepted guidance platform, even if not strictly required.  When you are breached (and it is a when, not an if), your adherence to NIST or other standard is likely to go a very long way in reducing your fines.

3. Reviewing the NIST guide

The NIST Computer Security Incident Handling Guide SP800-61r2 is a comprehensive industry accepted incident handling guide.  The following sections take abstracted quotes from the NIST guide.

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 incidentrelated data and determining the appropriate response to each incident. The guidelines can be followed independently of particular hardware platforms, operating systems, protocols, or applications.

Establishing an incident response capability should include the following actions:

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

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

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

• Organizations should be generally prepared to handle any incident but should focus on being prepared to handle incidents that use common attack vectors
  • 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.

• Organizations should emphasize the importance of incident detection and analysis throughout the organization

• Organizations should create written guidelines for prioritizing incidents

• Organizations should use the lessons learned process to gain value from incidents

Chapter 1: Introduction

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

1.2 Purpose and Scope

1.3 Audience

1.4 Document Structure

Chapter 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

2.2 Need for Incident Response

2.3 Incident Response Policy, Plan, and Procedure Creation

2.4 Incident Response Team Structure

2.5 Incident Response Team Services

2.6 Recommendations

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

3.1 Preparation

3.2 Detection and Analysis

3.3 Containment, Eradication, and Recovery

3.4 Post-Incident Activity

3.5 Incident Handling Checklist

Chapter 4: Coordination and Information Sharing

The nature of contemporary threats and attacks makes it more important than ever for organizations to work together during incident response. Organizations should ensure that they effectively coordinate portions of their incident response activities with appropriate partners. The most important aspect of incident response coordination is information sharing, where different organizations share threat, attack, and vulnerability information with each other so that each organization’s knowledge benefits the other. Incident information sharing is frequently mutually beneficial because the same threats and attacks often affect multiple organizations simultaneously.

As mentioned in Section 2, coordinating and sharing information with partner organizations can strengthen the organization’s ability to effectively respond to IT incidents. For example, if an organization identifies some behavior on its network that seems suspicious and sends information about the event to a set of trusted partners, someone else in that network may have already seen similar behavior and be able to respond with additional details about the suspicious activity, including signatures, other indicators to look for, or suggested remediation actions. Collaboration with the trusted partner can enable an organization to respond to the incident more quickly and efficiently than an organization operating in isolation.

This increase in efficiency for standard incident response techniques is not the only incentive for crossorganization coordination and information sharing. Another incentive for information sharing is the ability to respond to incidents using techniques that may not be available to a single organization, especially if that organization is small to medium size. For example, a small organization that identifies a particularly complex instance of malware on its network may not have the in-house resources to fully analyze the malware and determine its effect on the system. In this case, the organization may be able to leverage a trusted information sharing network to effectively outsource the analysis of this malware to third party resources that have the adequate technical capabilities to perform the malware analysis.

This section of the document highlights coordination and information sharing. Section 4.1 presents an overview of incident response coordination and focuses on the need for cross-organization coordination to supplement organization incident response processes. Section 4.2 discusses techniques for information sharing across organizations, and Section 4.3 examines how to restrict what information is shared or not shared with other organizations.

4.1 Coordination

4.2 Information Sharing Techniques

4.3 Granular Information Sharing

4.4 Recommendations

Appendix A: Incident Handling Scenarios

Incident handling scenarios provide an inexpensive and effective way to build incident response skills and identify potential issues with incident response processes. The incident response team or team members are presented with a scenario and a list of related questions. The team then discusses each question and determines the most likely answer. The goal is to determine what the team would really do and to compare that with policies, procedures, and generally recommended practices to identify discrepancies or deficiencies. For example, the answer to one question may indicate that the response would be delayed because the team lacks a piece of software or because another team does not provide off-hours support.

The questions listed below are applicable to almost any scenario. Each question is followed by a reference to the related section(s) of the document. After the questions are scenarios, each of which is followed by additional incident-specific questions. Organizations are strongly encouraged to adapt these questions and scenarios for use in their own incident response exercises.  

A.1 Scenario Questions

A.2 Scenarios

Appendix B: Incident-Related Data Elements

Organizations should identify a standard set of incident-related data elements to be collected for each incident. This effort will not only facilitate more effective and consistent incident handling, but also assist the organization in meeting applicable incident reporting requirements. The organization should designate a set of basic elements (e.g., incident reporter’s name, phone number, and location) to be collected when the incident is reported and an additional set of elements to be collected by the incident handlers during their response. The two sets of elements would be the basis for the incident reporting database, previously discussed in Section 3.2.5. The lists below provide suggestions of what information to collect for incidents and are not intended to be comprehensive. Each organization should create its own list of elements based on several factors, including its incident response team model and structure and its definition of the term “incident.”

B.1 Basic Data Elements

B.2 Incident Handler Data Elements

Appendix G: Crisis Handling Steps

This is a list of the major steps that should be performed when a technical professional believes that a serious incident has occurred and the organization does not have an incident response capability available. This serves as a basic reference of what to do for someone who is faced with a crisis and does not have time to read through this entire document.

1. Document everything. This effort includes every action that is performed, every piece of evidence, and every conversation with users, system owners, and others regarding the incident.

2. Find a coworker who can provide assistance. Handling the incident will be much easier if two or more people work together. For example, one person can perform actions while the other documents them.

3. Analyze the evidence to confirm that an incident has occurred. Perform additional research as necessary (e.g., Internet search engines, software documentation) to better understand the evidence. Reach out to other technical professionals within the organization for additional help.

4. Notify the appropriate people within the organization. This should include the chief information officer (CIO), the head of information security, and the local security manager. Use discretion when discussing details of an incident with others; tell only the people who need to know and use communication mechanisms that are reasonably secure. (If the attacker has compromised email services, do not send emails about the incident.)

5. Notify US-CERT and/or other external organizations for assistance in dealing with the incident.

6. Stop the incident if it is still in progress. The most common way to do this is to disconnect affected systems from the network. In some cases, firewall and router configurations may need to be modified to stop network traffic that is part of an incident, such as a denial of service (DoS) attack.

7. Preserve evidence from the incident. Make backups (preferably disk image backups, not file system backups) of affected systems. Make copies of log files that contain evidence related to the incident.

8. Wipe out all effects of the incident. This effort includes malware infections, inappropriate materials (e.g., pirated software), Trojan horse files, and any other changes made to systems by incidents. If a system has been fully compromised, rebuild it from scratch or restore it from a known good backup.

9. Identify and mitigate all vulnerabilities that were exploited. The incident may have occurred by taking advantage of vulnerabilities in operating systems or applications. It is critical to identify such vulnerabilities and eliminate or otherwise mitigate them so that the incident does not recur.

10. Confirm that operations have been restored to normal. Make sure that data, applications, and other services affected by the incident have been returned to normal operations.

11. Create a final report. This report should detail the incident handling process. It also should provide an executive summary of what happened and how a formal incident response capability would have helped to handle the situation, mitigate the risk, and limit the damage more quickly

4. Reference material

1. NIST Special Publication 800-61 Revision 2 Computer Security Incident Handling Guide,
   https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf
2. ARPANET,
   https://www.britannica.com/topic/ARPANET
3. History of the Internet, http://en.wikipedia.org/wiki/History_of_the_Internet#Three_terminals_and_an_ARPA
4. Morris Worm,
   https://www.zdnet.com/article/the-day-computer-security-turned-real-the-morris-worm-turns-30/
5. CERT/CC at CMU,
   https://www.sei.cmu.edu/about/divisions/cert/
6. ARPA/DARPA, http://en.wikipedia.org/wiki/DARPA
7. Computer Worm, http://en.wikipedia.org/wiki/Computer_worm
8. SEI, http://en.wikipedia.org/wiki/Software_Engineering_Institute