The Security Development Lifecycle

SDL and the XSS Filter

Steve Lipner here.  When the Internet Explorer team posted the announcement about the XSS Filter feature in IE8  I asked some other members of the SDL blog team “why aren’t we talking about the new XSS Filter feature on the SDL blog?”  Bryan and Jeremy said something like “that’s a mitigation that only applies to specific clients and a subset of attacks”.  So we didn’t cross-reference IE’s XSS Filter post on the SDL blog at the time.  Instead, I agreed to write a subsequent post about the relationship of XSS Filter to the SDL and to the ways that our SDL and security science teams think about improving product security.

For those of you who aren’t familiar with XSS Filter, a brief summary is that it is a client-side defense against reflected cross-site scripting (XSS) attacks.  It works by recognizing that reflected XSS attacks inject script into the string that the browser sends to the targeted web server.  If the server doesn’t neuter or strip out the injected script, it gets sent back to the browser and executed in the context of the target web page.  Bad things then happen.  At a high level, XSS Filter remembers the string that the browser sent to the server, and looks at the server’s response to see if any of the script was actually in that string.  If it was, then XSS Filter decides that it got there because it was injected by an XSS attack and blocks the script from executing.  The rest of the web page renders as usual.  This is a vastly oversimplified sketch of XSS Filter – for details, see the post by David Ross, inventor of XSS Filter on the Security Vulnerability Research and Defense blog.

So what does XSS Filter have to do with the SDL?  Well, for almost nine years, since XSS was first discovered at Microsoft, we’ve been trying to figure out effective ways to reduce vulnerability to XSS attacks.  Our focus has been on improving the ways that web page developers code their pages, and we’ve developed a lot of tools and techniques for making web content safer from XSS attacks and for detecting XSS vulnerabilities in live pages.  The SDL requires the use of many of these tools and techniques, and we’re sure we’ve prevented a lot of XSS vulnerabilities from being introduced into Microsoft web pages as a result. 

But while we identify (and the SDL requires) measures that allow developers to avoid classes of vulnerabilities, we also look to identify more sweeping solutions that can either 1) eliminate classes of vulnerabilities, 2) reduce their severity, or 3) reduce the likelihood of attacks being successful.  The process usually starts from deep understanding of a class of vulnerabilities and attacks, and then we broaden defenses from there.  In the case of XSS Filter, David’s years of work researching XSS led him to come up with an approach that blocks many of the most common vulnerabilities to reflected attacks found on the web today.  The solution is compatible with existing web pages (doesn’t “break the web”) and thus we were able to enable it by default for users of Internet Explorer 8.  Because it’s a client-side mitigation, it will help protect users from attacks even though the sites they visit may be vulnerable to XSS. 

Our work on buffer overrun defenses follows a somewhat similar pattern – we started by prescribing coding techniques, banning the use of some APIs, and building tools that detect coding constructs that look like buffer overruns.  As we gained a deeper understanding of how buffer overruns can be exploited, we enhanced the /GS compiler flag and added ASLR in a quest to cause classes of exploits to fail even if a buffer overrun remains.  We’re not yet close to eliminating the SDL requirements for use of tools and coding techniques, but the SDL also requires the use of the mitigations to reduce the severity of vulnerabilities that slip past.  Will we ever get to the point where the mitigating technologies are so strong that we can relax the coding requirements?  Maybe not, but we will continue to introduce technologies that reduce the chances of a successful attack.

Similarly, in the case of XSS, even after IE8 ships, the SDL will continue to require the use of safe web site coding practices and tools such as the Anti-XSS library both to protect users of browsers other than IE8 and to provide protection in recognition of the fact that XSS Filter is a mitigation or defense in depth rather than a complete solution.  But we’ll also be keeping our eyes open (and doing active research) in the quest for an even more effective defense – whether client or server side – that eliminates XSS for good.

This post is a little far afield from the normal content of the SDL blog, but I thought it was important to provide a picture of the role of security science and security research in defining SDL requirements and in making major improvements in software security.  You can read more about our work in security science in the Security Vulnerability Research and Defense blog.

Security is bigger than finding and fixing bugs

I’ve been catching up on various security-related articles that I’ve been meaning to read, and the following article was on the list http://www.itnews.com.au/News/73635,google-shares-its-security-secrets.aspx about Google’s “security secrets.”
 
Quoting from the article:

“In order to keep its products safe, Google has adopted a philosophy of 'security as a cultural value'. The programme includes mandatory security training for developers, a set of in-house security libraries, and code reviews both by Google developers and outside security researchers."

