The Security Development Lifecycle

Financial Services Industry Publishes Software Assurance Framework

SDL Team — Wed, 01 Feb 2012 23:00:00 GMT

More and more enterprises are realizing the importance of proactive security practices and those involved in critical infrastructure are no exception. One of the most effective ways to drive security improvements in critical infrastructure is through industry consensus. Microsoft has been deeply involved in collaborating with several critical infrastructure sectors to better understand their needs and to help improve their secure software development practices. A critical sector is financial services where Microsoft has had long term collaboration with BITS, a part of the Financial Services Roundtable, made up of major US financial institutions that are responsible for almost 93 trillion in managed assets.

Today, BITS announced the release of their Software Assurance Framework. The purpose of this framework is to document the importance of secure development and to provide guidelines that financial services organizations can use to implement these practices more fully. The framework is rooted in education, integration of security in design using standards and threat modeling, best practices for coding, focused and comprehensive testing and followed with important implementation and response practices. This type of holistic, prescriptive, risk-based approach has been a hallmark of Microsoft’s SDL since inception back in 2004. The BITS Framework goes on to further cite the Forrester Consulting study which details the compelling economic (ROI) reasons to invest in a SDL program.

The framework was also designed to provide guidelines to software suppliers of the financial services industry in writing better, more secure software. BITS recognized the importance of making this an industry-wide effort which is why we are extremely pleased to see it was made available to the public. Microsoft has been a strong advocate for improving secure development practices with free information and tools for many years now. The BITS framework is another great example on the importance of prescriptive security versus descriptive security practices such as checklists.

Of note, this Framework was a collaborative effort that involved several financial services companies in conjunction with Microsoft. The BITS group contains some of the most experienced security people in the financial services industry working together to define clear guidance on the most critical software development best practices for financial services.

We encourage you to take a look at this important document and see how practices from Microsoft’s SDL have helped to make a difference in improving software security within the financial services industry

- Doug Cavit

Evolving Secure Code at Microsoft and Beyond

SDL Team — Wed, 01 Feb 2012 17:02:00 GMT

Steve Lipner here…

Over the past few weeks, Microsoft has been reflecting on the ten year anniversary of the Trustworthy Computing initiative; thinking about the things that have led us to this point in our history and speculating about the future.

Obviously a big part of our work has been the creation and evolution of the Microsoft Security Development Lifecycle (SDL). In our case, security has evolved in large part because of the issues that we faced early on. As referenced in my previous post, the uphill battle we fought in the early years put a negative spotlight on our products and our ability to keep customers safe.

By learning from our weaknesses and from close observation of the evolving threat landscape, we were able to make progress against the challenges by employing an effective approach to developing more secure software. The most prominent and arguably the most important attribute of our evolution lies in our commitment to the SDL – a comprehensive approach for writing more secure code. Under the Microsoft Trustworthy Computing umbrella, the SDL is considered the most battle-tested and effective software security assurance process in the industry.

Clearly Microsoft products are not the only ones being targeted by cybercriminals. Today there is an industry dedicated to finding security vulnerabilities; motivated security researchers are in a race to discover the next big vulnerability in hopes of selling them on the open market. So how does Microsoft work with the industry to help build a safer, more trusted computing ecosystem? One way is by freely sharing our prescriptive guidance around the SDL methodology and tools so that other organizations can build more secure software.

We’ve noticed that IT dependent organizations are no longer satisfied with the latest “Top n list” of security practices; instead they are demanding prescriptive practices like the SDL that make deliberate value judgments on security practices based on real world effectiveness. We’re proud of our efforts here – no other software vendor shares their tools and resources to the extent that we have. We feel strongly that by sharing our best practices and tools, we can help organizations implement a version of the SDL that makes sense for them – regardless of what platform they use.

This insistence on effective security development processes can be found in the recent release of the BITS Software Assurance Framework. For those readers unfamiliar with BITS, it is the technology arm of the Financial Services Roundtable – an organization that includes members from major US financial services organizations. BITS is chartered with finding collaborative solutions to challenges in cybersecurity, fraud reduction and critical infrastructure protection for its member companies. Today, BITS will publicly announce that they have successfully incorporated many of the key elements contained within Microsoft’s SDL into the guidance they provide to their member institutions and their software vendors. Their recommendation of many of our security development practices is gratifying and a strong testament to how far we have come with software development security.

We’re also pleased to see a growing community of individuals and enterprises that are implementing secure development best practices; we feel there should be a venue where those ideas and methodologies can be shared. In an effort to make that venue a reality and sustain the momentum behind secure development processes, we are pleased to announce the first annual Security Development Conference in Washington D.C., May 15th – 16th, 2012.

This event will bring together experts from a variety of industries to Washington, D.C. for a two day conference that centers on the theme “Evolving from Principles to Practices” and will serve as a focal point for education and collaboration for security development professionals. By holding this conference we intend to emphasize the importance of more secure code as the critical first step to protecting against criminal activity. The conference will provide in-depth sessions, panel discussions, and professional networking opportunities that will help organizations develop and accelerate their own security development lifecycle processes.

For more information and registration details, I’d strongly encourage a visit to the conference website at www.securitydevelopmentconference.com

Enhancements to /GS in Visual Studio 11

SDL Team — Thu, 26 Jan 2012 21:40:00 GMT

Hello all – Dave here…

As mentioned in previous posts, there are some interesting changes afoot regarding security in Visual Studio 11. Here is the next installment of the series by Tim Burrell outlining more of the work done by Security Science and the talented folks on the Visual Studio team…

-----------------------------------------------------------------------------------------------------------------------

Microsoft is actively developing Visual Studio 11 and continually looking for ways to improve security-related functionality in the software. We previously noted that we are updating the on-by-default /GS compiler switch, which provides protection against some memory safety bugs such as buffer overflows. This post will provide additional information on those changes.

You may recall that /GS buffer overrun protection places a cookie on the stack between local variables and critical security-critical metadata such as the return address.

The integrity of the GS cookie is checked at the end of the function, prior to the return address being used to return to the caller; if the cookie has been corrupted then execution is terminated rather than carrying on and transferring control to a now suspect return address in memory.

Note that this kind of protection is designed to catch the traditional overflow scenario – i.e. modification of consecutive bytes – and this is indeed by far the most common type of stack corruption bug. However it does not protect a scenario such as:

If the attacker can control the value of ‘n’ above then he can corrupt a single TCHAR character, leaving any GS cookie untouched:

In reviewing those Microsoft Security Response Center (MSRC) cases due to stack-based corruption that were not covered by the existing /GS mechanism, we noted one error that stood out as being more common than others: misplaced null terminators. A typical code sequence might be something like:

The ManipulateString() function correctly writes data within the bounds of the string ‘buf’– but fails to keep track of the final length ‘cch’ of the resulting string. The instruction that null-terminates the string could therefore write outside the bounds of the string buffer without corrupting the GS cookie.

Compile the code above using the Visual Studio 11 Developer Preview tools and you will see that the generated code includes an extra check:

The compiler has inserted range validation code for the null-terminating instruction to guard against an out-of-bounds write to memory, roughly equivalent to:

A couple of questions arising from this are:

1. “What is the __report_rangecheckfailure() function?”

2. “When/how often does this range validation happen?”

The __report_rangecheckfailure() is similar to the existing __report_gsfailure() function; it just terminates the program to prevent further execution in a state that we know is about to become untrustworthy. We will come back to this in more detail in a later post.

With respect to how often such range validation happens, it is targeted precisely at the code pattern for which there is historical data indicating the highest risk of a bug being present, namely an assignment to a single array element where:

- The array element size is 1 or 2 bytes, i.e. typically a string.

- The value being written is zero, i.e. to catch the null terminator case.

