While trying to create threat model template for customers, I analyzed many threat models inside and outside Microsoft.  It was insightful to see the patterns of what was useful across threat models and what was noise.

A good threat model has the following components:

• Security objectives.  What must you do vs. what's nice to do?  These set the boundaries of what's in scope vs. what's out of scope.  
• Key Scenarios.  Where and how will your software be used? These put your software in context and gives you context while evaluating.
• Security mechanisms.  These shine the spotlight on explicit security engineering decisions.
• Trust boundaries.  These help you focus on critical places where security trust levels change.  These also help prioritize entry points.
• Data flows.  These help you trace data through the system, to expose potential issues.
• Entry points.   Where do you accept input?  These are primary attack vectors.
• Exit points.  Where do you write output?
• Threats.  A list of these helps you put perspective when ranking vulnerabilities.  What's the worst that can happen?  What can you live with?
• Vulnerabilities.  A list of these helps you identify actionable places in your software to address security concerns.

A good threat model serves the following purposes:

• Informs your design
• Scopes your security testing
• Helps reviewers evaluate your security decisions

By far, the most tangible output of the threat modeling activity is a prioritized list of vulnerabilities.  These are action items for your developers and input for your testers.  The developer makes a call on whether and how to fix, and the tester will test the fix.

This sample Template for a Web Applications Threat Model comes very close to showing what I've empirically seen to be useful, though there's always a gap between reality and real-time.

Today, I cleaned up my Security Wiki on Channel9 at http://channel9.msdn.com/Security

The purpose of this Wiki is to let me share information that may not be completely fit and finish like on MSDN.  This comes in handy for a few things:

• EcoSystem.  It's a part of my security information ecosystem.  Effectively, I flow information from my internal Wiki to Channel9 and then to MSDN at http://msdn.com/SecurityGuidance, as the information morphs from quick and dirty to more polished.  Think of it as incrementally rendering guidance and various degrees of "good enough".
• Emerging and volatile information.  I like carving out the volatile information from the more stable information.  If the information is too volatile, I prefer to keep it on the Wiki and let the churn wear down before moving to MSDN.  For example, while we continue to learn the FAQs, I like having the ASP.NET 2.0 Security FAQ on the Wiki.
• Experiments.  I like using the Wiki to explore ideas.  This could be a new way to see information or a new way to capture information.
• Feedback.  I like proactive feedback.  With the Wiki, I can send links to Wiki pages to my customer base and ask their thoughts.  It's also easy to for customers to add comments to the end of a Wiki page.
• "Good enough" information.  This may be the single most important feature.  Some information never quite makes the bar to be published on MSDN, but gets 80% of the way there.  For example, we didn't flesh out our ASP.NET 2.0 Security Scenarios and Solutions during our Security Guidance for .NET 2.0 project, but that doesn't mean you can't use them as is, to maybe save yourself a few cycles of your own pathfinding.
• Indexes and views.  The Wiki let's me quickly mock up new ways to see information.  For example, I was able to create indexes for security checklists, security guidelines, and security how tos.  I later used this model on MSDN.  It also let me test out a way to present FAQs (see the ASP.NET 2.0 Security FAQ)
• Stories and meta-information.  The Wiki is a good place to share some of the thinking and the behind the scenes.  In one example, I put together the key components of our application security methodology.  It's a bit choppy and more visual than text, but some customers were curious about the foundation of our guidance.  In another example, Ward shares his experience walking through end to end application scenarios with our p&p security team in "Making My First Scenario and Solution"

What's in store going forward for Security Wiki?  Well, potentially a lot.  I'm still thinking through some of the possibilities.  If you have things you'd really like to see more of, let me know, and I'll see what I can do.

How do you know which techniques to use to shape your software throughout the life cycle?  Start with the high Return On Investment (ROI) activities as a baseline set.  You can always supplement or modify for your scenario.

Most development shops have some variations of the following activities:

·        Design guidelines

·        Architecture and design review

·        Code review

·        Testing

·        Deployment review

Identifying design guidelines involves putting together a set of recommendations for the development team.  The recommendations address key engineering decisions such as exception management and include input from software vendor recommendations, corporate policies, industry practices, and patterns.  This is a high ROI activity because it helps creates the scaffolding for the project.

