Perimeter
4/16/2012
11:30 AM
Commentary
Commentary
Commentary
50%
50%

Log Standards: Put Up, Shut Up, Give Up, Or Throw Up?

Do we need logging standards, or should we just follow the leaders to help direct our logging efforts?

Syslog was developed in the 1980s, and it probably took roughly five minutes of use before someone started complaining about how it wasn't capable enough. When the IETF drafted RFC3164 in 2001, essentially declaring syslog the de facto standard for log transmission, people immediately started talking about how to make a different and "better" standard.

Fast forward to 2012. Syslog is still the de facto log sending standard, but other technologies and methods have emerged to make the transportation and digestion of system logs easier -- and far more customizable. Some standards didn't quite make it, though -- and thanks to my good friend Dr. Anton Chuvakin, we have a detailed listing of headstones. Defense Advanced Research Projects Agency’s (DARPA's) Common Intrusion Detection Framework (CIDF) eventually became the Intrusion Detection Message Exchange Format (IDMEF), which was never really adopted by anyone. MITRE had Common Intrusion Event List (CIEL), but even that was cancelled early on in the process.

The current project-to-standard efforts continue to be lead by the usual suspects. MITRE has the Common Event Expression (CEE) standard, and The Open Group has the XDAS specification -- the two front-runners for something better. Balázs Scheidler’s syslog-ng extends the original syslog model with content-based filtering, rich filtering capabilities, and flexible configuration options, and it adds important features to syslog, like using TCP for transport. Also, Rainer Gerhards' rsyslog supports multithreading, message filtering, and a fully configurable output format. Several vendors also tossed their standards into the ring to help expedite syslog's demise, including IBM (CBE), Webtrends (WELF), ArcSight (CEF), eIQNetworks (OLF), Cisco (SDEE), and Q1 Labs (LEEF), to name a few. Vendors have also exposed APIs to allow third-party products to subscribe to generated logs, typically an XML formatted file with a RESTful API.

So what do you choose? My historical advice to buyers, developers, and vendors was always to look to the infrastructure vendors because they traditionally dictated what event formats and log transport mechanisms would be supported.

The reality in 2012, however, is that infrastructure providers like Cisco, Juniper, and the rest will continue to make do with syslog; though some will argue that they are exploring new methods, the fact remains that syslog will never go away. Application logging, on the other hand, has emerged as a much more complex problem and will likely change the way we generate and consume logs. If you adopt a yet-to-be ratified standard or, even more importantly, a yet-to-be adopted format, you may impact your product’s ability to join in on an enterprise monitoring ecosystem.

The best advice I can give to developers is to design logging mechanisms that are future-proof, i.e., support legacy syslog and explore emerging standards. Also, as a developer, be open to re-evaluating the logging mechanisms you’ve implemented and never settle on the current implementation.

For buyers, make sure the products you use fit into your existing monitoring ecosystem and that you’ve selected a vendor that is open to evolving. If you can get them to commit to it in the contract, then you get bonus points.

Andrew Hay is senior analyst with 451 Research's Enterprise Security Practice (ESP) and is an author of three network security books. Follow him on Twitter: @andrewsmhay

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
MROBINSON000
50%
50%
MROBINSON000,
User Rank: Apprentice
5/2/2012 | 1:31:24 PM
re: Log Standards: Put Up, Shut Up, Give Up, Or Throw Up?
Andrew,

Thank you for sharing some very interesting insights. We would like to
add an application securityGÇÖs company point of view. We believe that logging
functions should be centralized in order for them to behave similarly through
the application and is an essential step in centralizing information security
functionality.-á You can read more here: http://blog.securityinnovation...
Register for Dark Reading Newsletters
White Papers
Cartoon
Latest Comment: nice one
Current Issue
Flash Poll
Title Partner’s Role in Perimeter Security
Title Partner’s Role in Perimeter Security
Considering how prevalent third-party attacks are, we need to ask hard questions about how partners and suppliers are safeguarding systems and data.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2015-1235
Published: 2015-04-19
The ContainerNode::parserRemoveChild function in core/dom/ContainerNode.cpp in the HTML parser in Blink, as used in Google Chrome before 42.0.2311.90, allows remote attackers to bypass the Same Origin Policy via a crafted HTML document with an IFRAME element.

CVE-2015-1236
Published: 2015-04-19
The MediaElementAudioSourceNode::process function in modules/webaudio/MediaElementAudioSourceNode.cpp in the Web Audio API implementation in Blink, as used in Google Chrome before 42.0.2311.90, allows remote attackers to bypass the Same Origin Policy and obtain sensitive audio sample values via a cr...

CVE-2015-1237
Published: 2015-04-19
Use-after-free vulnerability in the RenderFrameImpl::OnMessageReceived function in content/renderer/render_frame_impl.cc in Google Chrome before 42.0.2311.90 allows remote attackers to cause a denial of service or possibly have unspecified other impact via vectors that trigger renderer IPC messages ...

CVE-2015-1238
Published: 2015-04-19
Skia, as used in Google Chrome before 42.0.2311.90, allows remote attackers to cause a denial of service (out-of-bounds write) or possibly have unspecified other impact via unknown vectors.

CVE-2015-1240
Published: 2015-04-19
gpu/blink/webgraphicscontext3d_impl.cc in the WebGL implementation in Google Chrome before 42.0.2311.90 allows remote attackers to cause a denial of service (out-of-bounds read) via a crafted WebGL program that triggers a state inconsistency.

Dark Reading Radio
Archived Dark Reading Radio
Join security and risk expert John Pironti and Dark Reading Editor-in-Chief Tim Wilson for a live online discussion of the sea-changing shift in security strategy and the many ways it is affecting IT and business.