Confessions of a Catastrophizer: How to Put Threat Models to Work for Your Organization

It is said that the first step in recovery is admitting you have a problem, so here goes. I am a catastrophizer.

For the benefit of the unafflicted, a catastrophizer is anyone who perceives an event to be worse than it is or assumes the worst possible outcome. To be fair, I only expect the worst outcome so I can imagine all the conceivable conditions leading up to that point. Case in point, my affinity for airplane disaster documentaries. It’s extraordinary how even in an industry like aviation with strict standards and procedures, one small misstep can start a cascade leading to a catastrophe. Whether it’s a curse or a blessing, catastrophizing is actually a very helpful trait in some circumstances – like cybersecurity – if you know how to harness catastrophic thinking.

“It’s extraordinary how even in an industry like aviation with strict standards and procedures, one small misstep can start a cascade leading to a catastrophe.”

One of the best ways to put a catastrophizer to work is by using threat modeling, which is a process that attempts to identify and quantify threats and vulnerabilities posed to an information asset with the aim of prioritizing and treating them. There are many different approaches to threat modeling including some with clever acronyms like STRIDE, PASTA, VAST as well as Trike, MITRE ATT&CK and many others. Two of my favorites are not specific to technology and I’ve found to be a good jumping off point before diving into the technical models. They are Fault Tree Analysis and Bowtie Analysis.

Fault Tree Analysis is one of my favorites because of its visual approach. In fault tree you start with a realistic negative event and branch out through potential contributing factors, working toward a root cause. As one example, let’s say the event is unauthorized data exfiltration. At a high level, major causes to unauthorized data exfiltration might include network intrusion or application compromise. Potential weaknesses for each major cause are then identified before including the contributing factors until you reach the actual or possible root cause.

Expanding on that example, under network intrusion we might record misconfigured firewall rule as a potential weakness, and its possible root causes could be insider threat, ineffective change management, insufficient third-party management, inadequate training, business culture, and so on. This sort of exercise can be a great way to examine layered defense approaches (defense in depth) that include both administrative and technical contributions. Also keep in mind that there may be combination of contributing factors such as a business culture that favors speed over quality coupled with absent or inadequate code testing.

Fault Tree Example:

• Event: Unauthorized Data Exfiltration
  • Major Cause: Network Intrusion
    • Potential Weakness: Misconfigured Firewall Rule
      • Possible Root Cause: Insider Threat
        • Contributing Factor: Lack of Background Checks
        • Contributing Factor: Weak Hiring Processes
        • Contributing Factor: Inadequate Training
      • Possible Root Cause: Ineffective Change Management
        • Contributing Factor: Lack of Change Policy
        • Contributing Factor: Lack of Procedures
      • Possible Root Cause: Ineffective Third-Party Management
        • Contributing Factor: Lack of Third-Party Monitoring
        • Contributing Factor: Inadequate Procurement Processes to Ensure Provider Quality
  • Major Cause: Application/OS Compromise
    • Potential Weakness: Business Culture
      • Possible Root Cause: Ineffective SDLC Governance
        • Contributing Factor: Preference Toward Speed Over Quality
        • Contributing Factor: Absent or Ineffective SDLC Process
        • Contributing Factor: Ineffective Release Management
        • Contributing Factor: Lack of Code Testing
    • Potential Weakness: Ineffective Patching Program
      • Possible Root Cause: Long Lead Times to Apply Critical Patches
        • Contributing Factor: Missing or Inadequate Test Environment
        • Contributing Factor: Inadequate Staffing

Note: The example above has been bulleted for the blog format, though I recommend using a flow chart format. It’s a great idea to start brainstorming on a whiteboard first.

Similarly, bowtie analysis takes it a step further by placing the event at the center. To the left are the threats, vulnerabilities and potential preventive mitigations that can lead to the event’s occurrence. To the right are the recovery (post-event) safeguards and the consequences when the controls fail. One major benefit of Bowtie Analysis is that it provides a better opportunity to chart the safeguards and actual consequences than does fault tree.

For either model, the exercise should shed light on the factors that may increase the likelihood of the negative event’s occurrence. Ideally, you could remove the conditions that created the contributing factors. In most cases, however, that’s not possible and you’ll be taking a closer look at the mitigating factors you have in place to reduce the likelihood or impact of the weakness or failure.

Which method is best for your organization depends on the maturity of your cybersecurity management system, the complexity of the environment and the skills of those conducting the exercise. My suggestion is to start with fault tree analysis and work toward more complex models specific to your organization or the technology being employed. The objective is to gain insights about the threats to your information infrastructure. It’s likely you will uncover a vulnerability lacking a control or find a new vulnerability altogether. Such a discovery is great news and the perfect opportunity to strengthen your security program.

Whichever method you choose, it’s essential that everyone contributes. This is not an exercise for the technical team alone; representatives from human resources, operations and management should be included. With that said, I have sometimes seen resistance from surprising places. Make sure all the participants know it is a safe space to discuss what could go wrong. When you uncover a new threat or vulnerability, it isn’t about blaming anyone or any departments. This is simply an exploration of the possible, however impossible someone from the group may believe it to be.

For more information on next steps, including prioritization and mitigation of the findings, feel free to contact me.