Introduction

Many compliance frameworks require Information Security Risk Assessments, and some organizations may receive third-party requests for Risk Assessment results. Organizations without any compliance obligations will still benefit from Risk Assessment as they are a key tool for efficiently increasing Information Security maturity and, more importantly, aligning Information Security with business needs and constraints.

This post defines the Risk Assessment process at a high level and guides organizations to other resources that can help them conduct their own Risk Assessment or vet third parties offering Risk Assessment services.

What Is a Risk Assessment?

An Information Security Risk Assessment determines the level of risk posed to the organization by specific threats to their Information Security. The results of the Risk Assessment are intended to be used to determine which security controls should be implemented to reduce these risks and prioritize them for implementation. The results can also enable executive leadership to make appropriate business decisions with an understanding of potential losses.

An information security Risk Assessment requirement is often included in compliance frameworks because most frameworks are based on a generic risk assessment that more or less apply to the information that the framework is concerned with protecting but cannot account for the unique circumstances at every organization implementing the framework. Requiring each organization to conduct their own Risk Assessment is a way of forcing them to consider these unique circumstances and address the additional Information Security risks that the framework does not address.

ISO 27005 and NIST SP 800-30 are documented Risk Assessment methodologies that are often used to support compliance with ISO 27001, NIST SP 800-53, NIST SP 800-171, and other compliance frameworks. While both methodologies use slightly different terminology, they both follow the same basic process:

• Establish risk criteria
• Identify threats to information security
• Apply risk criteria
• Determine risk treatment

What a Risk Assessment Isn't

There is often confusion about what a Risk Assessment is and is not. I have asked for Risk Assessment results many times in my career and have often been handed various reports that did not result from the process described above. These often include vulnerability scan reports, penetration test reports, gap assessment reports, and internal audit reports. All those documents are useful inputs to a Risk Assessment process but are not Risk Assessments by themselves.

A previous post described a variety of common compliance frameworks including NIST CSF, NIST SP 800-53, NIST SP 800-171, CMMC, HIPAA, GPDR, ISO 27001, and PCI DSS. Some organizations offer 'Risk Assessments' conducted 'using' one (1) of those frameworks. From the reports I have seen, these are typically conducted by determining which of the framework controls are not in place and flagging those missing controls as risks. While the missing controls likely result in increased risk, calling this method of assessment a Risk Assessment is a misnomer. This process would be more accurately described as gap assessment with some risk-based window dressing tacked on. This is because there are no identification of threats, impacts, or likelihoods. There is simply a statement that a control is not in place and an indication of risk, usually subjective based on how important the assessor deems each control.

None of the frameworks described above are suitable methodologies for conducting a Risk Assessment. In fact, nearly all the frameworks described above explicitly require conducting a Risk Assessment. It would be a paradox for a framework that contains a requirement to conduct a Risk Assessment to be used to conduct a risk assessment.

Many organizations conduct high level Risk Assessments that consider threats to the business, (e.g., Changing market conditions, political instability, inflation, etc.). Often, these Risk Assessments will include Information Security as a single line item. These are, in fact, Risk Assessments, but they are not Information Security Risk Assessments, even with the Information Security line item. A true Information Security Risk Assessment should contain many lines describing a variety of different Information Security threats and risks. An Information Security Risk Assessment can be used as an input to the higher level Risk Assessment or conducted as part of the higher level Risk Assessment.

The Risk Assessment Process

Establish Risk Criteria

The first step in conducting a Risk Assessment is defining the risk criteria. This refers to determining appropriate parameters so that risks can be weighed against each other and against the organization's needs. The criteria should be unique to every organization, as every organization will face different types of risk and have a different tolerance for risk.

The criteria that must be established includes:

• Likelihood
• Potential impact
• Risk level
• Acceptable loss
• Prioritization

An important aspect of the criteria is that they should be consistent between Risk Assessments. If the criteria change drastically every time a Risk Assessment is conducted, it will be very hard to compare the results of past and future Risk Assessments. Typically, the criteria will be established before the first Risk Assessment and will then be used for all future Risk Assessments with small updates only when necessary to adjust to changing conditions.

Likelihood

