Re: How do keep update my rules in Snort 2.0 over Windows 2000?

["Roy S. Rapoport" <snort-users () ols inorganic org>]

On Mon, Jun 02, 2003 at 10:06:38AM -0400, Erek Adams wrote:
>   *  Lowering Cost:  What would the cost be of a successful breakin due to
> auto-updated rules be?  Lets just say that there was a race condition in
> the auto-update script, and the rules.tar.gz file was zapped.  Now you
> have "no rules" and since it's automatic the person updating the rules as
> the good little drone will assume it's working fine...
[...]
> and _only_ after you are certain they are ready to be sent out to your
> sensors.  The sending out to the sensors should be automated, but it
> should be started and controlled by you.

I'm not all that fond of technical solutions to social problems
(disregarding for the moment that this is exactly what all security
systems are), but race conditions (or more properly, their outcomes) are
relatively easy to detect in this sort of situation -- just have your
pusher make sure that the file(/files) Snort is using for its config
actually has some rules in it.

I'm actually far more concerned about either rules being pushed out that
are bad for the enterprise (because they're too permissive) or what
potentially happens when we've modified our own set of rules and then
have them actually overwritten by new rules.  I'd be shocked if there
weren't people out there right now who are modifying the rules that come
with Snort rather than writing their own.

Getting back to the cost thing:  It's the insurance effect.  I mean, I
hate to be Cynical Corporate Guy (able to make cream go sour with his
eyes!), but look at it this way:  If I'm managing an engineering group,
then:
A) If I have more overhead in managing a system, I have to try to get
budget for it -- it's an ordinary expense that can be anticipated and
factored into my expenses.  However!
B) If I get owned by a hacker, that's a completely unusual business
expense and (in my experience) it'll be fairly easy to get management to
react by throwing money at the problem.  

I could go on at length about how "I don't manage that way," but in some
respects, when it comes to non-security issues, I've sometimes had to,
because the above scenario is an instance of a more general issue:  In
general, it's difficult to get budget to fix a problem until it's become
very painful for the whole enterprise.  The company I'm thinking of went
through cycles ~2 year cycles, where they'd first neglect to improve and
maintain infrastructure for a while (because we don't have the money,
and clearly the IT weenies are just geeks looking for toys) and then,
once everything started falling apart, spent money on IT "like a drunken
sailor on shore leave in Thailand," as my boss was fond of saying.  

>   *  Passing the buck:  Let's look at the reality of the this for a
> moment.  Snort isn't "Symantec Anti-Virus".  It doesn't have a "Live Update!"
> button--Hell, it doesn't even have a GUI!  So this auto-updater is some
> sort of program or script that is written by a third party.  If there was
> a problem that caused a lost file or a munged rule, just how would this be
> the fault of Snort or Snort rule writers?

Well, for one thing, how much do you expect the average CIO to know
about Snort?

But more seriously, I was actually thinking about a scenario where a
rule was 'bad' or interacted with my current rules in a 'bad' way to
cause this issue.  That may be impossible.  In the case you're thinking
of, we blame the makers of the updating software, of course.

> them.  That's fine.  But this is where the manual interaction comes in.
> At this point is when you examine the rules, one by one if need be.  Then
> and _only_ after you are certain they are ready to be sent out to your
> sensors.  The sending out to the sensors should be automated, but it
> should be started and controlled by you.

I completely agree with you.  Now, I could be wrong about this, so
correct my misperception, but is this how the big commercial IDS vendors
advocate you do things? Or do they say something like "We make sure to
write the rules so you don't have to, unlike with those OSS IDSs?"

Easy, rather than rigorous, management is important to some people.
Ideally you have both; if you don't (and you almost never do), you end
up finding your own compromise. 

And now we come to another issue:  Why do you develop Snort? Do you care
who uses it? That's not a rhetorical question.  You might develop a tool
because:
A) You want that tool and it's not going to be available if you don't do
it.  Once you have the tool, you don't mind if other people use it, but
that's not a primary goal (I'd argue that given the amount of time you
guys spend on supporting Snort, that's not likely the case here);
B) You think it's a cool tool and want to make sure other people in
small/OSS enterprises can have an alternative to the expensive
commercial IDSs;
C) You think the expensive commercial IDSs suck and you want to blow
them out of the water.

(There are other reasons, of course).

Ease of management, especially for complex systems such as an IDS, is
critical for Enterprise people.  This is exactly where Windows was able
to make inroads because management of IIS servers was easy enough that
Ops Administrators could manage it, rather than the engineers.  Snort
can be more competitive with commercial IDSs, I believe, if it is easier
to manage (at least, easier to manage than without adding some of the
addons).  I'm not arguing that you *should* be more competitive with
commercial IDSs.  I don't know if you care.

> Oh, and that's two penalty drinks [1] for 'Stupid Management Tricks'.  ;-)

Yours in the pursuit of inebriation,
-roy


-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users