- The array is declared to be of fixed known size (note that this could be a local or global array so not restricted to the stack).

In addition, for the compiler to be able to insert the instruction guarding against a range violation, it needs to know the size of the array. So an additional requirement in Visual Studio 11 Developer Preview is that the array assignment instruction involves an array of locally and statically declared size. By means of illustration, the following would not lead to a range check being inserted:

As always this is a trade-off. By targeting these extra checks as described above, Visual Studio 11 by default provides extra protection for a limited set of bugs that history tells us are the most common kind of stack-corruption bugs not covered previously by /GS, while minimizing performance and codesize impact by keeping the number of such checks low overall.

And of course /GS continues to provide the familiar cookie-based protection against traditional stack overflows.

The /GS compiler switch is one of many security enhancements being looked at for Visual Studio 11 and is but one small part of the Security Development Lifecycle (SDL) process and methodology for developing secure software, which includes much more than just using specific compiler switches – read more and find additional resources related to SDL here.

Tim Burrell, MSEC Security Science.

Secure Credential Storage

SDL Team — Mon, 16 Jan 2012 19:55:00 GMT

Pop security quiz: What’s the most secure way to store a secret?

a) Encrypt it with a strong symmetric cryptographic algorithm such as AES, using a 256-bit key.

b) Encrypt it with a strong asymmetric cryptographic algorithm such as RSA, using a 4096-bit key.

c) Encrypt it using a cryptographic system built into your platform, like the Data Protection API (DPAPI) for Windows.

Have you made your choice? The correct answer is actually:

d) Don’t store the secret at all!

