The Top Ten Cybersecurity Threats for 2009 - Draft for Comments

Here is my draft list of the Top Ten Cybersecurity Threats for 2009.  Your comments are greatly appreciated.  I will publish the final list later this month, based on comments received.

— Constant negative news reporting and adverse analysis undermining public and business confidence in leadership, business management and economic recovery efforts.

— Criminal manipulation, fraud and subversion of financial markets by opportunists and competitors.

— Identity masquerading to abuse, attack, blackmail, bully, extort, terrorize or molest others.

— Criminal fraud by password and identity theft via phishing, pharming, spyware, malware and theft of hardware.

— Criminal use of botnets and botnet-like technologies, for example email (marketing and rumor) spam and denial-of-service attacks.

— Criminal exploitation of social networks.

— Criminal use of cloud computing and software-as-a-service infrastructures for cyberattacks and spam.

— Spying and theft of data by governments, industry, terrorists and other criminals.

— Sabotage, theft and other attacks by disgruntled employees and insiders.

— Natural disasters, accidents, errors and unintended consequences without malicious intent.

Share and Enjoy:
  • Digg
  • StumbleUpon
  • del.icio.us
  • Technorati
  • Facebook
  • Mixx
  • Google
  • Slashdot
  • Furl
  • Reddit
  • Spurl
  • LinkedIn

Predictions for the 2009 CEP Market

Reposted (adapted) from The Complex Events Forum:

David Luckham:  Do you expect the market to expand?

No. The entire software market, for the most part, will have a very tough year in 2009, due to a very serious global economic crisis. Firms that have “bet the farm” on capital markets will suffer even more, as these firms are in a deep recession and IT spending always suffers in these environments. We might see some “smoke-and-mirrors” in CEP marketing-land, claiming an expanding market, but these claims will be unfounded and unsupported. As a side note, the largest software companies (in the CEP space) tend to bundle their CEP sales into enterprise software license deals, so it is nearly impossible to correlate actual CEP software sales and usage with what we read from these large vendors (and their reports are the lion’s share of the market).

David Luckham: Does the CEP technology currently offered by products on the market need improvement? If so, what improvements do you want to see?

Of course they need improvements! If the current generation products on the market actually could detect (difficult to detect) complex events in real-time with high confidence, the market would be much, much larger than it is today. I have discussed this in great detail in 2008, and will spare you all the pain and frustration of reading it again. Cheers!

David Luckham: Are there problems out there that customers are willing to pay to solve, but the current generation of CEP products cannot solve? What are they?

Yes of course there are plenty of “complex event” classes of (difficult and complex) detection-oriented problems people are willing to pay for. As I said before, if the software on the market actually did true “complex event processing” (not a watered down version of “everything is marketable as CEP” as we have seen in 2008) then software would be selling like cold water in the hot, dry desert. This is not rocket science. Proprietary stream processing (continuous query) engines have limited commercial value in the overall market, and the market is overly crowded with these vendors! This situation is unsustainable, especially in this (terrible) economy. As someone else opined, these many “doing the same thing” (ESP) vendors cannot all survive in such a negative business climate with so little new actual value-added technical (detection) capability.

David Luckham: Has the time come to talk about standards or interoperability of CEP products?

Software is already interoperable at the message / transport layer, and messaging is rapidly becoming a service-oriented commodity (see my recent post on Amazon SQS). Interoperability needs to happen at the “complex event modelling layer”, and this is not likely to happen in the foreseeable future, since we have so few “CEP vendors” in this space actually doing what I would call CEP. Most vendors are focused on routing, scheduling and simple (not complex) detection scenarios, a software market which is not sustainable, in my opinion.

David Luckham: And discuss any other CEP questions that come to mind!

Yes! But, I’m busy working on a few cybersecurity predictions and community (Web 2.0) software tasks for a major forum, so “that’s all for now on CEP!”

Share and Enjoy:
  • Digg
  • StumbleUpon
  • del.icio.us
  • Technorati
  • Facebook
  • Mixx
  • Google
  • Slashdot
  • Furl
  • Reddit
  • Spurl
  • LinkedIn

Amazon Simple Queue Service (Amazon SQS)

Does Amazon SQS and other “messaging as a service” applications mean that companies can start to think about reducing their ongoing expenses of licensed or hosted messaging systems?

