The IDMEF RFC provides for two kinds of identifiers:

• The "id" (analyzerid, messageid) is used to uniquely identify message creators (analyzers), and individual messages. This may be important and serve as a unique key for alerts. The key question here is whether it is acceptable to ensure unique analyzerid in a SIEM deployment or not. I assume that one would want to know what the sensors are, so it should be feasible.
• The "ident" (Classification, Source, Target, Node, User, Process, Service, File, Address, and UserId classes) originally had a different purpose. The goal was to reduce the volume of messages, by referencing a previously sent entity by its "ident", instead of retransmitting the whole information. It seems that no other format does this, and that the cost of memorizing idents is higher than the cost of simply retransmitting the information.

I would therefore would suggest that we recommend ensuring the id uniqueness, but deprecate the ident as too complex for proper implementation.

The IDMEF RFC provides several subclasses of the Alert class:

• ToolAlert should provide additional information if a specific attack tool has been detected.
• OverflowAlert should provide additional information if a buffer overflow has been detected.
• CorrelationAlert should provide information about alerts that are correlated in some way, generally by some alert correlation process.

It seems that the first two classes are rarely used, although for different reasons. For buffer overflows, this kind of attacks, which was prevalent at the time of writing the RFC, and particularly in the context of C programs, has been less prevalent and has been less useful. For tools, there are so many attack tools that it is definitively hard to produce that information.

Therefore, one question that comes here would be to deprecate subclassing entirely, and to promote CorrelationAlert as a new full IDMEF message, rethinking its structure and purpose.

I personnally would not deprecate theses classes.

Sure, they are not used much in the current context, but they do provide valuable information that would be stored as AdditionalData otherwise. And AdditionalData has a great deal of problem on the storage side.

Hervé Debar wrote:

The IDMEF RFC provides for two kinds of identifiers:

• The "id" (analyzerid, messageid) is used to uniquely identify message creators (analyzers), and individual messages. This may be important and serve as a unique key for alerts. The key question here is whether it is acceptable to ensure unique analyzerid in a SIEM deployment or not. I assume that one would want to know what the sensors are, so it should be feasible.

As a matter of fact, ensuring unique AnalyzerID has never been a problem in the context of Prelude. We rely on UUID generation at sensor registration time for that purpose.

• The "ident" (Classification, Source, Target, Node, User, Process, Service, File, Address, and UserId classes) originally had a different purpose. The goal was to reduce the volume of messages, by referencing a previously sent entity by its "ident", instead of retransmitting the whole information. It seems that no other format does this, and that the cost of memorizing idents is higher than the cost of simply retransmitting the information.

I would therefore would suggest that we recommend ensuring the id uniqueness, but deprecate the ident as too complex for proper implementatio

n.

I am not too sure about that. Ensuring object uniqueness come at a cost : you have to compute a hash of the various values available into a given IDMEF class. In the context of Prelude, this is not currently used, but I can think of usecase where this behavior would be useful, and would actually speed up data processing.

However, I think it would be usefull to standardize the way ident are computed : if different systems use different algorithms, then this greatly limit interoperability.