Class / fields modification
Added by Yoann Vandoorselaere over 7 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 7 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)