Security and Risk Management Strategies Blog

Prospects Brightening for a Common Event Standard

Blogger: Dan Blum

There are two groups actively working to create a common event standard that allows event logs and audit records to be shared and understood across many products, and the good news is that they’re talking to each other:

• Common Event Expression (CEE) language, by Mitre 
• X/Open Distributed Audit Standard (XDAS), by Open Group 

The business benefits of creating a common event standard would be considerable:

• Reduced log management and security information event management (SIEM) system integration costs 
  • Reduced volume of event data and simplification of SIEM architecture 
  • Reduced need for (and increased effectiveness of) normalization 
• Reduced cost of integrating new solutions with security management infrastructures and frameworks 
• Lower cost of integrating event management and audit into cross-enterprise applications (such as federated identity management)
• Faster and simpler data exchange between organizations, vendors and incident response services supporting real time response to threats and attacks 
• Better forensics for a common defense 

Late last year, our Burton Group Security and Risk Management Strategies (SRMS) group decided to push the question of event standards with vendors, trade press, and standards groups. But we felt that we needed evidence of end user enterprise interest and involvement to start doing so. Happily, as we began researching the space, we found that Mitre’s CEE was being driven by the EU, NATO and DoD as well as log management and platform vendors. Burton Group held a conference call discussing common event standards and SIEM with members of the International Information Integrity Institute (I-4), and key stakeholders showed up. The Open Group reports that enterprises as well as vendors are getting involved with XDAS. Clearly, enterprises seem ready to focus on this topic.

Of course, there are challenges ahead. Not only is there no complete common event standard out in the field today, there are many partial standards or solutions, including Syslog; the IETF’s Intrusion Detection Message Exchange Format (IDMEF) and Incident Object Description and Exchange Format (IODEF); the Java Specification Request (JSR) 47 Logging API, WS-Management subscribe/publish APIs and so on. Any comprehensive standard released in the future should work with existing technologies like these as much as possible. Also, there are a number of complexities, including mapping event semantics between different systems, synchronizing time while managing clock drift, and maintaining dynamic event handling policies.

Fortunately, the Mitre and Open Group efforts are gaining traction. Mitre has put up a CEE web site and one can ask to subscribe to the CEE mailing list. Mitre has described its scope as covering standard event taxonomy/terminology, log syntax, log transport and recommendations on what types of events and data elements systems should log. Mitre’s specifications are in the draft stage, and publication for comment is “expected 2008” according to the website. That’s pretty indefinite. But we are told that while not complete, these draft documents will reflect a considerable amount for work that has already been done and can be built upon. It is positive that a CEE community representative says Mitre plans to begin by seeking comments on the underlying goals and requirements for event standards. But to establish a broadly accepted industry standard anytime soon, Mitre and the government/defense community it servers will have to accelerate overly lengthy document review cycles and possibly streamline handling procedures designed for classified information rather than open standards deliberation.

As my colleague Bob Blakley wrote in “An Auditing Standard: Has this rough beast's hour come round at last?” last July, Open Group revived prior work on a specification called “X/Open Distributed Audit Standard” (XDAS).  XDAS addresses the concerns necessary to build a robust distributed security auditing system in a mature and complete way, but its 1990s era C and UNIX interfaces need to be updated. Novell, whose Bandit Project incorporates XDAS, has contributed source code to a new open-source project called OpenXDAS (http://openxdas.sourceforge.net/) which makes an XDAS implementation widely available.

As these two standards efforts proceed, we hear mixed signals. There have been some indications of contention; for example, CEE representatives purport to have a strong emphasis on “simplicity,” while some observers have expressed concern that XDAS may be “too complex.” Of course, the other side of the argument could be that CEE will over-simplify issues, but it’s hard to have that discussion when specifications for CEE aren’t publicly available yet.

Fortunately, olive branches have been extended as well. During the Open Group meetings in January, 2008 Burton Group observed the XDAS and CEE leadership discuss ways they could coordinate and avoid overlaps. For example, CEE and XDAS could make sure that XDAS APIs become a CEE-compatible logging transport and, if both organizations produce data dictionaries for events, they could be perhaps formulated to use a common taxonomy and to avoid schema conflicts and overlaps. We’re also hoping that vendors such as Arcsight, Oracle and CA – who have been proactive about proposing specifications or encouraging the industry to create a common event standard – will be become part of the convergence on a common solution.