Likelihood is the chance that a threat event could occur, regardless of whether it will have any impact if it does occur.

Likelihood criteria should allow for a wide variety of threat events, including events that are extremely rare (e.g., An electrical fire in the datacenter) and others that are very frequent (e.g., A port scan of Internet-facing IP addresses).

The following table is an adaptation of an example likelihood scale from Appendix G of NIST SP 800-30r1:

Note the qualitative (An arbitrary scale from very low to very high) and semi-quantitative values (Arbitrary numbers from 0-10) that can be used to denote likelihood. Typically, an organization would choose only one (1) of these scales to use. The choice of scale is a matter of preference for the organization conducting the Risk Assessment. Semi-quantitative scales can be used to calculate risk in ways that qualitative scales cannot. This, along with true quantitative scales, is explained more in the Risk Level subsection below.

Using the expected number of occurrences per year as the likelihood scale provides an objective way to measure likelihood and should help maintain consistency between Risk Assessments. Compare this to a scale that uses terms like Very Frequent, Frequent, Infrequent, Very Infrequent, and Almost Never in lieu of the number of occurrences per year. These are subjective terms and if different personnel conduct Risk Assessments in the future, they may interpret any of these terms differently than their predecessors.

Impact

Impact is the potential consequence if a threat event occurs, regardless of how likely the event is to occur.

As with the likelihood scale, the impact scale should be designed to cover a wide variety of threat events where some may have almost no impact at all and others may be catastrophic to the organization.

The simplest way to define risk criteria is in terms of financial impact on the organization as shown in this example:

The thresholds shown in this example should be tailored to each organization. A loss of $100,000 may be negligible for a large enterprise but could be catastrophic for a small business. As with the Likelihood scale that is based on occurrences per year, using a financial loss scale in this manner provides objectivity and avoids varying interpretations of subjective terms like Catastrophic, Severe, Serious, Minor, and Negligible.

Many organizations struggle to use purely financial-based impact criteria because they are not prepared to quantify the financial cost from certain types of events. A more complex set of impact criteria can establish other types of impacts, such as privacy and reputation, that can be used in conjunction with financial impacts as shown in this example:

The organization would consider a threat event against all the types of impacts presented and select the highest impact. For example, a sustained denial-of-service (DoS) attack may be predicted to have the following impacts on the organization:

• Financial: Low
• Privacy: None
• Reputation: High

In this case, the overall impact would be High, as the reputation impact is greater than the other types of impact.

As with financial impact, the criteria should be tailored to each organization. Sustained local news coverage could also be catastrophic for a small business that operates in a single location while it would have negligible impact on a large organization that operates internationally.

Organizations may choose to add other types of impacts that are specific to the types of activities they perform. For example, a chemical manufacturing plant may have Information Security systems that control heavy industrial machinery with potential life-safety and environmental implications. They may also want to directly consider the impact from production downtime. The following example impact criteria could be added to the examples provided above:

Ultimately, any of these additional types of impacts could be converted to a financial loss value if the effort was spent to understand the financial consequences (e.g., Regulatory cost of a privacy breach, the cost of every hour of production downtime, or the clean-up cost of a chemical spill), but this would require more detailed analysis during each assessment. Using alternative impacts are a convenient shortcut for completing the Risk Assessment process quickly with reasonable accuracy while still maintaining objective criteria, because reasonable parameters can be discussed and defined once.

Risk Level

Risk Levels combine the Likelihood and Impact values to produce an overall risk score.

Events with High Impact and Low Likelihood will usually be valued similarly to events with Low Impact and High Likelihood. This is to reflect how Low Impact but frequent events will have a cumulative effect on the organization over time comparable to a High Impact but rare event. Events with Low Impact and Low Likelihood will receive a Low risk level, while an event with a High Impact and High Likelihood will receive a High risk level.

Assignment of Risk Levels can be accomplished using a matrix with qualitative values as shown in this example from Appendix I of NIST SP 800-30r1:

By using this matrix, we can see that a hypothetical risk with a Moderate Likelihood and High Impact would have an overall Risk Value of Moderate.

