
Risk BowTie Method - unixhero
https://www.juliantalbot.com/post/risk-bow-tie-method
======
pge
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)

~~~
thetwentyone
Interesting recommendation. I've been wanting to read something that talks
about important failures and the root/structural causes. E.g. I loved reading
into the Challenger disaster and the follow-up investigations and was
interested in similar types of events to learn from. Do you think that book is
along those lines or something different?

~~~
pge
yes - Perrow spends much of the book (too much, perhaps) on case studies, with
Three Mile Island being the most significant.

------
PaulAJ
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](https://diametricsoftware.com)

------
A_No_Name_Mouse
A really good explanation of the bow tie method can be found on
[https://www.youtube.com/watch?v=dpGKHncw-d8](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?

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

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

~~~
dragonwriter
> Well, I wouldn't call it a "method"; it's just a graphical way

“way” (in this sense, as opposed to say the sense of “road”) is a synonym for
“method”.

~~~
Rochus
I am an engineer and as most other engineers have a concrete idea of what
"method" means; in any case, it is about much more than just painting
something. However, I agree with you - if I interpret you correctly - that
often the method how the result is developed is confused with a way of
presenting the result. Since Merriam Webster indeed offers "a way of or for
doing something" as a synonym for "a systematic procedure [...] employed by or
proper to a particular discipline" I changed my statement a bit to avoid this
(weak) ambiguity.

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

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

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

------
dctoedt
Reminiscent of Feynman diagrams.

