Why I Wrote Thinking Security
I have a new book out, Thinking Security: Stopping Next Year’s Hackers. There are lots of security books out there today; why did I think another was needed?
Two wellsprings nourished my muse. (The desire for that sort of poetic imagery was not among them.) The first was a deep-rooted dissatisfaction with common security advice. This common "wisdom"—I use the word advisedly—often seemed to be outdated. Yes, it was the distillation of years of conventional wisdom, but that was precisely the problem: the world has changed; the advice hasn’t.
Consider, for example, passwords (and that specifically was the other source of my discomfort). We all know what to do: pick strong passwords, don’t reuse them, don’t write them down, etc. That all seems like very sound advice—but it comes from a 1979 paper by Morris and Thompson. The world was very different then. Many people were still using hard-copy, electromechanical terminals, people had very few logins, and neither defenders nor attackers had much in the way of computational power. None of that is true today. Maybe the advice was still sound, or maybe it wasn’t, but very few people seemed to be questioning it. In fact, the requirement was embedded in very static checklists that sites were expected to follow.
Suppose that passwords are in fact terminally insecure. What the alternative? The usual answer is some form of two-factor authentication. Is that secure? Or is two-factor authentication subject to its own problems? If it’s secure today, will it remain secure tomorrow? Computer technology is an extremely dynamic field; not only does the technology change, the applications and the threats change as well. Let’s put it like this—why should you expect the answers to any of these questions to remain the same?
The only solution, I concluded, was to go back to first principles. What were the fundamental assumptions behind security? It turns out that for passwords, the main reason you need strong passwords is if a site’s password database is compromised. In other words, a guessed password is the second failure; if the first could be avoided, the second isn’t an issue. But if a site can’t protect a password file, can it protect some other sort of authentication database? That doesn’t seem likely. What does that mean for the security of other forms of authentication?
Threats also change. 21 years ago, when Bill Cheswick and I wrote
Firewalls and Internet Security,
no one was sending phishing emails to collect bank account passwords.
Of course, there were no online banks then (there was barely a Web),
but that’s precisely the point. I eventually concluded that threats
could be mapped along two axes, how skilled the attacker was and how
much your site was being targeted:
Your defenses have to vary. Enterprise-scale
firewalls are useful against unskilled
joy hackers, they’re only a speed bump to intelligence agencies, and
targeted attacks are often launched by insiders who are, by definition,
on the inside. Special-purpose internal firewalls, though, can be
very useful.
All of this and more went into Thinking Security. It’s an advanced book, not a collection of checklists. I do give some advice based on today’s technologies and threats, but I show what assumptions that advice is based on, and what sorts of changes would lead it to change. I assume you already know what an encryption algorithm is, so I concentrate on what encryption is and isn’t good for. The main focus is how to think about the problem. I’m morally certain that right now, someone in Silicon Valley or Tel Aviv or Hyderabad or Beijing or Accra or somewhere is devising something that 10 years from now, we’ll find indispensable, but will have as profound an effect on security as today’s smartphones have had. (By the way—the iPhone is only about 8 years old, but few people in high-tech can imagine life without it or an Android phone. What’s next?) How will we cope?
That’s why I wrote this new book. Threats aren’t static, so our defenses and our thought processes can’t be, either.
