Software Engineering Institute Carnegie Mellon

Organizational Models for Computer Security Incident Response Teams (CSIRTs)

[Abstract]   [Title Page]   [Preface]   [Acknowledgements]   [1 Introduction]  
[2 Establishing CSIRT Capabilities]   [3 Operational Issues]  
[4 Security Team--Using Existing IT Staff]   [5 Internal Distributed CSIRT]  
[6 Internal Centralized CSIRT]  [7 Combined Distributed and Centralized CSIRT]  
[8 Coordinating CSIRT]   [9 Choosing the Right CSIRT Model for Your Organization]  
[10 Closing Remarks]   [Appendix Summary of Services Offered]  [Bibliography]   [PDF File]

2 Establishing CSIRT Capabilities

2.1 Overview

There are many issues and questions that must be addressed for any organization to effectively create and implement a CSIRT or any type of incident management capability. High-level management needs to consider the following questions when deciding upon a CSIRT structure and function that best meets the requirements for their organization or constituency.

While the main focus of this handbook is on the various organizational models for implementing a CSIRT, this cannot be discussed in isolation. Other issues, such as the answers to all of the above questions, are variables that will influence the choice of a model. Most importantly the type of constituency, the chosen mission, and the provided services will play a large role in determining how the CSIRT structure or organizational model will need to be arranged. All of these issues will need to be kept in mind as you review the rest of this document.

2.2 Barriers in Establishing New Teams

Requirements for CSIRTs are just as diverse as the constituents and cultures they serve. Even so, many times organizations look to existing teams for "organizational" examples that might work in their own environments (see the next section). Our experiences in working with other teams and collecting general information on CSIRT structures and practices have helped us identify common team characteristics and practices that may be of assistance to those interested in formalizing a CSIRT capability.

Fundamental differences in mission, goals, and operations make it difficult to define one comprehensive blueprint for creating a CSIRT, although many newly forming teams would be satisfied to have any blueprint at all that could help them in their planning efforts. On the other hand, there are general problems that all new teams will face. For example, we find that

Without any knowledge about resources that exist, many teams have often had to undergo the same research and learning experience, pulling together the same information that others have already discovered, in an effort to learn how to create and operate their team.

Therefore, we believe that by collecting and providing at least some of the common information about suitable services, organizational structures, and supported constituencies in this handbook, we can make it much easier for the next generation of teams to become established. In turn, they will be able to concentrate on their own internal issues related to this process. As said before, this handbook will concentrate on organizational models. Other follow-on documents will need to be developed to cover other topics of interest to teams that can fill the gaps in the tools, techniques, and training mentioned above.

2.3 Using Existing Teams as Examples

The history of formalized CSIRTs, while only covering 15 years,3 shows that using existing teams as examples can be one of the best approaches for setting up new teams. In fact, prior to 1998--the year the Handbook for CSIRTs became available--no comprehensive document4 was available for interested organizations to learn about the challenges and tasks associated with establishing a CSIRT.

One of the most beneficial steps a newly forming team can take is to seek opportunities to meet other teams. These can include site visits (your site or theirs), events such as the annual Forum of Incident Response and Security Teams (FIRST)5 conference, and the regular meetings of regional groups such as the TERENA TF-CSIRT Task Force, a program to promote the collaboration between CSIRTs in Europe6 or the Asia Pacific Computer Security Emergency Response Team (APCERT), a coordination working group for CSIRTs in the Asia Pacific area.7 You can also learn about a specific team from information on that team's publicly available web site, if they have one. Many team's web sites have incident reporting forms, guidelines, procedures, and service lists that may provide ideas for your own team. If other teams share common characteristics with your particular situation, such as similar constituencies or organizational structures, their experience might be especially valuable to your success in planning and implementing your team. However, it is not always the case that a similar team will operate exactly the way your team does. In those cases you may not be able to use the other team's work as a starting point that you can then customize to match your needs.

As mentioned earlier, each CSIRT and the constituency the team serves is different; therefore understanding your constituency and their specific needs is key to determining your CSIRT goals, service offerings, and organizational structure. Any help you can obtain from other teams who went through a similar learning experience will help your plans move forward that much easier. Looking at or visiting similar organizations, identifying their operating characteristics, how they interact with their constituency, and where their CSIRT is located within the organizational structure of the host or parent organization or constituency will be of special interest to you in your planning processes.

Many teams are quite willing to accommodate requests to visit their team and share their experiences (both good and bad) in establishing their own team. They are also generally very supportive in providing resources or information concerning best practices or problem areas they have encountered. In addition, many existing teams consider it important for their day-to-day function to meet other teams, as any future interaction with those teams will facilitate communications, once they have established contact. Such meetings will help teams gain a better understanding of each other and build on an established means of communicating information.

One note of caution, however, is in order: There is no requirement that another team share information or experiences, so do not necessarily expect to receive copies of documents, policies, procedures, or tools. The other team might or might not have such information available, or they might be unable (or unwilling) to share them due to internal policies.

2.4 What's In a Name?

There are many abbreviations that have been used as the basis for team names, as well as characterizing what role the team has. For example,

