Microsoft designed MS-DOS, Microsoft Windows 3.1, and Windows 95 as single-user operating systems whose user would own and control all of the resources on the computer. Such a system doesn’t require internal security controls that can protect one user from another because there is only one user on a system, and he or she controls everything. Windows 95 was designed to connect to corporate networks that provided shared file and printer infrastructures and to connect to the Internet as a client system, but the primary focus of security efforts was the browser—and even there, the understanding of security needs was much different from what it is today.

So Microsoft Windows NT 3.1 was the first Microsoft product for which operating system security was a significant design consideration. The core team that designed Windows NT largely came from Digital Equipment, where the team members had gained years of experience and had successfully developed large time-sharing systems used in major enterprises. They knew that any server or multiuser operating system would have to address security threats and protect one user from another, one application from another, and one process from another. In fact, many members of the Windows NT team had previously worked at Digital Equipment on a system that was targeted at a relatively high “B2” security evaluation by the United States government; they initially planned to seek B2 evaluation for Windows NT and reflected many of the security assurance requirements for B2 evaluation in the initial design of Windows NT. See the following sidebar for more information.

Although the basic design of Windows NT was structured similarly to a multiuser time-sharing system, by the time the system was widely deployed, it was used as a desktop client in applications that required a more robust operating system than Windows 95, and it was used as a file, print, or Internet server (HTTP, FTP, DNS, DHCP, etc.) system. Windows NT was designed with a high degree of modularity and consideration for security, and the resulting system was relatively secure compared to other multiuser systems of its day. However, as server applications gained in popularity, Windows NT quickly came face to face with the evolving threat environment of the Internet.

The mid-1990s saw the explosive growth of the Internet and, with it, the evolution of a new cottage industry specializing in discovering security vulnerabilities. Internet infrastructure components for UNIX, including Sendmail, BIND, and X Windows, were early targets of this industry, and Web browsers and Web servers did not lag far behind as targets. Discoveries of vulnerabilities in Netscape and Internet Explorer received wide publicity (CERT 1997). In this early stage of research into the vulnerability of Internet software, the vulnerability finders, for the most part, confined themselves to demonstrations aimed at building credibility for their security product companies or consulting practices, although there were instances of hostile attacks as early as the dawn of the commercial Internet (CERT 1994). Some security researchers chose to release “exploit code” that could be used to make use of the vulnerabilities, and in some cases, “script kiddies” took advantage of the exploit code to attack unpatched systems.

Because it became evident that discovery and disclosure of software vulnerabilities would be a continuing feature of the Internet-connected world, Microsoft took multiple steps to deal with the new realities. Prior to 1998, Microsoft had taken an ad hoc approach to dealing with discoveries of software vulnerabilities. Individual product teams handled communications with vulnerability finders. Product teams released fixes as security updates through their support organizations and on Microsoft’s Web site, and the Windows marketing organization handled questions from the press concerning the discovery of new vulnerabilities in Windows.

In mid-1998, Microsoft created its Security Response Team to centralize the process of dealing with software vulnerabilities. Early team members included Jason Garms, Scott Culp, and coauthor of this book Steve Lipner. Security researchers were encouraged to report to a single well-known e-mail address ([email protected]), security updates were made public at a single Web site (www.microsoft.com/security), and the team handled press response to security issues associated with any Microsoft product. The new team’s charter was to improve communications and relations with security researchers and communications with customers. The Security Response Team—predecessor of today’s Microsoft Security Response Center (MSRC)—was widely acknowledged to have made a significant contribution to these objectives.

In parallel with the launch of the Security Response Team, Microsoft formed an internal Security Task Force to examine the underlying causes of vulnerabilities and to plot a course that could help to reduce vulnerabilities over time. That task force’s set of recommendations forms the earliest precursor of the SDL. Viewed from a perspective seven years later, the task force’s report appears prescient. Some of its key components included these recommendations:

