RE: IDS failures and avoiding them (WAS: Rather funny; looks like page defacement to me)

["Jim Butterworth" <res0qh1m () verizon net>]

        Having just returned from operations abroad as a military
Intrusion Analyst aboard an Aircraft Carrier, where my full time job was
doing Intrusion Detection, I would tend to agree with the assessment
that Intrusion Detection Systems are best left to the trained
professional.  You can quickly find yourself inundated with traffic,
packet aggregation and data mining, engineering installations in a
heavily switched environment, and just get in over your head real quick.
And for what?  That is really what is critical to think about.  Why do
you need, and what is it you intend to get out of it?  Like Mike
mentioned, most folks want to jump right into #3 (real time
notification) right up until the time that they find either their email
or pager is being DOS'd by your IDS sensor because of the immense amount
of false positives that are being generated by your "MUST HAVE" IDS
solution.  To get it right requires trained Intrusion Analysts, and some
time to baseline your traffic and analyze which is normal traffic.   If
your network load is maxing out your 100 Mbps cards on the periphery,
and your servers are getting close to maxing out the ATM/Gig-E cards
you're running, then AT BEST, you'll be pulling about 85% of the
packets, AT BEST! 
        It is imperative to know what it is you want out of the IDS
first, then engineer your solution.  This helps to implement rules,
helps in knowing whether you need a NIDS or HIDS or both solution,
whether you want to feel safe knowing you have a device, whether you
really want to try and stop malicious intent BEFORE it reaches your
network (stateful inspection), whether you want to try and be "Big
Brother" by seeing who is doing what, whether you feel confident enough
to rapidly work in a 95% DHCP network (no MAC reservation), using 8
different subnets, in an ATM environment, employing 6 different VLAN
architectures, using IP tunneling technology, blah blah blah...
        My point is, if you want to do Intrusion Detection, convince the
bean counters and money holders to hire some folks, and fund some
hardware acquisition.  If they are just treating it like an insurance
policy, MAKE DAMN SURE you get them to sign a disclosure agreement that
when your network gets hit, you are not responsible, because if you just
let them get away with bare bones, and you don't advise them to the
contrary, you will be perceived as being responsible because they
"bought you" a solution.  You are responsible to advise them, or don't
so it.  You'll give THEM a sense of security that YOU'RE responsible
for.  
        Also, be prepared to defend the investment of an Intrusion
Detection solution when you go months without ever capturing that zero
day (no notice) attack.  [Remember, the rules are based upon signatures
from documented attacks, meaning stuff that already happened]   What a
proper IDS will provide for you is:
#1 - Who is talking to my network?
#2 - Who is my network talking to?
#3 - Which ports are my applications using repeatedly?
#4 - Alerts of script kiddie sort of probes, scans, fingers, etc...
#5 - What is the normal behavior of my network
#6 - Needing to learn how to write/modify rule sets for YOUR
installation
#7 - When my network is talking outside my home, what is the nature of
the connection?
#8 - "I didn't know AOL Instant Messenger wasn't authorized!"  -  Johnny
SYSADMIN, 2003
#9 - An awareness that there is so much more to learn
#10 - an IDS solution IS NOT an antivirus solution!!!!!!!!!!!!!!!!!!!!!
Make them understand!!!!!!!!!!!

R/Jim Butterworth
SANS GCIA

-----Original Message-----
From: Mike Lyman [mailto:mlyman () west-point org] 
Sent: Saturday, June 14, 2003 11:42 AM
To: focus-ids () securityfocus com
Subject: RE: IDS failures and avoiding them (WAS: Rather funny; looks
like page defacement to me)

>   So most IDS systems are a waste of money. They may be 
> useful if they are installed by a MSSP who actually 
> understands security, but not by the average sysadmin handed 
> another box and told to install the IDS because the auditors 
> say we need one.

I've given this area a lot of thought lately because we are
reevaluating parts of our system and I've talked with other orgs where
their IDS deployments have been at best disappointing and in some
cases disasters.

In my mind, IDSs can serve four basic purposes:

1) Intelligence gathering
2) Investigation support
3) Real-time intrusion detection and investigation
4) Intrusion Prevention

I've listed them in order of what I think the resource required are
and the knowledge required are. The lines blur between the purposes
quite a bit and intelligence gathering systems can occasionally result
in intrusion prevention and intrusion prevention can certainly provide
intelligence. Still, I think the four basic purposes are a good way to
look at things.

I think most deployments are a disappointment because too many places
aim immediately for 3 & 4 without the knowledge, experience or
resources to make it successful. It is better to start small, gain
experience and grow as you are able. Some may argue that starting
small will not get you the full benefit of IDS but you will gain some
benefit and some benefit is better than none and could very well be
better than a failed deployment.

A good example of starting small was our deployment of HIDS. Most
people seem to think about targeting their critical systems
immediately. We went after the desktops first. Our thinking was based
on a number of things. First, at the time we lacked the testing
resources to do the testing necessary to move into business critical
systems and at the time if we impacted performance at all, we'd have
to be willing to cough up the resources to make up for the impact.
Second, we knew the desktops were the low hanging fruit that would be
the places first targeted by an intruder. Third, we knew that we could
detect reconnaissance just as well on the desktops as we could on the
servers and probably better because there are more desktops. Finally,
there are lots of spare resources on the desktop and impacts there
were far less likely to be noticed and if necessary, we could easily
uninstall things.

Admittedly, that desktop HIDS deployment was done as the path of least
resistance but in hindsight, it was a good approach that allowed us to
gain the experience that allowed us to move into the critical systems
with a far more intelligent plan than we would have put together when
we first looked at HIDS. We had proven the technology worked and that
we could gain benefit from it by just shooting for investigation
support and occasionally stretching things to real-time detection. 

We have always shot for 1 and 2 and still have occasionally been
disappointed by parts of our deployment but those disappointments
never resulted in us scraping IDS completely. In shooting for 1 and 2,
we have gained valuable experience, learned to tune things for our
environment and been able to sometimes create and stretch things into
3 and 4 without the resources that are often required to normally get
to those levels.

Of course there are exceptions. Small environments or environments
with the right people and skills might get to 3 and 4 quickly and with
fewer resources than other places and improved technology are helping
as well. As usually, YMMV.

Sometimes it is better to look for even a partial solution than a 100%
solution. You still get benefit and are less likely to fail than you
are shooting for a complete solution in one fell swoop when you are
ill prepared for the complete solution.

Mike Lyman
CISSP
mlyman () west-point org
pgp keyid 0xD7BBADAD 


------------------------------------------------------------------------
-------
Attend the Black Hat Briefings & Training, July 28 - 31 in Las Vegas,
the 
world's premier technical IT security event! 10 tracks, 15 training
sessions, 
1,800 delegates from 30 nations including all of the top experts, from
CSO's to 
"underground" security specialists.  See for yourself what the buzz is
about!  
Early-bird registration ends July 3.  This event will sell out.
www.blackhat.com
------------------------------------------------------------------------
-------


-------------------------------------------------------------------------------
Attend the Black Hat Briefings & Training, July 28 - 31 in Las Vegas, the 
world's premier technical IT security event! 10 tracks, 15 training sessions, 
1,800 delegates from 30 nations including all of the top experts, from CSO's to 
"underground" security specialists.  See for yourself what the buzz is about!  
Early-bird registration ends July 3.  This event will sell out. www.blackhat.com
-------------------------------------------------------------------------------