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]

3 Operational Issues

3.1 Overview

Along with the issues discussed in Chapter 2, there are many operational issues that will need to be addressed or considered when establishing a CSIRT capability. The primary focus of this document is the organizational model or operational structure of the team. This involves the physical location of the team, the place of the team in the parent organization or constituency, and how the CSIRT interacts with the rest of the constituency. It can also involve who the CSIRT reports to in the organization, the authority of the CSIRT within the constituency, and the way information flows into and out of the CSIRT.

3.2 Common Organizational Models for CSIRTs

In Chapters 4 through 8 of this document, five generic organizational models for a CSIRT are presented. These models are briefly described below.

Security Team:¹ In this model, no group or section of the organization has been given the formal responsibility for all incident handling activities. No CSIRT has been established.
Available personnel, usually system, network or security administrators, at the local or division level handle security events on an ad hoc and sometimes isolated basis as part of their overall responsibilities or job assignments. Incident response efforts are not necessarily coordinated or standardized across the organization. There may be no group or designated individuals available to gather information across the organization to scope the damage or impact of incident activities, analyze trends, report to senior management, or provide either effective recovery or protective steps. This is a "business as usual" approach and provides only very limited and unpredictable reactive incident handling capabilities.

Internal Distributed CSIRT: In this model, the organization utilizes existing staff to provide a "virtual" distributed CSIRT, which is formally chartered to deal with incident response activities.
There is a manager who oversees and coordinates activities for the distributed team. Across the organization, individuals are identified as the appropriate points of contact for working as part of the distributed team based on their expertise with various operating-system platforms, technologies, and applications; or based on their geographic location or functional responsibilities. The distributed team members can perform CSIRT duties in addition to their regular responsibilities or could be assigned to CSIRT work on a full-time basis.

The CSIRT serves as the single point of contact into the organization in relation to incident or vulnerability reports or activity for both internal and external parties.

Internal Centralized CSIRT: This model is a fully staffed, dedicated CSIRT that provides the incident handling services for an organization.
In many cases team members spend 100% of their time working for the CSIRT; however, this type of model could also be provided using part-time staff on a rotation basis. There is a CSIRT manager who reports to high-level management such as a chief information officer (CIO), chief security officer (CSO), or even chief risk officer (CRO) or some other equivalent manager. The team is centrally located in the organization and is responsible for all incident handling activities across the constituency or enterprise.

The CSIRT serves as the single point of contact into the organization in relation to incident or vulnerability reports or activity for both internal and external parties.

Internal Combined Distributed and Centralized CSIRT: This model represents a combination of the distributed CSIRT and the centralized CSIRT. It maximizes the utilization of existing staff in strategic locations throughout the organization with the centrally located coordinating capabilities of the dedicated team to provide a broader understanding of the security threats and activity affecting the constituency within the enterprise.

The CSIRT serves as the single point of contact into the organization in relation to incident or vulnerability reports or activity for both internal and external parties.

Coordinating CSIRT: In this model the CSIRT coordinates and facilitates the handling of incidents across a variety of external or internal organizations, which could include other CSIRTs. The CSIRT can be a coordinating entity for individual subsidiaries of a corporation, multiple branches of a military organization, institutions in a research network or specific domain, or for various organizations within a particular country or state. Coordinating CSIRTs usually have a broader scope and a more diverse constituency.

What makes this model unique is the set of services provided and how they are tailored towards helping other organizations deal with incident handling issues. Very often coordinating CSIRTs have no authority over the members of their constituency. Their main function is to provide incident and vulnerability analysis, support, and coordination services. They can distribute guidelines, advice, warnings, and recommended mitigation and recovery solutions.

Some organizations may find that they actually fall between two models or that their organization comprises multiple levels of CSIRT-related functions and actually encompass more than one model.

3.3 Other Issues

