Forming an Effective Incident Response Team: What's Your Mission?
This chapter is from the book
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.)
)
Figure 2-1. Questions to Help Identify the Team's Mission
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.)