Calculating total cyber risk is useful in IT asset management for:
Different types of assets will have different combinations of risk scenarios needed to estimate total risk. This is because different types of assets have different contexts in which they operate. For example, assets can be internally or externally facing, critical repositories or process, and so forth.
Tyler Britton is a Risk Consultant for RiskLens
An asset’s context makes certain types of scenarios relevant or irrelevant – the scenarios used to capture total risk for an asset should be consistent with the asset’s context. For example, a “Web App Attack” scenario would likely not be included in an internally facing asset’s total-risk assessment because a web app attack requires an application to be externally facing.
What process to follow to calculate total risk
Which scenarios are relevant to a given asset
The second point can be particularly challenging because the inevitable questions that come up when scoping scenarios to include in a total-risk assessment are:
To be clear, these questions are not specific to quantitative assessments, but are a thorn in the heel of qualitative assessments as well. Fortunately, there are a couple of good responses to this. For one, we don’t need to capture every possible scenario. Not only is this not feasible, but it’s not helpful because, using quantitative analysis with FAIR™, we only need a core set of scenarios to capture the vast majority of total risk for an asset.
Factor Analysis of Information Risk (FAIR) is the international standard for cyber risk quantification. With FAIR, risk and security teams understand cyber risk in terms of loss exposure in dollars and can effectively communicate cybersecurity priorities to business leaders.
Learn about FAIR training, endorsed by the FAIR Institute.
I will highlight the Pareto principle here, which stipulates that 20% of causes accounts for 80% of consequences. In the case of risk scenarios, adding more and more scenarios to an assessment has negligible impact on the end results: what matters most is including the important, core scenarios (i.e., ‘the 20%’) in the assessment, as they will account for most of the risk.
As outlined, including the right set of core scenarios in a total-risk assessment is important – after all we don’t want to analyze everything. But what are those core scenarios? Below are listed common core scenarios that should be considered in every total-risk analysis:
As said, there may be contextual nuance where another scenario or two might be included, but the above scenarios capture not only the vast majority of incident causes but also the vast majority of risk to a system.
The primary advantage of using generic assets is that it enables performing one assessment with slightly wider ranges to account for minor differences between the specific assets that fall under its umbrella.
To focus on specific assets, each asset would require a duplicate assessment – this approach is much more time consuming and repetitive. The two advantages of using specific assets are (1) inputs and results will be more precise than generic asset analysis and (2) the conversation during analysis will be slightly more focused
There is no ‘wrong’ or ‘right’ answer for whether to perform total-risk assessments using a specific asset or a generic asset. Generic assets lend themselves well to portfolio reporting, are extremely scalable, and tie in nicely with security architecture evaluations. However, they are a bit more complex to perform analysis upon than specific assets, and it’s important to ensure that the specific assets you are accounting for with a generic asset truly share the same context/control architecture.
Asset identification: Identify the asset that you want to perform the total-risk assessment upon – if it’s a generic asset, ensure that you review and document which specific assets it encompasses
Scenario identification: Identify the scenarios that capture risk for the asset – you can do this by reviewing the list we provided above, and for each scenario type assessing whether that type poses a confidentiality, availability, and/or integrity risk to the asset
FAIR analysis: Perform FAIR analysis on each scenario that is in scope for the total-risk assessment
Aggregate results: Software, such as RiskLens, will allow you to aggregate results automatically, however you can also easily do this by adding together the scenarios’ annualized loss exposure (ALE)
Once you have aggregated the results (via software or manually adding together ALEs) you will have successfully identified the total, baseline risk for the asset.
Once you complete a total-risk assessment, your work isn’t finished. Threat landscapes change, control architecture changes, and the asset context may change as well. All these factors mean that ongoing assessment is beneficial and necessary. This will likely include ongoing review (i.e., yearly reassessment) where you:
Add scenarios: Identify if any emerging threats require new scenarios to be in scope for the assessment
Remove scenarios: Identify if the threat landscape makes existing, in-scope scenarios irrelevant
Update scenarios: Re-analyze each scenario that is in-scope for the assessment by evaluating if the asset context has changed (such as changes in backups, process criticality, record counts, control architecture, etc.)
Monitoring total-risk assessments is a great way to demonstrate how you manage risk over time.