As previously mentioned there are other operational issues besides the organizational model that must be taken into account when establishing CSIRT capabilities. These factors will also influence the required organizational model and will affect the success level of any CSIRT.

3.3.1 Triage

Triage is the process of sorting, categorizing, and prioritizing 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.

Triage is an essential element of any CSIRT. It is on the critical path for understanding what is being reported throughout the organization. It serves as the vehicle by which all information flows into the CSIRT. Triage allows for an initial assessment of an incoming report and queues it for further handling. The triage function provides an immediate snapshot of the current status of all activity reported to the CSIRT--what reports are open or closed, what actions are pending, and how many of each type of report has been received. Triage provides an overview of activity being reported to the CSIRT. This process can help to identify potential security problems and help to prioritize the CSIRT workload. Information gathered during triage can also be used to generate trend information and statistics for upper management.

The triage process is important for providing an understanding of the scope of the reported incident activity. Depending on how the organization is physically and geographically structured, triage can be provided various ways:

If the constituency is distributed in nature, each geographic area, division, or department can provide a help desk or incident response hotline to receive requests from that area (this may also include a special email alias for receiving email requests). In this method, the team members at the distributed site do the initial triage of the requests and reports. They also ensure that all requests are forwarded to a central tracking database so that all reports can be synthesized, correlated, and analyzed.

Another method of providing this function might be to have all incident reports come into the CSIRT, itself. In this approach, the CSIRT receives all incident and vulnerability reports directly. There is a specific CSIRT email alias, phone number, or web form for reporting incident activity. The CSIRT has its own hotline or help desk for the enterprise, staffed with members from the team. This staff receives, categorizes, and initially prioritizes all phone, email, and web reports and requests. Incident reports or vulnerability reports are passed on to appropriate CSIRT analysts for handling.

A third method could be to have triage performed separately from the CSIRT. In this structure, the CSIRT works very closely with an enterprise-wide help desk. Help desk personnel serve as the funnel through which all information flows, but they are not part of the CSIRT. As the focal point for the initial collection, sorting, assignment, and tracking of reports, the help desk takes requests by phone, email, or web form. For the help desk to be successful in this activity the constituency must be given clearly defined guidelines for reporting and the help desk staff must be well trained to recognize and pass on security issues and problems to the CSIRT. The help desk staff also need to fully understand any information disclosure policies and must be able to be trusted to handle sensitive information properly.

For this triage model to work correctly, help desk personnel need to understand the services provided by the CSIRT and need to know when to seek assistance from CSIRT members. The CSIRT must be able to work closely with the help desk staff to review or reassign trouble reports to the appropriate individuals in the CSIRT for follow-up. The CSIRT will also require access to the help desk database. CSIRT staff (along with help desk personnel) need to be able to review trouble reports, modify those reports with updated information, open new reports, reassign reports, and close or reopen reports. Any information that is deemed confidential or sensitive may need to be stored in a different database or archived with access restricted to CSIRT staff. A secure communications mechanism between these two entities will also be needed.

Whatever approach is used, it is important to have widely distributed guidelines for reporting incident activity to the CSIRT. These guidelines should be available to all staff via an internal web site or similar function. It is important that the constituency clearly understand the organization's security policies and procedures; all users must understand the importance of reporting attacks, viruses, and any other suspicious or abnormal activity to the CSIRT. There must be no fear of retribution or repercussions for reporting activity. The key to success here is to establish an environment where individuals want to report suspicious activity. If they have a fear of reporting because of a perceived negative effect they will not report to the CSIRT. Some teams have implemented anonymous reporting to specifically address these types of concerns.

Because the centralized reporting and triage processes provide a way to coordinate the collection of information, it is possible to know what type of activity is being observed or reported across the organization. The CSIRT can therefore identify in a more efficient and timely manner whether critical system and network services are being attacked and act accordingly.

When creating and implementing a CSIRT, the method by which triage will occur will need to fit the operational and organizational needs of the constituency. This will be another decision to be made as a part of the implementation process.

