Incidents are events that disrupt the availability of systems, threaten the integrity or confidentiality of data, or violate or threaten to violate appropriate use standards of information systems. Incident response is the method with which an organization controls a security breach or an attack. Computer forensics might be part of an incident response when legal proceedings may ensue.
Like natural disasters, many of us do not expect security incidents to happen to us; the result is that when security incidents occur, the response is formulated on the fly. Planning is required to respond to incidents in a controlled and effective manner. The basic steps in incident response are:
- Detection and analysis
- Containment, eradication, and recovery
- Post-incident analysis
The objectives of these steps is to isolate the impact of a security incident as quickly as possible to limit damage, determine the exact nature of the incident and stop it, restore systems to operational state, and learn from the event.
Planning for Incidents
By planning for security incidents, you can employ policies and procedures that are already in place when they are needed. Employees will know what to do when an attack is suspected. Incident response plans should include:
- Definitions and examples of incidents so that employees can readily identify security events
- Roles and responsibilities for responding to incidents as well as established reporting structures
- Initial responses to be carried out in the event of particular types of incidents—for example, a notebook that has been infected with a virus should be immediately disconnected from the network
- Severity rankings of incidents and escalation procedures for responding—for example, a single client device infected with a virus should be reported to a service desk line manager; when multiple servers are infected with a virus, higher-level IT managers are notified.
Plans should describe the roles of non-technical staff as well, especially legal, media relations, and executive management in cases of significant breaches that violate regulations or require notification of third parties.
Detection and Analysis
The goal of the detection and analysis phase is to determine the type of attack under way so that it can be stopped. There are many types of attacks, but the general categories were described earlier. Training an incident response team in each type of attack enables the team to be able to assess the nature of an attack.
Indications of an attack are not always as obvious as an antivirus program issuing an alert that it has detected a worm on a server. Relatively unusual events, such as a Web server crash, can indicate an attack; however the same event could indicate a flaw in software that should be patched. IPSs commonly generate false alarms, so even security device warnings must be investigated to determine the cause of the alarm. Multiple indicators, such as a Web server crashing, unusual network traffic patterns, and a slow down in server response times, are evidence of a possible attack.
When indicators are present, analysis is done to determine whether there is a security incident or some other cause of the problem. Analysis is done by checking for variations from normal operating patterns, changes in file system integrity monitors, and events logged to multiple countermeasures or systems that may be correlated. If a network attack, such as a DoS attack, is under way, packet sniffers can be used to gather additional data.
Containment, Eradication, and Recovery
Once an incident has been confirmed, the next step is to contain the impact. What exactly should be done will vary, but options include:
- Shutting down affected devices
- Disconnecting devices from the network
- Stopping services
- Closing ports on firewalls
- Allowing an attack to continue but recording all network traffic for analysis or evidence
The appropriate response depends on several factors such as whether you intend to legally prosecute the attacker, the impact on service delivery, the time and resources required to implement and then recover from the action, and the length of time the action will have be continued. Eradiation requires eliminating the attack. In the case of malware, eradication requires removing the malicious code from infected machines. A DoS attack is eradicated when the flood of spurious traffic stops, such as by contacting an ISP to block traffic from the attacking source. After the incident has ceased, the next step is to recover services. This may be relatively simple, in the case of DoS attacks, or more complex in the case of a malware attack that damages data and leaves malicious programs such as keyloggers.
Post-incident analysis is an opportunity to learn from a security incident. Questions will naturally arise about why the incident occurred. Were countermeasures in place and properly configured? Were OSs and applications properly patched? Was a vulnerability missed during a vulnerability scan? It might also be the case that the organization was the victim of a zero-day attack (an attack that exploits a previously unknown vulnerability and for which no patch exists) or that the threat was anticipated by risk analysis and it was determined that the cost of remediation was too high or the likelihood too low to warrant additional countermeasures. Incident response is the one element of the information protection life cycle you would rather not have to address but should be ready for nonetheless.
This was first published in January 2007