[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IDS: Assessment tools/Scanners



FAQ: See http://www.ticm.com/kb/faq/idsfaq.html
IDS: See http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html
HELP: Having problems... email questions to ids-owner@uow.edu.au
NOTE: Remove this section from reply msgs otherwise the msg will bounce.
SPAM: DO NOT send unsolicted mail to this list.
USUBSCRIBE: email "unsubscribe ids" to majordomo@uow.edu.au
---------------------------------------------------------------------------
---
On Sat, 9 Oct 1999, Ron Gula wrote:

> Instead, we maintain logs of network attacks that we have collected
> with Dragon from places like DEFCON and SANS ID-Net. These logs may be
> trivially converted to TCPDUMP format for network replay.

trace-driven simulation is very useful, but there are a few problems in
using it alone for comparative evaluation.

1. good traffic is hard to find. DEFCON and SANS IDnet data tends to
   consist of ONLY attacks, with little or no "normal" background traffic.
   and without an authoritative list of attacks that actually exist in the
   trace, it's hard to compare IDS alert output.

2. even when the attacks are known, without a common attack taxonomy
   you end up comparing apples to oranges. ex. in the DARPA IDEVAL 
   (http://www.ll.mit.edu/IST/ideval/), 'mscan', 'nmap', 'SATAN',
   'NTInfoScan', etc. are listed as attacks - but these are actually tools
   that implement many discrete attacks, which are reported differently
   by different IDSs.

3. such testing is necessarily incomplete. by testing against a specific
   trace, you're demonstrating how well an IDS handles that particular
   dataset only. but what about an IDS's coverage of attack variants?
   or performance (and what metrics are you interested in, anyway)?

-d.

---
http://www.monkey.org/~dugsong/