There are numerous considerations that should be addressed during the formation of an incident response team. Then a solid foundation can be laid for the other decisions that must be made toward the completion of the team. The chapter first defines the focus and mission of the team, then moves into various operational aspects that may be considered.

This chapter is from the book

This chapter is from the book

Many people who enjoy putting jigsaw puzzles together take the same approach. That is, they find the pieces that outline the
picture and put the frame together first, then proceed to identify and place the inner pieces. By having the border in place,
it often becomes easier to get a sense of the overall picture, with the border serving as the foundation for completing the
task at hand.

This chapter focuses on identifying those border pieces of the CIRT puzzle by providing numerous considerations that should be addressed during the formation of a team. By addressing these
items first, a solid foundation can be laid for the other decisions that must be made toward the completion of the CIRT. The chapter first defines the focus and mission of the team, then moves into various operational aspects that may be considered.

Focus and Scope

Management courses frequently highlight the importance of mission statements. It is often emphasized that all members of a
team or organization should understand the group's mission so they can take ownership of the tasks at hand. The formation
of a CIRT team is no different with respect to having a clearly identified mission. Establishing a mission up front by identifying
the scope and focus of the team will ease the decision-making process for many later issues. The mission will also have a
direct impact on the number and types of resources that need to be allocated to the team. To aid with this task, start by
answering a few basic questions. (These questions are listed in Figure 2-1.)

Know Who You're Protecting: Defining Your Constituency

First, who is included in the team's constituency? In other words, who are the people who own, use, operate, and are responsible
for maintaining the computers that the team will be monitoring and responding to incidents on if they are attacked? In some
cases, this question is very easy to answer. For example, a university team would usually consider the students, staff, and
any other authorized users to be its constituency. In other cases, the answer may not be so clear. For example, a hardware
or software vendor may have a team established to address internal issues only, to address issues pertaining to its products
only for its customers, or possibly to address incidents on its products and other vendors' products through a consulting
arrangement. If the vendor has a partnership with another company, will the team have any responsibilities for addressing
incidents as part of the partnership? Deciding who the team will support up front helps set the stage for the next set of
questions that need to be addressed.

The distribution of the team's constituency or customer base will also have a major effect on many issues that must be addressed
when forming a team. Will all of the team's clients be located in one building, one city, one state, one geographic region,
one country, or worldwide? A large distribution will provide several obstacles or challenges when on-site support is needed
and when support must be provided 24 hours per day.

Defining Response

Once the constituency is identified, the manner in which the team will respond to incidents should be addressed. If the constituency
is located in one central location, this issue should not be a problem. If the computers are dispersed over a wide geographic
area or worldwide, however, on-site response can be a challenge. Depending on the technical expertise of the organization's
system administrators, a team may be able to remotely provide assistance by walking a local system administrator through response
procedures over the phone, rather than having someone from the team fly to the location and provide on-site support. This
approach should be taken whenever possible, as the reaction time will generally be quicker (thus limiting potential damage)
and the cost of responding to the incident will be lower.

If on-site support is required, then a minimum of two people should be sent to the location with specific checklists and tools
at their disposal. A two-person team is recommended for the following reasons:

If problems arise during the response process, the second person can provide backup support to the primary person in completing
a division of the tasks to be performed.

If personnel are to be interviewed, having a second person can expedite the overall process: One person can conduct the interviews
while the other performs the technical response.

If the level of expertise varies between the individuals, the knowledge and experience of one may be supplemented by the knowledge
and experience of the other. This is especially true for personnel who are relatively new to the incident response role.

A two-person team can provide verification that procedures were correctly followed in case any questions arise about the tasks
completed.

One person can help with documenting the steps taken, while the other is performing the tasks at hand.

Keep in mind that the above checklist should be considered a guide to help with the incident response, but cannot cover every
possible scenario that the incident handlers may encounter.

For teams that cover a large geographic region (including those with worldwide responsibility), the decision may be made to
create several teams and have them geographically dispersed. This approach can help with covering various time zones and limit
the potential response time for on-site support. On the downside, the possibility of detecting a wide-scale attack may be
inhibited because varying resources analyze the incident data. If multiple teams are used, it is a good idea to have one central
headquarters receive and evaluate the incident data from the subteams to provide wide-scale correlation. (As our tools progress
in this realm, this correlation should become easier.)