MASARYKOVA UNIVERZITA

FAKULTA INFORMATIKY

•P <?A

%, \J/ &

Business continuity and

disaster recovery for IS

BACHELOR THESIS

Martin Hinca

Brno,2006
Declaration
Hereby I declare, that this paper is my original authorial work, which
I have worked out by my own. All sources, references and literature
used or excerpted during elaboration of this work are properly cited
and listed in complete reference to the due source.

Advisor: doc. RNDr. Vaclav Matyáš, M.Sc, Ph.D.

11
Thanks
I would like to thank my advisor, Mr. Václav Matyáš, for introducing
me to this topic, as well as his guidance and invaluable contribution
to this thesis. My gratitude also belongs to my family and friends, for
their support and seemingly endless patience. And last but not least
to Ms. Miriam Claire, a writer and a friend, for her linguistic touch.

m
Abstract
The objective of this paper is to describe fundamental aspects of busi-
ness continuity planning, disaster recovery planning, and designing
a plan for ensuring continuity in a commercial environment com-
pany. This plan will be presented in two versions: one realistic, taking
into consideration the budget of the company, and the other idealis-
tic, heedless of any funding limits.

IV
Keywords
Business continuity planning, disaster recovery planning, IT security,
disaster preparedness, contingency planning, hazard mitigation, cri-
sis management.

v
Contents
1 Introduction 3
2 Contingency planning in a nutshell 5
2.1 Business continuity planning 5
2.1.1 About BCP 5
2.1.2 BCP components 6
2.1.3 What is a disaster? 6
2.1.4 Most common disaster causes 7
2.1.5 Can disasters be foreseen? 8
2.1.6 Possible disaster impact 8
2.1.7 BCP benefits and objectives 9
2.2 Disaster recovery 11
2.2.1 Disaster recovery plan 11
2.2.2 There's more to DRP than IT 11
2.3 Relation of disaster recovery to BCP 12
3 Creating a business continuity plan 13
3.1 The outline 13
3.2 Initiation of the plan 13
3.2.1 Policy 13
3.2.2 Defining responsibilities 13
3.3 Requirements and strategies 14
3.3.1 Identifying business threats 14
3.3.2 Risk and impact analysis 15
3.3.3 Prevention and recovery strategies 16
3.4 Plan Implementation 17
3.5 Operation and management 17
3.5.1 Testing the BC plan 17
3.5.2 Training and awareness of the staff 18
3.5.3 Reviewing of the plan 19
3.6 Common business continuity planning pitfalls 19
4 Developing a BC plan for VOtech 21

1
 4.1 About VOtech, Ine 21
4.2 Initiating the planning process 22
4.2.1 VOtech resources 22
4.3 Threat identification, risk analysis, and strategy design 23
4.3.1 Neglected threats 23
4.4 Precautions taken 25
5 Conclusion 26
Bibliography 27
Appendix 29
A VOtech risk analysis 29
B VOtech security policy 37
B.l Physical security 37
B.l.l Entering the building 37
B.l.2 Fire protection 37
B.l.3 Containers f or storing backup data 38
B.1.4 Electronic monitoring system 38
B.l.5 Video monitoring system 38
B.2 Hardware and software IS security 38
B.2.1 Uninterrupted Power Supply (UPS) 38
B.2.2 Firewall and separation from the network . . . . 39
B.2.3 OS and application-level authentication 39
B.2.4 Network backup components 39
B.3 Organizational and personal security 40
B.3.1 Access monitoring 40
B.3.2 Building access for visitors 40
B.3.3 Entrance monitoring 40
B.3.4 Creation and storing of backup copies 40

2
Chapter 1

Introduction
Dependence of modern business on its information technology sys-
tem has been growing rapidly during the past decade. And yet sur-
veys keep showing that while technology in terms of power and ef-
fectiveness is steadily progressing at fast pace, IT security still isn't
viewed by many as a necessity. Quite commonly, it is far from the
level that would be appropriate for the consequences, should the sys-
tems it is meant to protect become compromised.
Furthermore, management of many companies would still rather
respond to the disasters as they come, instead of reaching prepared-
ness via creating a business continuity plan, which would serve as a
means of prevention. Experts argue that this is because the aware-
ness about the risks is low within the organization, and in many
cases, the responsibility for security is blurred and unclear. It is diffi-
cult to understand the obvious lack of interest, considering that over
half of the reporting companies indicate that a single hour of down-
time costs them more than $50K [AllOl], and in some cases, the stated
sums climbed well over $5 mil.
Meanwhile, the gap between the increasing security risks and
what companies do to address them continues to widen. Interdepen-
dency between companies has grown to such degree, that security
issues no longer affect only one company, but its business partners
as well.
One of the most persuasive factors that are pushing the interest in
security forward, is the extensive number of regulations and conse-
quences for not complying with them. Still, only 18 per cent of small
companies are able and willing to meet ISO 17799. [You05] [Thi03]
On the brighter side, IT security in every aspect seems to be com-
ing of age. Reported incidents ranging from virus and malware in-

3
 1. I N T R O D U C T I O N

fections, all the way to natural disasters and terrorist attacks, have
added to the overall attention paid to the protection of information
technology. Also, the amount of companies specializing in providing
IT contingency plans is rising.

4
Chapter 2

Contingency planning in a nutshell

2.1 Business continuity planning

2.1.1 About BCP

A business continuity plan (BCP) describes the steps an organization

takes to prevent, or recover from a situation when it cannot oper-
ate normally because of a natural or manmade disaster (2.1.4). It's
objective is to minimize damage to the company, and possibly even
prevent the disaster from occurring in the first place.
Because a majority of organizations are new to computers and
networks, have never experienced a disaster, are unable or unwilling
to finance the planning effort, believe it will never happen to them,
or feel they can deal with the problems if and as they happen, they
discount the need for continuity planning.
However, literature shows that four out of five impacted organi-
zations do not survive one year, and ultimately, only one tenth sur-
vives five years. Businesses need their computers, although usually
the information stored in them is more valuable than the hardware,
and can continue operations without them for only four days, on av-
erage. [Nem97] For most companies, even those four days mean that
their day-to-day processes are disrupted.
While experts differ on this subject, most of them consider busi-
ness continuity planning to be a shelter for entire organizations. It
is possible to create a business continuity plan for a specific process,
but there is no doubt that a working plan must address all mission-
critical business processes.