Each of the above has been used with other descriptions, such as "Network," "Computer," "Security," "Computer Security," or "Information Technology." So we see as some sample names or titles

In addition, the service marked "CERT" (referring to the CERT® Coordination Center), has been used in combination with other letters8 by a variety of other teams to characterize their specific team9 and to build upon a well-established brand name. However, as already mentioned, while the names might be similar, the services offered, the fees, and the levels of support available might be quite different. Similarity in names also does not signify any endorsement or relationship between teams. The variety of names used by teams sometimes makes it difficult for users to understand what a team's position is or how they compare to other teams the user may know about.10

It should be noted also that currently11 there is no "requirement" that exists for naming a team, nor any over-arching authority that "certifies" that a CSIRT is, in fact, a bona fide CSIRT (and accepted as such). In practice, CSIRTs have gained acceptance through the reputation they establish over time and through the trust the team has earned from its constituency and from other external CSIRTs. It should also be noted that some CSIRTs are looking into more formal ways of certification and accreditation as a means of validating or benchmarking the quality of service provided to their constituency. This certification is being discussed for both the team and individual staff level.12

As a final note on naming conventions, we should also mention another set of acronyms for service providers, who provide contract "for fee" or membership services. Such contracts (agreements, memoranda of understanding, service level agreements) will detail the services to be provided, as well as the level at which these are offered by the provider. The names generally associated with such providers include but are not limited to

Another acronym is ISAC, which is Information Sharing and Analysis Centers. While MSSP, MSP, and ERS focus on helping individual organizations handle the technical aspects of any incident or attack, ISACs focus on the analytical task at a "sector" level (such as finance, critical infrastructure, telecommunication) to identify trends, risks, and associated mitigation strategies within the sector.

Whatever the naming convention used, it is important that the constituency understands what the CSIRT will (and will not) do in terms of the services it provides. It is also important for any CSIRT to be respectful and understanding of other teams and any services they provide (remembering that each may have different missions, goals, and resources, as we mentioned earlier in this document).

2.5 Defining the CSIRT Constituency13

The constituency to be serviced by the CSIRT, including its composition, physical or geographical location or distribution, and the sector in which it is located, will be a deciding factor in choosing an organizational model. A constituency that is composed of one organizational entity such as a commercial business, an educational institution, or a government department will have different organizational needs than a constituency composed of multiple educational institutions who collaborate in a research network or multiple government and critical infrastructure agencies within a country, or multiple national organizations within a region.

Some distinguishing organizational factors that can be used to identify a constituency include

2.6 Defining CSIRT Mission

The CSIRT mission15 should provide a brief, unambiguous description of the basic purpose and function of the CSIRT. This will outline the basic focus of the team, which could include any of the following: recovery of systems, analysis of attacks and intrusions, facilitation and coordination of response activities, coordination of information, investigation of computer crimes, monitoring of intrusion detection systems (IDS). Or it could include some other function specific to the CSIRT.

This mission, together with the CSIRT-provided services, will also influence what type of organizational model is needed. For example, if a team's mission is to actually perform system recovery and patching, then they will need to be able to access the site where the systems are located. If the mission is to only facilitate information exchange and perform analysis to look for trends and patterns in incident activity, then the CSIRT must have mechanisms in place to collect and analyze information from across the constituency. This in turn will require a mechanism for distributing information to the constituency.

2.7 Defining CSIRT Services

Another important issue to be addressed in establishing a CSIRT relates to the range and level of services to be provided to the constituency.

The original version of the Handbook for CSIRTs published in 1998 provided a list of common services that a team could provide.16 In that handbook, the only mandatory service required to be considered a CSIRT was the incident response service. This service definition has been expanded and is now referred to as incident handling,17 since the work done by a CSIRT is generally more than just "response."

Today the understanding of the services has matured, and the list of possible services that a CSIRT could provide has become larger and more structured. Provision of at least one of the incident handling services--incident analysis, incident response on site, incident response support, or incident response coordination--is still mandatory to be considered a CSIRT. This new, expanded list of services is outlined in the rest of this section and in the revised edition of the Handbook for CSIRTs that was published in 2003. It is also available as a separate web document from the CERT Coordination Center (CERT/CC) web site.18

There are a wide variety of services that a CSIRT could choose to offer. Some of the services offered will relate directly to incident handling as a core service of a CSIRT. Other services, such as security training or audits, may only relate indirectly to incident handling, while serving broader organizational security needs. By their very nature, some of the services may also be provided by other parts of an organization, such as IT, training, audits, or some other entity instead of the CSIRT. The actual assignment of tasks and responsibilities will depend on the structure of the parent or host organization in which the CSIRT is located.

Throughout the rest of this handbook we will draw upon this expanded list of services as we discuss which services are suited to which organizational model. For your reference and convenience, the list is included in this section.

A team should not expect to provide every service in the list. It is much better to perform a few services well than many services badly. Also the CSIRT must see where it fits in the constituency's organizational structure. What is provided will be based on what needs the constituency has. It will also be highly influenced by what computer security and incident response related functions are already being performed by existing departments or groups within the constituency.

CSIRT services can be grouped into three broad categories:

