Incident Response

What Is Incident Response?

Incident response is the discipline of handling situations in a manner that is:

Cost effective

Incident response is by nature a support function (except for companies and organizations that perform incident response as a core business service). Thus, keeping costs to a minimum is vital to success, since incident response is not revenue-generating but revenue-preserving and thus requires some expenditure.

Business-like

In order to be accepted in the business place, incident response must function just like any other business service.

Efficient

In every respect, efficiency is important. Without efficiency, you may encounter duplication of effort, lost time spent learning the basics needed for the given situation, excessive periods of downtime, or the wrong response tools brought to the situation.

Repeatable

As a business function, two similar incidents should be handled either similarly or identically in every regard. For example, the process to handle a network penetration is identical for any organization you encounter. There may be some location- or company-specific flavors or differences, or you may need to adapt your process to fit a special situation, but the overall process should not change that much from one incident to another.

Predictable

Incident response functions must also be predictable. Surprises are bad. A business function owner/manager needs to be able to rely upon incident response and to know what services and other support functions are to be expected from the response team.

If this list looks like it could be used to describe just about any aspect of a successful corporate IT program, it can.

Furthermore, an effective incident response system requires some level of awareness, cooperation, and support from every employee. Just as every employee should know the location of the fire exit, every employee should know how to recognize a potential incident and react appropriately. Employees are the first and sometimes only line of defense in information protection. Teaching them how to recognize potential incidents and react appropriately is a vital step in creating a successful incident response program.

In addition to the general characteristics of being cost-effective, business-like, efficient, and predictable, incident response activities have a number of specific characteristics. The following list is an introduction to the basics of incident response activities:

Prevention

Any legitimate incident response program must be tightly coupled with an organization’s IT security program that seeks to prevent incidents from ever happening. Prevention efforts are where many organizations traditionally devote most of their attention. They include the common security mechanisms employed throughout an organization, from username/password protection of desktop systems to deploying Internet firewall and intrusion detection systems. A successful incident response program seeks to map out and understand the security prevention mechanisms, procedures, and policies used throughout an organization. The reason for this is to be thoroughly prepared and capable of handling a crisis when it occurs by knowing the environment that the incident responders will be operating in.

Planning

Planning for an incident is the most important aspect of handling it effectively. It includes understanding the roles and responsibilities of each person or office, documenting policies and procedures, and developing a thorough understanding of management’s expectations of the incident response program as a whole. This also means having the appropriate levels of technical and management training for those charged with coordinating and/or responding to incidents.

Detection

Being able to handle an incident flawlessly is useless if there is no way of knowing when an incident occurs. Detection mechanisms range from the use of automated intrusion detection tools to awareness training of every employee on how and when to report a security incident. Detection and notification are the cornerstone of any information security incident handling program.

Analysis

When an incident occurs, it is necessary for an organization to be able to analyze and understand the technical nature of what has occurred or is occurring. This understanding is vital in developing a course of action.

Containment

Containing the damage caused by an incident is primarily to protect or restore business functions. Think of closing watertight doors on an ocean liner to prevent a leak from spreading to other compartments.

Investigation

Whether a formal investigation involving law enforcement or an internal investigation, an incident response program needs to facilitate an investigation of an incident. The results can range from seeking legal action for a criminal activity, or seeking monetary damages in a civil action, to simply being able to correct the situation that allowed the incident to occur in the first place. Of equal importance is understanding how to process evidence for potential use by law enforcement.

Eradication

Restoring systems to a secure baseline configuration is usually the final technical step in handling an incident, but must not be underestimated. A severe incident can impact hundreds or even thousands of computers in a large organization, and the business managers whose business functions reside on the systems need assurance that they can once again trust the systems to perform tasks faithfully. A computer system that has been tampered with by a malicious person must be thoroughly reviewed and restored. Sometimes, the best method of eradication is to completely erase the system and rebuild it from scratch. However, when doing so, make sure that the software used (operating system and applications) comes from trusted sources (e.g., CD-ROMs or trustworthy locations) and that your restored system is rebuilt according to your established processes and configurations. Otherwise, you may be setting yourself up for a future incident.

Postmortem

Once an incident is successfully resolved, teams need to review what happened and why. This candid and objective review should include the incident response team and those who participated in the resolution of the incident. Feedback and observations during this review will help discover what worked during the incident response process (a form of self-assessment for the team) and also serve as a “lessons learned” meeting with other technical staff and departments that were involved or impacted by the incident. The goal of such meetings is to facilitate technical or procedural fixes to prevent related incidents from taking place in the future.