[Snort-users] How do keep update my rules in Snort 2.0 over Windows 2000?

Erek Adams erek at ...950...
Mon Jun 2 07:08:29 EDT 2003


On Mon, 2 Jun 2003, Roy S. Rapoport wrote:

[...snip...]

> Now, in an environment where you have deployed the IDS as a political
> tool, automatic rule updates are also a political tool.  They make it so
> you essentially A) Lower the overhead of actually managing and updating
> your IDS; and B) Passing the buck to someone else who'll 'take the fall'
> if something bad happens.  Now, mind you, it's almost a win-win scenario
> because the person who'll be blamed -- the people who develop Snort
> rules, say -- can't actually be harmed by some IT guy going "hey, I
> don't know what happened, I guess they gave us bad rules."  There's a
> potential PR issue, of course.

I understand your points, I just can't agree with them.

  *  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...

  *  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?



Go back and read the old discussions on this.  You'll find two camps on
this issue:  Auto and Manual.  One thing that Auto-folks sometimes miss is
that rule updates can be automated, but to a certain point.  You can
automate a wget and snag the new copy of the rules, and uncompress/untar
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 think of auto-updates like an AutoPilot in an airplane.  No that's not
'The Autopilot' (Otto) in Airplane [0].  :-)  It doesn't land or take off.
It just handles the more routine and monotonous tasks.  Keeps the plane on
course, prepared altitude, turns over control to the pilot when the
weather gets bad, warns if there may be a problem ahead, etc.
Auto-updates should be like that.  Automated except where human
intervention is required.  No matter how good the program, it can never
have the judgment of a real person.

Excellent points, by the way.  Very sad, but possibly all too true.
*sigh*  I guess we should all go thank Microsoft for the 'click and drool'
mentality people seem to be infected with these days...  :-/

> (Oh, and s/IDS/Security Policy/g -- I can't tell you how non-amusing it
> was when I realized that the large Fortune 500 software company with
> whose internal workings I'm most familiar has had five CIOs in three
> years *AND* that every single one of them said fairly early in the
> process "We must have a security policy! Oh, and discard all the work on
> the security policy that my predecessor had paid for!").

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

-----
Erek Adams

   "When things get weird, the weird turn pro."   H.S. Thompson

[0]	http://us.imdb.com/Title?0080339
[1]	http://www.theadamsfamily.net/~erek/snort/drinking_game.txt




More information about the Snort-users mailing list