Organizational Models for Computer Security Incident Response Teams (CSIRTs)
[2
Establishing CSIRT Capabilities]
[4
Security Team--Using Existing IT Staff]
[6
Internal Centralized CSIRT]
[8
Coordinating CSIRT]
[10 Closing Remarks]
1 Introduction
When computer security problems occur, it is critical for the affected organization to have a fast and effective means of responding. The speed with which the organization can recognize an incident or attack and then successfully analyze it and respond will dramatically limit the damage done and lower the cost of recovery. Careful analysis of the nature of the attack or incident can lead to the implementation of effective and widespread preventative measures and the avoidance of similar events. This ability to respond quickly and effectively to a computer security threat is a critical element in providing a secure computing environment.
One way to provide such a response is through the establishment of a formal incident response capability. This response capability can be in the form of comprehensive policies and procedures for reporting, analyzing, and responding to computer security incidents. It can also be in the form of an established or designated group that is given the responsibility for handling computer security events. This type of group is generally called a Computer Security Incident Response Team (CSIRT). Focusing a team on incident handling activities allows them to further develop expertise in understanding intruder trends and attacks, along with acquiring knowledge in incident response methodologies. Depending on the services provided, the team can be composed of full-time or part-time staff.
A CSIRT provides a single point of contact for reporting computer security incidents and problems. This enables the team to serve as a repository for incident information, a center for incident analysis, and a coordinator of incident response across an organization. This coordination can extend even outside the organization to include collaboration with other teams, security experts, and law enforcement agencies. The team's relationships with other CSIRTs and security organizations can facilitate sharing of response strategies and provide early alerts to potential problems. As a focal point for incident information, a CSIRT can gather information from across their organization, gaining insight into threats against the constituency that might not have been apparent when looking at individual reports. Based on this information, they can propose strategies to prevent intruder activity from escalating or occurring at all. They also can be a key player in providing risk data and business intelligence to the organization, based on the actual incident data and threat reports received by the CSIRT. This information can then be used in any risk analysis or evaluation.
Having an experienced team established, with defined incident handling procedures in place, can jump start the response process. There is no need to determine who in an organization does what, as there is a team already in place knowing what to look for, who to contact, and how to affect the response as quickly as possible. CSIRTs located at constituency sites may also have familiarity with the compromised systems and therefore be more readily able to coordinate the recovery and propose mitigation and response strategies.
Depending on its mission and goals, a CSIRT can be structured and organized to provide a range of services in a variety of ways. Of key importance in deciding what types of services to offer will be the type of expertise available and the type of incident handling capability already in place in an organization. Environmental variables, such as organization and constituency size, available funding, and geographic distribution, can also affect the range and level of services provided by a CSIRT. A small, centrally located organization will require a CSIRT that is different from that required by a large, geographically dispersed organization.
Some CSIRTs provide a full set of services, including incident analysis and response, vulnerability1 handling, intrusion detection, risk assessments, security consulting, and penetration testing. A variety of these full-service teams can be found in the commercial sector. Other CSIRTs provide a smaller set of services. For example, the main service provided by some military organizations is intrusion detection, while some government organizations provide only a referral service, referring incidents to third-party teams. Some teams act as only a central repository to collect reported incident activity. Others act as that central repository and also disseminate any information on new vulnerabilities and intruder trends.
A CSIRT can also be organized as a coordinating CSIRT or coordination center rather than a one-on-one incident response service. In this case, the CSIRT provides information and support to constituent sites at different geographic or organizational locations. These sites can be branches of an organization located in various cities, states, or countries, such as the U.S. Military CSIRTs who coordinate with DOD-CERT,2 or they can be different independent organizations, such as the member organizations that subscribe to Australian Computer Emergency Response Team (AusCERT) services. These two examples illustrate the different ways that a coordinating CSIRT can work. In the case of DOD-CERT, the team has some authority to enforce some response and mitigation steps across the military. In the case of AusCERT, they have no direct authority over their constituent members but instead provide support, advice, information, alerts, and guidance to those member organizations. In either case, the coordinating CSIRT synthesizes reports and information from all areas to determine the accurate picture of incident activity across the constituency and its vulnerability to attack.
1.1 Scope of the Document
The purpose of this document is to present a variety of organizational options or models for a CSIRT structure. This report is not designed to be a how-to manual; rather it is a tool to help project managers make informed decisions in the critical early phases of planning their CSIRT capability. This document attempts to illustrate the various issues regarding each option and highlight the decisions that organizations will face when choosing a model.
It should be pointed out that this document only addresses one view of a CSIRT structure, namely, the "organizational" view in regards to the location of the CSIRT staff. There are many other views that can be looked at when determining a CSIRT structure, including how the CSIRT fits into existing business functions and decisions, what sector3 the CSIRT is part of, or even what mission a CSIRT has. This document does not address these other views, but they are interesting topics for future discussion and publication.
Regarding the decision-making capability and authority of a CSIRT, this document does not discuss how the CSIRT will interact with the business management side of any organization. Depending on the organization and the situation, it is often business factors rather than security factors that will determine what response occurs and at what priority. We do not try to address this at any depth in this document.
Once you have identified a model that best suites your situation, we highly recommend that you follow the guidelines presented in the Handbook for CSIRTs [West-Brown 03] to identify the next steps necessary to implement the decision. By being informed and prepared, the management team can focus their energy and resources appropriately and minimize the time and effort associated with building a solid foundation for an effective CSIRT within the organization.
Another document that may be helpful in building or sustaining a CSIRT is State of the Practice of CSIRTs [Killcrece 03]. This report provides examples of CSIRT processes, structures, and resources.
1.2 Intended Audience
Like the Handbook for CSIRTs, this handbook is a response to observations that many more organizations have recognized the need for a CSIRT. This document is therefore targeted at those who will be most heavily involved in the establishment and strategic direction of CSIRTs, including the decision of which organizational model should be used.
The primary audience for this document consists of managers who are responsible for the creation of a CSIRT or the creation of an incident handling service. The secondary audience consists of managers who are responsible for the operation of a CSIRT or an incident handling service and who would either like to benchmark their original CSIRT organizational structure against the models or who are looking to potentially reorganize their CSIRT structure and want to understand the considerations and issues involved with each model.
As well as being a useful reference for higher management levels and all CSIRT staff, this document can also be of use to other individuals who interact with CSIRTs and would benefit from an awareness of the issues that affect the organizational setup of any CSIRT. These would include
- members of the CSIRT constituency
- representatives from law enforcement
- representatives from media relations
- representatives from legal counsel
- others parts of the parent organization, including the information technology (IT) department, physical security area, human resources, and any investigative or auditing groups
1.3 Use of this Document
Ideally this document should be used once an organization has obtained management support and approval to form a CSIRT, but prior to the decision of which organizational structure to implement and before the team becomes operational. The document can also be of benefit in the development of any proposals for requesting support, approval, or funding to develop a CSIRT. This material can be used as the basis for understanding the issues involved in selecting a specific organizational structure or configuration for a CSIRT. The information can then be used to assist the development of detailed domain- or organization-specific operational model. This will serve in turn as a foundation to the further development of tailored and detailed service definitions, policies, and procedures.
In addition, members of an existing team can use this document to ensure that they have covered the main issues and options in selecting an organizational structure appropriate for their constituency or team.
It is important to note that this material is provided as a reference or guide for identifying an appropriate organizational model and corresponding services. We do not intend to imply or dictate the range or content of services that any given team should implement. These must be determined on a per-team basis and might even involve combining ideas from the different models presented later in this document to meet a specific team's needs. We encourage you to use the material provided in this document to understand the issues appropriate for your team's unique environment and decide which approach you should adopt based on your particular goals, needs, and situation.
Chapter 9 of this handbook has been developed as a guide to help you identify what type of CSIRT model may fit your situation. You may want to look at that section before reading about any particular model. Or you may want to read all the model descriptions and see which model best suits your organization.
1.4 Document Structure
The rest of this document is organized as follows:
1 A vulnerability is the existence of a flaw or weakness in hardware or software that can be exploited, resulting in a violation of an implicit or explicit security policy.
2 DOD-CERT is the coordinating CSIRT for the U.S. military.
3 "Sector" in this context means in what business area a CSIRT belongs, such as an educational, government, military, critical infrastructure, or commercial organization.
[2
Establishing CSIRT Capabilities]
[4
Security Team--Using Existing IT Staff]
[6
Internal Centralized CSIRT]
[8
Coordinating CSIRT]
[10 Closing Remarks]