Threat Modeling Big Chunks

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:

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

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 ๐Ÿ™‚



Comments (7)

  1. Kevin Lam says:


    Great blog there — to answer your question of which one is best, I like to look at it as which one is appropriate.  This is what I used to tell customers back when I worked on the ACE team and my customers now: for threat modeling line of business applications (LOB), you want to use the ACE threat modeling process.  For independent software vendor (ISV) scenarios, that is you are developing software and shipping it to be installed on customer computers (like Word, SQL Server, etc.) then you want to use Frank Swiderski’s process.  

    Incidentally, Frank doesn’t work for Microsoft anymore so might be interesting as to what he comes out with next ๐Ÿ˜›

    Again, great blog!


    Kevin Lam

    Impacta LLC (

    "Risk management solutions working for you"

  2. Alik Levin says:


    Thanks for nice words and the comment on this post.

    Appreciate it.

  3. alik levin's says:

    This post is inspired by Dave Ladd’s Security Education v. Security Training My favorite quote is "We

  4. alik levin's says:

    Lifecycle and prioritization seem like a key to successful implementation of Security Engineering. Why

  5. alik levin's says:

    I always suggest conducting Threat Modeling even in advanced dev cycle stages, although it might seem

  6. alik levin's says:

    patterns & practices team maintains Design for Operations [DFO] project on codeplex . The goal of

Skip to main content