Re: Belaboring the point of FPs

• Previous message: Arian J. Evans: "Towards a sound IDS Value Methodology--was-->Gartner is Dead, nCircle, Fusion, asset-correlation..."
• Maybe in reply to: Paul Schmehl: "Belaboring the point of FPs"
• Next in thread: JAVIER OTERO: "RE: IDS is dead, etc"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Fri, 22 Aug 2003 00:13:46 -0400
To: "Graham, Robert (ISS Atlanta)" <rgraham@iss.net>

Hey Robert,

Nice metaphors. :)

There's one bit of context missing from your post, and that is the
original purpose and environments that our respective products evolved
out of. Snort is an open source extensible software framework for
network traffic analysis that many people use as an intrusion detection
system, RS7/BlackICE is a purpose built commercial NIDS engine. I
wrote Snort for the first 2.5 years solely in my spare time and on
what could generously be termed as a shoestring budget with a Pentium
Pro 200 and a couple Celeron 300's as my development and testing
network.

Snort's detection engine was designed in the way that it was as a proof
of concept and inertia being what it is, it took a couple years to get
to the design that we have today. Development is still ongoing, but
suffice to say that we're working on some new stuff that'll be pretty
cool when it comes out.

Snort gives you what you ask for sort of like UNIX/C give you what you
ask for. BlackICE is much more of a black box, Windows to Snort's UNIX
perhaps (and I'm not being snotty, I actually like win2k in my
non-partisan moments). Given the backgrounds of both systems, I think
the reasons for this are obvious. I was building a framework for
everyone to fiddle with and you were building something that was going
to have to be deployed on arbitrary win32 systems, a daunting prospect
from a tech support standpoint so user fiddling with the innards were
to be discouraged as much as possible.

> I don't mean to take this analogy too far, but I'd like to point out
> the
> stories of genies-in-bottles who give you exactly what you ask for, but
> not quite what you want. We all know the story of king Midas who wished
> that everything he touched turned to gold -- but then realized the
> folly
> of his ways when he hugged his daughter, which turned her to gold.

Yeah, but if he had been smart about it he could have done better for
himself!

> I'm not saying that this is a BIG problem for Snort, please don't read
> too much into the analogy. It is indeed a good thing that Snort gives
> you what you ask for -- I'm just trying to point that it isn't 100%
> good.

This is kind of a "maturity principle" issue, do we trust people to
take responsibility for their actions and behave in reasonable ways or
not. We would certainly like to think so but history proves otherwise.

> The basic problem is that the Snort rules language is not expressive
> enough to give you what you want. It's like going to a French
> restaurant
> and ordering only those things on the menu that you can pronounce. I
> have friends that order bagels at the morning because they are
> embarrassed by their poor pronunciation of the French word "croissant".
> It's true that the coffee shop is not at fault for delivering what the
> customer asked for, but it doesn't mean the customer is completely
> happy
> with his bagel.

I'd like to amend the above sentence to "The basic problem is that the
Snort rules language is not *always* expressive enough to give you what
you want". This is true and its what leads us to evolve the language.
The byte_test/byte_jump functionality is a direct result of this
problem. The Snort language could use an overhaul sometime in the not
too distant future, it's certainly approaching the point at which we
need to seriously evaluate its functionality and readability as they
relate to ongoing extension and addition to the keyword system.

> I write lots of signatures for my IDS (RealSecure 7). I have written a
> clone of Snort (Trons). Most of the signatures that I write cannot be
> expressed in the Snort rules language. For example, I put an IMAP
> protocol-decode on port 143 that explicitly recognizes what an e-mail
> message is, and therefore won't match any patterns inside it (unless,
> of
> course, those patterns are supposed to be for e-mail messages).
>
> You could certainly extend the Snort rules languages with plugins. The
> 'uricontent' keyword is a good example of a limitation with
> pattern-matching that had to be resolved. You could certainly add a
> plugin for IMAP that resolves the false-positive discussed below, but
> the issue is that nobody has. Such problems can easily be solved within
> the Snort architecture, it's just that when you get Snort today, such
> problems are not solved.

At the same time, it's exceedingly difficult to write this simple Snort
rule as a BlackICE user (TRONS notwithstanding):

alert tcp $EXTERNAL_NET any -> $ANON_FTP 21 (\
flow: to_server, established; \
content: "USER"; nocase; \
content; !"anonymous"; nocase; distance: 1; \
content; !"ftp"; nocase; distance: 1; \
msg: "Non-anonymous login to anonymous FTP server"; \
classtype: policy-violation; \
tag: session 30 seconds; \
sid: 100000; rev: 1;\
)

> Again, I'd like to point out that when you use my IDS, you'll get a set
> of signatures that I wanted to give you. You can certainly add your own
> with the Trons feature and other "protocol-field" capabilities we give
> you, and you can sometimes adjust the signatures, but you DON'T have
> the
> complete ability (like Snort) to arbitrarily change the signatures that
> I wrote for you. As you can expect, since I wrote the signatures in a
> specific way, I believe that you'll get what you 'want' better out of
> my
> IDS than Snort, but it's certainly true that you have less ability to
> 'ask' my IDS to do something slightly different.

This is the basic difference between our approaches, I assumed that I
know nothing about defending people's networks and you decided
differently. My approach, for better or worse, assumes that the user
knows what they're doing or can at least figure it out. I emphasized
flexibility over other traits, but I thought (I believe rightly) that
that is what people wanted.

I think this ultimately boils down to a religious argument, but it's
certainly a valid one.

      -Marty

-- 
Martin Roesch - Founder/CTO, Sourcefire Inc. - (410)290-1616
Sourcefire: Enterprise-class Snort-based IDS Infrastructure
roesch@sourcefire.com - http://www.sourcefire.com
Snort: Open Source Network IDS - http://www.snort.org
---------------------------------------------------------------------------
Attend Black Hat Briefings & Training Federal, September 29-30 (Training), October 1-2 (Briefings) in Tysons Corner, VA; the world’s premier 
technical IT security event.  Modeled after the famous Black Hat event in 
Las Vegas! 6 tracks, 12 training sessions, top speakers and sponsors.  
Symanetc is the Diamond sponsor.  Early-bird registration ends September 6 Visit: www.blackhat.com
---------------------------------------------------------------------------

• Previous message: Arian J. Evans: "Towards a sound IDS Value Methodology--was-->Gartner is Dead, nCircle, Fusion, asset-correlation..."
• Maybe in reply to: Paul Schmehl: "Belaboring the point of FPs"
• Next in thread: JAVIER OTERO: "RE: IDS is dead, etc"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]