Perimeter
4/16/2012
11:30 AM
Commentary
Commentary
Commentary
Connect Directly
RSS
E-Mail
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
Partner Perspectives
What's This?
In a digital world inundated with advanced security threats, Intel Security seeks to transform how we live and work to keep our information secure. Through hardware and software development, Intel Security delivers robust solutions that integrate security into every layer of every digital device. In combining the security expertise of McAfee with the innovation, performance, and trust of Intel, this vision becomes a reality.

As we rely on technology to enhance our everyday and business life, we must too consider the security of the intellectual property and confidential data that is housed on these devices. As we increase the number of devices we use, we increase the number of gateways and opportunity for security threats. Intel Security takes the “security connected” approach to ensure that every device is secure, and that all security solutions are seamlessly integrated.
Featured Writers
White Papers
Cartoon
Current Issue
Dark Reading's October Tech Digest
Fast data analysis can stymie attacks and strengthen enterprise security. Does your team have the data smarts?
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-2012-2413
Published: 2014-10-20
Cross-site scripting (XSS) vulnerability in the ja_purity template for Joomla! 1.5.26 and earlier allows remote attackers to inject arbitrary web script or HTML via the Mod* cookie parameter to html/modules.php.

CVE-2012-5244
Published: 2014-10-20
Multiple SQL injection vulnerabilities in Banana Dance B.2.6 and earlier allow remote attackers to execute arbitrary SQL commands via the (1) return, (2) display, (3) table, or (4) search parameter to functions/suggest.php; (5) the id parameter to functions/widgets.php, (6) the category parameter to...

CVE-2012-5694
Published: 2014-10-20
Multiple SQL injection vulnerabilities in Bulb Security Smartphone Pentest Framework (SPF) before 0.1.3 allow remote attackers to execute arbitrary SQL commands via the (1) agentPhNo, (2) controlPhNo, (3) agentURLPath, (4) agentControlKey, or (5) platformDD1 parameter to frameworkgui/attach2Agents.p...

CVE-2012-5695
Published: 2014-10-20
Multiple cross-site request forgery (CSRF) vulnerabilities in Bulb Security Smartphone Pentest Framework (SPF) 0.1.2 through 0.1.4 allow remote attackers to hijack the authentication of administrators for requests that conduct (1) shell metacharacter or (2) SQL injection attacks or (3) send an SMS m...

CVE-2012-5696
Published: 2014-10-20
Bulb Security Smartphone Pentest Framework (SPF) before 0.1.3 does not properly restrict access to frameworkgui/config, which allows remote attackers to obtain the plaintext database password via a direct request.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Follow Dark Reading editors into the field as they talk with noted experts from the security world.