In the coming weeks and months, Burton Group will keep watching the event standards space and post more information on how matters develop. Please let us know by commenting on this blog if there are other standards efforts we should be watching, compatibility concerns to address, or other issues and questions you’re concerned about. We hope to continue being a voice for convergence and standardization that helps put the industry on the road to a common event standard by 2009.

The Fox and the Henhouse

Blogger: Bob Blakley

Yesterday Societe Generale, the second-biggest bank in France, announced that it had suffered almost 5 billion Euros in losses due to the activities of one of the bank's derivatives traders.

Societe Generale apologized for the losses, and explained a three-day delay in announcing the fraud publicly by saying that bank officials needed time to unwind as many of the fraudulent positions as possible in order to limit the bank¹s losses.

Although Societe Generale did not identify the trader responsible for the fraud in their initial communications, he has subsequently been identified as one Jerome Kerviel.

Societe Generale's press release regarding the incident can be found here:
http://www.telegraph.co.uk/money/graphics/2008/01/24/socgen.pdf.

The details of the fraud are not yet completely clear, and uninformed speculation is not likely to be helpful.  But the first paragraph of the bank¹s press release deserves comment.

Societe Generale begins by saying this: "Societe Generale Group (the "Group") has uncovered a fraud, exceptional in its size and nature: one trader, responsible for plain vanilla futures hedging on European equity market indices, had taken massive fraudulent directional positions in 2007 and 2008 beyond his limited authority."

Three things about this sentence are worrying.  First, the fraud is described as "exceptional in size and nature".   The good ones always are exceptional in size and nature.  Common frauds aren¹t usually hard to prevent after you¹ve seen a lot of them; the reason you pay a risk manager is to prevent the exceptional frauds.

Second, the bank describes Kerviel¹s job as "plain vanilla futures hedging." The worry here is that the bank¹s risk managers think futures hedging risks not worth worrying about because they¹re just "plain vanilla."

The third worrying thing is the last clause: "one trader... had taken massive fraudulent directional positions... beyond his limited authority." Clearly his authority was NOT limited; the risk management and governance mechanisms of the bank apparently failed to prevent Kerviel from exceeding his authority, and they also apparently failed to detect his actions in time to limit the damage.

Societe Generale goes on to say this in the last half of the first paragraph: "Aided by his in-depth knowledge of the control procedures, resulting from his former employment in the middle-office, he managed to conceal these positions through a scheme of elaborate fictitious transactions."

The governance and risk management lessons are the two usual ones:

1. The fox is a dangerous guard for the henhouse.  It may be safe to move traders into the design of risk-management systems; it is probably not a great idea to move the risk management personnel onto the trading desk.

2. The most dangerous assumption in the security business is the assumption that there are good guys. The risk management system MUST be designed to be secure even against attacks by insiders who have developed and operated it.

The only way to design a system to be secure against these insider attacks is to have strong attestation, transaction tracking, dual control, and supervision features - in other words, to ensure that activities are carried out in public and reviewed in a timely way.

Societe Generale appears to acknowledge these lessons later in the press release, when the bank notes that "The individuals in charge of his [Kerviel's - ed.] supervision will leave the Group."  Firing Kerviel's bosses will not fix the problem; only improving the bank¹s governance will prevent future frauds.

An Auditing Standard: Has this rough beast's hour come round at last?

Photo (C) Ian Glazer All Rights Reserved

Blogger: Bob Blakley

During the Q&A following an SRMS panel I moderated at our recent Catalyst conference, an attendee asked me “What new standard would you most like to see?”.  My answer was “A standard defining mechanisms for generation, collection, and disposition of audit events.”

I’ve wanted this for years, but I’ve not held out a lot of hope.  Auditing has always been the red-headed stepchild of security; everyone grudgingly agrees that it’s important but no one really wants to work on it, because it’s not cool like cryptography (you’ll never see a black syslog t-shirt declaring itself to be a munition).