The services are listed in Table 1 and described in detail below.

Table 1: CSIRT Services by Category

Table 1: CSIRT Services by Category

Note that some services have both a reactive and proactive side. For example, vulnerability handling can be done in response to the discovery of a software vulnerability that is being actively exploited. But it can also be done proactively by reviewing and testing code to determine where vulnerabilities exist, so the problems can be fixed before they are widely known or exploited.

2.7.1 Reactive Services

Reactive services are designed to respond to requests for assistance, reports of incidents from the CSIRT constituency, and any threats or attacks against CSIRT systems. Some services may be initiated by third-party notification or by viewing monitoring or IDS logs and alerts.

Alerts and Warnings

This service involves disseminating information that describes an intruder attack, security vulnerability, intrusion alert, computer virus, or hoax, and providing any short-term recommended course of action for dealing with the resulting problem. The alert, warning, or advisory is sent as a reaction to the current problem to notify constituents of the activity and to provide guidance for protecting their systems or recovering any systems that were affected. Information may be created by the CSIRT or may be redistributed from vendors, other CSIRTs or security experts, or other parts of the constituency.

Incident Handling

Incident handling involves receiving, triaging,19 and responding to requests and reports, and analyzing incidents and events. Particular response activities can include

Since incident handling activities are implemented in various ways by different types of CSIRTs, this service is further categorized based on the type of activities performed and the type of assistance given as follows:

Incident analysis. There are many levels of incident analysis and many sub-services. Essentially, incident analysis is an examination of all available information and supporting evidence or artifacts related to an incident or event. This may include analysis of network, host, and application audit logs; intruder toolkits, malicious code, and any other supporting information. The purpose of the analysis is to identify the scope of the incident, the extent of damage caused by the incident, the nature of the incident, and available response strategies or workarounds. The CSIRT may use the results of vulnerability and artifact analysis (described below) to understand and provide the most complete and up-to-date analysis of what has happened on a specific system. The CSIRT correlates activity across incidents to determine any interrelations, trends, patterns, or intruder signatures. Two sub-services that may be done as part of incident analysis, depending on the mission, goals, and processes of the CSIRT, are

Incident response20 on site. The CSIRT provides direct, on-site assistance to help constituents recover from an incident. The CSIRT itself physically analyzes the affected systems and conducts the repair and recovery of the systems, instead of only providing incident response support by telephone or email (see below). This service involves all actions taken on a local level that are necessary if an incident is suspected or occurs. If the CSIRT is not located at the affected site, team members would travel to the site and perform the response. In other cases a local team may already be on site, providing incident response as part of its routine work. This is especially true if incident handling is provided as part of the normal job function of system, network, or security administrators in lieu of an established CSIRT.

Incident response support. The CSIRT assists and guides the victim(s) of the attack in recovering from an incident via phone, email, fax, or documentation. This can involve technical assistance in the interpretation of data collected, providing contact information, or relaying guidance on mitigation and recovery strategies. It does not involve direct, on-site incident response actions as described above. The CSIRT instead provides guidance remotely so site personnel can perform the recovery themselves.

Incident response coordination. The CSIRT coordinates the response effort among parties involved in the incident. This usually includes the victim of the attack, other sites involved in the attack, and any sites requiring assistance in the analysis of the attack. It may also include the parties that provide IT support to the victim, such as Internet service providers, other CSIRTs, and system and network administrators at the site. The coordination work may involve collecting contact information, notifying sites of their potential involvement (as victim or source of an attack), collecting statistics about the number of sites involved, and facilitating information exchange and analysis. Part of the coordination work may involve notification and collaboration with an organization's legal counsel, human resources, or public relations departments. It would also include coordination with law enforcement. This service does not involve direct, on-site incident response.

Vulnerability Handling

Vulnerability handling involves receiving information and reports about hardware and software vulnerabilities, analyzing the nature, mechanics, and effects of the vulnerabilities, and developing response strategies for detecting and repairing the vulnerabilities. Since vulnerability handling activities are implemented in various ways by different types of CSIRTs, this service is further categorized based on the type of activities performed and the type of assistance given as follows:

Vulnerability analysis. The CSIRT performs technical analysis and examination of vulnerabilities in hardware or software. This includes the verification of suspected vulnerabilities and the technical examination of the hardware or software vulnerability to determine where it is located and how it can be exploited. The analysis may include reviewing source code, using a debugger to determine where the vulnerability occurs, or trying to reproduce the problem on a test system.

Vulnerability response. This service involves determining the appropriate response to mitigate or repair a vulnerability. This may involve developing or researching patches, fixes, and workarounds. It also involves notifying others of the mitigation strategy, possibly by creating and distributing advisories or alerts.21 This service can include performing the response by installing patches, fixes, or workarounds.

Vulnerability response coordination. The CSIRT notifies the various parts of the enterprise or constituency about the vulnerability and shares information about how to fix or mitigate the vulnerability. The CSIRT verifies that the vulnerability response strategy has been successfully implemented. This service can involve communicating with vendors, other CSIRTs, technical experts, constituent members, and the individuals or groups who initially discovered or reported the vulnerability. Activities include facilitating the analysis of a vulnerability or vulnerability report; coordinating the release schedules of corresponding documents, patches, or workarounds; and synthesizing technical analysis done by different parties. This service can also include maintaining a public or private archive or knowledgebase of vulnerability information and corresponding response strategies.

