Most of the security vulnerabilities that have been found in Windows over the last couple of years have not related to security features. For that reason, it's important that every developer understands how to build secure code. Yet it's not something that most people have had training on - it's not taught as part of most CS undergraduate courses, for instance. At Microsoft, it's been a long road over the last couple of years during which every developer has undertaken specific training on writing secure code.

Security is becoming more challenging: the time-to-exploit has been decreasing (from 331 days for Nimda to 25 days to Blaster). There is no silver bullet to ensuring security within a code base, it's something that takes a pervasive effort.

The Microsoft security framework comprises three key concepts: secure by design, secure by default and secure in deployment - known as SD3. Secure by design means security-aware features, and deliberate design to reduce vulnerabilities. Secure by default means switching off unneeded features - unless 90% of users require a feature, the goal in Windows is to switch that feature off on a clean installation. Finally, secure by deployment means creating processes and guidance to deploy secure systems, along with tools in the products to defend and update against vulnerabilities.

The SD3 approach includes a "Top 10" checklist:

  1. Build threat models: ensuring the design models potential attacks.
  2. Removing security flaws in source code: reviewing each line (against buffer overruns, for instance).
  3. Avoid new security flaws: for new code, being extra careful to prevent against flaws being introduced.
  4. Use managed code today: because it provides many intrinsic protections that can help reduce vulnerabilities.
  5. Use tools and checklists: books including Writing Secure Code, along with other patterns and practices (1 2).
  6. Turn features off: reducing attack surface by removing unneeded features that could be used in an exploit.
  7. Require minimum privilege: ensuring that even a successful exploit has limited value for compromising the machine.
  8. Add extra defensive layers: specific technologies to insulate an exploit from getting at the underlying system, as implemented in "Springboard" (see below).
  9. Be firewall and antivirus friendly: make sure that applications co-operate well with such environments.
  10. Create security guidance and documentation: giving the end-customer guidance on how to make their system more secure.

These approaches have been effective with recently released products. Subsequent to the launch of the Trustworthy Computing initiative, many products have completed full security reviews, checking each line of code for potential vulnerabilities. For instance, Windows Server 2003 had 6 vulnerabilities in the first 180 days, compared to 21 vulnerabilities over the first 180 days after the launch of Windows 2000 Server.

The aim too is to reduce the hassle of installing patches:

  • Reducing complexity: one patch experience
  • Reducing risk: better quality patches and a rollback capability for all patches
  • Reducing size: delta patching, enabling far smaller patches to download
  • Reducing downtime: doing everything possible to create patches that don't require reboots
  • Extending automation: making it easier to deploy patches using tools like Software Update Services and SMS 2003.

Windows XP SP2 and Windows Server 2003 SP1 will include some new technologies (codenamed "Springboard") to add extra defensive mechanisms - inspecting packets, enabling the NX feature in newer processors to create non-execute data pages, and to enable protection technologies by default (such as ICF). Windows XP SP2 will be in beta by the end of this year and released in the first half of 2004; Windows Server 2003 SP1 will be in beta in the first half of 2004 and released in the second half of 2004.