Total risk for an IT asset such as a data repository or web app is exactly what is sounds like: the aggregate risk to a digital asset posed by relevant cybersecurity risk scenarios. That is, an asset will have a combination of relevant scenarios that, aggregated together, account for that asset’s total risk. Total quantitative risk can be analyzed by performing an assessment on the asset's total-risk scenarios.
Calculating total cyber risk is useful in IT asset management for:
- Understanding which assets pose the most risk to your organization
- Ensuring that resources are allocated efficiently
- Building risk portfolios
- Board reporting on crown jewel assets
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.
The Challenges of Assessing Total Cyber Risk (and Solutions)
The two primary challenges with calculating total risk are identifying:
-
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:
- Well, what about this scenario, and this scenario, and this scenario?
- How can we capture everything?
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.
Types of Scenarios to Include in IT Asset Total-Risk Assessments
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:
- Foothold scenario – threat actor gets a network foothold (usually via phishing/malware) and gains access to an asset (usually a breach scenario)
- Big Game Ransomware – threat actor ransoms the asset after gaining access. In FAIR terms, the Threat Event Frequency (TEF) of this scenario is derived from the Loss Event Frequency (LEF) of the foothold scenario
- Ransomware – ransomware gets onto the network and eventually executes on the asset
- Web App Attack – the threat actor performs a web app attack against an externally facing asset (usually in confidentiality scenarios)
- DDoS – the threat actor launches a Distributed Denial of Service (DDoS) attack against the asset
- Insider error/misconfiguration – non-malicious insider accidentally causes loss (i.e., outage or disclosure) to the asset via error and/or misconfiguration
- Malicious insider – malicious/privileged insider causes loss to the asset (such as via breach or outage)
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.
Advantages of Using Generic IT Assets in Total-Risk Assessments
Let’s talk about the idea of generic assets for a moment. What is a generic asset vs a specific asset?- Specific Asset: a distinct, named asset in your environment, such as ‘XYZ database’
- Generic Asset: a general asset encompassing a number of specific assets that have the same context and control architecture, such as ‘Crown Jewel Repositories’
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.
Process for Performing Total-Risk Assessment for IT Assets
The process for performing total-risk assessments is quite straightforward:
-
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.
Ongoing Monitoring for Total-Risk Assessments
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.
