Forming and Managing an Incident Response Team

This chapter is from the book

Incident Response: A Strategic Guide to Handling System and Network Security Breaches

Learn More Buy

This chapter is from the book

This chapter is from the book 

Incident Response: A Strategic Guide to Handling System and Network Security Breaches

Learn More Buy

Issues in Forming a Response Team

Forming an incident response team generally is not as easy as it superficially might appear. The individual(s) charged with this responsibility must deal with many key issues, including policy, whether or not a team is really necessary, defining and communicating with a constituency, defining functional requirements, defining the role of the incident response team, staffing the team appropriately, and creating and updating operational procedures. This section discusses these issues.

Policy

The most important issue in forming and managing an incident response team, all things considered, is policy. Any incident response team must always operate within the constraints of the policy of the organization to which it belongs or that it serves. Suppose, for example, an organization requires that no employee make contact with or answer questions from the press unless that person obtains written approval from the head of the public relations department. Another organizational policy provision might be that no system being attacked can stay connected to the network if it holds extremely valuable resources (such as proprietary data, proprietary source code, and so forth).

Additionally, an incident response team might impose its own policy provisions on its own operations. A policy provision of this nature might be that no team member can spread information about any incident outside of the immediate team without the direct permission of the team leader. Failure to conform to existing policy spells catastrophe for an incident response team; consequences can range from embarrassment to termination of employment or even to dissolution of the team itself.

Is a Team Really Necessary?

Another extremely important issue is whether an incident response team is really necessary. Some of the advantages of forming a response team have been presented earlier in this chapter, but it is not always advantageous to create such a team. An alternative is to have individuals who are not part of an incident response team but who are available (usually on the basis of a matrix agreement¹ between organizations) when incidents occur. Here are some possible advantages of adopting this alternative approach:

• Smaller organizations generally do not need a team. A smaller organization, such as a small startup company, does not usually need an incident response team per se. This kind of company is not likely to have very much internal structure; creating policy and procedures, in many cases, is something that must be placed on the proverbial backburner while more immediately pressing issues (survival of the business) are addressed. Forming an incident response team would constitute overkill.

• Few resources might be available. One of the major reasons for not forming an incident response team is lack of resources, particularly personnel resources. Although not a particularly good reason from a security viewpoint, lack of resources is too often a problem for information security efforts in general.

• Incident response might work better as a distributed effort. In some organizations, incident response works better as a distributed effort. Different individuals from different divisions or groups can be called in whenever an incident of sufficient magnitude or impact occurs. Having this kind of arrangement can make these divisions or groups feel that they have some kind of direct control over the incident response process; some of their own staff members will be involved in handling their own incidents. Additionally, a distributed effort can help ensure that people who know and understand how individual units work, how the systems and networks are configured and maintained, how the applications work, and so forth will be involved in handling incidents. This can lead to better insight into what should and should not be done to resolve each incident satisfactorily.

  What if You Don't Have a Response Team Per Se?

  The authors of this book feel that, all things considered, it is better to have a response team to deal with security-related incidents than to call on individuals when incidents occur. Many readers of this book will never be part of an incident response team, however. If it is not possible to have such a team, you can adopt measures that will increase the likelihood of success in your efforts to handle incidents. Consider the following suggestions:

• Identify key personnel (especially technical personnel), people you feel are qualified to deal with incidents and obtain contact and other information.

• Establish some kind of ground rules or agreements concerning the availability of people who are likely to be needed in dealing with incidents. Try to get a commitment from management that guarantees a minimum number of hours of participation (per week, month, or year) from each individual who might be involved. Try to obtain assurance that even more hours of support will be available in the case of a severe incident.

• Be wise in your dealings with organizations that provide individuals who are available for incident response support. In many cases, having these individuals participate in incident handling detracts from their own mainstream missions. Avoid being overly demanding and be prepared for a "no" answer. Sometimes an organization might refuse to allow someone from that organization to deal with an incident due to a pressing need such as meeting a major project milestone. Having a long list of potential incident support personnel—so that if one person is not available, you can turn to another—is thus essential.

