Using Fortify Solutions for a Microsoft SDL Implementation

Jeremy Dallman here. I wanted to let you know about a great paper from Fortify, one of our newest SDL Pro Network Tools members. The paper highlights the Microsoft SDL approach to secure software development and shows how Fortify’s security solutions can help you implement the SDL and create/deploy more secure software.

At RSA 2010 last week, Fortify published a paper titled Optimizing the Microsoft SDL for Secure Development: Fortify Solutions to strengthen and streamline a Microsoft SDL Implementation. This paper does an excellent job of explaining the challenges of developing secure software, detailing the Microsoft SDL approach to secure software development, and mapping Fortify’s solution offerings to each SDL Practice based on the Simplified Implementation of the SDL.

If you are looking for tools to support your implementation of the SDL, I would encourage you to read through Fortify’s paper to see if their solutions can help you.

Telling their SDL stories: IE8 and Office 2007

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.

Announcing Elevation of Privilege: The Threat Modeling Game

What

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.”

Why

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.

How

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.

When

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

Who

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.

Acknowledgements

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.

SDL and the New End to End Trust Site

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

SDL at RSA

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

AND-202: Microsoft SDL Tools: Automating the Security Development Lifecycle

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.)

EXP-202: Picking a Yardstick to Measure Your Software Security Practices

Wednesday, March 3, 9:10 AM

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

HOT-203: Responsible Disclosure: It’s Their Fault!

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.)

AND-304: Threat Modeling: Lessons Learned & Practical Ways to Improve Your Software

Thursday, March 4, 1:00 PM

Adam Shostack and Danny Dhillon (EMC)

Casaba Releases Watcher 1.3.0 with Added SDL Integration

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).

The SDL and the CWE/SANS Top 25 Most Dangerous Programming Errors 2010

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.

VC++ 2010 and memcpy

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

Three New Announcements

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

How to open a parachute during free-fall: Introducing Quick Security References (QSRs)

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.

HeapSetInformation in Visual C++ 2010 beta 2

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

Introducing the InfoSec Assessment & Protection Suite

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

Announcing SDL for Agile Development Methodologies

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.

SDL at TechEd Europe and Platforma

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!

SIR Volume 7 Released

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.