Notes for Week 9

Chapter 9, Risk Management: Controlling Risk

Objectives:
This lesson continues the discussion of risk management. Objectives important to
this lesson:
1. Risk control options
2. Cost-benefit analysis
3. Maintaining risk controls
Concepts:
The chapter begins its discussion on page 315 with five classic options for dealing
with risks. The last version of the text listed only four, and called some by different
names:

defense (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, and by providing
an active defense against it

transferral (transference) - in general, letting someone else worry about it

In the ITIL model, this is included in the definition of a service:
"A 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 (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 (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, and to clean up afterward

termination (not listed in the previous edition) - instead of accepting the risk
of leaving the asset open to attack, the owner may choose to remove the
asset from the environment that holds the risk of attack; it is arguable that
any environment can be totally safe, but it may be possible to move the asset
to an environment that presents different, lesser risks; if this is not possible,

the owner may choose to stop offering a service, stop presenting data to the
public, or otherwise stop exposing such an asset to risks
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. Termination may make sense, if the
asset at risk cannot be protected at a reasonable cost, and our business plan can
do without it.
Last week we discussed setting values for company assets. The text revisits this
idea starting on page 322. 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, and more. 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. They could be sued, but the
genie would be out of the bottle, so to speak. 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 lost. If
it were 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 339, 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 attacks

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

326, 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 326. 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
consideration.
CBA = ALE (without the safeguard) - ALE (with the safeguard) - ACS of this
safeguard
In the formula above, 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
of feasibility 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 it?

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 timeline?