I usually keep a few books I am reading at a time. Plus I am writing the chapter (along with several others like Sahil Malik's chapter on Transactions) on SQL Server 2005 Security for the upcoming MS Press SQL Server 2005 book by Andrew Brust and Stephen Forte. It's been exciting to put over a year's worth of research and speaking on SQL Server 2005 down on paper.
One book has caught my eye and attention recently, and now so far my immense enjoyment in reading it, and that is Software Security: Building Security In by Gary McGraw. I have been in the software industry in one way or another for over 18 years now, but really focusing on software security for the last 4-5 years. This is the book I wish was available at the beginning, but, obviously, the field, as with everything, has to mature.
McGraw continues his software security series that began with Building Secure Software (written by McGraw and John Viega) which showed how to build secure software the correct way. The second book in the series was Exploiting Software (written by McGraw and Greg Hoglund - I mentioned Greg's other excellent book on Rootkits previously) which showed how code can be exploited, and the things to watch for in coding. This was one of those books that kept you up at night. :) The new book by McGraw continues where these two leave off. It is partly a practical "How-To" book filled with help in writing secure software and testing it to make sure you haven't left exploitable holes in your source code and architected systems. It is also partly a book about the "philosophy" of building security into your systems.
I think this second part is the toughest thing to convey to people. You can teach others how to avoid buffer overflows, how to test for SQL Injection, and to follow many lists for making sure source code is as secure as possible, but how do you teach people to really WANT to write secure software and consider that as important in their daily coding lives as unit testing, refactoring, and many other programming techniques? How do you get developers and managers of software projects to "get it" that software security doesn't happen by accident? In other words, how is building security in "caught" as well as "taught"?
I do like McGraw's thoughts that the best place to start with learning software security is with software people. The infosec field has a great purpose, but it can miss what happens beyond the firewall inside the organization and in it's running applications. For example, SQL Injection is still easy to thrwart the best intrusion detection systems and firewalls are powerless to stop "harmless-looking" data input if it goes through the right ports because it is a software exploit, not a hardware exploit. As McGraw states, teach software people how to do real secure code reviews, how to use security tools, and how to interpret the results. They already have the advantage of knowing and understanding software defects and can understand and spot coding that is simply bad or wrong. Learn to gradually adopt an SDL (Software and Security Development Lifecycle) within the organization that everyone agrees to and implements by default.
Software security professionals should read this cover to cover (yes, there will be many things here you have seen before or "lived" through first hand, but it is still worth it). If you are not focusing on software security as a profession, there are still chapters that should be read by everyone in your company that will make sure your product or software project will get started the correct way.
The web site for the book is at http://www.swsec.com. Check out the table of contents here.
