Robert Hurlbut Blog

Thoughts on Software Security, Software Architecture, Software Development, and Agility

Make Threat Modeling Work For You at O'Reilly Software Architecture Conference

Monday, March 7, 2016 Comments

 Architecture  Security  Threat Modeling  Speaking 
Share:   Share on LinkedIn    Share on Twitter    Share on Facebook   

Over the past couple of years, I have been speaking about, writing about, and helping companies and their teams with addressing issues in software security. In particular, I have several speaking opportunities early this year to talk about one of my favorite security, architecture, and development topics: Threat Modeling. In the next few months, I am speaking at local (Massachusetts/Connecticut) user groups (NAISG Boston Chapter Meeting on 3/8) and conferences (2016 Central Ohio InfoSec Summit, Columbus, OH on 3/29-3/30, Boston Code Camp 25 on 4/2, and the O'Reilly Software Architecture Conference on 4/10-4/13. If interested, you can see my full speaking schedule.

Last week, on March 1, I spoke in an online webcast for the O'Reilly Software Architecture Online Conference as part of four software architects addressing the topic "Stratetic approaches to real-world architectural challenges". I gave a preview of the talk I will be giving at the O'Reilly Software Architecture Conference in April. You can find the slides here on SlideShare: How To Make Threat Modeling Work For You or here on my website: How To Make Threat Modeling Work For You. It was four hours spent watching and listening to the other speakers and to their questions. 

I had a few questions about Threat Modeling in my part of the conference. I would like to mention these and discuss some of my answers.


1. Wouldn't "Warn User" as a mitigation strategy tell attackers where you are vulnerable?

(This is in reference to my slide on mitigation options - one of them being Warn User)

That is a very good point. Warn user really means "we know there is a threat, but we don't want to, can't for various reasons, or not our responsibilty to fix the issue and we are going to let you know there is a problem - use at your own risk". It is a "valid" mitigation option that businesses do take because of budget, or inability to fix the issue, but still want to make sure the feature is available. I agree - it is a difficult place to be and could let an attacker know where you are most vulnerable. Use with caution.

2. How long would it take to use 1-2 hour sessions to threat model a large system with lots of moving parts, etc.?

(This is in reference to my "typical threat modeling session" slide where I recommend taking 1-2 hours at a time for focused threat modeling sessions)

As with many things, it depends. Generally, though, each session builds on top of the previous session. My rule of thumb is to divide the system into sections, or features, or service boundaries and determine the threat model for each of these. These individual parts usually touch other parts, and when you threat model the next part, you will have better knowledge of the parts of the system this new part touches, and so on. I just completed a threat modeling engagement of a large enterprise product/system with lots of services and teams and we were able to threat model most of the system within a few months and meeting 1-2 hours at a time one or two times per team. The key is getting started and work your way through. You won't catch everything, but as you get started, you will quickly find out your weakest and most prominant attack surfaces, which will drive what you need to focus on for future threat modeling sessions.

3. Is there a threat model template we can use to get started?

There are several recommended books and resources I list at the end of my presentation as well as on my Threat Modeling page on my website. Each of these have great examples of case studies that may closely resemble your situation (e-commerce site, enterprise security, mobile application, etc.). Outside of that, I like using a simple Word document or Excel spreadsheet (or equivalents) to keep track of Risk Rating, Threat, Threat Description, Mitigation, Components/Services Involved, and Follow Up (bug filed, new requirement, completed?). My friend Dinis Cruz just posted a simple one-page threat model template to help you get started as well.


These are great questions! I look forward to speaking further on this topic at the O'Reilly Software Architecture Conference in April and other events. Tomorrow night, March 8, I will be speaking on "Developing a Threat Modeling Mindset" at the NAISG Boston Chapter Meeting which is a slightly new direction I am taking with the talk. If you have further questions or observations, please feel to include them in comments below. I will post more information on Threat Modeling in future blog posts - stay tuned.

Share:   Share on LinkedIn    Share on Twitter    Share on Facebook