Engineering Security

Abstract

Neither is it a security methodology book. Methodologies have to be general-purpose enough that they cover a wide range of circumstances and situations, which unfortunately tends to make them sufficiently vague that they’re difficult to apply for anyone who isn’t already knowledgeable in the field (this is why methodologies like Microsoft’s Security Development Lifecycle (SDL) come with a set of automated tools that look over your shoulder and tell you when you’re doing something risky, at least as far as the developers of the tools have been able to determine). The last thing we need is yet another catalogue of “best practices” for security. This book doesn’t contain a whole chapter (or chapters) on cryptography. That’s because you don’t need to understand it (do you really want to plough through thirty pages on the maths behind RSA or AES?). Understanding cryptography is what cryptographers are there for. Virtually all of the attacks on cryptography completely ignore the crypto anyway and instead attack the way that it’s used (see “What’s your Threat Model?” on page 242 for more on this). What you do need to know about cryptography is how to use it appropriately (and/or how not to use it inappropriately). There’s plenty of advice on that in this book. Another thing you may notice about this book is that there’s no mention of your favourite piece of cool security technology. In fact there’s no mention of lots of cool security technology, because there’s an awful lot of it out there and much of it will never really benefit anyone except the stockholders of the companies peddling it, if that. An example of this is quantum cryptography, a not-entirely-secure, short-range and above all extraordinarily expensive way of achieving what we’ve been doing using Diffie-Hellman key exchange since the mid-1970s. It uses physics, or magic, or something like that so it’s got to be good. There really isn’t room to cover all of these fashion-statement technologies (although I’ve made passing reference to a few in places where I wanted to illustrate something), so if you find that I’ve omitted to mention your pet technology then it’s most probably because I feel that it’s unlikely to have much, if any, effect on the bad guys, and because this book is already long enough as it is. So if that’s not what the book is about, what does it contain? As an industry, we’ve been trying to build secure systems for many decades now, particularly in the last fifteen years or so as a combination of the penetration of the Internet into everyday life and the increasing use of computerised devices and systems has enabled attacks at a scope and scale never before possible. In all of that time, we’ve gathered quite a bit of insight into what works and what doesn’t. Like Ross Anderson’s excellent book Security Engineering1 , this book talks about all of the things that conventional security books usually don’t: Stories of problems with secure (or, to be more accurate, allegedly secure) systems that turned out to be not so secure when they were exposed to attack. It also devotes quite a bit of space to discussing why some mechanisms and systems that have been proposed as solutions to various problems don’t actually solve them, and in some cases don’t really solve any problem at all (to use a phrase that comes up several times in this book, they don’t defend against anything that attackers are doing). A similar process has been followed in numerous other security-related industries, which learned from their failures by trial and error. For example bank vaults used to have square doors, which safecrackers would pry open just wide enough to pour liquid nitroglycerin (obtained by boiling sticks of dynamite) into the resulting gap, allowing them to blow the door off the vault. Banks responded by switching to close fitting round doors for which this attack didn’t work any more, in the process creating the iconic image of the bank vault with its massive round door. When safecrackers (someone a bit more sophisticated than the random outlaw with a stick of dynamite) started drilling out weak points in the safe’s door, the manufacturers responded first with hardplates, extremely wear-resistant metal plates that destroyed drill bits, and then relockers, glass plates that when broken by a drill locked the safe’s bolts into place to ensure that now the safe really couldn’t be opened any more. The same sort of evolutionary design process has occurred in many other fields. If you have quite a bit of time to kill, look at the design of artillery-shell and bomb fuses during the 20th century. The basic problem to be solved in these cases is how to design a mechanism that explodes on impact with a target but doesn’t explode on impact with a concrete floor (the development of the first proximity fuses, which detonate when they get near something, for example the gun barrel that they’re being fired from or the ship’s deck that they’ve been accidentally dropped onto, was particularly hair-raising). If you’d like an in-depth analysis of the arms race between attackers and defenders in the field of bomb fuse design, track down a copy of Major Arthur Hartley’s Unexploded Bomb — The Story of Bomb Disposal, which discusses the design of German WWII electronic fuses and the ingenuous countermeasures used to defeat them. Ironically, the most dangerous fuse type used was a WWI-era mechanical clockwork one, the type 17. Impact with the ground made this fuse sufficiently erratic that it could detonate at random whenever it felt like it. This shows, as do many of the examples presented throughout the book, that relatively unsophisticated traditional mechanisms are often more effective (or in the case of bomb fuses, dangerous) than fancy high-tech ones. A similar learning process has occurred with ATMs. Their design has evolved over the course of several decades of real-world use, leading to experience-based guidelines for attack-resistant ATM design as criminals have come up with new attacks that were never envisaged by the original ATM designers. Take two attacks that required changes to ATM designs in order to counter them. The first of these is a low-tech one called the Lebanese loop. A Lebanese loop is a strip of metal or plastic that prevents a card from being ejected from the ATM after the user has entered their PIN, which causes the ATM to abort the transaction and not issue any cash. The scammer, who’s waiting in line behind the victim, asks the victim to try re-entering their PIN, which they observe as it’s being entered. With their card apparently eaten by the ATM, the victim leaves and the scammer pulls out the loop and card and uses the PIN to empty the account. This process is labour-intensive and can be defeated by alert users. On the technical side, vendors can modify ATMs by adding sensors to the card readers to detect the use of Lebanese loops.