¶ What is the Diri bowtie risk assessment?
The bowtie risk assessment is step 3 of the Diri risk assessment process. Its purpose is to identify unacceptable risks so that you can decide on treatments that reduce them. Best-practice information security (ISO/IEC 27005) describes a risk scenario as a combination of assets, vulnerabilities, threats, controls and outcomes. Diri combines these concepts with the well-known bowtie analysis, and allows many-to-many relationships between all parts of the analysis.
A bowtie consists of an unwanted event with its possible causes on the left and consequences on the right. Treatments sit on both sides: preventive treatments reduce the probability of a cause, and reactive treatments reduce the impact of a consequence.
¶ Getting started
When you open step 3 of a new assessment, Diri offers four ways to start building your bowtie:
- Convert and import an existing risk assessment - import rows from Excel or CSV. Each row becomes linked causes, events and consequences, treatments included. See Bulk import.
- Guided risk - walks you through one complete risk, start to finish. Recommended if you are new to bowtie analysis.
- Use a template - start from pre-built assessments published by your organisation. See Using templates.
- Start from an empty bow tie - add events, causes and consequences as you go.
Later, you can use the buttons at the top of the work surface: Add guided risk, Import rows and Add from template. Several templates can be layered onto the same assessment; review for duplicates afterwards.
¶ The work surface
The work surface has five columns: Causes, Preventive (treatments), Events, Reactive (treatments) and Consequences. Use the plus signs to add causes, events or consequences. Switch between Bowtie view and Table view to see the same content as cards or as a table.
The process stepper at the top of the page can be shown in a compact form, leaving more room for the work surface while you build the bowtie.
¶ Highlighting an event
Clicking an event card shows only that event and the causes and consequences linked to it. Click the card again, or click Unselect all, to see everything. While an event is highlighted, new causes and consequences are linked to it automatically. A cause or consequence that is not linked to an event is not part of any risk, and does not show up in the risk matrix or the risk registry.
¶ Many-to-many relationships
A cause can lead to several events, and an event can lead to many consequences. There are two ways to connect elements:
- Drag and drop: Grab a cause or consequence card and drop it onto the event you want to connect it to. The chain icon on the card shows how many events it is linked to.
- Linked events: Open a cause or consequence and use Linked events to link or unlink events. On an event, the linked causes and consequences are listed and can be unlinked there.
¶ Pinning events in large assessments
As the number of causes and consequences grows, it gets harder to drag and drop. Pin an event to keep it on screen while you scroll. You can pin several events at once.
¶ Risks and the risk matrix
A risk in Diri is one path through the bowtie: a cause linked to an event that is linked to a consequence. Only linked paths appear in the risk matrix and the risk registry. The cause gives the probability and the consequence gives the impact.
The two risks above have the same impact (x-axis) but different probabilities (y-axis) in the risk matrix:
¶ The Add guided risk option
If you are new to this way of working, use Add guided risk. It takes you step by step through one risk: the event, what could cause it, its consequences, and how to treat them. You can register one cause in the wizard and add more on the work surface afterwards.
A guided risk walkthrough can end in a model like this:
¶ The bowtie infographic and PDF export
Open the bowtie infographic from an event card to see the event with its causes, consequences, threat actors, vulnerabilities, affected assets and treatments in one diagram. Use Sort by severity to order the causes and consequences, and Export to print the diagram or save it as a PDF. The export keeps the layout you see on screen. If nothing happens, allow pop-ups for the site in your browser.
¶ The parts of the bowtie
Diri uses the following definitions, based on ISO/IEC 27000.
¶ Cause
A cause describes how a threat exploits a vulnerability, leading to the event. Click Add cause (or Add existing cause to reuse one) and fill in:
- Cause name and Description.
- Threat: The potential source of an unwanted incident. Choose from the threats registered in step 2.
- Vulnerability: The weakness that the threat exploits. Choose from the vulnerabilities registered in step 2.
- Probability: The probability of the threat successfully exploiting the vulnerability, before any treatments are taken into account. Treatments are added afterwards.
¶ Recommended probability
When a cause has both a threat and a vulnerability linked, Diri shows a Recommended probability, based on the Highest threat level and the Highest exposure among them. The recommendation explains how the value was derived. Click Apply recommendation to use it, or choose another level if you have good reason to. If only one of them is linked, the form tells you what is missing.
¶ Event
An event is an occurrence or change of a particular set of circumstances. In Diri, the event is unwanted, and can have many causes and lead to many consequences.
- Select event type: Choose from the predefined event types. Administrators maintain the list in Settings; you can also add a new event type from the form with Add new event type.
- Description: An extra description, shown below the event title on the card.
¶ Consequence
A consequence is the outcome of an event that affects objectives. Click Add consequence (or Add existing consequence) and fill in:
- Consequence type: Choose from the catalogue of consequence types, or add a new one.
- Consequence name and Consequence description.
- Add affected asset: Choose the assets from step 2 that are affected. For each asset, choose whether the consequence affects Confidentiality, Integrity or Availability. The asset's evaluation is shown as guidance.
- Consequence estimate: The impact if the event leads to this consequence, before treatments are taken into account.
- Cost estimates: Optionally quantify the consequence with Min. cost of consequence, Max. cost of consequence and Average cost of consequence.
¶ Recommended impact
When an affected asset is attached and you have chosen which of confidentiality, integrity or availability is affected, Diri recommends a consequence level based on the Highest CIA classification (information assets) or the Highest importance (business assets) of the affected assets. As for causes, the recommendation explains how it was derived, and Apply recommendation sets it on the consequence.
¶ Risk treatments
Treating risk means modifying it. The main approaches are to:
- Reduce the probability of the event.
- Reduce the consequence of the event.
- Avoid the risk by removing the risk source.
- Share the risk with other parties, through contracts and risk financing.
- Accept the risk through an informed choice.
¶ Adding treatments to a cause or consequence
You can add treatments directly from a cause or consequence card on the work surface:
- Open the menu on the cause or consequence card, or hover over the card to see the treatment options.
- Choose a new treatment to create one, or link an existing treatment to reuse one (see below).
- Set the Treatment effect: how much the treatment reduces the probability (cause) or impact (consequence).
Treatments on causes are shown in the Preventive column, and treatments on consequences in the Reactive column.
¶ Registering a new treatment
- Name and Description.
- Type: Physical (for example door locks and fences), Technological (for example firewalls, monitoring and encryption), Administrative (policies, guidelines and routines) or People (for example hiring processes, awareness and training).
- Class: Based on established security frameworks:
- Identify - developing the organisational understanding to manage risk to systems, assets, data and capabilities.
- Protect and maintain - safeguarding and maintaining the delivery of services and protecting assets (mainly probability-reducing).
- Detect - identifying the occurrence of a security event.
- Respond and recover - acting on a detected incident, and keeping plans for resilience and restoring capabilities or services.
- Module, Tags and Control tags: Control tags connect the treatment to controls in your frameworks.
- Documentation link and Associated policies.
- Responsible and Due date: The responsible user is notified about the assignment and when the deadline approaches.
- One time cost and Yearly cost: Used in the cost-benefit analysis in step 4. Good estimates make that analysis much more useful.
- Status: Open (identified), Recommended, Planned (decided, not started), Ongoing (being implemented), Implemented (in use) or Non-applicable.
- Treatment effect: An estimate of how strong the treatment is against the cause or consequence. Consider the threat in question and its capabilities. For example, multi-factor authentication is generally a strong control against many attackers.
¶ Status and effect are set per assessment
A treatment's status, responsible, due date and effect are recorded for each assessment and each cause or consequence it is applied to. One treatment can therefore be implemented in one assessment and only planned in another. The treatment's status in the assessment decides how it counts in the risk picture:
- Before (inherent risk): no treatments count.
- Current: implemented treatments count.
- Planned: planned, ongoing and implemented treatments count.
- All: all treatments count, except non-applicable ones.
¶ Shared (global) and system-specific treatments
A treatment often affects the risk of many objects. A single sign-on solution gives access to many systems, and a network firewall protects many servers. When the same treatment is used in more than one assessment, it is registered once and reused, instead of being registered and recommended many times. A treatment used in only one assessment is system-specific. The treatment shows how many assessments it is applied in and how many risks it reduces.
¶ Reusing existing treatments
To reuse a treatment, choose to link an existing treatment from the card. The dialog Add an existing treatment lets you filter between This assessment and All treatments you have access to.
Important on reuse: Changes to the treatment itself (name, description, cost, type and class) apply everywhere the treatment is used. When you edit a treatment that is used in several assessments, Diri warns you that the change may affect multiple risk assessments and lists them. The effect is set separately for each cause and consequence the treatment is applied to.
Treatments can also be shared with sub-organisations through inheritance, with the options Allow child organizations to inherit this treatment and Allow child organizations to modify this treatment. See What is offered to the organisations below.
¶ Risk estimates and calculations
- Probability and consequence are both set on a scale from 0 to 100. The levels in your risk matrix correspond to ranges on this scale.
- The treatment effect is also a value from 0 to 100, and one cause or consequence can have several treatments.
- The effects multiply rather than add. For example, a cause with probability 80 is reduced by two implemented treatments with effects of 20% and 30%:
Current probability = 80 × ((100 − 20) / 100) × ((100 − 30) / 100) = 80 × 0.8 × 0.7 = 44.8
The result is placed on the scale and shown at the matching level in the risk matrix. - When an acceptance threshold is used, a risk scores the mean of its probability and consequence on the same 0–100 scale. A risk above the threshold counts as unacceptable. See Risk acceptance.
When the bowtie is complete, click Finish risk assessment and continue with Step 4 - Treatments & cost-benefit.