The goal is to offer diagrams that respect some legal requirements imposed by the legislation governing the field under study. Hence, the users unfamiliar with the topic, have direct access to pre-filled diagrams and do not have to browse through the legal texts to create them.

This is necessary in many areas where legislation exists. For instance, the French National Agency for the Security of Information Systems (ANSSI) published its requirements' framework for secure administration and maintenance providers, in April 2020. Any actor wishing to carry out a risk study concerning the management of an IT system will therefore have access to a design template containing the ANSSI's requirements related to the management of cyber risks on a local network. The corresponding design pattern is shown below.

We have designed two methods (top-down & assets-driven) and applied them on different case studies in order to assess their advantages and limitations, whether on the software or in their effectiveness. The results obtained are analyzed using various evaluation criteria (see the evaluation section for more details) allowing, among other things, to estimate the relevance of the case study.

It consists of defining the central part of the diagram (unwanted event, danger and impacted assets), then developing the left part of the diagram summarizing the causes that can lead to the realization of the event, and finally the right part of the diagram modeling the consequences of the event's occurrence.

1 / 5

2 / 5

3 / 5

4 / 5

5 / 5

❮ ❯

It consists of an iterative loop: after having defined the unwanted event and its danger, for each asset added, we complete parts of the diagram (causes and consequences) which have a link with the considered asset.

1 / 5

2 / 5

3 / 5

4 / 5

5 / 5

❮ ❯

The different risk analysis methodologies applicable to BowTie++ need to be evaluated in an objective way before drawing conclusions. This implies defining the relevance of the diagram created with this methodology. This is why we have set up several evaluation criteria: quality indicators and performance indicators. These include the level of complexity of the diagram, ratios between barriers and threats, causes and consequences, and the time taken to create the diagram. Each diagram created during our research phase can be evaluated and the results obtained can be used to define a correct diagram.

The user is guided throughout the whole creation cycle of their diagram. As it is possible to see in the demonstration below, the user is invited to give a hazard, an unwanted event and 3 or more different assets. Then the user can add as many causes/threats, barriers, escalation factors or consequences as desired. The order is decided by the methodology (top-down or assets-driven) we decide to keep as default.

LIVE EXAMPLE

This securing process has 3 goals :

• Modeling the security of Bowtie++
• Testing the security of Bowtie++
• Bowtie++ patching

The first objective is materialized by creating Bowtie diagrams allowing us to analyze the risks incurred by the application. This will allow us to apply the Bowtie method to a concrete case study and evaluate its usefulness in a cyber security driven scenario.
Moreover, testing the current state of the app’s security is done through a pentest phase which consists of searching for all the possible vulnerabilities that we have listed in Bowtie diagrams previously created. And finally, we aim at strengthening the app’s security by implementing remedial measures specific to the vulnerabilities found.

To fill-in the likelihood and impact matrices, the user has to decide the scale they want to use. Once the scale is set, the user can register it on the help menu so that other users working on the diagram can use the same scale to fill-in the matrices.