Ok, it was a trick question. But the answer is valid: thieves can’t steal what you don’t store. Let’s apply this principle to the action of authentication – that is, logging into a web site. If a site never stores its users’ passwords, then even if the site is breached, those passwords can’t be stolen. But how can a site authenticate users without storing their passwords? The answer is for the site to store (and subsequently compare) cryptographic hashes of the passwords instead of the plaintext passwords themselves. (If you’re unfamiliar with the concept of hashes, we recommend reading http://msdn.microsoft.com/en-us/library/92f9ye3s.aspx#hash_values before continuing.) By comparing hashes rather than plaintext, the site can still validate that the user does indeed know his or her password – otherwise, the hashes wouldn’t match – but it has no need to ever actually store that password. It’s an elegant solution, but there are a few design considerations you’ll need to implement to ensure you don’t inadvertently weaken the strength of the system.

The first design issue is that simply hashing the passwords alone isn’t enough protection: you also need to add a random salt to each password before you compute its hash value. Remember that for a given hash function, an input value will always hash to the same output value. With enough time, an attacker could compute a table of plaintext strings and their corresponding hash values. In fact, many of these tables (known as “rainbow tables”) already exist and are freely downloadable on the Internet. Armed with a rainbow table, if an attacker could manage to gain access to the list of password hashes on the web site by any means, he could use that table to easily determine the original plaintext passwords. When you salt hashes, you take this weapon out of the attackers’ hands. It’s also important to generate (and store) a unique salt for every user – don’t just use the same salt for everyone. If you did always use the same salt, an attacker could build a new rainbow table using that single salt value, and eventually extract out the passwords.

Figure 1: Comparing salted hashes

The next important design issue to take is to be sure to use a strong cryptographic hash algorithm. MD5 may be a popular choice, but cryptographers have demonstrated weaknesses in it and it’s been considered an unsafe, “broken” algorithm for years. SHA-1 is stronger, but is beginning to show cracks and now cryptographers recommend avoiding SHA-1 as well. The SHA-2 family of hash algorithms is currently considered the strongest, and is the only family of hash algorithms approved for use in Microsoft products per the Microsoft Security Development Lifecycle (SDL) cryptographic standards policy.

Instead of hardcoding your application to use SHA-2, an even better approach would be to implement a “cryptographic agility” that would allow you to change the hash algorithm even after the application has been deployed into production. After all, cryptographic algorithms go stale over time; cryptographers find weaknesses and computing power increases to the point where brute force approaches become feasible. Someday SHA-2 may be considered just as weak as MD5, so planning for this eventuality early may save you a lot of trouble down the road. An in-depth look at hashing agility is beyond the scope of this post, but you can read more about a proposed solution in the MSDN Magazine article Cryptographic Agility. And just as the SDL mandates the use of strong cryptographic algorithms in Microsoft products, it also encourages product teams to use crypto agility where feasible so that teams can more nimbly migrate to new algorithms in the event that a current strong algorithm is broken.

So far, we’ve talked about what to hash (the password and a random unique salt value) and how to hash (using a cryptographically strong hash algorithm in the SHA-2 family, and preferably configurable to allow for future change), but we haven’t talked about where to hash. You might think that performing the hashing on the client tier would be a significant improvement in security, since you’d only need to send the hash over the wire to the server and never the plaintext password itself. However, this doesn’t buy you as much benefit as you’d think. If an attacker has a means of sniffing network traffic, he could still intercept the call and pass the hash to the server himself, thus spoofing the user and taking over his session. At this point, the hash essentially becomes the plaintext password. The only real benefit to this approach is that if the victim is using the same password on multiple web sites, the attacker won’t be able to compromise the victim’s account on those other sites as well, since knowing the hash of a password tells you nothing about the password itself. A better way of defending against this attack is just to perform the hashing on the server side, but to ensure that the password and all credential tokens such as session cookies are always transmitted over SSL/TLS. We’ll explore the topic of secure credential transmission (and other aspects of password management such as password complexity and expiration) in future blog posts.

By following a few simple guidelines, you can help to ensure that your application’s users’ credentials remain secure, even if your database is compromised:

Always store and compare hashes of passwords, never the plaintext passwords themselves.
Apply a random, unique salt value to each password before hashing.
Use a cryptographically strong hash algorithm such as one from the SHA-2 family.
Allow for potential future algorithm changes by implementing a cryptographically agile design.
Hash on the server tier and be sure to transmit all passwords and credential tokens over HTTPS.

What a Journey It Has Been

SDL Team — Thu, 12 Jan 2012 23:54:00 GMT

I remember the security situation at Microsoft in 2001 and 2002 like it was yesterday. Perhaps no other couple of years will be so indelibly etched into my brain as those two. 2001 was not so good, but 2002 was a heck of a lot better! Given 2001, this was not a difficult achievement for 2002! So, let me start at the beginning…

In late 1999, a small band of us formed a small security team (as in “threats,” not as in “features”) to help raise software security awareness across the company. We had no name for a long time, until the vice president in Windows at the time, Dave Thompson, decided to call us the Secure Windows Initiative (SWI). Our charter was to start reviewing Windows code in depth looking for security bugs, but having a small number of people reviewing something the size of Windows was clearly not going to work. So, we moved to a “Security Bug Bashes” model where we would deliver security education in the morning to a small development group within Windows (e.g., networking, terminal services, IIS, IE, etc.), and then for the rest of the day we would have the engineering team go look for security bugs. It was fun and we found bugs. But the most important point was raising awareness. It really didn’t matter how many bugs were found—the key was to make people aware of the security issues and reduce the chance that mistakes would be made in the future.

The downside of the bug bashes was that even though they were more effective than the original SWI charter, they still didn’t scale very well and they were very labor-intensive. Still, the security bug bashes continued for about another eighteen months.

2001 was not a good year for Microsoft security because of CodeRed and Nimda, two worms that affected Internet Information Server 4.0 and 5.0. CodeRed was the result of a one-line error in some code running by default in IIS4 and 5. In hindsight, the code should not have been installed by default. Nimda was the more sophisticated of the two worms because it used more than one vulnerability to compromise systems.

While all this was happening, David LeBlanc and I were mid-way through creating the first edition of Writing Secure Code. We had written the book because the same security-related questions were being asked time and time again and we wanted a reference we could point people to. Little did we realize that Writing Secure Code would later become a runaway bestseller.

As 2001 wound down and Writing Secure Code was finally sent to the printers, I got an email from Loren Kohnfelder, who was one of the security leads in the .NET Framework. Loren is best-known for defining what is now commonly referred to as Public Key Infrastructure (PKI). You can read his 1978 thesis on the topic here. Loren was also one of the protagonists behind the STRIDE threat modeling mnemonic.

Loren told me that the .NET Common Language Runtime (CLR) team had uncovered a small number of security bugs during the final development phase of the project, and he was really concerned. We decided to do a bigger version of a bug bash; but rather than lasting only one day, it would be done when it was done. “Done” meant the rate of incoming security bugs approached zero. This became known as the “.NET Security Standdown,” and we even had T-Shirts made with the date of the start of the event. On the day the event was to start, the Pacific Northwest got a huge snow storm and the Microsoft Redmond campus was closed, so we started the standdown a few days later.

The standdown was a great success, thanks to Brian Harry and his team, who managed the process brilliantly. We reeducated the .NET engineering team, we found and fixed bugs, but most important, in my mind, we introduced the concept of reducing attack surface (i.e., limiting the amount of code exposed to untrusted users). That’s where the concept of AllowParticallyTrustedCallersAttribute (APTCA) came from and why we flipped ASP.NET to run in much lower privilege.

December 2001 saw the release of Writing Secure Code, and Doug Bayer and I had a lengthy meeting with Bill Gates to explain security vulnerabilities in detail. Clearly he was concerned by the worms of 2001 and wanted to learn more. At the end of the meeting I gave Bill a copy of Writing Secure Code.

At the end of December 2001, the .NET Standdown was over and we had learned a great deal about rallying the troops to a common security cause. But there was much more work to do!

In light of the success of the .NET work, we decided to aim our sights at Windows .NET Server (as it was called back then). Following the .NET model, we started in February and would be done when we were done. For the most part, that ended up being late March for most teams within Windows.

This became known as the “Windows Security Push.”

As everyone knows by now, Bill sent his famous Trustworthy Computing (TwC) memo to the company in January 2002, right as we were planning the security work for Windows. His memos are rare, and this one signaled the start of something big within the company.

During the push, we had three streams of education: I handled all the Windows developers, Jason Garms worked with all the program managers and architects, and Chris Walker trained all the testers. Steve Lipner and Glenn Pittaway led much of the day-to-day process management, keeping in constant communication with upper management.

One practice we borrowed from the security bug bashes was that we always had a senior person from management kick off the training. At one of my sessions, I had Rob Short, VP of Windows Base (Kernel down to the metal) open the day. Rob’s a tall, lean Irishman with a thick Irish accent, and there’s something he said that has stuck with me forever. He said, “There is nothing special about security; it’s just part of getting the job done.” Whenever I deliver a security talk to new engineers within Microsoft or am onsite with a customer, I always recite Rob’s words, because they are so incredibly true.

The Windows Security Push begat the SQL Server Security Push, the Exchange Security Push, and the Office Security Push. Slowly but surely things started to change across the company. Engineers and managers “got it.”

A key element of all the pushes was to reduce the default attack surface of the products. That’s why Windows Server 2003 (note the name change) had a reduced functionality browser, no Web server installed by default, and much more.

One thing that is not commonly known about the pushes is that a lot of documentation was written about the security implications of various technologies. Much of that learning ended up in the second edition of Writing Secure Code; the book ballooned from 500 pages to over 800 pages, and much of that was detail we learned and fine-tuned throughout 2002. A great example is the chapter concerning the security implications of internationalization and globalization. The text in the book is derived from a whitepaper written by the globalization team within Windows after they had gone through the push process and had looked at their important corner of Windows with a fresh security perspective.

The pushes were just the start, however. Real change came only when we implemented the Security Development Lifecycle (SDL). As I have said many times, you can’t build some software and then have a security push. It just doesn’t scale and, frankly, having a push at the end is too late. We needed something that was “part of the process,” and that is how the SDL was born.

There was a wrinkle along the way, however. In 2003 we saw Slammer affect SQL Server and Blaster affect Windows. Because one of the effects of Blaster was blue-screened computers, product support saw a huge increase in support calls. Many of us manned the phones to help out. Raymond Chen, a lead developer on the Windows shell team, and I were seated next to each other, and he wrote about it in his blog.

Blaster led to a lengthy and intense effort known as “Springboard,” led by Rebecca Norlander, Matt Thomlinson, and John Lambert. The end result of the process was Windows XP SP2, in which we not only found and fixed security bugs but also added numerous critical defenses to Internet Explorer, DCOM, and RPC. We also enhanced and enabled the Windows Firewall and added data execution prevention (DEP), and we made it easier for users to enable automatic updates by prompting them right after setup.

Microsoft has come a long way in the last ten years, and I am incredibly proud to have been a part of this watershed time. Much has changed. The SDL is now seen as industry-leading and is in use by many software developers outside of Microsoft. My role has changed too: I now work with our customers and partners as part of the Microsoft Americas Services Cybersecurity team to help them adopt SDL practices as they recognize the need for an increased focus on security.

It’s been an amazing ten years. We still have much to do, however. And no one knows that more than the incredibly talented people across Microsoft helping bake security into our products and our partners’ and customers’ products every day.

Michael Howard

Principal Cybersecurity Architect

Trustworthy Computing’s 10 Year Milestone – Reflecting on Humble Beginnings

SDL Team — Thu, 12 Jan 2012 17:39:00 GMT

January marks the ten year milestone of Bill Gates' memo on Trustworthy Computing. When I think about “where was I when…” the email hit my inbox, several memories come to mind that I thought I’d share. Back then I was the Director of Security Assurance, a position that encompassed both the Microsoft Security Response Center (MSRC) and the Secure Windows Initiative that focused on improving the security of Microsoft’s products before they shipped. We had had our share of problems in those days as attackers had released worms – Code Red, Nimda – against our products and customers.

On January 12^th 2002, Michael Howard, Jason Garms, Glenn Pittaway and I were working long days and nights preparing for the February start of the Windows Server 2003 security push. We were prioritizing component development groups, identifying tools that we’d tell groups to run, and working to finalize the four-hour security training class that we planned to present to a total of about 8500 people during the week of January 28, 2002.

One of our big concerns was how the employees would react. We knew that our managers up to senior and group vice president had approved our idea of conducting the security push, and we knew that the team commitments were on the calendar. But if the individual employees and lower-level managers weren’t on board with the idea, the process could crater badly.

Bill’s Trustworthy Computing mail appeared in the midst of this hard preparatory work. I won’t say we would have failed to get the employee engagement we needed if Bill hadn’t sent his mail – after all, we’d lived through Code Red, NIMDA, and some very embarrassing vulnerability reports against Windows XP, and developers and managers were aware of the negative customer perception. But I do know that Bill’s mail made a difference. We told developers, program managers, and testers to sit through four hours of training in a cramped (950-person) meeting room and pay attention, and they paid attention. We told them to review code and find security bugs rather than working on features, and they found and fixed security bugs. We gave them, what I know with ten years hindsight were, immature and flaky tools and processes, and they swallowed hard and used them effectively to find more security bugs. And to this day, I believe a lot of their willingness to do those things was not only because their managers said to do them, but because Bill and Craig Mundie (then Microsoft’s Chief Technology Officer and today Microsoft’s Chief Research and Strategy Officer) had said they were important to do – important for our customers and important for Microsoft.

We’ve done a lot to make our software and services more secure in the last ten years. The Security Development Lifecycle (SDL) evolved from the security push and today we’re recognized for our leadership because we share SDL process and tools with the broader software development community. But the security pushes of 2002 were the beginning. And Bill’s commitment and the way it mobilized the company were the key to that beginning.

Steve Lipner

Senior Director of Security Engineering Strategy

Trustworthy Computing

Compiler Security Enhancements in Visual Studio 11

SDL Team — Fri, 02 Dec 2011 17:42:00 GMT

Hello all – Dave here…

In chatting with our colleagues in the MSEC Security Science Team, there were a number of interesting topics that weren’t covered in our previous Code Analysis blog post – information that would help contribute to the understanding of security features and functionality in Visual Studio 11. So after some discussion, we have decided to release a series of posts covering this important work – everyone benefits from a better understanding of future technology offerings.

So with that, I again turn the blog over to Tim Burrell to elaborate!

_______________________________________

(Note – this blog post describes a feature in an unreleased product; this feature may be changed prior to final product release.)

Microsoft is actively developing Visual Studio 11 and continually looking for ways to improve security-related functionality. As part of this we are updating the /GS compiler switch, which is on-by-default and enables a basic level of code generation security features, with some enhancements beyond the now familiar cookie-based stack overflow protection. We’ll provide some more detail on these in a later post.

The Security Development Lifecycle (SDL) includes a number of recommendations beyond the scope of /GS where the compiler is able to assist secure software development. These range from specific code generation features such as using strict_gs_check to security-related compiler warnings and more general recommendations to initialize or sanitize pointers appropriately.

For the first time we intend to provide a central mechanism for enabling such additional security support via a new /sdl switch. The impact of /sdl is twofold:

- /sdl causes SDL mandatory compiler warnings to be treated as errors during compilation.

- /sdl enables additional code generation features such as increasing the scope of stack buffer overrun protection and initialization or sanitization of pointers in a limited set of well-defined scenarios.

This dual approach reflects our conviction that secure software is best achieved by the combination of detecting and fixing code bugs during the development process together with the deployment of security mitigations that will significantly increase the difficulty of exploiting any residual bugs.

The /sdl compiler switch is disabled by default, and can be enabled easily in the Visual Studio UI by opening the Property Pages for the current project, and accessing the Configuration Properties -> C/C++ -> General options.

So what does the /sdl switch do?

The features enabled by the /sdl switch are a superset of those enabled by /GS i.e. enabling /sdl enables everything included in /GS. We will be providing more background and in-depth details of the additional /GS and /sdl features in future posts. For now we note that they include:

The following SDL mandatory compiler warnings are enabled and treated as errors:

Warning	Command line switch	Description
C4146	/we4146	A unary minus operator was applied to an unsigned type, resulting in an unsigned result
C4308	/we4308	A negative integral constant converted to unsigned type, resulting in a possibly meaningless result
C4532	/we4532	Use of “continue”, “break” or “goto” keywords in a __finally/finally block has undefined behavior during abnormal termination
C4533	/we4533	Code initializing a variable will not be executed
C4700	/we4700	Use of an uninitialized local variable
C4789	/we4789	Buffer overrun when specific C run-time (CRT) functions are used
C4995	/we4995	Use of a function marked with pragma deprecated
C4996	/we4996	Use of a function marked as deprecated

If a developer wishes to opt in to most of the /sdl functionality but exclude a given warning ID (suppose C4146 for example) then this can be achieved by using the /wd switch to disable that specific warning under C/C++ -> Command Line -> Additional Options in the Visual Studio UI:

· The strict_gs_check pragma is applied to all C/C++ code compiled with /sdl. This instructs the compiler to consider more functions as potential candidates for stack buffer overflow protection. The GS optimization introduced in Visual Studio 2010 has been improved to work better in conjunction with strict_gs_check, specifically enabling many of the extra security checks resulting from strict_gs_check to be proven unnecessary and removed.

Additional /sdl code generation features will be covered in more detail in later posts.

Microsoft strongly recommends using the /GS switch as in previous Visual Studio releases; the new /sdl switch in Visual Studio 11 presents an opportunity for greater security coverage both during and after development: stay tuned for more details on specific security benefits of using /GS and /sdl in Visual Studio 11.

Of course the Security Development Lifecycle (SDL) is an entire process and methodology for developing secure software and as such includes much more than just using specific compiler switches – read more and find additional resources related to SDL here.

Tim Burrell, MSEC security science.

Welcoming Siemens to SAFECode

SDL Team — Tue, 08 Nov 2011 23:09:00 GMT

We’ve talked before on this blog about SAFECode – an organization of IT vendors who have come together to share and document best practices in software security.
SAFECode has published a number of papers on best practices in software and supply chain security – most recently an update to “Fundamental Practices for Secure Software Development” released earlier this year. The SAFECode web site is a great resource for vendor-independent guidance on software security.

Today, SAFECode announced that Siemens has become the eighth SAFECode member joining Adobe, EMC, Juniper, Microsoft, Nokia, SAP, and Symantec. Siemens, headquartered in Berlin and Munich Germany, is a supplier of products for use in industry, healthcare, energy and infrastructure. Software security is an important matter for Siemens, and they will bring SAFECode great expertise in control systems often used in critical infrastructure.

As the Microsoft representative to the SAFECode board and the board’s chair, I’m delighted to welcome Siemens to SAFECode. I’m looking forward to SAFECode releasing new products that take advantage of the expertise Siemens brings.

Steve Lipner

New SDL Industry Talk Wall Launched

SDL Team — Wed, 02 Nov 2011 17:03:00 GMT

George Pulikkathara here.

Every now and then we get asked by conference attendees or someone at a company who is evaluating the SDL for adoption at their company, “How well known is the SDL within the IT industry?” or “Where can I find video summaries of your SDL tools or whitepapers?”, or my favorite, “Who else is using the Microsoft SDL?”

Well, today, Microsoft launched a new SDL “Industry Talk” wall on the Security Development Lifecycle (SDL) website. This wall was designed to publically share some of the great evidence Microsoft has generated and continues to generate surrounding awareness and adoption of the SDL.

So if you are considering adopting the Microsoft SDL or know of someone who is looking for a single resource for what the Industry is saying about the SDL, look no further.

By the way, the “Industry Talk” wall was built using HTML5 technology which gives users an exciting new way of experiencing and consuming SDL information. This means you’ll need an HTML5 compliant browser such as Internet Explorer 9 or any of the latest browsers to view the content. Enjoy.

Code Analysis for All

SDL Team — Wed, 19 Oct 2011 18:52:00 GMT

Hello All -

As many of you already know, the SDL team at Microsoft has a strong relationship with our colleagues in the MSEC Security Science team - these guys are on the front line of tool development for the SDL, and are always looking for new ways to take the security technologies they produce and make them broadly available. With that in mind, I am quite pleased to turn over the blog to Tim Burrell to let you know about some new developments on the code analysis front.

- Dave

___________________________

At the recent BUILD Conference, the Visual Studio Code Analysis team presented some great new features of Microsoft Visual Studio 11 C++ Code Analysis. We thought we’d highlight a couple of the security aspects.

This is the first time that Code Analysis has been made available in an Express edition of Visual Studio – a reflection of Microsoft’s commitment to helping secure the software ecosystem beyond just our own software. It is also testament to the value that we believe such static analysis tools have to offer to every developer today. This value comes in many forms, mainly deriving from the fact that it’s way cheaper to fix a bug early on during development:

Fixing a bug early avoids wasted time debugging strange crashes or reliability issues later on.
Fixing a bug early avoids resetting/repeating testing after a bug is fixed late in the development cycle.
Fixing a bug early avoids the complexities associated with fixing it if it is exposed after the application ships.

The Security Science team with the Microsoft Security Engineering Centre (MSEC) worked closely with the Visual Studio Code Analysis team to ensure that the Visual Studio Developer Preview includes as many of the SDL mandatory C/C++ Code Analysis warnings as possible. These are the security-related warnings that Microsoft considers critical to fix for internal C/C++ software development.

Choosing which warnings to include in Microsoft Visual Studio 11 Express is a balancing act between giving all developers access to these warnings and not overloading people with so many warnings that they just ignore them. We’ve tried to select the best combination of high severity / low noise. We are keen to hear your feedback on your experience of using Code Analysis in Express.

Of course the Security Development Lifecycle (SDL) is an entire process and methodology for developing secure software and as such includes much more than just fixing a given set of warnings – you can read more and find additional resources related to SDL here.

As we alluded to at the start, code analysis covers more than just security bugs – indeed the distinction between security and reliability can sometimes be a subtle one: the bug that manifests as a crash today (a reliability issue?) could turn out to be controllable by an attacker tomorrow (a security issue). We highly recommend running Visual Studio Code Analysis to help develop secure and reliable applications.

Tim Burrell, MSEC Security Science

Updated SDL Tools Available

SDL Team — Thu, 25 Aug 2011 16:06:00 GMT

Hello all,

Today we are excited to announce that some enhancements have been made to three of our free Security Development Lifecycle (SDL) tools - Threat Modeling, MiniFuzz, and RegExFuzz.

As many of you know, tools can be an invaluable asset when it comes to implementing a Security Development Lifecycle process in any organization. Over the years, Microsoft has made many of its security development tools available for free here. We hope these new enhancements will provide greater flexibility and enable you to effectively implement an SDL process in your organization.

Threat Modeling Tool v3.1.8

The Threat Modeling Tool is used in the SDL Design Phase to find security problems before coding begins. Through beta testing we obtained valuable input on what changes could be made to improve the tool. In this new version, we focused on stabilization of the Visio 2010 and Team Foundation Server (TFS) 2010 support that was provided as part of the beta release, and fixed bugs that were discovered.

Thank you to all of our beta testers who reported issues in the forum as well as through the select beta program. Your input was critical to improving the tool and customer experience.

> Learn more or download the tool

MiniFuzz Tool v1.5.5

The MinFuzz Tool provides basic file fuzzing capabilities that can be applied by developers, testers and even those with limited experience with fuzz testing as part of the SDL Verification phase. In this new version of the tool, we have included support for Team Foundation Server (TFS) 2010, fixed stability bugs and made it easier to control target application shutdown.

> Learn more or download the tool

RegExFuzz Tool v1.1.0

The RegExFuzz Tool provides regular expression fuzzing capabilities that can be applied during the SDL Verification phase to check that regular expression evaluation times are not exponential. Regular expressions with very long evaluation times can lead to DoS attacks. In this new version, we focused on bug fixes requested from field use of the tool. A readme document has been added to the download which documents the fixes, remaining known issues, and planned future enhancements.

> Learn more or download the tool

As the threat landscape continues to evolve, we remain committed to freely sharing our secure engineering best practices and security tools with the broader community. We hope you find our tools useful and, as always, we welcome any comments or feedback you may have.

Regards,

Monty LaRue [SDL Team]

Application Security: 2011 & Beyond – A Forrester Research Report

SDL Team — Tue, 12 Jul 2011 22:07:00 GMT

Hi All. Doug here,

In April 2011 Forrester Research wrote a new study on Application Security. This study, titled Application Security: 2011 & Beyond led by Dr Chenxi Wang, Lead Analyst at Forrester Research, provides valuable research, insights and recommendations for security and risk professionals. We have since made this study publically available in hopes of creating greater awareness around the importance of secure application development.

The report observes that sufficient resource allocation to address application security remains a significant issue for businesses - Even though secure application development is considered a top priority by IT professionals and web application hacking continues to be the number one source of data breach incidents.

Part of the challenge is getting development organizations to undergo the culture shift required to making risk management and mitigation in application development a priority. Dr Wang’s report shows that organizations who do make the investment in secure application development are realizing positive returns. (More information about return on investment can be found in our recent blog post and in the MidAmerican case study).

There are several great recommendations in the paper which provide cost effective and incremental steps towards better application security. They include demanding better quality and security from vendors, acceptance testing for 3^rd party software, disabling unused default accounts, building a secure operational environment around the application, and effective bug reporting and handling.

Additionally, one of the key recommendations identified in the paper is to implement a secure application development program, such as Microsoft’s Security Development Lifecycle. Take a look to see the latest information and tools that Microsoft makes freely available.

We encourage you to read this study and use it to think about how you can leverage the changing IT environment, such as the introduction of mobile technology and applications, to help provide the catalyst to enable change in your application development culture to improve application security.

Updated Banned API Documentation Available

Michael Howard — Fri, 24 Jun 2011 00:02:00 GMT

Hi, Michael Howard here.

One very low-cost and low-friction SDL task that has high impact is removing (and not adding) banned functionality. The most common examples of banned functionality include various C runtime functions, such as strcpy(), strcat(), strncpy(), sprint(), gets() and their evil brethren; and weak crypto algorithms, such as DES, MD4 and SHA-1.

Over the years, I have shepherded the banned API requirement through the SDL, making updates along the way. One of the biggest changes in recent years (other than adding memcpy() to the list) is a separation of ‘required banned’ functions and ‘recommended banned’ functions. The reason for this change is some functions are a ‘clear and present danger’ and should never be used in any code. Ever. E.V.E.R! This is the SDL ‘required banned’ list.

Other C runtime functions pose less of a risk; but in high-risk code, or code with a very high attack surface, they should be considered for removal, and certainly not added to new code in the first place. This is the SDL ‘recommended banned’ list.

We have created an update to the original banned API and recommended replacements list. That updated text is here and the header file is here.

Feel free to leave a note if you have a question of comment

- Michael

Tooling News: Web Application Configuration Analyzer Released

SDL Team — Wed, 08 Jun 2011 22:00:00 GMT

Hello all, this is Monty LaRue posting with some SDL related tools news. Microsoft has recently released an updated version of the Web Application Configuration Analyzer (WACA). While this tool isn't intended to satisfy specific SDL requirements, it is valuable for performing best practices checks on your web application’s configuration. The checks span the Windows, IIS, ASP.NET, and SQL Server aspects of a deployment and are derived from standards that Microsoft uses to harden production servers. WACA is a good complement to the Attack Surface Analyzer tool which is applicable within the SDL Verification Phase.

You can find more details about each of these tools on the Microsoft Download Center: Web Application Configuration Analyzer and Attack Surface Analyzer Beta.

State of Application Security: Key Findings – A Forrester & Microsoft Webcast

SDL Team — Fri, 20 May 2011 21:19:00 GMT

Hi All – Doug here…

Earlier this year, Microsoft worked with Forrester Consulting and Dr. Chenxi Wang, Lead Analyst on secure application development, to survey the current state of application security amongst 150 of the largest corporations in the US and Canada. I talked about it in February when we first published it on this blog. The report turned out to have a lot of very interesting data, some of which we’ve discussed previously when we published State of Application Security - A Forrester Consulting Thought Leadership Paper Commissioned by Microsoft on our website.

Microsoft is hosting a webcast on Monday, May 23 at 11 am PDT with Dr. Wang talking about the results and her recommendations based on the information in the study. I will be following her presentation with a brief presentation of my own discussing similar benefits that we’ve seen in our interactions with other organizations. The two presentations will demonstrate that the SDL, as an end to end process that engages all the relevant parties within an organization, can have a significant impact.

The current security and compliance environment is driving many organizations to look at their own secure application development practices. The results from this study and the information in the webcast can help provide key parts of the business rationale for starting a secure application development program that is about more than just compliance. The findings of this study are very clear that there is a business benefit in not only doing better application security but also in the ROI of changing the corporate culture around software development. This is a great opportunity to get your business decision makers to hear the facts and to help you make your case.

Come listen and have an opportunity to ask questions. You can sign up here, Business Insights Webcast: State of Application Security: Key Findings.

Adding Usable Security to the SDL

SDL Team — Wed, 04 May 2011 17:53:35 GMT

Adam Shostack here. Lately, I’ve been focused on how we bring the engineering of usable security into the SDL. When I say usable security, I mean that for those times when we need to ask a user for input on something only they know. (For example, are you connecting to a coffee shop network or your work network? Are you trying to print to a printer you’ve never used before?) We want to ensure that those questions enable users to make security decisions in accordance with their preferences and goals. So if you’re coming here to read about what’s made it into the SDL, stop now. But if you’d like some insight into how we update and improve the SDL, and some insight into something we might add, read on.

Remember that, at Microsoft, the SDL is a collection of proven practices that integrate effectively into the software engineering process. One of the key elements there is that the practices are proven to be effective without an expert in the room. We know from our Experiences Threat Modeling at Microsoft that

rolling out a mandate too early can have unfortunate consequences, and we dread the idea of doing that again.

So as we think about usable security engineering, we’ve made some great steps forward. We have guidance that’s in use in some of our product teams. We’ve surveyed the engineers who are using it and they find it effective at producing better interfaces with less debate or churn. What we don’t (yet) have is really crisp entry and exit criteria or tool support, and those are important gates to bring something into the SDL.

All of that is background and context for some work that we’d like to share for your use and feedback. It’s a pair of new mnemonics for important things to consider as you’re building security user experiences. We hope you’ll agree that user interfaces should be NEAT:

Necessary to get the user’s input
Explained in a way that the target audience will understand
Actionable in that the user can realistically make a decision on what you’re asking of them
Tested in both benign and malicious scenarios

For more details, and even a second mnemonic, we suggest you look in the attached two pager by myself and my colleagues Rob Reeder and Ellen Cram Kowalczyk.

All that said, we think this is pretty NEAT, and we wanted to share it and ask for your opinion and feedback. Please give us your thoughts in the comments, or by email to tux@microsoft.com

I’m starting to use the SDL, but how do I…?

SDL Team — Wed, 27 Apr 2011 20:29:00 GMT

Jeremy Dallman here with another release of free SDL documents. Today we are making available a library of templates to help you get started with the more thought-based SDL practices or activities.

One of the big questions we faced early at Microsoft and are now hearing again as more companies of all sizes start to adopt the SDL in their own organizations is “How do I [insert SDL practice or process activity].” Most frequently, these questions are specifically talking about the SDL practices that cannot be addressed with tools and are more process-oriented or thought-based.

As these questions started coming in from other companies, we started digging into some of our internal archives for the documents we used early-on at Microsoft. Most of these documents have since been incorporated into web forms or our internal SDL management dashboards. However, we discovered that they served as very useful templates for other companies. Now we want to let other SDL organizations look at them and put them to good use as well!

Today, we are releasing a small library of templates for SDL practices that can help you address:

Defining Security Requirements
Creating a Security Bug Bar
Performing a Security Risk Assessment
Conducting a basic threat model (when not using the SDL Threat Modeling Tool or EOP game)
Managing SDL Exception Requests
Performing a Final Security Review

… as well as a .ZIP that contains all of the templates in a single package.

These documents are published under the same Creative Commons license as our other SDL documents. Please put them to use in their default form (without edits), as templates to modify/customize for your unique needs, or simply as a catalyst for brainstorming and creating your own documents. The goal is to help you accelerate implementation of the SDL practices and gather valuable security information about your projects.

We are glad to share these pieces of the Microsoft SDL with the ecosystem and look forward to hearing about how they were used in your own SDL projects.

Now available: Microsoft SDL Process Guidance updates – version 5.1

SDL Team — Thu, 14 Apr 2011 21:08:00 GMT

Jeremy Dallman here to let you know we have released our annual update to the Microsoft Security Development Lifecycle Process Guidance – version 5.1 (SDL 5.1). SDL 5.1 is now available for download (.docx format) as well as updated online in the MSDN library.

This public update of our internal SDL process guidance documentation is intended to provide transparency into how we implement the SDL at Microsoft. The changes in SDL 5.1 continue to demonstrate that the Microsoft SDL is continuously evolving to address new attacks, implement new protections, and improve the security of Microsoft products early in the software development lifecycle.

If you are just beginning your investigation or implementation of the SDL, we encourage you to first read the Simplified Implementation of the SDL paper and some of the additional resources we make available on the Microsoft SDL website. The SDL 5.1 guidance may be a useful resource for organizations whose processes align with Microsoft’s processes or are looking for detailed information on how Microsoft implements the SDL practices.

What is new in the SDL 5.1 documentation?

Since this is a “dot” release, the number of updates is smaller. We have tagged each change within the paper so they can be easy discovered by searching in document for “New for SDL 5.1”, “Promoted requirement for SDL 5.1”or “Updated for SDL 5.1”). The updated content in the MSDN library includes all updates automatically.