• Provide some kind of training and orientation to everyone who is likely to help in dealing with incidents. Ensure that everyone has at least a minimum level of knowledge about responding to incidents and that everyone understands the importance of cooperation and teamwork.

• To the maximum possible extent, solve leadership and authority issues in advance. In many (if not most) incidents, having someone in charge is essential to success. Conversely, having several people think they are in charge is extremely counterproductive.

• Do not call on the individuals who are available for incident response support unless they are genuinely needed. You are disrupting some other business unit or group's work each time you call on such individuals. You will wear out your welcome if you call on these individuals too much or if you call them into too many false alarms.

• Organize a committee or board that oversees incident response activities. Have this entity analyze critical aspects such as difficulty in obtaining support personnel, efficiency of incident response activity, and others. This entity might be instrumental in pointing out to management things that need to be improved (such as resource levels) and might prove to be instrumental in helping you form a team in time.

What Are the Functional Requirements and Roles?

If you have ever taken a course in software engineering, you have learned that defining requirements right up front is crucial to the success of the project. Incident response teams are no exception to this principle; functional requirements and the role for this team need to be defined as early in the life of the team as possible.

Basic Requirements

The most fundamental requirement for an incident response team is providing incident response support to a constituency. In providing incident response support, a response team can serve several potential roles:

• A team can assume full control over an incident and any computing and data resources involved. The extreme version of this role is to go to a site or area within a facility and take over all incident response efforts.² In most settings, however, this approach does not work too well in that it alienates others, particularly the owners of the computing resources and data, causing territory wars. If mandated by senior management, however, this approach can be viable in that it establishes a clear line of authority during incidents.

• Another, less extreme approach is control sharing—both the incident response team and operations or business unit staff. This generally causes less friction, but questions concerning who is in charge at any time are likely to arise.

• Still another possibility is providing direct (hands-on) incident response support but limiting this support to a purely advisory role. This means that an incident response team will do something only when its constituency requests that it do so. This role ruffles fewer feathers but typically also greatly limits the role and effectiveness of the people who serve on the incident response team.

• A final potential role for a response team is providing indirect rather than direct support in the form of advice but nothing more. This role is the most limiting for team members. However, it also tends to alienate others the least of any role.

Additional Requirements

In many circumstances, simply providing incident response support is not sufficient to keep management happy. Management too often views an incident response team as individuals who sometimes are busy but at other times have absolutely nothing to do. Management might, therefore, demand more of the team. In other cases, the individuals who attempt to create a response team can see the need for the team to perform other activities related to incident response support. Here are some additional potential types of requirements for a response team:

• Interagency/corporation coordination/liaison. The response team might, for example, provide a liaison function with other response teams, an organization's business continuity organization, law enforcement agencies, or some other entity.

• Serving as a clearinghouse. A clearinghouse serves as a central repository for information, patches, tools, and so forth. Although almost every response team in some way serves as a clearinghouse for information about incidents and vulnerabilities, serving as a clearinghouse for patches and tools has quite a few additional risks. What if the team provides the wrong patch, resulting in an unexpected incident or system failure? The same applies to tools. The point here is that serving as a clearinghouse for patches and tools often (but not always) poses more risk than potential benefit.

• Contingency planning and business continuity services. In some organizations, an incident response team also engages in contingency planning and business continuity functions. This is potentially a good idea in that incident response personnel generally become very proficient in recognizing and dealing with emergencies. All things considered, however, the best way to meet this kind of requirement is to have one or more individuals from a business continuity team closely work with or even join an incident response team. Business continuity staff members generally know things that incident response people need to know, such as what to do to protect business interests in the case of a prolonged outage. This kind of knowledge can be well applied to security-related incidents such as massive distributed denial-of-service attacks.

• Information security tool development. Another possible requirement is for the incident response staff to develop information security tools in their spare time. This kind of requirement can result in the availability of useful tools for a team's constituency. The downside is that tool development sidetracks team members from the team's main focus, namely handling incidents. A division within the team—incident handlers versus developers—might even develop.

• Incident response planning and analysis. A few teams have a requirement to analyze trends and plan for incident response and security needs of the future. Although most teams are not funded sufficiently to engage in efforts of this nature, incident response planning and analysis is one of the most proactive and potentially valuable activities in which a response team can engage.

