Risk BowTie Method(juliantalbot.com)
juliantalbot.com
Risk BowTie Method
https://www.juliantalbot.com/post/risk-bow-tie-method
9 comments
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)
Another view which addresses the complexity is STAMP (Systems-Theoretic Accident Model and. Processes) by Nancy Leveson. Rather than look at scenarios she sees a system as a set of nested control loops, where each loop involves two-way information flow between a system and a controller. STAMP analyses the information flow looking for messages which might cause erroneous behaviour if they are wrong.
This is based on the observation that in many system failures every component is found to have operated within its specification, but the system still failed. The 737-MAX is a good example; the MCAS did exactly what it was supposed to, given its inputs. Even the failed sensor was within spec, in the sense that the fleet-wide sensor failure rate no higher than expected. The problem wasn't a component failure, it was the interaction between a system (the airframe) and a controller (MCAS) once erroneous information started to flow. This was then exacerbated by the next control level up, where information about the MCAS failed to flow to the pilot who was controlling it.
This is based on the observation that in many system failures every component is found to have operated within its specification, but the system still failed. The 737-MAX is a good example; the MCAS did exactly what it was supposed to, given its inputs. Even the failed sensor was within spec, in the sense that the fleet-wide sensor failure rate no higher than expected. The problem wasn't a component failure, it was the interaction between a system (the airframe) and a controller (MCAS) once erroneous information started to flow. This was then exacerbated by the next control level up, where information about the MCAS failed to flow to the pilot who was controlling it.
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?
yes - Perrow spends much of the book (too much, perhaps) on case studies, with Three Mile Island being the most significant.
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
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?
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.
> 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”.
“way” (in this sense, as opposed to say the sense of “road”) is a synonym for “method”.
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.
It's a method, a method of thinking, which connects event tree and fault tree. A powerful way of working with hazards and risks.
We certainly use this all the time.
We certainly use this all the time.
Well, μέθοδος is derived from μετ᾽ (met᾽: towards,after) + ὁδός (hodós: road,way). So 'way' is a synonym in both senses.
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.
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.
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.