- Shopping Bag ( 0 items )
Ships from: Woodinville, WA
Usually ships in 1-2 business days
Ships from: acton, MA
Usually ships in 1-2 business days
Security engineering requires cross-disciplinary expertise, ranging from cryptography and computer security through hardware tamper-resistance and formal methods to a knowledge of applied psychology, organizational and audit methods and the law. System engineering skills, from business process analysis through software engineering to evaluation and testing, are also important; but they are not sufficient, as they deal only with error and mischance rather than malice.
Many security systems have critical assurance requirements. Their failure may endanger human life and the environment (as with nuclear safety and control systems), do serious damage to major economic infrastructure (cash machines and other bank systems), endanger personal privacy (medical record systems), undermine the viability of whole business sectors (pay-TV), and facilitate crime (burglar and car alarms). Even the perception that a system is more vulnerable than it really is (as with paying with a credit card over the Internet) can significantly hold up economic development.
The conventional view is that while software engineering is about ensuring that certain things happen ("John can read this file"), security is about ensuring that they don't ("The Chinese government can't read this file"). Reality is much more complex. Security requirements differ greatly from one system to another. One typically needs some combination of user authentication, transaction integrity and accountability, fault-tolerance, message secrecy, and covertness. But many systems fail because their designers protect the wrong things, or protect the right things but in the wrong way. In order to see the range of security requirements that systems have to deliver, we will now take a quick look at four application areas: a bank, an air force base, a hospital, and the home. Once we have given some concrete examples of the kind of protection that security engineers are called on to provide, we will be in a position to attempt some definitions.
1.1 Example 1: A Bank
Banks operate a surprisingly large range of security-critical computer systems: The core of a bank's operations is usually a branch bookkeeping system,. This keeps customer account master files plus a number of journals that record the day's transactions. The main threat to this system is the bank's own staff; about one percent of bankers are fired each year, mostly for petty dishonesty (the average theft is only a few thousand dollars). The main defense comes from bookkeeping procedures that have evolved over centuries. For example, each debit against one account must be matched by an equal and opposite credit against another; so money can only be moved within a bank, never created or destroyed. In addition, large transfers of money might need two or three people to authorize them. There are also alarm systems that look for unusual volumes or patterns of transactions, and staff are required to take regular vacations during which they have no access to the bank's premises or systems. The public face of the bank is its automatic teller machines. Authenticating transactions based on a customer's card and personal identification number-in such a way as to defend against both outside and inside attack-is harder than it looks! There have been many local epidemics of "phantom withdrawals" when villains (or bank staff) have found and exploited loopholes in the system. Automatic teller machines are also interesting as they were the first large-scale commercial use of cryptography, and they helped establish a number of crypto standards.
Behind the scenes are a number of high-value messaging systems. These are used to move large sums of money (whether between local banks or between banks internationally); to trade in securities; to issue letters of credit and guarantees; and so on. An attack on such a system is the dream of the sophisticated white-collar criminal. The defense is a mixture of bookkeeping procedures, access controls, and cryptography.
Most bank branches stilt have a large safe or strongroom, whose burglar alarms are in constant communication with a security company's control center. Cryptography is used to prevent a robber manipulating the communications and making the alarm appear to say "all's well" when it isn't.
|About the Author|
|1||What Is Security Engineering?||3|
|9||Banking and Bookkeeping||185|
|11||Nuclear Command and Control||231|
|12||Security Printing and Seals||243|
|14||Physical Tamper Resistance||277|
|16||Electronic and Information Warfare||321|
|17||Telecom System Security||345|
|18||Network Attack and Defense||367|
|19||Protecting E-Commerce Systems||391|
|20||Copyright and Privacy Protection||413|
|23||System Evaluation and Assurance||517|
How good is all this new security technology? Unfortunately, the honest answer is "nowhere near as good as it should be." New systems are often rapidly broken, and the same elementary mistakes are repeated in one application after another. It often takes four or five attempts to get a security design right, and that is far too many.
The media regularly report security breaches on the Internet; banks fight their customers over "phantom withdrawals" from cash machines; VISA reports huge increases in the number of disputed Internet credit card transactions; satellite TV companies hound pirates who copy their smartcards; and law enforcement agencies try to stake out territory in cyberspace with laws controlling the use of encryption. Worse still, features interact. A mobile phone that calls the last number again if one of the keys is pressed by accident may be just a minor nuisance-until someone invents a machine that dispenses a can of soft drink every time its phone number is called. When all of a sudden you find 50 cans of Coke on your phone bill, who is responsible, the phone company, the handset manufacturer, or the vending machine operator? Once almost every electronic device that affects your life is connected to the Internet-which Microsoft expects to happen by 2010-what does `Internet security' mean to you, and how do you cope with it?
As well as the systems that fail, many systems just don't work well enough. Medical record systems don't let doctors share personal health information as they would like, but still don't protect it against inquisitive private eyes. Zillion-dollar military systems prevent anyone without a "top secret" clearance from getting at intelligence data, but are often designed so that almost everyone needs this clearance to do any work. Passenger ticket systems are designed to prevent customers cheating, but when trustbusters break up the railroad, they cannot stop the new rail companies cheating each other. Many of these failures could have been foreseen if designers had just a little bit more knowledge of what had been tried, and had failed, elsewhere. Security engineering is the new discipline, that is starting to emerge out of all this chaos.
Although most of the underlying technologies (cryptology, software reliability, tamper resistance, security printing, auditing, etc.) are relatively well understood, the knowledge and experience of how to apply them effectively is much scarcer. And since the move from mechanical to digital mechanisms is happening everywhere at once, there just has not been time for the lessons learned to percolate through the engineering community. Time and again, we see the same old square wheels being reinvented.
The industries that have managed the transition most capably are often those that have been able to borrow an appropriate technology from another discipline. Examples include the reuse of technology designed for military identify-friend-or-foe equipment in bank cash machines and even prepayment gas meters. So even if a security designer has serious expertise in some particular speciality-whether as a mathematician working with ciphers or a chemist developing banknote inks-it is still prudent to have an overview of the whole subject. The essence of good security engineering is understanding the potential threats to a system, then applying an appropriate mix of protective measures-both technological and organizational-to control them. Knowing what has worked, and more importantly what has failed, in other applications is a great help in developing judgment. It can also save a lot of money.
The purpose of this book is to give a solid introduction to security engineering, as we understand it at the beginning of the twenty-first century. My goal is that it works at four different levels: As a textbook that you can read from one end to the other over a few days as an introduction to the subject. The book is to be used mainly by the working IT professional who needs to learn about the subject, but it can also be used in a one-semester course in a university.
As a reference book to which you can come for an overview of the workings of some particular type of system. These systems include cash machines, taxi meters, radar jammers, anonymous medical record databases, and so on. As an introduction to the underlying technologies, such as crypto, access control, infrence control, tamper resistance, and seals. Space prevents me from going into great depth; but I provide a basic road map for each subject, plus a reading list for the curious (and a list of open research problems for the prospective graduate student).
As an original scientific contribution in which, I have tried to draw out the common principles that underlie security engineering, and the lessons that people building one kind of system should have learned from others. In the many years I have been working in security, I keep coming across these. For example, a simple attack on stream ciphers wasn't known to the people who designed a common antiaircraft fire control radar so it was easy to jam; while a trick well known to the radar community wasn't understood by banknote printers and people who design copyright marking schemes, which led to a quite general attack on most digital watermarks.
I have tried to keep this book resolutely mid-Atlantic; a security engineering book has to be, as many of the fundamental technologies are American, while many of the interesting applications are European. (This isn't surprising given the better funding of U.S. universities and research labs, and the greater diversity of nations and markets in Europe.) What's more, many of the successful European innovations-from the smartcard to the GSM mobile phone to the pay-per-view TV service-have crossed the Atlantic and now thrive in the Americas. Both the science, and the case studies, are necessary.
This book grew out of the security engineering courses I teach at Cambridge University, but I have rewritten my notes to make them self-contained and added at least as much material again. It should be useful to the established professional security manager or consultant as a first-line reference; to the computer science professor doing research in cryptology; to the working police detective trying to figure out the latest computer scam; and to policy wonks struggling with the conflicts involved in regulating cryptography and anonymity. Above all, it is aimed at Dilbert. My main audience is the working programmer or engineer who is trying to design real systems that will keep on working despite the best efforts of customers, managers, and everybody else. This book is divided into three parts.
The first looks at basic concepts, starting with the central concept of a security protocol, and going on to human-computer interface issues, access controls, cryptology, and distributed system issues. It does not assume any particular technical background other than basic computer literacy. It is based on an Introduction to Security course that I teach to second-year undergraduates.
The second part looks in much more detail at a number of important applications, such as military communications, medical record systems, cash machines, mobile phones, and pay-TV. These are used to introduce more of the advanced technologies and concepts. It also considers information security from the viewpoint of a number of different interest groups, such as companies, consumers, criminals, police, and spies. This material is drawn from my senior course on security, from research work, and from experience consulting. The third part looks at the organizational and policy issues: how computer security interacts with law, with evidence, and with corporate politics; how we can gain confidence that a system will perform as intended; and how the whole business of security engineering can best be managed. I believe that building systems that continue to perform robustly in the face of malice is one of the most important, interesting, and difficult tasks facing engineers in the twenty-first century.
Programming a computer is straightforward: keep hammering away at the problem until the computer does what it's supposed to do. Large application programs and operating systems are a lot more complicated, but the methodology is basically the same. Writing a reliable computer program is much harder, because the program needs to work even in the face of random errors and mistakes: Murphy's computer, if you will. Significant research has gone into reliable software design, and there are many mission-critical software applications that are designed to withstand Murphy's Law.
Writing a secure computer program is another matter entirely. Security involves making sure things work, not in the presence of random faults, but in the face of an intelligent and malicious adversary trying to ensure that things fail in the worst possible way at the worst possible time . . . again and again. It truly is programming Satan's computer.
Security engineering is different from any other kind of programming. It's a point I made over and over again: in my own book, Secrets and Lies, in my monthly newsletter Crypto-Gram, and in my other writings. And it's a point Ross makes in every chapter of this book. This is why, if you're doing any security engineering . . . if you're even thinking of doing any security engineering, you need to read this book. It's the first, and only, endto-end modern security design and engineering book ever written.
And it comes just in time. You can divide the history of the Internet into three waves. The first wave centered around mainframes and terminals. Computers were expensive and rare. The second wave, from about 1992 until now, centered around personal computers, browsers, and large application programs. And the third, starting now, will see the connection of all sorts of devices that are currently in proprietary networks, standalone, and non-computerized. By 2003, there will be more mobile phones connected to the Internet than computers. Within a few years we'll see many of the world's refrigerators, heart monitors, bus and train ticket dispensers, burglar alarms, and electricity meters talking IP Personal computers will be a minority player on the Internet.
Security engineering, especially in this third wave, requires you to think differently. You need to figure out not how something works, but how something can be made to not work. You have to imagine an intelligent and malicious adversary inside your system (remember Satan's computer), constantly trying new ways to subvert it. You have to consider all the ways your system can fail, most of them having nothing to do with the design itself. You have to look at everything backwards, upside down, and sideways. You have to think like an alien.
As the late great science fiction editor John W. Campbell, said: "An alien thinks as well as a human, but not like a human." Computer security is a lot like that. Ross is one of those rare people who can think like an alien, and then explain that thinking to humans. Have fun reading
Posted June 21, 2001
<P> This book does so much more than guiding the reader through the design of distributed systems. It is the most comprehensive and general definition and illustration of information security that I have ever seen in one place. This is a book that can teach you to look at the world through security glasses so to speak and that of course is a prerequisite for security engineering. It is also a good thing to be able to do if you need to evaluate security measures for quality and appropriateness. <P> The way Ross Anderson goes about this task is systematic and pedagogical. He has obviously been lecturing for many years and is both an excellent presenter and a person demonstrating a good understanding of learning curves. Both the book as a whole and the individual chapters have been constructed in such a way that the reader can give up at various points of complexity without losing the plot altogether and simply start at the beginning of the following chapter for a less deep education than if he read and understood everything but nevertheless gaining a comprehensive feel for the nature of security and how to tackle its implementation. This design also enables the book to be used either as a textbook or as a reference work. Very smart - many technical authors could learn something from observing how Ross goes about it. <P>I also like that each chapter ends with a discussion of possible research projects, literature recommendations and of course a summary. The only irritating thing is that there are too many stupid typos such as missing words, things which another read-through by the editor should have caught. An example: `...using the key in Figure 5.7, it enciphers to TB while rf enciphers to OB...' should be `...using the key in Figure 5.7, rd enciphers to TB while rf enciphers to OB...' It is fine to use typographic tricks for illustrative purposes but you must make sure they make it into print if you do. I'm certain many readers will find the chapter on cryptography difficult enough without errors. Well, next edition... <P>The book consists of three parts. The first is a quite basic intro to security concepts, protocols, human-to-computer interfaces, access control, cryptography and distributed systems. I think that perhaps Ross gets a little bit carried away in Chapter 5 on crypt - I mean, why is a proof for Fermat's little theorem included? There are no other mathematical proofs anywhere. I also think that parts of this chapter could benefit from added verbosity or perhaps a few more illustrations. Whereas in this context it is not so important how crypt primitives function internally it is of course very important how they behave as system components. Just a suggestion - no real criticism. <P>In the second part of the book the author ingeniously uses a whole range of well-known systems incorporating security to illustrate both analytical methods and security engineering fundamentals. Using this pedagogical method, moving from the concrete and well-known to the abstract and general is good engineering practice. Almost every main section contains a subsection called What Goes Wrong in which the author analyses and presents architectural and design weaknesses in everything from ATMs to nuclear systems. I find this approach incredibly valuable, not only because it teaches good engineering methodology but also because it gives the author an opportunity to present a huge number of security problems at the implementation level in a context, from which they can be lifted, cross-referenced and placed in different contexts. This method, combined with the informed and intelligent analysis is what makes this book such a brilliant generator of understanding of security, the broad and full concept. <P>Also in this part of the book there is a clear line which is not only technological but which serves to place security concepts in organisational frameworks, another very strong point in favour of this work. This leads to tWas this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.
Posted April 9, 2001
This is the book I wish had been around in the early 1980s when I started earning my living doing security engineering. Then, there were plenty books and research papers on theory, but little on the actual practice. Nowadays, the situation is still much the same. And just as bridge builders learn more from the one bridge that falls down than from the hundreds that don't, so security engineers can learn much more from studying how real systems have been built - and, especially, how they have failed. The real problems have to do with system-level concepts; they lie in understanding what your application's protection requirements really are, and how you can combine the available mechanisms intelligently to meet them. This book distills the system know-how I've learnt in years as a banker, in more years as a security consultant, and in still more years as an academic. Putting it together has been fun. It's also been a valuable research exercise: there's no better way of finding out what you don't know than trying to write down what you do. With luck, this book will serve as a snapshot of what we know - and of what we don't - at the beginning of the twenty-first century. I hope you have as much fun reading it as I had writing it!Was this review helpful? Yes NoThank you for your feedback. Report this reviewThank you, this review has been flagged.