Top-down vs. bottom up (IDS) management

["Stout, William" <StoutW () pioneer-standard com>]

The discussions I've lurked over seem to dance around the intended
application (target audience) of the IDS system.

If the intended application is for management purposes, such as to
monitor a particular 'service level' of security, an IDS system would be
the best tool we currently have (best evidence) to measure what drifted
through the window and what fanged beast scratches at the doors.  A CIO
is typically measured by Service Level Agreements (SLA), and one
agreement which targets security may state that the servers or network
will be 98% secure.  Maybe 2% of the time there will be detected
security intrusions which could include internal WinNuke 'testing',
viruses, or even downtime caused by fixing what was installed insecurely
in the first place.

I believe it's widely accepted that if the intended IDS application is
to guarantee 100% security, it ain't gonna happen.  There's no way to
predict the future, or to forsee stealthy hacks crafted by clever
intruders.

Concerning active responses or integrating Artificial Intelligence (now
often called 'Applied Intelligence'), as with all applications, one
could also automate an IDS system to do stupid things.  Better yet, the
'knowledge base' contained in the IDS should trigger alerts, and use
'AI' to give detailed instruction on what to do to zoom in on an attack
to focus on the source, and/or to fix what allowed the attack, maybe
even determine what does not require paging someone, to prevent a
denial-of-sleep attack.  If the administrator sets the system to respond
a certain way automatically, with experience he'll learn what he can get
away with and what not to do in the future.

An IDS system needs an intelligent source of understanding to update the
knowledge base, Farmer correctly pointed out that you can't only work
off knowledge, you have to work off understanding (my translation).  If
the administrator is not a good source of understanding for that
knowledgebase, an outside source (subscription) should be used.  This is
basically outsourcing intrusion detection to those who should know what
it looks like.

An IDS system should also collect only as much data as possible until it
detects something worth the cost of detailed logging.  We could collect
all network traffic always, but that would constitute a self-inflicted
denial-of-storage attack.  Farmer is right that during the time you
debug or track something down down you need to collect as much seemingly
mundane data as possible during that instance.  What is actually needed
is a state-snapshot of configuration files from routers, systems,
firewalls, etc, maybe a 'cops-like' functionality to review what the
security of the systems were defined to be, or to determine what should
not be, or could have been changed.

An IDS system can be marketed as a network analyzer bits & bytes tool,
or a high-level executive SLA measurement system.  I predict IDS systems
will catagorize or absorb components of themselves into monitoring
tools, management tools, executive tools, and maybe even apply the
knowledge base to network/systems security planning tools.

Personally I view the future view of firewalls as much bigger than a
proxy box, it's a collection of boxes and high-level coordination
between systems to create a perimeter or area security system.

Bill Stout