May, 2009

Wanted to drop a quick note to talk about the SDL 4.1 process guidance that we released on May 19th...

While most of the attention and chatter from the development community has been focused on the announcement of the SDL Process Template for Visual Studio Team System and the addition of SAIC and SANS to the SDL Pro Network, the SDL 4.1 documentation release has a few important points to touch on.

First, it demonstrates our ongoing commitment to process transparency - we released the SDL 3.2 process documentation for the first time at RSA 2008 along with a promise to update it on a regular basis.  So here we are, just over a year later, with the latest changes.  Many people in the IT and developer communities are curious about the individual requirements and recommendations that make up the SDL.  Additionally, there has been a lot of interest on how a process like the SDL is applied at an organization the size of Microsoft - we think the new documentation does a good job at answering both these queries.

Second, there is a myth that I often hear repeated that the SDL "only works for Microsoft" or "is only suitable for development on Microsoft platforms."  Honestly, that's a bit of a shocker for me.  Security training, threat modeling, static code analysis, fuzz testing and other security actions performed as part of the SDL are *not* proprietary to Microsoft or the SDL.  While the 4.1 documentation *is* focused on how the SDL is applied at MS, it doesn't require a Nobel Laureate to see that many of the things that make up the SDL are simply good security practices.  So, I'd encourage people to take a look at the requirements and recommendations that are listed in the document and form your own conclusions. Fight the FUD.

Finally, we've illustrated the changes that one would expect of a living process - the expected fine tuning of our SDL requirements and recommendations to reflect changes in the security space.  In addition, we have included information on how the SDL is applied to online services (i.e. Microsoft publicly available websites) and how we use the SDL to build line-of-business (LOB) applications for internal use at Microsoft.  The changes specific to online services and LOB are called out in the text for easier review.

So that's it - a quick snapshot of the 4.1 process.  As before, it's available both as web guidance on the MSDN Security Developer Center and as a Word document from the MSDN Download Center.

As always, comments are welcome!

Hello all - Dave here...

We have been pleased thus far with the reaction from the developer community to our release of the SDL Template for Visual Studio Team System. However, some folks in the developer community have inquired about applying the template to agile methods. 

The SDL template is a software manifestation of the Microsoft SDL requirements and recommendations as we apply them to typical Microsoft “packaged product” development projects.  Most of those projects are using native code and following a spiral development methodology.

Agile methods are also used at Microsoft, but it’s critically important that we fully examine how the SDL can be integrated into agile methods to ensure that we get it right.  We’ve already learned that simply taking the SDL for spiral methodology and applying the entire SDL at each agile sprint is not the right answer. We're working to bring the benefits of the Microsoft SDL to users of the Visual Studio Team System MSF for Agile template in the near future.

When I joined the SDL team last fall, the SDL Pro Network had launched as a one-year pilot program.  Upon returning from maternity leave, I took over management of the SDL Pro Network.  I have been working on formalizing the program in order to bring it from pilot phase into a full blown partner program, to launch after November 2009.  I have also been working on bringing new consulting services and training members into the fold, even during this pilot phase of the program.

On May 19, the SANS Institute, one of the most trusted and largest sources for information security training, certification & research in the world, and SAIC, a company of over 45,000 employees worldwide with expertise in national security, energy and the environment, critical infrastructure and health, were also added to the SDL Pro Network in an effort to further broaden the SDL’s reach.

In joining forces with these two new SDL Pro Network members, Microsoft’s SDL team is bringing more options for world-renowned security training and consulting services to new developers around the world.

Please join me in welcoming SANS and SAIC into the SDL Pro Network.

-Katie Moussouris, Senior Security Strategist, SDL

Hi everyone! Jeremy Dallman here. I would like to announce a new and easier way to integrate the SDL into your development lifecycle.

In the year since we released the Microsoft SDL Process Guidance documentation, companies interested in adopting the SDL have often asked us “where do I start”? In the past year, we’ve provided the SDL Optimization Model, The SDL Threat Modeling Tool, and the SDL Pro Network as great options to get you started. Quite often, the follow-up comment has been “I just need a way to practically apply the SDL in my development lifecycle… can’t you just put it into Visual Studio?” In order to successfully integrate security into their development process, the people who own a security initiative realize that they need to introduce secure development practices and the SDL with minimal impact on their existing development frameworks and as part of the familiar environment.

Today we are making available the Microsoft SDL Process Template.

The SDL Process Template is a free downloadable template for Visual Studio Team System that integrates the SDL directly into a customer’s software development environment. Because it integrates with the team and process features of Team System, you do need a Team Foundation Server to manage your work. This is our first comprehensive offering that addresses all phases of the SDL from Requirements through Release.

