ITS 305 - Security Policies and Auditing

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 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:
  "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 - 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 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 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 consideration.

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