"Experiences" Threat Modeling at Microsoft

If there is one thing we can learn from the past, it is that we are doomed to repeat our failures if we ignore it.

The reciprocal is also true. If we reflect on our experiences properly, there is a lot we can learn from it.

In the world of designing secure code, this becomes more apparant as we see Microsoft's SDL process mature. Next year will hit the 10 year mark where threat modeling, as a formalized methodology, has been going on at Microsoft. In its infancy in 1999 only a few people at Microsoft were engaged in this. Now... every team is. And we can see the benefits of that when we reflect on the less critical bugs that have been reported in the last few years.

Today I cam across an interesting paper by Adam Shostack titled "Experiences Threat Modeling at Microsoft". Adam has ownership of the SDL Tool I mentioned earlier this month, and it was interesting to see his approach in explaining how Microsoft is focusing on threat modeling, and how the design is for normal developers, and NOT for security experts alone.

This is a critical point. Where in the past Microsoft has indicated it was important to do bainstorming sessions with a security expert in tow, now ownership of the model comes from the developers themselves. By designing tools that allow the architects, designers and developers to all know how to look at threats to their systems, everyone benefits. It's more cost effective. And it raises the bar as everyone thinks more critical about the security impacts of the code.

This is rather refreshing. And a good, quick read. So check out the paper.

Happy reading!

Introduction to Microsoft's SDL Threat Modeling Tool

If you design and/or write code, building trustworthy software may or may not be a driver in your team. If you care to build secure code (which I would assume since you read my blog) threat modeling may be a very important part of your development lifecycle.

If you are a regular reader of this blog, you know earlier this year I challenged Microsoft to cross-breed The Microsoft TAM tool with Microsoft's internal threat modeling tool that they use for their own commercial software. While the TAM tool is a great application threat modeling tool, it doesn't align well with the use of STRIDE, as part of SDL. You can see the difference in the two processes with this image:

During MVP summit, Alun, Jesper and I sat in on a developer security session where I pressured hard on Adam Shostack, the owner of the tool within Microsoft, to release this tool to the community. At the time it was heavily coded to use internal Microsoft resources and pathings, and just wasn't in a position to be released outside the corporate LAN.

Well, I am proud to annouce that Adam and his team listened to our feedback, and released a beta of the tool this week for FREE to the community. You can download it here.

John Bristowe, Developer Evangelist for Microsoft, heard about this and invited me on to a podcast where we talk about the tool. You can check out John's blog post here, or download the MP3 here.

And finally, if you download the SDL Threat Modeling Tool and would like to discuss how best to use it, want to report ways you think it could be better, or want to report potential defects, you can visit the Microsoft Security Development Lifecycle (SDL) - Threat Modeling MSDN forum here. I am one of the moderators there, so if you would like to talk to me about the tool, this would be a great avenue to do so.

Many thanks to Adam, his team and Microsoft for releasing such a useful tool that can significantly help in the threat modeling process, and drastically reduce the time and associated costs in making this process part of the development lifecycle of many different dev shops in the community.

Developing applications to work as a Standard User in Vista

Have you ever felt that the UAC prompts in Vista are annoying? Well, did you know a LOT of them could be avoided if developers would just design their code in a way where they don't pass a privilege boundary and require elevation? Simple examples would include writing to privileged areas of the registry, and to areas of the file system that are ACL tight.

Sometimes its difficult for developers to understand WHAT requires elevation, and what doesn't. Microsoft has answered this with a special project written by Aaron Margosis called "LUA Buglight".

If you haven't heard of it before, LUA Buglight is a utility that helps identify "LUA bugs" in applications -- application features that that fail as standard user but that work as administrator. Aaron works on it in his spare time, so progress has been slow. But his recent release has some nice updates, including:

• Much better Vista support
  
• Streamlined UI and improved flow
  
• Identifies more bugs
  
• On XP, not restricted to using a local admin account to create the "this-user-as-admin" context
  
• On Vista, prompts for elevation just one time per session instead of for each test
  
• Log file names autogenerated with timestamp in the name to avoid accidental overwrite of previous logs.
  
• User options saved to the registry.
  

If you would like to download it, check out Aaron's latest post here.

LiveID becomes an OpenID provider

So here is something interesting for the OpenID world. Microsoft has commited to supporting OpenID for Live services. Not only are they commiting to it... they already have a working IdP!!!

You can check it out here.

Right now it is a beta, and shouldn't be used for real identity control. The main reason is the INT database is not wired to the product Live services.

Oh, and a warning. If you sign up at https://login.live-INT.com/ PLEASE DON'T USE THE SAME PASSWORD that you do for your production LiveID account. For obvious reasons.

Interestingly enough, shouldn't be long before you can use OpenID and prove your identity using your Information Card from LiveID. How cool is that!