By taking advantage of the rich functionality in Visual Studio Team System and Team Foundation Server, we are now able to offer an SDL solution that reduces the barrier to entry for SDL adoption, provides auditing for satisfying the security requirements, and demonstrates security return on investment. The SDL Template is intended to provide the foundational components of the SDL for every phase of your development project.

How to check it out for yourself

We hope you will take the time to download the SDL Process Template and consider using it to integrate security and the SDL into your team project. If you do not currently use Visual Studio Team System, but would like to evaluate the SDL Process Template, evaluation versions in both VPC and Hyper-V environments are available for download. You can simply upload the SDL Process Template into that virtual environment and check it out for yourself.

A quick walk-through

Here is a quick preview of the basic functionality the SDL Process Template offers:

Process Guidance: Integrated SDL Overview, SDL documents, and How to customize

After installation completes and a new Team Project is created, the first page that appears is the Process Guidance page. This page provides everyone on the project with:

• A brief overview of the SDL
• Five steps for Getting Started on an SDL project
• Details on customizing the template and extending it for third party security tools

Below: The SDL Process Guidance “front page”

SharePoint: SDL Document Library and Project dashboard

Since SharePoint is included with Visual Studio Team System, The basic SharePoint site provides a single location for all project participants to get a common view of project status, related announcements and dates, and access the large document library.

Below: the SharePoint site serves as a project dashboard

SDL Requirements: Pre-loaded SDL work items ready to triage

By selecting the “All SDL Tasks” query the team can find the pre-populated list of all SDL Requirements and Recommendations. No more trying to figure out where to start when it comes to defining security requirements! The SDL Template also provides a custom work item that allows you to create and add your own unique requirements or recommendations.

Below: all SDL Requirements and Recommendations pre-loaded and ready to triage

SDL Check-in Policies: Enforce SDL policy with existing VS features

Developers care about security, but they want it to be intuitive. We have provided check-in policies that will ensure every set of code is taking advantage of the SDL required compiler/linker flags and Code Analysis features already in Visual Studio. This will eliminate entire classes of security weaknesses from your code. A Security Code Review work item is also included to support enforcement of security code reviews for security-sensitive code.

Below: Setting Check-in policies

Below: Check-in policies in action

Customized Security bugs: Tag and track Cause, Severity, and STRIDE Effect

Testers want to be able to emphasize the importance of a security bug and properly communicate the impact to their product. The default “bug” work item now has customized security fields so you can identify security cause, severity, and security effect (using STRIDE), and mark a bug as Blocking or Not Blocking. This feature allows you to track and search for security-specific bugs.

Below: Identifying a bug as a security issue

Final Security Review: Track and audit the state of all active security bugs, completion of SDL tasks, and effectiveness of security tools

The entire team and especially senior management want an easy-to-read document that summarizes the security work completed. The Final Security Review Report and Security Bugs Report provide an auditable set of evidence that details security work completed as well as deferred tasks.

• Page One: status of all bugs marked as Security Bugs
• Page Two: completion status for the SDL Requirements and Recommendations
• Page Three: security bugs found by all tools integrated with the template

Below: Page 1 of the Final Security Review

Below: Page 2 of the Final Security Review

Threat modeling: Seamless integration with the SDL Threat Modeling Tool

Threat modeling is a critical part of your early design process. It informs architects of the attack surface, provides insight for the developers to write more secure code, and enables testers to more effectively build test cases to verify mitigations. The SDL Process Template includes a script that will convert SDL Threat Modeling tool issues into security bugs and hook into the reporting piece of the template.

~~~~~~~

We hope you will take a look at the SDL Process Template and consider using it to ease adoption of the SDL in your development teams. As we move forward with more SDL offerings, our plan is to integrate any tools and guidance into the SDL Process Template – making it a dynamic foundation for an end-to-end SDL solution.

We look forward to your feedback as you download and begin using the SDL Process Template to make your code more secure.

Over the last few years I have written a number of articles, papers and books describing some of the dangers of using various buffer-manipulating C runtime functions. Well-known examples of bad function calls include strcpy(), strcat(), strncpy(), strncat(), gets() and their foul brethren. The SDL bans these and many other functions with dubious security history. But, when it comes to banning functions, we must tread a very fine line because we can’t just ban something because it looks odd, or that gut instinct tells us it’s bad, we can only ban functionality that has been demonstrated to cause security vulnerabilities and only if there is a viable alternative.

Because we have seen many security vulnerabilities in products from Microsoft and many others, including ISVs and competitors, and because we have a viable replacement, I am “proud” to announce that we intend to add memcpy() will to the SDL C and C++ banned API list later this year as we make further revisions to the SDL. Right now, memcpy() is on the SDL Recommended banned list, but will soon be added to the SDL banned API requirement list now that we have more feedback from Microsoft product groups.

