[FYI] (Fwd) Results, Not Resolutions

["Axel H Horns" <horns@ipjur.com>]

------- Forwarded message follows -------
Date sent:      	Fri, 15 Feb 2002 07:53:20 -0500
To:             	Digital Bearer Settlement List <dbs@philodox.com>,
	dcsb@ai.mit.edu, cryptography@wasabisystems.com, mac-crypto@vmeng.com
From:           	"R. A. Hettinga" <rah@shipwright.com>
Subject:        	Results, Not Resolutions

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


"We must lead the industry to a whole new level of Trustworthiness in
computing." - Bill Gates internal memo, 15 January 2002.

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.

I. Data/Control Path Separation


"Security models should be easy for developers to understand and build
into their applications." -Gates memo.

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

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

Implementation of Microsoft SOAP, a protocol running over HTTP
precisely so it could bypass firewalls, should be withdrawn.

II. Default Configurations


"Our products should emphasize security right out of the box." -Gates
memo.

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

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

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.

III. Separation of Protocols and Products


"As software has become ever more complex, interdependent and
interconnected, our reputation as a company has in turn become more
vulnerable." -Gates memo.

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.

IV. Building Secure Software


"So now, when we face a choice between adding features and resolving
security issues, we need to choose security." -Gates memo.

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.

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.

V. Transparency and Auditability


"If there is any way we can better protect important data and minimize
downtime, we should focus on this." -Gates memo.

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.

VI. Advance Publication of Protocols and Designs


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

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.

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

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

VII. Engaging the Community


"Compensation plans of Microsoft product engineers, such as raises and
bonuses, will also be tied to how secure their products are."
-Associated Press article on Gates memo, 15 January 2002.

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.

Conclusion


"Eventually, our software should be so fundamentally secure that
customers never even worry about it." -Gates memo.

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, Inc.


-- 
-----------------
R. A. Hettinga <mailto: rah@ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44
Farquhar Street, Boston, MA 02131 USA "... however it may deserve
respect for its usefulness and antiquity, [predicting the end of the
world] has not been found agreeable to experience." -- Edward Gibbon,
'Decline and Fall of the Roman Empire'

---------------------------------------------------------------------
The Cryptography Mailing List Unsubscribe by sending "unsubscribe
cryptography" to majordomo@wasabisystems.com
------- End of forwarded message -------


-- 
To unsubscribe, e-mail: debate-unsubscribe@lists.fitug.de
For additional commands, e-mail: debate-help@lists.fitug.de