An alternative method of determining risk is to use semi-quantitative Likelihood and Impact scores to calculate a Risk Score. For example, if we used the 0-10 semi-quantitative scales as shown in the Likelihood and Impact examples above, we could use the following formula to calculate a Risk Score in the range 0-20: (Likelihood Score) + (Impact Score) = (Risk Score).

Quantitative Approach

All of the Likelihood, Impact, and risk criteria presented above use qualitative or semi-quantitative measurements. Organizations can also objectively measure risk using strictly quantitative scores for all these criteria. This approach is often more difficult, as most organizations are not prepared to determine expected financial loss for all event types.

An example of this approach would be to use the following criteria:

• Likelihood: Number of expected occurrences per year
• Impact: Expected financial loss per event
• Risk: (Likelihood) x (Impact) = (Expected Annual Loss)

Using this example criteria, an event that is expected to occur once every two (2) years with a cost of $500,000 per event would have an expected annual loss (risk) of $250,000 (0.5 occurrences per year x $500,000 per occurrence).

Acceptable Loss

Organizations are not expected to reduce every risk to zero (0). Instead, organizations must establish an acceptable loss threshold. Generally, risks below the threshold will not be addressed. These risks should still be tracked because changes in the threat landscape may increase the risk above the acceptable loss threshold in the future.

A very simple example of an acceptable loss threshold using qualitative criteria could be as follows:

• All risks with a value of 'Very Low' are acceptable.
• Any risk with a value of 'Low' is acceptable if treatment will cost more than $10,000 or require more than one (1) week of effort.

Acceptable loss thresholds for organizations using semi-quantitative Risk Assessment methodologies can be expressed numerically. For example:

• All risks with a score less than two (2) are acceptable.
• Any risk with a score between two (2) and 10 is acceptable if treatment will cost more than $10,000 or require more than one (1) week of effort.

Organizations using quantitative Risk Assessment criteria can directly use quantitative values as their acceptable loss thresholds. For example:

• All risks with an expected annual loss of less than $10,000 are acceptable.
• Any risk with an expected annual loss of $10,000-$100,000 is acceptable if treatment will cost more than $10,000 or require more than one (1) week of effort.

The examples shown above are a starting point. As with the other criteria, acceptable loss thresholds should be tailored to each organization's unique needs.

Prioritization

The risks that fall above the acceptable loss threshold will need to be prioritized for treatment, effectively determining which risks will be addressed first.

Simple prioritization criteria that focuses on addressing higher risks first could be defined as follows:

• Risks will be prioritized according to their value, with higher value risks having a higher priority.
• If risks have identical values, the risks with the higher Impacts will be prioritized over risks with lower Impacts.
• If risks have identical Risk and Impact Values, the risks with higher Likelihood will be prioritized over risks with lower Likelihoods.

This example fails to consider the cost of addressing risks. While this approach is simple, it is potentially inefficient as it may be possible to have a larger impact on the organization's overall risk by addressing many lower valued risks for the same cost as addressing a single high-value risk.

More complex prioritization criteria could factor in the cost of addressing risks, thereby prioritizing the remediation of risks with the highest return on investment regardless of the overall risk score. This works best when quantitative risk criteria are used as it can be difficult to calculate return on investment when using qualitative or semi-quantitative criteria.

Identify Threats to Information Security

Once the risk criteria have been established, it is time to begin the core Risk Assessment processes. This begins by identifying threats to the organization's Information Security.

The Risk Assessment should consider anything that can affect:

• Confidentiality: The ability to keep sensitive information out of unauthorized hands
• Integrity: The ability to ensure information is reliably accurate
• Availability: The ability for authorized persons to access the information when it is needed

When most people think of Information Security threats they consider hackers, malware, and other types of electronic attacks. An Information Security Risk Assessment should have a much broader scope than these common types of adversarial attacks. For example, while a hacker can affect the availability of information (e.g., Via a DoS attack), there are other non-hacker threats that can also affect the availability of information (e.g., A user accidentally deleting data, a hard drive failure, or a natural disaster destroying a datacenter).

Appendix D of NIST SP 800-30r1 provides four (4) categories of threats that are worth considering when identifying threats, which have been adapted in a simplified form here:

• Adversarial: Individuals or groups attempting to harm the organization
• Accidental: Mistakes made by authorized users
• Structural: Equipment or software failures
• Environmental: Natural and man-made disasters and infrastructure outages