Artifact Handling

An artifact is any file or object found on a system that might be involved in probing or attacking systems and networks or that is being used to defeat security measures. Artifacts can include but are not limited to computer viruses, Trojan horse programs, worms, exploit scripts, and toolkits.

Artifact handling involves receiving information about and copies of artifacts that are used in intruder attacks, reconnaissance, and other unauthorized or disruptive activities. Once received, the artifact is reviewed. This includes analyzing the nature, mechanics, version, and use of the artifacts; and developing (or suggesting) response strategies for detecting, removing, and defending against these artifacts. Since artifact handling activities are implemented in various ways by different types of CSIRTs, this service is further categorized based on the type of activities performed and the type of assistance given as follows:

Artifact analysis. The CSIRT performs a technical examination and analysis of any artifact found on a system. The analysis done might include identifying the file type and structure of the artifact, comparing a new artifact against existing artifacts or other versions of the same artifact to see similarities and differences, or reverse engineering or disassembling code to determine the purpose and function of the artifact.

Artifact response. This service involves determining the appropriate actions to detect and remove artifacts from a system, as well as actions to prevent artifacts from being installed. This may involve creating signatures that can be added to antivirus software or IDS. The main focus of this function is artifact remediation.

Artifact response coordination. This service involves sharing and synthesizing analysis results and response strategies pertaining to an artifact with other researchers, CSIRTs, vendors, and security experts. Activities include notifying others and synthesizing technical analysis from a variety of sources. Activities can also include maintaining a public or constituent archive of known artifacts and their impact and corresponding response strategies. The main focus of this function is the gathering and sharing of artifact intelligence.

2.7.2 Proactive Services

Proactive services are designed to improve the infrastructure and security processes of the constituency before an incident or event occurs or is detected. The main goals are to avoid incidents and to reduce their impact and scope when they do occur.

Announcements

This includes, but is not limited to, intrusion alerts, vulnerability warnings, and security advisories. Such announcements inform constituents about new developments with medium- to long-term impact, such as newly found vulnerabilities or intruder tools. Announcements enable constituents to protect their systems and networks against newly found problems before they can be exploited.

Technology Watch

The CSIRT monitors and observes new technical developments, intruder activities, and related trends to help identify future threats. Topics reviewed can be expanded to include legal and legislative rulings, social or political threats, and emerging technologies. This service involves reading security mailing lists, security web sites, and current news and journal articles in the fields of science, technology, politics, and government to extract information relevant to the security of the constituent systems and networks. This can include communicating with other parties that are authorities in these fields to ensure that the best and most accurate information or interpretation is obtained. The outcome of this service might be some type of announcement, guidelines, or recommendations focused at more medium- to long-term security issues. This service becomes almost an intelligence-gathering function. Coupled with lessons learned from live data, this can be a powerful service to provide.

Security Audits or Assessments

This service provides a detailed review and analysis of an organization's security infrastructure, based on the requirements defined by the organization or by other industry standards22 that apply. It can also involve a review of the organizational security practices. There are many different types of audits or assessments that can be provided, including

Obtaining upper management approval is required before conducting such audits or assessments. Some of these approaches may be prohibited by organizational policy. Some approaches may also have legal or regulator implications that must be taken into account. Activities crossing any kind of border, whether country, state, provincial, or some other geographic designation, may be subject to an entirely different set of laws. On the other hand, there may be strict legal compliance requirements that the CSIRT and parent organization need to meet, and these should be built into the audit or assessment criteria.

Providing this service can include developing a common set of practices against which the tests or assessments are conducted, along with developing a required skill set or certification requirements for staff that perform the testing, assessments, audits, or reviews. This service could also be outsourced to a third party contractor or managed security service provider with the appropriate expertise in conducting audits and assessments.

Configuration and Maintenance of Security Tools, Applications, Infrastructures, and Services

This service identifies or provides appropriate guidance on how to securely configure and maintain tools, applications, and the general computing infrastructure used by the CSIRT constituency or the CSIRT itself. Besides providing guidance, the CSIRT may perform configuration updates and maintenance of security tools and services, such as IDS, network scanning or monitoring systems, filters, wrappers, firewalls, virtual private networks (VPN), or authentication mechanisms. The CSIRT may even provide these services as part of their main function. The CSIRT may also configure and maintain servers, desktops, laptops, personal digital assistants (PDAs), and other wireless devices according to security guidelines. This service includes escalating to management any issues or problems with configurations or the use of tools and applications that the CSIRT believes might leave a system vulnerable to attack.

Development of Security Tools

This service includes the development of any new, constituent-specific tools that are required or desired by the constituency or by the CSIRT itself. This can include, for example, developing security patches for customized software used by the constituency or secured software distributions that can be used to rebuild compromised hosts. It can also include developing tools or scripts that extend the functionality of existing security tools, such as a new plug-in for a vulnerability or network scanner, scripts that facilitate the use of encryption technology, or automated patch distribution mechanisms.

