Just to re-inforce some points that I seem to have difficulties expressing.

1. Timezone. I agree with you to a certain degree. The way you phrase it is what I don’t like. CEF uses the syslog timestamp if syslog is used. And we all know, syslog does not have the timezone, nor the year in the time stamp. Big problem! I agree! However, you can define a key-value pair, called rt, that would define the receiptTime. I don’t think the CEF standard is very specific about that. Maybe that’s something I should clean up.
2. Regarding separating interoperability efforts. Again, we only tried to come up with a syntax. Yes, if you want to exchange events, you NEED a transport. We just want to leave that up to the entities that need to communicate. That’s why part of CEE is a transport. CEF however is not at all in the space to define a transport. It’s only the syntax piece of a logging standard.
3. SignatureIDs and taxonomy. Be careful with your fourth comment. Again, I like to separate taxonomy from syntax. CEF does not talk about a taxonomy. However, it enables a taxonomy! Why? Because we have a concept of identifying a type of event through the signatureID. You need such a concept to have a lookup table for the categories of an event. I buy your arguments in your fourth comment, but again, that’s a problem the taxonomy needs to solve!
4. Just a general remark about CEF. We designed the standard because a lot of companies came to us, asking how they should log or they asked us to review their logging facilities. I have seen pretty much everything that’s out there. So we decided to come up with a very very cheap and easy way to generate standardized events (format). CEE will not be using pure CEF! CEE will most likely define the semantics of event fields. In addition, CEE will likely propose three syntaxes! Yes. Three. Why? Well, something along the lines of CEF: text-based, cheap, simple, fairly fast. However, there are drawbacks of CEF. Expressiveness. For example list values cannot be expressed. Therefore we need XML to have more complex structures. Especially in the apps world, this is of great use! The third instance will be a binary format. All optimized for speed. However, CEE will help standardize the semantics of all the event fields!

So, CEF nor XDAS is what’s cooking in the CEE pot.

Keep the comments coming!

1. I agree that the record format should be standardized separately from transport. However saying “use anything” is simply not useful in a distributed auditing environment. The event producer must use the same transport as the event consumer. In order to do this, they must agree on which transport is to be used. A distributed auditing standard should either designate the transport or define a mechanism by which the producer and consumer reach agreement.

2. It’s not an issue of synchronous or asynchronous, although OF COURSE any auditing standard should support both types of transport. Audit event consumers aren’t just log files; they are also (for example) management consoles and realtime status indicators. A perfectly sensible configuration for a distributed auditing implementation would be to write all events to a local event log, and to alert a remote console only when a high-criticality event occurs. This avoids unecessary network traffic by keeping low-criticality event records off the network but still notifies human operators in a timely fashion when high-criticality events occur. But it can’t be done without some way for producers and consumers to agree on which events each consumer wants to know about.

3. I did not suggest in my posting that the audit event standard should synchronize clocks. I did insist that the standard must allow clock synchronization issues to be addressed. You suggest “use NTP”. Let’s examine that in a specific case. Imagine that a prosecuting attorney is questioning a system administrator on the witness stand in criminal prosecution of a hacking incident. The prosecutor wants to know whether an event record timestamped (in CEF format) JUL 19 2007 10:24:45 on system one happened before or after another event timestamped JUL 19 2007 10:24:44 on system two. The prosecutor will ask a set of questions: were the systems synchronized? (The administrator can answer that both systems were using NTP, but nothing in the log entry supports his testimony on this point because CEF doesn’t attribute timestamps to any time source, so he’ll have to prove this by appealing to some other record). Do the two timestamps refer to the same timezone? (The administrator can answer, but again the CEF standard doesn’t require that timestamps be expressed in Zulu time or allow them to be qualified by a timezone reference). Other questions could be asked which would require information not present in a logfile structured as specified in CEF.

4. I’m happy to hear that CEE will start to define a taxonomy of events. The question of how much event syntax should be defined by the standard basically boils down to balancing the interests of producers and consumers. If you want to make things easy for producers, you leave event syntax and semantics loosely specified. This allows producers to use their existing terminology and do a minimum of translation when creating events. But it makes it very hard for consumers to interpret the results. Does “vendor1:product1:version1:device3:accessDenied” mean the same thing as “vendor1:product1:version2:device7:deniedAccess”, or does it mean something different? It’s impossible to tell without knowing a lot about every link in the vendor->product->version->device chain. My position is that logs are most useful when this tradeoff is made in such a way that event producers do MORE work to put events into a standard syntax and semantics, so that consumers don’t have to do much translation in order to make event log contents intelligible to the human beings who will use them.

Finally, I basically agree that XDAS is not what I want to see standardized. Neither is CEF. What I want, as I said in my own entry on the subject, is something which combines the power & utility of XDAS with the more modern architecture which CEF assumes.