I think it is great that Google has a security program they are willing to talk about and I could not agree more with the ‘security as a cultural value’ philosophy. But isn’t there something really fundamental missing here? Design? There is a lot more to software engineering other than coding and testing.
 
The SDL has a very large set of implementation-related requirements, but there are many design-related requirements also.

Computer security experts have known since the early 1970s that you have to get the design right; and our experiences with the SDL over the last 5 years have taught us that you need to consider security and privacy (but remember, you have to ship too!) very early in the design phase and have a consistent end-to-end process if you truly hope to reduce vulnerabilities and create more secure software. This is how the SDL is helping to create ‘security as a cultural value’ at Microsoft.

We’ve seen a general trend downward in security vulnerabilities in Microsoft products, and the IBM X-Force 2008 mid-year report backs the assertion that we’re making progress; according to the report Microsoft’s share of total vulnerabilities decreased from 3.7% in 2007 (1st place) to 2.5% (that’s 2.5% for all Microsoft products; a more appropriate comparison might be Windows vs Linux vs Mac OSX, or SQL Server vs Oracle vs DB2) in the first 6 months of 2008 (3rd place.) This is an encouraging signal that the SDL is working on a large scale… of course, it might also show that vulnerability researchers are moving to easier targets, which, to me shows the SDL is working too.
 
What do you think?

What do you want to know about SDL threat modeling?

Adam Shostack here. I'm working on a paper about "Experiences Threat Modeling at Microsoft" for an academic workshop on security modeling. I have some content that I think is pretty good, but I realize that I don't know all the questions that readers might have.

So, what questions should I try to answer in such a paper? What would you like to know about? No promises that I'll have anything intelligent to say, but I'd love to know the questions you're asking. So please. Ask away!

Improve Security with "A Layer of Hurt"

I got a lot of interesting comments from my TechEd 2008 presentation entitled, "How To Review Your Code And Test For Security Bugs," but the most comments and questions were reserved for fuzz testing; I was blown away by the number of people who thought fuzz testing was hard, or that you only left fuzz testing to ‘leet hackers.