Imagine my surprise, then, when my proposal drew a warm and enthusiastic response from the audience. The new emphasis on compliance seems to have made the value of good event auditing much clearer than it was fifteen years ago when I first worked on auditing technology.

Clearer to the users, that is… after listening to the audience express its desire for the sort of standard I’d described, the vendors on the panel all donned serious expressions and talked about how hard it would be to get “the vendors” (as if they were talking about someone else!) to agree on such a standard.  One vendor suggested the burden of developing the standard should be handed to NIST, on the grounds that government purchasing could be an adoption driver.

I think that’s a cop-out.  I don’t see any reason – commercial or technical – why an excellent distributed auditing standard couldn’t be developed quickly and adopted widely without resorting to government purchasing schedules and mandates.  I can see lots of reasons why such a standard should be developed, the most important of which is that the standard would supply one of the key missing pieces of the compliance reporting puzzle.

There is some movement in the direction of such a standard.  ArcSight has developed a proposed event record format called “Common Event Format” (CEF for short) and appears to want to standardize it.  It’s a decent start, but it will need more work before it becomes the standard we need.  Most notably, CEF defines only a record format; it doesn’t define service interfaces to allow event producers to notify event consumers that an event has been created and is ready to be processed.  There are also technical deficiencies in the record format itself; it does not contain any mechanism for dealing with clock synchronization issues in distributed environments in which multiple systems are producing events.  This omission makes CEF unsuitable for creating audit records which support forensic determination of the ordering of events which occur on different systems.  Finally, CEF leaves the definition of event types (which are called “Signature IDs” in the specification, in a nod toward the intrusion-detection world) up to the individual event producers, thus inviting both ID conflict issues and proliferation of different names for events of the same type in different systems.  You can get CEF from ArcSight here: http://www.arcsight.com/solutions_cef.htm.

MITRE is apparently starting an effort address some of the issues CEF leaves open through a standardization effort called “Common Event Expression” (CEE).  This effort was announced on several blogs (including here: http://raffy.ch/blog/2007/04/19/standard-logging-format-common-event-exchange-cee/) in April.  But no detailed information about CEE seems to have been published by MITRE yet.

In the meantime, an old standard I worked on all those years ago has been resurrected in not one but two places.  At about the time X/Open and OSF merged to create The Open Group, a standard called “X/Open Distributed Audit Standard” (XDAS) was advanced to “preliminary” status.  XDAS was a great piece of work; it addressed all the concerns necessary to build a robust distributed security auditing system in a mature and complete way.  But it was a child of its time; it was an interface standard for C programs running on UNIX machines.

The Open Group moved on from X/Open’s mission of standardizing UNIX interfaces and OSF’s mission of building distributed system code which could be shared by many vendors, and XDAS got left behind.

But sometimes ideas are too good to die, and it seems that like King Arthur, XDAS was not dead but only sleeping.  The Open Group Security Forum has recognized the need for an audit standard for the modern world, and is revising the specification to remove all the C and UNIX anachronisms and bring the functionality up to date.  The landing page for this effort is here: http://www.opengroup.org/security/.  And Novell, whose Bandit Project incorporates XDAS, has contributed source code to a new open-source project called OpenXDAS (http://openxdas.sourceforge.net/) which makes the XDAS implementation widely available.

Can XDAS be modernized? Can CEF be extended?  What will CEE look like? Which of these efforts should you support?  Or should you press NIST for a standard instead? 

Frankly, I think you should support all of these options.  We’ve been wandering in the audit desert for too long.  Three standards would be infinitely better than none.  One broadly agreed standard would be best of all – especially if that one standard exploited Web 2.0 information distribution channels like RSS.  If we all start going to the meetings, my bet is that the existing efforts will converge pretty quickly on something well-integrated into the Web 2.0 architecture which is lighter than XDAS, more functional than CEF, and more broadly supported than either; this should be the goal.

I’m putting my money (or at least my time) where my mouth is here.  I’ll be at the Open Group Security Forum meeting in Austin next week, working on XDAS again for the first time in a decade.  I’ll let you know how it goes.