Izar Tarandach & Brook S.E. Schoenfield

A couple of years ago I was engaging a new team into our Secure Development Life cycle (SDL) process. One of the initial activities is Threat Modeling, and in discussion with a product architect, I was asked, “We have a working design here, and now you want to come poke holes at it?” Having been in his shoes in the past, I struggled briefly with an explanation that might ease his reservations. The best I could come up with was, “I want to come explore with you how an attacker might poke holes at it, and help you stop them before it happens.”

Threat Modeling has been compared to an art form, black magic, contact sport, and spaghetti-on-the-wall-throwing. And every single one of these comparisons has a basis of truth, like most jokes. Threat Modeling is not immediately well-understood, and many times seen as an obstacle on the way to implementation and deployment, or as an after-the-fact detail of documentation.

But the fact is that it continuously proves itself as one of the most rewarding activities performed in favor of securing software. Identifying flaws at design time and working their mitigation into the fabric of the product beats fixing vulnerabilities at emergency pace in all possible measures. Worse, a problem with a design might cause lengthy rework or increase risks past the threshold of some potential users.

While having a subject-matter expert around to help navigate the process is a good thing, it is unfortunately beyond the possibilities for many software producers – these experts are still somewhat hard to find and many organizations still don’t have a security-oriented approach that would justify having a dedicated security practitioner, among other constraints.

With this document, the members of SAFECode aim to lend some of our many years of expertise to those who are new to the Threat Modeling process. We have renowned book authors, highly recognized conference speakers, people who have helped develop the methodologies in use by many practitioners; it is an accumulated amount of experience that is hard to find in any other body. SAFECode has brought these experts together to see what kind of guidance, advice, pointers and examples could be collated that would ease your way into Threat Modeling, and perhaps demystify it a bit without requiring your extensive research and reading. We’ve added references as well, so that you have a place to go after you digest our offering.

Rather than putting it on the table and walking away, we are interested in your feedback. We’d like to hear from your experience, what you learned, if you think we could have done something differently and better. Use what’s there; see what works and what doesn’t for you and your organization. Tell us what we may have missed that’s already working for you.

Much like a threat model, we would like this document to remain up-to-date and useful by adding your input to it. Much like the architect back then, we want you to realize how Threat Modeling will work for your team and your product and how you will benefit from a methodical approach to design flaw identification and mitigation.

Read Tactical Threat Modeling White Paper