The Security Task Force pointed the way to the SDL, but it could not know and thus did not prescribe the level of resources or effort that would be required. Discovering how the process should work, identifying and committing the necessary resources, and coming to terms with the continuing evolution of security and threats required the next five years and launched a process that will never be static or “done.”

The Security Task Force report coincided with the final stage of fixing bugs before the release of Windows 2000. Windows 2000 incorporated a great many new security features, including the use of Kerberos as the primary authentication protocol for Windows domains, integration of smartcards for user authentication, integration of a public key infrastructure and certificate server, integration of the IETF IPSEC protocol for network authorization and encryption, and the introduction of an Encrypting File System (EFS) to protect data stored on hard drives. However, it was clear that the value of the new security features could be put in jeopardy by a growing number of vulnerability reports. The management of the Microsoft Windows division took three key steps to implement the recommendations of the report:

PREfix was Microsoft’s first static analysis tool. The PREfix-related technology was acquired when Microsoft acquired a startup company named Intrinsa. Many of the Intrinsa personnel joined the Programmer Productivity Research Center at Microsoft Research. In the late 1990s, PREfix could detect a few classes of stack-based buffer overruns by tracing the flow of input from an untrusted source to a stack buffer. Although the PREfix technology that was applied to Windows 2000 made a positive contribution and led to the removal of some classes of security vulnerabilities, it took several years of additional development—and additional discovery of new classes of vulnerabilities in a partnership between Microsoft Research and the SWI team—to evolve the tool into a highly effective one for writing more secure code. Nonetheless, the Windows 2000 experience introduced Windows developers to the notion that their code would be subject to automated analysis and that they’d be presented with automatically filed “security bugs” requiring analysis and correction.

The penetration test team was assembled of experienced Microsoft developers and testers who had shown an interest in security and talent for finding security vulnerabilities. The team reviewed the code of Windows components that they believed were security-critical or highly exposed to attack, found potential vulnerabilities, and filed bug reports to ensure that the bugs were fixed. The team was initially a small one—fewer than 10 engineers—and they developed their approaches to finding vulnerabilities as they went, based on their own experience with the security of older systems and on the lessons learned from vulnerability reports to the Security Response Team. The team established a good track record in the sense that many vulnerabilities that were externally reported against Windows NT had already been found by the penetration team, fixed in the evolving Windows 2000 code base, and scheduled for correction in an upcoming Windows NT service pack.

The initial SWI team was chartered to work with product teams by reviewing component designs and code and making recommendations (or filing bugs) that would lead to improved security. Initially, this team was even smaller than the penetration team (fewer than five members), and it was made up of Microsoft engineers with expertise in software security design and analysis as demonstrated by their accomplishments and contributions while working in Microsoft product development groups. The team’s operational concept was to move from component team to component team, meeting with developers and program managers, making recommendations, and filing bugs. The limitation of this incarnation of the SWI team is obvious in retrospect—the team was too small to review all the Windows components.

The determination by Windows division management to treat security as a ship-stopper issue constituted a visible management commitment to security. Although the processes and resources applied during the development of Windows 2000 were a significant first step in improving the security of Microsoft software, the management commitment sent a message to middle managers and individual contributors that Microsoft’s focus on security was changing and that the company was committed to improving it.

After the release of Windows 2000, the penetration team and the SWI team continued to focus on the security of the Windows code base, turning their attention to Windows XP, the next planned release. Windows 2000 was shipping to customers, and vulnerability reports continued to arrive at a growing pace as security researchers turned their attention to the new product version. It was evident that the work done before Windows 2000 shipped, although useful, did not have sufficient impact on the product’s security.

The SWI team of 2000–2001, in particular, revisited its operational concept and recognized that it was simply not going to be possible for a small team to conduct sufficient design and code reviews to materially improve the security of the next Windows release. After considering alternatives, the team made a fundamental change: SWI engineers would still be available to consult on specific security design and coding issues, but their focus would be on helping the engineers in product groups build more secure code. Instead of fishing for security vulnerabilities on behalf of the product groups, the SWI team would teach them how to fish. This change coincided with a broadening of the SWI charter to cover all “major” or enterprise Micrsosoft products, and it seemed likely to constitute a “scalable” approach to improving product security.

