Application Risk Management is a vital part of a complete enterprise risk management program. Failure to adequately manage risk can lead to serious consequences that may threaten the continued existence of the enterprise.
Armed with Ardoq’s Application Risk Use Case, the Enterprise Architect can identify, assess and unveil risks that may otherwise go unnoticed and eliminate areas of uncertainty. This is valuable information for CIO, CISO and other corporate stakeholders, including the Information Security, Risk, Audit, Governance and Compliance teams who need to manage risks, prioritize mitigation efforts, adhere to standards and protect their company from threats.
This article discusses the components, reference and fields of the Application Risk metamodel. It also suggests how to structure data in Ardoq workspaces to effectively maintain your risk register, control library and other information about corporate risk frameworks, policies, etc.
To better understand the foundation for the method please refer to the Application Risk Purpose, Scope, and Rationale document.
Article Contents
Application Risk Metamodel Overview
Full Application Risk Metamodel
This Use Case provides you with an effective implementation of a baseline risk management metamodel. It requires Risk Owners, or the owner of a Risk Register, to create Risk components and provide an initial quantification and classification of them via a Survey. The relationship between a Risk and impacted Applications is used to calculate a more specific level of risk taking into account the beneficial effect of any Controls that have been deployed to the Application.
The aforementioned surveys assist in the following:
Creation of new Risks & Controls
Set the default values on Risks and beneficial Control Effects
Create references between Risks and the Applications. It is these references that are important.
Apply controls which adjust levels of risk on the reference.
The values of current likelihood and current impact on the references automatically calculate the values based on the values defined in the raw impact and raw likelihood and the beneficial effects of the applied controls. The current risk exposure can then be combined with the threshold values on the application component to gain an understanding of the risk.
Application Risk Components
At its core, the Application Risk use case is built around 3 core components; Risks, Controls, and Applications.
The relationships between these three component types are many-to-many relationships. Different types of risks can impact different applications and there can be several different controls that can mitigate those risks. The baseline and target risk values, and control effect values are captured on the risk and control components respectively.
The metamodel also stores risk threshold values for each application and it is through the references that establish the relationship between these 3 components that we can examine the current risk exposure.
Below is the full list of components that are directly part of the Application Risk use case.
Application Risk Components Types
Risk Workspace
Risk Category
The Risk Category component is adapted from the generic Category Component which used to organize in a categorized hierarchy. This may be of arbitrary depth, with the leaf nodes being of the component type that is organized in the hierarchy.
Risk Component
Risks represent a potential circumstance or event that adversely impacts or threatens continued business operations. Risk also needs to take into consideration the likelihood of the potential circumstance or event occurring. For example, Unauthorized Access is a risk that can carry a likelihood of occurring and impact depending on what function it is impacting.
The workspace of risks constitutes a risk register. Ardoq recommends that the risk register in Ardoq is regularly reviewed, maintained and up to date by the relevant risk owners. This is automated through the broadcast functionality where Ardoq suggests 6 month reviews of risks and controls. This is highlighted in the Application Risk Playbook. Deprecated risks that are no longer relevant to your business should be removed periodically ensuring good data hygiene. As an example, risks associated with the Y2K bug that are in your risk registry are no longer relevant and should be removed from the risk repository. This behavior ensures good hygiene and that the risk repository is relevant to your organization.
Risk Fields
Several metadata fields are used to capture risk attributes to help better classify and understand what that risk is and how it is impacting the organization. As mentioned these are either gathered through a combination of the risk owner or control owner surveys and automatic calculations.
Field | Field Type | Description | Definition |
Risk Category
(on the Risk component) | List Field | Used to classify the type of risks |
|
Raw Likelihood
(on the Risk component) | Number Field
Scale 1.0-5.0 | The likelihood of a risk occurring is a numerical measure that is largely dependent on the nature of each defined risk on a scale of 0-5.
| Collected through the risk survey to set a default, base likelihood value for the specific risk when applied to different applications.
|
Raw Impact
(on the Risk component) | Number Field
Scale 1.0-5.0 | Impact is the consequences of risk events if they are realized. Typically measured in a 0-5 scale. | Collected through a survey to set a default, base impact value for the specific risk when applied to different applications. |
Raw Exposure
(on the Risk component) | Calculated Number Field | A 1 to 25 calculated field, the product of Likelihood and Impact | Baseline level of risk to a given application. |
Target Impact (on the Risk component) | Calculated Number Field | This field represents the optimal state of impact if all mitigating controls are put into place. | A calculated field that takes the Raw Impact score and adds related Control Impact Effect of each Control that has a Mitigates reference to the Risk |
Target Likelihood (on the Risk component) | Calculated Number Field | This field represents the optimal state of likelihood if all mitigating controls are put into place | A calculated field that takes the Likelihood score and adds the Likelihood Effect of each Control that has a Mitigates reference to the Risk |
Target Exposure (on the Risk component) | Calculated Number Field | The product of target impact and target likelihood representing an optimal level for the risk component if all mitigating controls are deployed. | This represents the optimal state of risk that can be achieved if all the relevant controls are deployed to an application. |
Impact Count (on the Risk component) | Calculated Number Field | Used to help illustrate how widely the risk impacts the organization | Calculation returns the total number of outgoing impact references that the risk has |
Risk Calculations
Risk Fields provide the input for the Risk Calculations.
Raw Exposure = Raw Likelihood X Raw Impact
Target Impact = Risk.Raw Impact Score & Control.Impact Effect
Target Likelihood = Risk.Raw Likelihood Score & Control.Likelihood Effect
Target Exposure = Target Likelihood X Target Impact
Risk Category
There are many different types of risks that can impact organizations. We use the risk category field to classify the various types of risks in the register. These categories are consistent with the categories outlined by the Institute of Risk Management.
Strategic | It is defined as the probability that an event will interfere with a company’s business model. A strategic risk undermines the value proposition which attracts customers and generates profits. |
Operational | Can be defined as the risks of loss arising from improper implementation of processes, external issues (weather problems, government regulations, political and environmental pressures, and so on), etc. Operational risks can be better understood as a type of risk due to inefficiencies in business operations carried out by an organization. |
Financial | Can be defined as the potential losses incurred when a firm uses a large amount of debt, it incurs a significant interest expense and obligation to repay principal that makes it more likely to have financial difficulties if its cash flows decline. |
Compliance & Regulatory | Can be defined as the financial, legal, reputational or business impact on an organization of any size or structure of not adhering to a set standards, laws or frameworks. |
Knowledge | Can be defined as the potential for losses related to knowledge and knowledge processes. This includes risks related to low quality knowledge, knowledge gaps and incorrect information that lead to poor strategy, decisions and actions.
|
Information Security | Information security risks are concerned with the breach of the confidentiality of a company’s or clients’ sensitive data. The violation of such data can be a huge risk for an organization, and it might not just cause financial losses but also result in loss of goodwill |
Raw Likelihood
The likelihood of a risk occurring is a numerical measure that is largely dependent on the nature of each defined risk. When a risk owner, via the risk owner survey, adds a detailed description to a newly created Risk component, they should also provide an estimate of that Risk’s likelihood of occurring because it will be used to establish a baseline or raw likelihood value used in further assessing the risk towards applications.
This is recorded on a scale of 1 to 5, with 5 representing the most likely. These are often given definitions as part of a corporate risk model, using descriptions, probabilities or frequencies.
Examples are given in Table 2 below:
Likelihood | Descriptions | Probabilities | Frequencies |
1 | Almost certain not to happen | <20% chance | Never heard of in industry |
2 | Less likely to happen | 20-39% chance | Expected once every five years |
3 | Equally likely/unlikely to happen | 40-59% chance | Expected once every two years |
4 | More likely than not to happen | 60-79% chance | Expected every year |
5 | Almost certain to happen | >80% chance | Expected multiple times a year |
Table 2: Example Likelihood scales (source: Management of Risk [3])
Most risk management tools only record a single risk likelihood level for each identified risk. When it comes to Application risk, however, this is less than satisfactory.
To build on this the likelihood of a risk occurring is primarily dependent on the nature of the risk itself, it may well vary depending on the characteristics of the different applications that it threatens. This will be reflected when the relationship from the risk to the application is established through the impacts reference. For example, some applications may be more susceptible to a risk than others. The use of an application by many customers, or accessing it via the Internet, may increase the likelihood of some risks occurring compared with another application that is only accessed by staff via the Intranet.
The Likelihood is defined as the probability of a risk happening. Because of the sheer variety of ways that likelihood can be determined, we left the likelihood fields as a user input field to avoid under or over reporting likelihood values.
Raw Impact
Which is the expected harm or adverse effect that may occur due to exposure to the Application Risk. In other words, it measures how bad things could get if a particular Risk materializes. We ask risk owners to define this through the Risk Owner survey in a similar fashion to risk likelihood.
Risk owners initially should consider how the risk could affect the continued operations, security, and in how the event related to the risk could impact cost, schedule, or technical performance objectives. Impacts are not limited to these criteria, however.
As an initial recommendation for risk owners, consider a consistent approach like identifying impact assessment criteria that considers the following factors which affect the Raw Risk Impact:
Size: The size and number of the applications that the risk may impact. The more widespread the risk proliferates across the application portfolio will be more severe.
Complexity: The complexity of the applications the risk is likely to impact will also affect the raw risk impact. Risks that occur to complex applications can have a domino effect and cause even more problems with business operations.
Criticality: The importance of the application to the continued business operations. A small risk that can have big consequences for an organization if it impacts critical applications.
Raw Exposure
Raw Exposure (is commonly referred to as the risk level) is the combination of impact and likelihood.
Ardoq’s ‘Raw Exposure’ represents a raw unmitigated risk value, is a fairly straightforward calculation that follows industry standards;
Raw Likelihood x Raw Impact = Raw Exposure
This returns a risk value in the 1.0 - 25.0 scale.
The raw exposure calculated value can then be categorized on heatmaps. Raw exposure values above defined threshold values can be categorized as High and represented accordingly and provide a basis for prioritization.
Target Likelihood
Is a field that takes the Raw Likelihood score and adds the Likelihood Effect of each Control that has a Mitigates reference to the Risk. This allows the risk owner to identify the optimal state if all the mitigation controls are deployed to the applications at risk.
Target Impact
Is a field that takes the Raw Impact score and adds the Impact Effect of each Control that has a Mitigates reference to the Risk. This allows the risk owner to identify the optimal state if all the mitigation controls are deployed to the applications at risk.
Target Exposure
Is a field that takes the Target Likelihood score in combination with the Target Impact score and provides a value for the optimal state of exposure if all the mitigation controls are deployed to the applications at risk.
Risk References
Incoming References | Description |
Impacts (Risk → Impacts → Application) | Provides the linkage between Risks and the Application. Representing that a specific risk will in some way impact that specific application and requires the need determine the likelihood and impact of that risk on that application |
Risk Assessment Fields (On the Impacts Reference)
The fields below are used to facilitate the risk assessment process. Each field plays a specific function getting a singular risk value. For more detailed information on the risk assessment process, refer to the Application Risk: Purpose, Scope, and Rationale article.
Field | Field Type | Description | Definition |
Current Likelihood
(On the Impacts Reference) | Calculated Number
Scale 1.0-5.0 | Used to to calculate the current likelihood level for a risk as it relates to an application. | Calculation that starts with the Raw Likelihood, and reduces it by the Likelihood Effect of each deployed Control that also mitigates the Risk, and that has a deployed Deployment Date today or earlier. |
Current Impact
(On the Impacts Reference)
| Calculated Number
Scale 1.0-5.0 | Used to to calculate the current impact level for a risk as it relates to an application. | Calculation that starts with the Raw Impact, and reduces it by the Impact Effect of each deployed Control that also mitigates the Risk, and that has a deployed Deployment Date today or earlier. |
Current Exposure
(On the Impacts Reference)
| Calculated Number
Scale 0.0-5.0 | Used to to calculate the current risk level for a risk as it relates to an application. | Calculation that is based on the current impact and the current likelihood. In a similar fashion to that of Raw Exposure. |
Risk Plan (On the Impacts Reference) | List Field | Used to represent the type of risk treatment an application will receive when it surpasses the risk tolerance level. |
|
Risk Treatment (On the Impacts Reference) | URL Field | Used to link to the relevant documentation. This can be as simple as an email with an approval, a documented plan, an insurance policy document or an MSA with a vendor |
|
Current Exposure is a value that represents the level of risk after you have implemented all of the relevant controls to help mitigate the risk. This is determined by searching the connections in the graph and finding all the controls that mitigate the specific risk, then check to see if that control has been deployed to that application. For every control that helps mitigate the risk and is deployed to the application we take the combined Likelihood Effect and Impact Effect value(s) (unless that value is empty and then it falls back to the default raw values) and subtract it from the Raw Likelihood and Raw Impact values of that risk to facilitate the Current Exposure Calculation.
If you have implemented several controls and the control effectiveness is greater than the inherent risk value, then the residual risk will be reduced to a minimum of 1 (as there is no such thing as 0 risk). This also helps you identify areas where you might be over-allocating controls.
This calculation process is replicated for every risk that is mapped to the application. If there aren’t any controls implemented, then the residual risk value will be the same as the inherent risk value. This is because there is no control in place to mitigate the effect of the risk.
Application Workspace
Application Component
The concept of an Application component should be familiar to those who have done any of our previous use cases, such as the Application Lifecycle Management Use Case. You can also find more details about what we classify as an application in our What is an Application article. Applications can be impacted by multiple risks and have multiple controls applied to them. Calculated fields are used to show the cumulative effect of impacting risks and deployed controls.
Application Risk Fields
Application Risk introduces many new fields on the Application component. These fields are used to asses the application’s risk level and then track the remediation of that risk
Field | Field Type | Description | Definition |
Red Risk Threshold
(on the Application component) | Calculated Number
Scale 1.0-5.0 | Used to represent the acceptable or target risk level of the application, used to compare against the inherent and residual risk values on the impacts reference. | User sets the risk level value associated with various component types which then propagates that value onto all the components of that type.
|
Green Risk Threshold
(on the Application component) | Calculated Number | Used to represent the acceptable or target risk level of the application on an aggregated level. | Calculated by multiplying the Risk Tolerance field by the number of incoming Impacts references from Risks |
Highest Current Risk Exposure | Calculated Number | Current Exposure value among the incoming Impacts references from Risks to this Application. Zero if there are none. |
|
The risk tolerance field(s) are used to set the organizational tolerance levels of risk on the component, allowing for easy ways to visualize where systems exceed the acceptable level of risk.
Application Risk Assessment Fields
The assessment fields are used to provide insights to the risks rolled up to the application. Several different approaches have been implemented to return these values on the application. Some are more useful and accurate than others. Review the Risk Score: Options for Aggregation and Comparisons article for more details into the pros and cons of using various calculations to compare risk scores. It is important to compare these results to determine what will provide value for your organization.
Field | Field Type | Description | Definition |
Total Risk Count
(on the Application component) | Calculated Number | Used to show the total number of risks associated with the application
| Calculated by counting the total number of incoming risks to the application |
Live Controls Count | Calculated Number | Used to show the total number of active risks associated with the application
| Calculated by counting the total number of incoming risks to the application and ensuring their deployment date is prior to today. |
Risk Red Count | Calculated Number | The number of incoming Impacts references from Risks to this Application that have a Current Exposure value equal to or greater than the Red Risk Threshold value. |
|
Risk Amber Count | Calculated Number | The number of incoming Impacts references from Risks to this Application that have a Current Exposure value less than the Red Risk Threshold value and greater than the Green Risk Threshold. |
|
Risk Green Count | Calculated Number | The number of incoming Impacts references from Risks to this Application that have a Current Exposure value equal to or less than the Green Risk Threshold value. |
|
Once applications have been identified as having risk values that exceed the tolerance level they need to be reviewed in greater detail to determine a proper remediation to reduce the risk. These fields are used to track where applications are in their remediation process and how they are progressing.
Control Workspace
Control Category
The Control Category component is adapted from the generic Category Component which used to organize in a categorized hierarchy. This may be of arbitrary depth, with the leaf nodes being of the component type that is organized in the hierarchy.
Control Component
Controls are represented in Ardoq as a set of methods that have a mitigating effect on one or more Risks, and can be deployed to one or more Applications. Where a Control that mitigates a given risk has been deployed to an application, it will have the effect of reducing the overall level of risk associated with that risk’s threat to the application. The result is the Residual Risk level which is stored alongside the original, unmitigated risk level on the reference between the Risk and the Application.
Controls are a set of methods that can be realized by several things. A Control can be realized by a policy or by a piece of technology. When creating a control it is important to be specific as to how that control is realized in its naming convention. In the example below we have MFA and several token options. Because there are multiple App Based Token options, the specific control ‘App Based Token - Google Authenticator’ was named with the technology specifically to indicate how that control is being realized.
This helps to remove the ambiguity of what has been implemented to mitigate the risk.
Control References
The references from Control components form linkages to both the Risk and Application components.
Outgoing References | Description |
Mitigates (Control → Mitigates → Risk) | Provides the linkage between Controls and Risks. Show what controls can be used to reduce risk. Used to calculate residual risk values. |
Deploys To (Control → Deploys To → Application | Provides the linkage between Controls and Applications. Shows what controls have been implemented against the application. Used to calculate residual risk values. |
Is Realized By (Control → Is Realized By → Applications / Technologies / Policies) | Provides the linkage between controls and the applications/technologies/policies that facilitate the control. Showing what specific policy or technology can be implemented to reduce risk. |
In this example, we can see the control that satisfies a framework requirements and how that control is deployed and realized in the organization.
Incoming References | Description |
Realizes (Initiative WS) (Initiative→Realizes→Control) | Provides the linkage between initiatives and controls to show what controls are being implemented to reduce risk. |
Is Realized By (Capability WS) (Capability→Is Realized By → Control) | Provides the linkage between controls that realize business and technical capabilities. |
Control Fields
Field | Field Type | Description | Definition |
Likelihood Effect
| Calculated Number | Indicates the effect that this Control has in reducing the likelihood of Risks that it mitigates. | Negative Value -4 to 0 |
Impact Effect
| Calculated Number | Indicates the effect that this Control has in reducing the impact of Risks that it mitigates. | Negative Value -4 to 0 |
The thinking here is that some controls will reduce the likelihood of a risk occurring (e.g. 2FA reducing the likelihood of accounts being accessed by identity thieves), while others will reduce the impact (offline backup of data can reduce the impact of ransomware attacks, but doesn’t reduce its likelihood). Some Controls might affect both. We’ve assumed that no Control can have a worsening effect on either the Likelihood or Impact of a Risk.
Control Reference Fields
Field | Field Type | Description | Definition |
Deployment Date
(on the Deploys To reference)
| Date Time value | A date field that indicates when the Control has gone live in its deployment with the Application |
|
The Default Control Effectiveness value or can be overridden with the Recommended Control Effectiveness field when determined that the effectiveness of the control is lower or greater than the value in the Default Control Effectiveness field.
Framework and Policy Workspace(s)
Frameworks, such as the NIST Cybersecurity Framework [4], and internal organizational Policies are represented in the same way, as an Information Artifact component that may be broken down into a more detailed collection of Requirements. The requirements may be linked directly to Controls, indicating which controls are realizations of the requirements either of adopted frameworks or corporate policies.
The Information Artifact Component Type is used in Ardoq to represent “an item of unstructured information, like a document” [1] and the components can usefully contain a URL link to the source document. Corporate Policy documents, control frameworks (and official standards such as ISO 31000 and ISO 25010) are unstructured, in that they contain a lot of text, but the document itself is typically broken into sections that do form a logical structure.
For Application Risk we capture Frameworks and Corporate Policies in their own distinct workspaces. These workspaces can often reference each other, depending on how you have implemented frameworks, controls and policies within your organization.
Information Artifact and Requirement Components
Framework Workspace is composed of 3 component types
Category - The Category component is used to organize in a categorized hierarchy according to framework (NIST, SOC2, ISO27001, etc.). This may be of arbitrary depth, with the leaf nodes being of the component type that is organized in the hierarchy.
Information Artifact - In this context, the information artifact component type represents different security frameworks (ex. SOC2, ISO27001, CCM, NIST, etc). The information artifact in the context of a policy can simply represent a policy you have within your organization.
Requirement - In this context, the component type represents the specific requirements from the framework (ex. ISO 27001 Framework has a control requirement of A.5.1.1 - Policies for information security)
Framework & Policy Workspace Fields
Field | Field Type | Description | Definition |
Document URL (on Information Artifact component) | URL Field | Used to link to the actual document to avoid having to store the asset in Ardoq.
|
|
Category (on Information Artifact component) | List Field | Used to classify what time of information artifact it is as there can be several types |
|
Framework & Policy Workspace References
Outgoing References | Description |
Parent/Child - Information Artifact - Parent/Child - Requirement) |
|
Is Realized By (Requirement → Is Realized By → Control) | Used to connect specific framework requirements to the controls that satisfy them |
Is Realized By (Requirement→ Is Realized By → Information Artifact) | Used to connect specific framework requirements to the policies or other artifact that help satisfy them |
Application Risk Management Gremlin Code
This section contains the Gremlin code used to implement the Calculated Fields of the Risk components.
Calculated Raw Exposure
This contains the Gremlin code that calculates the baseline exposure associated with a given Risk Component
g.V(ids)// Assuming the label for risks is 'Risk'
.project('id','name','value').
by(id).
by('name').
by(project('impact', 'likelihood')
.by(coalesce(values('raw_impact'),constant(0)))
.by(coalesce(values('raw_likelihood'),constant(0)))
.math('impact * likelihood'))
Calculated Target Impact
This contains the Gremlin code that calculates the optimal impact if all mitigating controls are deployed
def getEffect = {
__.in('Mitigates').hasLabel('Control').values('impact_effect').sum()
}
def getImpact = {
values('raw_impact')
}
g.V(ids).
project('id', 'name', 'value').
by(id).
by('name').
by(project('effect','impact').
by(coalesce(getEffect(), constant(0))).
by(coalesce(getImpact(), constant(0))).
math('effect + impact'))
Calculated Target Likelihood
This contains the Gremlin code that calculates the optimal likelihood if all mitigating controls are deployed
def getEffect = {
__.in('Mitigates').hasLabel('Control').values('likelihood_effect').sum()
}
def getLikelihood = {
values('raw_likelihood')
}
g.V(ids).
project('id', 'name', 'value').
by(id).
by('name').
by(project('effect','likelihood').
by(coalesce(getEffect(), constant(0))).
by(coalesce(getLikelihood(), constant(0))).
math('effect + likelihood'))
Calculated Target Exposure
This contains the Gremlin code that calculates the optimal exposure if all mitigating controls are deployed
g.V(ids)// Assuming the label for risks is 'Risk'
.project('id','name','value').
by(id).
by('name').
by(project('target_impact', 'target_likelihood')
.by(coalesce(values('target_impact'),constant(0)))
.by(coalesce(values('target_likelihood'),constant(0)))
.math('target_impact * target_likelihood'))
Calculated Outgoing Risk Count
This contains the Gremlin code that calculates how many applications the risk impacts
g.V(ids).
project('id', 'name', 'value').
by(id).
by('name').
by(
__.outE('Impacts').
count())
Impacts Reference Gremlin code
This section contains the Gremlin code used to implement the calculated fields on the Impact Reference between the Risk and the Application components.
Calculated Current Impact
This contains the Gremlin code that calculates the current impact associated with a source Risk Component and target Application component
today = new Date().format('YYYY-MM-dd')
one = new Integer(1)
def getImpact = {
coalesce(__.outV().values('raw_impact'),constant(0))
}
def getEffect2 = {
coalesce(outV().in('Mitigates').hasLabel('Control').has('impact_effect').filter(match(__.as('start').outE('Deploys To').filter(has('deployment_date', lt(today))).inV().hasLabel('Application').as('app1'),__.as('app1').in('Impacts').hasLabel('Risk').in('Mitigates').outE('Deploys To').as('app2')).where('app1', eq('app2'))).values('impact_effect').sum(), constant(0))
}
g.E(ids).
project('id', 'value').
by(id).
by(project('impact','effect').
by(getImpact()).
by(getEffect2()).
union(math('impact + effect'), constant(1)).max())
Calculated Current Likelihood
This contains the Gremlin code that calculates the current likelihood associated with a source Risk Component and target Application component
today = new Date().format('YYYY-MM-dd')
def getLikelihood = {
coalesce(__.outV().values('raw_likelihood'),constant(0))
}
def getEffect2 = {
coalesce(
__.as('impactsReference').outV().
in('Mitigates').hasLabel('Control').has('likelihood_effect').as('control').outE('Deploys To').filter(has('deployment_date', lt(today))).inV().hasLabel('Application').inE('Impacts').where(eq('impactsReference')).
select('control').values('likelihood_effect').sum(),
constant(0)
)
}
g.E(ids).
project('id', 'value').
by(id).
by(project('likelihood','effect').
by(getLikelihood()).
by(getEffect2()).
union(math('likelihood + effect'), math('1')).max())
Calculated Current Exposure
This contains the Gremlin code that calculates the current exposure associated with a source Risk Component and target Application component
def getLikelihood = {
coalesce(values('current_likelihood'),constant(0))
}
def getImpact = {
coalesce(values('current_impact'), constant(0))
}
g.E(ids).
project('id', 'value').
by(id).
by(project('likelihood','impact').
by(getLikelihood()).
by(getImpact()).
math('likelihood * impact'))
Application Component Gremlin code
This section contains the Gremlin code used to implement the calculated Application Risk Fields of the on the Application components.
Calculated Current Green Count
This contains the Gremlin code that calculates the number of risks under the green threshold value
g.V(ids).
project('id', 'name', 'value').
by(id).
by('name').
by(match(__.as('start').values('risk_green_threshold').as('threshold'),
__.as('start').inE('Impacts').as('risk'),
__.as('risk').values('current_exposure').as('exposure')).
where('exposure', lte('threshold')).select('risk').count())
Calculated Current Amber Count
This contains the Gremlin code that calculates the number of risks over the green threshold value but below the red risk threshold value
g.V(ids).
project('id', 'name', 'value').
by(id).
by('name').
by(match(__.as('start').values('risk_red_threshold').as('red'),
__.as('start').values('risk_green_threshold').as('green'),
__.as('start').inE('Impacts').as('risk'),
__.as('risk').values('current_exposure').as('exposure')).
and(where('exposure', gt('green')), where('exposure',lt('red'))).select('risk').count())
Calculated Current Red Count
This contains the Gremlin code that calculates the number of risks over the red risk threshold value
g.V(ids).
project('id', 'name', 'value').
by(id).
by('name').
by(match(__.as('start').values('risk_red_threshold').as('threshold'),
__.as('start').inE('Impacts').as('risk'),
__.as('risk').values('current_exposure').as('exposure')).
where('exposure', gte('threshold')).select('risk').count())
Calculated Risk Totals Count
This contains the Gremlin code that calculates the number of risks impacting a given application
g.V(ids).
project('id', 'name', 'value').
by(id).
by('name').
by(
__.in('Impacts').
hasLabel('Risk').
count())
Calculated Controls Totals Count
This contains the Gremlin code that calculates the number of controls deployed to a given application
g.V(ids).
project('id', 'name', 'value').
by(id).
by('name').
by(
__.in('Deploys To').
hasLabel('Control').
count())
Sources
[1]Ardoq, “Ardoq Use Case Solutions Metamodel Version 1.4.” Aug. 2023.
Version | Date | Author | Rationale |
1.0 | 9/26/23 | Jon Scott | Published |