• Training and awareness. We will discuss training and awareness in more detail later in this chapter. Suffice it to say, at this point, that training and awareness is one of the most proactive activities in which a response team can engage. Response team members will learn about many developments and trends—such as new types of malicious programs, new types of attacks, new countermeasures, and so forth—that are potentially of great value to the team's constituency. Training and awareness activities are a good outlet for disseminating this kind of information.

Who is the Constituency?

An essential issue in incident response is determining exactly whom you are supporting. In other words, you need to find out who your constituency is. The reason this is so important is that an incident response effort that does not meet the needs of those it serves is doomed to failure. If you can determine whom your constituency is, you can communicate with that constituency to learn the needs that exist. You also will know how to better focus your efforts.

If, for example, you discover that your constituency consists largely of system administrators, your approach to providing incident response support will be substantially different than if you have mostly users as customers. In the first case, you will probably need to be more technical in your approach. Your communications with system administrators will, in all likelihood, be of a technical nature. In the second case, you will almost certainly take a much less technical approach, emphasizing instead things that users need and can understand. Motivating users to engage in sound computing practices—such as updating antivirus software on desktop systems and helping users whose systems have virus or worm infections by advising them to avoid dealing with these incidents directly³—would in this case be more appropriate.

A response team's relationship with its constituency will make or break an incident response effort. Providing quality help to the right people will eventually result in positive feedback to both the team and its management or sponsor. Many teams (some of which are still in existence, others of which are not), however, have failed primarily because they have neither understood who their constituency is nor served their constituency's needs very well. The following sidebar describes some of the many mistakes that some incident response teams have made.

Communicating with a Constituency

After a response team's constituency is defined, establishing communication channels is essential. One-way communication, in which the response team keeps sending information to its constituency without communication being initiated by the constituency, generally does not work. An effective response team needs to obtain information about what is actually occurring within its constituency. It is possible, for example, for a response team to be unaware that a worm is circulating within part of its constituency's networks. Learning that this is happening would enable the response team to be able to better serve its constituency.

The bottom line here is that an effective incident response team establishes two-way communication. It shares information about vulnerabilities and types of incidents that are occurring within its constituency. As the saying goes, "You have to give information to get information." If the response team's constituency does not share information with the response team, the response team is not likely to have much worthwhile information to share with its constituency.

A response team can use any or all of the following avenues of communication:

• Telephone. One of the most simple and direct avenues of communication is the telephone. Calling someone can inject a personal touch into communications with a constituency. The fact that telephone conversations are in real time is also an important advantage of this means of communication. The downside is that people do not always speak and/or listen as well as they should; misunderstandings and miscommunication can occur. Another downside is that telephone communications are subject to eavesdropping, especially with cordless telephones based on radio frequency transmission and wireless telephones.⁴

Secure telephones solve the eavesdropping threat in that they encrypt voice transmissions from one secure telephone to another. An example of an encrypting telephone is an STU-4—something that the U.S. government uses for transmitting classified information via telephone. A limitation is that not everyone can have access to a secure telephone when it is needed. Additionally, secure telephones can prove financially costly.

• Email. Email is another potentially advantageous means of communicating with a constituency because of its efficiency. You can send a message to someone else in another part of the world in only a few seconds. Furthermore, the person to whom you send the message does not have to be monitoring email at that particular moment in time. Additionally, you can create mail exploders to which you send a message that is subsequently sent to an entire distribution list of email addresses. As pointed out in Chapter 3, "A Methodology for Incident Response," however, email is extremely prone to eavesdropping. Email can also easily be spoofed, and incident response team members are also sometimes spammed by attackers.

A better solution is secure email, which encrypts email messages sent from one system to another. Various freeware and commercial packages that deliver email encryption are available. They provide a good solution for the eavesdropping problem but tend to be plagued with problems related to using encryption— particularly key distribution and key recovery.

• Fax. Sending faxes is an often overlooked but potentially effective means of communicating with a constituency. A nice feature of faxes is that they generally result in an easy-to-read hard copy. Additionally, faxes can be sent when one's network or mail server is down. Some types of fax machines can even explode a single fax message to hundreds of fax numbers in only a few minutes.

