This little dialog below really clearly shows us the prime problem
with security in software. Poor to non-existent testing regimen.
The code is not usually broken, it is circumvented through the exploit
of some kind of design flaw.
Good matrix testing is as necessary for software development as it is
for good science. Theories are fine, very noble even. Practice is the
more marketable item. There is a road that travels between theory and
practice that is of variable quality. Sooner or later someone who is
"perfecting" something encounters a need to put beans on the table.
If I had to point at a place in the process where Caesar stands and
imperiously declares "Let the Games Begin!", it would be there. Where
one can no longer afford to think fully about the situation.
After market considerations shorten your process and take quality steps
out of your delivery path, the pimply-faced hackers become your
testing crew, and because they are "au naturel", and diverse,
and un-organized, and interest driven, they rarely perform completely,
don't document, don't even properly analyze. The matrix that tests
thoroughly every feature, not because it might be weak, but because
it exists in dimensional space, is usually lost from the test regime.
The incredibly valuable database of functional tests, the thing that
saved Thomas Edison's ass again and again, ..."We now know 14,000 ways
the lightbulb doesn't work" is no longer working for you. And all those
curious young minds are working against your initiatives. Trying to break
them.
And so, in rushing to market, in heeding the siren's call, there,
let the games begin.
If you want to beat this, very thoroughly test. Use testing that begins
with a design of the tests themselves, a full layer of care and attention
that rarely exists (who has the time, who has the money). Rigor is the
real root of this. These aren't really security issues at all, they are
development and production issues. The subject of the production only
happens to be security in this case. We often get side-tracked by hype.
Happy Christmas, everyone! ...and a safe, secure new year.
-----------------------------------------------------
At 05:54 PM 12/23/98 -0800, David Gillett wrote:
>On 23 Dec 98 at 13:23, Michael Sierchio wrote:
>
>> You also seem to be misguided about "hackers." For the most part,
>> for every clever person who finds a weakness and develops exploit
>> code, there are tens of others -- pimply teenagers with delusions
>> of grandeur -- who download the code and exercise it.
>
> In my less-than-exhaustive perusal of "hacker literature", what
>strikes me is that these "clever persons" almost never work from a
>documented understanding of the design, but instead tend to reason --
>not always correctly -- back from a set of behaviours, observed in
>the field, to a testable theory about the implementation. Sometimes
>this finds errors in the design -- which design reviews may miss
>because reviewers are already "too close" to the design. More often,
>it finds errors in the implementation, which ALSO tend to escape
>detection in design review....
>
> I guess this puts me somewhere in the middle. Real-world testing
>and track record are not a waste of time, BUT ALSO open design review
>is more likely to increase than decrease the actual security of a
>system. Avoiding either, on whatever grounds, leaves one with little
>basis for *any* assumption about the actual security of the result --
>all you know is that you don't know.
>
>David G
>-
>[To unsubscribe, send mail to [EMAIL PROTECTED] with
>"unsubscribe firewalls" in the body of the message.]
>
Sincerely,
Larry Kwiat
Security Coordinator
Government of Yukon
[EMAIL PROTECTED]
Phone: (867) 667-8081
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
