ITS 305 - Security Policies and Auditing
Chapter 9, Risk Management: Controlling Risk
This lesson continues the discussion of risk management.
important to this lesson:
- Risk control options
- Cost-benefit analysis
- Maintaining risk controls
chapter begins its discussion on page 309 with four classic options for
dealing with risks:
- avoidance - make
every effort to avoid your vulnerabilities being exploited; make the
attack less possible, make the threat less likely to occur; avoid risk
by avoiding the activity associated with the risk
- transference - in
general, letting someone else worry about it
In the ITIL model, this is included in the definition of a service:
service is a means of delivering value to customers by facilitating
outcomes customers want to achieve without the ownership of specific
costs and risks."
A reader might misunderstand this statement, thinking that the customer
does not pay anything. That is not the case. An IT service provider
would assume the costs and risks of an operation
in return for the customer's payment for the service. This can be done in-house
or by outsourcing.
- mitigation - this
method seeks to reduce the effects
of an attack, to minimize and
contain the damage that an attack can do; Incident Response plans,
Business Continuity plans, and Disaster Recovery plans are all part of
a mitigation plan
- acceptance - this
counterintuitive idea makes sense if the cost of an incident is
minimal, and the cost of all of the other methods is too high to
accept; the basic idea here is that it costs less just to let it happen
in some cases
The best technique is probably a mixture of these methods. As
we discussed last week, avoiding
risk is best, but not always possible. Minimizing
the impact of risk with mitigation is also desirable. Transference makes the most sense
when you have no expertise in your organization, but you could say that
having a separate IT Security division is a kind of transference. Acceptance makes sense if the risk
and its outcomes are minimal.
Last week we discussed setting values for company assets. The
text revisits this idea starting on page 316. There are ten different
concepts in this section of the text. We might consider the value of
the income an asset generates, the cost we would incur if we had to
replace it, the cost of the loss of revenue if we no longer had it. As
a famous example, consider Coca-Cola.
What is the value of the intellectual property that is the recipe for
Coca-Cola? The formula for Coke is a trade secret, which is different
from a copyright. You can't copyright something unless you file the
information with a patent office, which makes it available to anyone
doing a patent search. This particular secret is not patented because
that would remove the marketing mystique of a secret formula, and it
would make it possible for someone else to make an identical product.
The mystique may be the more valuable part, an intangible quantity that
makes the physical product more valuable. So what is it worth?
The text admits that some asset valuations are only estimates.
The Coke formula is probably an example of an asset whose value
could only be known if it were to be lost. If it were to be lost, it is
unlikely that value could ever be regained.
After the discussion of value, the text brings up some of the
terms I introduced last week. Let's examine them again.
- 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. In the chart on page
330, the column labeled Cost per Incident corresponds to SLE
- Frequency of Occurrence: this
is the number given to you in exercise 1 of chapter 9, telling 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
We assume for exercise 1 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
explained on page 319, which stands for the dollar 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.
All of the figures above are needed to begin the Cost Benefit Analysis described on
page 320. The text tells us that there are several ways to determine a
Cost Benefit Analysis. It recommends that we calculate a value for CBA with regard to two values of ALE and a new concept, Annual Cost of Safeguard (ACS). The safeguard in question is a
procedure, a process, a control, or another solution that will provide
some measure of protection to our asset from the threat under
CBA = ALE (without the safeguard) - ALE (with the safeguard) - ACS of this safeguard
The value of CBA is defined as the ALE if we do not use the control, minus the ALE if we do use the control, minus the annualized cost of the control. If the pre-safeguard ALE is 5000, and the post-safeguard ALE is 4000, how much can the safeguard cost and still justify the new safeguard?
CBA may also be called economic feasibility.
The text mentions some other types as well that may be considerations
or limiting factors when considering safeguards and controls. Each may
be a factor in deciding whether a project request may move forward.
- organizational - Will the new solution fit
the way our company works? This is related to the consideration last
week about whether a proposed FASP standard was from a company that was
enough like our own.
- operational - Will the new system work for us?
Can we use it, can the users use it, is there any problem that will prevent it
from being of value to us?
- technical - Do we have the hardware or software to use this
system? Can we upgrade as needed to use it? Does the system limit our future
choices or expand them?
- economic - What will the system cost to build, implement,
and use? What associated costs, such as training and personnel, are needed for
- schedule - Not mentioned in the text. Will the timeline of the project take so long
that it will bring no value to the company? Will it cost too much to shorten the