To implement their new approach, the SWI team focused on component team–wide “security days” or “bugbashes.” Typically, such a day would begin with two to four hours of security training, followed by the component team spending the remainder of the day or more reviewing code and conducting penetration or other security testing. The team would file bugs against vulnerabilities that had to be eliminated and areas where the component design should be made more resistant to attack. Often, the SWI team presented prizes for the “best security bug” filed during the day.

The Windows penetration team continued its code reviews, finding additional vulnerabilities and other issues and filing bugs to ensure that they were fixed. More significantly, Microsoft’s tool developers (the Programmer Productivity Research Center [PPRC]) continued to enhance PREfix to improve its ability to detect buffer overrun vulnerabilities and also developed a new tool known as PREfast, which is very effective at detecting buffer overruns in individual modules.

Note

The major difference between PREfix and PREfast is that PREfix can find errors that span multiple programs or components, whereas PREfast is especially effective at finding errors in a single program. PREfix is maintained and operated by a central team that scans an entire product code base periodically. PREfast is executed by individual developers before they check in their code. PREfast has been released as the /Analyze feature of Microsoft Visual Studio 2005.

The Windows development organization continued its commitment to addressing security vulnerabilities when found, as evidenced by the fact that the Windows XP release was delayed to address a security bug (in the handling of encryption keys) discovered late in the development process.

The second half of 2001 was not a good time for Microsoft’s reputation with respect to security issues. Mid-July saw the release of the Code Red Internet worm, which exploited a vulnerability in Windows 2000 systems running an Index Server Internet Server Application Programming Interface (ISAPI) filter within the Internet Information Services (IIS) 5 Web server component (CERT 2001a). In September, the Nimda worm exploited another vulnerability in IIS as well as a vulnerability in the Internet Explorer Web browser component (CERT 2001b). Although the vulnerabilities exploited by Code Red and Nimda had been addressed by security updates released before the worms were launched, the worms affected significant numbers of customer systems. Finally, late in the year, news of a buffer overrun vulnerability in the Universal Plug and Play (UPnP) component of Windows XP made headlines, although the vulnerability itself was never successfully exploited (CERT 2001c).

Even as the worms prowled the Internet and researchers continued to discover Windows vulnerabilities, Microsoft’s top management was working on plans to make fundamental changes in the ways that Microsoft addressed security and privacy. The Trustworthy Computing (TwC) initiative was planned as a way of mobilizing Microsoft’s staff and markedly improving the quality of Microsoft software. Trustworthy Computing was planned during late 2001 and launched with a January 2002 e-mail message from Bill Gates to all Microsoft employees (Microsoft 2002).

While Microsoft executives were working on the plans for the broad TwC effort, members of the SWI team were working with product groups to devise immediate steps that would improve the security of product versions nearing release. Microsoft’s Developer Division was nearing release of the initial version of the Microsoft .NET Framework common language runtime (CLR), and in an effort to make the release as secure as possible, division management decided to delay the release and turn all of the engineers in the division to the task of reviewing code for security vulnerabilities and conducting penetration and other security tests. This effort—the first case of an effort that would come to be known as a security push—lasted for about six weeks and ended when the rate of discovery of security vulnerabilities dropped so much that further searching was unproductive. The outcome of this work was that a number of security bugs were fixed and extra defensive methods were added to the CLR and Microsoft ASP.NET to compensate for any missed security bugs (Paul and Evans 2006). The introduction of extra defensive methods led the SWI team to formalize the notion of measuring attack surface (Attack Surface Analysis [ASA]) and to advocate Attack Surface Reduction (ASR) as a way of compensating for the fact that you can never get the code one hundred percent correct (unless the code is trivially small in size). We’ll discuss ASR in more detail in Chapter 7.

