Creating a Computer Security Incident Response Team: A Process for Getting Started
Keeping organizational information assets secure in today's interconnected computing environment is a true challenge that becomes more difficult with each new "e" product and each new intruder tool. Most organizations realize that there is no one solution or panacea for securing systems and data; instead a multi-layered security strategy is required. One of the layers that many organizations are including in their strategy today is the creation of a Computer Security Incident Response Team, generally called a CSIRT.
Motivators driving the establishment of CSIRTs include
What Are the Questions?
As organizations begin to build their incident response capability, they are looking to determine the best strategy for putting such a structure in place. They not only want to know what has worked well for others, but also want some guidance on the process and requirements they must follow to establish an effective incident response capability.
CSIRTs and their parent organizations have numerous questions they want answered to help them design their response capability. They are also interested in knowing what other teams in similar industry sectors are doing. Typical questions being asked include but are not limited to the following:
There is not a standard set of answers to these questions. CSIRTs are as unique as the organizations they service, and as a result, no two teams are likely to operate in the exact same manner. It is important for the organization to decide why it is building a CSIRT and what it wants that CSIRT to achieve. Once this is determined, then the unique set of answers to these questions can be formulated.
This document is the first in a series of articles that will discuss the issues and decisions to be addressed when planning and implementing a CSIRT. This first article will focus on an overview of the basic high-level steps to be taken by organizations as they design and build a CSIRT. The article is written as a general guideline for any organization that is thinking about undertaking such an endeavor or for any individuals who are members of a project team that is working to establish a CSIRT.
What Are Some Best Practices for Creating a CSIRT?
Although CSIRTs will differ in how they operate depending on the available staff, expertise, budget resources, and unique circumstances of each organization, there are some basic practices that apply to all CSIRTs. We will discuss some of those practices as they relate to creating a CSIRT. (For more information on what a CSIRT is, see the CSIRT FAQ.) Although these actions are presented as steps, the process is not sequential; many steps can occur in parallel.
The steps are as follows:
Step 1: Obtain Management Support and Buy-In
Our experience shows that without management approval and support, creating an effective incident response capability can be extremely difficult and problematic. This support must be shown in numerous ways, including the provision of resources, funding, and time, to the person or group of people who will act as the project team for implementing the CSIRT. This also includes executive and business or department managers and their staffs committing time to participate in this planning process; their input is essential during the design effort.
It is important to elicit management's expectations and perceptions of the CSIRT's function and responsibilities. Without this information, a team may be built whose services and authority are not understood or appropriately used by the rest of the organization.
Along with obtaining management support for the planning and implementation process, it is equally important to get management commitment to sustain CSIRT operations and authority for the long term. Once the team is established, how is it maintained and expanded with budget, personnel, and equipment resources? Will the role and authority of the CSIRT continue to be backed by management across the various constituencies or parent organization? Without this continued support the CSIRT's long-term success may be in jeopardy.
Step 2: Determine the CSIRT Development Strategic Plan
Think about how to manage the development of the CSIRT. What administrative issues must be dealt with, and what project management issues must be addressed?
Step 3: Gather Relevant Information
Gather information to determine the incident response and service needs that the organization has. Take a look at the types of incident activity currently being reported within your constituency. This helps determine not only what type of services to offer but also the types of skills and expertise the CSIRT staff will need. For example, if your organization has been the victim of computer virus or worm activity, you will need staff with virus experience to handle the response. You will also need virus scanning, elimination, and recovery procedures, along with the appropriate anti-virus tools. You may want people with good training and documentation skills to help develop user awareness programs as a proactive step in dealing with virus activity.
Identify what information you need to know to plan and implement the CSIRT. Determine who has that information and how best to elicit that information, either through general discussions or interviews or by making them part of the project.
Meet with key stakeholders to discuss not only their incident response needs, but to achieve an initial consensus on the expectations, strategic direction, definitions, and responsibilities of the CSIRT. Your definition of what a CSIRT is and does may be very different from your manager's definition or the definition of another part of your organization. Use these discussions with the stakeholders to outline and identify how each group will need to interact with the CSIRT. The stakeholders could include but are not limited to
Stakeholders should also include anyone who will be involved in the incident-handling or notification process. Think about who will need to be notified during different types of incidents. Are there people in other parts of the organization or constituency who can provide information or input to the CSIRT or with whom the CSIRT will need to share or obtain information? These may include other parts of the IT or security departments, including any groups doing vulnerability assessments, intrusion detection, or network monitoring. Knowing what the CSIRT will need to do can help you identify the right people to be involved in developing the procedures.
Find out if anyone else is currently performing any of the services that the CSIRT may be looking to provide. Determine if those services should stay with the current group or move to the CSIRT over some agreed-to period of time. Addressing these types of issues in the planning stages can help identify what responsibilities will need to be delineated and what information will need to be gathered.
There may also be some resources available for review that will help in your information gathering. These may include
Reviewing these documents serves a dual purpose: first, to identify existing stakeholders, resources, and system owners; and second, to provide an overview of existing policies to which the CSIRT must adhere. As a bonus, these documents may contain text that can be adapted when developing CSIRT policies, procedures, or documentation. They may also include general notification lists of organizational representatives who must be contacted during emergencies. Such lists may be adapted for CSIRT work and processes.
In addition, investigate what similar organizations are doing to provide incident handling services or to organize a CSIRT. If you have contacts at these organizations, see if you can talk to them about how their team was formed. Take a look at other CSIRTs' web sites, and check their missions, charters, funding scheme, and service listing. This may give you ideas for organizing your team. Review any books or other publications about incident handling or CSIRTs. An initial list of resources can be found at the CERT CSIRT Development web page.
Attend courses or conferences that include sessions for developing
incident response strategies or creating CSIRTs. These venues can provide
you with opportunities to exchange ideas and interact with others in the
incident response field. A good place to start may be to attend the
annual FIRST conference.
Step 4: Design your CSIRT Vision
Step 4: Design your CSIRT Vision
As the information gathered brings to the forefront the incident response needs of the constituency and as you build your understanding of management expectations, you can begin to identify the key components of the CSIRT. This allows you to define the vision for the CSIRT and its goals and functions. You need both management and constituent buy-in and support of these goals and functions for the CSIRT to be successful.
It is important to achieve clear agreement on the definition and expectations for the CSIRT being formed. What the CSIRT staff thinks the team will do and what the managers and general constituency think the CSIRT will do may be completely different. A number of people have the perception that a CSIRT is a "cyber cop" for an organization or constituency. While this may be true for a small number of teams, it is not generally the main focus of a CSIRT. The main focus is to prevent and respond to incidents. The vision for the CSIRT must include a clear explanation of where these CSIRT functions fit into the current organizational structure and how the CSIRT interacts with its constituency. The vision explains what benefits the CSIRT provides, what processes it enacts, who it coordinates with, and how it performs its response activities.
In creating your vision, you should
Step 5: Communicate the CSIRT Vision
Communicate the CSIRT vision and operational plan to management, your constituency, and others who need to know and understand its operations. As appropriate, make adjustments to the plan based on their feedback.
Communicating your vision in advance can help identify process or organizational problems before implementation. It is a way to let people know what is coming and allow them to provide input into CSIRT development. This is a way to begin marketing the CSIRT to the constituency and gaining the needed buy-in from all organizational levels.
You may receive information that was missed or not available during the information-gathering stage. Use this information and input to make any final adjustments to the CSIRT organizational structure and processes.
Step 6: Begin CSIRT Implementation
Once management and constituency buy-in is obtained for the vision, begin the implementation:
A main resource you will need for your constituency is your incident-reporting guidelines. These guidelines define how your constituency interacts with your CSIRT, what constitutes an incident, what types of incidents to report, who should report an incident, why an incident should be reported, the process for reporting an incident, and the process for responding to an incident. They should be clear and understandable by the constituency being served.
The process for reporting an incident includes a detailed description of the mechanisms for submitting reports: phone, email, web form, or some other mechanism. It should also include details about what type of information should be included in the report.
The process for responding to an incident details how the CSIRT prioritizes and handles received reports. This includes how the person reporting an incident is notified of its resolution, any response timeframes that must be followed, and any other notification that occurs.
Step 7: Announce the CSIRT
When the CSIRT is operational, announce it broadly to the constituency or parent organization. It is best if this announcement comes from sponsoring management. Include the contact information and hours of operation for the CSIRT in the announcement. This is an excellent time to make available the CSIRT incident-reporting guidelines. You may also want to develop information to publicize the CSIRT, such as a simple flyer or brochure outlining the CSIRT mission and services, which can be distributed with the announcement. Some teams have held an open house or special celebration to announce the operational CSIRT.
Step 8: Evaluate the Effectiveness of the CSIRT
Once the CSIRT has been in operation for a while, management will want to determine the effectiveness of the team and use evaluation results to improve CSIRT processes and ensure that the team is meeting the needs of the constituency. The CSIRT, in conjunction with management and the constituency, will need to develop a mechanism to perform such an evaluation.
Information on effectiveness can be gathered through a variety of feedback mechanisms, including
It may be helpful to review previously collected information on the state of the constituency or organization before the implementation of the team. This information can be used as a baseline in determining the effect of the CSIRT on the constituency. Information collected for comparison may include
See section 2.2.4 of the Handbook for Computer Security Incident Response Teams for more information on evaluating the quality of CSIRT services.
Remember that Patience Can Be a Key
The length of time it will take to design, plan, and implement a team will vary with each organizational situation. We have seen CSIRTs become operational across a wide range of times, from two months to two years. It is important to realize that it can take about 12-18 months to work out the processes and procedures, especially for a large, distributed enterprise. After the team is operational, it can take another 12-18 months to obtain a good level of trust and comfort with your constituency. Many teams show a large growth in the number of incidents reported over their first year of operation. The longer you are in operation, the more your constituency will understand the work you are doing and the more likely that they will report to you.
Resources and More Information on Creating a CSIRT
The components discussed above are more fully discussed in the following:
These resources may provide additional insight:
Copyright 2002 Carnegie Mellon University
CERT® and CERT Coordination Center® are registered in the U.S. Patent and Trademark office.
Disclaimers and copyright information
Last updated February 27, 2006