ITS 305 - Security Policies and Auditing
Chapter 3, Planning for Contingencies
This lesson discusses high level planning for the
organization's information security interests. Objectives
important to this lesson:
- Need for contingency planning
- Components of contingency planning
- Creating contingency plans
- Testing contingency plans
This chapter covers contingency
planning, which the text tells us is about plans for
unexpected events. This is true, but also a bit naive.
We have to recognize that things will go wrong, people will attempt to
attack our systems, people will attempt to rob us. These events are not
so much unexpected as they are unscheduled. Contingency plans are what
we have proactively decided to do when something goes wrong. We must
also realize that our plans will need to be flexible, because we cannot
predict what will happen. A wise saying that I have heard translated
several ways warns us that no
plan of battle ever survives first contact with the enemy. We must
be ready to change our plans as the situation requires.
So, what do we do about some of the things we expect to go
- a contingency is something that depends
on something else
- a contingency plan is the plan that is
followed if an anticipated problem occurs
- controls are proactive measures you put in place to prevent mistakes, minimize risks, and increase system availability
- the business cannot continue operating if some necessary
technology stops working; we need plans for
what to do when different types of technological
- severe failure becomes a disaster,
which the text warns us we need separate plans to handle
- contingency plans and disaster plans should both lead to
the restoration of normal operations and
Several different kinds of plans are made, called by different
names that relate to the circumstances of the event and the scope of
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.
Before you 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.
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.
Despite the emotional response of the person in the text's parable this
week, one person having a desk full of paper ruined by water damage is
not a disaster. (For perspective, consider the legend about Isaac Newton,
who reportedly handled a worse circumstance with more grace.) 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.
- Your text says multiple incidents can become a disaster, or
may lead us to realize that there is one, especially if there is no
plan to overcome them.
- 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. Your book seems to
call this 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.
- Is there a condition for a blue
highlight? We might pretend there can be,
but it is unlikely that the IT Security staff would ever feel that safe
For all the areas of planning above:
- What are the contingencies we can plan for, and what plans
should we select from the
- What are our official plans and procedures? Have
appropriate staff been trained?
- How will we implement our plans, and how will we test them?
This includes a schedule for regular testing.
- What is our schedule for revisiting and revising our plans?
The text tells us more about Business Impact Assessment, and
as you might imagine, expands each threat analysis for each work unit
the threat might affect. In fact, the text proposes that we produce a detailed table,
like the one in Table 3-1, for each kind of threat we can imagine. It
is easier to create tables like this from experience than from
imagination. Luckily, we do not have to experience each kind of attack
ourselves to learn about it. We can harvest information about them (or
use the library of information about them) on the web sites maintained
by the various security software vendors.
Creating these charts is a good procedure but it may lead to a
false sense of
confidence. No matter what we prepare for, there will be an attack in
the future that is different from what we have seen before. Having a
large number of procedures to follow should not lead us to become
complacent. We should monitor our systems, and watch for unexpected
behaviors.In "the old days" the IBM company used to put signs on the
wall that simply said THINK. I would find such a
poster more appropriate and more motivating than the numerous motivational slogans
I've seen for many years.
The text proposes that the Business Impact Analysis should
include estimated costs of best, worst, and most likely outcomes of
threat and attacks. These estimates should be clearly labeled as
estimates, not the guarantees that some might hope they are.
More vocabulary lessons under the Incident Response section:
- threat - a potential form
of loss or
damage; many threats are only potential threats
- attack - a threat that has become real
event; sometimes called an exploit, but exploit actually means the method that is used
- incident - The text says an attack is an IT security incident if it is directed at IT assets, if it may succeed, and if it threatens the assets'
confidentiality, integrity, or availability. A great deal of help desk
work could be considered incident response work, although much of it
does not involve IT security. Not all incidents that happen to your
users will be security incidents.
- incident response - The procedure that is
followed when an incident is detected or reported. The text confuses
the idea by telling us that an incident response plan may have components for what to
do before, during, and after an attack. First, not all incidents are attacks.
Second, what you do during and after an incident will certainly be a
response, but what you do before
an incident should really be called something else like defensive
measures or controls.
A great deal of
help desk work could be considered incident response work, although
much of it does not involve IT security. Not all incidents that happen
to your users will be security incidents. The text continues with
several pages what might be done to detect and handle security
incidents. Some useful observations from it:
- a security incident may be indicated by monitoring software, user reports, presence or execution of unknown programs or
- stronger indicators are use of dormant (inactive) or machine accounts, changes to logs that should not
exist, hacker tools found on
- strategies for containment
of viruses and attackers: disconnect
affected devices/circuits, engage firewall
rules to limit or refuse traffic, disable user/device accounts as necessary, disable compromised services
- an analysis of how
the incident occurred should be done to determine how to prevent such incidents in the future
- security incidents typically must be reported to your own
organization, and may have to be reported as crimes
The text moves on to discuss Disaster Recovery Plans for a few
- disaster - The text
proposes that a disaster is what you are having if damage cannot be
contained or controlled, or if it will take some time to recovery to
- disasters can be classified as man-made or natural, which might be most
interesting to your insurance carrier (covered or not covered)
- flexibility - the
text finally considers the idea that your best plans may not be enough,
and should be flexible to accommodate reality
- Disaster recovery plans may or may not include procedures
to follow while the disaster
is occurring. As stated before, the organization you work for may call
these plans by different name or put them in a more reasonable order.
If the plan does not contain
concurrent procedures, those will be in a Business Continuity Plan.
Business Continuity Plans
are discussed next.
In the case of a disaster that makes a work site unusable,
such as a fire or flood, it becomes necessary to have a plan for
alternate means of continuing business. The text lists three types of
off site operation plans:
- cold site - a basic site with office
space, but without computers or other devices that you would have to
supply, without established connectivity, without a data copy unless
you can supply it. Sort of like having to take your laptop to a hotel.
- warm site - has office space, hardware,
and may have connectivity; may have a recent backup of your data, but
it will have to be loaded on computers that may also have to be
configured. Sort of like borrowing office space from another part of
- hot site - a functional duplicate of the
site that has gone down, including office space, computers,
connectivity to the Internet, telephone service, and the capacity to
either load a backup of your data that is stored there, or to use a
copy of your data that is already in place. Welcome to the mirror
- mobile by design
an option the text does not cover is being able to work from anywhere
you have connectivity, perhaps by using a laptop, using services and
drive space on the Internet, and using a software phone that runs on
your laptop. Alternatively, some organizations rely on field staff
using cell phones, smart phones, or tablets in place of "standard"
office equipment to increase mobility and make better use of their time.
Several variables are discussed, but they are best considered
as examples. You need to make plans and arrangements based on the
realities of your organization.
- Do you have multiple sites?
- Are all sites affected by the disaster?
- Can your staff function away from their regular location?