5
 2. C O N T I N G E N C Y P L A N N I N G IN A NUTSHELL

2.1.2 BCP components

A business continuity plan is an umbrella plan whose major sub-

components include the disaster recovery plan, and consists of fol-
lowing plans [Bah03]:

• Business Resumption Plan

• Occupant Emergency Plan

• Incident Management Plan

• Continuity of Operations Plan

• Disaster Recovery Plan

The Business Resumption Plan, Occupant Emergency Plan and

Continuity of Operation Plan do not deal with the company's IT in-
frastructure. The Incident Management Plan establishes a structure
and procedures to address attacks against the IT infrastructure of the
organization. If successful, it does not involve activation of the Dis-
aster Recovery Plan. The only sub-plan I will consider important in
further detail is the DRP.
According to some authors, business continuity planning only
deals with prevention. [Lam02] Once a disaster occurs, they claim
that it is the business recovery planning that kicks in. In this paper, I
will consider business recovery being part of continuity planning.

2.1.3 What is a disaster?

A disaster is defined as a sudden, unplanned event that hampers nor-

mal operation of the organization, or disrupts its critical processes.
Possible consequences of a disaster include damage to a wide range
of resources, such as premises, important data, employees, ability to
generate revenue, loss of capital, reputation and confidence, or even
complete loss of control over the company. [Bah03]

6
 2. C O N T I N G E N C Y P L A N N I N G IN A NUTSHELL

2.1.4 Most common disaster causes

While some authors divide and classify the disasters according to

what they affect, others divide them according to their nature. [Hal04]
At this theoretical stage, I prefer the latter.

• Manmade

fraud, theft, blackmail

- cybernetic attacks (hacking, viruses, malware)
sabotage, arson
- terrorism

• Natural disasters

- fire, floods, hurricane, earthquake...

- pollution, contamination

• Technical failures

- communication network failure

- power failure
- failure of information technology or software
- transportation failure

However, it is very important to realize that we should not plan

recovery from a specific type of disaster, but rather how to carry on
the goals of an organization in spite of anything. [Nem97] It makes
no sense to plan specifically for a disaster by fire or by flood. Instead,
planning for site loss, key personnel loss, communications disrup-
tion, or a vast loss of data is a lot more appropriate. It is, of course,
a good idea to discuss an expected high impact disaster individually,
but always in the context of an overall plan. [LL04]

7
 2. C O N T I N G E N C Y P L A N N I N G IN A NUTSHELL

2.1.5 Can disasters be foreseen?

The greatest risk to the organization is that a disaster can happen
without an adequate warning. Although sometimes it can be pre-
dicted that something likely to undermine the organization is going
to happen, most accidents and failures are not really foreseeable.
However, the notion that events like these are truly unforeseen
is spurious, as academics have always argued that all systems have
a propensity towards failure. [Smi90] Therefore, it makes no sense
for managers to consider if a system will fail, but rather, when that
will happen. It is possible to assume and accept the premise that all
organizations will face a crisis at some point in their lifespan.
Even though a warning may be issued beforehand, it will usu-
ally be too late, anyway. Even two or three days may not be enough.
Apart from evacuating the site to protect from a natural disaster, for
example, a lot of other things need to be done. Backing up the sys-
tem, expediting the essential orders as part of a vendor chain, or even
buying material needed during the aftermath; everything takes a lot
of time, and time is exactly what a disaster-struck company does not
have.

2.1.6 Possible disaster impact

Without a proper business continuity plan, the threats mentioned
in 2.1.4 can negatively impact vital components of the organization.
Business continuity planning is meant to protect:

• Public image of the company

• Revenue generation

• Market share

• Customer, employee and shareholder confidence

• Essential services the organization provides

• Health of its employees

• Position within a vendor chain, and more...

8
 2. C O N T I N G E N C Y P L A N N I N G IN A NUTSHELL

These factors are of high importance, and often considered es-

sential to most organizations. Many people in top-level management
are convinced that the mentioned threats will avoid their company.
Others would think that it is enough to pay insurance for the com-
pany, which is ready to cover the damage. Unfortunately, those opin-
ions are not based on experience, but on wishful thinking. IT Security
surveys show that an organization must be able to confront disasters
successfully in order to prosper. [Hal04]
It is obvious that proper and systematic prevention is cheaper
and more effective than recovering from the damage that could occur
without being prepared for it.
Fault-tolerance techniques have been deployed to increase com-
puter system availability, as well as to reduce the damage caused by
a component failure. But even though vital data can be stored on sta-
ble storage that is able to survive failures such as electrical outages
or system crashes, this will not be of much help if, for example, a nat-
ural disaster strikes. Not even placing redundant copies in multiple
places will help, if they are stored in the affected area. This approach
only protects against single device failures. [CLWOO]

2.1.7 BCP benefits and objectives

The most important reason organizations develop business continu-
ity plans is to guarantee speedy and cost-effective recovery of criti-
cal business processes following a disaster. Furthermore, a good and
comprehensive business continuity plan will have a series of benefits
for the organization:

• Make anticipation and prevention of critical situations possi-

ble.
• Reduce the need for making decisions under stress and time
pressure.
• Allow the entire staff be instructed on their responsibilities in
the event of a disaster.
• Let the organization develop various contingency arrangements
• Enable the company to meet various security requirements.

9
 2. C O N T I N G E N C Y P L A N N I N G IN A NUTSHELL

• Allow exposure of weaknesses in the plans by thorough test­

ing.

• Reduce the overall risk to the organization.

• Provide the company with a reasonable outlook to present to

its shareholders.
• Greatly decrease the impact of disasters, as described in 2.1.6.

The first and foremost objective of business continuity, however,

is the survival of the organization as a whole. Processes critical for
company's very existence must be restored in this first phase. Once
the state of the organization is stabilized, a long-term recovery of all
processes can be initiated.

