-=[FREE]=- Microsoft Attack Surface Analyzer

Microsoft’s Attack Surface Analyzer is an SDL verification tool for developers and IT professionals to identify whether newly developed or installed applications inadvertently change the attack surface of a Microsoft Operating System.  The free tool is downloadable from Microsoft’s website and is the same tool used by internal Microsoft product development teams.

Can’t wait to get home and download this tool, and see what it can do.  Microsoft will offer consulting services pertaining to SDL beginning in February.  The goal is to improve software security and reduce both customer risk and costs of development.  Other free tools (SDL Binscope Binary Analyzer, SDL Threat Modeling Tool) were also updated.

Microsoft is also releasing a report it commissioned from Forrester Consulting, entitled “State of Application Security,” studying the current state of application development practices and  investigating the potential return on investment by incorporating holistic security methodologies into product development life cycles.  The findings in the report validate the notion that addressing security early makes good business sense.   You can find a copy of the report on the Microsoft Download Center.

Elevation of Privilege: Threat Modeling Card Game

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.