I have just returned from the RSA Conference where I stumbled on a business opportunity that I think is out there for anyone addressing log and event management requirements.

On Thursday, April 23, there was a session entitled “Common Event and Log Standards: Leveling IT’s Tower of Babel.”
The abstract stated, in part, that:

“The IT industry suffers from a lack of standards for event, log, and audit information. Regulatory requirements to retain, protect, and destroy log data continue to increase. Organizations also need better situation awareness and cost control across complex IT security event horizons. The good news is that standards efforts are underway,…”

XDAS (for more info visit http://www.opengroup.org/security/das/xdas_int.htm) is one standard being developed/promoted to address these issues and the Common Event Expression (CEE) language, being developed by Mitre is an even broader effort that will, ultimately, subsume the former (for more information visit http://cee.mitre.org/). …but these efforts are, as a direct consequence of their ambition and generality, complex and solutions/implementations live somewhere in our future.

There is, of course, an established market for log and event management solutions that address the current heterogeneous and, often, incompatible log and event data streams and sources – do a search on “log and event management” as a case in point. Many of the vendors that will pop-up were also exhibiting at the RSA Conference – both promoting the value of Security Event Information Management (SEIM) and capitalizing on the confusion that stems from the lack of standards in this important field.

Well check this out…

In 2008, Microsoft announced that Visual Studio 2010 would include an extended version of Dotfuscator CE that would include, for the first time, the ability to inject tamper detection, application expiry behavior, session monitoring, and feature tracking – all post-build, without programming, on virtually every flavor of the .NET framework.

This move essentially enables the 6 million+ Visual Studio programmers to retroactively add streaming logs to virtually every .NET application ever written – and guess what? They will not only stream to any endpoint specified (dealing with distributed and cloud-based components) – they will ALL SHARE THE SAME SCHEMA!

– PROBLEM SOLVED????

Of course not – but here are some obvious implications

Given the historical adoption precedent of obfuscation, it is highly probable that 30%-40% of .NET developers will experiment with and incorporate these new capabilities into their development efforts. That’s millions of developers and many many thousands of software components.

As post-build injection becomes more widely accepted as a standard practice, the Java community’s adoption of similar capabilities is likely to increase as well (we support injecting the very same “streaming logs” into Java).

OPPORTUNITY

SEIM and Control Vendors – build-in support for the SOAP signals that will soon be a de facto standard on the .NET platform – differentiate your solutions by getting ahead of the .NET 4.0 curve and establishing yourself as a leader in application security event information management (aSEIM).

Application and Information Management Service Providers – expand your practices to address both the opportunities that this kind of application monitoring offers as well as any potential for abuse.

When 6 million of your closest developer friends have a technology in their arsenal – will it be too late for you to claim to be an expert?

For a more chatty discussion also inspired by the RSA Conference on why Cloud Conferences will never replace live events (and therefore, why Cloud Computing will never replace installed software) - visit my personal blog - Applications Are People Too…