It's a man-in-the-middle attack. "The Internet's Biggest Security Hole"  has been that interior relays have always been trusted even though they are not trustworthy.

That could apply word for word to how MQ Series and other enterprise messaging systems are deployed. Let's say you are a bank and have been happily running your business on a mainframe for decades. Life is good, come in at 9 leave at 5, count the cash. Then some dotcommer comes along and tells you that you need to get online. What are you gonna do? Rewrite your whole system from scratch? Hard to make that case.

First of all, let’s ground the discussion a bit by translating “smart order routing” to “rule-based message routing” since in this application “smart”  translates to “using rules” and “order” translates to “message”.    Basically, Mark (and other “new on the routing scene” stream processing players) argue that rule-based message routing is CEP.  I will argue that routing is not even close to CEP.  Here is why,

Let’s take a look at a router on the backbone of the global Internet.   A backbone router has very sophisticated software developed over many decades.   These routers run sophisticated, mature algorithms to determine how to route messages (packets) and use these algorithms to build complex routing tables. 

In addition, these routers process messages (packets) from countless sources and route messages (packets) to countless destinations.  Using some of the terms in early posts (above), there is a great “confluence of events” processed by routers.    Futhermore, there are normally quite complex authentication, authorization and other security parameters managed in a router, all in real time.   Routers do much more, but I don’t want to get too deep into routing in this post.

My point is that, without any doubt, global Internet routers process very “cloudy” “confluence of events” with much more sophistication than order routing applications.    However, we do not call Internet routing “CEP”, regardless of how many connections are processed or how much sophisticated processing occurs.  The reason is because the “C” in “CEP” defines a complexity that is at a higher abstraction than messaging and routing.

If you study the literature on CEP, some of which I posted recently, CEP was envisioned to solve complex event processing problems “on top of the routing layer” because the routing layer is a mature technology layer.  We can route, pure and simple.  Of course, we are always seeking faster, more scaleable and more secure routing. 

I admire some of the startups in the CEP/ESP/EP space for working hard to make money and for aggressively positioning their products and attempting to build market share.   However, issues surface when these same companies seem to believe they are the first companies to work in the event processing or message routing space and that they can define whatever they want as “complex event processing” as long as it benefits their sales targets.

There is no doubt that a router does much more sophisticated event processing than the new rule-based stream processing systems running continuous queries across streaming data.  There is no doubt that a router processes a complex “confluence of events”.   However, we don’t call routers “CEP”. 

We do not call routers “CEP” because CEP is about a higher level of knowledge processing.  CEP was created to detect the “complex events” that happen above the mediation and routing layer.     The literature and original examples on CEP are quite clear on this.

I agree with Mark that SOR is important and very interesting; but in his reply he seems to be confusing CEP with “complex EAI” or a “complex messaging” application.  For example, Mark says,

“It’s not uncommon for a single SOR system to connect to 10 or more markets and multiple asset classes.  Not only is this a confluence of events, it’s a stunningly complicated environment in which to create a complex, real-time model in which to apply “simple” routing decisions. On this basis alone, SOR needs CEP.”

Connecting to many market feeds with multiple asset classes might be complicated, but “complicated connections” are an EAI  (adaptation layer) function, not a core CEP function.   In fact, TIBCO Software has been doing this type of low latency back-office order routing for many years, and TIBCO historically calls this “messaging.”  Adding some rules to high speed, low latency messaging does not make it a “CEP” application.

Mark goes on to set up a counter argument to ILOG’s Changhai Ke, comments with,

“SOR operates by analyzing the confluence of events from market data feeds, order flows from OMS systems, and executions, aggregating and analyzing those events in real time, and adjust routing decisions on the fly.”

This is the well travelled argument the “new stream processing vendors in capital markets” have been saying, still unconvincingly, for the last few years.  Basically their perspective is that if you have a lot of ”feeds” and a core requirement for “speed” - “feeds and speed” - you are doing “complex event processing.” 

Mark Palmer forcefully stated his opinon that the folks who do not agree with him do not “understand” modern day SOR.    However,  a strong counter argument can be made that the “newcomers” to capital markets like StreamBase do not understand that “feeds and speeds” with order routing is little more than moderan day EAI.   This is a basic message routing capability and it has been around for a long time.  After all, Wall Street operated quite well before the term CEP was coined!  TIBCO technology was providing Wall Street back office, low latency, smart order routing a decade ago, and they called this technology “messaging”.  

