Much as I agree with many of the sentiments expressed in this discussion,
there's a certain air of unreality to it. While software has it's own
set of problems, it's not the first engineered artifact with security
implications in the history of the world. Bridges and buildings
regularly collapsed. (In the Egyptian desert, you can still see a
pyramid that was built too aggressively - every designer wanted to
build higher and steeper than his predecessor - and collapsed before
it was finished.) Steam boilers exploded. Steel linings on wooden
railroad tracks stripped of, flew through the floors of passing cars,
and killed people. Electrical systems regularly caused fires.
How do we keep such traditional artifacts safe? It's not by writing
introductory texts with details of safety margins, how to analyze the
strength of materials, how to include a crowbar in a power supply.
What you *may* get in an introductory course is the notion that there
are standards, that when it comes time for you to actually design
stuff you'll have to know and follow them, and that if you don't you're
likely to end up at best unemployed and possibly in jail when your
"creativity" kills someone.
In software, we have only the beginnings of such standards. We
teach and encourage an attitude in which every last bit of the
software is a valid place to exercise your creativity, for better
or (for most people, most of the time) worse. With no established
standards, we have no way to push back on managers and marketing
guys and such who insist that something must be shipped by the
end of the week, handle 100 clients at a time, have no more tha
1 second response time, and run on some old 486 with 2 MB of memory.
I don't want to get into the morass of licensing. It's a fact that
licensing is heavily intertwined with standard-setting in many
older fields, but not in all of them, and there's no obvious inherent
reason why it has to be.
The efforts to write down "best practices" at CERT are very important,
but also very preliminary. As it stands, what we have to offer
are analogous to best practices for using saws and hammers and
such - not best practices for determining floor loadings, appropriate
beam strengths, safe fire evacuation routes.
Every little bit helps, but a look at history shows us just how
little we really have to offer as yet.
-- Jerry
_______________________________________________
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
