Re: New rules for su root attempts

Hi,

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

> *  Most of the Prelude users use Snort, so it's a mandatory discussion
> item when we talk about data classification.

Don't forget Ossec, Nufw and soon Clamav, as all the other upcoming sensors. Focusing on a single sensor is a big mistake.

> *  The Correlator is heavily affected by data classification, so is
> also
a mandatory discussion item.

Agreed.

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

As for free text fields, they do not help humans since humans need a graphical interface to see those even. If 
they are classified, we can then improve the graphical interface and make the human experience better.

[...]

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

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

Unless we use classtype, 
unless we have way more event classified than events unclassified.

[...]

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

Since IDMEF is dead, and since Prelude is very active, we will add our custom fields soon or latter. IDMEF is not perfect but it does the job. I am all for adding extra fields, only:
* If they are not in additional data garbage we should get rid of (IMHO there should be a garbage per section instead of a big global chuck)
* If required fields are common to any possible sensor


Keep up the debate open, it is for all of us a big issue.


Cheers,
Sebastien.



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