IP: Computer Security: Will We Ever Learn? Risks Digest 20.90

[Dave Farber <farber@cis.upenn.edu>]

>Date: Mon, 15 May 2000 15:06:31 -0500
>From: Bruce Schneier <schneier@counterpane.com>
>Subject: Computer Security: Will We Ever Learn? (CRYPTO-GRAM, May 15, 2000)
>
>   [From CRYPTO-GRAM, May 15, 2000, in RISKS with permission, by Bruce
>   Schneier, Counterpane Internet Security, Inc. <schneier@counterpane.com>
>   See Bruce's free Internet security newsletter: 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.
>
>Copyright (c) 2000 by Counterpane Internet Security, Inc.
>Bruce Schneier, CTO, Counterpane Internet Security, Inc.  Ph: 408-556-2401
>3031 Tisch Way, 100 Plaza East, San Jose, CA 95128       Fax: 408-556-0889
>
>   [A version of this essay originally appeared in the April issue of
>   *Information Security* magazine.
>     <http://www.infosecuritymag.com/apr2000/cryptorhythms.htm>]