Chapter 1: Code Quality


Overview

Code quality–and security is a subset of quality–is critically important in the field of software. In fact, nothing is more important than code quality, with the possible exception of good design. In Windows Vista we spent a great deal of time reducing the chance that developers will inject new security bugs into the operating system, as well as finding bugs and removing them from the codebase.

With that said, getting the code and design 100 percent secure is impossible because security is a constant arms race between software developers and attackers. All you can strive for is to raise the security bar as far as possible in your code and to continue to do so as you create new code. And this is why other defenses are so important: there will always be design and code security bugs, but defenses can often eliminate a bug or reduce the chance that an attack will be successful. This chapter focuses on getting the code right; it does not discuss design-level issues that can be found through threat modeling. A good reference for the present threat modeling state of the art can be found in The Security Development Lifecycle (Howard and Lipner 2006).

The security engineering effort in Windows Vista is simply astronomical, and you can implement many of the process changes we made to Windows Vista within your own organization. This chapter outlines what we did (a) to help reduce the chance that developers will add new security bugs to the code and (b) to find existing bugs.

Note 

This chapter does not focus on defensive features available in Windows Vista; rather, it outlines some of the process improvements and code changes we made to the operating system.

Two of the major tasks undertaken in Windows Vista were removing banned application programming interfaces (APIs) and adding Standard Annotation Language (SAL) annotations to C functions and C++ methods. Both these tasks, explained later in this chapter, proved very effective at finding and removing security bugs. An analysis of 63 buffer-related security bugs that did not affect Windows Vista–but that did affect Windows 2000, Windows XP, or Windows Server 2003–discovered the following:

  • Code annotated with SAL caught 27 (43 percent) of the bugs.

  • Code that used banned APIs accounted for 26 (41 percent) of the bugs.

    image from book
    Figure 1-1: Chart of bugs prevented in Windows Vista because of banned API removal and SAL annotation.

In other words, the combination of SAL and banned API removal alone meant 84 percent of the buffer-related security bugs found in versions of Windows prior to Windows Vista did not affect Windows Vista because the bug was found via SAL or the problem was solved because the banned API was removed and replaced with a safer function. Of course, classes of bugs exist that will not be prevented through the use of SAL and banned API removal.

Stop and think about these figures for moment. Removing banned APIs is pretty straightforward and adding SAL annotations is not particularly complex, yet doing these two tasks found or prevented 52 out of 63 bugs! I think by any measure this is a great example of “bang for the buck!” One bug was prevented because of banned API removal and SAL annotation, which indicates that to be effective, you must perform both tasks on your code.

This chapter starts with a brief explanation of the Windows Vista Quality Gates and then continues by describing the security requirements required by the quality gates.



Writing Secure Code for Windows Vista
Writing Secure Code for Windows Vista (Best Practices (Microsoft))
ISBN: 0735623937
EAN: 2147483647
Year: 2004
Pages: 122

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net