Bob Blakley from the burton group wrote a blog entry about event interoperability standards. This clearly shows that interoperability is a hot topic. However, it also shows that we (CEE) still have to do a lot of work educating the community ;)I want to correct some of Bob’s statements about CEF and provide some more information and thoughts:
- “CEF defines only a record format”. Well, that’s absolutely right and very very intended. You do not HAVE to define anything else. The transport for example is something that should not depend on the syntax and vice versa. I keep haing to make that point. The ArcSight CEF standard is not bound to any transport. Use anything. If you don’t have anything better, use syslog. It is very very very easy to implement. You just marshall a packet, send it to port 514 and done. Yes, it’s not reliable and all, but it’s a very simple and quick start. If you want, use something more complicated and with more capabilities. CEE will be doing exactly the same thing. We’ll break the standard up into four subtypes, separating syntax from transport, recomendation, and taxonomy.
-  “it doesn’t define service interfaces to allow event producers to notify event consumers that an event has been created and is ready to be processed”. Wow, this is interesting. Why would you not just send the event? Why going asynchronous? People, get away from the notion of pulling events!
- “it does not contain any mechanism for dealing with clock synchronization issues in distributed environments”. Since when should an interoperability standard take care of synchronizing clocks? Use NTP. I am just assuming that! The standard should not have to talk about that!
- “[…] CEF leaves the definition of event types (which are called “Signature IDs†[…] ) up to the individual event producers, thus inviting both ID conflict issues and proliferation of different names for events of the same type in different systems.” Half of this is definitely wrong. The other half is again a separation issue. CEF is a syntax standard. Not a taxonomy! Furthermore, you use a combination of deviceVendor, deviceProduct, deviceVersion, and SignatureID for the unique ID. Hence, no overlapping IDs. I know where this is going. Have a look at CPE. Darn, that thing is complex. However, compeltely unnecessary in this case. Let people define their own IDs. They have them already anyways (except for most syslog entries, but there you just make an ID up). I know what I talk about. I have been doing all of this for the last 4 years! What is really missing in the critique is (and yes, I will admit that there are wholes in CEF) that the granularity of defining the signature IDs is not defined. For example, do you use the same ID for all logins? Failed and successful? The answer here is no. I need different ones, but that’s something CEF does not define. Be assured, CEE will!
I also disagree with Bob that multiple standards should be pursued and supported. I will definitely push CEE harder than CEF. It’s open, it’s a community effort, it’s Mitre led, and it’s going to be a more comprehensive approach. We are keeping NIST and all the other interested parties involved. No need for NIST to go out and create yet another standard. There are so many other standards out there also and just because they exist does not mean they are any good. For example XDASÂ is not what I want to see standardized! Why? See my review of XDAS.
[tags]CEE, CEF, event interoperability, standard, event exchange[/tags]
I’ll take your points one by one here.
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.
Comment by Bob Blakley — July 19, 2007 @ 10:42 am
Thanks for leaving a comment Bob!
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!
Comment by Raffael Marty — July 19, 2007 @ 10:58 am
[…] instead of making you register to download it. If you want more detailed information about CEF, check out an older post that I have written when I was still working on […]
Pingback by Raffy » Blog Archive » Common Event Format - Add-on — December 6, 2007 @ 9:31 am
[…] have been interested and been following event interchange formats or logging standards, you know of CEF and CEE. Problem is that we lost funding for CEE, which doesn’t mean that CEE is dead! In […]
Pingback by Security Intelligence and Big Data | raffy.ch – blog » A New and Updated Field Dictionary for Logging Standards — January 19, 2014 @ 2:51 pm