ITS 4350 - Disaster Recovery
Chapter 1, An Overview of Information Security and Risk Management
This lesson presents an overview IT security concepts. and
how they relate to plans for handling incidents and disasters.
Objectives important to this lesson:
- Key concepts
- Risk management
- Contingency planning
- Relating security policy to contingency planning
Our text defines contingency
planning as being the process that makes us prepared for
incidents and disasters related to our organization's IT assets. We are
given a few examples of historic incidents and a statistic that makes a
good point. The author tells us that "80%
of businesses affected by a disaster either never reopen or close within 18 months of the
event". These are organizations that either had no disaster plans, or
they had plans that were inadequate for the disasters they encountered.
Having made this point, the author spends several pages
discussing terms that you will need to know. Many should be familiar to
- Information Security - protection of
information and the systems that collect, store, disperse, and use it
The next set of terms is one you see in a lot of texts about
- Confidentiality - information should only
be accessible to users who have been granted access to it for valid
reasons. Only authorized users can access data if it is protected
properly, and if authorized users do not violate security policy.
- Integrity - data may not be changed except
by authorized users or processes. This means that data must be
protected from alteration, deletion, or other changes to its intended
- Availability - authorized users can access
data when they need to do so. Availability includes the idea that
proper access methods are provided to only to authorized users, not to
The text confuses the issue with a graphic on page 4 that the
author does not explain. The classic CIA
concept defines security from the point of view of the IT
Security staff. The text should explain that an expansion of
this concept is
called by several names, one being the McCumber
Cube, another being the CNSS
Security model. This is the name used in the text. It provides three
different perspectives on security, which
should be considered together to make better security decisions:
- IT Security perspective:
Confidentiality, Integrity, Availability
How do we protect the information, make sure it is not tampered with,
and provide access to those who need it?
- IT Operations perspective:
Storage, Processing, Transmission
How do we perform the basic IT functions of storing, processing, and
transmitting data? Are our processes secure?
- Business perspective:
Policy, Education, Technology
How do we make the rules for
employees about protecting information, educate our staff
about protecting it, and use the technology
we have to run our business safely?
This link will take you to a Google search for images
represent these concepts.
The author continues with more terms:
- Threat - a potential form of loss or
damage; many threats are only potential threats, but we plan for
them because they might happen
- Threat agent - a vector for the threat,
a way for the threat to occur; could be a person, an event, or a
program running an attack
- Vulnerability - a weak spot where
an attack is more likely to succeed
- Exploit - a method of attack
- Control - A process
that we put in place to reduce the impact and/or probability
of a risk. The author mentions that a control can also be called a safeguard or a countermeasure.
On page 5, the text presents a list of threat types ranked
from 1 to 12 in two different surveys. The rankings changed a bit, but
the list is given an aura of accuracy by showing us the same categories
in both survey years. Don't hope too much that these are the only
threat categories that matter. The surveys were done by the same
people, so they used the same categories. The author discusses each of
the twelve categories to give you a feeling for what they are. Browse
through any that are unfamiliar to you.
On page 12, the author changes topics, and discusses risk.
As some of you know, we have classes just about risk management, so
this section is not all there is to know about it. However, the graphic
on page 12 gives us a nice overview of a workable process for managing
- In the first phase, we identify risks, by inventorying and classifying all our assets, and then identifying the threats that apply to those assets, and the vulnerabilities those threats could use against us.
- The second phase takes us to the selection of appropriate controls, and justification of their cost and value to decision makers in our organization.
The chapter continues with an expansion on each of the topics in the graphic.
- Know something about the big picture - Who and what are we
protecting, from whom and what. To know details about these subjects, do
everything on the green chart.
- Identify, classify, and assign values to assets - To know
our exposure to risk, we have to know what we have and how it is
exposed. Assets can be classified by their level of secrecy, their
value to the organization, their need to be protected, or by
combinations of these factors as well as others.
In the chart on page 16, we see five information assets, each on a
separate line. Each is given a rating (from 0 to 1) on each of three
measures of how a compromise of that asset would affect the company.
The three measures in this case are impact on revenue, impact on
profitability, and impact on image. Assuming these are the most
important impacts our organization cares about, each is given a
relative percentage score. In the example, the organization cares 30%
about revenue, 40% about profitability, and 30% about image. That is
the criterion weight. For each asset, its score for a given criterion
is multiplied by that criterion's weight, producing three weighted
criterion scores for each asset. The asset's total weighted score is
the sum of its three weighted criterion scores. For
instance, the first asset has a score of .8 for revenue (weighted
criterion score is .8 times 30 = 24), .9 for profitability (weighted
criterion score is .9 times 40 = 36), and .5 for image (weighted
criterion score is .5 times 30 = 15), so its total weighted score for
the comparison is 75. Compare that score to the other lines, and you
see that this asset is the third most important asset in this
comparison. Warning: do not compare scores from one table to another unless they use the same criteria and the same weights.
The text provides another example of rating assets, based on a military
scale that uses four levels for secrecy. A scale like this may be more
useful for assets that do not have a particular effect on the
organization unless they are compromised.
- Threats must be identified, and matched with assets affected by them. Not all threats will affect all assets.
- Assets must be examined again, with respect to the threats
that could affect them. How vulnerable is each asset to each of its
possible threats? This evaluation gets us ready to do the big one on
Assuming you have followed the steps so far, there is an important calculation to do.
- Each asset needs to be given a value, based on its replacement cost, its current value to the organization, or the value of the income it generates. Pick one of those or some other value you care about. This is the Asset Value. Let's choose $100 as an example for Asset Value.
- Next, we need to determine, for each exploit, what the probable loss would be if that exploit occurs successfully. Would we lose the entire asset? Half of it? Some other percentage? Which percentage we pick tells us the Exposure Factor of a single occurrence of that exploit for this asset. Let's choose 50% as an example for Exposure Factor.
- We are still not where we want to be. Asset Value times Exposure Factor equals the Single Loss Expectancy. This is the Impact if the event occurs. In this example, it is $50.
- Now, we still need the Likelihood the event will occur.
The classic way to do this is to consult your staff about the frequency
of successful attacks of this type, or to consult figures from vendors
like Symantec, McAfee, or Sophos about
expected attack rates for your industry or environment. Let's assume we
have done that, and we are confident that we expect 10 successful
attacks per year in our example. This is the Annualized Rate of Occurrence.
- Taking the numbers we have so far, we should multiply the Annualized Rate of Occurrence times the Single Loss Expectancy, which will give us the Annualized Loss Expectancy for this asset from this kind of attack. This corresponds to the Risk Exposure. In the example we are considering, that amounts to $500.
that work led us to just one loss expectancy for one asset from one
kind of attack. That gives you an idea of the work involved in
calculating the numbers for each asset, each asset vulnerability, and
each kind of attack on those vulnerabilities.
The next idea is to identify controls that can reduce or eliminate
our risk. The text mentions five control strategies that are often
considered. The terms are a little different from some other texts:
So what do we do if we know that there are risks, and that we can't
protect ourselves from all of them? The text introduces four topics
from the next several chapters.
- Defense - also called Avoidance, this means to use policies, training, and technology to avoid the situations that can be exploited.
- Transferal - this means to hire expertise when you do not have it, or to pay a fee to another department or organization that is in the business of managing risk
- Mitigation - this means to reduce the damage
that will be done in a successful attack, such as not putting all
assets of a given type in the same place, protected by the same
- Acceptance - this is when you decide that a risk is not as costly to us as the controls that might be used to avoid or mitigate that risk.
- Termination - this means that we decide to stop doing the things that put us at risk; we simply stop dong the things that use or produce the assets that a risk applies to.
Business impact analysis
- This process is used to determine the effect that successful attacks
would have on our organization. We determine what could happen, what
the effects of that event would be, and what state the organization's
functions would be in at that time.
Incident response plan
- For known incident types, given the BIA done in the section above,
what should we do to handle the incident? Who do we call? How do we
stop the attack and it effects? This plan is about handling the
The text has the next two topics out of order. Let's fix that.
Business continuity plan
- How do we continue business when we have an incident? Do we change
our procedures? Do we use alternate locations or resources to continue
business? How do we continue providing products or services when part
of our organization has been damaged, compromised, disabled, or
destroyed? Business continuity plans discuss keeping the business in
business during the incident.
Disaster recovery plan
- A disaster has occurred. How do we get back to normal, or what will
be the new normal? The incident(s) has/have been handled. What do we do
to return to our undamaged state, stronger and wiser than we were
All four of the major topics above are part of Contingency Planning,
what we do when we know things can go wrong. The level of detail in
each of the plans will be determined by the size and complexity of the
organization making that plan. On pages 28 and 29, the text presents
more plans identified by the NIST that would apply to organizations
like federal agencies.
The chapter ends with five pages on Information Security Policy.
This section introduces the components you might find in a very
detailed policy. It begins with some definitions:
A policy is a rule, or a set of rules,
that affects how we want our organization and its employees
to function. The idea behind a policy may start with a principle,
which is often a broad, general statement of what we believe to be right,
true, or beneficial. A policy is more detailed,
and more specific about what we expect our people to do. Related
On page 32, we see a very detailed outline of the parts of a policy.
- Principle - a general statement about what we
believe or require in our area of authority (we will use only two
computer vendors at a time); what we expect
- Policy - rules about the conduct of our organization
with regard to particular actions (we will limit ourselves to
particular models chosen by the IT department); how we will approach
- Standard - a method or process that may be
procedural or technical (orders are to be placed by approved requesters
within each work area); what steps are to be followed to assure general
compliance with policy
- Procedure - a detailed set of steps to follow to be
in compliance (requests are to be made to your manager, who will
forward approved requests to your authorized requester); variations or
limitations that apply to specific work areas, to be followed if they
apply to your area
- Guideline - a suggested addition to any of the items
above that is recommended but optional (submit your requests two weeks
before the end of a quarter to allow processing time); do this to make
it work better
- Statement of the policy - what it is, where it applies, and who has to do what
- Authorized access - who is and is not allowed to use
equipment or software related to the policy, and what is private about
any related data
- Prohibited use - a graduated scale of offenses and discipline to be applied for violations of various types
- System management - who runs it, who watches it, how it is to be protected, secured, and/or encrypted
of policy - a graduated scale of offenses and discipline to be applied
for violations of various types of the policy itself
- Policy review and modification - how often the review will
take place, who will do it, and the process to change or remove the policy
- Limitations of liability - standard lawyer section