Project

General

Profile

Class / fields modification

Added by Yoann Vandoorselaere over 6 years ago

The following extension would, in my opinion, be useful:

  • A field containing the data that triggered the event (example: log, IP packet, etc).
  • Fields / class providing a way to store information about an eventual signature that triggered the event. This could also be done through the following modification of the IDMEF Reference class :

- Add the following optional fields: ident, revision, and vendor field (to be used when origin is set to vendor-specific), that might be used to identify the signature.
- url should become optional : it might not be available for a given sensor.


Replies (1)

RE: Class / fields modification - Added by Gilles Lehmann over 6 years ago

Yoann Vandoorselaere wrote:

The following extension would, in my opinion, be useful:

  • A field containing the data that triggered the event (example: log, IP packet, etc).

I agree. At least for the log it is ogten necessary for the operator to see the "original log" (today it's in aditionnal data in Prelude). Even if there is a log manager around it's good to be sure to keep the exact original log. The only problem I see is the volume of data it might generate (?)

  • Fields / class providing a way to store information about an eventual signature that triggered the event. This could also be done through the following modification of the IDMEF Reference class :

- Add the following optional fields: ident, revision, and vendor field (to be used when origin is set to vendor-specific), that might be used to identify the signature.
- url should become optional : it might not be available for a given sensor.

I suppose I agree also, although this information might be more for "expert" but it is necessary (probably more then the log which is often somewhere in log management)

    (1-1/1)