vPLfv

agement activities. Often the only way to combat malicious activity is to prevent its initial
entry into an enterprise. As a result of lessons learned during an incident, organizations often
have to make organizational and technical changes to their infrastructure to prevent attacks
from successfully happening again. Other proactive protection activities, such as vulnerability
scanning, penetration testing, network monitoring, public monitoring, and risk evaluation
or assessment, relate directly to methods of detecting and reporting events, incidents, vulnerabilities,
and other computer security related information. Protecting an organization’s infrastructure
becomes a strategy for not only preventing attacks but also for identifying, containing,
and stopping malicious activity in a timely manner. The infrastructure defenses are one
type of tool used to manage incident activity. Because of this multilevel connection between
the protection of an organization’s infrastructure and the resolution of incidents, we believe
that the Protect function must be included as one of the activities in the broader scope of incident
management.
One other process that we include and that is also mentioned by ISS [ISS 01] as being an important
part of the incident management process is Triage. Some people see triage as being
the first step in response (the Respond process), a method for performing an initial analysis of
a report to determine what has happened and what the impact is, while also categorizing and
prioritizing an event or incident. We have set Triage as a process separate from Respond, due
to the fact that how triage is performed will depend heavily on who performs it. Triage can be
handled in multiple ways. It can be done by an incident handler as part of the initial analysis
of an event; it can be done by a help desk that handles general computer problems for an organization;
it can be outsourced to a managed security service provider; or it can be handled
by specific positions in an organization, such as an information security officer. When handled
outside of a CSIRT, there are risks to the transfer of information from the triage role to
the incident handling role that can occur. Triage is also important as a location where categorization
and correlation of events can occur. As such, it is on the critical path to response and
should be accorded an appropriate set of resources. For these many reasons, we believe Triage
should stand alone as a process.
Depending on the type, structure, and mission of an incident management capability, some of
these processes may not apply. For example, a coordinating CSIRT might not perform any
type of Protect or even Detect functions. Various types of incident management capabilities
may actually only focus on one part of these processes. In future reports, we hope to address
some of these different types of capabilities and how their process workflows differ from the
ones described here.
2.4 Incident Management Versus Security
Management
Precisely defining incident management is difficult; the words mean different things to different
communities. For example, in the Information Technology Infrastructure Library
(ITIL), a best practice series of books providing guidance on developing and implementing
CMU/SEI-2004-TR-015 23