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