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.

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

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!

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.

Ninjas are cool, but engineers build bridges

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

Pirates are Way Cooler than Ninjas, but Engineering Got us to the Moon

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

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

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

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

I wanted to reply to one thing that Cory said:

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

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

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

Ninjas and Engineers Agree: Threat Model

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

Pirates and script kiddies would prefer you just fuzzed.

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

Hi, Michael here.

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

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

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

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

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

...

typedef struct _SRV_WORK_ITEM

{

...

    //

    // This is the Receive Buffer for the incoming request

    //

    PSRVBUFFER ReceiveBuffer;

    PSRVBUFFER ResponseBuffer;

...

} SRV_WORK_ITEM, *PSRV_WORK_ITEM;

...

NTSTATUS

Smb2ValidateProviderCallback( PSRV_WORK_ITEM WorkItem )

{

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

    PSMB2_WORK_ITEM pWI = Smb2GetWorkItem( WorkItem );

    PSMB2_CONNECTION pC = Smb2GetConnection( WorkItem->Connection );

    NTSTATUS status;

    pWI->ParentWorkItem = WorkItem;

    pWI->AsyncId = RFSTABLE64_INVALID_ITEM;

    WorkItem->ProviderWorkItemCleanupRoutine = Smb2CleanupWorkItem;

...

    if( pHeader->ProtocolId != SMB2_PROTOCOL_ID )

    {

        if( pHeader->ProtocolId == SMB_PROTOCOL_ID &&

            pC->Dialect == 0xFFFF )

        {

            //

            // Handle downlevel multi-negotiate

            //

            pWI->Command = SMB2_0_COMMAND_NEGOTIATE;

            goto process_packet;

        }

        else

        {

            WorkItem->DisconnectConnection = TRUE;

            return STATUS_INVALID_PARAMETER;

        }

    }

    pWI->Command = pHeader->Command;

...

process_packet:

    if( SRVWPP_LOG_MESSAGE( DEBUG_MODULE_SRV2, DEBUG_PERF ) )

    {

        Smb2OutputWorkItemRequest( WorkItem );

    }

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

    {

        return Smb2ValidateNotImplemented( WorkItem );

    }

    else

    {

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

    }

}

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

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

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

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

So why did the SDL miss this bug?

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

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

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

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

Going Out on a Limb!

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

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

- Michael

luv u kim x

Cross-Domain Security

Hi everyone, Bryan here. Peleus Uhley, Senior Security Researcher at Adobe, has written a guest post for the BlueHat blog on potential security issues with cross-domain access permissions for web sites. I’d like to encourage you to read Peleus’ post and also to expand on it a little to talk about the SDL requirements around cross-domain access.

Normally, the Same Origin Policy prevents web pages from interacting with resources hosted on domains other than the one they were loaded from. This is done for security reasons; without the SOP it would be trivial for malicious sites to steal or alter data on other sites. However, there are so many great legitimate uses for cross-domain access (like creating client-side mashups) that several technologies have been developed to allow it under limited, opt-in circumstances. These technologies include:

·         Flash’s crossdomain.xml policy file, also used by Silverlight

·         Silverlight’s clientaccesspolicy.xml policy file

·         IE8 XDomainRequest object

·         XMLHttpRequest Level 2 Access-Control headers

·         JavaScript document.domain property redefinition

Now, there’s nothing inherently wrong with any of these (although I have argued in the past that cross-domain XMLHttpRequest would destroy the internet). The problem with using these is that it’s easy to inadvertently expose data to sites you don’t intend to expose data to. Using wildcard domains when determining which domains have access permissions exacerbates this problem. The canonical example of this (no pun intended) is the crossdomain.xml setting

<allow-access-from domain="*"/>

This setting basically opens the web site up to cross-domain access from the entire internet.

To help prevent sites from unintentionally exposing data to malicious external domains, the SDL requires any site with authenticated access to enumerate the specific domains it is allowing access to – no wildcards allowed. Otherwise, the site is free to make its cross-domain access as permissive as desired.

The original draft of the SDL cross-domain requirement was slightly different. Initially, the requirement included restrictions on the use of wildcards based on the depth of the wildcard (i.e. two-dots vs. one-dot vs. no-dots) and whether or not the site provided a “private API”. If a site contained only completely public resources, then it was allowed to use wildcards at the two-dots level or greater; for example, *.live.com would be allowed (two dots) but *.com would not (one dot). If a site had any resources only accessible by authenticated users, then no wildcards were allowed; all domains with cross-domain privileges had to be explicitly enumerated in the appropriate policy file or header.

