Bloomberg Anywhere Remote Login Bloomberg Terminal Demo Request


Connecting decision makers to a dynamic network of information, people and ideas, Bloomberg quickly and accurately delivers business and financial information, news and insight around the world.


Financial Products

Enterprise Products


Customer Support

  • Americas

    +1 212 318 2000

  • Europe, Middle East, & Africa

    +44 20 7330 7500

  • Asia Pacific

    +65 6212 1000


Industry Products

Media Services

Follow Us

Bloomberg Customers


Results, not Resolutions

By Bruce Schneier and Adam Shostack 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. But unlike performance goals

or feature lists, progress toward it is hard to measure. How can we

determine if one piece of software is more secure than another? Or offers

better data integrity than another? Or is less likely to contain

undiscovered vulnerabilities? How do we know if Microsoft is really

committed to security, or if this is just another performance for the press

and public? It's not as easy as measuring clock speeds or comparing

feature lists; security problems often don't show up in beta tests.

As longtime security experts, we'd like to suggest some concrete ways to

evaluate Microsoft's (and anybody else's) progress towards trustworthiness.

These are specific and measurable changes that we would like Microsoft to

make. This is not intended to be an exhaustive list: building secure

software requires much more than what we delineate here. Our goal is to

provide a list of measurable recommendations, so that the community can

judge Microsoft's sincerity.

Some of our recommendations are easier to implement than others, but if

Microsoft is serious about security and wants to take a true leadership

position, they can't shirk any of them. Some of our changes are easier to

verify than others, but it is our goal that all of them be independently

measurable. In the end, the pronouncements and press releases don't mean a

thing. In security, what matters are results.

If we can distill our recommendations into a single paradigm, it's one of

simplicity. 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. Clearly Windows is, and

always will be, a complex operating system. But there are things Microsoft

can do to make even that complex system simpler and more secure. Microsoft

must focus its programmers on designing secure software, on building things

right the first time.


One of the simplest, strongest, and safest models is to enforce a rigid

separation of data and code. The commingling of data and code is

responsible for a great many security problems, and Microsoft has been the

Internet's worst offender.

Here's one example: Originally, e-mail was text only, and e-mail viruses

were impossible. Microsoft changed that by having its mail clients

automatically execute commands embedded in e-mail. This paved the way for

e-mail viruses, like Melissa and LoveBug, that automatically spread to

people in the victims' address books. Microsoft must reverse the security

damage by removing this functionality from its e-mail clients, and from many

other of its products. This rigid separation of data from code needs to be

applied to all products.

Microsoft has compounded the problem by blurring the distinction between the

desktop and the Internet. This has led to numerous security

vulnerabilities, based on different pieces of the operating system using

system resources differently. Microsoft should revisit these design


We recommend the following modifications in the next release of these

Microsoft products. In short: illustrate the actions, and provide a

sandbox environment. This release should be focused only on removing

insecure features and adding security.

Office: Macros should not be stored in Office documents. Macros should be

stored separately, as templates, which should not be openable as documents.

The programs should provide a visual interface that walks the user through

what the macros do, and should provide limitations of what macros not

signed by a corporate IT department can do.

Internet Explorer: IE should support a complete separation of data and

control. Java and JavaScript should be modified so they cannot use

external programs in arbitrary ways. ActiveX should eliminate all controls

that are marked "safe for scripting."

E-mail: E-mail applications should not support scripting. (At the very

least, they should stop supporting it by default.) E-mail scripts should

be attached as a separate MIME attachment. There should be limitations of

what macros not signed by a corporate IT department can do.

.NET: .NET should have a clear dilineation of what can act and what cannot.

The security community has learned a lot about mobile code security from

Java. Mobile code is very dangerous, but it's here to stay. For mobile

code to survive, it should be redesigned with security as a primary


Implementation of Microsoft SOAP, a protocol running over HTTP precisely so

it could bypass firewalls, should be withdrawn.

II. Default Configurations

Microsoft software, by default, installs with many more features than most

users need or want. This makes the software more vulnerable than

necessary. There are many recent examples of this. 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. The SuperCookie bug in Windows Media Player works

even if you don't use WMP. Code Red successfully attacks IIS

installations, even in Windows setups that aren't being used as a Web


"Our products should emphasize security right out of the

box." -Gates memo.

Additionally, features must be installable one by one. In UNIX, for

example, a Web server and an ftp server are separate, and must be installed

separately. With IIS, installing a Web server not only installs a Web

server, but also an ftp server, a Gopher server, and Bill himself probably

doesn't know what else.

It's not enough to give users the ability to turn off unneeded features.

Users don't even know which features are turned on, much less how to turn

them off, and the features might accidentally get turned on again. The

best prevention for attacks against a feature is for the feature not to be


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. We also recommend that this installation be visible to the user, so

that the user knows the features are there. We recommend that Microsoft

ensure that all features can be installed and uninstalled separately, as

well as in common packages. We recommend that unneeded features not be

installed, instead of being installed and disabled. Additional controls

should be implemented to allow a corporate IT department to prohibit

certain features from being installed.

We also recommend that .NET come with the ability to use configurations from

a variety of sources, including Microsoft, its competitors, and public

interest/advocacy groups like the Electronic Frontier Foundation.


Today Microsoft builds large, complex services that intermingle many smaller

services. For example, the Microsoft file-sharing protocol contains file

sharing, registry sharing, remote editing, printer sharing, password

