Working form the home office this morning. The best kind of commute. Now, back to my research.

Click here to subscribe to Liquidmatrix Security Digest!

And now, the news…

1. Google to allow third party code in Gmail? | Builder AU
2. Skype patches security policy bypassing vulnerability | ZDNet
3. Experts warn of security-dodging Trojans | vnunet
4. Microsoft Patch Tuesday promises seven fixes | The Register
5. 6 burning questions about network security | Network World
6. ArcSight and VeriSign Enterprise Security Services Launch Global Business Relationship | Compliance Home
7. EU gives mixed response to new U.S. travel laws | Reuters
8. Conroy launches service to warn of e-crimes | Australian IT
9. Are you a computer security professional? | InfoWorld

Tags: News, Daily Links, Security Blog, Information Security, Security News

One of the benefits of working in different countries is to get the perspectives of various client’s event processing problems.    Of interest to event processing professionals, companies are moving away from expensive software solutions and increasingly moving toward experimenting with economical and open software packages to solve complex problems.   

Recently, I was talking with a client about their experience with commercial security event management (SEM) solutions, for example ArcSight.   In his opinion, ArcSight was not a economically viable solution for his company, so he recommended I take a look at Open Service Event Management (OSEM). 
 
OSEM helps organizations collect, filter, and send problem reports for supported systems (ProLiant and Integrity) running compatible agents.   OSEM automatically send service event notifications when system problems are detected.

I have not had a chance to look under the hood of OSEM and see how it can be used to collect and send events to emerging rule-based event processing engines.    However, this looks like an interesting lab project and I would like to hear from readers who has experimented with this systems architecture.

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.

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.

Dan Kaplan over at SC Magazine had an article up today  (they use Intense Debate for comments too)about ArcSight's first day of trading.  It seems that in spite of the overall condition of the market, they went ahead with their planned IPO.  They picked a bad day to do so, as the NASDAQ was off 1.74%. Opening at 9 dollars a share (the low end of their expected range), they closed at 8.78, bouncing off an intra day low of 8.07.

OK not an auspicious start, but I think they deserve credit for putting the ship out in this storm. I remember when I was at Interliant and we were planning our IPO.  Trying to time the market is a fools game.  Sometimes you just have to go for it.  Only time will tell if the market rewards ArcSights gumption to go public at this time or punish them as they have done recently with Sourcefire. For reasons that include purely selfish ones would love to see the public markets be a viable alternative for security companies to pursue liquidity events and access to capital.  Without them no one will be able to gain the girth necessary to compete with the current security monoliths.

Dan Kaplan over at SC Magazine had an article up today  (they use Intense Debate for comments too)about ArcSight's first day of trading.  It seems that in spite of the overall condition of the market, they went ahead with their planned IPO.  They picked a bad day to do so, as the NASDAQ was off 1.74%. Opening at 9 dollars a share (the low end of their expected range), they closed at 8.78, bouncing off an intra day low of 8.07.

OK not an auspicious start, but I think they deserve credit for putting the ship out in this storm. I remember when I was at Interliant and we were planning our IPO.  Trying to time the market is a fools game.  Sometimes you just have to go for it.  Only time will tell if the market rewards ArcSights gumption to go public at this time or punish them as they have done recently with Sourcefire. For reasons that include purely selfish ones would love to see the public markets be a viable alternative for security companies to pursue liquidity events and access to capital.  Without them no one will be able to gain the girth necessary to compete with the current security monoliths.