However, we later realized that this requirement draft was both overly complicated and overly restrictive. If a site is completely public – no authenticated access, no private or sensitive data – then there’s really no reason to restrict its access at all. The reason for this is that cross-domain attacks are luring attacks. To succeed, the attacker needs to lure a victim into performing some action on the attacker’s behalf. For example, a cross-domain attack against a stock trading web site might cause the victim to send the attacker the complete details of his stock portfolio, or might cause the victim to make unintended trades. But in a completely public site, there’s no personal data to steal and no possible authenticated actions to forge. There’s no reason for an attacker to perform a luring attack – they already have the same access to the same data that everyone else has.

When we realized that our requirement was too restrictive, we changed it to its current form. However, let’s re-examine the requirement in light of Peleus’ research on cross-domain access chaining. (To give an extremely brief summary for those who haven’t read it yet: cross-domain permissions are transitive. If site A grants privileges to site B, and site B grants privileges to site C, then site A is implicitly and perhaps unknowingly granting privileges to site C.) For the completely public site the potential of privilege chaining is a non-issue in terms of SDL requirements; we’ve already said it’s acceptable to grant global access if desired. However, the situation is more complicated for the site with authenticated actions.

It is true that even with wildcard domains being prohibited, there is still the possibility that one of an authenticated site’s allowed domains could chain access to a potentially malicious third site. Unfortunately, short of banning cross-domain access entirely, there is no way to completely prevent this possibility. In most situations it would be impossible to map out a list of 3^rd and 4^th and n^th order chained domains at development time, and furthermore it would be pointless since the list could change at any time even after the app has been deployed.

In light of this research, we will be evaluating ways in which we can adapt the cross-domain requirement to continue to prevent unintended access from third-party domains. However, the requirement as it stands now remains useful and relevant. It raises the bar for attackers while imposing minimal design constraints and minimal time investments on the part of the development team.

Hi everyone, this is Eleanor Saitta with iSEC Partners, with a brief post about return on investment and structured security. 

A few weeks ago, Microsoft and iSEC Partners published a joint whitepaper titled, “Microsoft SDL: Return On Investment”, and I'd like to highlight a contradiction the paper discusses between what return on investment numbers show and common industry practice.  In many cases, we see companies spending most of their security budget on gatekeeper-style security projects — right before the product is released, a security team gets called in to try to find vulnerabilities.  This is more expensive and less effective than building security in from the start of a project and throughout the project’s development.  Vulnerabilities are missed with the gatekeeper approach because in any large and complex system there's rarely time to look at every line of code and every function.  That's not the worst of it, though — the cost of fixing the vulnerabilities found by the team can end up being huge because fixing security problems found late in the game may require a product be pushed back several stages in the development cycle and then retested to make sure no regressions are introduced and that the intended functionality didn't change.

This type of late-development churn is inefficient.  In fact, the difference in cost between finding and fixing vulnerabilities early and fixing them once an application is about to deploy can be a factor of 30 or more (per a 2002 NIST study — see the whitepaper for more details) For example, if you're writing a web application and you perform an architectural security review, protecting against Cross-Site Scripting can be built-into the software as a functional requirement, and you can ensure that the application is designed so all output is correctly encoded.  Putting in a point-fix at the right place in the framework and verifying that developers used the routine correctly is much easier and cheaper than trying to hunt down widely scattered cross-site scripting issues just as your ship deadline is approaching.  Similar platform-level mitigations can solve a wide range of what are commonly considered low-level issues.  Application platform vulnerabilities like Cross-Site Scripting or Cross-Site Request Forgery are what penetration testing is best at finding, but solving them up front with architectural review and secure design is still easier, cheaper, and more reliable than finding them in a gatekeeper-style penetration test and patching them.

In comparison, higher-level vulnerabilities in business rules, authentication, authorization or similar design issues can be both difficult to find and extremely time-consuming to fix if you only look for them once development has finished. Developers may have to change the core architecture of the system, leading to cascading code changes and regressions.  On the other hand, a high-level security analysis (via threat modeling, security design review and related techniques) can be very effective at finding these types of issues.  You can do this analysis even before development starts, preventing expensive architecture changes.

Known issue: Using MiniFuzz on Windows XP or Server2003

Michael Howard here with a quick update on MiniFuzz File Fuzzer.

