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, an 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 describes the major phases of the incident response process—preparation, detection and analysis, containment, eradication and recovery, and post-incident activity—in detail.
Preparation. Incident response methodologies typically emphasize preparation—not only establishing an incident response capability so that the organization is ready to respond to incidents, but also preventing incidents by ensuring that systems, networks, and applications are sufficiently secure. Although the incident response team is not typically responsible for incident prevention, it is fundamental to the success of incident response programs. This section provides basic advice on preparing to handle incidents and on preventing incidents.
Preparing to Handle Incidents. The lists below provide examples of tools and resources available that may be of value during incident handling. These lists are intended to be a starting point for discussions about which tools and resources an organization’s incident handlers need. For example, smartphones are one way to have resilient emergency communication and coordination mechanisms. An organization should have multiple (separate and different) communication and coordination mechanisms in case of failure of one mechanism.
INCIDENT HANDLER COMMUNICATIONS AND FACILITIES
- Contact information for team members and others within and outside the organization (primary and backup contacts), such as law enforcement and other incident response teams; information may include phone numbers, email addresses, public encryption keys (in accordance with the encryption software described below), and instructions for verifying the contact’s identity.
- On-call information for other teams within the organization, including escalation information.
- Incident reporting mechanisms, such as phone numbers, email addresses, online forms, and secure instant messaging systems that users can use to report suspected incidents; at least one mechanism should permit people to report incidents anonymously Issue tracking system for tracking incident information, status, etc.
- Smartphones to be carried by team members for off-hour support and onsite communications
- Encryption software to be used for communications among team members, within the organization, and with external parties; for Federal agencies, software must use a FIPS-validated encryption algorithm.
- Cyber-War room for central communication and coordination; if a permanent war room is not necessary or practical, the team should create a procedure for procuring a temporary war room when needed.
- Secure storage facility for securing evidence and other sensitive materials.
INCIDENT ANALYSIS HARDWARE AND SOFTWARE
- Digital forensic workstations and/or backup devices to create disk images, preserve log files, and save other relevant incident data.
- Laptops for activities such as analyzing data, sniffing packets, and writing reports.
- Spare workstations, servers, and networking equipment, or the virtualized equivalents, which may be used for many purposes, such as restoring backups and trying out malware.
- Blank removable media.
- Portable printer to print copies of log files and other evidence from non-networked systems.
- Packet sniffers and protocol analyzers to capture and analyze network traffic.
- Digital forensic software to analyze disk images.
- Removable media with trusted versions of programs to be used to gather evidence from systems.
- Evidence gathering accessories, including hard-bound notebooks, digital cameras, audio recorders, chain of custody forms, evidence storage bags and tags, and evidence tape, to preserve evidence for possible legal actions.
INCIDENT ANALYSIS RESOURCES
- Port lists, including commonly used ports and Trojan horse ports.
- Documentation for OSs, applications, protocols, intrusion detection, and antivirus products.
- Network diagrams and lists of critical assets, such as database servers.
- Current baselines of an expected network, system, and application activity.
- Cryptographic hashes of critical files to speed incident analysis, verification, and eradication
INCIDENT MITIGATION SOFTWARE
- Access to images of clean OS and application installations for restoration and recovery purposes
- Many incident response teams create a jump kit, which is a portable case that contains materials that may be needed during an investigation. The jump kit should be ready to go at all times. Jump kits contain many of the same items listed in the bulleted lists above. For example, each jump kit typically includes a laptop, loaded with appropriate software (e.g., packet sniffers, digital forensics). Other important materials include backup devices, blank media, and basic networking equipment and cables. Because the purpose of having a jump kit is to facilitate faster responses, the team should avoid borrowing items from the jump kit.
- Each incident handler should have access to at least two computing devices (e.g., laptops). One, such as the one from the jump kit, should be used to perform packet sniffing, malware analysis, and all other actions that risk contaminating the laptop that performs them. This laptop should be scrubbed and all software reinstalled before it is used for another incident. Note that because this laptop is for a special purpose, it is likely to use software other than the standard enterprise tools and configurations, and whenever possible the incident handlers should be allowed to specify basic technical requirements for these special-purpose investigative laptops. In addition to an investigative laptop, each incident handler should also have a standard laptop, smartphone, or another computing device for writing reports, reading emails, and performing other duties unrelated to the hands-on incident analysis.