Given the experience of the .NET Framework security push, the SWI team recommended that the management of the Windows division proceed with a similar security push focused on what was known at the time as Windows .NET Server and later would be renamed Windows Server 2003. At the time, Windows Server 2003 was in beta test and relatively close to its planned release date. This security push posed significant challenges: the Windows code base was roughly ten times larger than that of the .NET Framework, and it included legacy code (unlike the .NET Framework, which was a version 1 product) and associated constraints to maintain compatibility with former Windows versions. The Windows division also employed an engineering staff more than five times as large as that of the Developer division, so even logistics for the security push posed a major challenge.

Despite the challenges, and spurred on by the TwC commitment, the Windows division proceeded with its security push. The push began with training for more than 8,000 Windows division engineers (in late January 2002). Two members of the SWI team (author Michael Howard and his colleague David LeBlanc) had recently completed the first edition of Writing Secure Code in an effort to make lessons learned by the SWI team widely available to engineers inside and outside of Microsoft, and copies of Writing Secure Code were issued to all engineers who attended the security push training (Howard and LeBlanc 2002). Once the training was completed, the engineering staff turned to a series of activities planned by the SWI team and the Windows program management organization:

The Windows security push was initially planned to take place through February 2002. As the scope of the work involved became clear, the duration of the push was extended through the end of March 2002. At the end of the push, many security bugs had been filed and many design changes were specified, including those affecting attack surface. In the following months, Windows division engineers went on to fix the bugs and code and test the design changes.

By late 2002, Windows Server 2003 was largely ready to ship. The product was in the Release Candidate stage, which involves final testing by customers and the Microsoft IT organization. Around that time, the Microsoft executive responsible for Windows Server 2003 development asked members of the SWI team how they felt about the outcome of the security push and the other work that had been done on the new release. To answer this seemingly simple question, the SWI team launched a series of actitivies, including a review of bugs that had been filed as security bugs, an evaluation of the server release in the context of externally discovered vulnerabilities affecting prior Windows versions and competing products, and penetration tests by SWI team members and outside contractors.

The activities undertaken to assess the security of Windows Server 2003 led the SWI team to the conclusion that the work of the security push had largely been successful, and that Windows Server 2003 was on track to set a new standard for Microsoft operating system security. However, in reviewing the security of the Windows Server 2003 code base, the team discovered a few new classes of vulnerabilities (which were fixed before the software was released) and found that there were a few areas of the system where additional work would produce additional security benefits. They also determined that the browser component of Windows (Internet Explorer) needed significant security work before its security would be comparable to the rest of Windows Server 2003. Because the product was a server release, browsing arbitrary Web sites was not a primary usage scenario, so the SWI team and the product team worked together to “lock down” the browser, blocking most scenarios in which vulnerabilities might occur by default. (More fundamental changes to improve the security of Internet Explorer without requiring configuration lockdown were undertaken for Windows XP Service Pack 2 and Windows Server 2003 Service Pack 1, and even more significant changes aimed at further improving security are reflected in Internet Explorer 7, the browser component of the forthcoming Windows Vista.)

In addition to the browser changes, the Windows development team changed to a new compiler that incorporated enhanced run-time detection of attempts to exploit buffer overruns. This was the second security-related compiler change for Windows Server 2003—the first was made at the time of the Windows security push. Windows Server 2003 was launched in April 2003 and has had a much better security track record than its predecessors or competing products: roughly a factor of two in reduction of security vulnerabilities rated “critical” or “important” by MSRC.

The discussions in this section have focused on the Windows security push and the activities taken to improve the security of Windows Server 2003. The initiation of Trustworthy Computing in early 2002, in fact, mobilized product groups across Microsoft and led to security pushes—and, in some cases, prerelease security reviews—for a number of products or product service packs. Key among these products were Microsoft Office 2003, SQL Server 2000 Service Pack 3, and Exchange 2000 Server Service Pack 3. In every case, the result of these efforts was improved security. In some cases, the improvements were especially dramatic. For example, Microsoft issued 16 security bulletins addressing vulnerabilities in SQL Server 2000 from its initial release in late 1999 through the release of Service Pack 3 in January 2003. In the subsequent three years, through March 2006, Microsoft issued only three security bulletins related to SQL Server 2000.

