Building Secure Software: How to Avoid Security Problems the Right Way

Even IT professionals are not completely aware of how much our society relies on the effective use of computers. For if they did, security issues would always be foremost in our minds. Nearly all of us lock the doors to our houses when we leave and yet there are problems with computers that are equivalent to leaving the door open and posting a large sign as to where the valuables are located. I am just as guilty as most others in this area, but the heavy object has finally hit me over the head, so I am now deeply involved in learning all aspects of computer security. One of the best books that I have found that explains details rather than fluffy generalities is this one. In looking through books, there were so many that used the soapbox approach, proclaiming long and loud about the need for security, but never reaching the level of the designer in showing the specific ways in which security features can be implemented. This book does that. The specific code examples illustrating many of the security features show quite clearly how it is possible to include security in the basic structure of your programs. There are those who complain that publishing details of security flaws gives people information that will allow them to become an effective black hat hacker. This is an argument that is ridiculous. A malicious user is someone with a specific state of mind, and a bit of information does not make one a criminal, just makes it slightly easier for them to engage in their criminal acts. Any law enforcement officer will tell you that to prevent crime you have to learn the many ways crimes are committed. The authors of this book show you how the black hats do their cracking. As a consequence of reading this book, I was motivated to create a series of security lessons and write a proposal for a class in computer security for the next academic year. That class recently received overwhelming departmental approval and right now, this is the text that I will use.

What makes this book so important is that the authors provide an analysis of the major problems with all software, and give a collection of techniques with which to address the recurring problems, such as buffer overflows, access control exposures, randomness flaws and other security-related defects. They do not attempt to provide specific solutions. Instead they raise an awareness of the common problems, discuss the underlying causes, and give a framework with which developers can use as the basis for developing secure software.Key points of this book that I found especially useful include:(1) Even treatment of commercial and open source software. I found this refreshing because there are two camps, Microsoft developers and open source advocates, each of which criticize the other. Yes, Microsoft has a bad reputation for security, but the open source faction has its own challenges, and the authors show the strengths and weaknesses of each in an objective manner.(2)Surprises, such as documented cases of peer reviews that failed. I am an advocate of this technique, yet a case where a flawed, two-line piece of code that was extensively reviewed by literally thousands of reviewers and readers of a technical publication slipped by without notice for a long time.(3) The ten guiding principles for software security encapsulate the essence of building secure software. This list and the discussion of each principle should be required reading for every architect, developed and QA engineer.Chapter 1 (Introduction to Software Security) and Chapter 6 (Auditing Software) give a framework for security and a methodical approach to quality assurance. These, in my opinion, are the heart of the book.In addition to software security from a developer's point of view, this book also addresses other areas that need to be closely examined in order to achieve a solid security posture. In particular I liked Chapter 14, which covers database security, especially the treatment of statistical attacks. If you're a DBA this alone will make the book worth buying because despite the most careful design of views and access controls you may still be vulnerable in surprising ways. The chapters on Client-side security and firewall issues are also filled with excellent information, as is Appendix A (Cryptography Basics).The authors have imparted the sum of their extensive experience in this book. It's up to you to take that experience and apply it. The book's accompanying website adds further value. I also recommend Writing Secure Code by Michael Howard and David Leblanc, which was written after this book, and complements it well. Both books are much-needed additions to the body of knowledge for developing secure software.

As I say in the Preface of this book, "We wouldn't have to spend so much time, money, and effort on network security if we didn't have such bad software security." We all know that security is risk management. _Building Secure Software_ takes the same risk-management approach to security that I espouse in _Secrets and Lies_. But while my recent focus is on detection and response, this book focuses on prevention. Most importantly, it focuses on prevention where it should occur: during software design._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 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.

While it may not be very cool to review your own book, this isn't really a review, it's a response to a negative criticism that got posted as a review. The main point of the review is that we don't discuss social engineering. That claim leads me to believe that the reviewer did not read the book, as we discuss social engineering to a fair bit of length, as a quick browse of the index would have shown.A thesis of the book is that security should be about risk management. Social engineering is a risk. It's not the biggest risk; insider attacks usually are (but I'd say it's often second). I'm sorry, but for the more technical audience we're trying to reach, they're not really interested in hearing endless horror stories about social engineering. The strategies for defending against them are relatively simple, and presented in our book. We don't need to devote an entire tome to it; there is lots of more technical material to discuss.Most amusingly, you shrug off the book as worthless, then recommend a book by Bruce Schneier. Did you notice that he endorses the content of the book so much that he wrote the Foreword? I doubt you even picked the book off the shelf.Reviewer, I assert you did not read the book; you simply have a grudge. I would ask you to actually read the book, be even-headed in doing so, and then ammend your review. At that point, I will remove mine.If you still don't like it, but have honest, fair criticisms, that is okay by me. I'll still remove my review. However, I refuse to be bashed for not covering material that we cover, especially when a 30 second scan of the book would have shown your claims to be meritless.

For more than 20 years security professionals have bemoaned the abysmal state of software, and why it doesn't get any better. Viega and McGraw have put together a wonderful handbook that takes a big step in helping developers build more secure and reliable software. It addresses the tough practical problems that lead to technical disasters like Nimda and Code Red. Readers learn how vulnerabilities are exploited and how to avoid having the vulnerabilities. Key topics include buffer overflows, avoiding malicious input, proper random number selection, and many more.If there were only one security book I could make required reading for every programmer in the world, this would be it.