Risk BowTie Method

If you are interested in this topic, worth reading Charles Perrow's classic work, "Normal Accidents". The book is an analysis of industrial accidents (eg Three Mile Island) and their root causes. His observations suggest that correctly mapping the left side of a bowtie is virtually impossible in tightly coupled systems (ie. the possible pathways to a failure mode are too complex to be understood ahead of time). Mapping risk incorrectly can provide a dangerously false sense of confidence (perhaps a reference to Black Swans is in order here, but those were popularized 30 years after Perrow)

The "methodology" of bow-tie is that the diagrams are used to identify controls and show how they map on to hazards (often one control is applicable to several hazards). Once you have this mapping you can demonstrate that you have sufficient controls for the various risks, make trade-offs between controls, identify nugatory controls etc. And finally you can track the controls as requirements for the system to make sure that they all get implemented.

Its true that the diagram on its own is not a method, but once you have the diagram the rest of the method is pretty straightforward. The great thing about bow tie diagrams is that they capture the information you need for a high-level safety analysis without getting bogged down in the details.

Bow tie diagrams are also excellent for stakeholder communication. They are simple, intuitive, and don't require any training (imagine presenting a UML state chart to non-technical audience).

Product plug:

The Diametric Safety Case Manager does bow-tie diagrams, amongst other things. The diagrams are part of a model, so the tables of controls, hazards etc can be extracted from the model rather than maintained separately (i.e. the Don't Repeat Yourself principle).

See https://diametricsoftware.com

A really good explanation of the bow tie method can be found on https://www.youtube.com/watch?v=dpGKHncw-d8

Though I can see it helps in the analysis of a specific event, I feel to grasp how to use it to map risks a priori (in the area of cyber security). The total number of possible threat events run in the billions if you count all the possible threat actors, threats, vulnerabilities and impacts.

In the linked article, "car skids on wet road into tree" is just one event. Well, it could also have blown a tire or hit a cyclist instead. Do I make separate bow tie for each of those events? And how do I add up those risks? Risk/car owners just want to know how safe their car is. How does it help to map all possible failure modes? And if this is not the right method for it, what is?

I would recommend this method for documenting all functions, processes, APIs. It can be seen as making explicit what intended inputs, and outputs are, and adding layers to describe input validation to eliminate (buggy behaviors), and testing/fuzzing to prevent introduction of risks, and enabling exception code to mitigate unavoidable error conditions upon process completion. The bowtie method really encapsulates software behavior quite well.

Well, I wouldn't call it a "method"; it's just a combination of a fault tree with an event tree diagram for a given hazard; both of which are the result of a corresponding analysis. Bow-tie diagrams appear a lot in Eurocontrol documents and standards since twenty years (e.g. in their safety assessment method); also the FAA seems to use them.

This is the real deal.

It's a great thought tool to analyse risk and robustness, and how to improve security threat model of anything.

As an advice, focus on your threat vectors and establish barriers. Focus on the barriers. Do whatever you can in the org to fund raise to establish barriers to stop the risk threats to traverse the bowtie model.

The methodology behind the bow-tie method is great, but as with most sites explaining it, the graphs and examples are hard or impossible to read. The text in the graphs is small, the colours clash and the text boxes are too large to fit inside the graphics. This page even contains pictures of tables made in MS Word (as can be seen by the squiggly lines) so you can't select text or use a text-to-speech engine.

It's hard to trust a website to say correct or interesting things when it's put together so shoddily. This is a common problem with most "manager" related content I've come across on the Internet. Someone capable of writing and selling books should probably take the time to invest in making a better website.

Reminiscent of Feynman diagrams.