Dr. Gary McGraw on exploiting software

Technoflak was not able to go to last night's IEEE meeting, but fortunately Shahid Shah has posted an account of the presentation:

Gary started the 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.

Read the whole thing, almost like being there.