Architecture and design review is an exercise in evaluating the design against functional requirements, non-functional requirements, technological requirements and constraints.  It can be as simple as a whiteboard sketch or it can involve multiple documents, diagrams, and presentations.  An architecture and design review is most valuable when it’s performed early enough to help shape your design.  It’s less valuable when it’s performed late enough that it’s only function is to find “do overs.”

What better way to find problems than at the source?  Code review is a practical and effective way for finding quality issues.  While some issues can be found through static analysis tools, the advantage of a manual code review is contextual analysis (e.g. you know the usage scenario and likely conditions).

Testing is executable feedback for your software.  It works or it doesn’t.  If it works “right” is a bit trickier to establish.  The ideal case is where you establish an executable contract between your code and the requirements, including functional, non-functional and constraints.  It also helps to know what you’re looking for so you can test against it.   While testing is usually optimized around functional behavior, you can tune it for quality attributes depending on your ability to set measurable objective and to define what good looks like.

Deployment review is an evaluation of your application deployed to your infrastructure.  It’s where the rubber meets the road.   This is where you evaluate the impact of configuration settings against runtime behavior.   A deployment review can be your last actionable checkpoint before going into production.  Preferably you have a working build of software earlier vs. later in your development cycle so that early deployment reviews can help reduce surprises going into production.

What makes these activities high ROI activities is that, if applied properly, they directly impact the shape of the software throughout the process.  I know these are high ROI activities because I’ve seen them transform my customers’ results for the better.  These activities provide key feedback and action at high-leverage points in the development process.

As a software engineer, how do you cope with information overload?  I suggest domain specific categories.  If the basic idea of domain specific languages (DSL) is a software language targeted at a specific area of problems, then domain specific categories (DSC) are an idea to create categories specific to an area of problems.

Here's some practical usage for the categories:

• Organize sets of recommendations
• Organize sets of principles, practices, patterns and anti-patterns
• Organize sets of questions for more effective design inspections, code inspections, and deployment inspections
• Improve communication and information sharing across teams and orgs by using the categories
• Prioritize categories for effectiveness
• Chunk up or partition work effectively

Here's practical examples illustrating domain specific categories:

• Web Application Security Frame
• Web Application Security Design Guidelines
• Web Application Security Architecture and Design Review
• ASP.NET 2.0 Security Guidelines
• Web Application Performance Design Guideline
• Web Application Performance Architecture and Design Review
• Improving Managed Code Performance
• Improving ASP.NET Performance

In the examples above, notice how the headings are carefully chosen categories.  Each category that organizes recommendations is evaluated against both the problem space, such as security or performance, the application type, such as Web application, and then the specific technology at hand. 

Also notice how the baseline categories in the Web Application Security Frame become more specific and relevant in two ways:

1. Information within each category is more specific (e.g. general Web Application input validation vs. input validation in ASP.NET)
2. Categories are added or modifed based on the domain (e.g. ASP.NET has specific categories beyond than Web Application baseline set) 

Are there down-sides to not using a one set of categories fits all approach?  You bet ... but based on the results I've seen from practitioners, I'd bank on using more thoughtful and empirical categories that are tested against how actionable and relevant they are.

The Web Application Security Frame is a set of categories you can use to scope security and improve your effectiveness.  It consists of the following categories:

• Auditing and Logging
• Authentication
• Authorization
• Configuration Management
• Cryptography
• Exception Management
• Input and Data Validation
• Sensitive Data
• Session Management

We created these categories during Improving Web Application Security to represent two things:
1.  Where are the most common mistakes made
2.  Where are the most actionable improvements

How do you use these to be more effective?  You use these categories to focus and prioritize your security work.  For example, if you know the most prevalent security issues occur in the input validation, authentication and authorization categories, you can start there.

You can immediately put the Web Application Security Frame into action.  when you perform Security Design Inspections or Security Code Inspections you can use the frame to walk categories of common security issues.  To do so, see the following:

• Web Application Security Design Review
• How To Perform a Security Code Review for Managed Code 
• ASP.NET 2.0 Security Question List

For more information on the Web Application Security Frame, see Cheat Sheet: Web Application Security Frame.