Faxes, like anything else, are hardly a panacea, however. One of the greatest limitations is that they do not work when the destination fax number is busy or out of order. Faxing messages can also be unduly labor intensive because it takes a while to set up a fax transmission, undo any paper clogs at both ends of the transmission, replace empty paper bins, and so forth. Additionally, fax transmissions are potentially subject to eavesdropping. Secure faxes solve this eavesdropping problem, but they tend to be more expensive. Because of all the potential complications associated with fax communications, our recommendation is to use this method of communication as a backup rather than as a primary method.

• Bulletins/notices. Bulletins and notices provide an excellent way not only to communicate important information to a constituency but also to gain credibility. CERT/CC, vendors, and others already publish more than enough bulletins; ensuring that there is added value is thus an important consideration. An incident response team might, for example, publish alerts describing only the vulnerabilities currently being exploited most frequently. Alternatively, bulletins might describe new types of countermeasures.

  One of the keys to using bulletins and notices effectively is creating, and then constantly updating, an accurate distribution list. Doing so, however, is likely to be more labor intensive than one might imagine. Additionally, there are many potential pitfalls. Neglecting to add the email address of a key person from within one's constituency (or worse yet, accidentally or intentionally deleting that person's address) is a potentially major mistake. If bulletins are sensitive or proprietary but continue to be sent to employees who leave a company or organization, trouble can also occur.

  To Pay or Not to Pay, That Is the Question

  In the spring of 2001, CERT/CC announced that its advisories would no longer be available for free and that organizations would have to pay a yearly fee of up to $70,000 to obtain these advisories. A negative reaction within part of the Internet community resulted. Critics pointed out that CERT/CC's capabilities were developed at U.S. taxpayers' expense and that to start charging for CERT/CC advisories was unfair. Since CERT/CC made this announcement, other organizations that create bulletins describing new vulnerabilities have announced that they, too, are considering charging a fee for their bulletins. Even if CERT/CC does charge a fee for its bulletins, there is no need for panic. Many other teams and organizations produce bulletins of such high quality that there will be no shortage of information about vulnerabilities and incident trends.

• A web site. One of the most effective ways to share information with a constituency is to create and maintain a web site. Given the current popularity of the World Wide Web, it is now virtually mandatory for an incident response team to have its own web site. The web site should disseminate a variety of useful information, including bulletins and notices, how to contact the response team, and so forth. A response team might even use its web site to distribute patches and/or software tools if it chooses to perform this clearinghouse function.

  A key consideration related to running a web site is the security of the site. A break-in or defacement can cause all kinds of trouble, not only in terms of loss of face for the response team but also for that team's constituency. Without sufficient web site security, users might obtain bogus information or might download malicious programs. Another possibility is that the web site might not be available due to a prolonged outage because of a denial-of-service attack. The distributed denial-of-service (DDoS) attack on CERT/CC in the spring of 2001 is one of the best-known attacks of this nature.

• Conferences. Participating in a conference or actually holding a special conference can provide an effective way to communicate with a response team's constituents. Talks and panel presentations can disseminate useful information to a team's constituents. Additionally, having response team members participate as speakers and panelists can enhance the reputation of the team and help it gain more visibility within its constituency.

• Courses and workshops. Courses and workshops provide still another potentially useful way to communicate with a constituency. If of sufficient quality, courses and workshops can impart a considerable amount of information to those who need it. They can also enhance the reputation and credibility of team members who teach a course or workshop. Best yet, courses and workshops represent proactive efforts at their best. No incident response team will ever be able to help everyone within a constituency when incidents occur, but courses and workshops can teach users, system and network administrators, and managers enough to be able to deal adequately with most incidents that occur.

  A word of caution is appropriate here. Note that the preceding paragraph included the phrase: "If of sufficient quality . . . " If a course or workshop is not of sufficient quality, the team that develops and presents it can quickly become despised within its own constituency. The availability of so many outstanding security-related courses nowadays has raised the proverbial bar for security training. Getting help from training specialists, possibly from a consultancy, is often a wise move.

