Most of the incidents in your first paragraph were improved with the establishment of laws, regulation bodies, and external testing with a stamp of approval.
The Underwriters labaroratory was established to ensure that a product was sales worthy to the public due to manufacturers focusing on sales and not much on safety.

Having a clearing house/body/organization which inspects an application for business worthiness, critical machinery functions, consumer entertainment or consumer sensitive use (personal planner, financial package) might  persuade vendors to use security enabled tools and  software building tools stricktly based upon  how difficult it is to acheive a  worthiness  approval. For instance if an application is developed in C,C++,C# then an appropriate set of audits and testing must be performed to acheive a certification. Since these would be more comprehensive than other languages the vendor would have to decide which is easier the extra expense of the extensive audits and testing vs. using a approved language that does not required a greater degree of testing. This would provide software tools vendors the incentive to create more security enabled tools to align themselves with the requirements of the body delivering the accredication for use.

The software industry is no different than most other industries. There are devices with little risk a garage door opener, a radio might have more user risk depending upon how you look at it, and then there are very dangerous applicances Irons, Microwaves, Snow Blowers.
For software a game, word processor, personal finance planner, for a business a financial package.



"Leichter, Jerry" <[EMAIL PROTECTED]> 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.
-- 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


Check out the New Yahoo! Mail - Fire up a more powerful email and get things done faster.
_______________________________________________
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

Reply via email to