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]

9 Choosing the Right CSIRT Model for Your Organization

In the preceding sections, we have outlined a number of different models and CSIRT services to help you understand the options available. Of course, you can pick the most applicable features from each of the models described and design your own CSIRT model. Or perhaps your organization will require multiple organizational models to fit the needs of your situation. If you are still not sure what type of model would work best for your organizational structure, the guidelines in this chapter for choosing a model might help.

Please be advised that any answer that might be determined from the information below should be seen as a guide rather than a definitive recommendation. A definitive recommendation would require much more specific information about your constituency, mission, and services.

9.1 Do We Describe Your Team in this Handbook?

Although we have described several organizational models for implementing a CSIRT capability, this handbook is not inclusive. Specifically, we do not provide a model of operation for a vendor team or a managed security services provider. There may also be various situations that require a custom model for organizations.

If your team concentrates on security vulnerabilities as part of a vendor company, that is, your team receives reports of security flaws in your vendor products and works to repair these flaws and provide alerts, advisories, and fixes related to these flaws, then you are considered a vendor team. Since we do not provide a model for vendor teams, you may be able to discern a model yourself, based on the advantages and disadvantages described for each model in this handbook.

If your team provides incident response or security services to customers for a fee, then you are most likely a managed security services provider. We also do not provide a model for this type of team. Some of the models presented here may work for your organizational structure, but you will need to review the advantages and disadvantages of each and see which best suits your situation.

9.2 Are You a Security Team?

If you meet the following criteria, then you are probably a security team and should read Chapter 4.

There is no designated group responsible for incident handling.

Members of existing infrastructure, IT, and security groups handle any computer security incidents and problems, as part of their normal day-to-day work.

Members of the security team perform on-site incident response.

9.3 Are You a Coordinating CSIRT?

If you meet the following criteria, then you are probably a coordinating CSIRT and should read Chapter 8.

Your team does not belong to the same organization as your constituency.

Your team coordinates incident response efforts and information exchanges across many different CSIRTs, security teams, and/or other external organizations.

Your main services are to coordinate information exchanges and facilitate discussions of incident activity. You do not perform on-site incident response.

9.4 Are You an Internal CSIRT?

If you meet the following criteria, then you are probably an internal CSIRT.

Your CSIRT is in the same organization as your constituency.

The main priority of your team is to focus on incident handling rather than being responsible for maintaining any other part of the security infrastructure.

Specific authority and responsibility for handling incidents has been given to your team.

There are three different models for internal CSIRTs: distributed, centralized, and combined. Read the following information to determine what type of model may work best for you.

While it is rather straightforward to differentiate between the main categories of organizational models--security team vs. internal CSIRT vs. coordinating CSIRT, deciding whether a centralized approach would be better than a distributed or combined one for an internal CSIRT may be difficult. Instead we will discuss some of the factors that influence any decision.

Size and Distribution of Constituency
This refers to how big the constituency is (the part of the organization your team is responsible for). Size can be measured in terms of users as well as number of networks, internet connections, and systems to protect.

A small or mid-sized organization may only need a small centralized team, while a large organization usually implies that staff are spread out among more departments, buildings, or even geographic locations and may require a more distributed team to adequately accommodate the variety of systems, locations, and staff. Much more difficult to handle than geographic locations are time zones and language differences. Both make it difficult to serve constituent members efficiently.

Services Provided and Related Service Levels
If for example your team provides incident response on site instead of incident response support, this implies that you can be on site in a reasonable time period (otherwise it would not make any sense to provide that service). Depending on the service and related service levels negotiated, this is best provided by a distributed model or combined model, where part of the CSIRT capability is located at distributed sites.

The type of mission and function of the CSIRT as expressed by the services provided has a great impact on the type of organizational model that will be needed. The provision of certain types of services may require a particular organizational model to be effective. If the CSIRT's main function is to perform analysis and repair and recovery tasks, then in many cases a distributed or combined model would work best, especially if there should be close cooperation between the CSIRT and other staff or teams. On the other hand, if the purpose of the CSIRT is to collect information across the organization, provide support in cases of incidents, and propose recommendations and solutions, then a centralized CSIRT may work best.

Funding and Resources
This refers to the amount of funding or the budget available for creating and operating the CSIRT. If there is limited funding available, the organization may have to rely on a security team with an established incident response process rather than a formalized CSIRT. Another option might be to form a distributed team by using existing staff and only adding a new CSIRT manager position. A third option might be a small centralized team. If sufficient funding is available, larger and more complex models based on more staff may be an option. Even low funding levels can allow for a small, effective centralized CSIRT, if the services provided and the service levels are in line with the amount of funding and resources available.

Position in the Organization
While this factor cannot be influenced in most cases, it has a strong impact. In fact, for the internal setup of a CSIRT, the department that drives the development will greatly influence the organizational model chosen. Experience shows that a CSIRT usually starts out as an activity of the IT department, in which case technical issues and services are the main focus. A CSIRT may also evolve from the security/risk management or policy department, in which case the team will be much more focused on policies. Depending on the organizational structure that the responsible department has, the CSIRT will follow the intent and purpose of its originating entity. Only if the CSIRT will be established outside the existing "founder" will its model possibly change.

Related to this observation, in organizations with existing security teams, it might be possible to enhance those teams. Depending on the approach chosen, the organizational model for the CSIRT will become more centralized if one of the security teams is selected as the foundation of the CSIRT. The organizational model will become distributed if responsibilities for incident handling are given to all security teams already distributed across the organization.

The following are a few examples of choosing an organizational model based on combinations of various factors.

A small educational institution with little or no funding will continue to depend on their security teams, which require no additional funding. However, it is recognized that these types of teams do not provide good coordination or analysis of incidents beyond responding to them to recover and repair systems.

The same small educational institution would benefit from a small centralized CSIRT, which, although requiring some additional funding, could provide a centralized location for incident reporting, analysis, and response.

If the institution is too small and has no effective security teams already in place, then instead of concentrating on developing a CSIRT, emphasis may be placed on developing a security team with more staff and added responsibilities for incident handling.

For a large, multinational financial corporation with multiple affiliates and subsidiaries, a combined CSIRT with a centralized staff devoted to monitoring incidents across the organization and recommending security precautions and solutions might provide a suitable approach. The team members are chosen from each affiliate, subsidiary, and remote site as members of the distributed part of the combined CSIRT.

If in the large, multinational financial corporation the CSIRT has no authority over the affiliates and subsidiaries, a coordinating CSIRT within the headquarters will provide a much more effective structure. The coordinating CSIRT will work with CSIRTs at the affiliate/subsidiary level.

If in the large, multinational financial corporation the CSIRT has no authority over the affiliates and subsidiaries, the CSIRT might still be responsible for IT components such as the centralized backbones, Internet connection points, and critical infrastructure elements within the authority of the corporate headquarters. In such cases the CSIRT should be monitoring these elements and should handle--with authority as appropriate--all incidents that they become aware of. The centralized nature of these functions may make a centralized CSIRT feasible, or again a combined CSIRT might also work.