Computer incidents happen. They just do. Regardless of the expansive and proactive nature of a particular team, the Computer Network Defense (CND) job will include Incident Response.
Why? Because in part, CND is reactive. A properly running CND team will include a subgroup of Attack and Exploitation members who will actively look for vulnerabilities in your network, but 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.
A brief history
In the beginning was ARPA. And the Internet was with ARPA. And the Internet was ARPA. The Advanced Research Projects Agency (ARPA, later known as DARPA) network was the precursor of what we now know as the Internet.
In 1988, Robert Morris made international history… by mistake. A young Cornell student at the time, Morris crafted what became known as the Morris Worm. The worm was intended to gauge the size of the then current internet through a sequence of weak passwords and services available on most networked devices at the time. But Morris poorly coded his worm. The mistake was that the worm would reinfect the host computer as well as spread to other computers, thereby overwhelming the host computer with processes. 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 halt.
At the time, DARPA and the Defense Department were positioning the have a guaranteed delivery, always available information network. The Morris Worm helped them realize the vulnerability of the net, and their 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 created to be a coordination center for computer network operations defenders in the US and around the world.
The NIST Incident Guide
NIST’s Computer Security Incident Handling Guide 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, and 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, 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.
Reviewing the NIST guide
The NIST Computer Security Incident Handling Guide is very well thought out and presented. The following sections take abstracted direct quotes from the NIST guide.
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.
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.
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.
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.
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.
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.”
- ARPANET, http://en.wikipedia.org/wiki/ARPANET
- History of the Internet, http://en.wikipedia.org/wiki/History_of_the_Internet#Three_terminals_and_an_ARPA
- Morris Worm, http://en.wikipedia.org/wiki/Morris_worm
- CERT is a Registered Trademark of CMU, http://www.cert.org/incident-management/csirt-development/csirt-faq.cfm?
- CERT/CC, http://en.wikipedia.org/wiki/CERT_Coordination_Center
- CMU, http://en.wikipedia.org/wiki/Carnegie_Mellon_University
- ARPA/DARPA, http://en.wikipedia.org/wiki/DARPA
- Computer Worm, http://en.wikipedia.org/wiki/Computer_worm
- SEI, http://en.wikipedia.org/wiki/Software_Engineering_Institute