Re: Target based IDS review and discussion in Information Security

[Jeff Nathan <jeff () snort org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'd originally thought I shouldn't post this, but at this point there  
seems no reason not to.

This all began in 2000 when Marty lead the IDS development effort at  
Hiverworld (which is now defunct).  Others involved include Andrew  
Baker, Anne Tenholder and myself.

After a little digging, I came across the very message I was looking  
for (I vividly remember it being posted).  So, just to hammer the point  
home, here's the origin of target based IDS:
http://msgs.securepoint.com/cgi-bin/get/ids-0007/43/1.html

It's always fun to go back and look at old messages posted to IDS  
lists... you can get a sense of where people stood on various issues  
and how their opinions have changed.

- - -Jeff

On Jan 9, 2004, at 2:35 PM, Joel Snyder wrote:

> Marty:
>
> Thanks for the note & the comments.  I am also not ecstatic that the  
> sidebar on "what is Target-based IDS" was omitted from the printed  
> version.  I asked the editor, and he said that they will be running it  
> in an on-line form later with some tie-in to the topic.
>
> I agree 100% with what you said and even tried to get that  
> documentation in!  For the benefit of the readers of this list, I'll  
> include my sidebars as well, which restate what you've said and  
> include the comments from Ron Gula and Robert Graham who participated  
> in the discussion.
>
> I know that the editors of Information Security follow this list, but  
> I'll also cc: them with your note & mine to understand the issues and  
> your concerns.  One of the problems with the magazine world is that  
> space is at a very tight premium and in order to include all of the  
> product comparison, some of the background information is omitted.   
> This is not because we think that the readers cannot handle it, but  
> because there is only so much room for text on a page.  If push comes  
> to shove, the "new information" (i.e., the results of our testing)  
> will generally shove out "background information" (i.e., things which  
> people can learn about via other avenues).
>
> Thanks for the feedback, and thanks for all the help during the  
> review!!!
>
> jms
> ------
>
> What is Target-based Intrusion Detection?
>
> As a new term, “target-based IDS” may not mean the same thing to all  
> vendors.  However, Marty Roesch, an IDS researcher and one of the  
> authors of Snort, defines target-based IDS as having three components.  
> The idea behind target-based IDS is to bring additional information  
> about the systems being probed, attacked or abused to the IDS.  First,  
> and easiest to understand, is prioritization of IDS alerts using  
> information about the systems. Roesch’s company, Sourcefire, is  
> working on a target-based IDS product but has not yet released their  
> full implementation.
>
> “Raw intelligence” is how IDS author Ron Gula, of Tenable Security,  
> describes alerts as they pop out of IDS consoles.  They represent  
> information, but they don’t necessarily have much value.  To turn them  
> into “well-qualified intelligence”---the kind a President uses to  
> justify a war---requires an analyst.  The problem is that analysts are  
> expensive and slow.  Automating the process of qualifying alerts is  
> what target-based intrusion detection is all about.  Give a computer  
> rules for promoting and demoting alerts and you can turn 130,000  
> events (the average daily number we saw in our testing) into a  
> half-dozen that really need looking at.
>
> Roesch names two other components as integral to target based NIDS:  
> host context and network context.  By giving the NIDS more information  
> about the network it is sitting on and the hosts it is protecting, the  
> NIDS sensors themselves can be more accurate and reduce the irrelevant  
> alerts before they reach the console.
>
> Many commercial IDS vendors have incorporated parts of Roesch’s  
> framework into their products, although generally in a very limited  
> way.  For example, NFR Security chose not to participate in this  
> article, but did say that they are beginning to include some  
> operating-system detection code in their sensors which they think will  
> help to reduce the total level of noise in their products.
>
> The most activity in the NIDS market, though, is in the first aspect  
> of target-based IDS: post-processing of alerts to assess their impact  
> and the likely threat.  In this article, we focus on NIDS consoles  
> which filter and qualify alerts.   This aspect of target-based IDS  
> combines a normal IDS engine with post-processing tools to convert  
> alerts from “raw” to “well-qualified.”  All three products we tested  
> worked in a very similar manner.  Alerts flow into the console from  
> the NIDS engine in all their verbose glory.  However, before the  
> console displays the alerts to the security analyst, they are  
> promoted, demoted, or otherwise qualified to help separate them into  
> two piles: vulnerable, and not vulnerable.
>
> Target-based IDS does promotion or demotion using vulnerability  
> information.  It’s not a complicated thing to know what TCP and UDP  
> ports is a system listening on, what applications are running on those  
> ports; what versions of the applications are running, and what patches  
> are applied.  The thinking which goes along with this is also simple:  
> an attack on a system that cannot succeed should be demoted.  An  
> attack against a vulnerable system, or (even worse) a successful  
> attack, should be promoted.
>
> It’s important to understand that the world of NIDS moves very slowly  
> with very small steps.  Target-based IDS in today’s products only does  
> one thing: determine whether or not a system is vulnerable to an  
> attack identified in a particular signature.  Where NIDS is being used  
> to alert on attacks against vulnerable systems, this can reduce an  
> impossibly large pile of alerts to a very reasonable action list.   
> Where NIDS is used for other reasons, such as policy enforcement or  
> monitoring the general level of background radiation, target-based  
> technology doesn’t help.
>
> How Did We Get Here?
>
>
> Most commercial network intrusion detection systems depend on attack  
> signatures to identify malicious or out-of-policy activity.  The one  
> exception is Lancope’s StealthWatch, which is a statistical intrusion  
> detection system based on an entirely different design, looking for  
> deviations in traffic volume and pattern.  Signature-based NIDS is a  
> very CPU-intensive technology.  Before comparing packets against the  
> NIDS database of a thousand or more signatures, the sensors also have  
> to perform a variety of compute-intensive operations such as HTTP  
> normalization, converting URLs in HTTP data streams to a canonical  
> format so that they can be compared against a list of known bad  
> traffic.  To keep from losing packets, NIDS signature writers  
> generally only match against the minimum amount of data needed to  
> validate an attack. Until now, the thinking has been that it is better  
> to catch both suspicious and harmless activity than it is to miss  
> something by being too strict on the signature.
>
> Once you start down this path, IDS engineers start to get very picky  
> about terminology.  The term “false positive” is reserved for places  
> where the IDS actually made an error---where the IDS claimed that an  
> attack attempt occurred, but no such attack really happened.
>
> An example from Snort, the popular open-source IDS, is useful.  In  
> Snort’s signature database, an exploit for the Sendmail SMTP MTA  
> version 8.6.10 is trapped by a signature looking for a particularly  
> strange string: “Croot” followed by 7 tabs, followed by  
> “|Mprog,P=/bin”.  This is meant to appear at the start of an SMTP  
> dialog, but the way the signature is written, Snort will complain  
> anywhere it appears in the message.  This signature shows the balance  
> between performance and coverage.  Because the string is very unlikely  
> to appear in an email message, it’s unlikely to be a true false  
> positive.  However, if you send an email through a mail server  
> protected by Snort with that string in it, bells will ring and sirens  
> will sound.  Unless you were actually attacking Sendmail, you would  
> have a true false positive.
>
> False positives, though, are not the same as “noise:” false alarms,  
> false alerts, glare, or what some are calling “noncontextuals” or  
> “nontextuals,” positive detection of attacks which are contextually  
> irrelevant.  The same example can help us understand IDS noise.  The  
> example signature is for an attack against a specific SMTP MTA at a  
> specific version.  If you run the proper attack tool at the proper  
> time against any SMTP MTA, the IDS will generate an alert.  But if the  
> attack is against some other MTA, or the wrong version of Sendmail,  
> the alert is a false one, pure noise---no compromise is possible.   
> Since the NIDS sees all traffic, it would be possible for the  
> signature to be expanded so that it only triggers if it sees the  
> Sendmail banner earlier on in the message.  Or, perhaps even only the  
> Sendmail banner with a vulnerable version.  But Snort signatures  
> aren’t written that way, and neither are other IDSes.  Performance is  
> the reason: start looking at traffic at that level of detail, and you  
> run out of CPU speed very quickly.
>
> Some IDS vendors are working on making their signature and detection  
> engines smarter, but others are taking a different path: target-based  
> IDS.  The area is still a new one and the products are not entirely  
> fully baked, but the idea is simple.  Take additional information  
> about systems and use it to alter the alarming and alerting functions  
> of the IDS console.  Change the signal-to-noise ratio to increase the  
> signal, and decrease the noise.  Using our example, you’d still get an  
> alert for the Sendmail attack.  But if the attack were simply noise,  
> the alert would be given a low priority; if it were against a  
> vulnerable server, the alert would get a high priority.
>
> Security managers interested in the background radiation level of the  
> Internet can spend all day looking at low priority alerts.  Those  
> looking specifically for threats which need immediate remediation can  
> turn their attention to the short-list of high priority alerts.  At  
> least that’s the theory.  And that’s where our story begins.
>
>
> -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
> Phone: +1 520 324 0494 (voice)  +1 520 324 0495 (FAX)
> jms () Opus1 COM    http://www.opus1.com/jms    Opus One
>
>
> ----------------------------------------------------------------------- 
> ----
> ----------------------------------------------------------------------- 
> ----

- - --
Top security experts.  Cutting edge tools, techniques and information.
Tokyo, Japan   November, 2003   http://www.pacsec.jp

- -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQE//2HLEqr8+Gkj0/0RAvzCAKC2GFPXFlizI2e7/SsVOUQ+m6HXnwCfSeRL
Xb8Ys/ueDyXsTHB3a6Z0mnc=
=AMi7
- -----END PGP SIGNATURE-----



- --
http://cerberus.sourcefire.com/~jeff       (gpg/pgp key id 6923D3FD)
"I want to know God's thoughts... the rest are details."   - Albert  
Einstein
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQE//2HbEqr8+Gkj0/0RAvZbAJ4/8Mz7YmOvbi0HlpXwoUi7HZa+WQCgqJY6
bgan8hYtHlPMZVmWH7CVCvY=
=zOoG
-----END PGP SIGNATURE-----


---------------------------------------------------------------------------
---------------------------------------------------------------------------