We have received sporadic reports that a few MiniFuzz users are encountering an issue when attempting to run MiniFuzz on Windows Server 2003 or Windows XP platforms. This is a known issue that results from some missing registry keys on Windows XP and Server 2003 that are present in Vista and Server 2008 by default. We had documented this issue on the download site, but I wanted to also mention it here.

Below is a quick snapshot of the error and a simple command-line script that will automatically create the necessary registry settings and allow you to use MiniFuzz on these platforms. This should get you up and fuzzing immediately.

The error:

The manual fix:

Run the following command-line script to automatically create the necessary registry settings:

REG add "HKEY_CURRENT_USER\Software\Microsoft\Windows\Windows Error Reporting" /f
REG add "HKEY_CURRENT_USER\Software\Microsoft\Windows\Windows Error Reporting" /v DontShowUI /t REG_DWORD /d 1
REG add "HKEY_CURRENT_USER\Software\Microsoft\Windows\Windows Error Reporting" /v ExcludedApplications /t REG_MULTI_SZ

What we are doing about it:

We will be fixing this issue in MiniFuzz and putting up a fixed version of MiniFuzz in the future.

Thank you for downloading MiniFuzz. We apologize for this inconvenience, but hope this manual fix will help you begin fuzzing your applications.

Hi everyone, Bryan here.

As we’ve talked about on this blog many times in the past, the SDL requires the use of the Microsoft AntiXss library to defend against cross-site scripting attacks. However, we haven’t talked about the fact that until now, there have been two separate versions of AntiXss: one freely available to external users, and one restricted to use only inside Microsoft hosted data centers. Both versions include functionality to encode HTML output, so that injected script will be harmlessly rendered as text instead of executed by the target’s browser. However, the internal version also includes functionality to sanitize user input and remove potentially malicious script.

We have wanted to bring this internal technology to the external developer community for some time, so I’m excited to announce that the Information Security Tools team is including the HTML sanitization functionality in the new public version of AntiXss (version 3.1) and releasing the entire library under the Ms-PL open source license. Let’s take a quick look at how this functionality works and when you might want to use it.

When used correctly, output encoding is very effective at preventing XSS. However, a side effect of this is that it’s also very effective at preventing any type of user-specified HTML markup, whether malicious or benign. Yes, “<script>document.location='evil.com'</script>” should probably be blocked, but what about “I like <b>strong</b> coffee”? This is not malicious in any way and it seems overly restrictive to block it. (I’ll leave it to your own sense of good taste to decide whether the use of the <marquee> tag is malicious under any circumstances.)

Until now, the preferred way to selectively allow only certain HTML tags like <b> and <i> was to regex the input to ensure it contained only valid Unicode letter and number characters and those specified tags, something like this:

if (!Regex.IsMatch(input, @"^([\p{L}\p{N}'\s]|<b>|</b>|<i>|</i>){1,40}$")) throw new Exception();

This approach will prevent all unwanted tags, but it will also prevent all attributes on the allowed tags. Sometimes this is good – attackers can add malicious script to onmouseover attributes of <b> and <i> tags – but again, sometimes this is overkill and blocks the use of benign attributes like lang or title. It would be theoretically possible to extend the regular expression to allow these attributes, as well as other safe HTML tags and their attributes, but realistically that would be an incredibly difficult regex both to develop and maintain.

AntiXss 3.1 takes care of all of this logic for you, using the same whitelist approach: it filters the input using a list of known good tags and attributes and strips out all other text. Simply pass the untrusted input through the AntiXss.GetSafeHtml or GetSafeHtmlFragment method to sanitize it:

string output = AntiXss.GetSafeHtml(input);

I strongly encourage everyone to download the new AntiXss 3.1 and incorporate it into your applications starting today. It’s a very effective defense, especially when used in conjunction with the output encoding functionality that’s been a part of AntiXss from the beginning. And again, both output encoding and input sanitization are required by the SDL.

Finally, I’d like to thank both the Exchange team (whose HtmlToHtml library provides the sanitization logic) and the Information Security Tools team for bringing this functionality to the public, where it can do the most good for the most people.

Two New Security Tools for your SDL tool belt (Bonus: a “7-easy-steps” whitepaper)

Jeremy Dallman here to announce the release of two new security tools that will help you test and verify the security of your software – and meet some of the most critical requirements of the SDL. In addition, we are responding to customer requests and providing a basic 7-step guide for manually integrating key elements of the SDL Process Template into your existing Visual Studio Team System project.

