Books

I got started writing books when Douglas Hofstadter conned me into writing chapter 10 of his book Fluid Concepts and Creative Analogies.  (Incidentally, FCCA was the first book ever sold on amazon.) It was a slippery slope to the book Java Security from there, and that was over twenty years and eleven books ago.

My most important book Software Security was released in 2006 as part of a three book set called the Software Security Library. Software security as a field has come a long way since 1995. I am pleased with the progress we have made over the last twenty years and very excited about what is yet to come.

My books have turned out to be quite popular, which is very gratifying. I thank all of my readers for their support and loyalty. I am also greatly indebted to my excellent co-authors, collaborators, and partners in crime. You know who you are!

There’s a funny story or two associated with each book. The first book Java Security: Hostile Applets, Holes, and Antidotes actually has a hidden message on the cover. The second part of the title spells “HA HA”. We called that one “HA HA” throughout production.

Software Fault Injection, a software engineering tome written with Reliable Software Technologies chief scientist Jeff Voas, was supposed to have a needle on the front. Wiley said “ok” to the needle idea, then pulled a fast one by using Cleopatra’s needle (currently located in Paris) instead of a syringe. The cover turned out fine, but a junkie needle would have been sillier. How many software engineers do you know that shoot smack?

The cover of Securing Java also has an inside joke. Scott Oaks wrote a mediocre book in 1998 called Java Security. In O’Reilly fashion, his book had a birds nest with eggs in it on the front. We decided that it would be interesting to break the eggs. The question is whether the baby bird hatched and flew off into the sunset or a predator came and gobbled it up. You decide.

When we were almost done with Building Secure Software, we began soliciting blurbs for the praise pages at the front of the book. Peter Gutmann, one of the better crypto weenies on the planet, helped us with excellent reviews and some code, and we asked him for a quote. New Zealanders are known for being incredibly understated. In fact, the word “exciting” is not part of the New Zealand vocabulary. Anyway, Peter’s excellent quote for the praise page is “It’s not bad.” Of course, we included it!

Exploiting Online Games has a very cool cover designed by a Brasilian. When we were about to enter production, I sent him email asking for him to hit a certain deadline. He responded by saying “No problem. I can skip school next week since it is Carnival and they don’t take attendance.” Puly is a kid?! Wow.

Software security has come a long way in the last few years, but we’ve really only just begun. Software security is the practice of building software to be secure and to function properly under malicious attack. The underlying concepts behind Software Security have developed over almost a decade and were first described in Building Secure Software and Exploiting Software. Software Security begins where its predecessors left off, describing in detail how to put software security into practice.

After completing Java Security and following it up with Securing Java, I began wondering how it was that such excellent designers, engineers, and architects went astray when it came to security. What was it about software that made security such a problem? If you wanted to build secure software, how would you do it? These questions and the perseverance of John Viega led to Building Secure Software.

Building Secure Software (BSS), the white hat book, seems to have touched off a revolution. Security people who once relied solely on firewalls, intrusion detection, and antivirus mechanisms came to understand and embrace the necessity of better software. BSS provides a coherent and sensible philosophical foundation for the blossoming field of software security.

Exploiting Software (ES), the black hat book, provides a much-needed balance, teaching how to break software and how malicious hackers write exploits. ES is meant as a reality check for software security, ensuring that the good guys address real attacks and invent and peddle solutions that actually work. The two books are in some sense mirror images.

Software Security unifies the two sides of software security—attack and defense, exploiting and designing, breaking and building—into a coherent whole. Like the yin and the yang, software security requires a careful balance.