Tuesday, 02 October 2007

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:

  1. Read Larry's articles, they're quite good.
  2. Buy three books (you'll notice Michael Howard is an author on them all):
  3. Be a leader and implement what you learn.

Add/Read: Comments [1]
IT Security | Tech
Tuesday, 02 October 2007 19:17:50 (Pacific Standard Time, UTC-08:00)
#  Trackback

Referred by:
http://search.daum.net/ [Referral]
http://sport-novosti.com/user/vierilaxled/ [Referral]
http://www.jewelrymart86.com/ [Referral]
http://www.jeanstruereligion.org/ [Referral]
final threat model documentation (www.google.com) [Referral]
http://www.drebeatsheadphones.org/ [Referral]
http://replica-bag.co.uk/ [Referral]
threat modeling using onenote (www.bing.com) [Referral]
http://uiphone.wikispaces.com/ [Referral]
http://www.blogster.com/aleahaleah/unlock-iphone-items-to-ke... [Referral]
http://www.upsaid.com/adelinealex/ [Referral]
http://alanisalexa.wordpress.com/2012/04/01/how-you-can-unlo... [Referral]
http://themastercleanse.org/ [Referral]
http://alaynaalayna.blogspot.in/2012/03/unlock-iphone-things... [Referral]
http://unlockiphone.podbean.com/ [Referral]
http://www.help-women.com/user/lestiantofeta/ [Referral]
http://abbigailkari.insanejournal.com/256.html [Referral]
http://www.flixya.com/blog/4340973/Backlink-services-An-Over... [Referral]
http://www.articlesvision.com/blogs/17542/backlinks-service-... [Referral]
http://www.jukeboxalive.com/blog.php?blog_id=8859641 [Referral]
http://thefirmwareumbrella.blogspot.com/p/change-log.html [Referral]

Tuesday, 31 March 2009 23:10:35 (Pacific Standard Time, UTC-08:00)
Great post - I did some research a couple years ago on the role of software defects in major data loss events and it came out that over 50 percent of all data loss events in a study of 140 - were related to basic software defects - in other words - if you design and implement good code it will also be safe code. We've been using the PTA - practical threat analysis methodology and tool for about 2 years and it is a great way of quantifying and prioritizing software security countermeasures (in my humble experience anyhow). I've posted a link to the free eval here - <a href="http://www.software.co.il/pta">PTA free download</a> and there is an article here about how to use PTA - <a href="http://www.software.co.il/risk-management/238-using-threat-modeling-for-cost-effective-security-and-compliance-management.html">for cost effective security and compliance management</a>

Best regards
Danny Lieberman
Comments are closed.