Appendix E of NIST SP 800-30r1 also contains lists of various types of threat events that fall into these categories and can be used by organizations to create a list of threat events that concern them. This list should be considered a starting point. Organizations should also consider their own unique threats. Sources of inspiration for additional threat events that should be included in the Risk Assessment include:

• Threats identified in past Risk Assessments
• Past Information Security events and incidents at the organization
• Information about past Information Security incidents or events at similar organizations as reported via ISACs and threat reports
• Threat intelligence concerning ongoing attacks and emerging threats

Some potential threats may be so far-fetched for an organization that they can be excluded from the Risk Assessment entirely (e.g., An organization doing business exclusively in Kansas should not bother considering the threat of volcanic activity to their facilities), but threats that are even remotely possible should be included and considered. What may seem to be an extremely unlikely or low impact threat today may evolve in the future. Including these threats in the Risk Assessment will serve as a reminder to check on them in the future to determine if they are becoming more of a concern.

Asset-Based Approach

Both the NIST SP 800-30r1 and ISO 27005:2022 Risk Assessment methodologies include an event-based approach to Risk Assessment as described above, but ISO 27005:2022 also offers a more sophisticated approach that explicitly considers the motivations of attackers and their impact on assets.

In this asset-based approach, the organization would start by identifying their information assets, business processes, and the infrastructure that supports the information and processes. Threat events and vulnerabilities that could affect these assets would be documented as well. ISO 27005:2022 §A.2.5.1 lists examples of threats and §A.2.5.2 lists example vulnerabilities.

The organization would then document likely threat sources, their motivations, and target objectives. This example threat source is adapted from the examples provided in ISO 27005:2022 §A.2.3:

• Organized crime groups are a threat source that uses scams, ransomware, and botnets
• They are motivated by a desire to acquire resources
• Their objective is financial gain

Organizations would then combine the asset information with the threat source information to develop scenarios whereby a threat source could achieve their objectives by targeting relevant organizational assets. Example scenarios are provided in ISO 27005:2022 §A.2.6. These scenarios are used during the rest of the Risk Assessment in lieu of the threat events described above.

Applying Risk Criteria

Once the threat events (or scenarios) have been identified, the organization must apply their risk criteria to each threat event.

To oversimplify this, the organization will:

• Consider each threat against the Likelihood criteria to assign score
• Consider each threat against the Impact criteria to assign a score
• Consider the Likelihood and Impact scores of each threat against their risk criteria to assign a Risk Score
• Consider the threat's Risk Score against their risk acceptance criteria to determine whether to accept or treat the risk
• Use the prioritization criteria to prioritize the treatment of any risk that does not meet the acceptance criteria

In reality, most organizations will need to consider how independent or codependent their business processes, systems, and facilities are to determine how many times the risk criteria must be evaluated for each threat. This is because a threat that poses a High risk on one (1) system may only pose a Low risk on another separate system, and it would be inefficient to consider the threat once, assign it a High Risk Score, and implement identical controls to treat that risk on both systems (It would also be dangerous to assign the threat a Low Risk Score and decline to treat it on both systems). Conversely, if systems are highly interconnected, it's likely that a threat to any of the systems can affect another, and a threat that poses a High risk to one (1) system should be considered a High risk and addressed on all interconnected systems.

While the threats may be considered separately for certain systems, processes, or facilities, the resulting risks should be combined and prioritized together so that the more critical systems are addressed before the less critical systems.

Information on the Likelihood and Impact of threats can come from many sources. The organization may be able to use their own historical data related to Information Security events and incidents to determine the Likelihood and Impact of common threat events. Breach reports, information shared via ISACs, and other threat intelligence sources can also provide good Likelihood and Impact information. As with all external information, these inputs should be considered in the context of the organization and adjusted accordingly.

Vulnerabilities and/or controls can also be considered as part of a Risk Assessment and may adjust the Likelihood and Impact scores. This requires more effort during the Risk Assessment process but may produce more accurate results. Vulnerability scan and penetration test results are useful for identifying potential vulnerabilities that should be considered. Gap assessment and audit results are useful for identifying controls. Vulnerabilities typically increase Likelihood and Impact while controls decrease them. For example, maintaining a legacy application that can no longer be patched is a vulnerability that may increase the Likelihood of a malware threat gaining hold within the network, firewalling the legacy application so it has no Internet access and very limited internal network access may reduce the Likelihood of malware threat gaining a hold or spreading.

