Foreword
We wouldn’t have to spend so much time, money, and effort on network security if we didn’t have such bad software security. Think about the most recent security vulnerability about which you’ve read. Maybe it’s a killer packet that allows an attacker to crash some server by sending it a particular packet. Maybe it’s one of the gazillions of buffer overflows that allow an attacker to take control of a computer by sending it a particular malformed message. Maybe it’s an encryption vulnerability that allows an attacker to read an encrypted message or to fool an authentication system. These are all software issues.
Sometimes, network security can defend against these vulnerabilities. Sometimes the firewall can be set to block particular types of packets or messages, or to allow only connections from trusted sources. (Hopefully, the attacker is not already inside the firewall or employed by one of those trusted sources.) Sometimes the intrusion detection system can be set to generate an alarm if the particular vulnerability is exploited. Sometimes a managed security monitoring service can catch the exploit in progress and halt the intrusion in real time. But in all of these cases, the original fault lies with the software. It is bad software that resulted in the vulnerability in the first place.
Bad software is more common than you probably think. The average large software application ships with hundreds, if not thousands, of security-related vulnerabilities. Some of these are discovered over the years as people deploy the applications. Vendors usually patch the vulnerabilities about which they learn, and the hope is that users install the vendor-supplied patches (and that they actually work) or that the network security devices can be reconfigured to defend against the vulnerability. The rest of the software vulnerabilities remain undiscovered, possibly forever. But they’re there. And they all have the potential to be discovered and exploited.
It’s the software development system that causes bad software. Security is not something that can be bolted on at the end of a development process. It has to be designed in correctly from the beginning. Unfortunately, those who are in charge of a product’s security are not in charge of the software development process. Those who call for increased security don’t win against those who call for increased functionality. Those who champion principles of secure software design are not in charge of the software release schedule. The rallying cry of software companies is “more and faster,” not “less, slower, and more secure.”
To create secure software, developers need to understand how to design software securely. This understanding has several components. We need better education. Programmers must learn how to build security into their software design, and how to write their code securely. We need better computer languages and development tools—tools that catch common security vulnerabilities in the development process and make it easier to fix them. And most important, we need awareness: awareness of the risks, awareness of the problems, awareness of the fixes. This is not something that can happen overnight, but it is something that has to happen eventually.
Building Secure Software is a critical tool in the understanding of secure software. Viega and McGraw have done an excellent job of laying out both the theory and the practice of secure software design. Their book is useful, practical, understandable, and comprehensive. It won’t magically turn you into a software security expert, but it will make you more sensitive to software security. And the more sensitive you are to the problem, the more likely you are to work toward a solution.
We’re all counting on you, the readers—the programmers, the software architects, the software project managers—to work toward a solution. The software industry won’t, because today there’s no market incentive to produce secure software—the result of the lack of software liability. There is no market incentive to produce secure software because software manufacturers risk nothing when their products are insecure. The software industry has proved, product after product, that you can produce vulnerability-laden software and still gain market share. If automobile manufacturers were immune from product liability, I would be able to buy a motorcycle with a nitrous oxide injector spliced into my fuel line. I would be able to push the acceleration faster than the brakes could handle. I would be able to have any performance features that the manufacturers could build, regardless of the consequences. But I can’t, because the motorcycle manufacturers would face lawsuits for marketing an unsafe product.
There are no similar lawsuits in software. Look at a shrink-wrap license from a piece of software you’ve just purchased (or even from one you’ve helped write). That software is sold “as is,” with no guarantees of any kind. There’s no guarantee that the software functions as advertised, let alone that it is secure or reliable. There’s no guarantee that it won’t crash your entire network immediately on installation. In fact, the software vendor is explicitly absolved of any liability if it does.
For years I have preached that computer security, like all security, needs to be thought of in terms of risk management. We cannot avoid the threats through some magical application of technologies and procedures. We need to manage the risks. In this way, cyberspace is no different from the real world. People have been trying to solve security problems for more than 4,000 years, and there are still no technologies that allow someone to avoid the threats of burglary, kidnapping, or murder. The best we can do is to manage the risks. Why should cyberspace be any different?
Building Secure Software takes this risk management approach to security. Although my recent focus is on detection and response, this book focuses on prevention. Most important, it focuses on prevention where it should occur: during software design. The book begins by setting expectations properly. The first few chapters discuss the importance of treating software security as risk management, and introduce the idea of making technical tradeoffs with both security and the end goal (software that works) firmly in mind. Chapters 5 and 6 get to the heart of secure design, providing ten guiding principles for building secure software, and describing how to audit software. Then things get technical. The balance of the book is devoted to the bits and bytes of software security, with deep coverage of everything from the pernicious buffer overflow to problems developers face coping with firewalls.
Software security has a long way to go. We need not only to learn how to do it, we also need to realize that it is important to do it. The fact that you have this book in your hands is a step in the right direction. Read it; learn from it. And then put its lessons into practice.
We’re all counting on you.
Bruce Schneier
Founder and CTO
Counterpane Internet Security
http://www.counterpane.com