Warren Harrison wrote:
>I'd be interested in hearing arguments as to
>whether increased software quality leads to more
>secure software. I am not entirely convinced these
>are not orthogonal (the original discussion, if I
>am not mistaken involved security, not quality :-)
>
Absolutely:
* Reliable software does what it is supposed to do.
* Secure software does what it is supposed to do, and *nothing else*.
* Software engineering is the discipline of trying to build software
that what you expect.
So they are related. The relationship is sublte, in that software can be
said to be secure if it fails safe, i.e. halts if the bad guy messes
with it, but that lets the bad guy deploy a DoS attack against you.
Crispin
>
>In fact, as the new Editor-in-Chief of IEEE
>Software Magazine, I'd love to get some papers
>on this topic submitted (hint, hint).
>
>Warren
>
>Crispin Cowan wrote:
>
>
>>Shaun Savage wrote:
>>
>>
>>
>>>Crispin Cowan wrote:
>>>
>>>
>>>
>>>>Shaun Savage wrote:
>>>>
>>>>
>>>>
>>>>> 1A+ "competition inceases software quality"
>>>>>
>>>>>
>>>>Does not follow. A vendor that has a monopoly on a narrow niche may
>>>>be able to devote sufficient resources to supporting a complex
>>>>application, where as two competing vendors trying to live in the
>>>>same niche may find themselves with insufficent revenue to properly
>>>>support their applications.
>>>>
>>>>
>>>If two companies make "chairs" and if one company chair is softer,
>>>last longer, and cost the same, the other company will need to make
>>>better chairs in order to sell chairs. The niche example is an
>>>exception not the rule.
>>>
>>>
>>If there are exceptions, then it is not a rule. This is particularly
>>true if we use strong language like "axioms."
>>
>>
>>
>>>>> 1A- "shorter development time reduces software quality"
>>>>>
>>>>>
>>>>Does not follow. Good design can lead to shorter development and
>>>>better software quality. And this does not appear to have anything to
>>>>do with monopolies.
>>>>
>>>>
>>>Correct it does not relate to monopolies, but on average it is true.
>>>When a project reaches a large size, the good design will only help so
>>>much. On average, if competition forces the release of a project
>>>before it is ready, the software quality will be reduced. The more
>>>"man years" put into software the better the software ON AVERAGE.
>>>
>>>
>>All other things being equal, shorter development time reduces quality.
>>But there are lots of things you can do that simultaneously reduce
>>development time and improve quality, so it makes a very poor rule.
>>
>>
>>
>>>>>2> "proper software development inceases software quality"
>>>>>
>>>>>
>>>>Er, yes, but "proper" is so ill-defined that this statement is a
>>>>tautology.
>>>>
>>>>
>>>>
>>>Yes, the word proper is ill-defined. That is what I would like to see
>>>this group define. If this group can define what is "proper" then the
>>>group can help the state.
>>>
>>>
>>You seem to be trying to define principles of good software engineering.
>>That is a large and complex task. It is not special to CRIME, Portland,
>>or even security (although it is closely related to security). You might
>>want to check out the International Conference on Software Engineering
>><http://www.cs.orst.edu/icse2003/>, which will be in Portland in 2003.
>>But the core problem here is that the principles of good software
>>engineering are actually still unknown to science, and good software
>>engineering remains a black art.
>>
>>
>>
>
>
>
>
--
Crispin Cowan, Ph.D.
Chief Scientist, WireX http://wirex.com/~crispin/
Security Hardened Linux Distribution: http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html
This archive was generated by hypermail 2b30 : Thu Sep 26 2002 - 04:19:23 PDT