• Media interviews. Media interviews can also help in the process of communicating with a constituency. If done correctly, these interviews can enhance a response team's reputation and visibility. The following sidebar describes some basic principles in dealing with the media.

  Dealing with the Media

  Dealing with the media is often an important part of responding to incidents. Much of the damage from many incidents is in terms of loss of reputation or confidence in an organization due to one or more catastrophic incidents. Your organization should have a policy dictating that all contacts with the media be approved in advance by management. In fact, in the ideal scenario, a public relations department should handle all contacts with the media. (You might, in turn, be called upon to furnish technical information.) The following are time-proven methods for dealing with the media:

  • Learn as much about the interview in which you are going to participate as early as possible and prepare accordingly.

  • Outline the major points you want to get across.

  • Anticipate a wide range of difficult questions and prepare answers in advance.

  • Establish rapport with your interviewer as soon as possible.

  • Use brief sentences.

  • Provide simple explanations of each technical point you make.

  • Every time you speak, steer your communication to some point you want to get across (take the initiative to do this!).

  • Don't get intimidated.

  • Turn negatives into positives.

  • Be diplomatic, but always tell the truth.

  • When you don't know the answer, admit you don't know (and perhaps offer to find out).

  • Be liberal in giving credit but stingy in assigning blame.

  • Dress appropriately.

  • Avoid image-damaging nonverbal communication, such as avoiding eye contact or slouching as you sit.

  • After the interview, ask to review any written materials for inaccuracies.

  • You, the interviewee, have rights. Feel free to terminate the interview at any time if your rights are not respected!

  The following are some questions you are most likely to be asked:

  • What happened?

  • What was the result/damage?

  • What was the cause?

  • What did you do about it?

  • Is what happened likely to reoccur?

  • What can people do to avoid what happened?

  • There are, of course, no guarantees of success when you deal with the media, but following these principles listed can go a long way toward achieving a desirable outcome.

• Videotapes. A final method of communicating with a response team's constituency is videotapes. Videotapes can convey important information such as why having a response team is important, how to contact the response team, the kinds of incidents that are mostly likely to occur, and what to do if an incident actually occurs. If produced professionally, a videotape can have great impact on those who watch it. A videotape can also be shown multiple times with what usually amounts to little effort on a response team's part.

  The security group in one organization developed a very short but effective videotape titled "30 Seconds for Handling Security Incidents." This videotape presented a few major types of incidents and what to do about each if any should occur. The video played continuously in the organization's cafeteria; employees going in and out of the cafeteria were likely to catch at least some of the videotape as they were hanging their coats up or putting them back on.

  Like anything else, videotapes have limitations. Producing them through an in-house effort can be frustrating, time consuming, and financially costly. Yet a videotape produced by the team itself will almost certainly at least be tailored to the specific needs of the organization.

  Requirements for Communicating with a Constituency

  Because communications with a constituency are so critical to an incident response team's success, trying to meet all of the following goals is extremely important:

  • Relevance. A response team must provide information that is relevant to whomever it serves. If the constituency has mostly UNIX and Linux systems, providing bulletins about the latest vulnerabilities in mainframes will, if anything, antagonize individuals from within the constituency.

  • Timeliness. The information that a response team provides must be current. This means that if a new vulnerability that is being widely exploited by freely available cracking tools has been discovered, an effective response team will get this information to its constituency soon afterward. Additionally, this means that if other response teams have written and distributed bulletins about a new vulnerability, a response team cannot afford to lose face within its own constituency by waiting several days after the others have issued their bulletins to issue its own bulletin.

  • Accuracy. Information provided by a response team must be accurate. Few things destroy a response team's credibility as quickly as disseminating inaccurate information. At a minimum, every sentence of every bulletin or notice should be reviewed (preferably by experts outside the team) for accuracy before the bulletin or notice is sent. At the same time, however, it is important to realize that not all the information that will eventually be available might be available at the time one's constituency needs to hear about some new vulnerability or pattern of incidents. What superficially appears to be true might not turn out to be true over time. Being prepared to issue revised bulletins and notices, therefore, is critical. The same basic principles apply to training materials, press interviews, and so forth.

  • Originality. First-rate response teams write their own bulletins and notices. Copying or appending other teams' bulletins and notices is generally a bad idea. (An exception is when a very small incident response team has too few people to expend the level of effort needed to create original bulletins). Constituencies generally do not hold teams that merely copy other teams' bulletins in very high regard.

  • Understandability. Information that a response team disseminates must be readily understandable by those who receive it. Given that part of one's constituency is likely to be management and another part will be technical staff, this is a potentially difficult issue. Sometimes writing an executive summary at the start of a bulletin that is primarily technical in nature solves this problem. In other cases, producing two bulletins on each issue—one for management, one for technical personnel—works.

  • Reliable distribution. The information needs to get to those who need it—without exception.

