I read six books on software security recently, namely "Writing Secure Code, 2nd Ed" by Michael Howard and David LeBlanc; "19 Deadly Sins of Software Security" by Michael Howard, David LeBlanc, and John Viega; "Software Security" by Gary McGraw; "The Security Development Lifecycle" by Michael Howard and Steve Lipner; "High-Assurance Design" by Cliff Berg; and "Security Patterns" by Markus Schumacher, et al. Each book takes a different approach to the software security problem, although the first two focus on coding bugs and flaws; the second two examine development processes; and the last two discuss practices or patterns for improved design and implementation. My favorite of the six is Gary McGraw's, thanks to his clear thinking and logical analysis. The other five are still noteworthy books. All six will contribute to the production of more security software.
Gary McGraw's book gets my vote as the best of the six because it made the biggest impact on the way I look at the software security problem. First, Gary emphasizes the differences between bugs (coding errors) and flaws (deeper architectural problems). He shows that automated code inspection tools can be applied more or less successfully to the first problem set, but human investigation is required to address the second. Gary applauds the diversity of backgrounds found in today's security professionals, but wonders what will happen when this rag-tag bunch (myself included) is eventually replaced by "formally" trained college security graduates.
Second, Gary explains that although tools cannot replace a flaw-finding human, they can assist programmers trying to avoid writing bugs. Gary is the only author I encountered who acknowledged that it is unrealistic to expect a programmer to keep dozens or hundreds of sound coding practices and historical vulnerabilities in his head while writing software. An automated tool is a powerful way to apply secure coding lessons in a repeatable and measurable manner. Gary also reframed the way I look at software penetration testing, by showing in ch 6 that they are best used to discover environmental and configuration problems of software in production.
Third, Gary is not afraid to point out the problems with other interpretations of the software security problem. I almost fell out of my chair when I read his critique on pp 140-7 and p 213 of Microsoft's improper use of terms like "threat" in their so-called "threat model." Gary is absolutely right to say Microsoft is performing "risk analysis," not "threat analysis." (I laughed when I read him describe Microsoft's "Threat Modeling" as "[t]he unfortunately titled book" on p 310.) I examine this issue deeper in my reviews of Microsoft's books. Gary is also correct when he states on p 153 that "security is more like insurance than it is some kind of investment." I bookmarked the section (pp 292, 296-7) where Gary explained how the "19 Deadly Sins of Software Security" mix "specific types of errors and vulnerability classes and talk about them all at the same level of abstraction." He's also right that the OWASP Top Ten suffers the same problem. Finally, Gary understands the relationships between operators and developers and the importance of security vocabulary.
I was pleasantly surprised by "Software Security". I reviewed an early draft for Addison-Wesley and wondered where the author was taking this book. It ended up being my favorite software security book, easily complementing Gary's earlier book "Building Secure Software." In my opinion, Gary is thinking properly about all the fundamental issues that matter. This book should be distributed to all Microsoft developers to help them frame the software security problem properly.
less
0 comments
Post a comment