BreachBytes

Incident response (IR) is a critical responsibility for network security analysts and system administrators. Anyone operating a network should have an incident response plan in place so that when a network breach occurs everyone involved knows their roles and responsibilities. If a plan is not in place (or nearly as bad, the employees have not been trained to execute the plan) a simple incident can quickly be blown out of proportion and cause damage to the reputation of the organization and its employees.

To most people, IR means a call to action when a new threat emerges or the network is breached (broken in to). Most people think of IR solely in this capacity but responding to an event or incident is too complex to lump into a single category. This article extends the IR concept by breaking the traditional “response” component into three separate areas:

1. Response: the initial set of actions taken by system administrators and security analysts to asses the situation and stop the incident from spreading.
2. Recovery: this step involves getting effected machines back online and returning to regular operations.
3. (Public) Relations: even after the incident is contained and corrected, there may be PR fallout from the incident. This step is overlooked almost universally.

This new model for thinking of incident response, IR3, is meant to give notice to the often-neglected tasks of incident response. IR3 recognizes that simply responding to an incident is not enough. The security team needs to assist in returning the effected hosts to normal operations and provide technical information to the public relations staff so that any mention of the incident in the press is technically correct.

Consider a scenario where hackers have infected a critical database server with a trojan. After identifying the infected server and taking it offline for a postmortem (the response phase), the incident response team needs to work with the system administrator of the server to get it back online, patched and cleaned of any malicious code (the recovery phase). Only then can the server be returned to operational status. The incident response team must be involved in getting the server online because it is unlikely that a system administrator has the technical skills needed to execute all the tasks required in a recovery operation.

Public relations will likely come into play in such a scenario as well. If not handled well, as is usually the case, the compromise of a critical server with customer or employee information can lead to negative press and loss of trust in the brand. The incident response team can add considerable value to the PR team by providing an accurate and honest assessment of the incident. The incident response team should also be give the authority to review any materials prepared by PR prior to their release to assure that no misleading or potentially damaging information is revealed.

Enterprises, from the top down, need to start thinking of incident response in terms of IR3 instead of regular old IR. This means giving a voice to the incident response team and security analysts while at the same time expecting them to help return business operations to normal in the event of a breach.

This entry was posted on Thursday, February 28th, 2008 at 4:21 pm and is filed under Network Forensics, incident response. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.