3.3.2 Authority

Authority describes the control that the CSIRT has over its own actions and the actions of its constituents related to computer security and incident handling activities. Authority is the basic relationship the CSIRT has to the organization it serves.

According to the Handbook for CSIRTs, there are three distinct levels of authority that a CSIRT can have with its constituency: full, shared, and none.

Full authority: If a CSIRT has full authority, it can direct the constituency to perform the actions or response steps necessary to enhance the organization's security posture or to recover from an incident. During a security event, if warranted, the CSIRT can make the decision to take action without waiting for approval from higher level management. For example, with full authority a CSIRT can tell system administrators to disconnect systems from the network during an attack, or can isolate the systems themselves.

Shared authority: If the CSIRT has shared authority, it works with the constituency to influence the decision-making process concerning what actions should be taken. The CSIRT can influence the outcome of the decision, but it is a participant in the decision-making process, rather than the decision maker. In this case the CSIRT can recommend that systems be disconnected from the network during an attack and discuss actions to be taken (or repercussions if recommendations are not followed) with the rest of the constituency.

No authority: If a CSIRT has no authority, it can only act as an advisor to the organization (albeit a very strong advisor). The CSIRT cannot make any decisions or take any actions on its own. The CSIRT can recommend that systems be disconnected during an attack but it would not have a vote in the final decision. However, its role can be to raise the security implications that would result if its recommendations are not followed. The CSIRT may be able, because of its position and reputation in the organization, to influence the decision makers to act for the overall good of the organization.

Another type of authority highlighted in the Handbook for CSIRTs is "indirect authority." In this case, the CSIRT due to its position may be able to exert pressure on the constituent to take a specific action. An ISP for example may be able to strongly encourage its constituents to take a specific action or face discontinuation of Internet services.

The Handbook for CSIRTs also mentions some services that might not be possible if the CSIRT has no authority over its constituency.² Although the topic of authority is not considered in detail for the various models described here, such potential conflicts are highlighted. Some model descriptions do include a brief discussion of the suggested authority required for the model to work effectively.

For a CSIRT to be successful in its mission, it is critical that management approves and supports the level of authority that the team will have. Otherwise, the team will lose credibility in the organization and will not be successful. Management should also adequately and clearly convey the CSIRT authority to the constituency--particularly division managers, system and network administrators, and any other groups within the organization (e.g., IT departments, public relations, legal counsel, other management staff) that would be affected by any decisions made by the CSIRT.

Please note that in regards to the decision-making capability and authority of a CSIRT, this document does not describe 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, not security factors, that determine what response occurs and at what priority. We do not address this at any depth in this document. But anyone planning a CSIRT will need to take this issue into consideration.

3.3.3 Existing Teams in an Organization

In addition to issues related to identifying the best place for the CSIRT within the organization (its organizational position and reporting relationships), the existence of any other team(s) or group(s) already involved and performing incident handling tasks will need to be addressed to avoid any conflicts and to ensure that the constituency clearly understands the roles and responsibilities of each group.

If, for example, a different team in the organization is already handling computer virus incidents, then it is essential to consider this team or group and how it will interrelate to any new CSIRT team established in the organization. Options could include the virus-handling functions being absorbed by the new CSIRT or the virus-handling team, itself, becoming part of the CSIRT. Another option might be to keep the virus-handling team as a separate entity and have the CSIRT concentrate on other types of security problems and intruder activity. This last option would still require coordination between the two groups to ensure that all relevant activity is reported to the right team.

Whatever option is chosen, policies, processes, and procedures will need to be established that detail how these two teams will work together, including what information is shared between the two, what type of assistance each can provide to the other, and what type of notification (if any) occurs between the two concerning any ongoing incident event or activity.