During the presentation I mentioned in some depth how to perform fuzz testing, and what parts of an application should be fuzz testing targets. I also introduced an idea (that's not new) to help people who have never performed fuzz testing begin fuzz testing with very little cost and friction. The idea is to add a small layer of code to an application to automatically mutate untrusted data as it comes into an application; I called that code layer "a layer of hurt."

Before I continue, I want to point out that fuzzing is an SDL requirement, but the idea in this blog post is not an SDL requirement, it's just another way to help meet SDL fuzzing requirements.

Adding a layer of hurt, as shown in the picture below, is pretty simple as it involves adding code to an application to tweak data as it comes into an application. You can work out where to place the fuzzing code by looking at your threat models to see where data crosses trust boundaries. You could also simply grep the code looking for APIs that read data, for example:

• Read from files: fread, ReadFile
• Reading from sockets: recv, recvfrom
• For .NET code, any stream.Read

You get the picture.

The fuzzing code should appear right after the API that reads that data.

For example, C or C++ code that reads from a UDP socket and then fuzzes the data before it's consumed by the rest of the application might look like this:

Or, in C#, code that reads from an untrusted file:

In both code examples, Fuzz() mutates the incoming data. In the C++ case, the fuzzing code looks like this:

The sample C# and C++ fuzzing code is available as a ZIP file at the end of this post.

This code is an example of dumb-fuzzing, which is fuzzing with little or no regard for the data structure being manipulated. If you've never performed any kind of fuzz testing in the past, then you will probably find bugs with this simple fuzzing technique. Once you have weeded out the low-hanging bugs, you may need to turn your attention to smarter fuzzers. For example, in theory, this code would find few if any bugs in a PNG parser, because PNG files have a built in check-sum, so if you fuzz a PNG file, you'd have to recalculate the checksum to get decent code coverage.

When I showed this code during my presentation, I urged people to add it to their applications today if they currently don't do fuzz testing, and simply run their applications through their normal testing processes. Within three days of my presentation I received emails from people saying they had found bugs. I have no doubt others did too.

One of the comments I made during the session was,"If you can't spend the time on great fuzzing, fuzz anyway" and adding a "layer of hurt" is a reasonable start.

Please feel free to sound off if you have ideas to help improve the code and let us know what you think, either through email or comments to this post.

Wrapping up "Walking" with the SDL

Jeremy Dallman here. Before we move on with our regularly-scheduled programming here at the SDL blog, I wanted to pull all of the “Walking with the SDL” blog posts into a single document to put it all together in another format. You can find that document here.

"Walking" with the SDL - Part 4

Jeremy Dallman here with the final piece of my multi-part series on “Walking” with the Security Development Lifecycle (SDL) [Part 1, Part 2, Part 3]. So far I have discussed getting management approval, expanding security training, formalizing security requirements and effective ways to reuse your threat model or attack surface review data.  In this post, I will wrap up with a look into setting up final security reviews and managing post-release documentation.

Formalize your Final Security Review (FSR) Process

A Final Security Review is your final security audit to ensure your software is secure enough to deliver to your customers. I will assume the idea of an FSR is a new concept and try to provide some FAQ-style detail on this topic.

Who is the FSR team? An FSR Team usually consists of a non-product-team security expert (for impartial perspective), a security representative from the product team, and individual representatives from the separate disciplines. However, that size team may not scale to your company. If that is the case, at a minimum, you should have an impartial “outsider” separate from the product team who understands the security requirements as well as the measurements used to validate them. This person along with a project manager can probably perform the bulk of the FSR with development or test leadership providing input as needed.

What is needed to do an FSR? All threat models should be revised to reflect the final product, the code should be complete, and all security-related testing should be completed and documented. In addition, everyone involved in the FSR should have full access to the bug database to review status or exceptions to security bugs.

What does an FSR team do?

1. Re-review threat models to verify all mitigations identified in those exercises were fixed or went through an exception process.
2. Verify that all security issues uncovered during the development process were fixed or granted exceptions by the appropriate people. This is where you verify whether the state of your security bugs meets the “bug bar” requirements you have defined for your products.
3. If there is any output from security tools that you have used to define requirements, the FSR team would verify that the results of the tools meet the security requirements.
4. Review all exceptions to verify that they approve these decisions in the context of the final product. If they identify risks associated with the exceptions, they should communicate those to the business ownership for a final decision before signoff. Any decisions related to known risks should also be reflected in the response plan for future reference.
5. Finally, there should be a final signoff exercise where all security people and project leadership jointly approve the decision of the Final Security Review.

How long does an FSR take? If done correctly, the FSR will likely take some time. You should schedule this review well in advance of your release date to give your FSR team some time to complete the review, push issues back to the product team, and respond to any serious issues that may be discovered.

Final security reviews are a crucial piece to your Security Development Lifecycle. It would be easy to encourage secure development in your team, but as you expand your process to include formal security requirements and begin enforcing those requirements, it is necessary to perform a final audit of your product before it is released. Your customers will thank you for taking the time to add this layer of quality control to your operations and you will likely save yourself some security embarrassment down the road by adding a FSR to the end of your product cycle.

Document security work for reference

After the FSR is complete, there is still work for the security team. The final FSR documentation should be archived along with the symbols and code that represents the finished project. This becomes the time-stamped “snapshot” of your product. Your post-release process should include archiving the following documents in an easily accessible location:

·         All final threat models for future reference.

·         Bug bars, tool settings, and test results related to your project and the supporting tools used to validate. These will be referenced and reused in the next product cycle.

·         All documented security bug exceptions. These need to be rolled into your next product cycle to ensure they are addressed.

·         The final symbols that reflect the product shipped should be archived.

·         The Final Security Report and project signoffs to validate your security audit activity

·         Your Incident Response Plan (discussed in the Crawl post). This must be accessible for quick reference if security incidents occur.

Archiving this evidence serves a few critical purposes: it shows historic evidence of the work you did to ensure a secure product, allows you to postmortem the results and improves your process each time, and reduces the amount of time your team will have to spend next time around by making the existing resources reusable.

In closing…

I hope this long series has provided some practical steps you can take to move your Security Development Lifecycle practices to the next level. At Microsoft, creating a lifecycle to match security development practices has faced a fair share of challenges. However, the investment and time has resulted in more secure products. We’ll continue refining how we execute the Security Development Lifecycle and hope to share those ideas with you along the way. We welcome your thoughts and questions as you start “Walking” with the SDL in your own company and look forward to seeing more secure products and customers as a result.

I’ve created a unique tag on the SDL Blog to cover this series. To get a full list of the related posts, click the “Crawl Walk Run” tag on the left column. I’ll post a Word document version of the full “Walk” series sometime in the next week.

"Walking" with the SDL - Part 3

Jeremy Dallman here. This is Part Three in my multi-part series on “Walking” with the Security Development Lifecycle (SDL) [Part 1, Part 2]. So far I have discussed getting management approval and expanding security training. In this post I will discuss formalizing requirements and effective ways to reuse your threat model and attack surface review data. I’ll wrap up with a look into final security reviews and managing post-release documentation.

Formalize Requirements for long-term use

Now that you are making security development a lifecycle, it is time to lock down and formalize your security requirements. At this point, you need to take what you’ve learned and begin translating your security principles into something that can apply to multiple releases and multiple levels of your development process.

At a product level, you need to use the security rules created in prior projects to define long-term security requirements. Those requirements will become your core security policies.  Then, at the version level, you should create security requirements that are version-specific and are defined by the security objectives and features you want to address in that version.

Both of these sets of requirements can be formalized in a way that makes them easier to transfer across future product cycles and to modify based on the unique features or security issues of each version.  Making these a staple of your development lifecycle will also ease adoption of these requirements as team become familiar with them over multiple releases.

I would like to touch on one topic before moving on – enforcing requirements. As your team grows and your SDL matures, there is an inherent complexity that comes with managing and enforcing your requirements. In our experience, we’ve found that it is critical to identify a security advisor. Up until now, your company has probably had someone championing security and best practices – either as a formal role or simply as a informal advocate. However, making it a feature of your lifecycle requires dedicated effort to enforce and sustain the requirements as well as monitoring the security ecosystem for changes that may add requirements to your process. The security advisor(s) are the people who will help guide the creation of the security requirements both broadly and for each product cycle; for a smaller team, this may be a single individual. For a larger organization, a team of people may be needed. The security advisor should also evaluate your security policy and apply changes where needed, ensure the product bug database is tracking security issues that can be reviewed later (I’ll get to the Final Security Review in our next post), and guide the definition and enforcement of a security “bug bar”.

Security requirements serve as the backbone of your SDL. The amount of effort you put in defining and enforcing requirements, and keeping them up to date with the current threat landscape will have a direct return on investment in the security and privacy of the product you create. Be careful to document and clearly communicate your requirements to your team, and use them as evidence when talking to your customers about how you ensure the security and privacy of your product.

Reference & Reuse Threat Modeling results & Attack Surface Reviews

Your developers and testers should have access to and be familiar with the attack surface analysis or threat model documents you have created. These documents are invaluable reference tools. Use them to perform evaluate your security from multiple angles:

·         Think about component-level architecture

·         List common pitfalls in writing code, or begin defining and building test cases.

·         Code reviewers can reference threat models and attack surface documents to verify specific attacks were addressed in the code.

·         Architects can use them to identify new areas of potential attack surface based on how new code is written or interacts with existing code.

·         Project leadership can reference threat models or attack surface documents to ensure the completed project meets all security goals.

Building a “live” library of threat models that is accessible by everyone and is designed to be easily maintained or updated is a big undertaking. Based on experience, I would strongly encourage doing this early in the evolution of your security lifecycle to avoid losing valuable data and to prevent the sheer volume of data from becoming unusable. I have heard of some companies using wiki technology as their library for threat modeling while others may use searchable documents, spreadsheets, or websites to store/sort/share the information. Whatever method you use, it is important to anticipate the accumulation of a large set of information that should be easily used and shared across the organization.

I would like to do a deeper dive on the importance of security code reviews as part of your “walk” evolution. Security code reviews focus on identifying insecure coding techniques and vulnerabilities that could lead to security issues. The goal of a review is to identify as many potential security vulnerabilities as possible before the code is deployed. The cost and effort of fixing security flaws at development time is far less than fixing them later in the product deployment cycle [from Improving Web Application Security]. You should create a process where top security developers actively review code within the context of known threats prior to deploying your code. Leveraging the existing documentation about feature design is a vital reference piece to make those security reviews successful.

Later this week, I’ll close the series with a look at final security reviews (FSRs) and how to document your work for post-release and next-release reference.

In the meantime, we’d like to hear from you:

?        How do you express your security requirements? Do you use a checklist, a whitepaper, or something else?

?        What challenges have you faced in enforcing requirements across your teams?

?        How have you implemented threat models or attack surface reviews?

“Walking” with the SDL – Part 2

Jeremy Dallman here with Part Two in my series on “Walking” with the SDL. In Part One, I provided a snapshot of “Crawling” and discussed getting management approval. In Part Two, I will cover a couple more “Walk” components: expanding security training and formalizing requirements.

This blog gives us a place to talk about our experiences from using the SDL here at Microsoft and hopefully provide useful information that will help you implement it more effectively at your company.  So, I would encourage you to use the Comments section at the bottom of each post to ask questions, give us feedback, or request other topics for us to cover.

Some quick definitions before we dive in. I’ve been using the imagery of learning to “crawl, walk and run” as a way to provide some basic starting points that would move your organization toward implementing the Security Development Lifecycle (SDL).  “Walking” is the point where your security development practices become a lifecycle – a repeatable, reusable process that makes security a part of your development culture. To relate the analogy to SDL a bit more closely, think of crawling as the “SD” in SDL. For this post, we’ll continue to talk about walking – or adding the “L” in SDL.

Let’s jump into another component for adopting the Microsoft SDL to expand your own Security Development Lifecycle.

Expand Security Training

Once you have management approval, it is necessary to gain grassroots acceptance of the changes – at the developer, QA/test, and PM levels. If you have been “crawling”, you have probably already implemented some sort of discipline-specific training around things like threat modeling, using compiler defenses, and fuzz testing. Now that you are building a lifecycle, your goal for security training should expand. Security training should be about creating an environment where writing secure software is everyone’s mission. While security training should be undertaken with the goal of understanding security issues and how to address them, good training (and instructors) will also explain why solving security problems is in their best interests and create an environment where they know voicing security concerns is encouraged.

Training has been one of the earliest and most important elements of the SDL at Microsoft. From our experience, we learned that the most effective approach is to divide your training into two tracks: general security principles and role-specific security practices. Before I jump into the details, I want to encourage you to also read Shawn Hernan’s very good post about SDL training that highlights some of the ways to make security training effective.

The general security principles should explain why security is important, how you define security requirements, the process you will use for writing and validating secure code, and how security relates to each phase of the lifecycle or unique roles contributing to the development process. A key factor for building a development lifecycle is educating your individual contributors on the value of investing in security. Of course changing culture takes time, but using the opportunity of structured training to explain your principles will be one of your most effective platforms for influencing change.

At this point in your organizational maturity, you are also beginning to expand your security thinking by focusing on each role in the development process. Discipline-specific security training is where you dig into the details of implementing a Security Development Lifecycle.

·         The developer needs to understand the practical details of how to write code securely, how to set compiler flags, what a security code review means, how to avoid using banned APIs, and what tools are available for them to perform security analysis before checking in their code.

·         The QA/tester needs to know how to set security rules in test tools, how to perform penetration testing, and what the security quality criteria is for your product, or how to file a security bug.

·         The PM needs to understand how to define measurable goals or how security policies can be factored into feature design.

·         The business decision maker of your organization should understand how to track security metrics alongside other product measurements or how security policy plays a critical role in the overall quality and value of your product.

·         Finally, it is critical for the employees occupying all job roles to understand the value of threat modeling – both as a tool for understanding threats early in the design phase and throughout the development process as a key barometer to the security pulse of your product.

Discipline-specific training will be the place to address these issues for your organization. In case you were wondering, all job roles should be required to attend both types of security training before working on your product.

Our new SDL website [http://www.microsoft.com/sdl] will be a very good place to watch for future training materials. The SDL Training and Resources page has some useful material up now and more will be coming in the future.

That’s Part Two. In Part Three, I will discuss the important “walk” components of formalizing security requirements and reusing threat models and attack surface reviews. Then we will close with the discussions on conducting final security reviews, and managing post-release documentation.

I’d like to hear if anyone is using the concept of “crawling” and “walking” to implement SDL in your company.

?        Do you provide security training to your employees today?

?        Do these additional training topics make sense in your organization?

?        What would you add to this that is unique to your application or company?

"Walking" with the SDL - Part 1

Jeremy Dallman here. Back in March I wrote a post about “Crawling” Toward SDL. I used the imagery of learning to “crawl, walk and run” as a way to provide some basic starting points that would move your organization toward implementing a version of Microsoft’s Security Development Lifecycle (SDL).

In this series I am going to talk about “Walking” with the SDL. Walking is the point where your security development practices become a lifecycle – a repeatable, mostly reusable process that makes security a part of your development culture. To relate the analogy to SDL a bit more closely, think of crawling as the “SD” in SDL. For this post, we’ll talk about walking – or adding the “L” in SDL.

I will be covering quite a bit on this topic, so I intend to split it up in to a multi-part series over a few days. I’ll condense it all into one big doc at the end. In Part One, I will review “crawling” and the foundation you need to have in place as well as discuss getting management approval. In Part Two we’ll cover the topic of expanding your security training. In the additional posts, we’ll discuss formalizing requirements, reusing threat modeling and attack surface review data, the importance of final security reviews, and managing post-release documentation. All of these are components to “walking” with the SDL.

Before I jump into detailing what you can do to “walk” with the SDL, let’s look back at a snapshot of what you should already have in place from learning to “crawl.” At a high level, crawling involved three components. Each of these components requires specific activities or tools that your team must implement to begin developing secure code:

1.       Detailed awareness of your architecture and its attack surface.

a.       Threat Modeling

2.       Tools that will perform security analysis on your application.

a.       Strengthen compiler defenses

b.      Use code analysis or static analysis tools such as PREfast, FxCop, AppVerif

c.       Build a strong fuzz testing capability

3.       Results that show how the analysis resulted in improved security

a.       Response planning and response process in place

b.      Use bugs to gather evidence and show that your work improved security

Think of these pieces as the “gross motor skills” you need to start walking. You should already be using these components and have reached a conscious decision to start building a lifecycle around your secure development practices. As you start figuring out how to “walk”, I want to point out that each of the concepts I discuss in this post is a critical component of the Microsoft Security Development Lifecycle. Adopting the SDL in your company involves a combination of integrating the existing SDL principles and the creating of unique requirements and components specific to your environment to build your own Security Development Lifecycle.

With that in place, let’s start talking about what it means to “Walk with SDL.”

Obtain Management Approval/Endorsement

Creating a Security Development Lifecycle will cost time and money. In addition, it will likely require some process changes. In most organizations, this change will not happen unless you obtain the management approval and endorsement necessary to compel the organization to act.

The key to successfully pitching SDL to your management can be found in the data you have been accumulating during the “crawl” phase. As you may recall from my crawling post, the simplest way to create evidence that clearly illustrates improved application security is to “mine” the data from your bug database. Connecting those bugs to known security vulnerabilities or to what would have been bad security issues that were avoided by fixing them in development is a powerful story. Of course your pitch should include other necessary components like anticipated costs, new software acquisition, possible vendor and consulting contracts and anticipated return on investment.

However, the heart of your argument will be the story you tell. The story is quite simply “If we hadn’t done this basic work in security, here is what we would have missed and how much it would have hurt…” followed by “if we continue to expand our security practices and make them a part of our process, we can better predict measurable security improvements that reduce the likelihood of future risks.”

The new SDL website [http://www.microsoft.com/sdl] provides some valuable reference material on the Business Case for SDL. I would recommend that looking through that information for some good supporting material. In Part Two, I will discuss expanding your security training as another component of “walking” with SDL.

I’d like to hear if anyone is using the concept of “crawling” and “walking” to implement SDL in your company.

?        What unique challenges are you facing as you try to push for SDL adoption?

?        What have you used to successfully communicate the importance of security to your management?

New SDL Website

Hi all, Dave here…

I’m pleased to announce the availability of new resources for the Microsoft Security Development Lifecycle (SDL). 

We have recently launched a dedicated SDL website at www.microsoft.com/sdl. This website will serve as the main online presence for all SDL related communications and resources from Microsoft.

For several years now the SDL has been at the heart of Microsoft’s strategy for making security and privacy an integral part of the software development culture at Microsoft. As a result of the SDL, we have seen significant security improvements across many flagship Microsoft products including Windows, SQL Server and others. These security improvements have been widely recognized by security analysts, researchers and other experts. However, despite the significant improvements and recognition, we believe that our connections to our broad technical audiences (developers and IT Pros) are not equating the SDL to the progress we have made with our technologies and services.

Given that, our goal is to help illustrate SDL processes and tooling in a structured and consistent manner – by providing actionable guidance for the different job roles within a development organization.

We welcome your feedback – on the site, and on other information you’d find useful in evaluating the SDL.

Security Thoughts from TechEd 2008

Hi, this week is a post from Michael Howard and Laura Machado de Wright, who both attended and presented at TechEd 2008 in Orlando the week of June 2^nd.

First up is Laura.

I have been a Security Program Manager for the last 3 years, working as a security advisor for a variety of products across Microsoft and the last seven months as a member of the SDL policy team.

 It's been a few years since I've been to TechEd, and this was my first time attending as a member of the security team. TechEd is now a two week conference, with one week dedicated to developers and  the other to IT professionals.  I think that breaking down the conference into a Developer week and an ITPro week was a good idea, and it allowed us to have good conversations with people who wanted more information about the SDL. I did two main things at TechEd:, I presented on threat modeling, and I spent a lot of time talking to customers at the SDL booth. At the SDL booth, we heard questions ranging from "What does the SDL stand for?" to "Our Web site was hacked; how do I stop it from happening again?" It was encouraging hearing people interested to hear more specifics about how we implement the SDL at Microsoft, and thinking through how they can apply it in their own companies.  My understanding from other TechEd veterans in our booth is that interest in the SDL seemed higher, which is great.

During my Threat Modeling session, , most of the feedback and follow-up questions were similar to the ones in the booth: how to expand the threat modeling processes to their own companies, and how to get started.

My typical response to both questions is to start small and do what makes sense for your organization. At  Microsoft, for example, when we introduce new SDL requirements, we usually start with a few teams so we can refine the requirement and supporting tools before expanding the requirements to a broader group. Similarly, while we have a core set of requirements that all teams have to meet, there are other requirements that are specific to a platform, scenario, or functionality. For example, there are some requirements that make sense for desktop-oriented products, but do not make sense for mobile devices.  You may very likely have to make changes to our policies to make them relevant to your organization, your scenarios, and functionality.

Now over to Michael.

Hi, Michael here.

One of the joys of presenting at TechEd each year is hearing from real people about the issues they face using our products in the real world; rarely are the issues pure philosophical security geekness. This year I gave two talks and one "chalk talk." The talks were "Top Ten Strategies
To Secure Your Code" and "How To Review Your Code
and Test For Security Bugs", and the chalk talk, which was a lot of fun, was simply answering numerous developer questions.

It's interesting to gauge overall security awareness from our customers, and there is no doubt that over the years, the level of security knowledge and maturity has risen. I think it's possible to evaluate overall security maturity by the questions posed. Some years ago, security was never really a topic of discussion other than those that relate to security technologies, such as how to use and manage X.509 certificates. About four years ago the tide really changed and people started asking more questions about "secure" application deployment and management, and developers wanted to learn more about securing their code; especially C and C++ code. Even then there was still a reliance on exterior defenses like firewalls. All too often I would hear people claim that they don't need to focus on securing their apps because a firewall was in the way. Heck, David and I documented this excuse in the original version of Writing Secure Code (Appendix D, "Lame Excuses We've Heard, #6, ‘We're Secure-we use a Firewall'") way back in 2002.

Fast forward to 2008.

Things have obviously changed. I don't know if finally the security message is getting through because many people asked me highly specific questions about securing their apps and how best to use the defenses we offer in Windows Vista and Windows Server 2008.

I still hear the firewall excuse a little, but not too much!

Perhaps the most telling trend I saw this year was a great deal of interest in the SDL. Not cursory, "that looks interesting" interest, but, "how can I implement this in my company" interest. After answering specific questions, I pointed most folks to  Jeremy's "Crawling Toward SDL" post on the subject.

In my opinion, getting to a point where you want to change your development process shows you really understand there's an issue that needs fixing.

SQL Injection Defense Tools

Bryan here. A couple of weeks ago, I posted a blog entry with links to SQL injection defense guidelines. The SDL requires guidance and education for end-users, and tools to verify security settings are highly recommended, as defined in "Stage 5: Implementation Phase: Creating Documentation and Tools for Users that Address Security and Privacy". Today, Microsoft is releasing two new SQL injection defense and detection tools, URLScan 3.0 and Microsoft Source Code Analyzer for SQL Injection (MSCASI). We are also excited to announce the release of HP Scrawlr, a SQL injection detection tool developed by HP Web Security Research Group in conjunction with Microsoft.

Each of these tools works differently and each attacks the SQL injection problem from a different angle, and in combination they complement each other well. MSCASI analyzes classic ASP source code to find potential SQL injection vulnerabilities. It can detect both first- and second-order SQL injection bugs and will point you to the exact line of source code where the error occurs.

However, sometimes you don’t have access to the complete source code of your application; for example, you might use third-party libraries or services in your code. This is where Scrawlr comes in. Scrawlr is a black-box analysis tool that doesn’t require access to source code. You just give Scrawlr the URL of your web application and it crawls and analyzes that application for SQL injection vulnerabilities. One downside is that Scrawlr can’t point you to the exact line of vulnerable code the way that Microsoft Source Code Analyzer for SQL Injection can, but this is why the two tools work so well together. In general, source-code analysis tools and black-box analysis tools often work better in conjunction with each other, but this is definitely a larger topic for another blog post.

Finally, URLScan 3.0 is an update to the existing URLScan IIS request filter tool. URLScan 3.0 blocks HTTP requests that contain suspicious text like SQL keywords. URLScan 3.0 is a good defense-in-depth measure, but it’s important to find and fix vulnerabilities at the source. Never rely solely on URLScan or any type of application firewall as your only defense. (I’ve talked on my blog about some potential dangers of substituting firewalls for secure development practices.)

If you’d like more information, the Security Vulnerability Research and Defense blog has posted a more in-depth analysis of each of these tools. I recommend that you download both of the detection tools and test your applications against them. If either tool reports a vulnerability, I also recommend that you use URLScan 3.0 to block attacks while you fix the problems in the source code.

SDL Threat Modeling: Past, Present and Future

Adam Shostack here.

I wanted to share my slides from the recent Layer One conference [link], where I talked about "SDL Threat Modeling: Past, Present and Future."

There are a few points that I wanted to emphasize. The first is that I'm talking about threat modeling from the perspective of the SDL. We have other threat modeling processes here at Microsoft, and we're working to bring you more clarity in how we speak about them. For my part, I'll try to clearly say "SDL threat modeling," or be explicit when I'm talking about threat modeling in broad terms.

Which brings me to my second point, and a slide I wanted to emphasize. (Shown here)

I no longer think of threat modeling as one thing. I see it as a label for a set of ways to address the question of "what could go wrong" with a design or set of requirements. The SDL has one process. The folks in ACE and Patterns and Practices each have another. All are customized to meet various needs. Much like we have lots of programming languages which address different problems, we're going to have lots of threat modeling processes.

Anyway, I hope you enjoy the slides.

Corrupted Heap Termination Redux

Hi, Michael here.

In a previous post I explained how to use HeapSetInformation correctly. In short there's an option when calling this function that will terminate your application if the heap manager detects some form of heap corruption, or the potential to cause heap corruption.

I would recommend you read the previous post before continuing.

You guessed it, the number one email I got after this post was, "So, what sort of corruption will terminate my app?"

So for all those who emailed me, here's a list:

• Corruption of an uncommitted range (region inside heap segments which are reserved but not committed)
• Heap header corruption, for example the heap header checksum is invalid. This can be a single header, or multiple headers.
• Walk of the large virtual blocks shows corruption (all blocks above about 512Kb on x86 and 1Mb on 64 bit are not allocated from segments; they are direct virtual allocations, the heap just holds a list of them along with some metadata to assure consistency with the rest of the heap. They are chained in a double linked list so corruption can be detected by walking the list.)
• Buffer overrun: the next block header size does not match the expected current block size.
• Buffer underrun: same as above, but the previous block header size does not match the expected current block size.
• Attempting to free a free'd block (double-free bug)
• Attempting to free a non 8-byte aligned block.
• Passing a bogus heap handle, it could simply be an invalid heap or a handle to a different heap.
• Corruption of free block list. A bit of a catch-all, including: writing after free, overrunning a previous and managing to step over the list entry.

But there is one huge and critically important caveat to using the defense: it only works if you use the Windows heap manager. You might be surprised to learn that many applications actually implement their own heap functionality for various reasons, often legacy reasons based on historically poor performance of operating system heap managers. A great deal of performance work was performed on the Windows Vista and Windows Server 2008 heap managers, but the work performed is way beyond the scope of this document. Another common scenario is to allocate a huge block of memory from the operating system and then perform custom allocation within that heap block. Again, if you do this, you will not get benefit from using the heap corruption termination capability and you will still be subject to repeatable heap based attacks.

Another down side of not using the native Windows heap manager (or if you use your own sub-allocation mechanism) is you cannot take advantage of Windows leak-detection tools because you are not using the Windows heap in the way it's meant to be used, or you're not using the Windows heap at all.

With all this said, I realize that moving off a custom heap to another heap is never an easy task, but if you want to take advantage of this defense, you should add "Move off our custom heap" to the list of development tasks.

SQL Injection Follow-up

Hi everyone, Bryan here. Michael wrote a great post here on SDL-required SQL injection defense techniques in the wake of the recent mass SQL injection attacks against ASP sites. Additionally, the Security Vulnerability Research & Defense blog has just posted an analysis of the attack along with guidance recommendations for IT/database admins, web developers, and end users. Finally, if you are looking for classic ASP-specific (not ASP.NET) guidance, Bala Neerumalla has posted a detailed document on preventing SQL injection in ASP on MSDN.