Comments or questions? You can either leave them in the Comments section below or visit the SDL Process Forum to ask questions and discuss your own implementation of SDL security practices in your organization.

The SDL Chronicles – How an Engineering Culture Change Driven by Security Needs Paid Off

SDL Team — Fri, 01 Apr 2011 20:22:00 GMT

Hi All – Doug here…

We recently had the opportunity to get an inside look into a large company’s journey addressing a web application security incident that led to a deep analysis and change in how a development organization builds security into their software development process.

MidAmerican Energy Holdings Company is a global leader producing energy from diversified fuel sources for the U.S. and U.K. consumer markets with approximately 6.9 million electricity and gas customers worldwide. In mid-May 2008, the MidAmerican Energy website was under attack from a botnet titled banner82. Botnets are networks of compromised computers controlled by hackers known as “bot-herders” and have become a serious problem in cyberspace.

The company has a long tradition of customer service so this was a very important issue to them. They surveyed industry best practices and chose the Microsoft Security Development Lifecycle (SDL) as their preferred process for developing secure software and changing their engineering practices.

This story is captured in a new case study that takes you through the entire story of the cyber-attack and steps to resolution. Important issues show up like the need for executive support and how to get everyone onboard as MidAmerican raised security development as a central focus for their internal development group moving forward. The case study validates the need to make deep changes when necessary within the software development culture versus performing “security around the edges”. Other important insights detail how an aggressive timeline created focus and gave everyone a clear goal. The case study reports on how the company was able to significantly reduce the number of vulnerabilities and meet their security goals while setting the company up for long term success.

