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
Current Issue
Dark Reading December Tech Digest
Experts weigh in on the pros and cons of end-user security training.
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-2014-4807
Published: 2014-11-22
Sterling Order Management in IBM Sterling Selling and Fulfillment Suite 9.3.0 before FP8 allows remote authenticated users to cause a denial of service (CPU consumption) via a '\0' character.

CVE-2014-6183
Published: 2014-11-22
IBM Security Network Protection 5.1 before 5.1.0.0 FP13, 5.1.1 before 5.1.1.0 FP8, 5.1.2 before 5.1.2.0 FP9, 5.1.2.1 before FP5, 5.2 before 5.2.0.0 FP5, and 5.3 before 5.3.0.0 FP1 on XGS devices allows remote authenticated users to execute arbitrary commands via unspecified vectors.

CVE-2014-8626
Published: 2014-11-22
Stack-based buffer overflow in the date_from_ISO8601 function in ext/xmlrpc/libxmlrpc/xmlrpc.c in PHP before 5.2.7 allows remote attackers to cause a denial of service (application crash) or possibly execute arbitrary code by including a timezone field in a date, leading to improper XML-RPC encoding...

CVE-2014-8710
Published: 2014-11-22
The decompress_sigcomp_message function in epan/sigcomp-udvm.c in the SigComp UDVM dissector in Wireshark 1.10.x before 1.10.11 allows remote attackers to cause a denial of service (buffer over-read and application crash) via a crafted packet.

CVE-2014-8711
Published: 2014-11-22
Multiple integer overflows in epan/dissectors/packet-amqp.c in the AMQP dissector in Wireshark 1.10.x before 1.10.11 and 1.12.x before 1.12.2 allow remote attackers to cause a denial of service (application crash) via a crafted amqp_0_10 PDU in a packet.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Now that the holiday season is about to begin both online and in stores, will this be yet another season of nonstop gifting to cybercriminals?