software design

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.

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 most languages and many languages are discussed, however, the slant here is towards C.

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's easy to read overall, but I found it a bit dry in a couple of spots. This book deserves 5 stars for relevance and author knowledge and 3 for price. I read it cover to cover and enjoyed it. I've found it useful as a reference on occasion after the read.

I was especially excited to read _Building Secure Software_, and not only because I know Gary McGraw's work is top quality: I have read and written more than a few books on the topic of computer security myself, and I recognize the timeliness of this work on good software coding practices. One of the books I've written is _Hacking Exposed_, which talks about network- and system-level vulnerabilities, how to exploit them, and how to counteract such attacks. While HE focuses on tools, processes and techniques that exploit vulnerabilities in the real world, _Building Secure Software_ focuses on creating software that is much less susceptible to these sorts of attacks in the first place. They make a great one-two punch for those who want to take a proactive approach to security. Together with Hacking Exposed, Building Secure Software represents a comprehensive solution to today's security woes.

Many transformations begin with an indictment. Two notable examples are Martin Luther's "95 Theses" criticizing the Catholic Church, which began the Reformation, and Ralph Nader's denunciation of the auto industry with "Unsafe at Any Speed." An indictment of the software industry and its indifference to writing secure software hasbeen published in "Building Secure Software: How to Avoid Security Problems the Right Way" by John Viega and Gary McGraw.

Twenty years into the client-server revolution, and a decade into the Internet revolution, it's a measure of inadequacy of secure coding that only now are the first books being written on how to secure software -- the very foundation of information systems.

Software developers who code without taking security into consideration are potentially as dangerous as a physician prescribing a drug without knowing its side effects. As a society, we should tolerate neither.

While security products such as firewalls, encryption devices, event monitoring and intrusion-detection systems are needed to secure networks; it must not be forgotten that behind every security problem is a common enemy -- insecurely written software.

Building secure software is not rocket science. Writing secure code doesn't mean turning every developer into a world-class cryptographer. It simply means training them in the fundamentals of how software works, including security. If corporate end users can betrained not to send inappropriate (sexist, racist, confidential, etc.) e-mail via corporate servers, then software developers can certainly be trained to write secure software programs.

The revolution needed in software development is to integrate security into software engineering. The current approach in software is to patch problems after they occur. In fact, 2003 saw the rise of many patch management companies; a sector that only came to be recently. Endless patching is a downward spiral that only serves to treat the symptoms, not the true problem, and only in a reactive manner. Had those same programmers been trained in writing secure code, much of the problems would have been obviated and billions of dollars saved in the interim.

It's all the rage to send development offshore in the name of saving money. If companies understood how much more money could be saved by building secure software from the get-go, rather than bolting security on as an afterthought; wouldn't they do the same?

It's frightening to think that in just a matter of years, everything but the food we eat will have an IP address attached to it. When the time comes that your family vacation commences with a flight on a pilot-less airplane, here's hoping the developers of the navigation and control systems knew the rudiments of writing secure software.