ITS 3050 - Security Policies and Auditing

Managing Risk in Information Systems
Chapter 5, Defining Risk Assessment Approaches
Chapter 6, Performing a Risk Assessment


This lesson presents two chapters about risk assessment. General schemes in chapter 5, and specific steps in chapter 6. Objectives important to this lesson:

  1. Risk assessment
  2. Components of risk assessment
  3. Types of risk assessment
  4. Challenges in risk assessment
  5. Best practices

  6. Selecting a risk assessment method
  7. Management structure identification
  8. Assets and activities
  9. Evaluating threats
  10. Identify and evaluate vulnerabilities
  11. Identify and evaluate countermeasures
  12. Select a methodology
  13. Develop mitigation recommendations
  14. Presenting risk assessment results
  15. Best practices
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.

    Grace Murray Hopper quote

    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, a 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

Impact risk on parts of ISSThe 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


Assignments for these chapters will be found in Blackboard. We will explore that in class.