In this installment of the Risk Management Guide, learn how to define the scope of the IRM team's responsibilities, the difference between qualitative and quantitative risk analysis and the tools used to carry out risk analysis.
Continue Reading This Article
Enjoy this article as well as all of our content, including E-Guides, news, tips and more.
Before a risk assessment and analysis is started, the team carries out project sizing to understand what assets and risks will be evaluated. Most assessments are focused on physical security, technological security or personnel security. Trying to assess all of them at the same time can be quite an undertaking, so you should determine which issues the group will be addressing and those that it will not.
Risk analysis methodology
There are two types of approaches to risk analysis: quantitative and qualitative. Quantitative risk analysis attempts to assign real and meaningful numbers to all elements of the risk analysis process. These elements may include safeguard costs, asset value, business impact, threat frequency, safeguard effectiveness, exploit probabilities and so on. When all of these are quantified, the process is said to be quantitative. Quantitative risk analysis also provides concrete probability percentages when determining the likelihood of threats. Each element within the analysis (asset value, threat frequency, severity of vulnerability, impact damage, safeguard costs, safeguard effectiveness, uncertainty and probability items) is quantified and entered into equations to determine total and residual risks.
Purely quantitative risk analysis is not possible, because the method attempts to quantify qualitative items, and there are always uncertainties in quantitative values. For example, if a severity level is high and a threat frequency is low, it is hard to assign corresponding numbers to these ratings and come up with a useful outcome. In most instances today, qualitative risk analysis is used.
A quantitative method uses percentages, formulas and monetary values. The most commonly known and understood formulas are the single loss expectancy (SLE) and the annualized loss expectancy (ALE) methods. The formulas are:
Asset value x exposure factor = SLE SLX x annualized rate of occurrence = ALE
In the SLE formula the IRM team assigns a monetary value to the asset (asset value) and multiplies it by the amount of damage that would most likely be endured if a specific threat became realized. So if the organization's reputation has a value of $500,000 and it was found out that this organization did not abide by the California privacy law, this could damage this asset by 20%, which would mean that the SLE equaled $100,000. Now the team must take this value and multiply it by the annualized rate of occurrence (ARO), which is the number of times this threat would most likely become realized in a 12-month period. If the team thinks that this can happen twice in 12 months, the ARO has the value of 2. If the team thinks that this can happen once in ten years, the ARO value is 0.1. So the team takes the SLE value and multiplies by the ARO. In our case we will assign the value of 2 to the ARO. The resulting ALE value is $200,000.
This means that if the company does not make sure that it abides by the California privacy law by implementing a monitoring countermeasure and a process of telling customers of a potential compromise, the company could lose approximately $200,000.
The IRM team goes through these steps to determine the potential loss that can be endured so that they know how much can be spent on mitigating this specific risk as it pertains to this one asset.
The qualitative method
The reason that a qualitative method is more commonly used than a quantitative method is because of the difficulty of assigning monetary values to assets, calculating the percentage of damage that could be endured (exposure factor) and deriving the probability of frequency of a threat becoming realized (ARO).
Inserting a value, quantitative or qualitative, for probability is a difficult and potentially dangerous move. Most risk methodologies use some type of probability value to represent the likelihood of a threat being realized; i.e. a vulnerability being exploited.
NIST uses the following categories and definitions:
CobiT uses High, Medium and Low ratings, as does the Octave approach to risk management. Another approach to qualitative risk assessments is the Australian/ New Zealand approach which uses a percentage to represent probability, as shown in the following graphic.
The difficulty in using metrics that represent the probability of a threat being realized is that it is very subjective and complex. In our ALE example, how would the team decide that the company would most likely experience the issue of not being compliant with the California law two times a year and not zero times or 15 times?
There are many constantly changing variables that would have to be considered to properly forecast the correct likelihood of a vulnerability being exploited and the frequency of this taking place. For example, what is the probability of our company --StuffRUs -- not abiding by the California privacy law and reporting an exposure to its customers that live in California? This one question leads to many other questions; what is the probability of someone hacking into our database? What is the likelihood of someone hacking through our firewall, not being detected by our IDS, hacking through our access controls and encryption on the database? What is the probability of this type of incident going unnoticed? What is the likelihood of an internal employee or contractor doing this type of activity? How would we know that our California customers' data was accessed? And so on. This one question can easily take the risk analysis team up to three hours to answer, but even after all of this effort, how do they know they are right? As the environment changes and the threat agents change, the probability of this threat being realized changes.
There are many complicated and complex ways of trying to assess the probability of a vulnerability being exploited, but in the end it is mainly guesswork. The team can review past performance data and review the patterns that correlate with this type of threat, but most companies do not have this type of past performance data to pull from. The team could look to the industry and see what other companies have experienced and try and use that as a baseline, but the different companies most likely use different types of technologies, processes and people so this is not necessarily a fair comparison.
So most organizations use a qualitative approach, but the industry as a whole is trying to define metrics that can be used for quantitative analysis. Almost everyone would like to use a quantitative risk analysis approach since the exercise is carried out to basically figure out where to best spend the company's finite security budget. In this series I will be covering some risk management tools that use a quantitative approach and explain the pros and cons of these tools.
So far we have developed our IRM policy, created our IRM team, defined the team's scope, and decided on if the team will be using a qualitative or quantitative approach to risk analysis. In the next article we will go through the steps of an actual risk analysis.
RISK MANAGEMENT GUIDE
Introduction: Understanding risk
An overview of the risk management process
How to define an acceptable level of risk
How to write an information risk management policy
How to implement an effective risk management team
Information risk management: Defining the scope, methodology and tools
How to conduct a risk analysis
How to deal with risk
About the author
Shon Harris is a CISSP, MCSE and President of Logical Security, a firm specializing in security educational and training tools. Shon is a former engineer in the Air Force's Information Warfare unit, a security consultant and an author. She has authored two best selling CISSP books, including CISSP All-in-One Exam Guide, and was a contributing author to the book Hacker's Challenge. Shon is also the co-author of Gray Hat Hacking: The Ethical Hacker's Handbook.
This was first published in April 2006