Through most of 2003, the SWI team continued to work with product groups to provide training, help organize security pushes, and conduct pre-ship reviews—originally referred to as “security audits” but now called Final Security Reviews (FSRs) to avoid confusion with financial or operational audits—on software that was close to release. These efforts were effective, and the products shipped during this period showed reduced vulnerability rates, but the process that the SWI team followed was still ad hoc. The team was guided by documents that were produced (especially by Michael Howard) at the end of the Windows Server 2003 security push, and it was guided by an “oral tradition” of effective practices and issues to watch out for. It was clear that the process was effective, but it was less clear what the process itself was!

In late 2003 and early 2004, members of the SWI team held a series of meetings with senior managers across Microsoft’s product development organizations. The focus of these meetings was to review the results achieved since the first security pushes and to revisit the requirements that would have to be met to put in place a consistent and effective security engineering process. These meetings culminated in a decision at high levels of the management at Microsoft to replace the ad hoc process of training, security pushes, and FSRs with a mandate declaring that essentially all Microsoft products must meet the requirements of a formally defined Security Development Lifecycle. The SDL mandate applies to any software that meets these criteria:

The formal definition of the SDL—which has evolved into the process described in Part II of this book—proceeded in parallel with the series of meetings that established the SDL mandate and informed senior management across Microsoft of the existence of the mandate and its implications for product groups. The formal version of the SDL was designated as SDL Version 2.0 in recognition of the fact that many product versions had undergone an earlier (and less formal) SDL process during the era of security pushes and the first FSRs.

More Info

Part II of this book, describes the SDL stage by stage—from "Chapter 5" through "Chapter 17.”

The transition to SDL Version 2.0 was completed by 1 July 2004. By that time, well over half of Microsoft’s engineering population had completed the new security training mandated by SDL, and the formal requirements for SDL compliance were posted on an internal Web site. The staffing of the SWI team grew significantly between January and June of 2004 to provide the level of effort needed to

The SWI team has continued to grow since July 2004 as the process has evolved and the requirements of implementing it have become clearer. The SWI team updates the SDL itself at six-month intervals. SDL Version 2.1 went into effect in January 2005, and Version 2.2 became effective in July 2005. SDL Version 3.0, a major revision that incorporated privacy requirements for Microsoft products, went into effect in January 2006.

This chapter has summarized the history of the SDL at Microsoft from earliest attempts to improve software security to a formally defined process that is supported by a relatively large staff and subject to regular updates. The reference to updates might prompt the reader to ask, “When will you be done?” Neither of the authors believes that the process of building secure software will ever be “done.” That’s why the SDL process includes security responses. See Chapter 14, and Chapter 16.

We expect the discovery of new ways to attack software—and new classes of vulnerabilities—to go on forever. Security researchers will continue to seek new classes of vulnerabilities at the design and implementation levels that are not addressed by current security techniques. People who try to build more secure software will continue their efforts by finding new ways to make software more resistant to attack and by developing tools and techniques that respond to new classes of attack when they are discovered. Although the people working on more secure software will make the security researchers’ and attackers’ jobs harder and will reduce the set of products and features that can be attacked, the combination of new classes of products and new classes of vulnerabilities means that the problem of making software secure will never go away.

We know that applying the techniques of the SDL can make the attacker’s job harder—the vulnerability statistics for software versions that were developed with the SDL process (and its immediate predecessors) show that. But better is not the same as perfect. We also know that new discoveries of classes of vulnerabilities will require new techniques and tools. That’s why we continue to update the SDL, and security response is an integral part of the process. We’ve written this book to give other development organizations a framework for making their software more resistant to attack and for organizing their own process to respond to the continuing challenge of software security.