The panelists were:
William P. Crowell – former Deputy Director of the National Security Agency
Michael P. Jackson – Deputy Secretary, Department of Homeland Security
Jose A. Rodriguez, Jr. – former Director CIA, National Clandestine Service & CIA, DCI Counterterrorist Center

Overall, it was a very nicely arranged event on a brisk fall evening with about 100 CXO attendees; mostly large but some small government contractors and a few product companies like ScienceLogic that conduct business with military, intelligence and the public sector.

No surprise, given the financial crisis the economy is suffering from that the panelists said we also have a crisis coming on the Federal budget front. This will put enormous pressure on the way Administration thinks, and how and where to spend the $$.

Obama’s tone regarding the issues he will be confronting in the world during the election was encouraging. Make the world more non-partisan and take on the threats that we have in front of us head-on!

The panel was very upfront about current threats. William Crowell said,

“It is highly imprudent to believe that there will not be another 9-11. We have to fund and support the work to stop other attacks. We can only mitigate risk but we can’t eliminate risk. We have to try to absorb the sense of urgency and wake up every day looking at the intelligence screens as if 9-11 happened within the last couple of months.”

He added,

“They (the intelligence community) need the innovation, sense of commitment and urgency that comes from the private sector – a sense of mutual commitment to that mission.”

Predicted Priorities for investment for DHS:

1. Cyber attack as the top issue
2. Nuclear threats including dirty bomb
3. Chemical and biological attacks
4. Explosive attacks against critical infrastructure with maximum # of lives and or financial disruption / loss.
5. Large scale natural disasters – hurricane + earthquakes
6. Border penetration - identity management and border management issues

An Obama administration will spend dollars around these threat vectors. They will want to spend $$ to help state and local governments. Grants to state and local governments should significantly increase with the Obama administration, so think about how you will increase your focus on the state and local government spending initiatives.

Secure border investments – the panelists believe that the new administration will feel compelled to invest here. Michael P. Jackson bluntly said, “You have to make investments in border tools to get meaningful immigration reform.”

Panelists agreed that the 1^st year will be an intense period of scrutiny about fundamental directions. We can’t afford it all at DHS; it is dramatically under budgeted. At TSA/DOT and then at DHS, we spent about $4 Billion on technology investments since 9-11; those investments are now reaching the end of the original service life.

One gripe from the panel that I found humorous: “We don’t have a group of people who think like entrepreneurs.” It is insane how long things last when you buy things in the government. As an example, we are still replacing vacuum tubes in some of the very old FAA gear… this is well beyond what any reasonable person would think these initial investments should/would last.

Final Thoughts:
I actually think that the Obama Administration will be quite favorable to COTS software products, SaaS offerings, and creative financing initiatives from the private sector. The government just won’t have the capital budget to do everything it wants to accomplish. I would say if you look at how intelligently and aggressively Obama used technology to assist his campaign, the odds are good that this new breed of IT talent (which is already really comfortable with SaaS products, blogs, wiki’s, hosted/outsourced Cloud solutions… this team really understands the latest technology trends) will quickly work to bring these new IT paradigms to the Federal marketplace. Clearly the private sector can help the Government achieve more with lower capital budgets – beginning to provide services rather than transaction-based selling. Another clear idea is to think about leasing as a better way to work with the government which going forward will have increased budgets restrictions.

They will likely be in confrontation with members of Congress that won’t change fast enough, however the future of our nation’s ability to fight terror lies in becoming more efficient and effective. It requires the government be flexible enough to figure out what jobs and IT functions to outsource in a nimble and smart way. My prediction: this is great news for Service Providers. Overall the next 4 years should be great for our business as well as the Managed Service Provider/SaaS industry!

Even thought TIBCO’s BusinessEvents does not yet support Bayesian Classifiers, Artificial Neural Networks and other advanced decision support algorithms, it is just a matter of time before TIBCO will add these advanced features “out of the box”.  On the other hand, the extensible nature of TIBCO’s BE makes it possible to add probabalistic computing functionality, however this requires quite a lot of programming and integration work.

When I see a great release like this for TIBCO, it makes me a little nostalgic for “the good old days” travelling the world in the front of the aircraft for TIBCO.   TIBCO has a rich and diverse customer base.  This customer base includes financial services companies; however, TIBCO is much less dependent on financial services than other event processing companies.   So, with TIBCO you not only get great technology, but rock-solid stability in an unstable and uncertain business world.

As a side note, an S&P analyst recently downgraded TIBCO’s stock (TIBX), primarily due to chao in the financial services sector.    Because of TIBCO’s global reach and stability, plus forward vision, advanced technologies and many years of commericial success, the S&P downgrade will create a buying opportunity for TIBCO stock.

“Experienced end users are very intelligent.