According to Amazon, Amazon Simple Queue Service (Amazon SQS) offers a reliable, highly scalable, hosted queue for storing messages as they travel between computers. By using Amazon SQS, developers can simply move data between distributed components of their applications that perform different tasks, without losing messages or requiring each component to be always available. Amazon SQS makes it easy to build an automated workflow, working in close conjunction with the Amazon Elastic Compute Cloud (Amazon EC2) and the other AWS infrastructure web services.

Amazon SQS works by exposing Amazon’s web-scale messaging infrastructure as a web service. Any computer on the Internet can add or read messages without any installed software or special firewall configurations. Components of applications using Amazon SQS can run independently, and do not need to be on the same network, developed with the same technologies, or running at the same time.

Functionality:

  • Developers can create an unlimited number of Amazon SQS queues, each of which can send and receive an unlimited number of messages.
  • New messages can be added to a queue at any time. The message body can contain up to 8 KB of text in any format.
  • A computer can check a queue at any time for messages waiting to be read.
  • A message is “locked” while a computer is processing it, keeping other computers from trying to process it simultaneously. If processing fails, the lock will expire and the message will again be available.
  • Messages can be retained in queues for up to 4 days.
  • Developers can access Amazon SQS through standards-based SOAP and Query interfaces designed to work with any Internet-development toolkit.

It may be possible that some software companies selling messaging and SOA software will find they have been “out-serviced” by companies offering cloud-messaging services!

Share and Enjoy:
  • Digg
  • StumbleUpon
  • del.icio.us
  • Technorati
  • Facebook
  • Mixx
  • Google
  • Slashdot
  • Furl
  • Reddit
  • Spurl
  • LinkedIn

Prelude to The Top Ten Cybersecurity Threats for 2009 - Cyberspace

Soon I will publish my The Top Ten Cybersecurity Threats for 2009. However, before doing so, let’s take a look at some interesting aspects of The Top Ten Cybersecurity Threats for 2008.  In my cybersecurity threat list for 2008, I mentioned:

— Criminal manipulation and subversion of financial markets.

What we observed in 2008 was much more than criminal threats. Now we are seeing both intended and unintended consequences of cyberspace.   For example, analysts from competing banks use the Internet to spread “doom and gloom” rumors and flawed analysis to do serious harm to their competitors.

In my post Cyberattack! Manipulation and Subversion of Financial Markets! we discussed the situation of a direct competitor to E*Trade Bank, Citigroup, using the power of cyberspace, rumors and (mis)information to manipulate investor confidence in  E*Trade (ETFC).  This might have not been such an eyebrow raising event if the analyst rumor, released like a bomb in cyberspace, was by a disinterested third party.  The “cybernews bomb” was released by a direct competitor with their own subprime balance sheet problems.  In reality, Citigroup came closer to bankruptcy than E*Trade!

This is a direct abuse of cyberspace and a purposeful, malicious action that can threaten every business in today’s modern networked, connected world.

Moreover, potential more harmful threats are the unintended, not directly malicious “doom and gloom” reports, analysts opinions and news stories, where the entire cyberworld is full of “doom and gloom”, driving the world’s global economics into a downward spiral.

In other words, the biggest looming threat to cyberspace is not the low level hacks and attacks that IT professional often discuss.   The biggest threat is cyberspace itself and how malicious rumors in cyberspace can destroy confidence in sound businesses in milliseconds.  In addition, cyberspace “doom and gloom” has taken on a life of its own, much like a global personality. Unfortunately, we don’t have “cyberdrugs” to treat “doom and gloom” global information-based depression.

Many folks are worried that the global economy will be even worse in 2009.   Never in our history have we had such a global economic downturn combined with global cyberspace “doom and gloom” messaging pumped into our news readers and brains 24 hours a day, 365 days a year, globally and instantaneously.

Indeed, cyberspace itself has become a serious threat, perhaps the greatest threat for 2009.

Share and Enjoy:
  • Digg
  • StumbleUpon
  • del.icio.us
  • Technorati
  • Facebook
  • Mixx
  • Google
  • Slashdot
  • Furl
  • Reddit
  • Spurl
  • LinkedIn

Proposed EPTS Steering Committee Reorganization

Following up to my earlier posts on Event Processing Technical Society (EPTS) related topics, I am proposing a draft reorganization of the EPTS Steering Committee. The current EPTS Steering Committee was structured as follows:

# Industry Primary EPTS-Related Technology Comments
1 Software Company Event Stream Processing / Continuous Query Vendor
2 Software Company Event Stream Processing / Continuous Query Vendor
3 Software Company Event Stream Processing / Continuous Query Vendor
4 Software Company Event Stream Processing / Continuous Query Vendor
5 Software Company Event Stream Processing / Continuous Query Vendor
6 Software Company Rete Rules Engine + Continue Query Engine Vendor
7 Technology Analysis / Convention Host Research Notes, Presentations, White Papers Vendor
8 Independent Consultant CEP Promotion, CEP Web Site Sponsorship, CEP Evangelism Vendor
9 To Be Confirmed To Be Confirmed Vendor
10 To Be Confirmed To Be Confirmed Vendor

Discussion:

The current EPTS Steering Committee (SC) does not represent the art-and-science of event processing. All SC members are vendors and all but two of the SC members are software vendors, all but one of these software sellers are selling very similar products, event stream processing / continuous query engines. There is one industry analyst (a vendor). There is only one independent consultant, evangelist (another vendor).  There are no end users or other industry segments represented on the SC. In a nutshell, the EPTS is composed of vendors, most of which are software vendors selling very similar products.

I propose that the event processing community at-large would be better represented and served if the EPTS SC was reorganized, something like this:

# Industry Primary EPTS-Related Technology Comments
1 Software Company Event Stream Processing / Continuous Query Vendor
2 Telecommunications Network Management End User
3 Financial Services Security and Risk Management End User
4 Software Company Neural and/or Bayesian Networks Vendor
5 Software Company Rules Engine Vendor
6 Military / Government Data and Sensor Fusion / CEP End User
7 Transportation Operations Research End User
8 Independent Consultant CEP Promotion, CEP Web Site Sponsorship, CEP Evangelism Vendor
9 NPO Event Processing Standards End User
10 Open Open End User

The above list could certainly be improved and refined. It is just a first draft. However, as readers can see, instead of being a society that is managed by vendors with a single, dominate software technology, the society shifts to one where various industries and technologies are more equally represented. The majority of the SC members in my proposed reorganization would be end users, not vendors.

Your comments and suggestions are warmly appreciated.

Share and Enjoy:
  • Digg
  • StumbleUpon
  • del.icio.us
  • Technorati
  • Facebook
  • Mixx
  • Google
  • Slashdot
  • Furl
  • Reddit
  • Spurl
  • LinkedIn

Zen and the Misery of Experience

It is great to relax and just enjoy the good life in Northern Thailand.  As I read so many blog posts and technology articles by people who just don’t have a clue about what they are talking about, I am reminded of a passage by one of the world’s great writers Umberto Eco.

Foucault’s Pendulum was the second novel written by Umberto Eco. The plot revolves around three friends, who work for a small publishing company in Milan. After reading many manuscripts about occult conspiracy theories they decide they can do better and begin to invent their own conspiracy for fun.  Their conspiracy, which they call “The Plan”, is about an immense and intricate plot to take over the world by a secret order descended from the Knights Templar.  As the game progresses, the three men slowly become obsessed with the details and their game turns dangerous when others learn of The Plan and believe that the three have actually discovered the secret to regaining the lost, vast fortune of the Templars.

In this amazing novel, there is an immortal, Comte de St. Germain, who is central to the story.   During a long ocean voyage, standing desk-side on top of a large vessel watching the sun go down, one of Comte de St. Germain admirers asks, in effect (paraphrasing),

“It must be great to be immortal?” (paraphrasing)

The next few passages in Eco’s narrative are unsurpassed in beauty and wisdom, as Comte de St. Germain laments the painfulness of watching humans born into the world, grow, learn and die, passing along very little knowledge to the next generation, who are doomed to repeat the same mistakes over and over again.  This, in a nutshell, is a metaphor of the human condition.

So my friends, as my hair slowly, but surely, turns gray, and I read so many opinions from those with less experience, I feel pain as did Comte de St. Germain in his amazing immortal journey.  Granted, one lifetime and three decades of technical experience, including zero day Internet distributed computing and network systems engineering experience, is a far cry from immortality; however, I can still feel the pain of reading and watching so many with less experience make so many mistakes, or boast of their new “discoveries”.

