Application Risk Metamodel

Learn the details of the Application Risk metamodel and how to structure your information to realize value and succeed.

Jon Scott avatar
Written by Jon Scott
Updated over a week ago

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:

  1. Creation of new Risks & Controls

  2. Set the default values on Risks and beneficial Control Effects

  3. Create references between Risks and the Applications. It is these references that are important.

  4. Apply controls which adjust levels of risk on the reference.

  5. 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

  • Strategic

  • Operational

  • Financial

  • Compliance & Regulatory

  • Knowledge

  • Information Security

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.

  • Reduction - Reduce the risk level through controls and other means to bring the risk level below the tolerance threshold

  • Removal - Removal of the violating system

  • Transfer - Transfer the risk associated with the system by insuring against it

  • Retention - Accept the risk level

  • Share - Distribute the risk with a 3rd party (Vendor, MSP)

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 unacceptable or critical risk level of the application, used to compare against the inherent and residual risk values on the impacts reference.

User defines the value for the red risk threshold associated with various component types.

Green Risk Threshold

(on the Application component)

Calculated Number

Used to represent the risk level of the application, where the value is within level of risk where the risk requires no further actions.

User defines the maximum value for the green risk threshold associated with various component types.

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.

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.

Calculated Value used to represent all the risks over the Red Risk Threshold Level.

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.

Calculated Value used to represent all the risks over the Green Risk Threshold and below Red Risk Threshold Level. These would be consider moderate risks to the organization.

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.

Calculated Value used to represent all the risks below the Green Risk Threshold.

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 -5 to 0

Impact Effect

Calculated Number

Indicates the effect that this Control has in reducing the impact of Risks that it mitigates.

Negative Value -5 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

  1. 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.

  2. 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.

  3. 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

  • Standard

  • Principle

  • Policy

  • Pattern

  • Framework

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

Did this answer your question?