Many regulations and virtually all security frameworks require some objective assessment of risks. The reason is...
simple: Security controls should be selected based on real risks to an organization's assets and operations. The alternative -- selecting controls without a methodical analysis of threats and controls -- is likely to result in implementation of security controls in the wrong places, wasting resources while at the same time, leaving an organization vulnerable to unanticipated threats.
A risk assessment framework establishes the rules for what is assessed, who needs to be involved, the terminology used in discussing risk, the criteria for quantifying, qualifying, and comparing degrees of risk, and the documentation that must be collected and produced as a result of assessments and follow-on activities. The goal of a framework is to establish an objective measurement of risk that will allow an organization to understand business risk to critical information and assets both qualitatively and quantitatively. In the end, the risk assessment framework provides the tools necessary to make business decisions regarding investments in people, processes, and technology to bring risk to acceptable level.
Two of the most popular risk frameworks in use today are OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation), developed at Carnegie Mellon University, and the NIST risk assessment framework documented in NIST Special Publication 800-30. Other risk frameworks that have a substantial following are ISACA's RISK IT (part of COBIT), and ISO 27005:2008 (part of the ISO 27000 series that includes ISO 27001 and 27002). All the frameworks have similar approaches but differ in their high level goals. OCTAVE, NIST, and ISO 27005 focus on security risk assessments, where RISK IT applies to the broader IT risk management space.
How does a company know which framework is the best fit for its needs? We'll provide an overview of the general structure and approach to risk assessment, draw a comparison of the frameworks, and offer some guidance for experimentation and selection of an appropriate framework.
All risk assessment methods require organizations to select an asset as the object of the assessment. Generally speaking, assets can be people, information, processes, systems, applications, or systems. However frameworks differ in how strict they are requiring organizations to follow a particular discipline in identifying what constitutes an asset. For example CMU's original OCTAVE framework allowed an organization to select any item previously described as the asset to be assessed, where the most recent methodology in the OCTAVE series, Allegro, requires assets to be information.
There are advantages and disadvantages associated with any definition of asset. For example, if an asset is a system or application, the assessment team will need to include all information owners affected by the system. On the other hand, if the asset is information, the scope of the assessment would need to include all systems and applications that affect the information. Practically speaking, it is important to define the asset precisely so the scope of the assessment is clear. It is also useful to be consistent in how assets are defined from assessment to assessment to facilitate comparisons of results.
A critical component of a risk assessment framework is that it establishes a common set of terminology so organizations can discuss risk effectively. See below for a list of terms used in most frameworks.
Risk assessments frameworks establish the meaning of terms to get everyone on the same page. Here are some terms used in most frameworks.
Actors, motives, access: These terms describe who is responsible for the threat, what might motivate the actor or attacker to carry out an attack, and the access that is necessary to perpetrate an attack or carry out the threat. Actors may be a disgruntled employee, a hacker from the Internet, or simply a well meaning administrator who accidently damages an asset. The access required to carry out an attack is important in determining how large a group may be able to realize a threat. The larger the attacking community (e.g., all users on the Internet versus a few trusted administrators), the more likely an attack can be attempted.
Asset owners: Owners have the authority to accept risk. Owners must participate in risk assessment and management as they are ultimately responsible for allocating funding for controls or accepting the risk resulting from a decision not to implement controls.
Asset custodians: A person or group responsible for implementing and maintaining the systems and security controls that protect an asset. This is typically an IT entity.
Impact: The business ramifications of an asset being compromised. The risk assessment team needs to understand and document the degree of damage that would result if the confidentiality, integrity, or availability of an asset is lost. The terms impact, business impact, and inherent risk are usually used to describe, in either relative or monetary terms, how the business would be affected by the loss. It's important to note that impact assumes the threat has been realized; impact is irrespective of the likelihood of compromise.
Information asset: An abstract logical grouping of information that is, as a unit, valuable to an organization. Assets have owners that are responsible for protecting value of the asset.
Risk magnitude or risk measurement criteria: The product of likelihood and the impact described above. If we consider likelihood a probability value (less than 1) and impact a value of high, medium, or low, the risk magnitude can be "calculated" and compared to risks of various threats on particular assets.
Security requirements: The qualities of an asset that must be protected to retain its value. Depending on the asset, different degrees of confidentiality, integrity, and availability must be protected. For example, confidentiality and integrity of personal identifying information may be critical for a given environment while availability may be less of a concern.
Threats, threat scenarios or vectors: According to OCTAVE, threats are conditions or situations that may adversely affect an asset. Threats and threat scenarios involve particular classes of actors (attackers or users) and methods or vectors by which an attack or threat may be carried out.
Risk assessment methodology
The heart of a risk assessment framework is an objective, repeatable methodology that gathers input regarding business risks, threats, vulnerabilities, and controls and produces a risk magnitude that can be discussed, reasoned about, and treated. The various risk frameworks follow similar structures, but differ in the description and details of the steps. However, they all follow the general pattern of identifying assets and stakeholders, understanding security requirements, enumerating threats, identifying and assessing the effectiveness of controls, and calculating the risk based on the inherent risk of compromise and the likelihood that the threat will be realized. The following is a basic methodology, largely derived from the OCTAVE and NIST frameworks.
1. Identify assets and stakeholders
All risk assessment methods require a risk assessment team to clearly define the scope of the asset, the business owner of the asset, and those people responsible for the technology and particularly the security controls for the asset. The asset defines the scope of the assessment and the owners and custodians define the members of the risk assessment team.
NIST's approach allows the asset to be a system, application, or information, while OCTAVE is more biased toward information and OCTAVE Allegro requires the asset to be information. Regardless of what method you choose, this step must define the boundaries and contents of the asset to be assessed.
2. Analyze impact
The next step is to understand the both the dimensions and magnitude of the business impact to the organization, assuming the asset was compromised. The dimensions of compromise are confidentiality, integrity, and availability while the magnitude is typically described as low, medium, or high corresponding to the financial impact of the compromise.
It's important to consider the business impact of a compromise in absence of controls to avoid the common mistake of assuming that a compromise could not take place because the controls are assumed to be effective. The exercise of analyzing the value or impact of asset loss can help determine which assets should undergo risk assessment. This step is mostly the responsibility of the business team, but technical representatives can profit by hearing the value judgments of the business.
The output of this step is a document (typically a form) that describes the business impact in monetary terms or, more often, a graded scale for compromise of the confidentiality, integrity, and availability of the asset.
3. Identify threats
Identify the various ways an asset could be compromised that would have an impact on the business. Threats involve people exploiting weaknesses or vulnerabilities intentionally or unintentionally that result in a compromise. This process typically starts at a high level, looking at general areas of concern (e.g., a competitor gaining access to proprietary plans stored in a database) and progressing to more detailed analysis (e.g., gaining unauthorized access through a remote access method). The idea is to list the most common combinations of actors or perpetrators and paths that might lead to the compromise an asset (e.g., application interfaces, storage systems, remote access, etc.). These combinations are called threat scenarios.
The assessment team uses this list later in the process to determine whether these threats are effectively defended against by technical and process controls. The output of this step is the list of threats described in terms of actors, access path or vector, and the associated impact of the compromise.
4. Investigate vulnerabilities
Use the list of threats and analyze the technical components and business processes for flaws that might facilitate the success of a threat. The vulnerabilities may have been discovered in separate design and architecture reviews, penetration testing, or control process reviews. Use these vulnerabilities to assemble or inform the threat scenarios described above. For example, a general threat scenario may be defined as a skilled attacker from the Internet motivated by financial reward gains access to an account withdrawal function; a known vulnerability in a Web application may make that threat more likely. This information is used in the later stage of likelihood determination.
This step is designed to allow the assessment team to determine the likelihood that a vulnerability can be exploited by the actor identified in the threat scenario. The team considers factors such as the technical skills and access necessary to exploit the vulnerability in rating the vulnerability exploit likelihood from low to high. This will be used in the likelihood calculation later to determine the magnitude of risk.
5. Analyze controls
Look at the technical and process controls surrounding an asset and consider their effectiveness in defending against the threats defined earlier. Technical controls like authentication and authorization, intrusion detection, network filtering and routing, and encryption are considered in this phase of the assessment. It's important, however, not to stop there. Business controls like reconciliation of multiple paths of transactions, manual review and approval of activities, and audits can often be more effective in preventing or detecting attacks or errors than technical controls. The multi-disciplinary risk assessment team is designed to bring both types of controls into consideration when determining the effectiveness of controls.
At the conclusion of this step, the assessment team documents the controls associated with the asset and their effectiveness in defending against the particular threats.
6. Calculate threat likelihood
After identifying a particular threat, developing scenarios describing how the threat may be realized, and judging the effectiveness of controls in preventing exploitation of a vulnerability, use a "formula" to determine the likelihood of an actor successfully exploiting a vulnerability and circumventing known business and technical controls to compromise an asset.
The team needs to consider the motivation of the actor, the likelihood of being caught (captured in control effectiveness), and the ease with which the asset may be compromised, then come up with a measure of overall likelihood, from low to high.
7. Calculate risk magnitude
The calculation of risk magnitude or residual risk combines the business impact of compromise of the asset (considered at the start of the assessment), taking into consideration the diminishing effect of the particular threat scenario under consideration (e.g., the particular attack may only affect confidentiality and not integrity) with the likelihood of the threat succeeding. The result is a measure of the risk to the business of a particular threat. This is typically expressed as one of three or four values (low, medium, high, and sometimes severe).
This measure of risk is the whole point of the risk assessment. It serves as a guide to the business as to the importance of addressing the vulnerabilities or control weaknesses that allow the threat to be realized. Ultimately, the risk assessment forces a business decision to treat or accept risk.
Anyone reading a risk assessment method for the first time will probably get the impression that they describe a clean and orderly stepwise process that can be sequentially executed. However, you'll find that you need to repeatedly return to earlier steps when information in later steps helps to clarify the real definition of the asset, which actors may be realistically considered in a threat scenario, or what the sensitivity of a particular asset is. It often takes an organization several attempts to get used to the idea that circling back to earlier steps is a necessary and important part of the process.
Which framework is best?
Over the years, many risk frameworks have been developed and each has its own advantages and disadvantages. In general, they all require organizational discipline to convene a multi-disciplinary team, define assets, list threats, evaluate controls, and conclude with an estimate of the risk magnitude.
OCTAVE, probably the most well known of the risk frameworks, comes in three sizes. The original, full-featured version is a heavyweight process with substantial documentation meant for large organizations. OCTAVE-S is designed for smaller organizations where the multi-disciplinary group may be represented by fewer people, sometimes exclusively technical folks with knowledge of the business. The documentation burden is lower and the process is lighter weight.
The latest product in the OCTAVE series is Allegro, which has more of a lightweight feel and takes a more focused approach than its predecessors. Allegro requires the assets to be information, requiring additional discipline at the start of the process, and views systems, applications, and environments as containers. The scope of the assessment needs to be based on the information abstraction (e.g., Protected Health Information) and identify and assess risk across the containers in which the information is stored, processed, or transmitted.
One of the benefits of the OCTAVE series is that each of the frameworks provides templates for worksheets to document each step in the process. These can either be used directly or customized for a particular organization.
The NIST framework, described in NIST Special Publication 800-30, is a general one that can be applied to any asset. It uses slightly different terminology than OCTAVE, but follows a similar structure. It doesn't provide the wealth of forms that OCTAVE does, but is relatively straightforward to follow. Its brevity and focus on more concrete components (e.g., systems) makes it a good candidate for organizations new to risk assessment. Furthermore, because it's defined by NIST, it's approved for use by government agencies and organizations that work with them.
ISACA's COBIT and the ISO 27001 and 27002 are IT management and security frameworks that require organizations to have a risk management program. Both offer but don't require their own versions of risk management frameworks: COBIT has RISK IT and ISO has ISO 27005:2008. . They recommend repeatable methodologies and specify when risk assessments should take place. The ISO 27000 series is designed to deal with security, while COBIT encompasses all of IT; consequently, the risk assessments required by each correspond to those scopes. In other words, risk assessment in COBIT -- described in RISK IT -- goes beyond security risks and includes development, business continuity and other types of operational risk in IT, whereas ISO 27005 concentrates on security exclusively.
ISO 27005 follows a similar structure to NIST but defines terms differently. The framework includes steps called context establishment, risk identification and estimation, in which threats, vulnerabilities and controls are considered, and a risk analysis step that discusses and documents threat likelihood and business impact.. ISO 27005 includes annexes with forms and examples, but like other risk frameworks, it's up to the organization implementing it to evaluate or quantify risk in ways that are relevant to its particular business.
Organizations that do not have a formal risk assessment methodology would do well to review the risk assessment requirements in ISO 27001 and 27002 and consider the 27005 or NIST approach. The ISO standards provide a good justification for formal risk assessments and outline requirements, while the NIST document provides a good introduction to a risk assessment framework.
The Value of Formal Assessments
A thorough analysis of risk helps justify security spending
Formal, methodical, risk analysis allows organizations to reason about the magnitude of business risk given the value of the system or information at risk, a set of threats, and a set of security controls like authentication, firewalls, and monitoring. The magnitude of the risk is a function of the degree of damage or loss that would occur if the threat is realized and the likelihood of the realization of the threat. This kind of thoughtful and objective approach not only helps to meet regulatory requirements, but also provides a practical way to manage security expenditures.
The value of assessing risk in this manner is that it transforms risk discussion from a conversation among technical people into a one relating technical vulnerabilities and controls to business impact. The process requires technical and business representatives to come to an understanding of what the business risk is and how it relates to technical risk. It also facilitates the economic discussion of whether investments in technology and processes are justified by the damage that may result from an attack or incident and the likelihood of the event. In short, it steers organizations away from being held hostage by the fear mongers or being starved for security investment by business people who do not appreciate the dangers posed by insufficient security controls.
With practice, an organization can establish a methodology based on this approach. However, it is worthwhile to review the OCTAVE family and, in particular, the Allegro framework. Its focus on information, its forms and relatively lightweight approach (when compared to other OCTAVE methods) provides a good alternative to NIST and will allow an organization to build a customized method that meets its own requirements.
Consistency is key
In the end, the most important aspect of choosing a framework is ensuring that the organization will use it. Auditors will seldom inspect the details of your risk assessment method, but will look at whether you have a systematic method and apply it regularly. It's an organization's prerogative to accept risks that are too difficult or expensive to mitigate. However, one can only accept risks that one understands. Consistent and repeatable risk assessments provide the mechanism to not only understand risk, but also to demonstrate to auditors and regulators that the organization understands risk.
Whether your goal is to simply achieve good security or also meet regulatory requirements, creating a risk assessment method based on a well-known framework is a good place to start.
About the author:
Richard E. Mackey, Jr. is vice president of consulting at SystemExperts, an information security-services firm. Send comments on this article to firstname.lastname@example.org.