It is almost unimaginable to think about how much pain one would feel after living hundreds of generations, like Comte de St. Germain, seeing “experts” with little clue about what they are doing, talking as if they actually knew what they were talking about.

Sigh.

Share and Enjoy:
  • Digg
  • StumbleUpon
  • del.icio.us
  • Technorati
  • Facebook
  • Mixx
  • Google
  • Slashdot
  • Furl
  • Reddit
  • Spurl
  • LinkedIn

The Fallacy of Fallacy

Paul Vincent posts The Eight Fallacies of Distributed Computing where he and his colleagues state that “essentially everyone” makes these assumptions when designing a distributed computing application.

Essentially everyone, when they first build a distributed application, makes the following eight assumptions. All prove to be false in the long run and all cause big trouble and painful learning experiences.
1. The network is reliable
2. Latency is zero
3. Bandwidth is infinite
4. The network is secure
5. Topology doesn’t change
6. There is one administrator
7. Transport cost is zero
8. The network is homogeneous

I have been designing and building (or architecting) distributed network andInternet applications since around 1988, and I cannot recall one design team who ever made any of the eight assumptions quoted above.

Competent network systems engineers simply do not make these assumptions.

Share and Enjoy:
  • Digg
  • StumbleUpon
  • del.icio.us
  • Technorati
  • Facebook
  • Mixx
  • Google
  • Slashdot
  • Furl
  • Reddit
  • Spurl
  • LinkedIn

No Brave Bot Hunters in CEP Land?

In August of this year, we issued the challenge,  The Bot Hunter: An Event Processing Challenge (Bot or Not). Not surprisingly, none of the “self-described CEP vendors” with grand claims of CEP greatness, responded.  Real-time detection of threats and opportunities, the core premise of CEP, is very different than algo trading, order routing and process orchestration. Solving real problems is quite different than marketing.

One would think that vendors would take advantage of a real CEP challenge to “show their stuff” versus the releasing marketing fluffy awards.   Folks believe in solutions tested by independent experts, not self-proclaimed proclaimations of greatness.  Every major company has a web site, so it is quite useful to create a CEP solution that can accurately detect automated bots in real-time (with low false positives and false negatives) and then block the bots with high confidence.

One problem is that it is non-trivial to write a set of rules that examine all the real-time web log entries and determine, with high confidence, which transactions are from bots and which are from humans.  This useful application is a bit “complex” and hence, a great CEP application.   Unfortunately,  CEP vendors, claiming “quick, low coding application development” can’t silence their critics!

Readers might recall from The Attack of the Spiders from the Clouds my musings on how cloud computing services can easily be used as a platform for massive denial-of-service attacks.  This is a real-time threat, ripe for a CEP solutions, but we cannot find a single CEP vendor that can meet the challenge.

Share and Enjoy:
  • Digg
  • StumbleUpon
  • del.icio.us
  • Technorati
  • Facebook
  • Mixx
  • Google
  • Slashdot
  • Furl
  • Reddit
  • Spurl
  • LinkedIn

Event Soup and The Story of Amaldo

Continuing with our discussion on Complex Systems and CEP, let’s turn our attention, momentarily, to more scientific, or perhaps philosophical, discussions. Let’s review a bit of chaos theory via the Lorenz effect and talk about the “event soup”, a phrase I shamelessly coined in On the Maturity of CEP.

Edward Lorenz was using a computer model to simulate weather when he rounded .506127 to .506 and the result was a vastly different weather scenario.  This motivated Lorenz and others to discuss, mathematically, how small, seemingly insignificant events can have profound effects over time.  Most of you have heard of “The Butterfly Effect”, the popular notion that a butterfly flapping their cute little wings can have a dramatic effect on weather patterns far away (in space and time); this is a metaphor for the Lorenz effect.  Let’s ground this concept with a similar metaphor, The Story of Amaldo.

The Story of Amaldo.

A man promised his wife that he would stop smoking.   Worried about his wife’s nagging, the man sneaks out the back door and walks down an alley behind his urban home.  When he stops to light his cigarette his eyes meet the eyes of a small alley cat.  The frightened alley cat runs under the building into a coven of alley cats who scatter in many different directions.  We follow one particular cat who jumps up on a nearly ledge of a neighbor’s bedroom window.   At the same time, a man and a woman are making love and they woman sees the cat in the window, she turns, and accidentally knocks over a lamp.   Her lover, overly aroused and a bit drunk, get angry and complains how she always ruins his mood.   They argue and there is no love making that night.   It so happens that because they did not make love and conceive a child, their son was not born, who fathered another son who turned out to be a great scientist, Amaldo, who (would have) discovered a cure for a devastating disease. Many people died because Amaldo was not born into this world.

