September 4, 2007

Application Security Log Output Standards – Gartner’s View

Filed under: Uncategorized — @ 4th of September 2007, 00:01

While I am on a roll, talking about normalization and log standards, let me have a look at a publication from Gartner. It is a bit dated already (May 2006), but people are probably still referring to it. There are a couple of things that I want to make sure people understand.
While I like the fact that someone like Gartner is trying to dive into a technical topic, I am not too certain that this is very productive. The Gartner publication I am looking at is “Define Application Security Log Output Standards” by Amrit Williams. I must say, the publication is not horribly wrong or bad, however, there are some interesting problems that I want to address:

  • The publication outlines what fields should be contained in an “account access event”. Most of the fields make sense. However, there are two fields: “login success” and “login failure”. These fields should be normalized. There shouldn’t be two fields, one for success and one for failure. Just have one that indicates success or failure. That way you can correlate those two events against each other. Otherwise you can’t because you have two different fields. Well, you can, but it’s much more difficult.
  • Another field in the account access event is “access rights”. If you include this field in an event, you need a system which can deal with sets or lists of values. This is not simple and I don’t think any of the SIMs really take care of that. Not that they shouldn’t, but it’s really really expensive to build that into a correlation engine. Now, in this specific instance, for access rights, they should not be in an event anyways. This is static information that should be read into the correlation engine asynchronously or looked up on a need to know bases.
  • The publication further indicates that the access events have additional variables, called “Variable 1”, “Variable 2”, etc. I have no idea what these fields would be used for. But that’s not even important. The important part is that having generic variables without a fixed meaning is not very useful for later consumption in reports or correlation rules. You need a semantic associated with every field. That’s exactly why there is a common event language to start with!
  • The same mistake with splitting out the same type of events into multiple event fields is done in the “account /role management events”. Make one field tat talks about “creation”, “modification”, etc. One of the things to mention in this context is an event taxonomy. I am working on a generic taxonomy right now for CEE, the common event exchange format. CEE is an effort that I pushed Mitre to address a long time ago. Finally, there is a small working group and we should soon have the <A href=”http://cee.mitre.org”>Web presence</A> up and running.
  • I don’t agree with the “Log Output Formats” discussion at all. Sorry. Gartner (or Amrit?) recommends syslog as output format. While I am quite a fan of syslog, it’s definitely not my transport of choice. Read that again: TRANSPORT! Syslog is not a log format. It’s a transport. I am not going to roll-up my rant about formats and transports again. Read my older blog entry about the <a href=”http://raffy.ch/blog/2007/04/19/standard-logging-format-common-event-exchange-cee/”>format vs. transport</A> issue.
  • It seems really interesting to me that syslog is pushed as the “log format” (again, it’s a transport, but whatever). The publication even mentions all the RFCs associated with syslog, but not a single sentence about the draw backs. Unstructured, reliability (okay TCP is mentioned), poor timestamp, etc.

Again, I think it’s great that Gartner picked this topic up. It’s incredibly important, but it takes a fair amount of work and experience to get a decent log standard put together. Stay tuned and check back for more information about <a href=”http://raffy.ch/blog/2007/04/23/common-event-expression-cee/>CEE</A>.

Technorati Tags: , , ,

1 Comment »

  1. Raffy,

    Thanks for taking the time to review the document. Originally I wrote this to address a large series of calls from clients that were dealing with in many cases hundreds, yes hundreds, of internal applications. 99.99% of the time the log output for these internal applications was limited to debug information for the developers, if anything all. The majority of these customers were also undertaking a SIEM or log management initiative and struggling to configure the SIEMs/log managers to collect data from these customer defined data sources. At the same time I was doing some research on web services security and was running into a similar issue – hundreds of internally developd applications (primarily web-based in this area) with organizations looking to improve the security, most of which had a centralized method for log management. At the time there was nothing readily available that wasn’t tainted by a vendor perspective that I could provide these folks as a foundation to implement a standard log output for internally developed applications. I wasn’t looking to boil the ocean, just get an organization to implement a policy that all internally developed applications would generate security oriented log output that could be easily consumed by a internally developed, or commercial log management system or SIEM. I also worked closely with the IAM/user provisioning analysts who were taking similar calls from their constituents.

    Anyway I think your feedback is valid, although perhaps a bit nitpicky 😉

    Comment by Amrit — September 27, 2007 @ 9:16 pm

RSS feed for comments on this post. | TrackBack URI

Leave a comment

XHTML ( You can use these tags): <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> .