Overview of Incident Response

The next portion of this chapter provides an overview of the process of responding to incidents.

Initial Considerations

A successful incident response effort is closely linked to policy. This next subsection explains why and how.

Policy

Computer and information security begins and ends with policy. An information security policy is a high-level description of essential elements of computer and information security, including the basic requirements and infrastructure necessary for establishing security.A policy generally describes do's and don'ts for users (and possibly system administrators) and specifies punishments for failure to observe the provisions of the policy. An effective policy also describes an organization's security stance ‚ whether the organization generally wants open and free access at the cost of little security, tight security controls at the cost of greater inconvenience to users and possibly loss of functionality and performance, or something in between these two extremes.

Performance Appraisal

Ideally, an information security policy will also include provisions related to each employee's adherence to the information security policy in the personnel performance-appraisal process. In most cases, this is a better approach than simply spelling out punishments for failing to comply . The prospect of punishment generally evokes strong negative emotions in humans .

A policy is a necessary part of a successful computer and information security effort. Failing to specify requirements in advance spells doom. Although the context of the coverage of policy here has been computer and information security in general, everything said so far applies equally well to the area of incident response (which is one of the many areas within the umbrella of computer and information security). Unless an organization's information security policy specifies requirements for incident response, these requirements will almost certainly not be met. Some important types of incident response requirements typically included in an information security policy are as follows :

• The sanctioning of the incident response capability, (that is, stating that it is a required function of the organization in question)

• The mission or objectives as well as the scope of this capability

• The authority (if any) given to this capability

• The limits of incident response (what kinds of actions are and are not permissible during the process of responding to an incident)

• The relationship to the law enforcement community (whether law enforcement should be brought in to deal with an incident and, if so, when)

Simply writing a policy, of course, does little or no good and is, in fact, an almost sure recipe for the policy being ignored. Obtaining buy-in from those who are affected by it is necessary to stave off resistance. Especially critical is approval by senior-level management; without senior-level management's support, a policy is almost certainly doomed to fail. Making the buy-in from senior-level management widely visible (for example, by having the CEO or someone who reports to the CEO sign it) to those affected by the policy is, in fact, one of the best strategies in making a policy work.

Policy Review

Having a policy is important, but policies get out of date over time. It is thus important to review an organization's information security policy, especially (in the current context) any provisions related to incident response, and make changes as needed. New types of incidents will emerge, necessitating changes in incident response ‚ related policy provisions. Parts of an incident response effort might also prove unsuccessful , necessitating an analysis of whether certain requirements were appropriate in the first place.

Who should participate in a policy review? Normally, the manager of the incident response effort, the head of computer and information security (who might or might not also be the incident response manager), senior IT management, the head of audit, and others should participate. Note that effective policy is high level and thus does not include technical content. ^[1] Having technical personnel participate in a policy review is thus usually in appropriate.

^[1] This statement does not imply that technical requirements should go unwritten. Technical requirements should simply be embedded in another type of document (a technical standards or guidelines document) rather than in a policy.

A policy review should normally occur every six months to a year, although it is a good idea to conduct a special review whenever it is appropriate (for example, when a conflict between provisions in the policy and other requirements is discovered ).

Planning and Organization

Chapter 5,"Organizing for Incident Response," covers planning and organizing for incident response in detail. This next section introduces topics covered more fully later.

Developing an Incident Response Architecture

Developing an incident response architecture is especially critical. An incident response architecture defines the components of an incident response capability and how these components are interrelated. Normally, an architecture can be represented by a pyramid with the highest (most conceptual) elements at the top, followed by more specific elements at the next level, followed by even more specific elements at the next level. Possible components include policy, procedures, technology, intrusion detection, communications, and others. Figure 1.2 illustrates one possible rendition of an incident response architecture.

Figure 1.2. A possible incident response architecture.

Estimating Resources Needed

One of the downsides of incident response is that it is not cheap from a financial perspective. Many incident response efforts fail, or at least border on the brink of ruin, due to lack of resources. It is thus essential for management to attempt to accurately gauge the level of resources needed for an incident response effort and then begin to explore ways to obtain this level. Resources must cover expenditures on items such as personnel, technology, travel, training, facilities, and other categories.

