Bow Tie for Cyber Security Series:
0x01 - How to Tie a Cyber Bow Tie <-- You are here.
Welcome to the first installment in our Bow Tie for Cyber Security series, where we will focus on the use of the risk assessment methodology of Bow Tie analysis to examine the attack surface of software installations and discuss how we’ve used the technique at OSIsoft to examine our own software. The technique aims to improve the reliability and resiliency of a system to threats overall, regardless of attribution. While I’ll be sharing this material within the context of countering malicious actors, these same measures can protect against insider or incidental threats to the system as well.
To put this approach in context, in the early 90’s Bow Tie methodology was adopted and developed into an industry standard by Shell as a technique to analyze and manage risk. Traditionally Bow Tie has been used within the realm of safety, but the technique is broadly applicable to any situation where there is the potential for harm. With the convergence of IT and OT, safety and security are becoming more aligned; it’s time that we apply analysis tools from each area for common goals.
Bow Tie methodology provides a framework to assess risk by identifying the relevant threats, defenses against those threats, impacts and methods to reduce those impacts for any negative event associated with a hazard. In concept, by placing defenses and reductions in place as barriers, we both reduce the likelihood of the event and lessen the impact of the event should it take place. The example below is the simplest representation of a Bow Tie diagram. Within the context of security, we could conceptualize the approach as “keeping the bad guys out” with the measures on the left side of the diagram and “limiting the damage if they get in” with the measures on the right side.
Let’s take a look at an example. To construct a Bow Tie diagram, we must first identify the hazard. The hazard could be anything with the potential to cause harm, high pressure steam in a pipe, driving a car, etc. Next we identify the event, which is an occurrence where control is lost over the hazard such as a pipe bursting, or losing control of a vehicle. In this case, let’s consider running a web server as our hazard and a web server compromise as our event. With the event identified, on the left side we can enumerate the all of the threats that could potentially cause the event and on the right side we enumerate all of the potential impacts that could result should the event occur. After taking some time to brainstorm and research, I end up with a diagram like the one below. Here I’ve chosen to use broader categories of attacks, but depending on the use case, more granularity can be used when enumerating the threats and impacts. For example, a developer may want to map specific examples of potential exploits to investigate, while an administrator may find categories more actionable since many specific attacks can be blocked by similar defenses.
After the threats and impacts are enumerated, we can identify defenses to place as barriers between the threats and the event, as well as impact reductions to act as barriers between the event and the impacts. For this post, I chose to focus on a single threat and one of the associated impacts. The diagram below provides 4 barriers each for the threat “Overload Server Resources" and the potential impact of “Service Delayed or Unresponsive”.
For defenses, to prevent the server from becoming overwhelmed, we can: implement HA, harden IIS, set up Dynamic IP Address Restrictions or throttle the CPU. In the event the server is overwhelmed, some examples to limit impact include automatically recycling the application pool, or measures which facilitate response such as event logging, diagnostic data like performance counters and a notification system (pardon the shameless plugs) to alert of anomalous behavior. This list is by no means exhaustive, but reflects a few effective barriers for an IIS based web server.
This simplified example provides one threat and impact, but there is not a 1-to-1 correspondence between threats and impacts in general. One of the main benefits of Bow Tie analysis in cyber security is that it provides a way to visualize multiple facets of the security posture of a software module together. Security is about more than passwords and firewalls, but those are too often the only aspects that get attention. To get a more thorough picture with the web server Bow Tie, we still need to enumerate the barriers for each of the other threats and impacts, which is precisely what we'll do in the next installment.
So, I played it safe this time with a DoS example for a generic IIS web server, but keep an eye out for the next entry in the series where I’ll go into a deeper analysis of PI Coresight with a diagram. In the meantime, it would be great to hear your comments. In particular:
- Are you using Bow Tie for your work?
- If so, what areas have you applied the methodology?
- What are some of your favorite DoS defenses?
Update: Added table of contents with links to other posts in the series.