Throughout this process, the team conducting the Risk Assessment should consult with business and system owners to confirm that their understanding of threats, Likelihood, Impact, vulnerabilities, and controls are correct and verify that the resulting risk scores are reasonable. It is critical to the success of the Risk Assessment objectives that the business and system owners have faith in the process so that they will commit to following up on its recommendations.

If the Likelihood, Impact, or Risk Scores resulting from this process don't make sense, the Risk Assessment team should reevaluate their process. This sometimes happens with a Risk Assessment process lacks objectivity. Adjusting risk criteria to establish objective measurements that do not rely on opinions can help alleviate this problem. Risk criteria may also need to be adjusted as the organization grows or changes (e.g., A financial loss threshold that was appropriate when the organization was a small startup may need to be raised if the organization develops into a mature enterprise with a much larger budget).

Determine Risk Treatment

The final step in the Risk Assessment process is to determine how to treat the risks that have been identified. The ideal goal is to reduce all risks below the risk acceptance threshold, although this is not possible in many cases.

Typically, a risk can be treated in four (4) ways:

• Avoid: Stop doing whatever created the risk (e.g., If a database of sensitive information poses a confidentiality risk due to the possibility of compromise, but the sensitive information is no longer needed, delete the information)
• Modify: Implement controls that reduce the likelihood or impact of a risk (e.g., If sensitive data stored on laptops poses a confidentiality risk due to the possibility of theft or loss, encrypt the data on the laptops)
• Share: Transfer the risk onto another organizations (e.g., Outsource processes or purchase cyber insurance)
• Retain: Live with the risk (e.g., Accept that use of a vulnerable legacy application is unavoidable, and the risk cannot be further modified to an acceptable level or shared)

Avoiding risk is the best option as it is the only way to reliably eliminate a risk completely. Unfortunately, many activities that create risk are unavoidable for an organization to keep operating its business, so many risks will have to be treated in another manner.

Retaining risks is a last resort. Retaining a risk is similar to the concept of accepting a risk under the risk acceptance criteria, except this risk would be above the usual acceptance threshold. Risks are often retained when the cost of further reducing the risk exceeds the benefit that can be gained by treating the risk in another manner.

Modifying risks is the most common option chosen. The ISO 27002 framework provides an extensive list of security controls that can be used to modify risks and guidance on how to effectively implement those controls. Recommended controls to modify risks are usually fed into a planning and change control process to come up with detailed plans for implementing an effective control.

These risk treatment options are not exclusive to each other. In many cases, a risk may be modified to reduce as much risk as is practical using controls and, if it is still above the risk acceptance threshold, the remaining risk may be shared. If sharing the risk is not possible or the risk remains above the acceptance threshold, the remaining risk may be retained.

Business process and system owners should be very involved in the risk treatment decision process. They will likely be responsible for implementing the recommendations and must deal with the consequences of treating or declining to treat risks.

Do It All Over Again

Risk Assessments are not meant to be a one-time event. Threats and organizations change, and the Risk Assessment helps keep organizations aware of the effects of these changes. Typically, an organization-wide Risk Assessment will be updated annually.

Risk Assessments can also be more narrowly scoped. A Risk Assessment can be used when a new system is being deployed or an existing system is undergoing significant modification. These limited scope Risk Assessments help build good security practices into systems at the design phase when controls can be added more efficiently and with less disruption.

Ongoing Risk Assessments are a core part of a mature Information Security program.

Shameless Plug

TrustedSec performs Risk Assessments based on the FAIR, ISO 27005, NIST SP 800-30, and other methodologies for our clients to support general Information Security maturity and compliance Risk Assessment requirements. TrustedSec's Risk Assessments can incorporate the results of our own technical penetration testing activities to provide increased accuracy.

TrustedSec also helps our clients build their own risk management program to implement the concepts describe here and conduct their own in-house Risk Assessments.