S ^
sPtŕ
jŕ <fs (U

ŕ
K /t K / i r^/i
v/\( i/\j t/V -y

disaster original
strike state

Figure 2.1: Order of actions following a crisis

This makes sense - if the organization goes bankrupt because its

critical functions are disrupted, it is pointless to plot full recovery.
It is this first survival phase that is most important to the whole
mission. It needs to be planned thoroughly by anticipating as many
potential problems as possible, and developing strategies capable of
solving them.
While managing an incident, it is important to understand that
a large number of business-critical decisions will need to be taken in
a very short timespan. Furthermore, the people responsible will be
under a great amount of stress, and will be working outside of their

10
 2. C O N T I N G E N C Y P L A N N I N G IN A NUTSHELL

normal posts. Therefore, when possible, it is a good idea to plan in

as much detail as possible. Making at least some of the decisions in
advance will relieve the pressure and benefit the recovery process
greatly.
The long-term recovery phase needs only outline planning, be-
cause there will be time to plan the details when the company has
been stabilized, and the precise details of the recovery process known.
[SS95] Thus, it is more effective to consider in terms of broad strate-
gies only, instead of detailed tactics.

2.2 Disaster recovery

2.2.1 Disaster recovery plan
The focus of a disaster recovery plan (DRP) is to restore the oper-
ability of systems that support critical business processes, so that the
organization can return to normal mode of operation as soon as pos-
sible, thus minimizing the damage. Since many critical processes de-
pend on an information technology infrastructure, the DRP is an IT
focused plan.
Restoration of systems does not necessarily imply technology re-
dundancy. Workflows that would be automatized under normal cir-
cumstances may have to be completed manually when DRP kicks in.
A good example is accountancy. The decision of what to do manually
in the critical event is cost-driven, and based solely on the manage-
ment of the organization.
Having a DRP in place reduces the risk of going beyond the length
of time the business process takes, according to what has been deter-
mined acceptable by management within the organization. During
the recovery phase, the focus is on establishing controls over occur-
ring events to limit the risk of any additional losses. [Bah03]

2.2.2 There's more to DRP than IT

By planning for computer disaster recovery, the need to plan for the
recovery of other business services can become less obvious. With
a "tick in the box" for computer recovery, managers may overlook
planning for the reinstatement of other, similarly critical services. Al-

ii
 2. C O N T I N G E N C Y P L A N N I N G IN A NUTSHELL

though it might not be apparent, disaster recovery is more than just

the recovery of information technology. There is a lot more to con-
sider. For example, manpower to operate the system must be pro-
vided. Also, it is important to realize that the reputation of an or-
ganization is often more fragile and essential, than an information
system that works without interruption, and deserves equal atten-
tion [SS95]. Consequently, it is not enough to prepare information
technology systems only, but due to the nature of this paper, we will
focus on IT.

2.3 Relation of disaster recovery to BCP

The relation between DRP and BCP is not very clear. Having studied
an extensive amount of literature, I have concluded that the most
sensible view is the one that declares disaster recovery as a subset of
business continuity planning, as presented in 2.1.1, [CC04].
However, some authors consider disaster recovery planning to
be on the same level as disaster recovery. In [Dav03], the author in-
troduces comprehensive emergency management program (CEMP),
and claims that both BCP and DRP are parts of it, along with mit-
igation, business resumption, and contingency planning. However,
even according to this paper, the main difference is that while disas-
ter recovery mostly covers information technology and data recov-
ery, business continuity cares about business processes and how to
recover them. Still, disaster recovery is not only concerned with in-
formation technology (see 2.2.2). Some say that BCP kicks in once the
event has been stabilized to a certain degree, thanks to DRP-based
recovery [Cas04].
Disaster problems may begin with a lack of appreciation for the
differences between business continuity planning and disaster recov-
ery planning, because there is a difference between having insurance
to cover a disaster and strategizing so that an organization can con-
tinue to thrive under adverse conditions. [Nem97] The point is that
it is not sufficient to make recovery plans and buy insurance policies
for disaster recovery, when so many things can go wrong, and create
an unanticipated impact.

12
Chapter 3

Creating a business continuity plan

3.1 The outline

A business continuity plan is cyclical in nature. The reason for this
is, that most organizations constantly change themselves. They de-
velop, grow, introduce new workflows and processes, and the cre-
ated plan becomes obsolete relatively soon. Therefore, it is impera-
tive that the plan must be reviewed and updated regularly, in order
to reflect on any changes that might have occurred.
Unless mentioned otherwise, the bibliography used throughout
this chapter is [Hal04], [Lam02], [Rik03] and [SS95].

3.2 Initiation of the plan

3.2.1 Policy
An organization's security policy must be at the foundation of ev-
ery BC plan. Usually, it is issued by the senior management of the
company, and expresses that a BC plan needs to be created and im-
plemented. This policy delegates authority to the people in charge of
developing the plan, and allows the planning activity to commence.
It may provide basic guidelines for the plan, a timeframe in which
the plan is expected to be ready, budget expectations, or even spe-
cific requirements.

3.2.2 Defining responsibilities

The responsibilities for a BC plan must be clearly declared. While
it is a good idea for those responsibilities to be given to a senior-

13
 3. CREATING A BUSINESS CONTINUITY PLAN

level manager, frameworks should also allow delegation of particu-

lar tasks to staff with the appropriate business and technical exper-
tise.
Along with planning responsibilities, incident management re-
sponsibilities also need to be specified. Though it is worth consider-
ing to map those within the normal company management hierarchy,
it is not necessary. If the organizational structure is too complicated,
it should be simplified, because complex day-to-day management
does not work well in times of crisis.

3.3 Requirements and strategies

3.3.1 Identifying business threats
The most important resources for an IT-based organization could be
divided into three types: technology, information, and people. In this
phase of plan development, it should be considered what threats
may negatively affect the ability to use, or readily access those re-
sources.

• Technology threats include failure of IT, fire, power failure, nat-

ural disasters, various cybernetic attacks, viruses, theft, sabo-
tage, terrorism, or vandalism.

• Information resources often closely depend on technology, so

any threat that affects technology can also lead to loss of infor-
mation. Additionally, the data must be protected against alter-
ation, misuse, fraud, theft, fabrication, and end of information
carrier lifespan.

• Threats to people include disease outbreaks, resignations, the

inability of the organization to employ new people, pregnancy,
strikes, adverse weather conditions, or unavailability of trans-
portation or office access.

Conducting threat identification workshops within the organiza-

tion is a very good approach, because some threats are industry-
specific, and not obvious at all. There are also other resource types

14
 3. CREATING A BUSINESS CONTINUITY PLAN

worth considering, such as premises, equipment, services, or com-

munications.
Every threat has a typical and a worst-case scenario, and the plan
should cover both, according to their likelihood. Additionally, both
permanent and temporary resource loss scenarios should be consid-
ered.
Generally, the resources that need protecting would need to be
listed by examining the most vital business processes, and trying to
find out what resources they need to keep running. However, as this
paper is focused on information system continuity planning, other
resources will not be discussed in detail.

3.3.2 Risk and impact analysis

It is necessary to identify, quantify and prioritize the level of risk to
the business continuity of the organization. Risk is a factor that con-
siders the likelihood of the threat actually occurring, and its impact
on the organization's properties, such as those mentioned in 2.1.6.
The seriousness of each risk depends on the particular organiza-
tion. For example, a company that mostly operates within a vendor
chain values this position, and making their deliveries, more so than
its public image.
The higher the likelihood of a threat occurring, the higher the risk.
This likelihood can range from rare to almost certain, although speci-
fying it exactly can be very difficult at times. Likewise, the risk grows
with the consequences of a particular threat. The consequences can
move on a scale from minor to catastrophic, and specifying the conse-
quences of a threat is usually easier than determining its likelihood.
As the relations between specific factors in risk analysis are rather
complex, they are illustrated by the figure 3.1.
Most BC plans characterize the risks as low, medium, high, or
critical. High or critical risks would be those that are likely to occur,
and would result in major consequences. Therefore, preparing to face
them is of high priority.
An organization should make it clear what level of risk it consid-
ers acceptable, and which treats can be ignored because their conse-
quences or their likelihood are too insignificant.
This phase is often referred to as business impact analysis (BIA).

15
 3. CREATING A BUSINESS CONTINUITY PLAN

benefit from
Threats Vulnerabilities

protect increase increase/ jeopardize

against.

decrease
Security Functions Risks Resources

are met by introduce increases 1 have

Security Requirements Value

Figure 3.1: Risk relation diagram [Sta05]

3.3.3 Prevention and recovery strategies

For each of the risks that the organization has not chosen to ignore,
a strategy must be implemented to prevent the risk from taking place,
or recovering afterwards. These strategies will provide an outline of
the actions to be taken in the event of the threat occurring. The choice
of BC strategies is important, because it often affects the overall de-
sign of the system.
For each of the strategies, a more detailed tactical plan has to
be created, which will show how the response and recovery will be
executed. It is important to consider several criteria when deciding
which strategy to choose:

• Overall cost and time of implementing the strategy, including

deployment, training and testing.

• Level of protection the strategy offers.

• Other potential benefits, or drawbacks, to the organization.

• The amount of time it takes to restore normal operations.

16
 3. CREATING A BUSINESS CONTINUITY PLAN

Various strategies have various costs and levels of effectiveness.

Whether it pays off to implement an expensive strategy, or is safe to
trust a less reliable one, greatly depends on the level of the risk.
It is a good idea to establish crisis teams in advance. Those teams
may or may not be the same for each recovery strategy. Clear objec-
tives, responsibilities, and roles need to be assigned to specific mem-
bers of the team. Authorities and means of communication within
the team should also be covered. [HSOO]

3.4 Plan Implementation

The phase should begin with a short planning process, where specific
details are set, the implementation objectives are rehearsed for the
last time, and the team is synchronized. It is a good idea to divide the
implementation process into two or three parts, dealing with standby
arrangements and risk reduction measures, or recovery plans and
strategies respectively.
The particular mode of implementation often differs greatly from
plan to plan, because steps to ensure continuity for various compa-
nies are rarely the same.

3.5 Operation and management

3.5.1 Testing the BC plan

Before completing the planning process, the plan needs to be tested

thoroughly. This is done mostly to identify possible shortcomings
and flaws of the plan, and to ensure that it works as expected. How-
ever, it is also done to evaluate effectiveness of the plan, and give the
management of the organization a feeling of confidence.
As testing a large-scale plan may take a lot of time, it is important
to consider what testing would do to day-to-day operations of the
company. If the testing would disrupt business processes as much as
a disaster, it would defeat the whole purpose of planning.
Testing needs to be repeated until the plan matches the carefully
set performance criteria.

17
 3. CREATING A BUSINESS CONTINUITY PLAN

3.5.2 Training and awareness of the staff

Although this is normally not part of the planning process, even the
best laid plans can (and often do) go astray, because the details of the
plans may not be effectively communicated to the people responsible
for their implementation. Thus, I believe that training the staff is an
important step on the way to business continuity.
Clearly, a plan is only as good as the ability of the organization to
implement it. And that ability is highly dependent upon how famil-
iar and proficient are the staff members with the BC plan, as well as
executing the tasks. Even the least complicated plans require many
complex and interdependent tasks to be executed in coordination,
and under pressure.
It is unthinkable that the first time the staff will be reading and
trying to understand the plan, will be during the stressful hours fol-
lowing a disaster. But they also cannot be expected to read the BC
plan diligently, and learn their role by heart in advance, no matter
how well it is documented. Actually, it would be idealistic to expect
that most of them will even skim through the plan once. [Mor98]
Consequently, it is very important to take care that the plan is
conveyed to the employees in as efficient a way as possible. Keith
Hearnden describes and evaluates in his work a number of ways of
doing that. [Hea95]
As the most effective way, he considers a personal memo deliv-
ered to each and every employee, and compulsory training to in-
duce the plan. Though a little less effective, a less obtrusive approach
would be to incorporate the plan into staff handbook, conducting an
optional training, or sending the plan to everybody in an e-mail. As
poor, or even disastrous, he describes choosing an approach which
relies on the initiative of the employees. Documentation only avail-
able on request, or even no formal procedure, such as word of mouth,
can be an unpleasant setback for the BC plan quality. [Pat99]
Hearnden also claims that only a third of companies incorporate
said policies into their terms and conditions of employment, and that
only about 28 per cent of employees receive proper instructions and
training regarding an organizations' computer systems and security
policies.

18
 3. CREATING A BUSINESS CONTINUITY PLAN

3.5.3 Reviewing of the plan

As mentioned in the beginning of this chapter (3.1), the BCP is a cycli-

cal plan. Because the environment of the plan changes all the time,
each plan must have a framework within which it can be reviewed
and modified on both a periodical basis and in response to changes
in the company policy, or with respect to results of the testing of the
plan.
Among other impulses that require changes in the plan belong
changes in laws or regulations concerning the plan, developments
and upgrades within the organizations IT infrastructure, changes in
the market, and many other things that affect the organization in all
but the most subtle ways.
If a misconception in the plan is detected, the planning process
must restart in order to modify the former plan accordingly.

3.6 Common business continuity planning pitfalls

There are several common pitfalls one should heed when creating
a business continuity plan. It is considered to be a a strong indication
of low quality when the plans fall into one of the listed categories
[Lam02]:

Incomplete - The BCP process is not complete. Outputs such as the

business continuity plan and policy either do not exist, or exist
in incomplete form.

Inadequate - The plan and strategies can't deal with the level of risk
that the organization deems acceptable.

Impractical - The plan is not practical or achievable within the or-

ganization's constraints (manpower, time, and budget, for ex-
ample).

Overkill - The plan is overly elaborate or costly with respect to the

overall level of business risk that the organization is willing to
take.

19
 3. CREATING A BUSINESS CONTINUITY PLAN

Not communicated - The business continuity team has not commu-

nicated the plan to all the right people. Staff, both management
and technical, remains unaware of business continuity issues.

Lacking a defined process - Business continuity processes remain ill

defined. Staffers are unsure of how to react in a failure scenario,
or they discover too late that their existing processes fall short.

Untested - The organization hasn't tested its plan, or hasn't tested it

thoroughly enough to provide a high level of confidence in its
soundness.

Uncoordinated - The business continuity effort lacks organization

and coordination. The organization has either not established
a business continuity team, or the team lacks individuals who
can effectively drive the effort to completion.

Out of date - The plan hasn't been reviewed or revised in light of

changes in the organization, its business, or technology.

Lacking in recovery thinking - The organization doesn't adequately

address how it intends to recover to a fully operational state af-
ter executing its business continuity plans.

20
Chapter 4

Developing a BC plan for VOtech

4.1 About VOtech, Inc.

VOtech, Inc. is a young and progressive company employing around

a hundred people, dealing in information system integration and
communication networks. The company is Slovak, with headquar-
ters located in Bratislava, and two branches in Banská Bystrica and
Košice, ordered by size.
The branches are far less important to critical business processes
than the main building in Bratislava. The branch in Banská Bystrica
is reasonably large and equipped to serve as a warm-site.
As I am going to present a lot of sensitive information about
the company's security in this chapter, after discussing this with its
top management, I am going to keep the company anonymous -
"VOtech" is an assumed name. The company is not fictional, how-
ever, nor is any information provided in this chapter.
The company has a database of its customers' and partners' pri-
vate data, and even deals with classified information (according to
§6 of the law published in Collection of Laws under Nr. 215/2004 in
Slovakia). Along with the company's know-how and internal doc-
uments, protection of the information against theft, loss, damage,
unauthorized access, modification and propagation, is the highest
priority security objective of VOtech. This is a result of the company's
commitment, as well as local laws and regulations (§19 of the law
published in Collection of Laws under Nr. 428/2002 in Slovakia).

21
 4. DEVELOPING A BC PLAN FOR V O T E C H

4.2 Initiating the planning process

It was clear from the very beginning, that this business continuity
plan would be slightly different from a typical one, because of the
circumstances. First of all, only the initial phases of plan creation are
covered, as the company will decide about possible implementation
when the preliminary plan has been created and delivered. Defining
responsibilities for this project doesn't make sense, neither.
Also, I am the only person working on the plan, which is some-
what of a setback, because usually an entire team of professionals
works on the plan to an extent far exceeding the scope of this paper.
Therefore, subtle differences to the theoretical process described in
chapter 3 had to be admitted.
I was pleasantly surprised by the enthusiasm the CEO of VOtech
showed, when he was presented with my proposal. He gave me the
green light, privilege and access to necessary information on a need-
to-know basis, and a much valued contact within the company's high
level management.
It's also important to note that this company had a security policy
and a basic recovery plan in place prior to my engagement. However,
the plan was not quite detailed, was in place mostly to oblige the
slovak laws and regulations, and could hardly be used in the times
of crisis.

4.2.1 VOtech resources

The following company resources have been identified:

• Data representing company know-how, finance and accoun-

tancy, marketing details, private vendor and customer data,
security details.

• Information system, and its continuous availability.

• Company property, buildings and equipment.

• Security of employees, and their private property.

22
 4. DEVELOPING A BC PLAN FOR V O T E C H

4.3 Threat identification, risk analysis, and strategy

design
Considering that my role is only to design the plan in theory, this
is unquestionably the most important phase. I have identified the
threats that could disturb the mission-critical processes of VOtech,
with focus on its information system, and summarized the details.
As the tables take up a lot of space, I will mention only a single sam-
ple risk (table 4.1) in this chapter, and move the rest of them to the
appendix A.
Please note that in order to avoid redundancy, both plan ver-
sions are presented at once. The high budget precautions and strat-
egy fields refer to the second plan version, which has little or no
funding limitations. The high budget plan expects the company to
buy an alternate facility in a different city, and equip it to serve as a
hot-site. This facility should be able to take over any critical business
process of the company in as little as a day, preferably sooner.

4.3.1 Neglected threats

This plan will propose reasonable arrangements to protect the com-
pany's resources against theft, loss, damage, unauthorized access,
modification, and propagation. However, there is a variety of threats
that are difficult to predict, with the likeliness estimated to be very
low, and possible prevention too expensive and ineffective, which
are left out deliberately. Most obvious are natural disasters, except
fire, because the area is deemed to be safe in this accord. Also, ba-
sically uncovered are criminal activities targeting people, such as
blackmail, and various accidents that the company cannot affect.

23
 4. DEVELOPING A BC PLAN FOR V O T E C H

Information system failure

This threat affects: Integrity and availability of data, IS
accessibility.
Typical scenario: Failure affects some systems, the re-
pair time is short
Worst case scenario: Failure affects all systems, recovery
time is long
Likeliness: medium
Level of impact: high
Seriousness: high
Precautions taken: Regular maintenance of IT, duplica-
tion and backup of data.
Continuity strategy: The company will have third-party
service agreement with guaranteed
on-site response time. In the worst
case scenario, the branch in Banská
Bystrica will serve as a warm-site.
High budget precautions: Doubling the amount of back up and
buying a replacement server to mirror
each company server, and keep them
on hot standby.
High budget strategy: Servers at the hot-site will take over
in a few hours, and traffic will be re-
routed there. The hot-site will be able
to keep the processes that are in dan-
ger of disruption running, while the
main servers are being repaired.

Table 4.1: Sample threat, information system failure

24
 4. DEVELOPING A BC PLAN FOR V O T E C H

4.4 Precautions taken

VOtech will take precautions and implement the following protec-
tive systems as a part of its business continuity planning:

• System of physical protection of its premises.

• Electronic access monitoring and control system.

• Industrial video monitoring system.

• Visitor registration procedure.

• Authentication system to access data in its network and IS.

• Fire alarms placed around the building.

• User access monitoring system.

• Network protection against access from the outside.

• Regular maintenance of IS components.

• Backup and archiving system.

For implementation details of these precautions, please refer to

appendix B.

25
Chapter 5

Conclusion
I was surprised at the lack of consistent, authoritative and univer-
sally valid information in this field. Business continuity planning is
not a young field within the area of information system security, and
yet I was unable to find an authoritative source of information. There
are very few books on this topic, which is believed to be caused by
the lack of market enthusiasm. Most continuity planning providers
jealously guard their know-how, so basically the only sources of in-
formation are generic articles, which IT journals occasionally pub-
lish.
However, while authors of renowned journals often differ on the
formalities of the plans, the core and principles thankfully remain the
same. This has led me to believe that the form is not very important
compared to the plan itself, and differences are tolerated. Business
continuity planning is more about common sense, than about elabo-
rate documents, or expensive software.
In other words, it doesn't really matter how the plan of a com-
pany is formulated and structured. It is only important to make sure
that a good plan, which doesn't have any fatal flaws like the ones
mentioned in section 3.6, is in place.
Contrary to how people often misinterpret BCP, it is not just an
on/off property. It's not sufficient to say that you have a continuity
plan, because proper planning is continuous and ever-changing, ad-
equately responding to changes and progress in the company itself.
Business continuity plans are not unlike insurance — although
the organizations hope they won't have to use the plan, in case some-
thing goes wrong, they benefit greatly if they do. After all, there must
be a reason why companies specializing in disaster recovery profit so
greatly compared to those providing continuity plans.

26
Bibliography
[AllOl] Eagle Rock Alliance. Cost of downtime. 2001.
[Bah03] Chad Bahan. The disaster recovery plan. Information Se­
curity Reading Room, SANS Institute, June 2003.
[Bre98] Robert Breton. Replication strategies for high availability
and disaster recovery. Bulletin of the IEEE Computer Soci­
ety Technical Committee on Data Engineering, 1998.
[Cas04] Carolyn Castillo. Disaster preparedness and business con­
tinuity planning at Boeing: An integrated model. Journal
of Facilities Management, 3(l):8-26, March 2004.
[CC04] Virginia Cerullo and Michael J. Cerullo. Business conti­
nuity planning: A comprehensive approach. Information
System Management Journal, 2004.
[CLW00] Manhoi Choy, Hong Va Leong, and Man Hon Wong. Dis­
aster recovery techniques for database systems. Commu­
nications of the ACM, pages 272-280, 2000.
[Dav03] Steve Davis. Developing continuity in government plan­
ning. Disaster Recovery Journal, 16, Spring 2003.
[Hal04] Jiří Halouzka. Příručka manažera - business continuity
planning. DSM, Časopis o bezpečnosti, správě, a řízení
rizik informačních systémů, 2004.
[Hea95] Keith Hearnden. Business continuity planning: Part 1, con­
temporary issues in corporate computing. Computer Au­
dit Update, pages 3-10, May 1995.
[HS00] Petr Hanáček and Jan Staudek. Bezpečnost informačních
systémů. Úřad pro státní informační systém, 2000.

27
 5. C O N C L U S I O N

[Lam02] Wing Lam. Ensuring business continuity. IT Pro, pages

19-25, May, June 2002.

[LetOl] Nick Lethbridge. Impact of information warfare on busi-

ness continuity planning. Australian Information Warfare
and Security Conference, 2:21-28, 2001.

[LL04] Patricia Y. Logan and Stephen W Logan. Bitten by a bug:

A case study in malware infection. Journal oflnformation
Systems Education, 14:301-305, march 2004.

[Mor98] Gregory Morwood. Business continuity: awareness and

training programmes. Information Management & Com-
puter Security, 6/1:28-32,1998.

[Nem97] Martin Nemzow. Business continuity planning. Interna-

tionaljournal of network management, 7:127-136,1997.

[Pat99] Douglas Paton. Disaster business continuity: promoting

staff capability. Disaster Prevention and Management,
8(2):127-133,1999.

[Rik03] Barb Rike. Prepared or not... that is the vital question. In-
formation Management Journal, May-June 2003.

[Smi90] Denis Smith. Beyond contingency planning: towards a

model of crisis management. Industrial Crisis Quarterly,
4:263-275,1990.

[SS95] Martin Smith and John Sherwood. Business continuity

planning. Computers & Security, 14:14-23,1995.

[Sta05] Jan Staudek. Analýza rizik a tvorba havarijního plánu,

2005.

[Thi03] Val Thiagarajan. BS 7799 audit check list. SANS institute,

2003.

[You05] Ernst & Young. Global information security survey. 2005.

28
Appendix A

VOtech risk analysis

 A. VOTECH RISK ANALYSIS

Fire
This threat may affect: Integrity and availability of data,
building, hardware, and employees.
Typical scenario: Destruction of equipment in a single
server room.
Worst case scenario: Complete loss of the building and ev-
erything inside.
Likeliness: low
Level of impact: high
Seriousness: medium
Precautions taken: Fire extinguishers and alarms are
placed around the building. Servers
are placed in safe zones around the
building, and data is backed up.
Continuity strategy: The roles of the impacted servers
will be delegated to different servers
for the several days it'd take to re-
build that part of the building and get
new hardware up and running. In the
worst case scenario, it is possible to
move essential processes to a different
branch temporarily.
High budget precautions: Installing a fire-extinguishing system
and fire-resistant barriers throughout
the building.
High budget strategy: The hot-site will take over all pro-
cesses that have been disrupted,
while the damage is being repaired.

Table A.l: Fire

30
 A. V O T E C H RISK ANALYSIS

Unauthorized system access, data theft

This threat may affect: Confidentiality of data, information
system availability, company reputa-
tion.
Typical scenario: A random attacker gains access into
some of company's system from the
Internet, and downloads some pri-
vate data.
Worst case scenario: Professional attackers steal a spe-
cific data important to them, leaving
heavy damage to the IS in their wake.
Likeliness: low
Level of impact: high
Seriousness: high
Precautions taken: Network is protected against access
from the Internet, users have to au-
thenticate properly before accessing
any important data.The computers
storing classified information are not
networked, and the access is con-
trolled physically, as mentioned in
B.1.4.
Continuity strategy: Information about the extent of the
data leak must be gathered first, in
order to evaluate the situation. The
company will fix the security hole,
and if containing the data is not pos-
sible, try to restore confidence in its
security system among its customers
and partners.
High budget precautions: Additional means of authentication
will be obtained, and combined au-
thentication, such as fingerprints or
iris scans plus passwords will be re-
quired to access sensitive informa-
tion.
High budget strategy: No modifications.

Table A.2: Unauthorized system access, data theft 31

 A. V O T E C H RISK ANALYSIS

Virus, trojan, or malware infection

This threat may affect: Confidentiality of data, information
system availability, company reputa-
tion.
Typical scenario: A several personal computers are in-
fected, virus doesn't spread through-
out the company, recovery takes less
than a day.
Worst case scenario: Every networked computer is in-
fected, important data leaked, or lost.
Repair time up to a week.
Likeliness: medium
Level of impact: high
Seriousness: high
Precautions taken: Network is protected by a firewall
and an intrusion detection system.
Computers are protected by antivirus
software. Data recovery is ensured by
backup.
Continuity strategy: The company will have third-party
service agreement with guaranteed
on-site response time. In the worst
case scenario, the branch in Banská
Bystrica will serve as a warm-site.
High budget precautions: No modifications.
High budget strategy: Servers at the hot-site will take over
in a few hours, and traffic will be re-
routed there. The hot-site will be able
to keep the processes that are in dan-
ger of disruption running, while the
IT infrastructure is being cleaned.

Table A.3: Virus, trojan, or malware infection

32
 A. V O T E C H RISK ANALYSIS

Communication services provider failure

This threat may affect: Timely communication within the
company, availability of data.
Typical scenario: Internet service provider network ac-
cess is down, short repair time.
Worst case scenario: Complete loss of communication abil-
ities, repair time lengthy.
Likeliness: medium
Level of impact: low to high
Seriousness: medium
Precautions taken: Company has multiple communica-
tion channels in use, the probability
that all of them are off-line is very low.
Continuity strategy: Depending on the nature of the fail-
ure, restoration will be attempted, or
alternative means of communication
will be devised.
High budget precautions: Company buys satellite communica-
tion services.
High budget strategy: Company pays a third party provider
to provide essential communication
ASAP.

Table A.4: Communication services provider failure

33
 A. VOTECH RISK ANALYSIS

Power failure
This threat may affect: Availability of IS and data, continuity
of most processes.
Typical scenario: Power outage takes no more than an
hour.
Worst case scenario: The time without power is long, pos-
sibly due to a different disaster.
Likeliness: medium
Level of impact: low to high
Seriousness: medium
Precautions taken: An uninterrupted power supply de-
vice that can keep servers running for
several hours will be installed.
Continuity strategy: The network backbone and vital sys-
tems will be immediately switched to
the backup power source, which will
be able to provide enough power for
safe termination of applications and
devices, preventing corruption of the
data being processed.
High budget precautions: A stronger UPS system, able to keep
hardware in the entire building run-
ning for several hours will be in-
stalled. The company will also buy
a power generator, able to produce
enough power for the entire build-
ing with enough fuel for several days.
Emergency low-power lights will also
be installed.
High budget strategy: The UPS system will kick in instantly,
the generator might be turned on
manually later, depending on the out-
look of the situation.

Table A3: Power failure

34
 A. V O T E C H RISK ANALYSIS

Unauthorized physical access to the building

This threat may affect: Availability and confidentiality of
data and IS, lifes and health of em-
ployees, classified information secu-
rity. ..
Typical scenario: A burglar enters the building at night,
with the intention to steal hardware
or data.
Worst case scenario: An armed group takes the building
by force, possibly creating a hostage
situation.
Likeliness: low
Level of impact: high
Seriousness: high
Precautions taken: The building will only be possible to
enter via the main entrance, which
will be locked from the outside at
all times. All visitors will be logged
and guided by a janitor. The building
will be monitored by electronic access
control, and an industrial video sys-
tem.
Continuity strategy: At any breach, a third party security
company will be contacted immedi-
ately. They should be able to secure
the building within several minutes.
The police will also be notified.
High budget precautions: The company will hire several armed
guards, who will be monitoring the
premises at all times. Security barriers
will be installed.
High budget strategy: If the intrusion can't be dealt with by
normal means, the building will enter
a lockdown mode.

Table A.6: Unauthorized physical access to the building

35
 A. V O T E C H RISK ANALYSIS

Human error
This threat may affect: Availability of data and IS
Typical scenario: An incorrect command is entered,
and it does damage to an important
database.
Worst case scenario: A security administrator's mistake
leaves the company network open to
an attack.
Likeliness: medium
Level of impact: high
Seriousness: high
Precautions taken: All employees are properly trained,
depending on their position in the
company. The system will be regu-
larly checked for possible mistakes.
Continuity strategy: Largely depends on the mistake
caused. Typically, a team will be cre-
ated to undo the damage, and backup
tapes can be used to recover the data.
High budget precautions: A team of third party consultants will
be hired to help cope with this possi-
bility.
High budget strategy: In the event of critical processes being
disturbed, the hot-site will take over.

Table A. 7: Human error

36
Appendix B

VOtech security policy

This security policy has been created by modifying current security

policy of VOtech, so that it meets the requirements laid by the pro-
posed business continuity plan.

B.l Physical security

Physical security of the system will be controlling the access to IS
resources. Every person entering the building will be checked and
monitored. The building itself will be divided into several security
zones, preventing uncontrolled access to sensitive parts of the build-
ing. This precaution will be applied even to company employees,
who will be authorized to enter certain zones only.
The premises will be protected by an industrial video monitoring
system, with an alarm connected to a central protection system of
a private security service company.

B.l.l Entering the building

Entering the building for visitors is only possible via the main en-
trance. The entrance will be locked from the outside at all times, and
visitors will be able to ask for permission to enter using an electronic
gate control. Access through other entrances will be prevented by
making them impossible to open from the outside.

B.1.2 Fire protection

Fire extinguishers and alarms are placed in sufficient amounts all
around the building.

37
 B. V O T E C H S E C U R I T Y P O L I C Y

B.1.3 Containers for storing backup data

For safe storage of backup data, containers with proper security level
must be created. An electronic copy will be stored on a tape in a safe
of the company's CEO. Paper copies will be kept in a metal locker in
one of the higher security zones.

B.1.4 Electronic monitoring system

After working hours, the building will be protected by installing an
electronic monitoring system divided into security zones, which will
prevent even company employees from reaching restricted areas. At
any breach, a security company will be notified immediately.

B.1.5 Video monitoring system

All entrances into the building will be monitored by a video system.
The footage will be stored for at least 36 hours following.

B.2 Hardware and software IS security

Authorization will be solved standardly by logging into the operat-
ing system using an username and password. The personal data will
be stored within a standard database system based on Microsoft SQL
Server. Protection of the data will be ensured by application-level ac-
cess control. Furthermore, access to the company network will be
controlled. Anonymous modifications of the database will be pre-
vented, and every access to the database will be logged. Backup and
archiving will be realized using a tape unit, how the tapes are stored
is mentioned in B.1.3. The information system will be protected from
network attacks by a firewall and a network-wide antivirus system.

B.2.1 Uninterrupted Power Supply (UPS)

In the event of power failure, the network backbone and vital sys-
tems will be immediately switched to the backup power source, able
to provide enough power for safe termination of applications and
devices, thus preventing corruption of the data being processed.

38
 B. V O T E C H S E C U R I T Y P O L I C Y

B.2.2 Firewall and separation from the network

The IS will be protected from the external network by a firewall able

to detect and stop intrusion attempts. Access from the Internet is pro-
tected by a Cisco IOS firewall, with intrusion detection system, and
a 3DES feature set. Wireless network within the building will change
encryption from WEP to WPA 2.
Network communication among the branches will be encapsu-
lated in a secured channel. The authentication within the network
will be implemented using the Kerberos protocol, access from the In-
ternet will be secured by the Radius protocol, and is only accessible
by a secure point-to-point tunneling protocol (PPTP).
Furthermore, there will be a cluster of computers completely sep-
arated from any network. These will store the most sensitive infor-
mation, including the classified materials. Physical access to those
computers will be limited using the electronic monitoring system se-
curity zones mentioned in B.1.4.

B.2.3 OS and application-level authentication

In order to prevent access to the network and application storing per-

sonal data, every software used to work with the data will demand
authentication by means of username and password. In the event
of multiple failures to authenticate, the account will be blocked for
a predefined time of at least 24 hours, and the system administra-
tor will be notified. User passwords are valid for a limited period of
time, with minimum length of 8 characters, and must include at least
one number and a special symbol.

B.2.4 Network backup components

The company owns a backup for each of the network backbone de-
vices. In the event of a failure of some of them, it is possible to replace
them within a short span of time. The same is true for hardware run-
ning essential parts of the system.

39
 B. V O T E C H S E C U R I T Y P O L I C Y

B.3 Organizational and personal security

Security administrator, as well as every employee to come in contact
with personal data are properly educated and aware of responsibil-
ities resulting from the law. All new employees have to pass entry
tests, and have the said responsibilities stated in their work plans.

B.3.1 Access monitoring

All attempts to breach the security from the outside are monitored
and logged by software and hardware means. Network administra-
tors are responsible for controlling the logs regularly.

B.3.2 Building access for visitors

Entry to the building for visitors is only possible via the main en-
trance, at which point, the visitors are guided and logged by a janitor.
The entrance is locked at all times, made possible only by the use of
an electronic gate system controlled from the secretariat and logistics
section. In case the secretariat employee that is delegated to register
visitors is not present, any logistics section worker will replace him
or her.

B.3.3 Entrance monitoring

All attempts to enter or leave the monitoring system security zones
will be logged for at least four days, while video surveillance footage
will be stored for three days, as mentioned in B.1.4. Control and man-
agement of those logs and footage is the responsibility of the security
manager.

B.3.4 Creation and storing of backup copies

Network administrators will be responsible for backing up the data
using a tape drive in intervals of 48 hours at the most.

40