Jeremy Dallman here to let you know we published a couple of new interesting Microsoft SDL stories last week in an effort to continue demonstrating in a tangible and easy-to-read way how Microsoft teams implement the SDL.

We hear about more companies investigating how they can integrate the Microsoft SDL into their software development process in order to ship more secure software. At Microsoft, we have been doing this for several years, but have only recently shared the stories behind how our product teams do the SDL (see SDL Publications – whitepapers). As Windows Internet Explorer 8 and the 2007 Microsoft Office System were publicly released, the security experts that guided those products through the full Security Development Lifecycle saw an opportunity to share some details about how each of these products executed on the SDL. They have written the stories of the SDL for each of these products.

How the Security Development Lifecycle helped improve the security of the 2007 Microsoft Office System

Internet Explorer 8 and the Security Development Lifecycle

These papers can serve as a reference tool as you begin to think about the implementation of the SDL in your own software development lifecycle. The Microsoft SDL has been in place at Microsoft for almost six years and has demonstrated its effectiveness in improving software security. We hope that these papers along with the SDL Optimization Model, the Simplified Implementation of the Microsoft SDL  whitepaper, and our other resources on the SDL portal will help you as you begin integrating the Microsoft SDL into your own software development process.

If you are starting to think about adopting the SDL or already have created your own version of the SDL, we would love to hear from you! Feel free to either tell us in the Comments section of this post or email us directly.

Adam Shostack here. I’m pleased to announce that at RSA this week, Microsoft is releasing Elevation of Privilege, the Threat Modeling Game. Elevation of Privilege is the easiest way to get started threat modeling. EoP is a card game for 3-6 players. Card decks are available at Microsoft’s RSA booth, or for download here. The deck contains 74 playing cards in 6 suits: one suit for each of the STRIDE threats (Spoofing, Tampering, Repudiation, Information disclosure, Denial of Service and Elevation of Privilege). Each card has a more specific threat on it.  For example, here’s the 5 of Tampering.

The threat is “an attacker can replay data without detection because your code doesn’t provide timestamps or sequence numbers.”

Because we want everyone developing software to threat model, and there’s no better way to get people to do what you want than to ensure they have fun while doing it.

Everyone in software draws diagrams. From pictures on napkins or whiteboards to DFDs, UML or other formalisms, everyone diagrams.