These end users know the complex event processing problems they need to solve; and they know the limitations of the current COTS approaches marketed by the CEP community.  Even in Thailand, a country many of you might mistakenly think is not very advanced technologically, there are experts in telecommunications (who run large networks) who are working on very difficult fraud detection applications, and they use neural networks and say the results are very good.   However, there is not one CEP vendor, that I know of, who offers true CEP capability in the form of neural nets.

Almost every major bank, telco, etc. has the same opinion, and the same problem. They need much more capability than streaming joins, selects and rules to solve their complex event processing problems that Dr. Luckham outlined in his book.   The software vendors are attempting to define the CEP market to match their capability; unfortunately, their capabilities do not meet the requirements of the vast majority of end users who have CEP problems to solve.

If the current CEP platforms were truely solving complex event processing problems, annual sales would be orders of magnitudes higher.  Hence, the users have already voted.   The problem is that the CEP community is not listening.”

Not to be overly repetitive,  but the last part of this quote from a year ago is worth highlighting:

“If the current CEP platforms were truely solving complex event processing problems, annual sales would be orders of magnitudes higher.  Hence, the users have already voted.   The problem is that the CEP community is not listening.”

Frankly speaking, nothing in the “CEP world” has changed, technologically speaking, since this September 2007 post was written.  From a sales perspective, we have seen less CEP-related sales in 2008 than in prior years.   If these so called CEP products were actually capability of detecting “real” complex network-centric situations (threats) in real-time, they would be selling faster than a cup of ice water in the blazing hot Sahara desert.

Don’t shoot the messenger.  Build better detection engines!

On the other hand, maybe complex detection is too hard for most of these companies and that is why they focus on routing, mediation and relatively simple rule-based scenarios, versus complex event processing?

Louis Lovas of Progress Apama wrote a complimentary blog entry on the topic at hand, CEP Maturity Models.   In his post, Louis says:

“What a CEP platform has tracks independently of what it is capable of doing. ….. What CEP does, is likely what Tim is referring to when he states we’re in the Technology Trigger phase.”

Peter Lin’s comment, in reply to Louis, concurs:

“Given that COTS CEP has only been around a few years, I think it is safe to say it’s still in the early phase. If we compare it to messaging middleware, which has been around for more than 15 years, CEP isn’t as mature. Another comparison is business rule engines and expert systems. The earliest business rule engines date back to late 80’s. All things considered, I would agree with Tim. COTS CEP still has a lot of time to mature.”

Louis was spot when he said that I was focused on overall CEP functionality; not individual product realiabity.

Independent of how reliable a particular CEP-type application might appear; the overall state-of-the-art of CEP is really quite immature.

In reply to Paul Vincent’s post Is CEP a Service or a Process? I posted Is CEP a Service or a Process? Reloaded.  This post is a follow-up to my dialog with Paul and the CEP community, as a whole.

Some of the more remarkable critical comments on the book “The Power of Events” was that the book did not (for the most part) discuss architecture. 

As we all know, there are many definitions of “architecture;” however, one definition that is easy to discuss, in this context, is that an IT systems ”architecture” represents the components of an IT system and the relationships between the various components in the architecture. 

An architecture can be “technical” or “functional” or “operational” or ”data” centric.  For example, an architecture can be based on an orchestration of service-components, like an SOA.  In another example, an architecture can be represented by the semantics of the data.  In yet another example, an architecture can be represented by the functionality of the components.

Because David’s book on CEP did not address architecture, folks have been free to use any “tool” or “technique” they like, and call it “CEP”.   My focus has been on overall CEP functionality and reference architectures that depict this functionality for solving CEP classes of problems.

This was one of the first topics (issues) with CEP we identified a few years ago; and is why we, including me at my good ole’ days at TIBCO until now, created a functional reference architecture for CEP (also in this blog and the TIBCO CEP blog).

In that functional reference architecture, we discussed and illustrated how CEP should operate as a cooperative (distributed) functional reference architecture to solve most “real” CEP classes of problems.

Therefore,  CEP should not be, generally speaking, considered as a “process” or a “service”,  per se,  because CEP, as a functional reference architecture, depicts the methodologies (functionaility) required to solve complex detection-oriented problems.  This abstract permits CEP to have meaning in a broad context of event processing applications.

Naturally, a functional reference architecture can be viewed as a “service” if all the components in the architecture cooperate to solve a problem and are encapsulated as a service.  In addition, a functional reference architecture can be viewed as a “process” when solving problems in a specific domain.  So, a “process,” in this case, is an instance of the functional reference architecture; and if the instance is packaged as a solution, this solution can be encapsulated as a service.

So, it is misleading, at least in my opinion, to reduce CEP to a “process” or a “service” unless we are discussing a particular solution to a domain problem within a (functional) reference architecture (functional context).