What we found particularly interesting was that after they went through this experience, MidAmerican was not only creating more secure applications but they also found something they hadn’t counted on. The SDL’s process requirements and the resultant engineering culture shift had brought together the entire development organization with QA in a way they hadn’t seen previously. Together they engaged in the SDL process and as a result there were fewer security bugs that were found and needed to be fixed late in the process – when it is most expensive. MidAmerican saw a real productivity gain out of their development organization, not just better application security. These ROI results mirror the key findings from the recent Forrester Consulting thought leadership paper as well as the Aberdeen Group research report. You might also want to take a look at the SDL Progress Report as it provides much of the same information that MidAmerican used to make their decision to implement the SDL.

Check out this fascinating real life story that we often don’t get to hear.

For your consideration: The SDL Progress Report

SDL Team — Wed, 30 Mar 2011 18:51:00 GMT

Hello all - Dave here...

I wanted to take a few moments to alert you to a new publication from Trustworthy Computing entitled "The SDL Progress Report." This work has been in progress for a number of months and incorporates data and analysis from various groups in our organization. We hope you find valuable information on secure development lessons learned at Microsoft, how we've applied security science, and the correlation between holistic security processes, risk reduction, and organizational efficiency.

If we have learned one prevailing truth over the years, it's that security threats aren't static - as a result, our work developing secure software and evolving the SDL to stay ahead of complex attacks will never be done. We believe our SDL tools and processes add value and should be shared broadly with the security ecosystem - a collective effort is needed to meet the threat to computer users worldwide.

