Food for thought...

["Harris, Tim" <tharris () ocair com>]

Archive: http://msgs.securepoint.com/ids
FAQ: http://www.ticm.com/kb/faq/idsfaq.html
IDS: 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.
UNSUBSCRIBE: email "unsubscribe ids" to majordomo () uow edu au
-----------------------------------------------------------------------------
Greetings and felicitations.  What do you folks think about...

I use snort as an IDS and I was wondering about how some of the shortcomings
of an IDS might be overcome.  I expect that these questions have been
debated before in various forums but I have not been privy to those
discussions so here goes...

1. The fundamental problem with any current IDS is that it relies on
signature files.  It is very simple to modify an attack (particularly a
buffer overflow) to avoid using the known signature thus causing the analyst
to have no data to examine.

2. An IDS is difficult to tune.  You either get many false positives and
can't find the real threat or you never see the actual attack.

3. Snort creates large quantities of data that need to be filtered by the
analyst.


What would happen if we changed the basic philosophy of the IDS to be a
conceptual "deny except as permitted"?  Right now it shows me the things
that it knows are bad.  What if it sorted a packet (or packets) into four
categories instead of only alert or ignore?

Category 1: Things that are explicitly OK.  Pass without notice
Category 2: Things that are bad but I am safe from.  Log without Alert
Category 3: Things that I am not safe from.  Log and Raise Alert
Category 4: By defualt, everything else is questionable.  Log in a separate
location

The obvious problem with this scheme is that category 4 will initially be
huge.  But after time, things would be moved into one of the other
categories by writing or modifying a rule.  The thing that the analyst needs
is to be able to focus on the high risk areas (category 4).  Once a threat
is identified it can be re-categorized from a level four to a 1, 2, or 3.

I know that I'm being a bit muddy in my thinking but let me give you an
example.

Suppose I have a server set up with HTTP and DNS daemons running.

The first level of filtering would be to ignore everything that we have
defined as OK.  This might be a list of
files/directories/addresses/ports/etc that I know are OK.  All these things
would pass without mention.

The second level of filtering would be addresses or ports that don't exist
and/or have no listeners.  Activity against these would go into a historical
log to be used if more detail is needed.  This category might also include
information gathering attempts that are not important such as pings and
traceroutes.

The third level would be positive attacks against existing ports/addresses.
These would go into a separate log of hostile activity.

The fourth level would be everything that is left.  That would be the
separate file that the analyst would use to identify new attack modes.  The
analyst would spend the majority of time examining that data.  As the
analyst identifies a new attack or determines that the traffic is
unimportant/harmless, a rule would be written to place that traffic or
attack method into one of the other categories.


I can see a lot of difficult problems with defining each of these areas but
this would give the analyst data on previously unknown attack modes as well
as the backup data for someone who has been poking for a while.  There are
lots of things that happen that are not important unless a real attack
occurs.  An example would be a port scan or a ping.  I don't care about
those unless a real attack occurs.  Then I need to be able to refer back to
the historical data.  This scheme would save the relevant data without
making me wade through unimportant alerts.

Any thoughts or opinions that you would like to share?