So, I remain unconvinced, at least by Mark’s passionate counter post, that SOR is CEP.   SOR, as Mark and other have described it, is a low latency messaging technology.  Message routing rules have exisited in this technology space for decades.

I agree with Mark completely that low latency EAI (like SOR has been described) can be quite complex, from a “feeds and speeds” perspective.   However,  I remain skeptical that “feeds and speeds” is much more than  modern day messaging and message routing.

In closing, in the network and security management world we have been dealing with “myriad feeds and speeds” for as long as I can remember, but admitted not like capital markets.    Taking myriad feeds, running rules against the feeds and then routing the messages/events for further processing, regardless of the complexity of the feeds and the data, is actually more of a messaging/ESB technology than a CEP technology. 

I remain completely open minded to any convincing counter arguments.

My goal at that time was to show everyone that there was a very mature (functional) reference architecture with decades of maturity that applies to (complex) event processing, adapted from the JDL model for information fusion.  Kum Bai Ya.

There is plenty of room for everyone in this model.  Kum Bai Ya.

The model is inclusine not exclusive. Kum Bai Ya.

The JDL model is based on years of operational maturity.  Kum Bai Ya.

The model is functionally and technically accurate.  Kum Bai Ya.

Everyone at the first event processing symposium (March 2006) seemed to agree with this model, at least publicly, because there was no “push back” at the symposium.  Kum Bai Ya.

Professor David Luckham did not discuss architecture in his book, The Power of Events.  Kum Bai Ya.

David’s research at Stanford, some CEP related, was funded by DARPA, who also support the JDL information fusion model.  Kum Bai Ya.

TIBCO Software adopted the JDL model (Note: I worked for TIBCO the time.) Kum Bai Ya.

We built a functional reference architecture around this mature model.  Kum Bai Ya.

We did not claim we invented it.  Kum Bai Ya.

We did not patent the model, only shared it. Kum Bai Ya.

The model is free and open for everyone to use.  Kum Bai Ya.

The folks in the military and government totally agree with this model for CEP/EP.  Kum Bai Ya.

Complex operational problems are addressed every day with this model. Kum Bai Ya.

Air traffic control uses this model.  Kum Bai Ya.

Missile defense uses this model to protect us from harm everyday.  Kum Bai Ya.

Intrusion detection and network management now use this model (Note: I published an ACM paper on adapting this model for cybersecurity 10 years ago). Kum Bai Ya.

Oh, blog-o-sphere.  Kum Bai Ya.

Preface

The TCP/IP protocols were conceived during a time that was quite different from the hostile environment they operate in now. Yet a direct result of their effectiveness and widespread early adoption is that much of today's global economy remains dependent upon them.

While many textbooks and articles have created the myth that the Internet Protocols (IP) were designed for warfare environments, the top level goal for the DARPA Internet Program was the sharing of large service machines on the ARPANET. As a result, many protocol specifications focus only on the operational aspects of the protocols they specify and overlook their security implications.

Though Internet technology has evolved, the building blocks are basically the same core protocols adopted by the ARPANET more than two decades ago. During the last twenty years many vulnerabilities have been identified in the TCP/IP stacks of a number of systems. Some were flaws in protocol implementations which affect only a reduced number of systems. Others were flaws in the protocols themselves affecting virtually every existing implementation. Even in the last couple of years researchers were still working on security problems in the core protocols.

The discovery of vulnerabilities in the TCP/IP protocols led to reports being published by a number of CSIRTs (Computer Security Incident Response Teams) and vendors, which helped to raise awareness about the threats as well as the best mitigations known at the time the reports were published.

Much of the effort of the security community on the Internet protocols did not result in official documents (RFCs) being issued by the IETF (Internet Engineering Task Force) leading to a situation in which "known" security problems have not always been addressed by all vendors. In many cases vendors have implemented quick "fixes" to protocol flaws without a careful analysis of their effectiveness and their impact on interoperability.

As a result, any system built in the future according to the official TCP/IP specifications might reincarnate security flaws that have already hit our communication systems in the past.

Producing a secure TCP/IP implementation nowadays is a very difficult task partly because of no single document that can serve as a security roadmap for the protocols.

There is clearly a need for a companion document to the IETF specifications that discusses the security aspects and implications of the protocols, identifies the possible threats, proposes possible counter-measures, and analyses their respective effectiveness.

