On Mon, 27 Mar 1995, Dr. Frederick B. Cohen wrote:
> Think that automated external testing without disclosure is best - but
> not ideal. Dispite all of the problems with it, it seems better than
> giving bad guys attack code that works on 40% of the world's computers
> and better than not telling people about vulnerabilities.
I have a couple of concerns about this approach.
The first is that a publicly accessible automated tester could be subject
to abuse. There could be malicious people "out there" who might decide
"Hey, let's start about 50 or a 100 tests against Prodigy!" The results
would represent a fair annoyance here.
Second, this approach does nothing to help me test from the inside or to
test from remote "trusted" (because we control them) sites --- short of
hiring you as a tester. ;-) Given the setup, to audit a server I have
to expose this server to the very environment that I'm trying to shield
it from --- before I know if those shields are effective.
Just to add a third concern to my promised list of two ... I'd like to
know what was done, how it was done, and *exactly* what the implications
of the results are. A report that hedges about telling me what the
problems and potential exploit paths are does me much less good. It's
hard to justify changing something in a "production" environment as it
is. It's almost impossible to justify it on the grounds of, "This piece
of email says that the blah-blah daemon might have a problem." The
rationale for doing something has to be explict and iron clad. I.e., "An
intruder could gain access by subverting this daemon in this way.
Replacing the program with so-and-so will eliminate this possiblity."
Statement made, email sent, back to work! :-)
"Outside of a dog, a book is a man's best friend;
inside of a dog, it's too dark to read." -- Groucho Marx