Are you interested in learning more about, or running tabletop exercises for Threat Modeling in your organization? Want to introduce the Software & Security Development Life Cycle to your dev teams and security folks? How about making it interesting, educational and FUN!?
Microsoft has made a card game out of threat modeling, find the details and downloads here. The idea is to print out security scenarios on cards and create a competition to figure out how each scenario can be applied to an application. They do a good job of enumerating common scenarios for each stride element – it isn’t exhaustive, but it covers a good deal of ground and should provide good guidance to staff that may not be accustomed to thinking about attack scenarios. A development team may even enjoy finding and documenting security threats. It’s a clever way to approach threat modeling.
Just like in the classic threat modeling process, the diagram of the application is incredibly important. It balances the entire exercise, and provides the hinge-point to success or failure. A diagram that doesn’t model ALL of the data flows is going to miss threats and be incomplete. A diagram that is too high level or leaves crucial details in the abstract (for example a series of components collapsed into one entity, hiding a trust boundry), could be be a real handicap. A diagram that shows unnecessary elements is also problem because it presents more information than humans can consume in a single session.
For those of us looking to introduce threat modeling into your organization, this is a good starting point. If your organization develops its own applications, you should consider threat modeling in some capacity. It is the best methodology I have found for doing design level security analysis.