Organizational Models for Computer Security Incident Response Teams (CSIRTs)
[2
Establishing CSIRT Capabilities]
[4
Security Team--Using Existing IT Staff]
[6
Internal Centralized CSIRT]
[8
Coordinating CSIRT]
[10 Closing Remarks]
4 Security Team--Using Existing IT Staff
4.1 Overview
The security team model is not a typical CSIRT model. Rather, it is the exact opposite: it is the absence of a formal CSIRT. In this model, there is no centralized functional area or group that is given the overall responsibility for providing or coordinating an incident handling capability. Incident handling tasks and services are conducted by the system and network administrators or other security experts who normally maintain, configure, and protect the organization's hosts and networks.
These system, network, and security administrators are loosely called the security team because their job functions involve internal and external security defenses. For example, they handle security issues and technologies such as firewalls, antivirus filters, secure remote access, and intrusion detection.
The term "security team" can refer to individuals who perform these functions or to a group of individuals who work as a team. These individuals might be located in a centralized site, but more often are distributed across the enterprise.
In this model there is really no cross-organizational authority for providing incident response, collecting and analyzing incident data, or implementing recovery and mitigation steps. Instead, teams or individuals are locally responsible for security in their part of the organization. All authority for implementing any security policies and response efforts falls to the departments, divisions, or functional business units. Each of these areas has full internal authority for determining when an incident has occurred within their department or business unit and for deciding what recovery steps to take. Authority may, in fact, rest with non-technical managers working in conjunction with their system, network, or security administrators.
Typically with this kind of model, little coordination of incident information and response occurs, since each area performs tasks on an as-needed basis. It is a minimalist or "business as usual" model, in which no extraordinary measures are taken to prepare a coordinated response to security events by the organization as a whole. The members of the security team deal with incidents in an ad hoc approach as part of their day-to-day work. This model is very reactive and is not conducive to the provision of proactive services.
The goals of the security team are generally to protect systems and networks, detect abnormalities, and if necessary respond to the abnormalities that are identified. Their basic mission is to return the affected systems to operational status as soon as possible. To provide more than these services, an organization probably needs to choose one of the other models discussed later in this document.
We would be remiss if we did not acknowledge that there are indeed instances where the security team model is implemented and works effectively in performing both reactive and proactive incident handling tasks. Usually this is due to the fact that the staff involved go beyond their normal responsibilities to ensure information is coordinated. It can also result when enterprise-wide policies and procedures are enforced regarding incident reporting and incident response and when specific notification and information sharing policies are in place. The security team, although not a formal CSIRT, in many respects performs its role as such. In that regard they are considered a pseudo internal distributed team for all intents and purposes.
4.2 Supported Constituencies
The security team model is often found in organizations that have a narrow, focused need for security-related administration. As this need is recognized, small teams may be established to handle particular security issues or areas that require even more specialization. Most often, organizations start with dedicated teams for central security infrastructure components like firewalls, virtual private networks (VPNs), intrusion detection systems (IDS), remote access points, or antivirus scanning and prevention. Other work can include maintenance and implementation of security configurations for host systems. By virtue of doing this type of work, the members of these teams handle any other security issues that may occur.
These teams may consist of multiple staff or just one individual. Collectively, these specialized teams make up what is called the security team in this handbook.
This model is usually found in a commercial business, government department, or educational institution.
4.3 Organizational Structure
There is no real organizational structure for incident management in this model. The focus for incident reporting is division and platform based because that is where the hardware and software expertise lies. Responsibility for security and incident issues rests with the system, network, or security administrators. These administrators are scattered throughout the enterprise and do not usually have a centralized means of communication or collaboration for incident handling efforts.1 Each division and its operational staff end up being the policy- and decision-making entity rather than just the implementer of response efforts. However, the divisions still support and follow any enterprise-wide security or IT policies.
There is generally no centralized repository of incident data that can be used by the organization to generate an overall picture of incident activity, unless one can be provided through an organizational help desk.
There is also generally no one assigned with specific incident handling experience to work with external groups, the media, law enforcement, or other CSIRTs. Usually these tasks fall to the existing organizational public relations coordinator and legal counsel. Because there are no designated incident handling liaisons, any member of the security team might call for assistance from other security experts, other CSIRTs, other coordination centers, or law enforcement. This can often be done in isolation, with the requesting party not realizing that another part of the organization is already in touch with the third party experts. In turn it can make it confusing for the third party, as they are talking to many different people in the same organization.
4.4 Triage
Triage2 in this model is handled in an ad hoc manner, as no single reporting point has been identified. Each part of the security team will evolve its own reporting and triage mechanisms based on the policies of the division or department in which it is located. Contact points where incidents may end up being reported might include the general help desk; a specific divisional help desk; designated system, network, or security administrators; or the informal office "gurus."
Under this model, each part of the security team may develop its own set of procedures for processing, sorting, and prioritizing incoming information. There may be no formal record keeping; or if there is, there most likely is no way to consolidate the information that is obtained unless, as mentioned previously, a centralized help desk is being utilized. In such an environment, it is difficult or impossible to know what type of activity is being observed or reported across the enterprise, because there is no comprehensive mechanism for reporting, sorting, and disseminating information. Even if information is collected it may not necessarily be what is needed to coordinate an effective response.
Without a coordinated effort, categorization and analysis of information can be handled differently across the enterprise, resulting in inconsistent or even incorrect incident evaluation, prioritization, or response.3 Without a mandate to report information to a centralized point, no true picture of incident activity can be synthesized for the enterprise. In a structure such as this, to gain a high-level view of the enterprise, someone must be designated as the central point for collecting incident information and activity. If this type of synthesis of incident activity is to be done, the key questions will be where is this central point located in the enterprise and what staff will be assigned this responsibility? In most cases, for centralized reporting and analysis to work, one of the other models discussed in this handbook is needed.
4.5 Available Services
The following sections describe those CSIRT services that might be provided in a security team model. It is recognized that every organization is different, so these are general descriptions based on observations of and discussions with organizations using a security team model. The method in which the service is delivered assumes a certain level of infrastructure, staff, and equipment, which is discussed later.
4.5.1 Core Services
Because most often in the security team model there is no centralized or coordinated group for providing incident management and because the operational goal of organizations with this type of model is to recover and repair damaged systems and networks, the following services are those generally offered. The emphasis on repairing systems makes the security team's main function focus on incident response. Note that they are somewhat different from the normal core services offered by CSIRTs that are discussed in Section 2.7.4.
Incident Analysis
Incident analysis in this model is usually done only at the surface level to determine what has happened and what mitigation steps are necessary to get affected systems operational. Any deeper analysis such as incident correlation or trend analysis will most probably not be done, as the security team will focus on reacting to the computer security event, rather than proactively working to prevent future occurrences.
Initial incident analysis is done on a divisional or departmental basis or by the available members of the security team. Even the person reporting an event might do the analysis. The analysis will be focused on determining if a security incident has occurred, how widespread the activity is at the local level, and what impact it is expected to have. The analysis can also include researching existing information and strategies to help mitigate the activity.
Problems that can result using a security team model involve duplication of effort, lack of consistent analysis processes, and sometimes lack of expertise on the part of the security team staff on how to effectively respond to incident events.
Depending on the staff member's level of expertise, they may or may not be able to identify that a problem exists, or how severe it is. They may only be able to identify a symptom (not the real cause of the problem), and may or may not know who to call. Those who are sufficiently knowledgeable and can perform the analysis may not share their results with others, instead focusing only on building a response strategy for their own local systems.
Different members of the security team may conduct very different types of analysis, since there is no standard methodology. Duplicate effort will very likely be expended by other divisions or locations in addressing similar types of incidents and reports. Without sharing this information, the amount of time it takes to resolve an incident across the enterprise increases, effectively resulting in a more costly recovery process. Problems that could have been prevented will instead spread across the enterprise, causing more down time, loss of productivity, and damage to the infrastructure. If information is indeed shared, the recipients may not be sufficiently skilled to implement the repairs in an effective manner.
As mentioned previously, incorrect conclusions can be drawn and insufficient actions taken to address similar problems, depending on the expertise of the administrator or individual investigating the activity. Some areas will respond quickly because they understand what has occurred and know what needs to be done to repair the damage. Others might need to seek advice, guidance, or approval, which could delay analysis and response. Still others might misdiagnose the problem and apply inadequate solutions that do not completely address the problem--or worse, introduce even more serious vulnerabilities. Without consolidating the collected information, there is no mechanism for identifying security trends, patterns, or potential problems that can affect the entire organization.4 Activity might go unreported or unnoticed because no notification of what to look for was disseminated.
Incident Response On Site
As with triage and incident analysis, incident response is handled at the local level. Response efforts are most likely left to system, network, and security administrators. This service fits well within the security team model as the members of the team are located throughout the enterprise so they are located where the activity will need to be addressed. They will also, due to their other work responsibilities, have experience with the systems and networks in their purview, which can help in the resolution of incident activity. The response work will be done as an extension of their normal duties.
However, just because members of the security team are familiar with the systems and networks and are strategically located, does not mean that they will have the expertise to handle an incident and resolve it correctly. This is a major down side of the security team model, that staff are not necessarily trained in correct incident response processes or methodologies. They may also not be familiar with various intruder attacks and corresponding mitigation strategies. These administrators may not realize the potential seriousness of an event, might fail to give the response the appropriate priority, or not know to whom to elevate more serious threats. Reports can be handled more than once because the origin or source of the problem is not addressed, only the symptom. Since there is no formal mechanism for sharing information or lessons learned as a result of handling a particular type of event, potential knowledge relating to this activity may be lost.
Also because members of the security team do incident response and also perform other duties, this can potentially cause a conflict in prioritizing their workload. If other work takes precedence and incidents are not recognized or addressed in a timely fashion, then activity can cause further damage or erroneous responses to reports. Each report very likely is handled anew, resulting in the organization unnecessarily expending additional resources. The next time a similar report is received, it may even be sent to a different group of security experts within the organization.
With this limited localized response, it is unlikely that there is any significant sharing of information with other parts of the enterprise, let alone externally with other CSIRTs.
If critical system and network services are attacked, only local system, network, or security administrators who are directly involved with those systems or services are aware of the activity, and they may or may not be able to repair the damage. For example, if there is a virus outbreak in another part of the organization, only the people who work with systems in that area may be aware that there is a problem. They may fix the problem without letting personnel in any of the other areas know what has occurred. Other parts of the enterprise can suffer from the same virus and have to solve the same problem again, without the ability to leverage the benefit of work already done. In addition, solving the same problem multiple times across other parts of the enterprise will incur additional costs, result in loss of time and effort that could have been devoted to other tasks, and can even result in different (possibly incorrect) solutions being applied.
Incident Response Coordination
Incident response coordination in this model is performed at a minimal level, usually only within the affected division or group. Extended coordination may be required if the response actions that need to be taken are under the control of a different department; for example, if filters need to be installed on the enterprise firewall but the administrators handling the incident do not have control of the firewall. In this case a channel must be established to ask the appropriate people to make the changes to the firewalls. Often in the security team model these formal channels do not exist, so it may be difficult to not only find who to talk to about having the changes made, but also difficult to have the appropriate people comply in a timely manner.
With incident response handled individually in each area and without the benefit of a centralized reporting area, there is also no way to create standard responses that can be used across the organization. Another problem resulting from this structure is that there is no way to ensure that systems, patches, and virus updates are made in a consistent manner or that they are even made at all across the enterprise. Each division can only be responsible for ensuring that their administrators have complied with the recommended mitigation strategies.
Since response work is done at the local level, there is no point of contact to handle any requests or questions from external sources or to pass on information to external sources. Information about external sites and organizations involved in the incident might (or might not) be passed to other relevant CSIRTs to allow them to contact these organizations directly. It is unlikely that there is consistent or complete reporting to all external parties, especially if an incident involves a large number of sites. The security team members generally do not have the resources to contact many sites nor possibly the tools and skills to facilitate such coordination even if they want to take the appropriate steps to contact and inform others.
The success of any coordination effort in this model depends on how well various team members work together. It also depends on having clear procedures for notification of other parts of the constituency or enterprise, and a clear means of escalation of incident activity if necessary. Along with procedures, a list of the members of the security team and their contact information is needed, so that the appropriate people within the constituency can be notified.
Vulnerability and Artifact Response
As part of their normal security tasks, members of a security team undertake actions to mitigate or repair a vulnerability, as well as to determine the appropriate actions to detect and remove artifacts such as viruses, Trojan horse programs, toolkits, and exploits from a system.
In addition, the members of the security team determine what other protective measures need to be taken to avoid future similar or equivalent attacks and incidents. This usually involves researching and applying patches, fixes, and workarounds. It may involve creating signatures that can be added to virus scanning databases or intrusion detection systems.
If members of the security team are scattered across a constituency or organization, they may not readily share analysis of exploits or problems they have discovered or mitigation strategies resulting from their testing and research. This can cause inconsistent remediation efforts to be applied throughout the enterprise.
Configuration and Maintenance of Security Tools, Applications, and Infrastructures
This generally is the main service provided by the members of the security team. This is their normal day-to-day work: maintaining the availability and security of the local environment and infrastructure.
The system and network components configured and maintained can include firewalls, VPNs, IDS, or even virus scanners. Work may also involve user account and password management or the review of network, system, security, and accounting logs.
Depending on how security standards have been implemented in the parent or host organization, this configuration and maintenance may be done along enterprise-wide guidelines or by divisional guidelines. Unfortunately, if it is done divisionally, this may mean that different areas of the enterprise are not protected as effectively as others, and therefore could be more vulnerable.
If the security policies are divisionally based, and different security settings are used across the enterprise, then this may also affect how efficiently and timely response efforts can be applied throughout the parent or host organization. If other parts of the enterprise do not use the same security policies, tools, or configurations, then more work will be needed to determine what comparative action can be taken.
Intrusion Detection Services
This service can be provided in one of two ways: either centrally by one department or unit in the enterprise, or divisionally. If it is handled divisionally, multiple efforts are expended to review the IDS logs and determine what actions to take. Also, there is usually no consolidation of information across the enterprise to provide a "big picture" of intrusion activity for use in the analysis of trends and patterns.
4.5.2 Additional Services
In addition to its core services, a security team may facilitate other services. The following services are those most likely to be provided.
Alerts and Warnings
Because it is the mission of security teams to handle security configuration and maintenance tasks for their parts of the organization, they are the appropriate point of contact to receive alerts and warnings sent from other security-related organizations or vendors. They can use this information to determine prevention and mitigation strategies to handle vulnerabilities, intruder attacks, or other related computer security problems. They may also be given the responsibility to disseminate the information to others within the organization or constituency. Besides alerts and warnings forwarded from others, they may disseminate annotated messages and alerts and warnings they have composed. In all, their tasks may include collecting, evaluating, distributing, and perhaps even developing alerts and warnings. However, this depends on their having enough time to do this work. Often the normal day-to-day work may keep the staff so busy that they cannot send out alerts in a consistent manner. It is possible that alerts may be sent out only on an occasional or emergency basis.
If the security team has no designated authority, any alerts they send out may be ignored by other groups unless management requires that the alerts be followed.
Vulnerability and Artifact Analysis5
In the context of a security team, any work in regard to the analysis of vulnerabilities or artifacts is initiated by a real need, most often by an incident or attack detected by the security team. If there is no standard methodology to follow, the analysis done is usually ad hoc and inconsistent. The analysis is also limited to the technical expertise of the available local analysts and most probably focused on a particular event.
If there are no resources or expertise to perform this type of work, members of the security team need to rely on analysis done by other external CSIRTs or security organizations. Such analysis resources may include advisories, alerts, trend analyses, and technical documents.
Vulnerability and Artifact Response Coordination
Any vulnerability and artifact response coordination that occurs will usually be within the local division or unit, to ensure that all systems in that area are addressed. Coordination outside the local unit with other parts of the enterprise usually only happens if there has been some established channel to share this information. In most cases this means that there is no comprehensive tracking and recording of vulnerabilities and artifacts across the enterprise. Without such consolidation of information, there is no mechanism for identifying similar trends or patterns, nor is it possible to identify potential new threats to the organization.
Even if no vulnerability or artifact handling effort is undertaken, members of the security teams involved in responding to an incident or attack will need information. They might ask other CSIRTs, vendors, or security companies for assistance and coordinate any further response regarding newly identified vulnerabilities or artifacts. If a point of contact for dealing with vendors and security companies is not established, multiple parts of the organization may attempt to correspond with these vendors. This can cause confusion and in the end frustration on both parts as duplicate information is relayed through multiple channels, increasing the chance of miscommunication. Vendors may also require that only one point of contact work with them.
Development of Security Tools
Based on their involvement with the configuration and maintenance of security tools, applications, and infrastructure elements, members of a security team may experience situations in which a specific solution is not readily available. In such cases members of a security team might develop tailored tools to provide a workaround or temporary fix to help satisfy such specific requirements, if they have the necessary expertise or skills.
Other Services
Other reactive and proactive services such as incident response support, announcements, technology watch, security audits and assessments, and security-related information dissemination would not normally be provided by a security team. Of course there may be some organizational structures in which these may be provided as additional services, but in general many of these services require dedicated resources and therefore would be difficult to provide within the ad hoc nature of the security team model. Without a common focus on incident management across the organization, these services cannot be effectively provided in a coordinated manner.
4.5.3 Impact on Security Quality Management
Without the benefit of any organized response plans, it is unlikely that the security team will have the resources or time to provide any proactive quality management services that do not already relate to their normal work activities. For example, a security team will most likely not provide security awareness training, tutorials, or briefings.6
Since members of the security team may be involved in actually implementing and maintaining security solutions, they will likely be involved at some level in the testing of potential hardware and software products. Product evaluations can be done as part of routine purchase decisions or in response to a request by some department or unit. The evaluation mechanisms can range from informal testing to formal certifications.
Other problems that result from the ad hoc nature of the security team include the difficulty in extracting incident trends and patterns when there is no centralized repository of incident data and reports. The CSIRT in this model is not usually positioned to provide business intelligence into any risk analysis or business continuity planning. Each member or group from the security team can try to use lessons learned from their own experiences, but other parts of the organization and perhaps even other members of the security team will miss out on the knowledge about important threats and the corresponding mitigation strategies if no coordinated exchange of lessons learned is established.
4.6 CSIRT Resources
4.6.1 Staff
This model requires no additional staffing. It utilizes existing personnel, such as system administrators, local area network and wide area network (LAN/WAN) administrators, security administrators, database administrators, help desk personnel, and software developers to support any incident handling activity at the local level. Any response efforts (reactive, proactive or security quality management) are performed in addition to the normal day-to-day responsibilities of the staff.
As the responsibility for security and incident handling resides with existing staff, their technical, communication, and personal skills determine the quality and level of response that is provided. The model does not provide a consistent method for developing incident handling expertise across the organization.
Although there are no additional salary costs incurred if incident handling tasks are done as part of the day-to-day operations of the security team, there is the potential for wasting money on duplicated and inefficient activities. Of course, if incident handling activities are outsourced, then there will be additional costs.
As with any other model it is very important to have an updated list of the staff members in the various components of the security team and their area of expertise and contact information. This information can be used to contact others when specific skills, expertise, or assistance is needed. A list of other platform or software specialists outside of the security team is also beneficial. There is no guarantee, however, that such assistance could be provided, especially if these specialists are located in other divisions, departments, or at other physical locations. They may also be too busy with their other responsibilities and tasks to provide assistance.
4.6.2 Equipment
There is no requirement for additional equipment in this model. It requires no additional ancillary support services. Existing computer equipment, peripherals, telephones, and pagers are used. If more equipment is needed for specialized analysis work, it may be possible to negotiate with other parts of the enterprise to borrow or use equipment such as software-development facilities or a test lab in a non-production environment when investigating incident activity.
4.6.3 Infrastructure
No new infrastructure costs are incurred, as there is no coordinated or focused incident handling capability. The existing infrastructure is used. It is hoped that the infrastructure will provide some computer security features, such as separate networks and firewalls, baseline computer configurations, security guidelines for system administrators, and acceptable-use policies for users. If any incident tracking or coordination is to occur at an enterprise level, an integrated help desk system will be needed that all members of the security team can use.
4.7 Summary
This model does not include a formal CSIRT. Incident response activities are handled by system, network, and security administrators throughout the enterprise who are responsible for the maintenance and configuration of the enterprise systems and networks. Incident response work is handled on an ad hoc basis as part of the normal security activities. The network, system, and security administrators involved in this work are loosely referred to as the security team.
With this model, it is critical to have well-written security guidelines, effective policies, and detailed procedures in place to ensure consistent configurations for computing environments throughout the enterprise. The constituency must rely on such defensive measures, as there is very little or no coordinated incident response team.
If incident management in this ad hoc manner is to occur with any success, some method for contacting and notifying the rest of the organization is also necessary. It is not an easy task to define where this process will reside, and even if done, whether other parts of the enterprise will respond to the notifications unless there is strong management support. One of the other internal CSIRT models would provide better coordination and management of incident activity across the enterprise.
4.7.1 Impact on Constituency
This model has the least impact on the current operations of the constituency; it is basically "business as usual." The consequences to enterprise-wide security are that vulnerabilities and risk may vary from location to location and the organization does not have the mechanisms in place to recognize threat patterns across the enterprise or the ability to prevent or mitigate such threats.
In this model, no individual or team has any real authority to effect enterprise-wide changes for the broad constituency, since the effort is focused in localized areas.
4.7.2 Constraints
The lack of a coordinated incident handling effort is the main constraint in providing this capability via the security team model. The basic problem is how to provide standard, cross-organizational reporting, analysis, and response when each division is handling those activities in an ad hoc manner.
4.7.3 Strengths and Weaknesses of the Model
As we have mentioned, one problem this model presents is that there is no way to ensure consistent and correct response across the organization. Also, viewed from an organizational perspective, by not sharing information among divisions, erroneous or incomplete recovery steps could be taken across the enterprise even if some security administrators correctly address the problem locally. Other expertise that is needed and that might exist in other units is not known, and no overall picture of the incident activity throughout the enterprise is obtained. Further, other areas of the enterprise can remain exposed to threats if the solutions are only applied where they occurred or were locally recognized and are not passed on to others.
The lack of a centralized presence or authority for incident handling and reporting also causes confusion within departments and among staff members. Staff are not sure who to notify about incidents or who to involve in response efforts. There may be such a wide variety of areas of expertise that there can be no consolidated response effort on a collaborative basis across the enterprise. In addition, some areas of expertise might not be available, leading to a situation where an incident is recognized but no one feels responsible or is able to provide the necessary support for any response effort.
A bigger problem is that it is difficult to determine ownership of a problem in this type of security environment. For example, if a UNIX system is compromised in a particular functional area, who is responsible for deciding what to do, the UNIX administrators or the functional business unit (e.g., the system operator or the system owner)? If personnel in one area discover an intrusion and suggest mitigation and recovery steps, how do they get buy-in and compliance from other groups and divisions if they need their assistance? On the other hand, if one area discovers an intrusion or security breach, they may be motivated to cover up the problem before anyone else notices, rather than share the knowledge with other business units.
There are no real strengths in this model in regard to incident handling, as it does not provide true incident handling services. The only benefit gained may be that no additional costs are incurred in equipment and staffing. However, that cost savings will most probably be offset by subsequent damage resulting from incident activity that was not quickly and efficiently handled due to the lack of coordinated response efforts. It is possible, however, that a security team may be effective in a small organization, where the number of incidents are low and the team has an in-depth understanding of the systems and networks and their corresponding security configurations.
To be a successful security team in regards to incident handling activities, the following requirements are suggested. Please note that this is not a comprehensive list of everything that would be needed, but some key requirements.
- an established response plan and identified staff with designated assignments and tasks that have management support and approval
- an established method to notify the rest of the enterprise when a computer security event occurs
- a matrix or list of platform and network experts in the organization and their availability and contact information, along with support from management for them to be pulled into incident handling activities as needed
- an incident tracking system that can be shared and accessed by all members of the security team components in the organization. Included in this requirement is the need to have agreed-upon definitions, categories, and priorities for incident types.
- an identified escalation path when normal resources are not enough to handle the situation or when additional expertise and advice are needed
- security awareness training and incident reporting guidelines for the constituency and the members of the security team
1 Although there can be, for example, email notification lists that are set up to share information, we have often seen that such notification still does not ensure or invoke a coordinated response.
2 Even in the absence of a formal method, triage implicitly occurs when system and network administrators scan their incoming mail for information and tasks that need to be handled and determine what additional steps need to be taken.
3 This is not to say that a security team model cannot have an integrated tracking and reporting system. But our experience shows that normally this is one of the weaknesses of this type of model.
4 There are some security teams we have seen that work together and follow established incident response procedures. In most cases this is due to the dedication, commitment, and expertise of the personnel involved. If these personnel leave for some reason, the process often collapses.
5 Although the technical details are quite different, the considerations for vulnerability handling are similar to those for artifact handling. Therefore both services are handled together throughout this document. Differences are clearly stated whenever necessary.
6 That is not to say that such activities do not occur at all, but that it is unlikely in the security team environment.
[2
Establishing CSIRT Capabilities]
[4
Security Team--Using Existing IT Staff]
[6
Internal Centralized CSIRT]
[8
Coordinating CSIRT]
[10 Closing Remarks]