Developing Out-of-Band Communications

At some time during the life of an incident response team, conventional communications channels will not be available. It is therefore important to develop out-of-band communications capabilities. A few alternative channels are wireless networks, text pagers, fax communications, and email delivery via a postal service. The first two of these alternative channels, in particular, require advance arrangements and coordination within a response team's constituency. It is expedient to analyze current communication channels and then develop out-of-band communications capabilities for plausible primary communications outage scenarios. You should ensure that each communication channel meets some kind of minimum security standards, and you should regularly test each communication channel to ensure that it works as expected. New developments show that HAM radios are becoming a popular mode for emergency communications.

Staffing Issues

So far, we have described many difficult issues that need to be addressed, but no issue is more difficult than dealing with staffing. Addressing staffing-related considerations such as team size, prerequisite skills, and location of team members is critical. A discussion of these considerations follows.

Team Size

The size of your team will undoubtedly be dictated by available funding. This is particularly true during the early stages of your team's existence. At a minimum, you will initially want to have someone to manage the team and, if funding permits, someone with the technical skills necessary to deal with the problems that are most likely to surface within your constituency.⁵ You can then add staff to broaden the range of expertise as funding allows.

Team Skills

This section presents the kinds of skills that are generally required in an effective incident response team.

• Management skills. Proficiency in management is almost without question the single most important skill. Without effective management, even the most technically proficient team will falter. The manager of an incident response team must be able to ensure that the team has the appropriate skill sets; organize and coordinate the team's activities; keep team members motivated and on track; ensure that the team has sufficient resources and that the resource burn rate is within acceptable limits; ensure that proper priorities, procedures, and policies are in place and are revised as necessary; prepare reports for senior management; monitor how well the team is meeting its requirements; intervene if and when conflict occurs; and play politics well enough to both shield team members from them and keep management supportive of the team.

  The team manager does not have to be technically proficient (and, if fact, probably should not be too technically proficient to avoid the temptation of getting involved in technical issues at the expense of performing critical management responsibilities). At the same time, however, the team manager needs to know enough about technical matters to be able to make good judgments about priorities and to avoid hurting the team's reputation when the manager deals with the constituency, vendors, and others.

• Technical skills. Technical skills are extremely essential to a response team's effectiveness. Many incidents require a high degree of technical proficiency in analyzing what is wrong and dealing with the situation. Additionally, unless team members earn a large degree of respect for their technical prowess within a team's constituency, no one will contact them for help, nor will they heed their warnings and advice. Technical skills in operating systems (UNIX, Linux, Windows NT and Windows 2000, NetWare, OS390, and so forth) and network security are particularly critical.

  Programming experience, particularly in system programming, can help considerably when a response team needs to reverse-engineer malicious programs such as worms and back doors. There is no substitute for real-world troubleshooting experience such as dealing with operational outages. Computer crisis coordination capabilities are constantly in crisis mode; previous relevant experience has great payoff.

  Not every team member needs to be a top-notch technical expert, however. Exceptionally strong technical personnel are rare. Furthermore, they generally command top salaries. Funding realities will generally limit how many gurus can be hired. A key to having sufficient technical expertise, therefore, is to hire one technically accomplished staff member to anchor each key technology area in which the team needs to become involved. The guru in each area can then advise and mentor less technically accomplished team members.

• People skills. Nowhere are people skills more important than in the incident response arena. Harmony within the team is critical to the team's efficiency and effectiveness. Being able to get along well with individuals within the team's constituency is also very important. Technical gurus often have the reputation of being hard to get along with, so the challenge of hiring team members with good people skills is a difficult one. Periodic training in interpersonal skills can also have a high payoff.

