vPLfv

objectives and business drivers has led management in many organizations to distribute that
capability across the organization and, in many cases, outsource much of it to third parties.
This observation has led us to look at incident management outside of its historical boundaries
within the IT department and instead see incident management as a distributed capability.
Just like a CSIRT, an incident management capability can take many forms. It can be a set of
comprehensive policies and procedures for reporting, analyzing, and responding to computer
security incidents. It can be an ad hoc or crisis team with defined roles and responsibilities
that is called together when an incident occurs. It can also be an established or designated
group that is given the responsibility for handling computer security events. So in essence, a
CSIRT is one type of incident management capability.
To summarize this discussion of the definition of CSIRTs and incident management:
• Incident management activities and functions are broad based; they can involve not only
incident analysis and response but also vulnerability analysis, artifact analysis, security
awareness training, intrusion detection, public or technology monitoring, and other services
as listed in the CSIRT Services list in Figure 1.
• In a commercial, educational, military, or government organization where an internal
CSIRT model would be appropriate, the incident management activities are often performed
across multiple parts of the organization, including the CSIRT, as well as across
multiple organizations such as contractors and service providers
• A capability for providing incident management activities can take many forms; a CSIRT
is one type of incident management capability.
Often when working with a newly forming CSIRT or an organization wishing to develop an
incident management capability, we discover that incident management activities are already
occurring in other parts of the organization but are not identified as such. In our publications,
we discuss how important it is to identify what types of incident management activities are
already occurring and who is responsible for performing these activities as part of the planning
and design process of building an incident management capability. This can help shape
and structure the needed services. For example, if the organization is looking to create a
CSIRT, then by looking at what is already in place, the interfaces required between the
CSIRT and any other ongoing incident management activities can be defined. If certain functions
are already being successfully handled, then perhaps the CSIRT can instead focus on
those activities that are not being done. For example, if configuration management, vulnerability
scanning, and security awareness training are already being done by an organization’s
IT department, it may be appropriate to have that area continue to provide those services
while a new CSIRT concentrates on other services such as incident analysis, technology
watch, vulnerability coordination, or incident response support and coordination. 5 The main
change to the existing functions is that there must be some type of formal mechanism or interface
put into place and agreed to by both groups to provide coordination and information
exchange between those IT (or other) functions and any new CSIRT functions.
5
For definitions of these services, see CSIRT Services at http://www.cert.org/csirts/services.html.
CMU/SEI-2004-TR-015 7