As secure coding becomes an increasingly important piece of software development across the industry, we realize that security tools become a critical piece of your “security tool belt” and help ease adoption of security development best practices in your organization. In today’s economy, the tools that will get deployed are the inexpensive (or free) tools that effectively identify security issues, work seamlessly with your existing development environment and help teams implement the basics of the SDL.

Today we are making available BinScope Binary Analyzer and MiniFuzz File Fuzzer as no cost downloads.

We put together a couple of demo videos also. You can find them here: BinScope video & MiniFuzz video.

Let me briefly introduce you to each of these tools and explain why we think they are ideal tools to download and immediately include in your development lifecycle to verify the security of your code.

BinScope Binary Analyzer

What it does

The BinScope Binary Analyzer is an SDL-required security tool that has been used by Microsoft teams since the early days of the SDL. It analyzes your binaries for a wide variety of security protections with a very straightforward and easy-to-use interface. At Microsoft, developers and testers are required to use this tool in the Verification Phase of the SDL to ensure that they have built their code using the compiler/linker protections required by the Microsoft SDL.

The analyzer performs a diverse set of security checks. These checks include:

• /GS flag is being set to detect stack-based buffer overflows
• /SafeSEH flag is being set to enable and ensure safe exception handling
• /NXCOMPAT flag is being set to enforce data execution prevention (NX)
• /DYNAMICBASE flag is being set to enable Address Space Layout Randomization (ASLR)
• .NET Strong-Named Assemblies are being used to ensure unique key pairs and strong integrity checks are in place
• Known good ATL headers are being used
• Up-to-date compiler and linker versions are being used (minimum Visual Studio 2005 SP2)
• Reports on dangerous constructs that are prohibited/discouraged by the SDL (e.g. read/write shared sections, global function pointers).

How you use it

The BinScope Binary Analyzer can be downloaded as a standalone tool or as a tool that can be integrated into Visual Studio 2008. By offering these two options, this tool can easily and quickly help you build your code to meet the SDL compiler/linker protections.

(Figure above: stand-alone BinScope)

(Figure above: BinScope integrated in Visual Studio)

Extra Goodness

With an integrated installation of the BinScope Binary Analyzer for Visual Studio, validation is readily available in the development environment. In addition, BinScope integrates with Microsoft Team Foundation Server (TFS) to output results into work items. Finally, if your project is using the Microsoft SDL Process Template for VSTS, BinScope will seamlessly integrate with the template’s security work items and SDL Final Security Review reporting.

(Figure above: Easy output to TFS to create bugs and speed triage)

(Figure above: Seamless integration with the SDL Process Template reporting)

MiniFuzz File Fuzzer

What it does

The MiniFuzz File Fuzzer is a very simple fuzzer designed to ease adoption of fuzz testing by non-security people who are unfamiliar with file fuzzing tools or have never used them in their software development processes. A less capable and non-graphical version of this tool was originally published on the CD that came with the book The Security Development Lifecycle by Steve Lipner and Michael Howard. Since that tool was effective at finding quality bugs, we wanted to offer it more widely along with our other SDL tools, improve the user experience, and provide integration with Visual Studio and Team foundation Server.

Because fuzzing is effective at finding bugs, it is a required activity in the Verification Phase of the Microsoft Security Development Lifecycle (SDL). With the release of the MiniFuzz File Fuzzer, we have made a simple file fuzzer available to assist developer efforts to find and address more security bugs in code before it ships to customers. Simply provide the tool with a set of correctly formed files to serve as templates, and it will generate corrupted versions for testing. The effectiveness of fuzz testing can be increased by providing more variation in the template files.

How you use it

When you install the MiniFuzz File Fuzzer, it is provided as a stand-alone fuzzing tool that can be launched from your Start Menu. However, if you are using Visual Studio 2008, you can easily include the tool in Visual Studio as an Add-in Tool and launch it from there. In addition, the tool can also output to Team Foundation Server and integrate with the Microsoft SDL Process Template for Visual Studio Team System similar to the BinScope Binary Analyzer.

Whitepaper: Manually Integrating the SDL Process Template

The whitepaper can be downloaded here

After a successful release of the SDL Process Template for VSTS, we heard from some customers that they would like to include the key elements of the SDL into their existing team project. So, we figured out how to do that in 7 easy steps and wrote a whitepaper! This paper outlines the steps for manually extracting the key elements of the SDL Process Template and integrating them into an existing Visual Studio 2008 team project. By completing each of these manual steps, you can include the key elements of the SDL into your project without waiting until you start or build your next team project.

