When three years ago I started to practice Threat Modeling I thought it is most boring part of security (which itself is not the most fascinating thing to most of people). I hated it since it seemed too boring - interview folks, read tones of specs, and write documents. Come on! I am .Net code guy! But fortunately to me I was motivated by good reasons to keep doing it - one cannot build good design from security perspective unless security is considered through out the design process itself. That is essentially the one and single reason to do Threat Modeling.

Now what approach to take? How actually to conduct Threat Modeling? Here came the confusion...

These are some really good sources of knowledge I tried to adopt:

• Michael Howard's and David LeBlanc's book Writing Secure Code has the whole chapter on this.
• Frank Swidersky's book Threat Modeling that totally dedicated to the subject.
• JD Meier from patterns&practices  has detailed walkthrough in Improving Web Application Security: Threats and Countermeasures
• And then came out updated whole guidance form JD, totally dedicated to Threat Modeling Web Applications
• Also I found very cool walktrhough here - Guerrilla Threat Modelling (or 'Threat Modeling' if you're American)
• Our team, ACE (Application Consulting & Engineering) has very cool tool that supports the process - Microsoft Threat Analysis & Modeling (free download here) loaded with goodies.
• There is more...

Seems like we are really crazy about the topic, lets do some search, hmm indeed we really like it:

• Live Search
• Google

So which one is the best?

Depends on who you are. Are you developer, architect, IT guy, security auditor, security consultant, doing line of business app, ISV guy, what is your budget, what is your dev culture? There are lot more attributes.

So while I cannot map each each and every attribute to the above Threat Modeling techniques (which have a lots in common anyway), I found the big chunks of the process while conducting Threat Modeling that work for me and my customers. It is also very aligned to Security Language That Every One Understands

Here are my big chunks:

• Understand the business. Find some role that understands the business and can explain the biz processes and the valuable stuff from biz perspective. Usually it is mid range managers with the customer. This big chunk helps generating Threats and Objectives (which I use in the last big chunk).
• Understand application architecture and design. It is totally technical information. Find app architect and dev lead to understand how the dev solution supports/implements the biz processes explained in first big chunk. The outcome of this big chunk is static view of the solution, data flows, and major usage scenarios (not use cases!).
• Go home and analyze. Try to find gaps between the two big chunks above, i.e. how biz valuable stuff gets unwanted impact by technical implementation of the solution. This big chunk generates Vulnerabilities that the solution must [based on severity] fix.
• Go back to customer and show the analysis. This step must get senior management involved. I usually do not talk security stuff during this big chunk rather present to senior management threats [generated during first big chunk] that are not countered or poorly countered by the solution [vulnerabilities identified during second big chunk]. If I succeed to present it right then senior management directs development team to fix most severe threats. How? According to the fix I provide along with the vulnerability found.

It is not my invention rather what I absorbed from the resources above and adjusted to my needs.

Today I just love Threat Modeling and the above approach works for me - I am still got paid for this :)

Enjoy.