[FYI] CRYPTO-GRAM, May 15, 2000: Computer Security: Will We Ever Learn?

["Axel H Horns" <horns@t-online.de>]

------- Forwarded message follows -------
Date sent:      	Mon, 15 May 2000 15:06:31 -0500
To:             	crypto-gram@chaparraltree.com
From:           	Bruce Schneier <schneier@counterpane.com>
Subject:        	CRYPTO-GRAM, May 15, 2000

                  CRYPTO-GRAM

                 May 15, 2000

               by Bruce Schneier
                Founder and CTO
       Counterpane Internet Security, Inc.
            schneier@counterpane.com
           http://www.counterpane.com


[...]

** *** ***** ******* *********** *************

     Computer Security: Will We Ever Learn?



If we've learned anything from the past couple of years, it's that
computer security flaws are inevitable.  Systems break,
vulnerabilities are reported in the press, and still many people put
their faith in the next product, or the next upgrade, or the next
patch.  "This time it's secure," they say.  So far, it hasn't been.

Security is a process, not a product.  Products provide some
protection, but the only way to effectively do business in an insecure
world is to put processes in place that recognize the inherent
insecurity in the products.  The trick is to reduce your risk of
exposure regardless of the products or patches.

Consider denial-of-service attacks.  DoS attacks are some of the
oldest and easiest attacks in the book.  Even so, in February 2000,
coordinated, distributed DoS attacks easily brought down several
high-traffic Web sites, including Yahoo, eBay, Amazon.com and CNN.

Consider buffer overflow attacks.  They were first talked about as
early as the 1960s -- time-sharing systems suffered from the problem
-- and were known by the security literati even earlier than that.  In
the 1970s, they were often used as a point of attack against early
networked computers.  In 1988, the Morris Worm exploited a buffer
overflow in the Unix fingerd daemon: a very public use of this type of
attack.

Today, over a decade after Morris and about 35 years after these
attacks were first discovered, you'd think the security community
would have solved the problem of security vulnerabilities based on
buffer overflows.  Think again.  Over two-thirds of all CERT
advisories in 1998 were for vulnerabilities caused by buffer
overflows.  During an average week in 1999, buffer overflow
vulnerabilities were found in the RSAREF cryptographic toolkit (oops),
HP's operating system, the Solaris operating system, Microsoft IIS 4.0
and Site Server 3.0, Windows NT, and Internet Explorer.  A recent
study named buffer overflows as the most common security problem.

Consider encryption algorithms.  Proprietary secret algorithms are
regularly published and broken.  Again and again, the marketplace
learns that proprietary secret algorithms are a bad idea.  But
companies and industries -- like Microsoft, the DVD consortium,
cellular phone providers, and so on -- continue to choose proprietary
algorithms over public, free alternatives.

Is Anyone Paying Attention?

Sadly, the answer to this question is: not really.  Or at least, there
are far fewer people paying attention than should be.  And the
enormous need for digital security products necessitates people to
design, develop and implement them.  The resultant dearth of experts
means that the percentage of people paying attention will get even
smaller.

Most products that use security are not designed by anyone with
security expertise.  Even security products are generally designed and
implemented by people who have only limited security expertise. 
Security cannot be functionality tested -- no amount of beta testing
will uncover security flaws -- so the flaws end up in fielded
products.

I'm constantly amazed by the kinds of things that break security
products.  I've seen a file encryption product with a user interface
that accidentally saves the key in the clear.  I've seen VPNs where
the telephone configuration file accidentally allows a random person
to authenticate himself to the server, or that allows one remote
client to view the files of another remote client.  There are a
zillion ways to make a product insecure, and manufacturers manage to
stumble on a lot of those ways again and again.

No one is paying attention because no one has to.

Computer security products, like software in general, have a very odd
product quality model.  It's unlike an automobile, a skyscraper, or a
box of fried chicken.  If you buy a product, and get harmed because of
a manufacturer's defect, you can sue...and you'll win.  Car-makers
can't get away with building cars that explode on impact; chicken
shops can't get away with selling buckets of fried chicken with the
odd rat mixed in.  It just wouldn't do for building contractors to say
thing like, "Whoops.  There goes another one.  Sorry.  But just wait
for Skyscraper 1.1; it'll be 100% collapse-free!"

Software is different.  It is sold without any claims whatsoever. 
Your accounts receivable database can crash, taking your company down
with it, and you have no claim against the software company.  Your
word processor can accidentally corrupt your files and you have no
recourse.  Your firewall can turn out to be completely ineffectual --
hardly better than having nothing at all -- and yet it's your fault. 
Microsoft fielded Hotmail with a bug that allowed anyone to read the
accounts of 40 or so million subscribers, password or no password, and
never bothered to apologize.

Software manufacturers don't have to produce a quality product because
there is no liability if they don't.  And the effect of this for
security products is that manufacturers don't have to produce products
that are actually secure, because no one can sue them if they make a
bunch of false claims of security.