~~~~~~~~~~~~~~~~

That’s a lot of news for one day, but I hope you are as excited as we are to be releasing these tools and making it possible for more development teams to write secure code and adopt the SDL. We welcome your comments and questions as you download and begin using these tools!

[edited: 9/16/09 11AM - added links to videos]

Hi, this is Johannes Ullrich from SANS.

As CTO of the SANS Internet Storm Center www.isc.sans.org , I lead the development of complex and exposed applications. Recently, SANS www.sans.org became a member of the SDL Pro Network. I am happy that I will be able to teach the SDL curriculum in San Diego September 15^th http://www.sans.org/ns2009/.

As a developer, you are faced with an almost impossible task. Even small projects process hundreds of pieces of input data, provide access control to multiple users and interact with multiple systems like databases and browsers. If you make one mistake, one single SQL injection flaw, one function with insufficient access control, you lose. On the other hand, an attacker only has to find one single flaw in order to breach the application.

How do you “win” given these unfavorable odds? One mistake made by developers is to worry too much about individual lines of code forgetting about the big picture. As part of teaching developers about secure coding and defending web applications, I have started to adopt a philosophy I describe as “application security street fighting”. This philosophy focuses on easy and repeatable coding techniques. These techniques do not require developers to become security experts. Instead the approach focuses on using the right tools and principles to guide developers to create secure applications that can be efficiently implemented and maintained.

1 – Simple repeatable coding techniques

One aspect of street fighting, as compared to martial arts practiced in dojos and exhibited in competition is the fact that complex techniques don’t work. A quick kick to the groin usually beats the complicated judo throw. For a developer, this means that standard problems have to be solved in simple, repeatable ways. For example, the ever-present issue of SQL injection is easily addressed. By writing a simple library to enforce the use of prepared statements, the need to implement and secure SQL statements one at a time will diminish.

Another example is user input validation. We typically teach developers to write two lines of code. One line is to retrieve the data from the user, and another line to validate that the data is in the expected format. In my opinion, this is one line of code too much. Instead, write a library once that will retrieve the data and validate it. Going forward, the developer will now only call one function, which will retrieve and validate the data. To illustrate, a little bit of pseudo code:

First the traditional way:

Userdata=GetInput(‘email’);

If ( ! is_email(Userdata) {

Error

}

Next the better version:

Userdata=GetEmail(‘email’);

2 – Threat Focused Coding

Once we get past simple issues like SQL injection and input validation, our developer is able to focus on more challenging security problems such as: How am I going to accurately describe the business logic?; or Which techniques could an attacker use to bypass access control restrictions? The developer’s focus will shift from individual lines of code to the larger threat. Threat modeling, an important part of the SDL, will now become much more meaningful to the developer. To apply a street fighting metaphor: Don’t look at your gun, look at your target. You need to know what is happening on a macro level and not get lost focusing on details.

3 – Training

Even simple techniques will not work if they haven’t been taught and practiced properly. There is a point for “dojo” style training in which you are presented with a set scenario and a safe environment in which to practice. This training needs to be applicable and based on real life situations in order to be effective. One thing I liked about the SDL curriculum developed by Microsoft is that it comes from a company that is able to apply these techniques in its own products. Software security training should not just come from security people, but be strongly influenced by developers. Aside from classroom training, there are plenty of other opportunities to learn and practice in your day-to-day job. It is also important to distinguish between training and practice. Training focuses on learning new skills, usually from an outsider. Practice on the other hand is all about applying what you learned and repeating it. Practice can benefit from outside feedback, but it can also be done on your own. Classroom training should illustrate how you are able to practice what you learned once you get back home. At SANS, one of our long-standing promises has been that what you learn in class, you will be able to apply the day you come home. If it would be any other way, we would only teach skills which you will never use and eventually forget.

4 – Conclusion

The SDL starts with training. Training your developers to reuse code and, to use simple and repeatable techniques to code securely will pay off later during implementation. Code reviews will be easier and faster if developers adhere to these guidelines. Even your response plan can harness the same principles by automating the detection and response to common attacks.

As I’ve discussed here, Application Security requires a combination of knowledge, basic skills and practice so that defending applications through secure coding is done instinctively. The MS SDL process is a great toolkit and leverages the hard lessons learned over the years in security. If you’d like to learn the basics in a one day class, I’ll be teaching the MS SDL in San Diego on September 15^th. Check it out and register at http://www.sans.org/ns2009/.