|
|
ITS 3050 - Security Policies and Auditing
Managing Risk in Information Systems
Chapter 5, Defining Risk Assessment Approaches
Chapter 6, Performing a Risk Assessment
Objectives:
This lesson presents two chapters about risk assessment. General schemes
in chapter 5, and specific steps in chapter 6. Objectives important
to this lesson:
- Risk assessment
- Components of risk assessment
- Types of risk assessment
- Challenges in risk assessment
- Best practices
- Selecting a risk assessment method
- Management structure identification
- Assets and activities
- Evaluating threats
- Identify and evaluate vulnerabilities
- Identify and evaluate countermeasures
- Select a methodology
- Develop mitigation recommendations
- Presenting risk assessment results
- Best practices
Concepts:
Chapter 5
The chapter begins with a list of things we must do in a risk assessment.
Yes, we are taking the first objective above and expanding it to another
bunch of steps. Well, that's what a methodology is: a step by step list
of things to do, and each of those things may have steps of their own.
The list from page 139 covers most of the objectives above:
- Identify assets and activities - The text has not mentioned before
that activities can be at risk, and they can put us at risk. I am reminded
of a quote attributed to Grace Murray Hopper.
I don't know if Admiral Hopper said it first, but I think it is something
she would have agreed with. The act of setting sail exposes a ship to
risks. Most actions, like opening a store, performing a service, or
promoting an idea, expose us to risks. We can't avoid being at risk
if we choose to do anything important, so let's do something and prepare
for the risk.
- Identify and evaluate threats
- Identify and evaluate vulnerabilities
- Identify and evaluate countermeasures
- Assess threats, vulnerabilities, and exploits
- Evaluate risks
- Develop recommendations
- Present recommendations
Before we start breaking down the steps of assessment, the text reminds
us of some reasons for doing them. Two are listed:
- to support decision making - we must decide where to spend our budget,
so we assess our situation to make reasonable choices
- to evaluate control effectiveness - are our controls sufficient or
must they be changed?
There are three suggested times to do an assessment. This list appears
above the reasons, but it should follow it, so I will mention them here:
- when evaluating a risk - actually, this should say "when beginning
a risk management process"
- when evaluating a new control - as noted above, to measure the effectiveness
of a control you have to understand the risk it is associated with
- when reviewing a control - you should avoid continuing processes just
because they are in place; examine your controls on a regular schedule
to improve or replace them as needed
Let's turn to three parts that begin a risk assessment.
- Identify scope - The text give us an example of an evaluation of the
risks associated with a web server. Do we evaluate only the web server,
its associated database server, its network zone, or some combination
of these? Since the services provided by the web server depend on the
other server as well, it might be best to adopt the largest scope in
this situation, but your deadlines and project funding may limit the
scope. Make the best decision you can and get something done.
- Identify critical areas - Each of the three elements in the largest
scope mentioned above are considered in the text's example.. Each is
examined in terms of its own hardware, software, network connections,
and power needs. In terms of hardening and reducing risk, the text suggests
that neither the web server, nor the database server, should be allowed
to contain services or data not needed for the purposes they serve.
The more a box does, the more avenues for attack may exist on it.
- Identify team members - Ideally, the people doing the risk assessment
should not be the people who do the daily service, protection, and correction
on the components being assessed. This may not be possible in a small
organization, but it may be useful for cross training in an organization
large enough to have several teams who can regularly examine the work
and assets of another team. In other words, if you don't have specialists
doing the assessment, at least your separate teams can assess risks
for each other.
The text presents two general methods for conducting risk assessment.
They differ in their methods of assigning value to assets. How shall we
count the value of an asset? This is easier to answer once we choose
between two points of view:
- Quantitative Risk Assessment - Every asset must be given a
currency value of some sort that can be used in the measure of its impact
on the organization. Several methods of assigning this value can be
considered.
- Replacement cost - What would it cost us to replace
this asset if it were compromised or destroyed in
an attack? If a partial loss is possible, what would be the
value of each part of it?
- Purchase cost - What did the asset cost to acquire
it or develop it?
- Depreciated cost - If the asset loses value over time,
at what rate is it lost, and what is it worth now?
- Qualitative Risk Assessment - In this method, every asset is
given a relative value, not a currency value, which means that
each must be measured against the others in terms of its worth to the
organization
 The
