‚ < ‚ Free Open Study ‚ > ‚ |
The next portion of this chapter provides an overview of the process of responding to incidents. Initial ConsiderationsA successful incident response effort is closely linked to policy. This next subsection explains why and how. PolicyComputer 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.
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 :
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 ReviewHaving 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.
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 OrganizationChapter 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 ArchitectureDeveloping 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 NeededOne 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 BaseA 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 ProceduresPlanning 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:
Developing Cooperative RelationshipsSecurity-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 ConsiderationsEvery 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 MetricsMetrics 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. |
‚ < ‚ Free Open Study ‚ > ‚ |