Preface
Most computer security books tell you what to do and what not to do. This one tells you why.
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 recover it.
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 password-guessing 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 no modems.
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 generator.1
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.
Acknowledgments
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.
—Steve Bellovin
https://www.cs.columbia.edu/~smb