Re: New rules for su root attempts

Alright, I'm making a few assumptions going into this conversation.
Feel free to challenge them if you feel they're not valid.
*  Snort is a good representative of an external non-Prelude sensor.
*  Most of the Prelude users use Snort, so it's a mandatory discussion
item when we talk about data classification.
*  The Correlator is heavily affected by data classification, so is also
a mandatory discussion item.
Now, what you're talking about below is a taxonomization system.  Most
commercial SEIMs have it.  It's very useful for a correlation engine
because it gives the event context...what does this event mean?  Free
text fields don't do that...free text is useful for humans, but not
computers.
I attempted to accomplish a limited form of that some time ago in the
LML rules by standardizing what the classification.text field would look
like.  I say "limited" because it's not heirarchal as you suggest (which
is the "right" way to do it according to the commercial SEIM world), and
needs to be an exact match to allow the correlation to work between
devices.
A heirarchal system isn't really possible in classification.text.  The
reason is a combination of the fact that classification.text is the
primary front-end view of an event, and because of the way Snort sends
data to us.
Snort logs:
1.  The event payload
2.  The generating sid and revision.
3.  A classtype field.
4.  A msg field.
The msg field is what we currently populate into classification.text,
and is unique to every event, so can't be used to taxonomize.
What *can* we use?
*  Classtype is the most likely candidate.  Unfortunately, there is only
a small list of different classtypes.  That makes the resulting taxonomy
*very* vague.
*  A lookup table that would map sids into their individual taxonomies.
This is technically possible, but someone would actually need to do the
work for it (which is a lot of very boring stuff), and someone would
need to maintain it for new rules.
Neither solution is very good in my opinion, as a replacement for the
current classification.text pseudo-taxonomy.
HOWEVER...
What if we introduced a new, additional_data.taxonomy field?
Additional_data fields are free to use wherever we like, are not
required to be compatible with other IDMEF implementations, and wouldn't
always be required to be present.  In the case of Snort, we could use
the classtype field to generate a vague taxonomy that wouldn't be overly
useful, but would still be there and usable.
One note on heirarchal taxonomies: I've used them before, and found that
sometimes events come around that are difficult to classify in one
branch of the taxonomy or another; they appear to belong to multiple
spots in the taxonomy.  Just keep that in mind.
Comments from anyone?

- Ramon 

-----Original Message-----
From: Steve Grubb [mailto:[email protected]] 
Sent: Thursday, July 24, 2008 9:33 AM
To: G Ramon Gomez
Cc: Sebastien Tricaud; Yoann Vandoorselaere;
[email protected]
Subject: Re: [prelude-devel] New rules for su root attempts

What I'd really like to see is some hierarchial notation that can be
specific and abstract depending on what you need. But I really don't
feel that all kinds of events have been described, classified, and
organized in a way that can be used. From a NIDS perspective, the evnts
are abstract...someone is logging in or trying a know exploit against a
service. From a HIDS point of view, you have very specific
information...pam goes through 4 phases on login and I can see all 4 of
them Failure in one may signal a different kind of issue. 

Authentication, authorization, session open failures all have different
meaning. Authorization could be brute forcing, Authentication could be
someone that stole the password and are now trying to get in from a
remote location. Session open is usually a resource problem not of the
user's making. I'd like to describe both broadly and specifically what
an event means so that it can be used in more ways.

-Steve
_______________________________________________
Prelude-devel site list
[email protected]
http://lists.prelude-ids.org/mailman/listinfo/prelude-devel