Customer Reviews

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

5 star:		(17)
4 star:		(1)
3 star:		(4)
2 star:		(1)
1 star:		(2)

 

 

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.

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.

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.

Viega and McGraw have finally written the book that the technical
community has been clamoring for. This is a refershing view of how to
build secure systems from two of the world's leading experts. Their risk
management approach to security is a central theme throughout the book.
Whether it's avoiding buffer overflows in your code, or understanding
component integration and interaction, this book offers readers a
comprehensive, hype-free guide. The authors demonstrate that
understanding and managing risks is an important component to any
systems project. This well written book is a must read for anyone
interested in designing, building, or managing systems.

This is a thoughtful and well written approach to application security that anyone involved with application security from web application designers to security architects should digest and re-digest regularly. John Viega avoids the sensationalist tactical approach of many security books and focuses on what matters in the real world. To use an analogy "if you think you may have cancer, you need to be taking blood tests and x-rays, not seeing if you have dilated pupils !". This is the surgeons general approach to preventing cancer !

As a Windows developer, I am little disappointed. The authors have probably much more experience with developing Unix and Java software that Windows software. This wouldn't be necessarily a bad thing, if they did their homework and check things with a Windows expert. But they didn't. The result is that the book contains some incorrect and misleading information in Windows-related sections. For example:

1. In the footnote on page 56 authors state, that there are "no DCOM implementations for the UNIX world". Not true - there is at least one popular DCOM implementation for UNIX - EntireX from Software AG.
2. On page 58 authors say, that delegation of identity is not available for DCOM. Wrong - delegation with unlimited number of identity transfers is a standard feature of Windows 2000 and XP.
3. On page 382 authors claim that Microsoft SQL server does not support encryption. Again not true - SQL 2000 can use either SSL or standard Windows RPC encryption to encrypt all traffic between the client and the server.

These kind of mistakes almost make you wonder if they were intentional. Anyway, if you are developing on Unix it is probably a good book (I cannot judge - I'm not an UNIX expert). If you are a Windows developer, you should probably treat it more as a general overview of potential software security problems and not rely on it when it comes to details.

This subject of this book isn't written about often enough. Where are the vulnerabilites? Think about that question... They are in the software! This is an area of security that is not adressed often enough. I consider this book essential reading for anyone in the IT security arena. This is the first book of its kind.

The first 6 chapters can be read and understood by programmers and managment alike. The first 6 chapters should be required reading for any security professional or manager. They discuss software engineering and how vulnerabilities creep into the software.

The remainder of the book is geared towards secure coding technques. The techniques discussed can be applied to any language and many are discussed. Much is geared towards C however. There are sections on inherently vulnerable functions and input validation. Also of interest are sections on the implementation of PRNG and crypto.

All of the helpful code samples are available at the book's web site. This 2-year old text will be relevant for years to come. It will be a security classic. It's enjoyable to read overall, but I found it a bit dry in a couple of spots. I really rates about 4 and a half stars. I read it cover to cover and enjoyed it. Unlike many modern security books, I've found this one incredibly useful as a reference since reading it.

I very much enjoyed this book and found learning it's content to be very worth my while. I think this book should be part of every computer science and computer engineering curiculum. I just graduated with a computer engineering degree and none of the basic security concepts covered in this book were ever mentioned in my required software classes. How can we expect developers to write secure software when they have not been taught how to?

My biggest criticism of the book is it doesn't deal enough with Windows and when it does address Windows the authors are often wrong (as is pointed out in previous reviews). But I don't think the authors are Windows experts, so they can be somewhat forgiven.

I also want to offer rebuttals to some of the negative reviews. Several reviewers gave the book few stars because it didn't cover web applications. No matter what language you write you web app in, you still will need to be aware of the concepts in this book. Your web app is not secure if it contains exploitable buffer overflows or input vulnerabilities.

A couple reviewers also fault the book for not explaining how to setup a secure web server or securely configure Apache. These are not topics the book aims to address and have nothing to do with writing secure code.

Also read John Veiga's rebuttal if you have any doubts about the book.