RE: Bug-free software (was: Re rant about virii on VMS...)

["Mark Graff" <mark () markgraff com>]

The discussion about whether any software can be "bug-free" (we might read
"secure") reminds me of a fellow I know who was asked by his wife to install
a coat-rack dowel in a closet. (I mean the sort of rod that spans the back
of a closet and lets you hang up coats.)

He asked her, "How high up do you want it?" She specified, "Six feet above
the floor." He then asked, "Six feet--to what tolerance?"

The wife, being herself an engineer, replied after a moment's thought, "Oh,
a quarter inch will be fine." The coat rod survives today, as does the
marriage.

I certainly see and endorse the point that in evaluating the security of an
application system, we need to consider the security quality of each of that
system's components, including specifically the firmware involved, etc. But
I think we must take a lesson from the designer's of today's builders--and
those engineers in the story I cited above--and seek to define and work to
an accepted set of *tolerances*.

"How secure do you want it?" "Just secure enough." Once we can quantify and
tot up the unaddressed risk in the o.s., and the app, the web server, and
all the firmware, then we--like the folks that design bridges--can hope to
add up the cumulative risks and see if the likelihood of failure meets the
specification of the system. We'll then add or substract more or less secure
components, like a structural engineer specifying stronger horizontal
members and higher-grade bolts, until we can demonstrate according to
generally accepted principles that the system structure can sustain the
loads for which it is intended. Tables and handbooks would be nice.

I know how far we are away from that environment, but wanted to re-introduce
into this thread my sense of where "security engineering" should be going.
Bug-free ain't the goal, IMHO.

-mg-

p.s. Thanks to KRVw for the bridge analogy.