Establishing the Proper Technology Base

A suitable technology base is absolutely integral to a successful incident response effort. For example, intrusion detection is an extremely important component of such an effort. To determine whether a security-related incident has actually transpired, intrusion detection software might be necessary. This kind of software is generally not cheap; without proper planning, a budget shortfall that precludes the purchase of such software is likely. Other kinds of software that might be essential are integrity-checking software that detects any change in files and directories, antivirus software (which is now virtually a necessity rather than a luxury), forensics software, database software (to archive relevant data), and other types.

Software, however, is only part of the technology base that needs to be established. Hardware such as server platforms and workstations is a necessity. Communications devices such as cellular phones and pagers are no longer just an option. Palm Pilots, dictaphones, fax machines, and other types of devices might also be necessary.

Developing Procedures

Planning and organizing for incident response also requires creating highly comprehendible, detailed procedures for responding to incidents. Such procedures offer several significant benefits, including the following:

• Shortening the learning curve. Incident response typically requires a steep learning curve. The availability of procedures can substantially shorten this learning curve for those who are new to the incident response arena.

• Uniformity of response efforts. If followed, procedures ensure that the same kinds of steps are followed by those who engage in incident response, regardless of the particular individual involved, type of incident, and so forth.

• Quality assurance. If well written, procedures help ensure a certain degree of adherence to established standards. This promotes quality of incident response efforts.

• Legal considerations. If a lawsuit or even criminal charges should grow out of an incident, evidence of the existence and deployment of standard procedures for incident response can counter certain legal allegations that might be presented.

Developing Cooperative Relationships

Security-related incidents are seldom isolated to one or two systems or networks in a single organization anymore. Increasingly, these incidents are widespread, typically even crossing international boundaries. Additionally, one never knows the next entity with which one must deal. Incident response teams , Internet service providers (ISPs), vendors , and law enforcement agencies are just a few of these possible entities. After all, "no man is an island."The incident response effort that does not heed this truism will likely not accomplish much. Building cooperative relationships with other entities is an important consideration in planning for and organizing an incident response effort.

Dealing with Organizational Considerations

Every incident response capability is part of some overall organization or, in some cases, group of organizations. To be truly effective, this capability must fit in reasonably within the organization(s). Virtually every medium- to large- size organization has, for example, an operations organization. On the downside, it is possible for an incident response effort to collide with operations, causing major fallout. On the upside, operations might deploy certain hardware and software that might be useful. A good example is hardware and software used in intrusion detection. If operations already has created an intrusion-detection capability, tapping into this capability would normally make more sense than setting up an independent one.

It is also important ‚ to the maximum extent possible ‚ for intrusion response capabilities to work within the cultural context of the organization to which they belong. An organizational culture that, for instance, highly values privacy is not likely to be receptive to efforts to construct profiles on individual employees .

Finally, it is critical for an incident response effort's procedures, data archival methods , and other facets of operation to coincide to those of the organization of which this capability is a part. If a conflict surfaces, modifying the team's procedures and practices to coincide with the organization's is normally the best course of action. In exceptional cases, special requirements (such as the need for forensics) might call for exemption from the organization's procedures and practices. In this case, discussing the team's particular requirements with senior management is the proper course of action.

Establishing Metrics

Metrics are measurement conventions represented in terms of numbers . Metrics in the field of computer and information security have gotten off to a rather slow start; it is, after all, often difficult to think of metrics for critical variables such as "adequacy of existing controls given levels of threat." Metrics are now starting to gain more acceptance, in part because they provide one of the most important ways to communicate with senior management.

Metrics are particularly important in the area of incident response because management is likely to ask for status reports or other queries in terms of metrics, such as "number of incidents handled." It is important to consider and evaluate possible metrics when planning and organizing for incident response. Fortunately, the incident response arena is very conducive to the use of metrics. Metrics, such as the number of incidents handled, number of business- threatening incidents handled, average time for incident detection, average time from incident onset to termination, and others are fairly intuitive.