Exploiting Software: How to Break Code

Last night I invited Dr. Gary McGraw to give a talk on his new book Exploiting Software: How to Break Code at our monthly IEEE Computer Society Northern Virginia Chapter meeting. We had almost 100 people attend a wonderful talk on computer security with a focus on software security (as opposed to network security). If you haven’t heard Gary give a talk before, you should definitely attend one in the future (given that he’s a renowned expert he’s a prolific speaker at most industry conferences and many local events). Usually technical talks are are boring, but Gary presented the software security subject in an entertaining, insightful, and engaging manner. Exploiting Software is Gary’s fifth security book and I’ve read 3 of the previous ones as well but found this latest one to be the most applicable to the work I do for my clients. The other ones are nice, too, but this one just seems more relevant because I talk about the same things with my customers all the time. Exploiting Software‘s content (the book and the talk last night) is crisp, doesn’t waste time with theories, and provides useful guidance on how to make sure your software doesn’t do “stupid things”. Gary started the meeting off with an amusing anectode about how it seems that people are more likely to listen to you if you write a book about bad things (like breaking code) instead of positive ways of securing software (like his previous books). I was heartened to hear him talk about many of the same things I deal with on a daily basis: that security is emergent property of the system and not a feature that is added by tossing in a username and password; that developers of software (the builders) can do more to protect software than the operators; that network security is only the first of dozens of steps to securing software and data.

He went on to state that commercial security is a reactive process when good software security need to be proactive. Everybody chuckled at his remark that “crypto fairy dust” will not solve security problems: he was pointing out that most developers believe, wrongly, that just using SSL and cryptography will secure their software. It’s so common to think that putting in a SecureID card instead of normal password challenge/response is somehow “software security” (sure, it’s part of the solution, but only a start).

He also elaborated on the fact that systems are, of course, only growing more complex and that there is a correlation between the complexity of systems (measured in lines of code, function points, etc) and the risk associated with systems. If you have 1,000 lines of code you will have fewer security problems than if you have 1 million. It’s one of those “duh” moments and Gary pointed out that if you can convince your customer to reduce complexity of requirements or cut features altogether you can create less complex systems with fewer security holes. He said something I hadn’t thought about ealier: to help build more secure software, reduce features and simplify architecture which will help reduce cost. This means building more secure software can actually pay for itself. Not sure how many managers would buy the argument, but it’s worth making for sure.

He challenged the security experts by exlaiming that the bad guys are usually programmers who write code to assist their break-in efforts but the good guys on the security watch are usually operators who don’t know about code. Gary was pointing out, correctly, that “it’s not fair.” That to be a good security specialist, you have to know how to code so that you can think like the bad guys. That was one reason for his writing the book.

I also liked his comments on how you can not become a “software security engineer” without years as a programmer, more years as a software architect, and then even more time as a security specialist. If you have a guy with two years coding experience telling you he’s a software security guru there’s probably something wrong!

Gary and I talked afterward the meeting about the fact that his latest books doesn’t cover data security (which is as big a problem, if not bigger for some clients, than application security). After I finished reading his book and after hearing him talk that was the only think I felt was lacking. He said it wasn’t that he didn’t consider the data security problem important (he does), just that it wasn’t part of the book’s focus. I personally have found lots of holes in people’s databases, data transfer, and web services code (where data can actually change the flow of code) and consider help in that area of application security to be lacking in the literature in general. I’ve found very few books on that subject, but one that I have found interesting is called Translucent Databases. If you’re worried about securing data outside your application, check it out.

Want to learn more about what Gary has to say? Follow these links: