The point of initial deployment of an IDS system is to have all the events
reporting back to the console, then after some time, tune the policies to
avoid the false positives from making IT admins running for the hills or
avoid the "Crying Wolf" issue.
IDS should also provide diagnostic information indicating something is
broken (i.e. the web server)
/m
At 12:04 AM 8/8/00 -0500, bwilson2 wrote:
>Rule based, commercial IDS systems need to be protected from "the flood"
>by the border router ACLs and firewall. Otherwise, they just cry all day
>long from the flood and report everything as a serious attack . . . even
>the failures. For example, a Web cgi attack was reported by a commercial
>IDS raised everyone's attention only we later verified that the Web
>server had 404ed the requests. It was just one of a flood of false alarms
>reported everyday and hour.
>
>We also use a TCPDUMP (aka, shadow) IDS in front of the border router and
>firewall to detect the "holes" by analysis of the outbound traffic. The
>external IDS takes skill but it gives insights the commercial IDS miss or
>mask in the flood.
>
>Bob Wilson
>-
>[To unsubscribe, send mail to [EMAIL PROTECTED] with
>"unsubscribe firewalls" in the body of the message.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
