On Sun, 5 Nov 2006, Leichter, Jerry wrote:
> 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.
Well said, and quite right. A few pointers though.
A bridge is a single-purpose device. A watch is a simple purpose computer,
as was the Enigma machine, if we can call it such.
Multi-purpose computers or programmable computers are where our problems
start. Anyone can DO and create. One simply has to sit in front of a
keyboard and screen and make it happen..
As such, even if built well, the computer is programmable, and thus at
risk.
Gadi.
> -- 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
>
_______________________________________________
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
