I spoke a couple times this past week on the topic of "Threat Modeling for Secure Software Design". Here are the decks (there are some slight differences, with BCC 24 one being most current):
Western Mass Development Technology User Group - 11/19/2015 PDF
Boston Code Camp 24 - 11/21/2015 PDF
In both sessions, there were a lot of great questions. Here is one that stood out for me:
Can we do all of this (i.e threat modeling) with a tool instead?
My answer:
A short answer: No.
Long answer: There are some tools out there, like the excellent Microsoft Threat Modeling Tool 2016 which helps you find threats in your software architecture. And, of course, there are several static and dynamic source code scanning tools, as well as pen testing tools to use against your application, but these find the low hanging fruit and other obvious problems.
One thing you find in secure software design and development is as much as you can automate things (and we are getting better and better at this), ultimately the process is still a human endeavor. The tools will never understand all of your business processes and workflow. Even the Threat Modeling Tool from Microsoft will only help you find what is common. Threat modeling really takes an understanding of the business goals, the technical goals, and how well the developers, QA, project managers, architects, and other business stakeholders understand the impact of security decisions for the application. It takes people, not tools and code, to understand the importance of security throughout all of the application.
So, as much as we like our tools, threat modeling is necessary because it is still people who make business decisions, write code, and work with the applications.
For the talk I gave on 11/19 I had more time to include a sample threat modeling session. By request, I led the group to start creating a threat model for a Javascript SPA application. I will post a separate blog entry on my research and some guidelines for creating your own threat model for JS SPA app.