Intrusion Detection Services

CSIRTs that perform this service review existing IDS logs, analyze and initiate a response for any events that meet their defined threshold, or forward any alerts according to a predefined service level agreement or escalation strategy. Intrusion detection and analysis of the associated security logs can be a daunting task--not only in determining where to locate the sensors in the environment, but collecting and then analyzing the large amounts of data captured. In many cases, specialized tools or expertise is required to synthesize and interpret the information to identify false alarms, attacks, or network events and to implement strategies to eliminate or minimize such events. Some organizations choose to outsource this activity to others who have more expertise in performing these services, such as managed security service providers.

Security-Related Information Dissemination

This service provides constituents with a comprehensive and easy-to-find collection of useful information that aids in improving security. Such information might include

This information can be developed and published by the CSIRT or by another part of the organization (IT, human resources, or media relations), and can include information from external resources such as other CSIRTs, vendors, and security experts.

2.7.3 Security Quality Management Services

Services that fall into this category are not unique to incident handling or CSIRTs in particular. They are well-known, established services designed to improve the overall security of an organization. By leveraging the experiences gained in providing the reactive and proactive services described above, a CSIRT can bring unique perspectives to these quality management services that might not otherwise be available. These services are designed to incorporate feedback and lessons learned based on knowledge gained by responding to incidents, vulnerabilities, and attacks. Feeding such experiences into the established traditional services (described below) as part of a security quality management process can improve the long-term security efforts in an organization.

Depending on organizational structures and responsibilities, a CSIRT may provide these services or participate as part of a larger organizational team effort.

The following descriptions explain how CSIRT expertise can benefit each of these security quality management services.

Risk Analysis

CSIRTs may be able to add value to risk analysis and assessments. This can improve the organization's ability to assess real threats, provide realistic qualitative and quantitative assessments of the risks to information assets, and evaluate protection and response strategies. CSIRTs performing this service would conduct or assist with information security risk analysis activities for new systems and business processes or evaluate threats and attacks against constituent assets and systems.

Business Continuity and Disaster Recovery Planning

Based on past occurrences and future predictions of emerging incident or security trends, more and more incidents have the potential to result in serious degradation of business operations. Therefore, planning efforts should consider CSIRT experience and recommendations in determining how best to respond to such incidents to ensure the continuity of business operations. CSIRTs performing this service are involved in business continuity and disaster recovery planning for events related to computer security threats and attacks.

Security Consulting

CSIRTs can be used to provide advice and guidance on the best security practices to implement for constituents' business operations. A CSIRT providing this service is involved in preparing recommendations or identifying requirements for purchasing, installing, or securing new systems, network devices, software applications, or enterprise-wide business processes. This service includes providing guidance and assistance in developing organizational or constituency security policies. It can also involve providing testimony or advice to legislative or other government bodies.

Awareness Building

CSIRTs may be able to identify where constituents require more information and guidance to better conform to accepted security practices and organizational security policies. Increasing the general security awareness of the constituent population not only improves their understanding of security issues but also helps them perform their day-to-day operations in a more secure manner. This can reduce the occurrence of successful attacks and increase the probability that constituents will detect and report attacks, thereby decreasing recovery times and eliminating or minimizing losses.

CSIRTs performing this service seek opportunities to increase security awareness through developing articles, posters, newsletters, web sites, or other informational resources that explain security best practices and provide advice on precautions to take. Activities may also include scheduling meetings and seminars to keep constituents up to date with ongoing security procedures and potential threats to organizational systems.

This awareness building may also include reports and briefings for management, to not only discuss the "state of the organization" in regards to computer security issues but also to educate management on the implications and effects of taking or not taking various security actions and precautions. This education will also include helping management understand security problems and mitigation strategies.

Education/Training

This service involves providing information to constituents about computer security issues through seminars, workshops, courses, and tutorials. Topics might include incident reporting guidelines, appropriate response methods, incident response tools, incident prevention methods, and other information necessary to protect, detect, report, and respond to computer security incidents. This service could also include training on specific types of incidents or vulnerabilities, as well as educating constituents about social engineering, SPAM, viruses, and virus hoaxes.

Product Evaluation or Certification

For this service, the CSIRT may conduct product evaluations on tools, applications, or other services to ensure the security of the products and their conformance to acceptable CSIRT or organizational security practices. Tools and applications reviewed can be open source or commercial products. This service can be provided as an evaluation or through a certification program, depending on the standards that are applied by the organization or by the CSIRT.

2.7.4 CSIRT Core Services

It is recommended that any team that wants to be considered a CSIRT start with a suitable subset of services that it can realistically support with existing resources and staff, gain the acceptance of the organization by providing those services in a quality manner, and then develop any further capabilities as other services are needed and can be effectively supported.

Although we mentioned that a CSIRT needs to provide (at a minimum) an incident handling service, in reality, most teams we see forming today provide much more. As a result, a baseline set of services has emerged that appears to be appropriate for initial consideration by any CSIRT.

