|
|
ITS 3050 - Security Policies and Auditing
Managing Risk in Information Systems
Chapter 7, Identifying Assets and Activities to Be Protected
Chapter 8, Identifying and Analyzing Threats, Vulnerabilities, and
Exploits
Chapter 9, Identifying and Analyzing Risk Mitigation Security Controls
Objectives:
This lesson presents three chapters about identification
and analysis of our assets, their risks, and controls. Objectives
important to this lesson:
- Downtime in availability
- Review of asset types
- Identifying assets: immediate importance to incidents, to
business continuity, and to disaster recovery
- Identification of threats, vulnerabilities, and exploits
- In-place controls
- Planned controls
- NIST classification of controls
- Procedural, technical, and physical controls
- Best practices regarding controls
Concepts:
Chapter 7
The chapter begins by returning to access and availability,
this time with some common measures. We may need our systems to be up
24/7/365(366), or we may only be interested in having them up and
available for specific business hours. The idea of needing to be up for
a limited time each day applies to a smaller audience than it did
before the Internet made every business feel the need to be open to
customers on any schedule, in any time zone. Because this is so, we
generally see charts about uptime that assume a goal of the system
being always available.
The text only mentions downtime briefly. You should know more
about it. Below, you see a table of downtimes (third
column) expressed as a span of time that represents a
percentage of a year. This is a common measure, but you should
be aware the vendors often show their expected downtime by spreading
the yearly time over the entire year, and treating the system as if it
would be off line by the amortized amount in a week
or a month. This is interesting, but you should
realize that system outages measured as annual amounts may be clustered
around only a few events, not spread evenly
throughout each month, week, or day of the year. You should be aware of
the notation regarding the number of nines in each example, since it is
commonly used:
Percentage of Uptime |
Name |
Yearly Downtime |
90 |
One Nine |
36.5 days (10%)
|
99 |
Two Nines |
3.65 days (1%)
|
99.9 |
Three Nines |
8.76 hours (0.1%)
|
99.99 |
Four Nines |
52.56 minutes (0.01%)
|
99.999 |
Five Nines |
5.26 minutes (0.001%)
|
99.9999 |
Six Nines |
31.5 seconds (0.0001%)
|
Note that we are not really under an hour of downtime
for the year until we reach five nines, which is more
reliability than the average customer would think to ask for until they
see a chart like this. Do you think an hour per year isn't much? What
if it happens all at once? What if your cable system was out for an
hour a year? Which hour? How about your phone? How about the 911
service in your area? How about the power to a hospital or to an air
traffic control system? For some systems, failure is not an
option.
The text mentions that server redundancy with failover
is a common practice. It is briefly described on page 168 in a system
with two servers, one designated as the failover server. It is
ready to go into service should the primary server go down. Be
aware of the concept. Having your key servers in clusters that
provide failover allows for more uptime, and also allows for
maintenance without downtime in service. Think about redundancy in
other areas where it is probably needed:
- storage
- network runs and networks
- power
- operating sites
Let's move on to page 173, where the text discusses assets
again.
- It expands on the level of detail we should capture about
our software assets. For each program, record its name, published,
version number, and more. The text recommends using an automated system
that regularly polls all hosts, or requires them to regularly report,
to keep up to date records of software and patches. In a small shop,
you could do this by visiting each workstation, but a larger shop makes
manual listing unworkable. To determine which option is better for your
organization, do a cost benefit analysis.
- Personnel assets are mentioned, and it is recommended to
use management software to track incoming and outgoing personnel,
training, jobs, skills, and evaluations.
- Data assets are the ones that come to most minds first for
large organizations.
The text offers several categories of data, to remind
you to look in those corners of the company assets as well.
- Employee data - payroll data, insurance data, job
performance data
- Billing and financial data - bills we are owed as well as
bills we must pay
- System configuration data - you do keep records about your
systems' state when set up, as well as their current states? If not,
why not?
- System data - everything that explains how our systems
work, where everything is, and how it is all connected
- Vendor data - who do we buy from, what do we buy, what do
we do with what we buy?
- Customer data - everything we know about our customers
- Intellectual property - inventions, patents, trademarks,
and company secrets
The text breaks things down again in terms of where our
concerns are in each of its seven domains. I begin to think that the
author came up with this concept. After making a diligent search for
assets and their associated information, the text leads us to the next
logical step. Each asset should be tagged with information about our
need for that asset in order to continue doing business. Several kinds
of planning are involved in a cycle that starts here. In different
organizations, several different kinds of plans are made, called by
different names that relate to the circumstances of the event and the
scope of the plan.
- 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.
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 that will 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.
Determining that a disaster has even occurred requires that we judge
its scope. One person having a desk full of paper ruined by spilled
water 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. 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 of its users. Some books 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 and
serene.
Chapter 8
You may note, in the objectives above, that I only assigned
one objective to Chapter 8. It is very repetitive and we can skim
through it easily. The main purpose of the chapter seems to be to
introduce more technical definitions and to fill pages with material
from other chapters. On second thought, let's not go to chapter 8. It
is a silly place.
Chapter 9
Chapter 9 has more content, so we will move on to it. (See,
it's not always the last one in sequence that's the most worthless.)
The chapter begins by dividing controls into two groups:
- in-place controls - controls we are already
using, which should be evaluated according to their performance
- planned controls - controls we are planning
to use, but have not for various reasons; we need to know what controls
have already been approved, purchased, or sit in a
box waiting to be installed, so that we do not notice a need and
run off looking to find a solution that is already in our pipeline
The text warns us that there are more controls than we could
possibly list in this chapter. This link will take you to NIST
SP 800-53, revision 4, a 462 page document whose bulk is mostly
taken up by its appendices, mostly F and G. It is one of several models
for organizations who are planning on adopting security controls. This
one discusses over 200 security controls. (We will discuss more models
in the second half of this course.) Pages 227 through 229 in our
current text describe 18 categories (or families) of controls in NIST
SP 800-53. You should browse through the list to get an idea of the
many things you may have to make rules about, make procedures for, or
install equipment to protect.
Several pages of the text are devoted to describing controls
that fall into three categories. Before we discuss them, be aware that
there are many ways to categorize controls, even in the same model.
Some categories overlap, so don't wonder much if your intuition is not
mirrored in any one particular scheme::
- procedural controls - This category has several
parts which include policies (rules), procedures (methods of following
rules), standards (specific applications of rules), and guidelines,
which are more like good suggestions that are not actually enforced.
- technical controls - Technical controls have to do
with technologyand actions that are performed by devices (technical solutions), such
as firewalls denying packets.
- physical controls - These include any physical
barrier, like a locked door or a fence, as well as security cameras and
guards.
The examples of most of these controls are clear, but make
sure you look at them as examples, not as a definitive list. In the
section about physical controls there is a short discussion about fire
suppression, which belongs in any safety class, as well as any
class concerned with network or system security.
For a fire to exist, three factors are needed:
If you can eliminate any one of these factors, the fire will
go out. This is why Carbon Dioxide extinguishers work: the CO2
replaces the oxygen in the immediate vicinity of a
fire, and the fire stops. Smothering a campfire works about the
same way.
A fire
break is an example of fighting a fire by depriving it of fuel.
Forest fires can be fought this way. Somewhat similarly, I once walked
into a rest room in an office and found that someone had placed a roll
of toilet paper on top of the light fixture over the sink. I noticed it
because it was on fire. I grabbed the roll of paper and tossed it into
the sink. This established a fire break between the fire and the rest
of the building. I then put out the fire on the roll of paper with
water (depriving it of oxygen).
Keeping your computer system cool, so that a fire will
not ignite, is your most effective form of firefighting: don't let
it start.
Fire Extinguishers - American fire extinguishers are
classed by the kind of fire they are able to put out. The links below
will take you to sites with more information about fire classes and
extinguishers. In surveying several sites, I found that there are
currently at least four classes of fires, and that the symbols
for them have been updated to use pictures instead of letters.
Some sites list a Class K for cooking oils (Kitchen fires), but this
does not seem to be universal. The chart below contains American
symbols:
Description of Extinguisher Class
|
Letter and Shape Symbol for Class
|
Picture for Class
|
Class A: paper, cloth, wood. |
|
|
Class B: oil, gasoline, kerosene, propane. |
|
|
Class C: electrical |
|
|
Class D: combustible metals, such as magnesium,
potassium, sodium |
|
|
Class K: combustible cooking oils |
|
|
The table below is from a Wikipedia article
on fire classes. It shows that the same kind of fire is called by a
different name in different places:
Comparison of fire classes
American |
European |
Australian/Asian |
Fuel/Heat source |
Class A |
Class A |
Class A |
Ordinary combustibles |
Class B |
Class B |
Class B |
Flammable liquids |
Class C |
Class C |
Flammable gases |
Class C |
UNCLASSIFIED |
Class E |
Electrical equipment |
Class D |
Class D |
Class D |
Combustible metals |
Class K |
Class F |
Class F |
Cooking oil or fat |
In most cases, a multiclass extinguisher is preferred. On
extinguishers I examined at my workplace, multiple picture symbols were
used, showing the pictures for classes A, B, and C.
Another text discusses some fire extinguishing systems. Common
types are sprinkler systems, foam systems, and gas dispersant systems.
- Sprinklers typically spray streams of
water or water
mist. The test in the video behind this link seems to point out a
limitation of automatic mist.
- Gas dispersant systems used to use Halon, and still
can, but they are restricted to existing Halon supplies. Carbon dioxide
is an alternative, but both solutions tend to be dangerous to
air-breathing life forms in the immediate area.
- Another system uses foam as a
suppressant, and the people testing this system
seem to be enjoying it greatly.
- The text also mentions dry chemical systems
which spray a fine powder over the fire. This is
similar to using baking soda to fight a small kitchen fire.
The chapter ends with some best practices about
mitigation controls:
- ensure controls are effective
- review controls in all areas
- review NIST SP 800-53 families of controls
- review the matching risk assessment if a control is changed
|