I've worked in the financial services software industry for years. For the last couple years I ran the security division of a major online-banking software and services provider. Security is paramount in that market. The responsibility that goes along with the role is huge, but it's a responsibility that's shared by everyone involved. Taking security seriously can't be something that happens after the work is done, and it can't just happen at some milestone point in a project. It needs to be an ingrained principle, part of the way things are done from beginning to end.

Threat modeling, loosely-described, is a design process by which you examine your software application design through the eyes of the bad guys, in order to determine what your design needs to take into consideration and how it should be built to protect against malicious threats. From the design phase you take your documented threat model into development and use it as a living document throughout the development lifecycle. Or at least that's how we did it.

Larry Osterman, who's worked at Microsoft pretty much forever, is a pro when it comes to threat modeling and secure coding. I haven't ever met Larry, but I've read his thoughts on the topic and they're solid. He's written before a couple times about this, and more recently (over the past month) he wrote and posted a series of excellent articles on his blog about threat modeling at Microsoft in the Windows division. If you're into this sort of thing, as I am, it's also very interesting to look back at his articles from the earlier years and to compare how they do things today. They've matured quite a bit.

I'll leave the narrative and examples to Larry, but let me add this by way of punctuation: Threat modeling takes some time and effort, but understand that security is a critical component of quality. Reputations (and therefore businesses) depend on it. It takes a very intentional process to properly understand the landscape and to look at all the threats and vectors of attack. It's not easy for people to shift gears. Most developers spend all their time thinking in terms of getting software to function according to customer requirements. Just as important is making sure it won't do what the bad guys want it to do. So, if you're ready to argue that you don't have time to do threat modeling, I have a solid argument (several of them really, which are backed up by real-world proof) that you can't afford not to. Threat modeling is risk management for the software industry.

And then there's the very-real side benefit of threat modeling. When your designers and developers sit down before building the product and really start to think about all aspects of quality in a formal, documented manner, you don't just get security improvements. They'll be seeing and thinking about general product improvements that you just won't get otherwise. I can't tell you how many times someone has come to me during a threat modeling process with a look of glee in their eyes, excited to tell me "hey this threat modeling stuff is pretty cool, and we even came up with some other stuff that isn't strictly security-related but will make it a much better product. I'm glad we did this."

The rule of the game is strategic thought, proper defense, quality first, and better software done faster that costs less. And it can happen if you let it.

If you're a software developer, tester or product manger and you don't know what threat modeling is and how it works, you're missing out on something that really should be required in this day and age. So here is what you should do:
Read Larry's articles, they're quite good. - Buy three books (you'll notice Michael Howard is an author on them all):

The Security Development Lifecycle Writing Secure Code (2nd Edition) - Threat Modeling

  • Be a leader and implement what you learn.