Posts
What is Software Security Building Security ?
Software is easy to criticize and hard to do. The bigger the software, the more that is true.
It is thus like speech—the more you say, the easier it is for the reader to find something
to criticize, and the more likely the critic will get it wrong. Brevity may be the soul of
wit, but it is wit that is the soul of brevity.
And, indeed, our software is nothing if not loquacious, slang-riven, ill-bred, bloated, and
raw. Is it any wonder that software is as prone to misinterpretation as is our language, any
wonder that our software, like our language, can be "twisted by knaves to make a trap for
fools?" No, it is not, but, as with language, everything we collectively are now depends
on software. Software is so very essential that it is unlikely that the world's population
would be as great as it now is without software—software to transport, to transact, to
transcribe, to translate, to transmit, to transform. In other words, the evidence is
unarguable that we have to get software right, just as the evidence is unarguable that
getting software right does not, and will not, come naturally.
As Dr. McGraw reminds us, breaking something is easier than designing something that
cannot be broken, though I personally prefer Sam Rayburn's earthy formulation, viz.:
"Any jackass can kick down a barn, but it takes a good carpenter to build one." And that
is what makes secure software in particular the pinnacle of concern because the very
definition of secure software is that it withstands sentient opponents. Parsing that
definition in its contrapositive: If a product does not have sentient opponents, then it does
not have security requirements. This is best examined by looking at why products fail—if
your product fails because of a collection of clueless users ("Hey, watch this!"), alpha
particles, or discharged batteries, security is not your issue. If your product fails because
some gleeful clown discovers that he can be the super-user by typing 5000 lowercase As
into some prompt, said clown may not be all that sentient, but nevertheless your product
has security requirements.
This can't be a completely bright line, but it is an instructive distinction. Secure software
is, by definition, designed with failure in mind. Secure software resists failure even when
that failure is devoutly wished for by the opponent. Secure software is designed for the
failure case as much as or more than the success case. Designers and implementers alike
envision an opponent who can think.
As Dr. McGraw says throughout this book, baking in security only happens when there is
intent to do so. My father used to scold me when my excuse for this or that was "I didn't
mean to do it, Daddy." His stinging comeback, for which I am a better man, was always
"But did you mean not to?" Given what I do for a living, I read vulnerability reports
every day. Every one of them says, "I didn't mean to do it, Daddy." Sometimes they even
try to say, "I didn't do it, but if I did I didn't mean to, and anyway you didn't notice, so all
you have to do is install this tiny little fix unless you want what happens next to be your
fault; aren't I a good boy?" I want to scream "Did you mean not to?" even though the
honest answer will at best be "I thought I meant not to."
Download Software Security Building Security by Gary McGraw
Post a Comment