IP: Results, Not Resolutions

[David Farber <dave () farber net>]

> http://www.securityfocus.com/news/315
>
> Results, Not Resolutions
> A guide to judging Microsoft's security progress.
> By Bruce Schneier and Adam Shostack
> Jan 24 2002 3:50AM PT


Abstract:

Last week, Bill Gates published a company-wide memo outlining a new 
strategic direction for Microsoft.

Comparing this to the change when the company embraced the Internet, Gates 
elevated security to Microsoft's highest priority.

By focusing on what he called "Trustworthy Computing," Gates plans on 
transforming Microsoft into a company that produces software that is 
available, reliable, and secure.

Trust is not something that can be handed out; it has to be earned.

And trustworthiness is a worthy goal in computing.

Our goal is to provide a list of measurable recommendations, so that the 
community can judge Microsoft's sincerity.

Complexity is the worst enemy of security, and systems that are loaded with 
features, capabilities, and options are much less secure than simple 
systems that do a few things reliably.

This has led to numerous security vulnerabilities, based on different 
pieces of the operating system using system resources differently.

The recent Universal Plug-and-Play bugs work even if you don't know what 
UPnP does, or whether or not you're using it.

Code Red successfully attacks IIS installations, even in Windows setups 
that aren't being used as a Web server.

In UNIX, for example, a Web server and an ftp server are separate, and must 
be installed separately.

We recommend that the next release of all Microsoft products have default 
installations with the most minimal feature set possible, and that 
additional features require special installation activity to make them work.

Additional controls should be implemented to allow a corporate IT 
department to prohibit certain features from being installed.

These need to be split into separate services, running on separate bits of 
server software so that a user can choose which to install where.

Much of what we discuss above (data/command separation, default 
configurations, separate software for separate protocols) has the effect of 
minimizing the impact of software bugs by reducing the amount of software 
on a computer.

If a portion of the software is critical to security, then there is no way 
to achieve trustworthiness without publication.

Our recommendations are by no means comprehensive.

There's substantially more involved in building secure software than the 
seven items we list here.

These items are intended to be near-term milestones; they're 
recommendations more about implementation than architecture.

Buffer overflows, everyone's favorite whipping boy, are a comparatively 
easy implementation-level problem to fix.

Higher-level constructs, such as implementing a scripting engine or 
securing inter-process communications, are more complicated design-level 
issues.

But if Microsoft doesn't start with the simpler stuff, they're never going 
to get to the hard stuff.

Security isn't easy, nor is it something that you can bolt onto a product 
after the fact.

Making security Microsoft's first priority will require a basic redesign of 
the way the company produces and markets software.

It will involve a difficult cultural transition inside Microsoft.

It will involve Microsoft setting aside short-term gains in order to 
achieve long-term goals.

It's a difficult goal, and we believe that Microsoft can do it.


For archives see:
http://www.interesting-people.org/archives/interesting-people/