The first section of the document focuses on the history of the Microsoft SDL from its earliest days -highlighting important milestones in the development of the SDL process. As we collated material for this section of the document, it wound up being an interesting history lesson; starting with Bill Gates' original TwC memo in 2002, it pinpoints the inclusion of many of the processes and technologies over time that make up the SDL as it is practiced today.

For example, some of the theoretical underpinnings of the threat modeling process (most notably STRIDE), are based on a paper written by Praerit Garg and Loren Kohnfelder in 1999. We would be remiss if we failed to include a "tip of the hat" to the security researcher community. We noticed increased use of fuzzing techniques to find vulnerabilities starting in the late '90's. In keeping with the "use what works" philosophy here, we integrated fuzzing in the early days of the SDL - we remain aggressive advocates of fuzz testing to this day.

In the second section of the document, Matt Miller did an excellent job at illustrating our ongoing commitment to security science. In addition to going into detail on some of the mitigation techniques required by the SDL, the security science section exposes some interesting data about the adoption of these techniques by a section of the ISV community.

We surveyed 41 popular applications in use worldwide to assess the use of technologies like ASLR and DEP. In addition, we did a further analysis to look at the use of these technologies in four European countries - France, Germany, Russia and the UK. I'd encourage you blog readers to take a look - the results are eye-opening. For example, ASLR usage across the sample set of 41 apps is mixed - 34% enabled full support, 46% partially enabled support and (unfortunately) 20% did not enable ASLR support in their applications. Lots of great data, lots of insightful analysis...

