Re: New rules for su root attempts

Le vendredi 25 juillet 2008 à 01:19 +0200, [email protected] a écrit : 
> * Snort is a good representative of an external non-Prelude sensor.
> 
> Snort is a prelude sensor, sensors are always externals. While I agree
> snort cannot be aside (even though we had prelude nids because we
> disagreed with snort),
> we suffer from its mistakes (uncontrollable classification.text). It
> does not mean we should not fix that in a way.

Snort is a good representative since it is probably the widest deployed
sensor, with a large number of rules that we cannot control, making it
harder to categorize the output into a taxonomy.


> > 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.
> 
> Taxonomization == classification.text, maybe a better marketing synonym.
> 
> Correlation engines need classification.text, which is as important as
> the kind of sensor we are dealing with. 

classification.text is a text field: an enumeration member would be
better suited to force a given sensor to rely on the taxonomy
dictionary. 

Although we can keep using classification.text, and making sure the
input value is "acceptable".

> > 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.
> 
> That is the way it is done today, that is want we want to fix because
> the current situation is really a mess. As of today, we
> suffer from the misunderstanding of all those alerts coming from all
> those sensors. And please, if you are too snort centric, forget
> about snort and try to see events as a whole.
> 
> > Snort logs:
> 
> [...]
> 
> > *  Classtype is the most likely candidate.  Unfortunately, there is
> > only
> a small list of different classtypes.  That makes the resulting
> > taxonomy
> *very* vague.
> 
> And the taxonomy must remain vague. It is a primary classification.
> Details come afterwards, digging deeper in the IDMEF message.

Finally, the question is more whether we will be able to fix <insert
sensor name> in a transparent way when <our own|CEE|any taxonomy
dictionary> come out.

Since CEE is supposed to become a standard, it will be easier to push it
for broad range adoption. If there are resistance adopting this
standard, and we wish to keep using this specific dictionary, we will be
able to start thinking about way to overcome the problem (normalization
on the Manager side is an example).

Anyway, the first step will probably be that a first draft of CEE
taxonomy come out so that we can see if we deem it viable for the
Prelude system.


> > What if we introduced a new, additional_data.taxonomy field?
> 
> Please don't. Enough of additional_data garbage because if IDMEF
> insufficient to do a proper job. Classification.text is for what you
> call Taxonomy.

It really depend on the taxonomy draft we decide to adopt in the future.
There might be multiples fields required.


> Since IDMEF is dead, and since Prelude is very active, we will add our
> custom fields soon or latter. 

IDMEF is used by all Prelude sensors, including others IDS from others
companies. I would not say it is a dead standard, even through there is
no active work group improving it at the moment. 

Keep in mind IDMEF has required an enormous amount of work, that
mobilized a lot of persons, and even thought it's not perfect, the
security/SIM landscape owe a lot to it.

-- 
Yoann Vandoorselaere | Responsable R&D / CTO | PreludeIDS Technologies
Tel: +33 (0)8 70 70 21 58                  Fax: +33(0)4 78 42 21 58
http://www.prelude-ids.com

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