Thinking Security: Stopping Next Year’s Hackers by Steven M. Bellovin


7458846ea3b8f2b-261x361.jpeg Author Steven M. Bellovin
Isbn 9780134277547
File size 11.33MB
Year 2015
Pages 400
Language English
File format PDF
Category security



 

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. Thinking Security 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 [email protected] 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. pages cm Includes bibliographical references and index. ISBN 978-0-13-427754-7 (hardcover : alk. paper) 1. Computer networks—Security measures. 2. Computer security. I. Title. TK5105.59.B45154 2016 658.4’78—dc23 2015030719 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. ISBN-13: 978-0-13-427754-7 ISBN-10: 0-13-427754-6 Text printed in the United States on recycled paper at RR Donnelley in Crawfordsville, Indiana. 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. Contents Preface I Defining the Problem 1 Introduction 1.1 Changes 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 II Technologies 4 Antivirus Software 4.1 Characteristics 4.2 The Care and Feeding of Antivirus Software 4.3 Is Antivirus Always Needed? 4.4 Analysis 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 5.6 Analysis 6 Cryptography and VPNs 6.1 Cryptography, the Wonder Drug 6.2 Key Distribution 6.3 Transport Encryption 6.4 Object Encryption 6.5 VPNs 6.6 Protocol, Algorithm, and Key Size Recommendations 6.7 Analysis 7 Passwords and Authentication 7.1 Authentication Principles 7.2 Passwords 7.3 Storing Passwords: Users 7.4 Password Compromise 7.5 Forgotten Passwords 7.6 Biometrics 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 7.12 Analysis 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 8.5 Analysis 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 9.5 Analysis 10 Clouds and Virtualization 10.1 Distribution and Isolation 10.2 Virtual Machines 10.3 Sandboxes 10.4 The Cloud 10.5 Security Architecture of Cloud Providers 10.6 Cloud Computing 10.7 Cloud Storage 10.8 Analysis 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 People 14.1 Employees, Training, and Education 14.2 Users 14.3 Social Engineering 14.4 Usability 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.1 Planning 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.1 Obsolescence 18.2 New Devices 18.3 New Threats 18.4 New Defenses 18.5 Thinking about Privacy 18.6 Putting It All Together References Index 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 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 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 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 see.” “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 very confusing.” “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 —LEWIS CARROLL 1.1 Changes 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 that possible: • They have to have very high confidence that the right person is connecting to the account. • 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 changes. 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 demands. 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 [Comerford 1998]: 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 you’re a security or network professional, you already know the “do’s and don’ts”: run AV software and firewalls, lock down your systems, use encryption, watch network traffic, follow best practices, hire expensive consultants . . . but it isn’t working. You’re at greater risk than ever, and even the world’s 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 world’s most respected security experts, Bellovin helps you gain new clarity about what you’re doing and why you’re 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. You’ll learn how to move beyond last year’s checklists at a time when technology is changing so rapidly. You’ll also understand how to design security architectures that don’t just prevent attacks wherever possible, but also deal with the consequences of failures. And, within the context of your coherent architecture, you’ll 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, it’s 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 Beginner’s 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

Leave a Reply

Your email address will not be published. Required fields are marked *