Re: Re: Application Insecurity --- Who is at Fault?

[Crispin Cowan <crispin () immunix com>]

I strongly disagree with this.

Rigorous professional standards for mechanical and structural 
engineering came about only *after* a well-defined "cookbook" of how to 
properly engineer things was agreed upon. Only after such standards are 
established and *proven effective* is there any utility in enforcing the 
standards upon the practitioners.


Software is *not* yet at that stage. There is no well-established cook 
book for reliably producing reliable software (both of those "reliably"s 
mean something :)  There are *kludges* like the SEI model, but they are 
not reliable. People can faithfully follow the SEI model and still 
produce crap. Other people can wholesale violate the SEI model and 
produce highly reliable software.


It is *grossly* premature to start imposing standards on software 
engineers. We have not a clue what those standards should be.


Crispin

Edward Rohwer wrote:

> I my humble opinion, the bridge example gets to the heart of the
> matter. In the bridge example the bridge would have been design and
> engineered by licensed professionals, while we in the software business
> sometime call ourselves "engineers" but fall far short of the real,
> professional, licensed engineers other professions depend upon.  Until 
we as

> a profession are willing to put up with that sort of rigorous examination
> and certification process, we will always fall short in many area's and of
> many expectations.
>
> Ed. Rohwer CISSP
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of [EMAIL PROTECTED]
> Sent: Friday, April 08, 2005 10:54 PM
> To: Margus Freudenthal
> Cc: Secure Coding Mailing List
> Subject: [SC-L] Re: Application Insecurity --- Who is at Fault?


Margus Freudenthal wrote:

> > Consider the bridge example brought up earlier. If your bridge builder
> > finished the job but said: "ohh, the bridge isn't secure though. If
> > someone tries to push it at a certain angle, it will fall".

> Ultimately it is a matter of economics. Sometimes releasing something

earlier

> is worth more than the cost of later patches. And managers/customers are

aware

> of it.


Unlike in the world of commercial software, I'm pretty sure you don't
see a whole lot of construction contracts which absolve the architect of
liability for design flaws.  I think that is at the root of our
problems.  We know how to write secure software; there's simply precious
little economic incentive to do so.

--
David Talkington
[EMAIL PROTECTED]



--
Crispin Cowan, Ph.D.  http://immunix.com/~crispin/
CTO, Immunix          http://immunix.com