ITS 305 - Security Policies and Auditing
Chapter 12, Incident Response Team (IRT) Policies
This lesson covers chapter 12. It discusses policies that relate to
incident response teams and procedures. Objectives important to this
- Incident definition
- Incident response policy definition
- Incident classifications
- Incident response teams
- Procedures for IRTs
Okay, let's turn this around. Defining an IRT before you define an incident
is nonsense. Sorry, Mr. Johnson.
Let's start at the bottom of page 330. The short version is that an incident
(actually, a security incident, because there are other
types) is an event that significantly violates a security policy.
It can be any kind of disruption of service or violation of the CIA standard,
as long as it puts the organization at risk. In other environments, the
simple word incident is more generic, so be aware that this chapter
is about security incidents.
Incident Response Policy
That being understood, the chapter actually opens with the idea that
there should be a multidisciplinary team in place to handle significant
security issues. This is confusing because it is not uncommon for there
to be a general incident response team on the organization's help
desk, whose job is to handle any incident that does not have significant
security implications. It is important that when, for instance, there
is an ongoing attack on some aspect of the organization that the right
people be available to defend our assets. The text also discusses the
idea that there will be smaller violations of security policies that will
not require the attention of this team of specialists. Those problems,
such as sharing a password, will be handled by local management, without
needing to involve the security incident response team (SIRT).
This is why there is a need for a security incident response policy,
a set of criteria that make it easier to determine when there is
a security incident, and when the current problem is only a security
infraction, which will be handled and properly reported. The essence
of the distinction is this: is this an emergency? If so, the SIRT should
Your security incident policy should include a classification method,
otherwise the SIRT will receive the wrong trouble calls, and will fail
to receive the right ones. The text informs us that there is no definitive triage list for this purpose. This is probably because the duties of the SIRT staff vary from one organization to another.
text tells us that the Visa company's requires a report of
any breach of customer information, and that it tracks these reports by
exploit type. Tracking this information provides a rough estimate of
how many attacks of each type we might expect to see in a given time
period. Compare the list of types tracked by Visa on page 331 to the
list of types tracked by NIST standards on page 332. There are unique
items on each list. Do the Visa merchants never encounter a DoS attack?
Do the agencies using NIST standards never have misconfigured
networks? Perhaps those issues are infrequent in their respective
environments, or they are unlikely to cause security problems for those
Regardless of tracking the type of incident, it is a common
practice to handle minor incidents at the help desk or within the work
area. However, there must be a definition of what is a minor incident,
and what is a major incident. As the text says, it is easy to see the
difference at the top of the scale. It is more difficult in the middle,
so there must be measurements we can use. When there is a potential for
loss of life, it is a major incident. When it affects all or a significant number of users, it is a major incident. In practice, the number of users affected or threatened
is often a measure of the severity of the incident. If incidents can be
measured on that scale, that is a good method. However, there may be
other factors. In small, outlying locations, it may be more meaningful
to measure the percentage of staff affected, rather than the raw
number. If there are only 10 staff at one location, and 100 at another,
the effect of 5 people being unable to work is more significant in the
first location than in the second.
Incident Response Teams
On page 333, the text turns to the ways an incident
response team might be organized and empowered. It may begin with a
charter, which is a commonly used business document that establishes
the purpose of a group or project, and the extent of the authority
granted to the staff involved in it. The
reason for a charter is to make it clear to all staff that the security
incident response team has been given authority to take charge of an
incident, to act to resolve it, and to expect cooperation from all
The text lists three scopes
that a security incident response team might be empowered to act under.
- On-site response - The security incident response team is empowered to take a hands-on approach to incidents, taking charge of them and performing the necessary tasks to resolve them. The text explains that political realities may require the SIRT staff to advise a local expert about what to do. This is still within the scope of this scenario.
- Support role - This scope is more likely when the organization is complex, having many systems whose maintenance is done by experts
who are the appropriate staff to handle their problems. It is also
appropriate when other staff have expertise in handling
incidents. The SIRT members will provide advice and management of the
- Coordination role - When
the organization is larger than one geographic location, it may be best
to have the SIRT staff act as a central authority whose role is to
manage the activities of local staff at every location. This is a
problem if there are many locations, few staff to distribute among
them, and no remote management software.
The text moves on to consider the specialties that might be
useful for the members of a SIRT. If you are not reading carefully, you
might miss the fact that security staff form the core of the team, so I
will add a bullet point for them:
- SIRT core members who are security experts
- Experts in systems that are affected
- Human resources staff when needed, such as when there is an internal attack
- Legal staff who may interface with police agencies and/or advise the organization about legal and regulatory responsibilities
The other staff listed on page 336 are more useful to the business side of the organization than to the technical solution side. Even the data owner may be a business person who has official
control of the data, but who does nothing on the technical side. The
text beats this concept to death for a few more pages, but we don't
have to watch the beating.
On page 340, the text presents a case for having Business Impact Analysis done. It relates to a concept we have seen before, establishing what resources we need to restore, with what speed, and in what order in various incident scenarios. Once this information is prepared, we can write incident policies and procedures that describe what must be done in particular circumstances.
As usual, we find the actual steps to perform during or after
an incident in the procedures associated with it. The grapic on page
342 shows a circular set of processes, each of which would have
procedures to follow to achieve the desired result. The information in
this text in the remaining pages in the chapter was summarized better
in our last text. Documenation should take place at all stages:
- Business Impact Analysis - The green highlight
on this bullet is to show that this step should be done when times are
good and we can examine our systems performing normally.
can plan for what to do, you have to figure out what is normal for your
business, what can go wrong, and what can be done to minimize the
impact of incidents and problems/disasters (see the bullets below).
- What are the business's critical functions? Can we construct a prioritized list of them?
- What are the resources (IT and other types as well) that support those functions?
- What would be the effect of a successful attack on each resource?
- What controls should be put in place to minimize the effects of an incident or disaster? (Controls are proactive measures to prevent or minimize threat exposure.)
- Incident Response Planning - The red highlight
on this bullet is to acknowledge that the plans made in this step are
used when there is an emergency for one or more users. (Shields up, red
alert? Why were the shields down?)
The text is consistent with the ITIL guidelines that call a single occurrence of a negative event an incident. An incident response plan is a procedure that would be followed when a single instance is called in, found, or detected.
For example, a user calls a help desk to report a failure of a monitor
that is under warranty. (Note that this is an example of an IT incident, not an
IT security incident. What further details might make this part of a
security incident?) There should be a common plan to follow to repair
or replace the monitor. Incident Response Plans (Procedures) may be
used on a daily basis.
- Business Continuity Planning - The orange highlight is meant to indicate that these plans are not concerned with fighting the fire, but with conducting business while the fire is being put out.
Business continuity means keeping the business running, typically while the
effects of a disaster are still being felt. If we have no power, we run
generators. If we cannot run generators (or our generators fail), we go
where there is power and we set up an alternate business site. Or, if
the scope of the event is small (one or two users out of many) maybe we
pursue incident management for those users and business continuity is
not a problem.
- Disaster Recovery Planning - The yellow highlight here is to indicate that the crisis should be over and we are cleaning up the crime scene with these plans.
A disaster requires widespread
effects that must be overcome. A disaster might be most easily
understood if you think of a hurricane, consequent loss of power,
flooding that follows, and the rotting of the workplace along with the
ruined computers and associated equipment.
A disaster plan is what we do to restore the business to operational status after the
disaster is over. There may be specific plans to follow for disasters
under the two bullets above, but the disaster recovery plan is used
after the crisis, unless this term is applied differently in your working environment.
- By the way, in ITIL terms, a series of incidents may lead us to discover what ITIL calls a problem, something that is inherently wrong in a system that might affect all its users. When a problem knocks out a critical service, we have a disaster. The organization you work for may use all three terms, or any two of them to mean different scopes of
trouble. You need to know the vocabulary to use in the setting where
you work, and you need to call events by the names they use.
The text also mentions analysis of the incident and our response. Analysis of the incident should begin during the incident, to lead us to a good solution. Analysis after the incident can examine what actually happened, whether the steps we took were effective, and what we should recommend or require to avoid such an event in the future.