This confusion also manifests itself in the lively debate between Mark Palmer and the blogosphere regarding the maturity of CEP.   Mark and others have created an instance of event processing in capital markets and call it “CEP,” when in fact, what they are doing is COTS algo trading and using one or more functional components of CEP to realize their solution.

The is an important distinction, in my opinion.

Deciphering the Myths Around Complex Event Processing  by Ivy Schmerken stimulated a recent flurry of blog posts about the maturity of CEP, including; Mark Palmer’s CEP Myths: Mature or Not? and Opher Etzion’s On Maturity.

I agree with Ivy.  CEP is not yet a mature technology by any stretch of the imagination.  In fact, I agree with all three of Ivy’s main points about CEP.

In 1998 David C. Luckham and Brian Frasca published a paper, Complex Event Processing in Distributed Systems on a new technology called complex event processing, or CEP (Postscript Version).  In that seminal paper on CEP, the authors said, precisely:

“Complex event processing is a new technology for extracting information from message-based systems.”

Ten years later there are niche players, mostly self-proclaimed CEP vendors,  whom do very little in the way of extracting critical, undiscovered, information from message-based, or event-based, systems.  

A handful of these niche players have informally redefined CEP as “performing low latency calculations across streaming market data.”  The calculations they perform are still relatively straight forward and they focus on how to promote white-box algo trading with commercial-off-the-shelf (COTS) software.  In this domain, we might be better off not using the term CEP at all, as this appears to be simply a type of new-fangled COTS algo trading engine.

The real domain of CEP, we thought, was in detecting complex events, sometime referred to as situations, from your digital event-driven infrastructure - the “event soup” for a lack of a better term.    In this domain, CEP, as COTS software, is still relatively immature and the current self-styled COTS CEP software on the market today is not yet tooled to perform complex situational analysis.

This perspective naturally leads to more energy flowing in-and-around the blogosphere, as folks “dumb down” CEP to be redefined as it benefits their marketing strategy, causing more confusion with customers who want CEP capabilties that have zero to do with low latency, high throughput algo trading, streaming market data processing, which maybe we should call “Capital Market Event Stream Processing” or CESP - but wait we don’t really need more acronyms!

Hold on just a minute!  Wasn’t it just a short couple of years ago that folks were arguing that, in capital markets, it was really ESP, not CEP, remember?  Now folks are saying that it is really CEP and that CEP is mature?   

CEP is mature?  CEP is really not ESP?  CEP is really event-driven SOA?  CEP is really real-time BI?  CEP is really low latency, high throughput, white-box COTs algo trading?  CEP is really not a type of BPM?  CEP is not really for detecting complex events?   Complex does not really  mean complex? 

Come on guys, give us a break! 

(Anyway, no one is going to give us a break….  so stay tuned!)

Let’s talk about the scope creep of Government security, shall we?  Fact of the matter is, it’s going to happen, and you’ll get eventually get caught up in FISMA if you’re one of the following:

• State and local government
• Government contractor
• Telco
• Government service provider
• COTS software vendor
• Utilities who own “Critical Infrastructure”

Why do I say this?  Mainly because just like how the DoD is discovering that it can’t do its InfoSec job without bringing the civilian agencies along due to connectivity and data-sharing issues, the Federal Government is coming to the point where it can’t secure its data without involving these outside entities.  Some are providers, but the interesting ones are “business partners”–the people that share data with the Government.

State and local government are the ones to watch for this pending scope creep.  The Federal Government works on the premise that the responsibility to protect data follows wherever the data goes–not a bad idea, IMO.  If they transfer data to the states, the states need to inherit the security responsibility and appropriate security controls along with it.

Now if I’m a contractor and exchange data with the Government, this is an easy fix:  they don’t pay me if I don’t play along with their security requirements.  When a new requirement comes along, usually we can haggle over it and both sides will absorb a portion of the cost.  While this might be true for some state programs, it becomes a problem when there is no money changing hands and the Federal Government wants to levy its security policies, standards, etc on the states.  Then it becomes a revolt against an unfunded mandate like RealID.

There are some indicators of Federal Government scope creep in the Georgia policy.  This one’s my favorite:

The performance metrics will also enhance the ability of agencies to respond to a variety of federal government mandates and initiatives, including the Federal Information Security Management Act (FISMA).

Georgia on my Mind by SewPixie.

Bookmark to:

The SQL [structured query language] inserts that came earlier were just pablum intended to lull the Army cadets into a false sense of security. But then the bad guys unleashed a stealthy kernel-level rootkit that burrowed into one workstation, started scraping data and "calling home."

It was a highly sophisticated attack, but this time the bad guys were really good guys in wolves' clothing.