• You start with such a diagram (ideally, one focused on data flows) and deal the cards to 3-6 players. You’ll also want to assign someone to take notes.
• Play starts with the 3 of Tampering. The player with that card reads it out, and explains how the threat on the card (“An attacker can take advantage of your custom key exchange or integrity control which you built instead of using standard crypto") might apply to the system you’re building. If they can provide a credible threat, they get a point. A credible threat here is one for which you’d file a bug.
• Play proceeds clockwise until each player has had a chance to play a card. Each player needs to play in suit if they have a card in suit.
• When each player has played, the highest numbered card played wins. [Ace is high] The player who won gets a point for the hand, and gets to lead the next hand, including picking the suit that leads that next hand.
• If a player doesn’t have a card in the hand that was lead, they may play any card. Elevation of Privilege cards are “trumps” that beat any other suit. Only the suit lead or Elevation of Privilege can win the hand.

When you’re done (all the cards have been played), count up the points, give the winner a pat on the back, and have someone file bugs.

That may seem a little complex, but it’s pretty simple when you have cards in hand. There’s a video of me explaining the game here and of people playing on the launch page. There’s also a strategy card in the deck with a flowchart to help you decide what card to play.

Right now! If you’re at RSA, come by the Microsoft booth, or download the cards here

If you’re developing software, this is for you. We’d love to hear your feedback here, we’d love for you to blog about it, but most of all we’d love for you to play Elevation of Privilege.

Once you have, we’d also like you to play with the idea of serious games for threat modeling and security. To help you get started, we’re making Elevation of Privilege available under a Creative Commons Attribution license which gives you freedom to share, adapt and remix the game.

I want to thank Austin Hill of Akoha for introducing me to the wide field of serious games (see http://www.seriousgames.org/ or http://en.wikipedia.org/wiki/Serious_game for some more on the broad concept), and Laurie Williams of North Carolina State University for designing “Protection Poker,” which inspired me to design Elevation of Privilege.

On Friday, the team at Microsoft that’s driving our End to End Trust initiative launched a new web site that provides an update on the End to End Trust vision for a more trustworthy and accountable Internet.  The site’s launch was timed to precede Scott Charney’s keynote next Tuesday at the RSA Security Conference in San Francisco.  The site will be updated later that day with a video of Scott’s keynote.

One of the key components of the End to End Trust vision is what we refer to as “Security and Privacy Fundamentals” – the recognition that better authentication and accountability are only effective if the underlying computer systems are built to resist attack and the intrusion of unwanted software.  At Microsoft, the way we build systems to resist attack is by implementing the SDL for any products or online services that expose our users to risk.  The End to End Trust site includes several videos about the SDL and its role in End to End Trust, as well as links to details posted on the SDL web site.  I’d encourage you to review the End to End Trust site, Scott’s video when it’s posted, and of course the SDL information on both the End to End Trust and SDL web sites.

Steve Lipner

Hi everyone, if you’re headed to RSA next week be sure to check out these sessions featuring SDL team members:

Wednesday, March 3, 9:10 AM

Katie Moussouris and Bryan Sullivan

(A preview of this session is available as a podcast at https://365.rsaconference.com/blogs/podcast-series-rsa-conference-2010/2010/02/19/and-202-microsoft-sdl-tools-automating-the-security-development-lifecycle-pk-session.)

Wednesday, March 3, 9:10 AM

David Ladd, Eric Baize (EMC), Gary McGraw (Cigital), Richard Pethia (Carnegie Mellon University)

Wednesday, March 3, 10:40 AM

Katie Moussouris, Martin McKeay (Network Security Blog), Brad Arkin (Adobe Systems), Tim Stanley (Continental Airlines), Steve Dispensa (PhoneFactor), Michael Barrett (PayPal), HD Moore (The Metasploit Project)

(A preview of Katie Moussouris speaking on the topic of Responsible Disclosure can be found at https://admin.secure.streamos.com/streamos/player/flv/?url=http://rsa.edgeboss.net/flash/rsa/rsaconference/2010/us/podcasts/rsac_02-03-10-hot-203-moussouris.mp3.)

Thursday, March 4, 1:00 PM

Adam Shostack and Danny Dhillon (EMC)

Hi everyone, Bryan here. We’ve written here before about Casaba Security’s Watcher tool and how it can help you verify compliance with several of the SDL web application security requirements, such as:

·         User controlled open redirects

·         Insecure domain references in Silverlight client access policy files

·         Use of the Javascript eval method

·         More…

I’m excited to report that Casaba has just released Watcher v1.3.0, which adds even more useful checks and also integrates with the SDL and MSF-A+SDL process templates. In addition, it can also tell you which of its checks map to SDL requirements.

Watcher is available for free download on Codeplex, and Katie will be demonstrating Watcher during our presentation at RSA next week (AND-202: Microsoft SDL Tools: Automating the Security Development Lifecycle).

Hi, Michael here,

As you might be aware, a collaboration of industry experts and academia worked together on the CWE/SANS Top 25 Most Dangerous Programming Errors for a second year to define and describe the most significant programming errors that can lead to some of the most serious software vulnerabilities. As we did last year, Microsoft was involved helping define the CWE/SANS Top 25 for 2010.

As the process to define the Top 25 started to draw to a close and the draft top 40 candidates were selected to be whittled down to 25, we decided, as we did in 2009, to see how the SDL processes and tasks map to the Top 25. 

As we expected, the SDL maps very nicely to the 2010 Top 25, just as it did in 2009. Every one of the Top 25 is covered by one or more SDL requirements, and most of them are also covered by an automated SDL verification tool or secure coding library. Even CWE 98, "PHP File Inclusion," is covered by the SDL in our required security training classes, which is especially remarkable when you consider that virtually no PHP code is written at Microsoft!

The reason that we address issues like PHP file inclusion in the SDL is that we don't simply wait for new vulnerability taxonomies to be released and then rush to add mitigations to our security processes; rather, we structure the SDL to provide developers with fundamentally sound, secure programming practices. As a result, we cover not just the known vulnerabilities of today (like the Top 25) but also many of the unknown vulnerabilities that will be discovered tomorrow. The fact that all of the Top 25 are addressed by the SDL is a great validation, but it is the result of the content of our process and not the cause.

A year ago, I wrote a short post about us banning memcpy in the SDL for new code. Well, I’m happy to announce that in VC++ 2010, we have made it much easier to remove potentially insecure calls to memcpy and replace them with more secure calls to memcpy_s; it’s automagic, just like we do did for other banned functions!

As I said in a previous post, I am a huge fan of adding defenses to code automatically, and making such changes as easy as possible for software engineers, and this auto-migration is a great example.

In short, if your code has a call to memcpy, and the compiler can determine the destination buffer size at compile time, the compiler will replace the call to memcpy with a call to memcpy_s.

For example, if you compile the code below with:

cl /D_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES_MEMORY=1 foo.cpp

#include <memory.h>

int main() {

    int src[100];
    const size_t src_size =  _countof(src) * sizeof(int);

    memset(src, 12, src_size);

    const size_t dst_size_int = _countof(src);
    int dst[dst_size_int];

    memcpy(dst, src, src_size);

    return 0;

}

You’ll see that the calls to memcpy are replaced with memcpy_s courtesy of this code in memory.h:

#if defined(__cplusplus) && _CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES_MEMORY

extern "C++" {

#ifndef _CRT_ENABLE_IF_DEFINED

  #define _CRT_ENABLE_IF_DEFINED

    template<bool _Enable, typename _Ty>

    struct _CrtEnableIf;

    template<typename _Ty>

    struct _CrtEnableIf<true, _Ty>

    {

        typedef _Ty _Type;

    };

#endif

    template <size_t _Size, typename _DstType>

    inline

    typename _CrtEnableIf<(_Size > 1), void *>::_Type __cdecl memcpy(_DstType (&_Dst)[_Size], _In_opt_bytecount_(_SrcSize) const void *_Src, _In_ size_t _SrcSize) _CRT_SECURE_CPP_NOTHROW

    {

        return memcpy_s(_Dst, _Size * sizeof(_DstType), _Src, _SrcSize) == 0 ? _Dst : 0;

    }

}

#endif

Note that for this to work, you must define a preprocessor variable:

_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES_MEMORY = 1

This is another great example of why migrating your C++ code to Visual C++ 2010 can help improve the security of the code with virtually no engineering effort.

(Big thanks to the C++ folks over in the Developer Division for getting this work done in time for VC++ 2010)

- Michael

The SDL pond may have seemed quiet over the holidays, but we have three new announcements we hope will make ripples for developers and organization who want to adopt the SDL. We are announcing three new releases at the Black Hat conference in Washington DC today:

1.       a new white paper: Simplified Implementation of the Microsoft SDL

2.       a new program: SDL Pro Network Tools category and new members

3.       a new tool: MSF for Agile Software Development + SDL Process Template for VSTS 2008

Simplified SDL whitepaper

First up is the release of the Simplified Implementation of the Microsoft SDL white paper. One of the common misconceptions about the Microsoft SDL is that you have to be an organization the size of Microsoft in order to be able to implement it. Another misconception is that the SDL is only appropriate for Microsoft languages and Microsoft platforms, and that you need to use some other methodology if you’re writing code with Ruby for OS X. The Simplified SDL white paper helps address these misconceptions by explaining how the SDL can be implemented with limited resources and applied to any platform. By outlining a minimum threshold that stays true to the core attributes of the SDL, this paper provides an effective model for building an effective security development lifecycle in any organization.

SDL Pro Network Security Tools category and new members

Our second announcement is the expansion of the SDL Pro Network to include a new category of membership, Tools, which will complement the existing Consulting and Training categories. Tools member organizations are able to deploy security tools such as static analysis tools, fuzzers, or dynamic and binary analysis tools. Security tooling is a critical piece of the SDL and we’re excited to have this new Pro Network category to help organizations use their tools and their time more effectively.

We’re also announcing an expansion of the Pro Network to include seven new members:

·         Fortify (Tool Member)

·         Veracode (Tool Member)

·         Codenomicon (Tool Member)

·         Booz-Allen Hamilton (Consulting Member)

·         Casaba Security (Consulting Member)

·         Consult2Comply (Consulting Member)

·         Safelight Security Advisors (Training Member)

We welcome our new members and hope you will consider them or our other Pro Network members for your security training, consulting, and tooling needs.

MSF for Agile + SDL Process Template

Last, but not least, we’re releasing the first public beta of the new MSF for Agile Software Development plus SDL Process Template for VSTS 2008, or “MSF-A+SDL” for short. Like the SDL Process Template we released last year, this template helps teams to integrate secure development processes directly into their Visual Studio Team System development environment. However, the MSF-A+SDL template is based on the new SDL-Agile process. MSF-A+SDL also has some completely new features from our previous SDL Process Template offering:

·         Automatic generation of SDL task work items for new iterations. Given that Agile projects can live forever (as in the case of web applications or cloud services with no defined “end date”), these projects need to periodically re-complete SDL requirements as defined in the SDL-Agile process. The MSF-A+SDL template accomplishes this by creating new security tasks for the project whenever a user adds a new iteration.

·         Automatic generation of SDL task work items for new code. Whenever new Visual Studio projects or web sites are checked into an MSF-A+SDL project’s source control repository, the template will generate new SDL requirements appropriate to that project. For example, if the user creates a new C# web site, the template will add requirements such as disabling ASP.NET tracing, and applying the AntiXss library.

·         Much more, that we’ll be posting about here soon

If you’re attending Black Hat this week and would like to see MSF-A+SDL in person, come to Bryan’s talk “Agile Security; or, How to Defend Applications with Five-Day-Long Release Cycles” on Wednesday February 3 at 1:45.

Just in case you missed them inline, here are some handy links:

SDL Pro Network page

Simplified Implementation of the Microsoft SDL white paper

MSF for Agile Software Development plus SDL Process Template for VSTS 2008 free download

Jeremy Dallman here to tell you about some new security guidance papers we are releasing today.

“My company was just attacked by something called SQL Injection! I have no idea what that is, or what I should do next! Where do I start?”

Unfortunately, this is a frequent scenario for many developers and IT Pros who have just discovered their systems, websites or applications have been compromised.

We’ve spoken to a number of people in the IT community who equate this to being tossed a parachute and thrown out of a plane into free-fall with no idea what to do next.  These folks know the parachute will help them, but need a quick and easy way to find the D-Ring.

Today we are releasing the first of a new type of security guidance paper. We are calling them “Quick Security References” (QSRs). 

A QSR is designed to provide the information necessary to quickly understand and address specific security threats from the perspectives of four IT-focused job roles (business decision makers, architect/program manager, developer, and tester).  QSRs will also help establish security practices and provide a framework for addressing future incidents. 

For those familiar with the SDL Optimization Model, the guidance contained in a QSR is targeted at organizations that fall into the “Basic” level of organizational maturity.

The first two QSRs focus on Cross-Site Scripting and SQL Injection. We chose these two topics since they represent the most common attack types a development or IT Pro team will encounter today.

These papers were the result of some collaboration with some experts in both XSS and SQL Injection. I would like to thank each of them for sharing their knowledge and contributing to the paper.

Acknowledgements:

For the XSS paper:

Contributors: Jeremiah Grossman, Robert  Hansen, Gareth Heyes, Dennis Hurst, David Ladd, Eric Lawrence, Katie Moussouris, Billy Rios, David Ross, Bryan Sullivan, and Jeremy Dallman.

For the SQL Injection paper:

Author: Bala Neerumalla

Contributors: Raul Garcia, David Ladd, Katie Moussouris, Bryan Sullivan, and Jeremy Dallman

The QSR papers can be accessed from the SDL website or downloaded directly from the Microsoft Download Center.

Hi, Michael here.

Over the years, we have learned a great deal about the practical aspects of securing software; but two lessons that really stand out for me are:

·         You will never get the code perfect, so add defenses.

·         Make securing software as easy as possible for designers, developers and testers.

Anyone following the SDL will realize that we spend a lot of time, research and effort adding defenses such as /GS, ASLR, NX and so on and then making them SDL requirements. Another SDL defensive requirement we added about two years ago, is to add the following to the startup code, usually main(), in native C or C++ code:

BOOL f=HeapSetInformation(NULL, HeapEnableTerminationOnCorruption, NULL, 0);

You can read more about this function and its security benefits in a blog post from February 2008.

The problem with adding this code is you have to churn your code! Obviously, it’s not a big deal in this case, as the code diff is only one line long.

Even though I’m a huge fan of defenses like this, we’re always looking for ways to make life as easy as possible for developers, and often that means changing the way we generate code or adding defenses to Windows.

Now back to the subject of this post! Something we have added to VC++ 2010 beta 2 is an automatic call to HeapSetInformation() for all unmanaged C and C++ applications. I love this for two reasons: it’s a great defense that makes it harder for an attacker to successfully exploit a heap-based buffer overrun in your code, and it’s frictionless because there is nothing the developer needs to do other than compile the code with VC++ 2010 beta 2 or later!

Later in the year I’ll write about some other defenses in VC++ 2010 .

Michael

It's been a frighteningly confusing week for frequent flyers (and confirmed cowards) like me. First we had the Underpants Bomber, his Christmas-day attempt to take down a Detroit-bound flight thwarted by slow-acting chemistry and quick-thinking passengers. Next -- within a day -- came inexplicable new regulations that seemed designed more to punish the rest of us than to discourage future acts of terrorism. The new rules were unsettling not just because they seemed as laughably ineffective as they were inconvenient, but because they suggested that the authorities had no idea what to do, no real process for analyzing and reacting to potential new threats. As the Economist was moved to write, "the people who run America's airport security apparatus appear to have gone insane".

A few days later the TSA, to its credit, rolled back some of the more arbitrarily punitive restrictions -- in-flight entertainment systems can now be turned back on, and passengers are, at the airline's discretion, again permitted to use the toilets during the last hour of flight.

But while a degree of sanity may have returned to some of the rules, the TSA's new security philosophy appears to yield significant advantage to attackers. The current approach may actually make us more vulnerable to disruption and terror now than we were before. See the rest of this (rather long) entry...

If you can climb a fifteen foot ladder and fit through a two foot diameter hole, you can, with a bit of advance planning, take an extensive "top-to-bottom" tour of a Titan II ICBM launch complex, complete with missile silo and missile. Best of all, you no longer have to trespass or join the Air Force to do it.

And so I just returned from Sahuarita, AZ and the Titan Missile Museum, a place known during most of the cold war as SMS Launch Site 571-7. I spent the better part of the day beneath the surface of the earth, part of a group of six hardy nuclear tourists under the direction of Lt. Col. Chuck Smith (USAF, retired, a former "missileer" at the site), exploring the nuts, bolts and welds of Armageddon.

At the peak of the cold war, there were over 1,000 nuclear missiles in buried silos located throughout sparsely populated areas of the continental United States, all fueled and ready to be launched toward the Soviet Union on a few minutes notice. From 1963 through 1984, this included 54 Titan II missiles at sites in Arizona, Arkansas and Kansas, each equipped with a W-53 warhead capable of delivering a nine megaton thermonuclear yield. Nine megatons is horrifically destructive even by the outsized standards of atomic bombs, capable of leveling a good size city in a single blast. And the Soviets had at least as many similar weapons aimed right back at us.

How did we keep from blowing ourselves up for all those years? See the rest of this (rather long and heavily illustrated) entry...

The Information Security Tools (IST) team has released the InfoSec Assessment & Protection (A&P) Suite.  It’s a suite made up of protection and assessment tools which include:

• Web Protection Library (WPL) - an umbrella for several libraries and runtime modules including the Microsoft Anti-Cross Site Scripting Library v3.1 (Anti-XSS V3.1) and Security Runtime Engine (SRE), packaged together with Anti-XSS when downloaded. Helps prevent XSS and SQL injection attacks, but instead of having to make changes to the code (which is manual and costly), a user makes changes to the application configuration and not the code (white list/black list). Watch the podcast, “Enhanced Web Protection Library,” as Anil Revuru (RV) from the IST teams shares the details of the new expansion of this library.
• Code Analysis Tool for .NET (CAT.NET) - a managed code security source code scanning tool that has been totally rewritten.
• Web Application Configuration Analyzer (WACA) designed to scan your development environment against best practices for .NET security configuration, IIS settings, SQL Server Security best practices and some Windows permission settings.

Read more about the A&P suite here and watch the podcast, “Assessment and Protection Suite,” as Anil Revuru (RV) and Mark Curphey from Microsoft IST team discuss the future of this suite of tools.

To download these tools for free, you will need to register on the Connect site. Once you’ve registered, you can download the tools below directly. Get the latest on the A&P Suite on the IST Blog.

Download, A&P Suite will include:

• CAT.NET 2.0 CTP
• WPL 1.0 CTP
• WACA 1.0 CTP

Hi everyone, Bryan here. There is a common misconception that because the SDL was originally created for Microsoft’s big showcase box products like Windows and SQL Server, that it only works for those kinds of products. This is of course patently false: virtually every Microsoft product and online service, large or small, follows the SDL. Many other organizations outside of Microsoft are also successfully implementing the SDL. However, while the content of the SDL – its requirements and recommendations – may be universal, the structure of the SDL as originally designed is more suited to long-running waterfall- or spiral-style development methodologies. Consider the classic “chevron” SDL graphic:

As you can see, the SDL prescribes certain activities to take place during certain phases of the development lifecycle – threat modeling for example happens during the Design phase, and static analysis is performed during the Implementation phase. But not every development methodology has well-defined lifecycle phases like this. Specifically, Agile development methodologies do not have distinct phases and instead follow an iterative, time-boxed approach. How can the SDL be applied successfully in these environments?

One solution might be to take all the SDL requirements and put them into the product backlog, then pull them into the active queue (aka the sprint backlog, if you’re using Scrum) just like any other user story. This might work adequately for box products with well-defined product lifecycles that use Agile; for example, the Visual Studio teams that follow Scrum would fall into this category. However, the majority of internal teams (and very likely the majority of all development teams outside Microsoft too) that follow Agile use it to build web applications. This is important because web applications often don’t have a defined “end”; they just keep building and growing indefinitely. If we put the SDL requirements into the product backlog, it might take a year or more for a team to complete them all, but all the features added to the product after that date would go unsecured.

An alternative solution might be to just apply the entire SDL to every iteration. This would solve the problem of unsecured functionality being added after the SDL requirements have been completed, but it would create a whole new problem just as big, namely: how to complete all that SDL work in such a short amount of time! Per the Agile Manifesto, Agile projects should have short iterations, lasting from one month to a few weeks or less. There are online services teams here at Microsoft with one week long sprints. There’s no way these teams could complete the entire SDL in a sprint that short. And even if they could, there would be no time left to actually develop new features.

Another alternative would be to pare back the SDL, to cut out the “unnecessary” SDL requirements and just complete a smaller, core subset of the SDL each iteration. Unfortunately, this approach is flawed too, because none of the SDL requirements are unnecessary. Every requirement has been proven to prevent vulnerabilities or to reduce the impact of a successful exploit. Leaving requirements out of Agile projects would jeopardize their security, and that’s simply not an acceptable solution.

However, although none of these approaches solves the problem of adapting the SDL to Agile, that doesn’t mean the task is impossible. Over the last year, a team of security professionals throughout the Trustworthy Computing Security and Online Services Security & Compliance teams (including myself and Michael Howard from SDL) have worked to find a solution to the problem. Our resulting process has been in internal beta since the spring, has just recently released internally, and now I’m happy to announce that we’re releasing the details of the SDL for Agile Development Methodologies process today.

In brief, SDL-Agile breaks the SDL into three categories of requirements: every-sprint requirements, the requirements so important that they must be completed every iteration; one-time requirements, the requirements that only have to be completed once per project no matter how long it runs; and bucket requirements, the requirements that still need to be completed regularly but are not so important that they need to be completed every sprint.

Over and above the reorganization of requirements into a more Agile-friendly structure, SDL-Agile also provides guidance for adapting many of the core SDL activities to Agile. Threat modeling is a perfect example: a team could easily spend an entire week-long sprint performing threat modeling, but this may not be the best use of their time. SDL-Agile describes how a team can spend an appropriate amount of time modeling new features as well as how to build up a baseline of threat models for existing functionality.

Instead of getting into an in-depth discussion of SDL-Agile in the limited space I have here, I ask that you download and read the complete SDL-Agile guidance here, included as part of the SDL 4.1a Process Guidance document. We believe we’ve developed a process that is faithful to both Agile and to SDL, in which teams can innovate and react quickly to changing customer needs but in which the products they create are still more resilient to attack. As always, we welcome your feedback.

Hi everyone, Bryan here. I’m going to be presenting two sessions on the SDL next week, one for TechEd Europe and one for the Microsoft Platforma event in Moscow. If you’re attending either of these conferences, stop by and introduce yourself, or better yet stay for the session!

TechEd Europe:

SIA-205: SDL-Agile: Microsoft’s Approach to Security for Agile Projects

Monday 11/9 9:00-10:15, Berlin 1 Hall 7-3a

Platforma:

FF-206: The Microsoft Security Development Lifecycle

Thursday 11/12 4:30-5:30, Red Congress-Hall

Hope to see you there!

Hi everyone, Bryan here. Earlier this week, Microsoft released the latest volume of the Security Intelligence Report (SIR), which covers the first half of 2009. There are many interesting statistics in this report, but there’s one that I’d like to draw particular attention to: the number of industry-wide reported vulnerabilities as broken down by OS vulns vs. browser vulns vs. application vulns.

It is gratifying to see a sharp decline in the number of application vulnerabilities reported in the first half of 2009, but it’s important to note that they still make up the vast majority of vulns. Attackers are still largely focusing on the long tail of third-party applications. It’s more important than ever for all development shops, no matter how small, to bake security practices into their development lifecycles and ensure that their products don’t end up contributing to next year’s blue Application Vulnerabilities bar.

Cory at Matasano has a new blog post explaining “Ninja threat modeling.” Ninja threat modeling is Matasano’s approach to threat modeling as part of a penetration test. I’m really happy that they’ve given their approach a name. A few years back, we would just talk about “threat modeling” and it got confusing. With that said, Adam here, and I wanted to offer up our perspective. I’ll do that by first comparing and contrasting the SDL and ninja approaches, and then respond to on some Cory’s impressions of the STRIDE-per-Element approach to threat modeling which we’re using in the SDL.

There’s a lot to be said for giving your approach a cool name, and we love cool names too, like “The SDL Threat Modeling Tool.” How cool is that? Ok, ninja is much cooler. It seems from Cory’s post that Matasano’s customers are coming to them for security at the end of their process, rather than at the start. I think we all agree that threat modeling late produces less value. Here at Microsoft, we’ve invested in making it possible for any software engineer to threat model at the start of development. We’ve made enough progress in this that Forrester has said “Many application architects and developers don’t know enough about developing secure applications… Microsoft’s SDL Threat Modeling Tool is a unique new tool that helps developers identify and mitigate security risks to make applications more secure from the get-go.” (“Use Threat Modeling To Develop More-Secure Applications,” March, 2009.)

I do think that we can map between the current SDL approach and the Ninja approach:

For a summary of their process, I looked at the boxed text “Ninja threat modeling at a glance.” I wish Cory had explained the approach a bit more: what’s the difference between an app overview and a data flow? Why are there 2 threat enumeration checklists (assumptions, deadly sins)? I think it might be interesting to combine the two threat enumerations. I also think that the risk management step could be formalized a bit more.

So I’m glad that Matasano has a way to help you if you haven’t threat modeled. Our experience and observations over many, many years has shown that most people don’t want (or haven’t budgeted for) ninjas to drop into their process and slice up their design at the last minute. That’s why we’ve been sharing the SDL optimization model, building out the SDL Pro Network and sharing our approaches. We think that most people want to engineer a good and secure product from the start. We all need to work to make that easier, more predictable, and more effective. I also recognize that many organizations are not building security into their development processes yet. So it’s great to see Matasano think through what a threat model at the end of the dev process should look like, and share that thinking.

I wanted to reply to one thing that Cory said:

“It has spawned not just one, but two, Visio-driven toolsets from Microsoft and countless data-flow diagrams, attack trees, consulting engagements, and perplexed developers. When performed by a skilled and experienced team member, the model can be used to identify architectural weaknesses, guide default application behavior, and outline functional requirements for the product.”

Cory’s right. We have two tools, and it’s confusing. We’ll be making that much clearer soon. Additionally, we’ve presented a lot of information about our many approaches over the years.Today, we have one authoritative site at microsoft.com/sdl which presents the most current guidance. We no longer use attack trees. We’re working hard to speak clearly. Is it working for you? Let us know what’s not clear. Yes, there are a lot of books and what-have-you that can’t be updated, but we aim to publish and maintain guidance on the SDL portal that is authoritative, current, and understandable. Kicking attack trees is sort of like commenting on the security of Win98: we’ve learned a lot since then.

One of the most important things we’ve learned is that we needed to simplify the model, the approach, and the training, and we’ve done all three of those things. Having done those things, we’ve seen non-experts pick up the tool and create good threat models. We’ve heard from partners who are using the tool successfully, and we’ve received great feedback from analysts about efforts. None of which means we’re perfect. We’re still continuing to innovate with the aim of making the process better, and seeking the feedback from anyone who’s downloaded and applied our free tools and guidance. We’ve got some tricks up our sleeve, and while we don’t want to play them too close to the chest, we’re going to continue to innovate, and are glad to see a profusion of ideas for making things better.  Finally, we work to share our experience.

We’ve seen the STRIDE-per-element approach work for non-experts. We suggest you give it a try. But far more important than which approach you try is when you try it. Start early. Take a look at the optimization model. If you want some consulting help, go to one of our Pro Network partners or even to Matasano. If you have a few hours, experiment with both approaches and see which fits. But start early and find a threat modeling approach that helps you deliver more secure software.

Pirates and script kiddies would prefer you just fuzzed.

10/20/2009: Updated with correct CVE - thanks to Matthieu Suiche for pointing this out to me.

Hi, Michael here.

When I wrote the first analysis of why the SDL had missed a security vulnerability, I made a comment that I would continue to write these posts, but only for bugs that interested me. To be honest, all security bugs interest me, but this one really got me to sit up because it’s in new code.

For reference, the security update that fixes this is MS09-050, and the bug is CVE-2009-3103.

What makes the bug of concern is it’s in networking code; thankfully, there are some mitigations available, such as the Windows Firewall, that reduce exposure to attacks.

First, let’s take a look at the vulnerable code. Can you spot the bug?

#define Smb2GetWorkItem( WI ) ((PSMB2_WORK_ITEM)(WI->ProviderWorkItem))

...

typedef struct _SRV_WORK_ITEM

{

...

    //

    // This is the Receive Buffer for the incoming request

    //

    PSRVBUFFER ReceiveBuffer;

    PSRVBUFFER ResponseBuffer;

...

} SRV_WORK_ITEM, *PSRV_WORK_ITEM;

...

NTSTATUS

Smb2ValidateProviderCallback( PSRV_WORK_ITEM WorkItem )

{

    PSMB2_HEADER pHeader = (PSMB2_HEADER)WorkItem->ReceiveBuffer->Buffer;

    PSMB2_WORK_ITEM pWI = Smb2GetWorkItem( WorkItem );

    PSMB2_CONNECTION pC = Smb2GetConnection( WorkItem->Connection );

    NTSTATUS status;

    pWI->ParentWorkItem = WorkItem;

    pWI->AsyncId = RFSTABLE64_INVALID_ITEM;

    WorkItem->ProviderWorkItemCleanupRoutine = Smb2CleanupWorkItem;

...

    if( pHeader->ProtocolId != SMB2_PROTOCOL_ID )

    {

        if( pHeader->ProtocolId == SMB_PROTOCOL_ID &&

            pC->Dialect == 0xFFFF )

        {

            //

            // Handle downlevel multi-negotiate

            //

            pWI->Command = SMB2_0_COMMAND_NEGOTIATE;

            goto process_packet;

        }

        else

        {

            WorkItem->DisconnectConnection = TRUE;

            return STATUS_INVALID_PARAMETER;

        }

    }

    pWI->Command = pHeader->Command;

...

process_packet:

    if( SRVWPP_LOG_MESSAGE( DEBUG_MODULE_SRV2, DEBUG_PERF ) )

    {

        Smb2OutputWorkItemRequest( WorkItem );

    }

    if( ValidateRoutines[pHeader->Command ] == NULL )

    {

        return Smb2ValidateNotImplemented( WorkItem );

    }

    else

    {

        return (ValidateRoutines[pHeader->Command])( WorkItem );

    }

}

If you can’t see the bug, here’s the fix:

    if( SRVWPP_LOG_MESSAGE( DEBUG_MODULE_SRV2, DEBUG_PERF ) )
    {
        Smb2OutputWorkItemRequest( WorkItem );
    }

    if( ValidateRoutines[pWI->Command] == NULL )
    {
        return Smb2ValidateNotImplemented( WorkItem );
    }
    else
    {
        return (ValidateRoutines[pWI->Command])( WorkItem );
    }
}

Look at the two array references to ValidateRoutines[] near the end, the array index to both is the wrong variable: pHeader->Command should be pWI->Command.

So why did the SDL miss this bug?

There is only one current SDL requirement or recommendation that could potentially find this, and that is fuzz testing. In fact we did find it very late in the Windows 7 development process through network fuzzing and that is why post-RC versions of Windows 7 do not have this bug.

Right now there is no static analysis tool I know of that would point out the developer used the wrong variable, and our analysis tools didn’t spot the potential array bounds problem in part because it’s hard to do so with generate a very large quantity of false positives. With that said, we’re looking deeper into the latter challenge now.

The only other method that could find this kind of bug is very slow and painstaking code review. This code was peer-reviewed prior to check-in into Windows Vista; but the bug was missed. Humans are fallible, after all.

Some years ago I created a “How to review code for Security Bugs” class and toward the end I explain that code reviewers need to question all coding logic assumptions when the code deals with untrusted data; I will add a new bullet point: are the correct variables used?

I’ve mentioned this before, but it’s worth mentioning again. I think we’re getting to a stage at Microsoft where the SDL has whittled away most of the ‘low-hanging’ bugs. Of course, I might be proven wrong, but looking at all the bugs over the last year in Windows, the only pattern I can spot is there is no pattern! The majority of the bugs I see in Windows are one-off bugs that can’t be found easily through static analysis or education, which leaves only manual code review, and for some bug classes, fuzz testing. But fuzz testing is hardly perfect, because the malformed data might not hit the vulnerable code path or trigger a failure in the code.

I would say that this is a great argument for software developers spending more time on defenses against unknown vulnerabilities, as well as trying to prevent or remove vulnerabilities. The SDL mantra of “Reduce the number of vulnerabilities and reduce the severity of the bugs you miss” is very consistent with this belief.

- Michael

luv u kim x