management, and a host of other services. If a user wants one of those

services, he has to implement them all.

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. Absent

that, the complexity of the software grows to demonstrably insecure levels.

We recommend that Microsoft separate functionality so that the user can

install only the specific functions they need. We also recommend that

Microsoft provide, and allow others to provide, a variety of pre-bundled

functions. Most users don't want to install individual functions, and will

rely on others to tell them what they need.


Commercial software is full of bugs, and some of those bugs harbor security

vulnerabilities. This is not meant to excuse Microsoft's long-standing

apathy towards security; it's merely a statement of fact. These bugs are

caused by bad software specification, design, and implementation.

"So now, when we face a choice between adding features and

resolving security issues, we need to choose security." -Gates


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. However, there will still be a great deal of software on any

computer, and that software needs to be resilient to attack. This means

that the software doesn't easily break when attacked. And if it does

break, the system as a whole doesn't fall apart. Today, we can worry that

a single bug in Windows will render a server completely insecure, or a

single bug in IIS will expose all the data in .NET. Today Microsoft

software is brittle; it needs to be resilient.

There is much Microsoft can do to make its software more resilient, and our

recommendations could go on for pages. But generally speaking, certain

features are more fragile than others. We recommend the following:

Microsoft should drop all plans for automatic software updates via the

Internet until they can be done securely and reliably. Today there are too

many problems with updates and patches to allow them to occur without the

user's knowledge, and too many problems with authentication to prevent

others from maliciously using the capability to attack systems.

Microsoft should eliminate all centralized customer databases in its .NET

services. These databases are too dangerous to keep in one place; the

ramifications of a security breach are too great.

Microsoft is already moving towards signing code files. While we recommend

that Microsoft continue this practice, we also recommend that Microsoft not

rely on code signing for security. Signed code does not equal trustworthy

code, something the security community graphically demonstrated through the

many ActiveX vulnerabilities. Microsoft should drop the code-signing

security paradigm in favor of the sandbox paradigm.

Today, too many Microsoft server components run as Administrator. When a

service runs as Administrator, it is much easier for a security flaw to

result in the machine being fully compromised. Under UNIX, servers are

often designed to run as a normal user. This should be the default

configuration for Microsoft servers as well.

All other Microsoft features should be evaluated for resilience. Those that

are too risky should be removed until they can be rewritten and secured.


Too much of the Microsoft operating system operates invisibly, without the

user's knowledge. Too much of it functions without leaving audit records

of what happened. With each successive version of the Microsoft operating

system, it has become increasingly difficult for a user to control his own

system or to examine what his system is doing. This has disastrous

security ramifications, and should be reversed.

We recommend that Microsoft add strong auditing capabilities to all

products, both operating systems and applications software. We recommend

that Microsoft provide configuration tools along with its operating system,

as well as tools for an IT department to manage the configurations of its

computers. We would also like to see Microsoft abandon the Registry in

favor of a less opaque and more user-friendly system.


If there's one thing that security experts have learned over the years, it's

that any system, when initially proposed, will have security bugs. The

only reliable remedy is to publish system details early, and let the

security community examine them.

"There are many changes Microsoft needs to make as a company to

ensure and keep our customers' trust at every level-from the way we develop

software, to our support efforts, to our operational and business

practices." -Gates memo.

Microsoft needs to publish specifications for protocols in advance and

encourage public comment. This is doubly important for security protocols

and systems. If a portion of the software is critical to security, then

there is no way to achieve trustworthiness without publication.

Publication does not ensure security, but it's an unavoidable step in the


We're not suggesting that Microsoft must give up all proprietary rights to

its protocols and interfaces, or allow anyone to implement or use its

standards. We are saying that they must be public, not secret.

The published specifications must be complete, readable, and generally

available. It's not sufficient to make the specifications available to

specific researchers, or to people who have signed non-disclosures or paid

for the privilege. Again, this is not easy from a business point of view,

but if Microsoft is serious about putting security first, it needs to

engage rather than ignore the security community. And Microsoft should wait

before implementing those specifications in products

We recommend that all protocols and interfaces used in Microsoft software be

immediately published, and a one-year moratorium be placed on all

non-security modifications to those protocols. We also recommend that

Microsoft publish any new protocols or interfaces at least one year before

implementing them in products.

In addition to making its protocols and interfaces public, we suggest that

Microsoft consider making its entire source code public. We're not

advocating that Microsoft make its products open source, but if they really

want to impress everyone about their newfound security religion, they will

make their code available for inspection. Honestly, we don't expect

Microsoft will do this. It's too much of a cultural change for them to even



Tying security to compensation is the best way to effect a cultural change

inside Microsoft. We feel that Microsoft needs to go further, and reward

not only Microsoft employees but independent researchers. Microsoft can no

longer threaten, insult, or belittle independent researchers who find

vulnerabilities in their products.

Microsoft needs both automated security reviews and evaluations by security

experts. A great deal of work in this area has already been done outside

Microsoft. We recommend that Microsoft devote resources towards

comprehensive security reviews for all of its code, using security experts

both inside and outside the company. We also recommend that Microsoft set

up an independent body to evaluate security vulnerabilities found by

researchers outside the company.


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. We hope that they remain committed. Bruce Schneier is Chief Technology Officer of Counterpane Internet

Security Inc. Adam Shostack is Director of Technology at Zero-Knowledge Systems,


blog comments powered by Disqus