As mentioned above, one of the goals in writing this paper was to illustrate the point that using a holistic development process is more than just a good idea - application of security process in a holistic fashion leads not only to risk reduction, but also leads to increased organizational efficiency. Two recent studies published by Forrester Research and the Aberdeen Group lend credence to that assertion.

The Forrester Consulting thought leadership paper (Full Disclosure: a Microsoft sponsored study) concludes that end to end approaches to security reduce risk and increase ROI; and those using SDL (or SDL-like processes) report notable ROI gains relative to those organizations who don't take a coordinated approach.

In addition, Aberdeen Group (independent research) found that the average investment in holistic security processes is $400k - while the average cost to fix a critical vulnerability after application deployment, hovers around $300k per vulnerability. It requires no great intellectual feat to conclude that a deliberate approach to finding and fixing vulns pays for itself very shortly after the first critical vulnerability in a development project is found and fixed, prior to release. Finally, the companies Aberdeen surveyed reported a 4x return on annual investment for those that take a deliberate approach to achieving application security.

Two things struck me as I worked with Matt and others on the creation of this report.

First, from a defender standpoint, I believe that the days of "easy find" vulnerabilities are over. Mind you, I am not saying that there are no easy vulns still out there - I know the security researcher community will continue to find problems based on some failure of process, tooling or human error. That said, Microsoft is seeing an uptick in the number of attacks that are unique and complex. For example, the attack against IE8 at the CanSecWest "Pwn2Own" competition required exploitation of three individual vulnerabilities - and two of those had already been fixed using the SDL for IE9. It was a very innovative approach - that helps to illustrate my point. We're seeing more complex "edge cases" - not the traditional stack overflows that we were seeing five years ago.

Second, I remain convinced that "list based" approaches to security (while initially helpful) are not a good long term bet for development orgs concerned about security. Until recently, claims about the effectiveness of holistic approaches were based on anecdotal data and gut feel. I think over time, IT orgs will be confronted with the need for something more than the typical "How do I stack up against Process X?" or the latest security popularity contest. Consequently, the adoption of dynamic end to end security processes - like the SDL - that track the threat environment and adjust process and technology accordingly, will increase.

Thanks for reading - download the report and sound off about what you think!

Dave

P.S. Stay tuned for more details on how the SDL is helping real organizations with IT security challenges.

P.P.S. Follow our Twitter feed http://twitter.com/msdl for more information on SDL related releases, events and news!

Updated SAFEcode Development Practices Paper

SDL Team — Fri, 18 Feb 2011 21:28:51 GMT

Hi, Michael here.

Last week, SAFECode released a large update to the “Fundamental Practices for Secure Software Development” paper. The paper helps software development teams create more secure software.

Not only did SAFECode members overhaul the paper’s technical content, the group also added Common Weakness Enumeration (CWE) references and details about verification tools and techniques to determine if a development team is adhering to the practices.

In my opinion, the paper is unique and important in that it describes what SAFECode members are doing in practice to raise the security bar; it’s deeply pragmatic and not a theoretical or academic document.

SAFECode is also actively seeking public comment on the paper, especially in the verification sections. If you know of specific tools or techniques to help determine if a software development team is adhering to the practices, please let us know.

Attack Surface Analyzer demonstration and Q&A session: Noon Thursday @ RSA

SDL Team — Thu, 17 Feb 2011 00:48:00 GMT

Solomon Lukie here, blogging from the Microsoft booth at RSA 2011.

Last month we released a new tool, Attack Surface Analyzer BETA, for use by IT Developers during the verification phase of the SDL and for IT Departments to profile the aggregate attack surface change when deploying applications within their organization.

I’m the owner of the tool and currently at the Microsoft booth giving demonstrations and discussing usage scenarios for Attack Surface Analyzer BETA. The response has been overwhelming so I’ll be hosting a quick intro to the tool and Q&A session in the Microsoft Theatre at noon tomorrow.

If you’re in the exposition hall tomorrow drop past the Microsoft theatre, which is adjacent to the Microsoft booth and if you have your badge scanned you’ll be entered in a raffle for a Microsoft Zune or XBOX 360 Kinect bundle.

Return on Investment (ROI) and Secure Application Development: Can a holistic approach save money and increase productivity?

SDL Team — Tue, 15 Feb 2011 21:56:00 GMT

Doug Cavit here to talk about a presentation I’m giving at the RSA Conference featuring findings from a Forrester Consulting thought leadership paper we recently released.

We’re often asked, “What is the real return on investment for putting a secure application development program in place?” The conventional wisdom is that doing secure application development is more expensive than not doing it, the probability of getting hacked is low and most organizations really don’t have the time or resources to do it right. In other organizations secure development is recognized as important; but in practice, corners are cut and only a few of the activities called for in holistic security processes are actually completed. There are many examples of the failure of these philosophies in the news.

We have thought about this for quite a while now; and we’ve concluded that the Microsoft SDL process does in fact provide return on investment beyond the costs of implementation. To date though, we haven’t systematically looked outside the company to confirm our belief that holistic processes do benefit an organization’s bottom line.

We worked with Forrester Research to refine our thoughts and to test our premises with 150 Fortune 1000 companies. Forrester found that most of the companies in the study do not use a holistic security development process. However, of those that did have a process (such as the Microsoft SDL), many saw improvements in overall ROI – especially when compared with those using ad hoc solutions or “checklist” approaches.

This report gives insight into current application security development practices, exposes gaps in common processes and discusses the issues that can arise from not using a comprehensive approach to secure software development. Additionally, the report provides guidance on potential process improvements and suggests ways to measure development security ROI. The report can be found here: Forrester Consulting State of Application Security Thought Leadership Whitepaper.

