Concrete suggestions (no matter how hard to implement in reality) are a good thing. Microsoft should take a long hard look at these suggestions and make use of them wherever possible.

When commenting on an early draft of this article, I was struck by an analogy to writing that I find helpful when thinking about building secure software. Consider the act of writing something coherent. Implementation-level flaws in software are like mis-spelled words, incorrect verb tenses, or "syntax" problems. Architectural problems are like semantic problems, idea flow issues, poor paragraph structure, etc. Today, we spend all our time running software security spell checkers, and nobody knows how to write cohernet essays! We need to change that.

We *must* pay more attention to architectural problems to make real progress in software security. As I said to Bruce and Adam (and they repeated), "The most insideous software security problems (and the hardest to stamp out) are architectural in nature. Buffer overflows, everyone's favorite whipping boy, are an easy implementation-level problem to fix. Higher-level constructs such as including scripting engines or securing inter-process communication are more complicated design-level issues." This bears repeating.

Building secure software is a challenge that we can face. The time has come.

gem

Gary McGraw, Ph.D.

CTO, Cigital

co-author of "Building Secure Software"

[ reply ]

Link to this comment: http://www.securityfocus.com/comments/articles/315/10088#10088