I completely agree with Frank here...scanning technologies are
interesting to get a snapshot, but by definition they miss all kinds
of things:
- devices/workstations/servers which are 'off' or offline when the
scan is performed.
- software/servers installed after the scan
- hw positioned behind FWs which might be blocking the scans
- new hw (laptops, etc.) or hw behind a wifi
- partner network links and the hw on that network
- false/poor OS information generated by odd hw configurations/OS tweaks
Also, agree with Frank re: value of detecting compromises. I'm not a
fan of alerts, but i think it's important to know that an asset had
been subjected to an attack (even if that attack is targeting the
wrong OS/vulnerability/etc.) maybe it makes more sense to use an
asset database to de-prioritize unsuccessful alerts, but it doesn't
make sense (to me anyway) to not report on an attempted attack...
just my 2 cents.
/will
On 7/24/05, Frank Knobbe <frank@knobbe.us> wrote:
On Sun, 2005-07-24 at 13:30 -0700, Swift, David wrote:
and ideally to turn
off alerting for events the protected network is not vulnerable to.
You meant to say "network is not *known* to be vulnerable to". The
knowing part is the tricky part. I'm not start with 0-day issues. Even
without those, the vulnerability landscape is in flux. What happens when
an not-vulnerable server dies, and gets restored to a vulnerable
version? Your vulnerability scan engine would have to constantly run
scans.
Again, why not detect "compromises" instead of "assumed/confirmed
vulnerability states"?
Regards,
Frank
------------------------------------------------------------------------
Test Your IDS
Is your IDS deployed correctly?
Find out quickly and easily by testing it
with real-world attacks from CORE IMPACT.
Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708
to learn more.
------------------------------------------------------------------------