This baseline set of services has been developed from resources such as the Handbook for CSIRTs, the collective knowledge and experience in incident response activities gained over the last decade by CERT/CC and many other teams, discussions with other CSIRTs, a review of available literature, and a pilot organizational survey of CSIRTs done as part of the research for the State of the Practice of CSIRTs report.

The base list of services is the services we commonly found being offered across CSIRTs. We are not saying that every CSIRT must provide these services; we are saying that we found in most teams that one or more of the following services were being offered. Therefore, for a team starting out, they may find that this list gives them an idea of what types of services they may want to consider. It is essential that the advertised set of services for a CSIRT be achievable with the available resources and skills, so deciding which set of services to initially offer must be done with care. As mentioned before it is better to offer a few services well than many services badly. A CSIRT that is thought to perform badly will find it very difficult and time-consuming to repair a negative opinion about their operations and their usefulness to their constituency. Poor performance and the resulting damage to the reputation, integrity, and trustworthiness of the CSIRT are often irreparable.

The baseline set of services consists of the following:

The core set of services offered by any team will be specific to their situation. Teams can offer any number of services in whatever combination they choose or are required to provide, but experience shows us that it is very difficult to claim to be a CSIRT and to not at least provide some form of the above reactive services related to the incident handling functions (incident analysis, response support, response on site, or response coordination).

2.7.5 Extending Service Offerings

Over time, there will inevitably be changes in the environment of any CSIRT, whether this is due to changes in funding, the staff working in the team, technology, or other external influences. In the same way, there are situations where changes will be actively pursued by the CSIRT itself to adjust its services and service levels, or more likely to extend its service offerings to address a newly recognized need.

Such service needs can be related to

It is also the case that a more market-oriented point of view can be taken. For example, from a business perspective, a CSIRT already providing services may see an opportunity to generate additional revenue by offering similar services to other subscribers or customers. Or an existing team may find that the activity within its constituency has changed and a new service is warranted. This could also be a situation where business considerations call for changes. A commercial CSIRT might expand its service availability to 24 hours a day, 7 days a week, 365 days a year instead of providing service for standard local business hours only.

Strategic considerations might also influence selection of services, e.g., striving for a specific market position nationally or internationally. As a final example, a commercial CSIRT seeking to be recognized for specializing in a type of service, such as automated security audits, might heavily market that capability.

These situations can be similar to some of the decisions you will face before actually building your CSIRT. You will need to assess the conditions, requirements, and options available and choose those services that best fit your situation.

In addition to how changes evolve to address business considerations, there are also a few "natural progressions" that have been observed in the evolution of a variety of CSIRT services. Remember as you read these, however, that some services may have no or very small economies of scale. This must be considered as you decide if you will expand your service offerings. For example, to take on services such as forensics analysis will require more staff, more time, more tools, and more training than may be available and these skills might not end up being used frequently. Meanwhile developing an advisory service may reach a broader audience with not as much investment.24

2.7.5.1 Building New Services on Existing Services

Many of the services mentioned throughout this handbook have similar requirements with regard to the necessary information, experience, and skills needed to provide a specific service. Understanding the interconnections between different services will greatly help to extend the range of services over time. The chances for the success of new services that build on existing services are higher, and the costs of ramping up such services can be lower.

Furthermore, the implied (or suggested) evolution of service offerings in the sections described below can also illustrate the benefits of providing services with close interconnections. Not only do the services benefit from each other in this evolution, but the same staff members involved with one service might also provide the other service(s) as well. But a word of caution must be made here: before adding or expanding services, you need to be sure that funding and staffing levels are appropriate. Staff cannot take on additional services without expanded funding and resources. Managers must be careful to avoid staff burnout and overstretching staff commitments. Staff must be available to handle incidents as they occur, and large-scale major events can require dedicated time and staff.

It is also important to note that changes in services might also mean that a change in organizational model is needed to adequately provide the new services. For example, a team might evolve from a local security team to a centralized or coordinating CSIRT.

Note: The arrow in the following titles implies that a CSIRT delivering the service on the left of the arrow can evolve into the service on the right of the arrow under the conditions discussed in each section. Also, these services could only evolve if there was adequate time available for the CSIRT to provide the new service and, of course, only with management approval.

Awareness Building --> Education/Training

To be successful, training must build on the achievement of general security awareness by the constituent population. Deficiencies in awareness can be identified through feedback received during training courses or as the result of constituency behavior that allows various computer security incidents to occur.

Since awareness building utilizes some of the approaches and mechanisms that are also used in education and training, a team providing awareness building has already established the foundation for more elaborate training sessions and an education program. All it needs is to formalize the coverage and the technical depth of the material. Some of the necessary infrastructure might already be available within other parts of the organization (e.g., IT, human resources, or a corporate training department).

Security Consulting --> Risk Analysis / Business Continuity

While security consulting in the general sense might deal with questions related to risk analysis or business continuity, at a CSIRT level it is much more likely that it relates specifically to some dedicated problem areas (remote access) or more practical security problems (firewall or host system configuration). Security consulting by a CSIRT can be provided based on the specific expertise available in the team, but the full-fledged risk analysis/business continuity planning and assessment, which addresses all technologies and applications used in the constituency, needs to build on a much more elaborate knowledgebase and practice as each of these areas have their own methodologies and frameworks. Risk analysis and business continuity planning (or disaster recovery planning) is usually done by specialists with skills and backgrounds in those areas.