Experience shows that if care is not taken to develop the correct synergy, conflicts may (and often do) occur that will affect future relationships, not only between the existing teams/groups, but also with the constituency that is being served. This can negatively impact any CSIRT. It is very important to get the support and buy-in from any other teams or groups involved in handling incidents or computer security issues to ensure the success of any CSIRT.

Consider another example in which teams, each handling separate services, are now coordinated under a centralized CSIRT (e.g., an existing security team, a virus protection team, and maybe a separate team that handles network security monitoring). Not only should the services of the newly forming CSIRT be considered and determined based on already-available services, but the notion of the CSIRT as a single point of contact for the organization as a whole must be evaluated to determine if it could affect already-established cooperation and communication links to other teams or vendors. Care must be taken to avoid detrimentally affecting such existing relationships. It will be vital to the overall success of the CSIRT to ensure that important communication links within the community are not broken. It is important to adopt solutions that allow for the necessary centralized reporting and coordination, while preventing any bottleneck or interruption of existing working relationships.

One suggested approach in the above example could be to extend the services offered by the existing team or group instead of creating an entirely new component within an organization. In some situations, such an option has some inherent advantages. The issues related to these migrations are discussed in more detail in Section Extending Service Offerings.

3.4 Comparison of Organizational Models

So that readers can effectively compare the CSIRT organizational models presented in the following chapters, we have described each in a similar manner. In this section we explain the topics addressed for each model:

Overview

Supported Constituencies

Organizational Structure

Triage

Available Services

CSIRT Resources

Summary

These topics in essence become the criteria by which each model can be compared and through which recommendations can be made.

3.4.1 Overview

The overview provides a general description and introduction to the model.

3.4.2 Supported Constituencies

Not every organizational model will support every type of potential constituency in the best and most effective way. More specifically, not all services of a particular organizational model will address the most urgent needs of any possible constituency.

Besides choosing the right services (see Section 2.7), knowing the limitations in supporting particular constituencies will help to prevent some common pitfalls.

In this section, we discuss the constituencies most suitably supported by a given model.

3.4.3 Organizational Structure

This section describes the CSIRT's place in the organization--that is, its organizational position and reporting relationships. It may also describe the physical and geographic location of the team. In addition, communications, both internal and external, are discussed here.

3.4.4 Triage

This section of each model will discuss any specific triage processes that might be required by or affect the structure of a particular organizational model.

3.4.5 Available Services

As described earlier in this document, a CSIRT can offer a wide variety of services based on its mission and purpose. The "Available Services" section of each model discusses how such services will be delivered (or possibly not delivered) under the model. This section also provides the rationale for why services work best in a particular model. This section is broken down into core services that the CSIRT can provide in the model and additional services that might be provided. Core services are those that are best suited to the model and that are the main focus of the CSIRT.

In reading each section the reader may see services commonly described across the various models. This occurs because even though the model is different, the service is still provided in a similar manner.

3.4.6 CSIRT Resources

This section will include any special considerations or requirements regarding staffing, equipment, and infrastructure that are required to support the model. For additional detailed discussion of these resources, refer to the Handbook for CSIRTs.

3.4.7 Summary

This section will highlight the effect the model has on the organization's constituency and will also detail the strengths and weaknesses of the models.

The remainder of this document will describe each of the organizational models in more detail in separate chapters. Chapter 9 provides a brief guide to help readers determine what type of model their constituencies might need, if they are not sure which model to consider. These chapters are followed by a closing remarks summary section.

3.4.8 Appendix

The appendix contains a matrix showing the different CSIRT models and the corresponding core and additional services that are provided as part of each model.

¹ Within the context of this handbook, the reference to security team is used in a generic sense. We acknowledge that some organizations have clearly defined groups of expert staff who are assigned to a more formalized Security Team, a team that has very specific roles and responsibilities, but not within the ad hoc context used in this description.

² For a detailed discussion of this topic, refer to the Handbook for CSIRTs, Section 2.1.2.3, Relationship to Constituency.