State of the Practice of Computer Security Incident Response Teams (CSIRTs)

Our examination of the literature identified a few broad-based observations that will be of interest to new and existing CSIRTs. This information can be used to further increase their overall knowledge and understanding of incident handling, team responsibilities, team composition, techniques and procedures, and policy issues.

• There is a growing base of anecdotal and case study information appearing in print about not only the formation and organization of CSIRTs, but also the general types of activities these teams undertake and how they perform them.
• More information is available about the management and costs related to building and operating incident response teams.
• There are some common functional processes for performing incident handling activities in a CSIRT. Even if these processes are grouped somewhat differently in the articles and publications discussed in this technical report, the basic processes revolve around the following tasks: prepare/protect, detect, respond, improve. See Section 3.7.7 for more detailed information.
• There are many similarities in CSIRT processes; however, in the day-to-day operations of a CSIRT, the way in which these processes are implemented and the depth and breadth of the services that are provided may be very different.

Based on (a) our collective experience, (b) the reviewed literature, web sites, and CSIRT project information, and (c) the collected survey data, we see the current state of the practice for CSIRTs as follows:

• All evidence points to a large growth in the number of incident response teams over the past four to five years. This growth has primarily taken place in the commercial sector. Growth in education and government teams has also continued. Others seeking to create CSIRTs include organizations in critical infrastructures such as the finance/banking and power/energy sectors. Globally we are seeing more interest in implementing CSIRTs, especially national and local government teams.
• The reasons for the growth in teams include (a) the increase in the number of security incidents and the recognition of a need for a planned response, (b) new legal requirements, and (c) the current view that computer security must be proactive to be successful; being reactive is no longer sufficient.
• Incident handling and incident response teams are still relatively new areas in computer security, and incident response is still an immature field. Because of this there are few standards for incident handling methodologies or processes that are widely adopted, although there are many projects currently in progress that are attempting to gain acceptance and establish some standard mechanisms.
• Because of the newness of this field there is also no consistent structure or set of services for a CSIRT. The nature of incident response makes it imperative that a team match the goals and objectives of its constituency or parent organization. This means the services offered and the structure of the CSIRT must be set up to support those being served. The majority of teams do, however, offer some form of incident handling, development of security policies, and development of alerts and advisories.
• There is no commonly used taxonomy for incident response and computer security terminology. This can cause confusion when teams share data that has the same classification name, but which may represent different things.
• Employees who are trained and experienced in incident response techniques and practices are difficult to find.
• No established education path for CSIRT professionals exists as of today. Many incident handling activities have evolved out of traditional system, network, and security administration. Various training courses, as well as mentoring by experienced CSIRT members, is what is currently available today to help educate incident handling staff. There are also certification programs, but none has been adopted as a standard.
• There is a lack of publicly available sample templates for policies and procedures for use in the day-to-day operations of a CSIRT.
• Few tools such as tailored help desks or trouble ticket solutions addressing the specific needs of CSIRTs--authenticity and confidentiality, as well as workflows--are readily available.

It has also been observed that CSIRT best practices do not currently exist in the following areas:

• standards for interfaces--a team's location within the organization, with whom they interact (internally and externally), what is reported, how that occurs, etc.
• data management--how teams manage, access, archive, and share their CSIRT data
• professional standards--the formal or official specification for what a CSIRT comprises and the staff who perform the work

In the CSIRT community as a whole, there is general agreement that standards are needed and that some minimal support is needed for automating incident tracking, response, and analysis.¹⁴⁸

There are various projects and discussions currently under way that address many of these issues. Critical and relevant discussions include

• incident data exchange: how to develop and utilize a common and easy-to-use mechanism to allow sharing of data between teams and synthesis of collected data
• trusted introducers: what type of mechanisms are needed to help identify and verify teams
• operational coordination: what types of mechanisms for incident handling coordination between various geographic areas and groups of CSIRTs in order to quickly control and contain incident activity, share expertise, analysis, and data, and then effect a coordinated response
• formalization of procedures and formats: what types of standards are appropriate and can be applied to teams. Various standards are currently being sought by the community in all areas, from common incident tracking systems to advisory preparation and data collection and exchange.
• requirements for establishing a CSIRT capability: Teams are looking for methods to evaluate their effectiveness. They want to baseline their operations and services against a set of basic requirements and best practices.
• vulnerability disclosure: How, when, and to what extent to disclose vulnerability information has been a highly volatile topic in the incident response and computer security community. Various discussions are underway to determine if there can be any agreed-upon standards or processes in this area.
• certification and training: What types of training and certification should a member of an incident handling team should be required to have? Many teams are struggling with these issues today, along with the fact that just finding skilled incident handlers is not an easy task.

As previously mentioned throughout this report, each of the above depends on a variety of factors, such as the mission or role of the CSIRT and its constituency, along with its organizational structure, funding, and staffing. Because of this, it may not be possible to set standards that every CSIRT would be able to follow. In a general sense, however, some "best practices" should be possible across many CSIRTs--even if the specific implementation for how the practice is performed is different. For example, from our observations and experience, we can generally agree that, to be effective, CSIRTs require the following:

• management support and trust from their constituency
• a plan in place for handling incidents when they occur
• established relationships with a variety of others as appropriate (e.g., constituent members, other CSIRTs, management, law enforcement)
• capable staff who are well trained and knowledgeable in the activities being handled by the team to provide effective response
• a consistent and repeatable process for CSIRT operations in receiving, accessing, and archiving data (including sharing information as appropriate)

© 2008 Carnegie Mellon University