• Teamwork skills. Teamwork skills are somewhat different from people skills in that they involve different types of knowledge, abilities, and perspectives. Teamwork skills are related to having a common vision, effectively dividing responsibilities, effectively estimating task completion time, knowing when to start new tasks, knowing how to get out of other team members' way when doing so is appropriate, obtaining feedback concerning each team member's progress, and so forth. Strong management skills are once again the key ingredient; good managers promote and build team skills. We also recommend participating in periodic team skills training.

• Communication skills. Communication skills go hand-in-hand with both interpersonal skills and team skills. Special kinds of communication skills, particularly writing and speaking skills, can be exceptionally valuable. Many incident response teams hire a technical writer for the specific purpose of producing accurate, understandable bulletins and notices. Additionally, speaking skills are very useful for conference and workshop presentations, filming videotapes, and so on.

Location of Staff

Where should team members be geographically located? If an organization and its constituency are all within a single geographical area, the answer is obvious. But what if the constituency is spread out among several different locations, possibly even on different continents? Should all team members reside at one location, or should the team be divided so that each part of the team's constituency is served by team members located where they are needed?

The answer to this question depends on a number of factors. Some advantages of having all team members at a single location include a better ability to coordinate the team, greater ease of communication within the team, facilitation of team building among team members, and (generally) a lower financial cost because only one physical facility, one telecommunications provider, one document custodian, and so forth will be necessary. Additionally, separating a team into different parts residing in different geographical locations often results in undesirable divisions and negative politics within the team itself. In this case, it is not unusual to find that each piece of the team develops an "us versus them" mentality.

Advantages of having multiple locations are generally related to providing a higher quality of service to one's constituency. If part of the constituency is in central Europe, for example, and part is in the central United States, the difference in time of seven hours might prove to be an overwhelming obstacle if all members of a response team are in the central United States. If someone in central Europe arrives at work at 8 a.m. Monday morning and discovers an incident, that person would likely have to wait approximately seven hours before being able to talk to someone from the response team. It would probably be better, in this case, to have part of the team reside in central Europe.

Should you have full-time or part-time team members? The answer to this question is simple; in general, it is better to have full-time team members. Having full-time team members means more personnel resources will be available when they are needed. This is particularly important when high-impact incidents occur or when a multiple-points-of-presence attack (in which multiple attacks are launched against sites in different geographical locations) is launched. On the other hand, funding realities might dictate that part-time team members be hired. Alternatively, perhaps some gurus are available only on a part-time basis. In these cases, part-time involvement is better than no involvement at all.

Creating Operating Procedures

The topic of procedures is potentially very complex. Entire books on effective information security–related procedures have been written. Previous chapters of this book have touched on this topic, especially regarding the necessity of having well-written, well-distributed procedures for incident response. Additionally, procedures must constantly be revised if they are to be effective in guiding the incident response team and others to appropriate actions.

You cannot really simply copy some other team's procedures and then use them. You must instead create procedures that are appropriate to your particular team and the requirements that team must fulfill. The following, however, are issues that any set of procedures must address if they are to be effective:

• What the purpose of the procedures is

• To whom or what the procedures apply and under what conditions (if at all)

• Lines of authority within the incident response team and the organization(s) it serves

• Restrictions on the kinds of actions in which team members can and cannot engage (including actions such as counterattacking sites known to launch attacks)

• How information and evidence must be documented

• Who can contact outside entities (such as the media, law enforcement agencies, and so forth) and under what conditions

• Priorities in response efforts (for example, protecting the lives of humans, keeping systems and networks operational, and so forth)

• What to do in case of incidents in highly valuable, sensitive, proprietary, or classified systems and/or networks

• Kinds of information that can and cannot be disseminated outside of the immediate group or division in which the incident response team belongs

• Management's role with respect to the response team and its activities

• When and how the procedures must be changed

• How the procedures are to be distributed

Procedures should in every respect be a living document. Every time your incident response team engages in the follow-up stage of the PDCERF methodology (or whatever methodology your team creates), it should evaluate existing procedures to determine whether they actually worked. You should then revise your procedures as needed.