The upshot of this is that the marketplace does not reward real 
security.  Real security is harder, slower, and more expensive, both
to design and to implement.  Since the buying public has no way to
differentiate real security from bad security, the way to win in this
marketplace is to design software that is as insecure as you can
possibly get away with.

Microsoft knows that reliable software is not cost effective. 
According to studies, 90% to 95% of all bugs are harmless.  They're
never discovered by users, and they don't affect performance.  It's
much cheaper to release buggy software and fix the 5% to 10% of bugs
people find and complain about.

Microsoft also knows that real security is not cost-effective.  They
get whacked with a new security vulnerability several times a week. 
They fix the ones they can, write misleading press releases about the
ones they can't, and wait for the press fervor to die down (which it
always does).  And six months later they issue the next software
version with new features and all sorts of new insecurities, because
users prefer cool features to security.

The only solution is to look for security processes.

There's no such thing as perfect security.  Interestingly enough,
that's not necessarily a problem.  In the U.S. alone, the credit card
industry loses $10 billion to fraud per year; neither Visa nor
MasterCard is showing any sign of going out of business.  Shoplifting
estimates in the U.S. are currently between $9.5 billion and $11
billion per year, but you never see "shrinkage" (as it is called)
cited as the cause when a store goes out of business.  Recently, I
needed to notarize a document.  That is about the stupidest security
protocol I've ever seen.  Still, it works fine for what it is.

Security does not have to be perfect, but the risks have to be 
manageable.  The credit card industry understands this.  They know how
to estimate the losses due to fraud.  Their problem is that losses
from phone credit card transactions are about five times the losses
from face-to-face transactions (when the card is present).  Losses
from Internet transactions are many times those of phone transactions,
and are the driving force behind SET.

My primary fear about cyberspace is that people don't understand the
risks, and they are putting too much faith in technology's ability to
obviate them.  Products alone cannot solve security problems.

The digital security industry is in desperate need of a perceptual
shift.  Countermeasures are sold as ways to counter threats.  Good
encryption is sold as a way to prevent eavesdropping.  A good firewall
is a way to prevent network attacks.  PKI is sold as trust management,
so you can avoid mistakenly trusting people you really don't.  And so
on.

This type of thinking is completely backward.  Security is old, older
than computers.  And the old-guard security industry thinks of
countermeasures not as ways to counter threats, but as ways to avoid
risk.  This distinction is enormous.  Avoiding threats is black and
white: either you avoid the threat, or you don't.  Avoiding risk is
continuous: there is some amount of risk you can accept, and some
amount you can't.

Security processes are how you avoid risk.  Just as businesses use the
processes of double-entry bookkeeping, internal audits, and external
audits to secure their financials, businesses need to use a series of
security processes to protect their networks.

Security processes are not a replacement for products; they're a way
of using security products effectively.  They can help mitigate the
risks.  Network security products will have flaws; processes are
necessary to catch attackers exploiting those flaws, and to fix the
flaws once they become public.  Insider attacks will occur; processes
are necessary to detect the attacks, repair the damages, and prosecute
the attackers.  Large systemwide flaws will compromise entire products
and services (think digital cell phones, Microsoft Windows NT password
protocols, or DVD); processes are necessary to recover from the
compromise and stay in business.

Here are two examples of how to focus on process in enterprise network
security:

1.  Watch for known vulnerabilities.  Most successful network-security
attacks target known vulnerabilities for which patches already exist. 
Why?  Because network administrators either didn't install the
patches, or because users reinstalled the vulnerable systems.  It's
easy to be smart about the former, but just as important to be
vigilant about the latter.  There are many ways to check for known
vulnerabilities.  Network vulnerability scanners like Netect and SATAN
test for them.  Phone scanners like PhoneSweep check for rogue modems
inside your corporation.  Other scanners look for Web site
vulnerabilities.  Use these sorts of products regularly, and pay
attention to the results.

2.  Continuously monitor your network products.  Almost everything on
your network produces a continuous stream of audit information:
firewalls, intrusion detection systems, routers, servers, printers,
etc.  Most of it is irrelevant, but some of it contains footprints
from successful attacks.  Watching it all is vital for security,
because an attack that bypassed one product might be picked up by
another.  For example, an attacker might exploit a flaw in a firewall
and bypass an IDS, but his attempts to get root access on an internal
server will appear in that server's audit logs.  If you have a process
in place to watch those logs, you'll catch the intrusion in progress.

In this newsletter and elsewhere I have written pessimistically about
the future of computer security.  The future of computers is
complexity, and complexity is anathema to security.  The only
reasonable thing to do is to reduce your risk as much as possible.  We
can't avoid threats, but we can reduce risk.

Nowhere else in society do we put so much faith in technology.  No one
has ever said, "This door lock is so effective that we don't need
police protection, or breaking-and-entering laws."  Products work to a
certain extent, but you need processes in place to leverage their
effectiveness.


A version of this essay originally appeared in the April issue of
_Information Security_ magazine.
<http://www.infosecuritymag.com/apr2000/cryptorhythms.htm>

[...]

------- End of forwarded message -------