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
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-4231
Published: 2015-07-03
The Python interpreter in Cisco NX-OS 6.2(8a) on Nexus 7000 devices allows local users to bypass intended access restrictions and delete an arbitrary VDC's files by leveraging administrative privileges in one VDC, aka Bug ID CSCur08416.

CVE-2015-4232
Published: 2015-07-03
Cisco NX-OS 6.2(10) on Nexus and MDS 9000 devices allows local users to execute arbitrary OS commands by entering crafted tar parameters in the CLI, aka Bug ID CSCus44856.

CVE-2015-4234
Published: 2015-07-03
Cisco NX-OS 6.0(2) and 6.2(2) on Nexus devices has an improper OS configuration, which allows local users to obtain root access via unspecified input to the Python interpreter, aka Bug IDs CSCun02887, CSCur00115, and CSCur00127.

CVE-2015-4237
Published: 2015-07-03
The CLI parser in Cisco NX-OS 4.1(2)E1(1), 6.2(11b), 6.2(12), 7.2(0)ZZ(99.1), 7.2(0)ZZ(99.3), and 9.1(1)SV1(3.1.8) on Nexus devices allows local users to execute arbitrary OS commands via crafted characters in a filename, aka Bug IDs CSCuv08491, CSCuv08443, CSCuv08480, CSCuv08448, CSCuu99291, CSCuv0...

CVE-2015-4239
Published: 2015-07-03
Cisco Adaptive Security Appliance (ASA) Software 9.3(2.243) and 100.13(0.21) allows remote attackers to cause a denial of service (device reload) by sending crafted OSPFv2 packets on the local network, aka Bug ID CSCus84220.

Dark Reading Radio
Archived Dark Reading Radio
Marc Spitler, co-author of the Verizon DBIR will share some of the lesser-known but most intriguing tidbits from the massive report