For four days in late April, the National Security Agency -- the nation's most secretive repository of spooks, snoops and electronic eavesdroppers -- directed coordinated assaults on custom-built networks at seven of the nation's military academies, including West Point, the Army university 50 miles north of New York City.

It was all part of the seventh annual Cyber Defense Exercise, a training event for future military IT specialists. The exercise offered a rare window into the NSA's toolkit for infiltrating, corrupting or destroying computer networks.

The 34 Army cadets comprising the West Point IT team operated in a different kind of battlefield, but their combat skills and instincts need to be every bit as sharp. Like George Washington said: "There is nothing so likely to produce peace as to be well prepared to meet the enemy."

The SQL injections, targeting their Fedora Core 8 Web server, were a piece of cake for these IT combatants. Each injection tried to smuggle malicious code inside the seemingly harmless language used by the network’s MySQL software. The cadets handily defended with open source Apache web server modules, plus some manual tweaking of the SQL database to "avoid any surprises," in the words of Lt Col. Joe Adams, a West Point instructor who helped coach the team.

But the kernel-level rootkit was much more dangerous. This stealthy operating-system hijacker can open unseen "back doors" into even highly protected networks. When they detected the rootkit's "calls home" the cadets launched Sysinternal's security software to find the hijacker, then they manually scoured the workstation to find the unwelcome executable file.

Then they terminated it. With extreme prejudice.

"This was probably the most challenging part of the exercise, since it required them to use some advanced techniques to find the rootkit," Adams says. And rooting it out helped boost the West Point team to the top of the pile when, in the aftermath of the exercise, the referees rated all the universities' network defenses.

For the second year in a row, the Army placed first over the Navy, Air Force, Coast Guard and others, winning geek bragging rights and the privilege of holding onto a gaudy, 60-pound brass trophy festooned with bald eagles and American flags. Adams credits the team’s thorough preparation and their excellent teamwork despite the round-the-clock schedule.

At the network control room on the second floor of West Point’s 200-year-old engineering building (which once was an indoor horse corral and still smells like it in some remote corners, according to one instructor), the IT team set up cots and, just for the hell of it, camouflaged netting. They worked in shifts, with one team member always monitoring incoming and outgoing traffic. He or she would alert other cadets -- "router guys" -- to block any suspicious addresses. Meanwhile, off-shift cadets would make food and coffee runs to keep everyone fueled up and alert. Together, the team was "faster than anyone else," Adams says.

But the way the cadets designed their network was a big factor in their victory, too. The NSA dictated some terms: All networks had to be capable of e-mail, chat and other services and had to be up and running at all times despite any attacks or defensive measures. Beyond that, the teams were free to come up with their own designs.

West Point's took three weeks to build. The cadets settled on a fairly standard Linux and FreeBSD-based network with advanced routing techniques for steering incoming traffic in directions of the IT team's choosing.

The choices in software tools for responding to any attack really boiled down to "automatic" versus "custom," says Eric Dean, a civilian programmer and instructor. He adds that while automatic tools that do most of their own work are certainly easier, custom tools that allow more manual tweaking are more effective. "I expect one of the 'lessons learned' will be the use of custom tools instead of automatics."

Even with a solid network design and passable software choices, there was an element of intuitiveness required to defend against the NSA, especially once it became clear the agency was using minor, and perhaps somewhat obvious, attacks to screen for sneakier, more serious ones.

"One of the challenges was when they see a scan, deciding if this is it, or if it’s a cover," says Dean. Spotting "cover" attacks meant thinking like the NSA -- something Dean says the cadets did quite well. "I was surprised at their creativity."

Legal limitations were a surprising obstacle to a realistic exercise. Ideally, the teams would be allowed to attack other schools' networks while also defending their own. But only the NSA, with its arsenal of waivers, loopholes, special authorizations (and heaven knows what else) is allowed to take down a U.S. network.

And despite the relative sophistication of the NSA's assaults, the agency told Wired.com that it had tailored its attacks to be just "a little too hard for the strongest undergraduate team to deal with, so that we could distinguish the strongest teams from the weaker ones."

In other words, grasshopper, nice work -- but the NSA is capable of much craftier network take-downs.

In Q&A from BCS SPA meeting on CEP,  friend and colleague Paul Vincent says:

 ”AFAIK there are no current military systems (as opposed to government intelligence systems) using Commercial Off The Shelf CEP systems, although I recall one commercial product being developed with US military money (your tax $ at work, etc etc).”

Actually, Paul’s statement is slightly misleading.   Companies like StreamBase and AgentLogic have their roots in supporting the military.  In addition, IBM has a number of event processing related solutions in the military.   (There are also others, we suspect.)

It is true, however, that current generation COTS CEP engines do not have the advanced event processing capabilities required for most CEP applications  in the military; but as CEP engines advance, this should change.