At 4:10 pm on Tuesday, February 15, I’ll be exploring this topic area more in depth in the Microsoft booth at RSA. If you’re at the RSA Conference, stop by and let us know what you think!

Back to the Future: Attack Surface Analysis and Reduction

SDL Team — Mon, 14 Feb 2011 19:07:16 GMT

Hi, Michael here.

A couple weeks back we released a beta version of the Attack Surface Analyzer tool. Hopefully, you’ve downloaded and looked at it by now!

This tool is one of many tools we use as part of the SDL to help software developers make their products more secure. But we didn’t always have a tool like this; we used a collection of tools to measure various attack surface elements, such as open ports or services running by default. Clearly running lots of little tools is tedious, so we created the attack surface analyzer tool.

In the rest of this article, I’d like to spend some time explaining how we’ve refined the attack surface analysis process at Microsoft over the years.

Prior to working on the SDL, I worked on the IIS4, 5 and 6 teams and one of the items I created in 2000 was a simple checklist for web server administrators to use to lock down IIS4 and IIS5 servers. The checklist was not required for IIS6, but more on this later.

In 2002, Steve Lipner asked me how I would measure security progress in Windows .NET Server (it later became Windows Server 2003.) His question was totally open-ended, so I thought about it for a while. After a couple of days, I told him I thought that designing products as securely as possible and writing code that’s as secure as possible were lofty goals and we need to also think about not exposing features to attackers that are not commonly used. I had created some metrics that became known as the Relative Attack Surface Quotient or “RASQ.” Yes, many people tried to find ways of deriving RASCAL or RASQAL acronyms, but none succeeded!

The data elements we measured included:

· Open ports

· Named pipes

· RPC endpoints

· Null Sessions

· Installed Services

· Services running default

· Services running as SYSTEM

· IIS web directories (including sample apps)

· Users

· Etc.

Enumerating all these elements took about a dozen tools. The output of each tool was tallied to create a graph like this that showed the RASQ for each version of Windows since Windows NT4 through Windows XP. Smaller is better.

Notice the delta from “Windows NT 4 SP6a + Option Pack” to “Windows NT 4 SP6a + Option Pack + IISChk” and “Windows 2000” to “Windows 2000 + IISChk.” IISChk is the checklist I mentioned, and the “Option Pack” is IIS4. Clearly, part of a checklist’s goal is to reduce attack surface.

I think the most telling delta is from “Windows 2000 + IISChk” to “Window Server 2003.” The default install of Windows Server 2003 has a smaller attack surface than the default install of Windows 2000 after the checklist is applied. This was a watershed moment for Microsoft Windows, and the biggest change was IIS was no longer installed by default.

As the SDL started to evolve, we invented the slogan “Secure by Design, Secure by Default.” The first clause means “get the design and code secure” and the last clause means “the product will never be 100% secure, so reduce the product’s attack surface.”

Once development teams inside Microsoft saw the value of a reduced attack surface: fewer security bulletins and lower severity bulletins, it was obvious we had to streamline how we measured attack surface. So the attack surface analysis tool was born in our group. This tool is a standard tool run by all teams as part of their SDL requirements.

An important success factor to using this tool is to run it often, preferably on every build, to make sure you catch anything that might unnecessarily increase attack surface.

Next week at the RSA Conference 2011 in San Francisco, Bryan Sullivan and I will present a paper entitled, “[AND-108] Stop Exposing Yourself: Principles of Attack Surface Analysis and Reduction” that explains the process of attack surface analysis and provide guidance for reducing attack surface without annoying your customers.

So, if you’re at the conference, please stop by. Even if it’s just to say “hi!” or see a demo of the new tool.

Speaking of demos, one of the team members that created the tool, Solomon Lukie, will be at the Microsoft booth at the RSA Conference giving hands-on demos and explaining the tool’s value.

And speaking of the RSA Conference, Scott Charney, corporate vice president of Trustworthy Computing at Microsoft, will present a keynote session on Collective Defense: Collaborating to Create a Safer Internet. Scott will highlight computing trends and discuss the reality of evolving cyber threats. He will share Microsoft’s vision about how we can collectively work together to improve security protections for all Internet users. The keynote will be at 9:00 am on Tuesday, February 15, in North Hall D, Moscone Center (KEY-101).

Follow @MSFTSecurity on Twitter for news and information and @msdl for SDL info.

SDL and PCI DSS/PA-DSS: Aligning security practices and compliance activities

SDL Team — Fri, 11 Feb 2011 19:12:00 GMT

Jeremy Dallman here to introduce our second paper aligning SDL practices with compliance activities. Last year we released the SDL and HIPAA whitepaper. This time, we chose the Payment Card Industry Data Security Standards (PCI DSS) and Payment Application Data Security Standards (PA-DSS) commonly used by merchants, payment card processors, and application developers equipping those industries. These two sets of requirements create industry standards to protect how cardholder data and payment applications store, process or transmit data as part of authorization or settlement. Today, I would like to announce the release of a new whitepaper:

SDL & PCI DSS/PA-DSS: Aligning the Microsoft SDL with PCI DSS/PA-DSS Compliance Activity

Every day, consumers use electronic payment systems to complete purchases in physical stores and on the internet. These transactions must reference and store personal data. Because this data is being stored, it is crucial that it is handled securely at every point in a transaction. This involves not only the merchants and payment card processors, but the entire IT system used to support the merchants, authorize the purchases, and store the information. The risks to consumers are profound, and have resulted in new regulations - designed to ensure technology is being used correctly to protect personal information. Although the PCI DSS goes to great lengths to protect the physical and network infrastructure surrounding the payment card industry, our increasingly digitized world requires software protections as well. It is no longer enough to only rely on perimeter defenses. The process of creating more secure applications is what the Microsoft SDL is designed to address.

Recent studies have shown that organizations are spending on compliance tasks in lieu of security – however compliance and security don’t have to be at odds. As merchants and software developers are being asked to meet PCI DSS requirements, it is important to find ways to align proactive, risk-based security practices with compliance activities. We saw this need and realized that we should evaluate the application of the Microsoft SDL alongside some of these regulatory activities.

This paper shows how the Microsoft SDL can help meet some of the requirements of PCI DSS and PA-DSS. It addresses two primary scenarios—1) building new PCI DSS compliant software and 2) custom software integration (e.g. a Point of Sale system in a retail store). Each of these scenarios illustrates a common intersection between software security and PCI DSS or PA-DSS requirements. Our goal is to show where software security can both assist in attaining regulatory compliance with PCI DSS and ensure that the software created for these industries are written and deployed with security as a priority to mitigate risk, using the Microsoft SDL as a guide.

Similar to our first paper, the expected audiences for this paper are business decision-makers, compliance managers, software developers, IT consultants, and systems integrators who are working within or on behalf of organizations that must meet PCI DSS requirements. This paper is not intended to advise organizations of their legal requirements and responsibilities. It is assumed that the reader understands the laws and regulations mentioned in this paper and how those laws and regulations apply to their organization.

The paper is broken into easy-to-digest sections that we hope are both readable and practical in application:

Reading section:

· Overviews of the Microsoft SDL and both PCI DSS and PA-DSS

· A scenario-based review of SDL applicability to parts of the PCI DSS and PA-DSS

Appendix (three “rip out” tables for reference)

· One table mapping SDL Practices to the PCI DSS Requirements

· A second table mapping SDL Practices to PA-DSS Requirements

· The Simplified SDL spreadsheet for reference.

We realize that aligning security practices with compliance activities will vary across organizations; we hope this paper will ease the task of integrating secure software development activities with PCI DSS regulatory requirements.

As always, we welcome your questions and feedback.