The following security updates all have one thing in common: memcpy().

·         MS03-030 (DirectX)

·         MS03-043 (Messenger Service)

·         MS03-044 (Help and Support)

·         MS05-039 (PnP)

·         MS04-011 (PCT)

·         MS05-030 (Outlook Express)

·         CVE-2007-3999 (MIT Kerberos v5)

·         CVE-2007-4000 (MIT Kerberos v5)

·         …many more!

It’s not just memcpy() that we’re banning; we will also ban CopyMemory() and RtlCopyMemory(), and the replacement function is memcpy_s().

Banning memcpy() in your code

You too should start banning memcpy() in your new code, here’s what you can do right now:

Add the following line of code to a common header file:

#pragma deprecated (memcpy, RtlCopyMemory, CopyMemory)

Every time the compiler sees an instance of the banned functions, you’ll get the following warning:

warning C4995: 'memcpy': name was marked as #pragma deprecated

In Visual C++, you can also add this early in a common header:

#define _CRT_SECURE_WARNINGS_MEMORY

And you will get warnings like:

warning C4996: 'memcpy': This function or variable may be unsafe. Consider using memcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details. c:\program files\microsoft visual studio 9.0\vc\include\wchar.h(1201) : see declaration of 'memcpy'

You can deprecate these functions if you’re using gcc by poisoning them:

#pragma GCC poison memcpy RtlCopyMemory CopyMemory

Fixing memcpy() calls

Thankfully, it’s pretty simple to migrate a call to memcpy() to a safer call to memcpy_s(); the big difference is memcpy_s() takes one extra parameter: the size of the destination buffer. If nothing else, memcpy_s makes you think about the size of the target buffer.

The SAL-decorated function signature in VC++ 2008 is:

errno_t __cdecl
    memcpy_s(
        _Out_opt_bytecap_post_bytecount_(_DstSize, _MaxCount)
                void * _Dst,
        _In_ rsize_t _DstSize,
        _In_opt_bytecount_(_MaxCount) const void * _Src,
        _In_ rsize_t _MaxCount
    );

All you need to do is update calls to memcpy() by adding the size of the destination buffer. So calls like this:

char dst[32];

memcpy(dst,src,len);

becomes

char dst[32];

memcpy_s(dst,sizeof(dst), src,len);

Of course, you can easily make a call to memcpy_s() insecure by getting the buffer sizes wrong. The following code is no better than memcpy():

memcpy_s(dst,len, src,len);

You’ve been warned!

I wonder when Larry, Steve and Linus will start banning strcpy() in their products?

Hi, Bryan here. Regular readers of this blog know that I’m more likely to write technical posts about new defense tactics than I am to pontificate on the state of the security industry. However, while I was at the RSA Conference last month, I overheard a concerning misconception about the SDL that I’d like to address.

During a panel discussion on static- and source-analysis techniques, the panelists – Chris Wysopal of Veracode, Jerry Archer of Intuit, Mary Ann Davidson of Oracle, and Brian Chess of Fortify – had strayed somewhat from the original topic and into a discussion of security processes. At this point, several of them stated their belief that the SDL is only useful for large organizations running Windows, and that it wouldn’t work well for “5-person shops writing PHP.”

Now, I don’t believe that the only way to create secure software is to follow the SDL exactly the way we follow it at Microsoft. Not everyone building software is ready to commit as much time and energy to security as we do. For that matter, not everyone even needs to commit as much time and energy to security as we do! But everyone building software should be doing something to make that software more secure, which is exactly why we developed the SDL Optimization Model.

It’s true that if you have 1000 or more developers, you’ll probably want to eventually work your way up to the Dynamic level of the Optimization Model (where we see ourselves), but the 5-person PHP shop could greatly benefit from implementing the SDL at the Standardized level. At the Standardized level, you perform high-ROI security activities such as validating input and encoding output to defend against cross-site scripting attacks, using stored procedures to defend against SQL injection attacks, and fuzzing your application inputs to find unknown errors. These all sound pretty applicable to a 5-person PHP shop to me!

Ok, that’s definitely enough pontification for me for a while. The next time I post, I promise it’ll be something technical, like a comparison of various managed code static analysis tools or best practices for implementing cryptographic agility in your applications. Talk to you then.

Steve Lipner here,

Steve Bellovin, one of the pioneers of Internet security wrote a blog post about security, open source, and secure development process.  It's worth reading if you're an open source fan, or if you're not. 

My one quibble is that Steve refers to fixing bugs in a way that implies that just fixing bugs improves security.  Our experience is that fixing bugs is not enough - you have to use tools and processes that specifically prevent security bugs from getting into the code in the first place.

But that’s a minor quibble.  I think Steve's post is right on and a great read.