text continues with a discussion of Quantitative Risk Assessment
that leads to a complicated calculation. This text does not present all
the terms you may need to know to carry out a quantitative assessment.
I will supply a few more from another security text:
- Asset Value (AV):
the value that an asset has for the next several calculations; this
value may be different depending on the context of its use
- Exposure Factor (EF):
the percentage of the value that would be lost
in a single successful attack/exploit/loss; this accommodates the idea
that an entire asset is not always lost to an attack
- Single Loss Expectancy (SLE):
this is a number that can be obtained by multiplying AV
times EF. You may want to start
two columns of data at the point, one holding the SLE for a probable
loss, the other holding the SLE for a total loss. In both cases,
use this formula:
SLE = AV * EF
- Frequency of Occurrence: this
number tells you how many attacks
to expect in some time period;
this is ambiguous if we are not told whether this is the rate for all
such attacks, or the rate for all such successful
attacks We generally assume that the number given is the rate at which
successful attacks occur.
- Annualized Rate of Occurrence
(ARO): often, known frequency
of occurrence may be expressed in days or hours, but the executive you
report to may want the numbers expressed in years.
This is understandable if, for example, we are talking about establishing
a yearly budget for IT Security. Reporting is often done based on calendar
or fiscal years, which is another argument for making this conversion.
- Annualized Loss Expectancy
(ALE): the final number stands
for the currency value of our expected loss for a given asset in one
year; provided you have calculated the numbers so far, ALE
equals SLE times ARO.
ALE = SLE * ARO
- Safeguard value - Also known as the Cost of the Control,
this is the cost to the organization of applying a control to reduce
the risk. It must be compared to the ALE of the risk to determine
if the cost is justified. Be aware, however, that some controls must
be implemented regardless of their cost because there may be a legal
or moral reason for doing so. We will consider this further in the second
half of the course.
As the text explains, some or all of the numbers used in the equations
above may be estimates or guesses. There is lack of certainty
about them, so we should not be too confident that our numbers are right
and always will be.
Turning to Qualitative Risk Assessment, The text expands on the
idea mentioned above that assets and risks are given numbers related to
their impact on the organization. A formula is given on page 121 that
is useful:
Risk Level = Probability that an exploit of a vulnerability
will succeed x Impact of that occurrence on the organization
In its discussion of probability, the text suggests that we assign general
levels of probability to risks, such as low, medium,
and high, giving each of them a value such as 10, 50,
and 100. In the table on page 121, the text presents an idea that
is a little different. It is saying that low level's 10 is really
a range of 0 to 10, the medium is really a range of 11
to 50, and the high is really a range of 51 to 100.
This can be understood as the number associated with the level being the
worst case example or limiting value of the impact of a
risk at that level. This gives us a better chance of assigning a level
to a risk that is a best match for it. These levels can be applied to
both of the values in this method's equation, probability and impact.
The text continues its discussion with a few examples of risks on page
122. It suggests that we should do research to get the opinions of experts
in the field about the importance of risks that apply to similar organizations.
Collective wisdom from people who work in the field may be more reliable
than a single guess from one or two of our own people. We need to balance
their experience against our knowledge of our own systems. Obtaining agreed
upon ratings for priority and for effectiveness of safeguards (page 125)
is recommended. The text calls using the opinions of experts the Delphi
Method on page 127.
In the table on page 126, the text shows us a line for each of three
controls. On each line, we see a column representing a kind of
risk. The intersections of the rows and columns tell us the effectiveness
of each control in mitigating that risk, which gives us a way to select
the best choices for protection against each risk. In a real world scenario,
I would suggest swapping the rows and columns, since we would have many
more risks to consider than we have controls to help mitigate those risks.
The text examines limitations of the qualitative approach on page
128. Four are mentioned:
- It is subjective in all respects.
- It is based on someone's opinion.
- It does not include a cost benefit analysis (CBA),
which the quantitative method does.
- Standards are not used, only levels defined by or for the organization.
The text spends several pages discussing the lack of certainty in measures
and assumed values for assets and risks, regardless of the method used.
The chapter ends with a list o f best practices for risk assessment.
- state your goals and scope at the beginning
- get support from the people who run your organization
- use people who understand the process
- conduct risk assessment on a regular schedule
- define or redefine your method to get more skill in using it
- provide a report that can be used to make better choices
Chapter 6
Chapter 6 continues the discussions from chapter 5, discussing them in
more detail. It expands on each topic, attempting to give us an example
to follow. We can skip to the summary, and review the new items this chapter
offers.
- describe each system and process being assessed
- review past audits - have problems been identified in the past, and
have they been addressed?
- review past assessments - things change, so are the assets and threats
mostly the same or very different?
- assess with regard to management structure - who "owns"
what in the organization? who is empowered to make changes? who must
be consulted about any existing or new controls?
- stay inside your scope, or redefine it sooner rather than later
- identify threats that apply to each asset, that are relevant to it,
not wasting time on threats that do not affect it
- as above identify vulnerabilities that are relevant to each asset
- identify and evaluate countermeasures (controls) that apply to at
least one threat/vulnerability pair; matching more pairs is better,
since that increases the benefit of a control
- track results to make sure you are recommending good solutions, that
solutions are either adopted or not, and that applying recommended controls
was effective
|