For a lack of a more precise definition, let’s call Amaldo’s story causality, or simply cause-and-effect.    One of the factors that makes causality complex is that causality is vast and deeply inter-related.   For example, in our event-scenario above, we only followed one cat and a bit of causality of one cat’s journey and how it effected Amaldo.  It is easy to see that the cause-and-effect of events increases exponentially over time in most circumstances. Unfortunately, I don’t have a formal mathematical model at hand provide support to this claim.

Yet, without formal proof, I think most readers will agree that the universal set of events grows exponentially with each microsecond or nanosecond.   Every decision you make, every choice you pick, every mouse click, every stock transaction, is an event which can (and does) effect many lives.   Each decision you make follows the same principles as the Lorenz effect.  Each event also follows the same principles.  Naturally, some events are more “influential” or “consequential” than others and therefore have a larger effect.  My apologies for the lack of formality in this part of the discussion.  I hope this truth is self-evident without formal proof.

Events in computer networks have similar non-linear consequences.  The Lorenz effect was based on a simple computer rounding error.  Professor Luckham attempted to describe this in his formal CEP model as the “event cloud.”  It turns out Professor Luckham’s formal model of his event cloud, based on POSET theory, was in the right direction, albeit too simplistic.     For event processing, and particular complex event processing, we might be better off if we think of the “event soup” versus the “event cloud”.

When we think about events in electronic networks,  some events have an obvious profound effect on our world.   Some events, similar to the Lorenz effect, are seemingly insignificant and have a great effect as well.   No matter how we view this, the shear volume of events is increasing exponentially over time, today.   This trend will continue indefinitely unless something very dramatic happens and our planet freezes over or some other global disaster happens!

Note: An interesting question not addressed here, but obviously important; is will the exponentially increasing event soup effect a future global disaster?

There is some interesting research to be done on applying complexity theory to events and event processing.  The very nature of the expanding event soup demands that other researchers look at complexity, causality, Lorenz effects and more, in the field of event processing.

We need more formal models in this area, and I suggest to you in this post that there is a future Nobel Prize winner out there who will build formal [complex event] processing models that will help us get our minds around the ever growing complexity and space and time causality of the exponentially expanding electronic event soup.

Share and Enjoy:
  • Digg
  • StumbleUpon
  • del.icio.us
  • Technorati
  • Facebook
  • Mixx
  • Google
  • Slashdot
  • Furl
  • Reddit
  • Spurl
  • LinkedIn

CEP in the 1960s: Air Traffic Control

Professor Luckham wrote about CEP and the future of global Air Traffic Control (ATC) in The Future Event Driven World: Global Air Traffic Management.   One of the first commercial applications of complex event processing was in the early 1960s in the field of commercial aviation, for example see the history of Air Traffic Control.

Although experimental use of computers in ATC had begun as early as 1956, a determined drive to apply this technology began in the 1960s. To modernize the National Airspace System, the FAA developed complex computer systems that would replace the plastic markers for tracking aircraft. Instead, controllers viewed information sent by aircraft transponders to form alphanumeric symbols on a simulated three-dimensional radar screen. By automating some routine tasks, the system allowed controllers to focus on providing separation. These capabilities were introduced into the ATC system during the ten years that began in 1965.

Applying a phrase like “complex event processing” to a subset of software on the market today certainly does not negate all the CEP applications that existed long before the phrase was coined or became popular.  Global ATC has been defined as a future use case for CEP.  Obviously, early ATC history, where processing complex events goes back as far as the early 1960s, is quite significant to our understanding of CEP/EP.

Event processing applications, including complex event processing applications, have been around for over 40 years. There has been four decades of both commercial and military event processing and CEP applications.  ATC is only one example of myriad historical commercial applications of complex event processing.


Note: This post was adapted from my post in the Earliest applications of commercial CEP.

Share and Enjoy:
  • Digg
  • StumbleUpon
  • del.icio.us
  • Technorati
  • Facebook
  • Mixx
  • Google
  • Slashdot
  • Furl
  • Reddit
  • Spurl
  • LinkedIn