Inside the Secure Windows Initiative

Published: January 7, 2000

By Michael Howard

The Secure Windows Initiative (SWI) is an effort within Microsoft dedicated to making Microsoft products more secure from malicious attacks. It is part of a broader security initiative that includes programs such as the Microsoft Security Response Center (MSRC) .

SWI focuses on designing, building and testing secure products using multiple vehicles: education, tools, process improvement and testing. SWI personnel are essentially a central security consulting and process improvement team for many products.

Security Education

Few developers are formally trained in building secure products; many learn about security technologies such as firewalls, encryption and authentication protocols; but knowledge of individual features does not ensure these developers will write secure code. In using a specific security technology (e.g. SSL, encryption, or Smart Card logon), the developer may feel his feature is secure. However, the technology used may not appropriate for the feature's intended usage scenario, and alternatives may need to be considered.

SWI shows development teams where security vulnerabilities, such as buffer overruns, occur in software design and code, and what makes them dangerous. In the last year, SWI trained more than 3,000 Microsoft product development team members. Education methods include the following:

• Security Review Days

• Live and on-line presentations

• Best practice documentation

• Adding security information to MSDN and the Platform SDK.

Security Review Days

A Security Review Day begins with training sessions for all product team disciplines (design, development, testing and documentation). Topics include dispelling industry misconceptions about security design, "We're secure; we use encryption," identifying how misplaced security features can backfire, and how to implement secure design throughout the planning and development process.

The training explores categories of security vulnerabilities, such as buffer overruns, stored secrets in code, bad cryptography, poor access control mechanisms, insecure function calls, and requiring that applications run with privileges they do not really need. The training team highlights problems and solutions using sample code fragments, and describes how to build test plans to identify this class of vulnerability.

After training, the team heads back to their offices to look for potential design, coding, testing and documentation security issues. They file any necessary bugs, which SWI and members of the product group then triage. The afternoon review session helps students immediately apply what they have learned.

The Security Review Day process uncovers a good portion of issues in a product. They can, however, miss complex security bugs for which a line-by-line security code review is in order. SWI regularly engages in highly focused code reviews, perhaps only analyzing 10 pages of code at a time, to look for more complex bugs.

Most Microsoft code is currently written in C and C++. Security issues are well understood in these languages. The SWI team also focuses on Web-based vulnerabilities created when developing web services and applications using the .NET Framework.

Live and On-line Presentations

Many SWI presentations, covering threat analysis (covered later in this document), coding practices and secure application configuration, are also broadcast over the corporate network. Presentations are also archived so that any Microsoft employee at any time can view them on demand.

Best Practice Documentation

If SWI spots an insecure design or coding practice, such as buffer overruns or poor ACL usage, SWI members immediately create documentation describing the problem and how to eradicate it. SWI best practice documentation currently covers RPC, DCOM, ActiveX, buffer overruns, cryptography, ACLs, random numbers, and so on. Many of these best practices will soon be available in a new Microsoft Press book, Writing Secure Code. You can find out more about this book at https://www.microsoft.com/mspress/books/5612.asp .

MSDN and Platform SDK Improvements

The primary references used by Microsoft platform developers are MSDN (msdn.microsoft.com) and the Platform SDK. SWI has begun documenting function call security issues for inclusion in MSDN and the SDK. The first offerings can be found in the latest Platform SDK and at https://msdn.microsoft.com/library/en-us/dnwxp/html/appsec.asp .

Improving the Process

SWI has initiated process improvements within many product groups, for example including security considerations in functional specification templates, so that teams will think about security early in the process.

SWI also uses threat modeling to catch security issues early in the design phase, before code is written. In our experience, teams may misuse security features; for example they may use SSL to protect data on the wire, when the real threat is accessing the Web server or database directly through other means. Historically, SWI can help a product team document about 20-40 threats during a two hour threat analysis meeting. Threat analysis is an important component in the functional specification. Teams commonly revisit their threat model at development milestones, when the product is more complete and to address the ever-changing security landscape.

SWI is critical in closing the security vulnerability response loop, becoming involved from the moment the Microsoft Security Response Center (MSRC) is notified that a security bug may have been found. Before a fix is proposed, SWI helps triage the bug to determine whether it is really a security bug, and if it is, to make sure it is addressed appropriately. Once the bug is fixed and a bulletin posted to www.microsoft.com/technet/security , SWI researches the issue to determine the origin of the bug, how it could have been prevented, and what steps are necessary to prevent it from happening again. This research flows into the security education process.

SWI also regularly monitors security vulnerabilities of other vendors' products, notifying teams within Microsoft if any issues are found. This process helps educate our developers and ensure that Microsoft code does not have similar issues.

Another critical role of SWI is to provide on-going security consulting to product groups through face-to-face meetings and email. We answer more than 50 SWI-related emails a day asking questions like, "is this code safe?", "how do I mitigate this kind of threat?", "this security bug was fixed, but I think the fix is wrong, what do you think?" and "I think this is a bad idea, comments?" All product groups know SWI is a resource they can use on a daily basis.

Tools

SWI works closely with the Microsoft Programmer Productivity Research Center (MPPRC) group within Microsoft Research to provide input for new tools that find and remove vulnerabilities in pre-release code. If a security vulnerability is found to be a code defect, the code is analyzed and added to auditing tools to prevent it from re-appearing in new code bases.

Two tools that have been produced by Microsoft Research are PREfix and PREfast. PREfix is a dynamic source code inspection tool that builds a virtual run-time environment and identifies possible errors through execution simulation. PREfix requires big hardware and deep expertise to operate. PREfast is a smaller, less complicated tool used by individual developers to verify their code before checkin. PREfast uses the intermediate output from Microsoft Visual C++ .NET to operate. PREfix was first used to improve code quality in the Windows 2000 project. New code-defect classes identified through SWI's analysis of previous bugs and MSRC security bulletins, most notably many buffer overrun cases, have been added to the PREfix test base. The potential to productize PREfast is currently being investigated.

SWI also assisted the Visual C++ .NET team in the design of the new –GS flag, which helps mitigate certain classes of buffer overruns in C and C++ code. This feature, along with PREfast, PREfix, and ongoing security education, are helping reduce the chance of exploitable buffer overruns in our code.

Testing

SWI trains development teams on how to incorporate security scenarios in their testing programs. SWI was behind the win2000test.com web site project that ran from August 1999 to October 1999. Even though the system remained uncompromised throughout the test cycle, we gained a great deal of insight into how people attempt to compromise Windows systems, and we identified and fixed several denial of service bugs. In 2001 the exercise was repeated with Windows XP.

Summary

SWI has built a deep knowledge base of the security mistakes made by software developers throughout the industry, and has turned that knowledge into many process and educational improvements to bolster the security of Microsoft products.

Michael Howard is a security program manager in the Microsoft Secure Windows Initiative.