This document is the result of an assessment of the IETF specifications of the Internet Protocol from a security point of view. Possible threats were identified and, where possible, counter-measures were proposed. Additionally, many implementation flaws that have led to security vulnerabilities have been referenced in the hope that future implementations will not incur the same problems. This document does not limit itself to performing a security assessment of the relevant IETF specification but also offers an assessment of common implementation strategies.

Whilst not aiming to be the final word on the security of the IP, this document aims to raise awareness about the many security threats based on the IP protocol that have been faced in the past, those that we are currently facing, and those we may still have to deal with in the future. It provides advice for the secure implementation of the IP, and also insights about the security aspects of the IP that may be of help to the Internet operations community.

Feedback from the community is more than encouraged to help this document be as accurate as possible and to keep it updated as new threats are discovered.

At Consumer Reports, we have always believed that scientific testing is the best way to evaluate products. We also use a statistically-valid survey methodology to measure consumer experiences. In preparing our September security reports, we employed both methods as we have for many decades. Some additional notes on this column:

• The story was not, as you state, "filled with data sourced to eMarketer." That service provided just two pieces of data, namely the current number of Internet- and broadband-using U.S. Households
• Using a separate credit card for online transactions avoids having to cancel your main card should fraud occur.
• We test software against modified versions of actual malware because such threats are what security software will often be called upon to recognize on the job.

Finally, a note about your claim that Consumer Reports was invited to respond. Your e-mail to us requesting a comment was time-stamped on the same Saturday evening as your column is labeled as having posted. That left fewer than six hours to respond, on a weekend. It would have been helpful to have had more time.

This use case is a clear example of a subfunction of complex event processing, folks in the mult-sensor data fusion field (and here at The CEP Blog) refer to as event (object) refinement, sometimes called “track and trace.”

The reason we call this processing function “event (object) refinement” is that, in the way the use case was described in the press release, the medical staff are basically tracking body temperature and comparing it to a key indicator to generate an alarm, in this case “body temperature too high.”   This is a simple event, not complex, because the level of inference is quite very low in an overall knowledge hierarchy.

For example, we cannot infer from the alarm that “body temperature too high” is caused by a previous medical condition.  There is no causality at this stage of the game.   We cannot infer from the alarm that the walker has embarked up a steep hill, and the body temperature is expected to exceed a key indicator for a period of time.

Looking at another complex event model,  the system does not (yet) combine all of the body temperatures of the entire group of walkers, correlated by the situation of an approaching thunderstorm, and infer that the walkers have increased their pace because they don’t want to be caught in a driving rainstorm with high winds.

In other words, tracking a single object like “body temperature” is a basic-step in a CEP application, but not really a CEP application yet, because to really be a complex event, there should be some inference of higher knowledge, or estimated situation.    For example, tracking and tracing the position of an aircraft is good data, but being able to infer the complex situation “potential mid-air crash” between two airplanes is better (defining a complex event vs simply tracking state changes).

Steam processing engines are well suited for track and trace processing of individual event objects, like a walker’s body temperature, or a similar temperature monitoring application from a network device, as demonstrated by the Apama use case.  Tracking events such as “temperature in an object reaches critical threshold” have been going on for decades, in your network, in your car,  in your washing machine, in as spacecraft, just about everywhere we sense-and-respond to temperature changes.

The real marvel of this application was not the event processing on the back end, but in the sensor network, comprised of the human body, an RFID sensor, and a transmission network to a centeralized data collection facility.

The question whether biological viruses are forms of life has been debated, since they lack the respiratory and metabolic process of other accepted life forms. Naturally, different scientists have different reasons for opinions either way.

So how does the new virus-infecting-virus work?

With just 21 genes, Sputnik is tiny compared with its mama — but insidious. When the giant mamavirus infects an amoeba, it uses its large array of genes to build a ‘viral factory’, a hub where new viral particles are made. Sputnik infects this viral factory and seems to hijack its machinery in order to replicate. The team found that cells co-infected with Sputnik produce fewer and often deformed mamavirus particles, making the virus less infective. This suggests that Sputnik is effectively a viral parasite that sickens its host — seemingly the first such example.

…

“It was the cause of great excitement in virology,” says Eugene Koonin at the National Center for Biotechnology Information in Bethesda, Maryland. “It crossed the imaginary boundary between viruses and cellular organisms.”

Science fiction, fantasy and the popular imagination have been fueled in recent decades by the concept of the cyborg, that fusion of machine and creature — but under the scientists’ new definition, even your laptop might be evidence of life…provided it’s infected by a computer virus.