For a CSIRT, the evolution to such a service may be much longer to achieve and may need to be carefully orchestrated, as staff will need to acquire these new skill sets and also to avoid unnecessary duplication of effort with whoever is currently performing these services in the organization. One way to migrate into providing such a service is to work collaboratively with those in the organization who have this background and skill set. The CSIRT, with its involvement in incident data collection, can provide authenticated risk data to the risk management process. They can also provide input into the security configurations most suited to the organization. In this way they can begin to work as part of the team that does provide the risk analysis and business continuity planning service. If no one in the organization is already providing these services, then the work done by the CSIRT can begin to fill this gap.

Vulnerability / Artifact Analysis and Response --> Security Audit and
Assessments Vulnerability / Artifact Analysis and Response --> Intrusion Detection

The knowledge gained from analyzing artifacts and vulnerabilities is important for providing robust security audits and assessments, as well as maintaining up-to-date intrusion detection configurations. In many cases, both services are looking at similar issues from different perspectives: Security audits look for new vulnerabilities and attacks that can compromise the security of systems from an attacker's point of view; intrusion detection does the same but from the defender's point of view.

Previously gained knowledge from the Vulnerability as well as Artifact Analysis and Response activities provides a natural progression for team members with this expertise to contribute to security audit and assessment initiatives and intrusion detection activities. It should be pointed out, however, that performing security audits and assessments requires a specific skill set and application of definitive techniques. CSIRT staff will probably not transition into these positions but rather provide information to the security audit and assessment functions, providing criteria and requirements in the security area that need to be reviewed and evaluated.

Vulnerability Analysis and Response --> Vulnerability Response Coordination

The coordination of efforts related to any response to new vulnerabilities requires an extensive knowledge of vulnerability analysis and response. The CSIRT must understand the situations that vendors face when a new vulnerability is identified in one of their products and have a long-term, trusted relationship with the vendor community.

Once a team undertakes vulnerability analysis and response, cooperation with vendors, other CSIRTs, organizational system, network, and security administrators, and other security experts will inevitably lead to a situation where such interactions need to be coordinated.

Product Evaluation --> Configuration and Maintenance of Security Tools/Applications/Infrastructure --> Development of Security Tools

The relationships between these three services are also dependent on the common knowledge and background for each.

Just the evaluation of specific products or of products belonging to a specific group of tools by itself will provide the constituency with useful information. Some of the knowledge gained through such product evaluations can serve to kick-start an extension of the service to the configuration and the maintenance of a specific product (one that is selected based on the evaluation).

The progression to the next level of service, and the development of new tools, generally has one of two goals:

  1. to solve weaknesses in existing products that should be mitigated
  2. to address gaps that should be closed and missing functionality that should be addressed

These goals build on knowledge gained through extensive experience with existing tools and products. Staff involved in delivering these services also require a background in secure programming practices and system architectures.

In summary, the above sections describing how services might evolve over time has been included as an illustration of ways in which CSIRTs might modify and extend their services as a team matures. As your new team is developing a strategy and becomes operational it might also be useful to consider how the team's services could potentially evolve over time. Such considerations in the early phases of your development and planning discussions will help to identify the infrastructure, tools, staff, and skill set that will be needed in the future to ensure that your CSIRT operations continue to effectively serve your constituency.

2.7.5.2 Building New Constituencies on Existing Services

Throughout this document we stress that the focus of any CSIRT service needs to be tailored towards the needs of the constituency, whether it be an organization or a group of many separate organizations. But it is also true that, once the CSIRT service is fixed for any constituency, other constituencies could be identified that have similar needs. Another progression in the evolution of a CSIRT could be that it provides a set of well-defined services to a different set of customers (or a completely new constituency).

There are some examples, such as the dCERT25 service offering, where a previously internal team started to provide a commercial service, taking advantage of their expertise and the established infrastructure. A key factor in dCERT's successful transition was the personnel or staff of the organization. Because the team members had experience based on their internal work, they were able to successfully transition to a wider commercial audience. It is important to note that in this example the commercial service created uses clearly outlined contracts that detail the service offerings and service levels associated with them.

It would be much more difficult to position a team from a commercial organization as the "national" team (for a region, country, etc.), since many of the stakeholders (constituents) involved could fear a conflict of interest. The situation might be viewed differently if the team is serving a large constituency and has already established a not-for-profit or neutral position.26

Any political issues need to be addressed before any migration towards new constituencies should be planned. From a team's business perspective it can certainly be advantageous to expand their scope of service delivery.

On the other hand, there are some arguments, against using the same team to serve different constituencies. Foremost is the potential conflict of interest--for example, even multinational organizations like Siemens prefer to have a clearly defined, internal team that is separate from the team that handles product vulnerabilities. This is done to avoid any possibility of such a conflict of interest. This is most significant when a CSIRT is providing for-fee services to external customers. In such a case, if there are two incidents, one involving internal systems, the other from an external customer, it is better that they are handled by separate teams. If an incident involved not only the systems of an external customer but also an internal system, the external customer might question the neutrality of the CSIRT feeling that they may favor or protect the internal customer over the external customer. More than that, such a situation could present a legal conundrum with respect to negligence and disclosure.

