|Author||Steven M. Bellovin|
About This E-Book
EPUB is an open, industry-standard format for e-books. However, support for EPUB
and its many features varies across reading devices and applications. Use your device or
app settings to customize the presentation to your liking. Settings that you can customize
often include font, font size, single or double column, landscape or portrait mode, and
figures that you can click or tap to enlarge. For additional information about the settings
and features on your reading device or app, visit the device manufacturer’s Web site.
Many titles include programming code or configuration examples. To optimize the
presentation of these elements, view the e-book in single-column, landscape mode and
adjust the font size to the smallest setting. In addition to presenting code and
configurations in the reflowable text format, we have included images of the code that
mimic the presentation found in the print book; therefore, where the reflowable format
may compromise the presentation of the code listing, you will see a “Click here to view
code image” link. Click the link to view the print-fidelity code image. To return to the
previous page viewed, click the Back button on your device or app.
Stopping Next Year’s Hackers
Steven M. Bellovin
New York • Boston • Indiannopolis • San Francisco
Toronto • Montreal • London • Munich • Paris • Madrid
Capetown • Sydney • Tokyo • Singapore • Mexico City
Many of the designations used by manufacturers and sellers to distinguish their products
are claimed as trademarks. Where those designations appear in this book, and the
publisher was aware of a trademark claim, the designations have been printed with initial
capital letters or in all capitals.
A complete list of sources and credits appears on pages 379–380.
The author and publisher have taken care in the preparation of this book, but make no
expressed or implied warranty of any kind and assume no responsibility for errors or
omissions. No liability is assumed for incidental or consequential damages in connection
with or arising out of the use of the information or programs contained herein.
For information about buying this title in bulk quantities, or for special sales opportunities
(which may include electronic versions; custom cover designs; and content particular to
your business, training goals, marketing focus, or branding interests), please contact our
corporate sales department at [email protected] or (800) 382-3419.
For government sales inquiries, please contact [email protected]
For questions about sales outside the United States, please contact
Visit us on the Web: informit.com/aw
Library of Congress Cataloging-in-Publication Data
Bellovin, Steven M., author.
Thinking security : stopping next year’s hackers / Steven M. Bellovin.
Includes bibliographical references and index.
ISBN 978-0-13-427754-7 (hardcover : alk. paper)
1. Computer networks—Security measures. 2. Computer security. I. Title.
Copyright © 2016 Steven M. Bellovin
All rights reserved. Printed in the United States of America. This publication is protected
by copyright, and permission must be obtained from the publisher prior to any prohibited
reproduction, storage in a retrieval system, or transmission in any form or by any means,
electronic, mechanical, photocopying, recording, or likewise. To obtain permission to use
material from this work, please submit a written request to Pearson Education, Inc.,
Permissions Department, 200 Old Tappan Road, Old Tappan, New Jersey 07675, or you
may fax your request to (201) 236-3290.
Text printed in the United States on recycled paper at RR Donnelley in Crawfordsville,
First printing, November 2015
To Diane, for many reasons and then some,
and to Rebecca and Daniel who asked me not
to write another book but no longer live at
home and hence don’t get a veto.
I Defining the Problem
1.2 Adapting to Change
1.3 Security Analysis
1.4 A Few Words on Terminology
2 Thinking About Security
2.1 The Security Mindset
2.2 Know Your Goals
2.3 Security as a Systems Problem
2.4 Thinking Like the Enemy
3 Threat Models
3.1 Who’s Your Enemy?
3.2 Classes of Attackers
3.3 Advanced Persistent Threats
3.4 What’s at Risk?
3.5 The Legacy Problem
4 Antivirus Software
4.2 The Care and Feeding of Antivirus Software
4.3 Is Antivirus Always Needed?
5 Firewalls and Intrusion Detection Systems
5.1 What Firewalls Don’t Do
5.2 A Theory of Firewalls
5.3 Intrusion Detection Systems
5.4 Intrusion Prevention Systems
5.5 Extrusion Detection
6 Cryptography and VPNs
6.1 Cryptography, the Wonder Drug
6.2 Key Distribution
6.3 Transport Encryption
6.4 Object Encryption
6.6 Protocol, Algorithm, and Key Size Recommendations
7 Passwords and Authentication
7.1 Authentication Principles
7.3 Storing Passwords: Users
7.4 Password Compromise
7.5 Forgotten Passwords
7.7 One-Time Passwords
7.8 Cryptographic Authentication
7.9 Tokens and Mobile Phones
7.10 Single-Sign-On and Federated Authentication
7.11 Storing Passwords: Servers
8 PKI: Public Key Infrastructures
8.1 What’s a Certificate?
8.2 PKI: Whom Do You Trust?
8.3 PKI versus PKI
8.4 Certificate Expiration and Revocation
9 Wireless Access
9.1 Wireless Insecurity Myths
9.2 Living Connected
9.3 Living Disconnected
9.4 Smart Phones, Tablets, Toys, and Mobile Phone Access
10 Clouds and Virtualization
10.1 Distribution and Isolation
10.2 Virtual Machines
10.4 The Cloud
10.5 Security Architecture of Cloud Providers
10.6 Cloud Computing
10.7 Cloud Storage
III Secure Operations
11 Building Secure Systems
11.1 Correct Coding
11.2 Design Issues
11.3 External Links
11.4 Trust Patterns
11.5 Legacy Systems
11.6 Structural Defenses
11.7 Security Evaluations
12 Selecting Software
12.1 The Quality Problem
12.2 Selecting Software Wisely
13 Keeping Software Up to Date
13.1 Holes and Patches
13.2 The Problem with Patches
13.3 How to Patch
14.1 Employees, Training, and Education
14.3 Social Engineering
14.5 The Human Element
15 System Administration
15.1 Sysadmins: Your Most Important Security Resource
15.2 Steering the Right Path
15.3 System Administration Tools and Infrastructure
15.4 Outsourcing System Administration
15.5 The Dark Side Is Powerful
16 Security Process
16.2 Security Policies
16.3 Logging and Reporting
16.4 Incident Response
IV The Future
17 Case Studies
17.1 A Small Medical Practice
17.2 An E-Commerce Site
17.3 A Cryptographic Weakness
17.4 The Internet of Things
18 Doing Security Properly
18.2 New Devices
18.3 New Threats
18.4 New Defenses
18.5 Thinking about Privacy
18.6 Putting It All Together
Most computer security books tell you what to do and what not to do. This one tells you
The list of security dos and don’ts is long: run antivirus software, get a firewall, lock
everything down, follow extensive checklists, encrypt everything in sight, watch
everything that goes on in your network, (especially) bring in over-priced consultants, and
so on. The results are dismaying: companies are spending a great deal on security, but we
read of massive computer-related attacks. Clearly, something is wrong.
The root of the problem is twofold: we’re protecting (and spending money on
protecting) the wrong things, and we’re hurting productivity in the process. Unlike
automobile locks, which increase a car’s functionality by enabling you to park in bad
neighborhoods, computer security tends to stop a user from doing something rather than
enabling them to go into bad neighborhoods safely. People—read that as
“employees”—want to be productive; when security measures get in their way, guess
what’s going to suffer? That’s right: security.
The solution, though of course easier said than done, is similarly twofold: protect the
right things, and make it easy for employees to do the right thing. That requires more than
checklists; it requires thought about the actual threats and technology. That’s what this
book is about: how to think about security.
Protecting the Right Things
Security starts by knowing what you’re protecting and against whom. A corollary to this is
that any security advice that doesn’t start with those two questions is wrong: you’ll spend
too much effort on the wrong things. If you’re protecting national security secrets against
foreign intelligence agencies, you probably need every defense ever invented and some
that haven’t been invented yet. You also need defenses against “the three Bs”: burglary,
bribery, and blackmail.
Many of us don’t have spies as our enemies (though news reports suggest that that may
be changing [Barrett 2015]). The typical attacker today is motivated by money; the
question you have to ask yourself is how an attacker can monetize your computers and
networks. If you work for a bank, the answer is pretty obvious; banks are, to quote the
famous line, “where the money is.” But any random computer can help the bad guys steal
from the rest of us, so we can’t let our guard down. These attacks, though, will be often
opportunistic rather than targeted. Even then, there are different gradations of risk.
There’s a corollary to this: defense is also about money. It makes no sense to spend
more money to protect an asset than you have at risk. There’s a saying that bears
remembering [Schiffman 2007]: “Amateurs worry about algorithms; pros worry about
economics.” Your goal is not to make a system penetration impossible; rather, it’s to make
it too expensive for your enemies, while not spending too much yourself.
Let’s look at passwords as a typical example. We’ve been told for more than 30 years
that weak passwords are a bad idea [Morris and Thompson 1979]. It’s absolutely true;
break-ins caused by poor password selection are very real. We’re also told never to write
down a password. However, the world has changed in many ways since 1979.
Suppose I pick a really strong password. Well, I’m not picking just one really strong
password; I’m picking many different ones, for all the different web sites I have to log in
to. There’s no way I can remember all of them; I’m certain to forget a few, so I’ll have to
resort to a password recovery mechanism. And what is that? For many web sites, they’ll
just email me the password. The security of my account, then, depends on the security of
my email, right? Not quite—there’s more.
For many people, the real threat isn’t a password guesser, it’s a keystroke logger. That
is, someone or something has surreptitiously installed some malware—some malicious
software—on their computers; this software records all of their keystrokes, especially
including passwords. Even if you have a very strong password that you have remembered,
if you ever actually type it your account will be compromised [D. Florêncio, Herley, and
Coskun 2007]. By contrast, if your password is emailed to you via a recovery mechanism
and you use copy-and-paste to enter it, you never type it and you’re safer. And your email
account? Many people have their email passwords stored by their mailers; those are never
typed, either. But if they are typed, all of the password-strength mechanisms for the
original web site are useless, because this stolen email password will let the bad guys
Password security, then, is a far more complex problem than simplistic checklists would
have us believe. You have to have good passwords, but you have to protect them in the
right way against the right threats. There is no perfect answer. Making the best choice
requires understanding the interactions, the trade-offs, and the threats. In other words, a
checklist will not suffice; you have to understand why to do things.
Doing the Right Thing
Once upon a time, back in the days of dial-up access, there was a company in Silicon
Valley that worried about security. They were worried about “war-dialers”—hackers who
dial all of the phone numbers in an exchange, looking for a modem—and passwordguessing attacks. So they did the obvious: they banned modems.
The problem with the ban was that it conflicted with the prevailing culture in Silicon
Valley, where many of the best developers are fond of working at all hours while garbed in
their pajamas or less. The developers did the obvious: they went to their local
neighborhood computer store, bought a modem for $29.95, and hooked it to their office
phone lines when they left for the day. Corporate security caught on soon enough, though,
and countered by installing a digital phone system, one for which modems were not
readily available. Getting a regular analog phone line required a signature from the vice
president in charge of signatures. All looked good, but the security folks couldn’t ban that
other indispensable adjunct to modern corporate life: the fax machine. Suddenly, a lot of
engineers needed fax lines in their offices; those requests, of course, were approved. To be
sure, those $29.95 modems could send and receive faxes; it wasn’t 100% bogus.
Everyone was happy—security was happy because they knew there were no dialin
lines, and the engineers were happy because they could log in from their hot tubs. All
went well, until a disgruntled former employee started breaking in via these poorly
protected, unofficial modems. And security was mystified, because they knew there were
Imagine, instead, if there were a centrally managed modem pool, with proper
authentication and a login list linked to the personnel department’s database. It would be
secure enough and it would foster productivity without tempting people to evade the rules.
Security: Not Too Big, Not Too Small, Just Right
These two scenarios have a lot in common. Most importantly, they show that security
decisions cannot be made in a vacuum. There’s a large human element to worry about;
security solutions that are not matched to people’s behavior, good and bad, will fail.
Another point of similarity is that the defenses are often poorly matched to the actual
threats. Strong passwords don’t protect against keystroke loggers; nevertheless, countless
users are annoyed by the necessity of complying with such rules. Worse yet, they have to
comply with many sets of rules, all subtly different. Strong passwords are more easily
forgotten, thus creating a reliance on password-recovery schemes; these are generally
much weaker than the primary authentication scheme, as Sarah Palin learned when her
email account was hacked [Zetter 2010]. The site she used went to great trouble to
develop the recovery code, to collect and store the data, and to prompt for the questions. In
a strong sense, they had to do that; people will forget passwords—but was the real flaw
reliance on strong passwords in the first place?
Similarly, the ban on modems was intended to keep out war-dialers. They ignored the
disgruntled insider attack, while at the same time they cost themselves productivity. They
also suffered the more subtle problems of buying too many modems at retail prices, and
they probably paid for too many extra phone lines.
Sometime in the next few years, your boss will read about the new Herkawat attack, and
about how some Kushghab.com software will prevent it. Should you buy their product?
How will you decide? Those, I hope, are the sorts of questions this book will help you
answer, even for attacks and product names that don’t come from a random password
1. “APG (Automated Password Generator),” http://www.adel.nursat.kz/apg/.
A Guide to the Perplexed
This book is not an introductory security text. Think of it as a graduate course, one aimed
especially at system administrators, IT managers, chief security officers, and system
architects. I assume that you know what firewalls are, and what the difference is between
symmetric and public key cryptography. You’ve probably seen the usual checklists,
perhaps achieved a (checklist-based) security certification, and obeyed most (but not all)
of their prescriptions. I won’t tell you how to avoid buffer overflows, cross-site scripting,
and SQL injection attacks; there are other books that do that. Rather, my goal is to teach
you how to think about the implications of security decisions, and how to design an
architecture that will deal with the consequences of failures. I don’t know what the Internet
will be like or what the popular services or devices will be 10 years hence; I’m quite
certain that there will be some very surprising new ones, ones that haven’t even reached
the garage or dorm room tinkering stage yet. How will you protect yourself, from them or
with them? Checklists are for when people know the right answers, but sometimes, none
have been developed yet.
Part I of this book is about mindware: how to think about the subject. Of necessity, it
includes a discussion of likely enemies. Part II discusses the basic technologies of interest,
not just security technologies like firewalls, but also the special properties (or lack thereof)
of wireless communications.
In Part III, I discuss putting it together. How do you build and operate real systems?
We’re living in an imperfect world; we need to solve our problems now.
Finally, in Part IV, I demonstrate these principles with a few case studies and offer
some very vague thoughts about the future of the field.
A Note on Link Rot
George R.R. Martin wrote [G. R. R. Martin 2000], “Valar morghulis… all men must die.”
The same seems to be true of links to web pages. I checked every URL in this book in
August 2015—but by the time you read these words, some of the links will no longer
work. Even the US Supreme Court suffers from this problem [Zittrain, Albert, and Lessig
2014]. Right now, there are no great solutions. The Wayback Machine
(https://www.archive.org) is probably your best hope.
I obviously did not invent the science of computer security, nor am I self-taught. I owe a
great debt to three giants from whom I learned a great deal: Fred Grampp of Bell Labs,
Bob Morris of the Labs and the NSA’s National Computer Security Center, and Fred
Brooks of the University of North Carolina at Chapel Hill. Grampp’s lessons on
passwords, log files, and social engineering were very valuable. Morris taught me to think
about utility when he asked someone presenting a design for a secure OS, “How do you do
backup and restore?” The speaker had no answer; was his system too secure? Morris also
taught me about the role of economics when evaluating security. Brooks taught me how to
think about software systems and made me painfully aware of the problem of buggy code.
I owe many profound thanks to the many people I imposed upon when writing this
book. In alphabetical order, they include (but of course are not limited to) Randy Bush,
Bill Cheswick, Richard Clayton, Greg Conti, Simson Garfinkel, Levi Gundert, Paul
Hoffman, Russ Housley, Maritza Johnson, Brian Kernighan, Angelos Keromytis, Brian
Krebs, Bala Krishnamurthy, Susan Landau, Fabian Monrose, Kathleen Moriarty, Kevin
Poulsen, Avi Rubin, Adam Shostack, Sal Stolfo, Rob Thomas, Win Treese, Paul van
Oorschot, and of course all of the people from Addison-Wesley with whom I have worked
on this book: John Fuller, Stephanie Geels, Julie Nahil, Melissa Panagos, Mark Taub, John
Wait, and more. Errors, of course, are mine.
Part I: Defining the Problem
Chapter 1. Introduction
“Who are you?” said the Caterpillar.
This was not an encouraging opening for a conversation. Alice replied, rather
shyly, “I hardly know, sir, just at present—at least I know who I was when I got up
this morning, but I think I must have been changed several times since then.”
“What do you mean by that?” said the Caterpillar sternly. “Explain yourself!”
“I can’t explain myself, I’m afraid, sir,” said Alice, “because I’m not myself, you
“I don’t see,” said the Caterpillar.
“I’m afraid I can’t put it more clearly,” Alice replied very politely, “for I can’t
understand it myself to begin with; and being so many different sizes in a day is
“It isn’t,” said the Caterpillar.
“Well, perhaps you haven’t found it so yet,” said Alice. …
Through the Looking-Glass, and What Alice Found There
One of the most visible aspects of the computer industry is how rapidly things change.
Four aspects of the change rate are of interest here: performance improvements
(obviously, today’s computers are much faster); capability improvements (we can do
things today that we couldn’t do even a few years ago); price; and environment (because
people and companies around us do more, we can interact with them electronically). All of
these affect security.
Recently, I received a check in the mail and deposited it by taking a picture of it with
my phone. Think of the technical security challenges the bank had to deal with to make
• They have to have very high confidence that the right person is connecting to the
• This server application has to be very robust against all sorts of attacks; it can, after
all, touch live bank accounts. In particular, it can add money to an account, based on
user input; quite conceivably, their previous online application deliberately couldn’t
do that, as a security measure.
• However—the deposit is conditional, based in part on the image of the check being
examined, by a human or by software, to verify the amount. In other words, some
sensitive part of their system has to process an enemy-supplied image file.
• They have to allow the upload of large image files, with the consequent need for
bandwidth, disk space, and more.
• My phone’s operating system has to be secure enough that rogue phone apps can’t
spy on or modify the banking transactions.
• All traffic has to be encrypted.
• The phone has to be assured of connecting to the proper destination.
• There needs to be a proper audit trail for all transactions.
• Everything must work seamlessly with the “traditional” web application (itself not
more than 15 years old, and probably a lot less), human tellers, and the legacy backend systems that may have originally been written in COBOL and entered on punch
cards for some giant mainframe, but now probably runs on a mainframe emulator on
the CTO’s tablet.
• Given all of these other changes, the entire architecture’s security characteristics
should be revisited.
Obviously, my bank and many other banks have made the necessary changes; the
application works. The system architects figured out what had to be done; the security
folks, the programmers, the network engineers, and everyone else made the necessary
The interesting question is what the internal debates looked like. Did a security person
say, “No, you can’t do that; our back-end process isn’t robust enough to accept online
deposits”? Did the user experience group have to fight with the security group about
authentication for account setup? Did the lawyers want to know how well fraudulent
transactions could be traced to a particular phone or physical location? Did the head of the
security group still try to say, “No, you can’t do it; it’s just too risky”?
Sometimes, “no” is indeed the right answer. As noted, though, capabilities and
environments change. The worst mistake one can make in the computer business is to
blithely give yesterday’s answer to today’s question. The second worst mistake, of course,
is rejecting yesterday’s answer without thinking about it. The technical and economic
constraints may be the same; alternately, the same answer may be correct for an entirely
different reason. The challenge is performing the analysis correctly.
1.2 Adapting to Change
There are many ways to deal with change and its likelihood. You can leave enough hooks
to handle all possible future contingencies; you can reject changes until you’re dragged
into the future, kicking and screaming (or go out of business); you can embrace all
changes, willy-nilly—or you can stop to do the sober, careful analysis that the problem
Planning for all contingencies is the simplest and most common option. After all,
everyone who has been in the business more than a few years knows that change will
come, and will come in unpredictable ways. There are a number of problems with this
approach. For one thing, it’s ugly and produces ugly systems. Jon Postel said it well
It’s perfectly appropriate to be upset. I thought of it in a slightly different way
—like a space that we were exploring and, in the early days, we figured out this
consistent path through the space: IP, TCP, and so on. What’s been happening over
the last few years is that the IETF is filling the rest of the space with every
alternative approach, not necessarily any better. Every possible alternative is now
being written down. And it’s not useful.
Planning for everything also produces complex and bloated systems, and while memory
and CPU are not critical resources these days, the engineering time to build, maintain, and
configure such systems is expensive and becoming more so. From a security perspective,
though, complexity is fatal. No one understands a complex system, from the architects and
programmers who design and build it to the engineers who have to configure it. A 1994
study showed that about 25% of security flaws were due to bugs in the specification, not
the code [Landwehr et al. 1994]. In other words, it’s not just a programming problem.
Author Steven M. Bellovin Isbn 9780134277547 File size 11.33MB Year 2015 Pages 400 Language English File format PDF Category Security Book Description: FacebookTwitterGoogle+TumblrDiggMySpaceShare If youre a security or network professional, you already know the dos and donts: run AV software and firewalls, lock down your systems, use encryption, watch network traffic, follow best practices, hire expensive consultants . . . but it isnt working. Youre at greater risk than ever, and even the worlds most security-focused organizations are being victimized by massive attacks. In Thinking Security, author Steven M. Bellovin provides a new way to think about security. As one of the worlds most respected security experts, Bellovin helps you gain new clarity about what youre doing and why youre doing it. He helps you understand security as a systems problem, including the role of the all-important human element, and shows you how to match your countermeasures to actual threats. Youll learn how to move beyond last years checklists at a time when technology is changing so rapidly. Youll also understand how to design security architectures that dont just prevent attacks wherever possible, but also deal with the consequences of failures. And, within the context of your coherent architecture, youll learn how to decide when to invest in a new security product and when not to. Bellovin, co-author of the best-selling Firewalls and Internet Security, caught his first hackers in 1971. Drawing on his deep experience, he shares actionable, up-to-date guidance on issues ranging from SSO and federated authentication to BYOD, virtualization, and cloud security. Perfect security is impossible. Nevertheless, its possible to build and operate security systems far more effectively. Thinking Security will help you do just that. Download (11.33MB) Network Security: Current Status and Future Directions Network Security Principles And Practices (ccie Professional Development) Network Security A Beginners Guide, Third Edition Computer Architecture and Security: Fundamentals of Designing Secure Computer Systems Enemy at the Water Cooler: True Stories of Insider Threats and Enterprise Security Management Countermeasures Load more posts