This is the preamble of an RFC-1341 encoded, mixed message.
On Tue, 15 Jul 1997 Bob Beck <beck @
obtuse .
com> said:
>Subject: Re: Firewall Integrity Testing??
> It seems to me that you have implied that using a scanning tool is a
> waste of time and not useful.
> You seem to base this on assuming that anyone who would use one; 1)
> doesnt know much about evaluating a security implementation, other than
> how to use the scanner, 2) will use that tool exclusively to determine
> the effectiveness of the security implementation, and 3) will
> irresponsibly chuck the raw output of the tools findings at the "client"
> and walk away, done.
> IMHO, this is not necessarily the case.
> First of all, IMO, no matter how good you think you are, you can't verify
> something (e.g. a security policy implementation) works, without testing
> it. A scanner can be _one_ useful tool in doing so.
> Testing is a basic principle of troubleshooting ( which, although perhaps
> a stretch, applies to this activity).
Using a scanning tool to verify that a piece of software does what it was
designed to do, may make some people feel good, but wouldn't
a better test be one that tests for what was not designed too?
> Second, I think most would agree that given unlimited time and money, you
> can find a way to bypass, circumvent, damage, etc a security
> implementation. The fact is, a security implementation, like any other
> IT project, is always a delicate balance of functionality and cost.
And more often than not it's not through the firewall!
> Third, you can't plug a hole if you don't know it is there. If, as part
> of a complete security evaluation, you find a "hole" with a scanner, then
> you have accomplished something good, and of value to the client, in,
> perhaps, a shorter amount of time than could have been done "manually".
Exactly! So if the scanning software is not looking for the hole where is the
assurance. Usually, in a good code walkthrough or
code review!
> All in all, I think it irresponsible to trash the tools or the users of
> such. Like any tool or process, a "security scanner" can be mis-used or
> mis-understood or mis-represented. But that is no reason to discount
> it's effectiveness in the proper context, or the intent and credibility
> of anyone who might utilize one.
I think what is key here is the strong reliance on security scanners
which should be simply on components of a security review. Security scanners
tend to come at a problem from one direction, yet we know
that the best solutions to problems come from integrating the results from
every direction.
> Having said that, a scanner will never replace the noggin of a competent
> security "expert/consultant/miscreant/whatever" and shouldn't be intended
to.
In order for that to happen the scanners would need to incorporate AI and AI
would need to be further developed. Predicting human behavior is not an easy
task and that is what the scanners would have to evolve to. Unfortunately some
security experts arm themselves with software turn off the noggin. Which makes
those that
use their brains worth so much more.
char
/*
********************************************************************************************
*/
/* char sample; that really is my name */
/* phone: (410)412-8161 */
/* e-mail: char_sample @
notes .
pw .
com */
/*
********************************************************************************************
*/
The following item was sent as a file attachment to this mail
message:
WINMAIL.DAT (3580 bytes)
It has been uuencoded for transmission via Internet mail. If your
mail software is unable to decode this attachment, it can be restored
to its original format using the Unix "uudecode" program. Please
contact your system administrator if you need assistance.
Attachment:
WINMAIL.DAT
Description: application/lotus-notes
End of attachments
|
|