The key factor for any CSIRT that considers adding new constituencies to its already existing base constituency (this is also true for any service changes) is that the team must fulfill all requirements for and provide suitable interfaces with any supported constituencies. This requires careful planning and may also require additional resources. The CSIRT must also look at its existing organizational model and determine if that structure will adequately support the new additional constituency. If not, then a different model may be appropriate and may need to be implemented.

1 For more information, see http://www.cert.org/certification/.

2 For more information, see http://www.giac.org/subject_certs.php#GCIH.

3 As of the date of this publication.

4 Certainly there were already papers that highlighted specific issues, but no single document covered the breadth of information related to creating and operating a new team.

5 See http://www.first.org/ for more information regarding the Forum of Incident Response and Security Teams. Past conference programs (as well as conference materials, papers, and presentations since 2000) are available, along with information on upcoming events. The annual conference is generally held in June each year.

6 See http://www.terena.nl/tech/task-forces/tf-csirt/ for more information. Past meeting minutes and presentations are available, as well as information on upcoming meetings.

7 See http://www.apcert.org/ for more information.

8 Use of "CERT" requires permission from the Software Engineering Institute. To obtain permission, submit your request here permission form.

9 See the FIRST Teams Member List at http://www.first.org for examples of different CSIRT names.

10 To some extent we are similarly guilty, as the terminology we introduce in the rest of this document is not yet well established within the CSIRT community. However, we have selected these conventions because we believe they more precisely describe the roles of the different team models.

11 It is certainly possible that in the future some teams will have naming requirements.

12 Information about existing certification programs for incident handlers can be found in the CERT State of the Practice of CSIRTs report [Killcrece 03].

13 See the Handbook for CSIRTs [West-Brown 03] and the State of the Practice of CSIRTs for more detailed information on CSIRT constituencies.

14 "Internal" and "external" in this context only refers to the relationship the CSIRT has with the constituency. It does not have anything to do with who the CSIRT communicates with.

15 See the Handbook for CSIRTs for more information about defining the CSIRT mission.

16 Originally the list was presented on page 20. Since that time, the Handbook for CSIRTs has been updated and now provides a revised and expanded set of services that matches what is presented in this section.

17 "Incident handling" is used in the CSIRT Services List [Killcrece 02].

18 In an effort to consolidate CSIRT service terminology, the Trusted Introducer service for CSIRTs in Europe worked with the CERT CSIRT Development Team in 2002 to produce this updated and more comprehensive list of CSIRT services. It can also be found at http://www.cert.org/csirts/services.html.

19 Triaging refers to the sorting, categorizing, and prioritizing of incoming incident reports or other CSIRT requests. It can be compared to triage in a hospital, where patients who need to be seen immediately are separated from those who can wait for assistance.

20 Note that "incident response" is used here to describe one type of CSIRT service. When used in team names such as "Incident Response Team," the term typically has the broader meaning of incident handling.

21 Other CSIRTs might further redistribute these original advisories or alerts as part of their services.

22 Industry standards and methodologies might include: Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE), CCTA Risk Analysis and Management Method (CRAMM), Information Security Forum's Fundamental Information Risk Management (FIRM), Commonly Accepted Security Practices and Regulations (CASPR), Control Objectives for Information and (Related) Technology (COBIT), Methode d' Evaluation de la Vulnerabilite Residuelle des Systemes d'Informa (MELISA), ISO 13335, ISO 17799, or ISO 15408.

23 It is important to note that this only refers to accepting information about vulnerabilities and passing that information along to another group or team for further investigation, response, analysis, and other support. It is a very basic handling of the information to facilitate dissemination to the appropriate individuals.

24 Certainly there are and will continue be other migration paths besides CSIRT services that can change the focus of a team (from traditional incident handling services to a more research or analysis-related work, or coordination capability); but they are not covered here. These other services will, of course, also be dependent on the knowledge and expertise readily available within or obtainable by the CSIRT.

25 dCERT started as internal CSIRT team within DaimlerBenz, later DaimlerChrysler, and is now a commercial service offering from T-Systems ISS GmbH, Germany. See http://www.dcert.de for more information.

26 Such evolutions (from a commercial team to a national team) are theoretically possible, but we are not aware of any real-life examples.

 

[Abstract]   [Title Page]   [Preface]   [Acknowledgements]   [1 Introduction]  
[2 Establishing CSIRT Capabilities]   [3 Operational Issues]  
[4 Security Team--Using Existing IT Staff]   [5 Internal Distributed CSIRT]  
[6 Internal Centralized CSIRT]  [7 Combined Distributed and Centralized CSIRT]  
[8 Coordinating CSIRT]   [9 Choosing the Right CSIRT Model for Your Organization]  
[10 Closing Remarks]   [Appendix Summary of Services Offered]  [Bibliography]   [PDF File]