InformationSecurityAsia2007 – Bangkok

If you are in Asia-Pacific next month, please drop me a line. I will be attending InformationSecurityAsia2007 in Bangkok, July 10 – 11th. It is possible I will be asked to present on CEP and SEM, if a speaking slot becomes available. Right now I am on the list as a backup! The good news is that if I don’t present, we can have more time to socialize. Hope to see you there!

Contact Info:

SilkRoad Asia Co., Ltd.
No. 16/23-24 Soi Sukhumvit 19 (Wattana)
Klongtoey Nua Sub-District, Wattana District,
Bangkok 10110

Direct (Cell): +66-(0)8-3297-5101
Tel (Office): +66-(0)2-254-1750-9
Fax: +66-(0)2-254-1754
www.silkroad-asia.com

Security Event Management (SEM) with CEP (Part 6) – Realizing SEM with CEP

Security Event Management (SEM) with CEP (Part 6) – Realizing SEM with CEP

In Part 6 in this series, Security Event Management (SEM) with CEP, we look at how CEP can be used to help security experts meet the 5 principles of SEM. In my earlier tutorial series, What is Complex Event Processing?. we reviewed a functional reference architecture for CEP, illustrated below.

From the discussion and the illustration above, we can summarize how CEP can easily be used as the framework for implementing SEM:

1. ESB/Messaging Infrastructure – Many state-of-the-art CEP solutions use a secure, standards-based communications infrastructure for distributed event management. This is the most effective way to normalize and manage heterogenous events from many distributed SEM event sources;
2. Strong Analytics – Many CEP implementations have extensible event-driven analytics to detect and refine threat-related situations using state-of-the-art techniques like rules-engines, Bayesian networks, neural networks and more;
3. EDA – State-of-the-art CEP architectures use standard-compliant messaging, alerts and automated responses to kick off workflow, compliance and other remediation and BPM activities;
4. Custom Reporting – Most CEP software applications ofter customizable dashboards. Reports are easily customized with a variety of state-of-the-art graphical studios, including AJAX-based user interfaces; and,
5. Scaleable, Distributed Architecture – As illustrated in the CEP reference architecture, event-driven, cooperative agents can be configured to process to millions events in a heterogeneous, distributed architecture.

The recent FSA announcement by Mark Palmer and team at Apama that the FSA will be using Apama’s CEP platform for Sabre 2, their next-generation, real-time market surveillance and market abuse detection system, shows that the CEP vendors are heading in the right direction!

So, in closing, if you need to build a robust, state-of-the-art fraud, misuse, or intrusion detection system based on the 5 principles of SEM, CEP can help! Congratulations Apama!

Copyright © 2007 by Tim Bass, All Rights Reserved.

BAM to SOA – Da’ Buzzhype Revisited

Many readers have read the hype, experienced the Orwellian marketspeak, watched the positioning debates, and seen poorly managed software companies play the game of analyst-chasing (similar to ambulance chasing when you think about it). Finally, the up-to-date definitions, and hopefully a bit of wit and humor:

BAM (Business Activity Monitoring) – software that gives you real-time visibility into your business. Be careful! Remember that airline flight a number of years ago where the pilot and co-pilot were so fixated on a broken altimeter that they forgot to look out the cockpit window and ran the plane into the ground? Don’t let that happen to your business, OK? Folks get so focused on IT and analyst-chasing they forget to run the business. Be honest, how much time do you waste on the net? Just call it BAM! Hey boss, I’m BAMing right now, I’ll fix it later!

BI (Business Intelligence) – software that gives you historical visibility into your business. Why is looking at historical data referred to as “intelligence” but monitoring real-time operational data is “activity monitoring”? Seems it would be more “intelligent” to monitor real-time data! Anyway, take two and call me in the morning if you still are confused.

BPM (Business Process Management) – software that manages business processes, normally dumbed down to mean some sort of rules-based workflow engine. BPM must be SOA based since software companies must sell more of the same old software (SOS) to meet their quarterly revenue targets. BPM must be EDA based, and CEP based, and have a BRE and work with a BRMS…. well you get the idea. Go out and buy one!

CEP (Complex Event Processing) – software that provides actionable intelligence from the nebulous “data cloud”, conceptually too complex for mere mortals to understand. Marketeers are working hard to eliminate the word “complex” because they think no one buys anything “complex”. Folks attempted to dumb-it-down to Event Stream Processing to process time-series data and then said “there is no spoon, it is your mind that bends!”

EDA (Event Driven Architecture) – the same as an SOA when SOA is “Da’ Big Market Hype” and different than SOA when trying compete against other SOA vendors, when you are flying at 20,000 feet, all the houses look the same, so who cares; anyway, snowbears and snow are the same thing at 5,000 feet. My lawn looks great from 2,000 feet. Some people say I’m a handsome fellow from 50 feet away. Well, you get the idea 🙂

ESB (Enterprise Service Bus) – software that manages data sharing between heterogeneous applications, but not in a way that actually works unless you buy MY ESB! Interoperability means less information technology revenue, so software companies driven by quarterly revenue announcements must make sure that their ESB is better than your ESB! Interoperability decreases middleware sales revenue! We can’t have than now, can we?

ESP (Event Stream Processing) – the same as CEP if you want it to be. Nevermind stream processing is different than cloud processing and that time-series data processing is different than rules processing. Nevermind that backwards chaining is different than forward chaining. Nevermind that measuring rain fall amounts is different than weather forecasting. Nevermind that rule-based processing is only a small segment of the event processing market. It’s all the same if you want it to be!

SOA (Same Old Architecture) – software that manages data sharing between heterogeneous applications, but not in a way that actually works unless you buy MY SOA! Originally envisioned for web-based cross-organizational distributed computing, but that was too hard, SOA became a religion, where you had to have one and spend millions to build one even thought your business worked fine before! Iron plumbing not in style? Let’s rip it out and change it to copper. SOA is another type of task fixation, where software companies without leadership get caught up in analyst-chasing and and run the business into the ground!

Got a favorite buzzword that the analysts are hyping? Feel free to comment. Free your mind. Remember, it is not the spoon that bends, it’s your mind! But the unanswered question is, “Who is bending your mind?”

Copyright © 2007 by Tim Bass, All Rights Reserved.

Security Event Management (SEM) with CEP (Part 5) – SEM Challenges

Security Event Management (SEM) with CEP (Part 5) – SEM Challenges and Shortfalls

In Security Event Management (SEM) with CEP (Part 4), we briefly reviewed the 5 functional principles of SEM. Most, if not all, of the current SEM offerings from security vendors today do not meet the core requirements of a robust SEM architecture.

The graphic below represents a taxonomy view of distributed fraud and/or intrusion detection systems, highlighting how security-oriented solutions tend to be purpose-built solutions which leads to security “stovepipes” that do not share event information.

The chart above illustrates one of the reasons we need the basic 5 functional requirements of SEM in cyberspace – a distributed event-driven architecture that supports heterogeneous event-driven systems with the capability to detect, with high confidence, real threats, prioritize them and kick-off some event-driven workflow that meets corporate risk management and regulatory requirements. All of this must happen in real-time, minmizing false alarms, optimizing resources, and providing decision-support tools, such as visualization, for operators.

I spent quite a bit of time on the net searching for pictures of SEM implementations. There are no shortage of centeralized event aggregators! Here are screen shots of 10 of them:

All of the implements above simply create “yet another security stovepipe” that performs some basic event aggregation and filtering. These “SEM tools” fall far short of accomplishing the 5 principles of SEM we discussed in Part 4. Here are two more “pseudo SEM implementations:”

To make a long story store, as we can see from the three charts above, most, if not all, commercial SEM implementations in the market today fail to meet the 5 key principles of SEM (summarized in part 4). Here are the key shortcomings of these SEM implementations, using the same 5 SEM principles as a backdrop for comparision:

1. No ESB – there is no secure, standards-based communications infrastructure for distributed event management in current SEM solutions;
2. Weak or no analytics – there is limited capability to detect and refine threat-related situations with high probability using state-of-the-art analytics;
3. Weak or no EDA – no standard generated alerts and automated responses to kick off workflow, compliance and other remediation activities;
4. Weak Reporting – dashboards and reports tend to be” event aggregators” that do not filter out the “noise”; and,
5. Unscaleable, centeralized architectures – current SEM architectures cannot manage millions events in a heterogeneous, distributed architecture.

In my next post in this series, Security Event Management (SEM) with CEP (Part 6), I will begin to discuss about how CEP can be used to help security engineers meet the 5 principles of SEM.

Copyright © 2007 by Tim Bass, All Rights Reserved.

Security Event Management (SEM) with CEP (Part 4) – The 5 Principles of SEM

Security Event Management (SEM) with CEP (Part 4) – The 5 Principles of SEM

In Part 2 and Part 3 of Security Event Management (SEM) with CEP, we reviewed trends in cybersecurity and the motivation for SEM and CEP. That introduction leads us to a brief post on the high-level functional requirements of SEM.

In a nutshell, according to the literature and the marketplace, SEM functionality is based on these 5 principles:

1. Log collection from heterogeneous devices – the capability to read, parse, normalize, and gather security events from a variety of heterogeneous event sources;
2. Situation detection – the capacity to detect and refine threat-related situations automatically and priorities based on an automatic impact assessment, optimizing staff performance to focus on preventing the most important threats;
3. Threat prevention and remediation – generate alerts and automated responses based upon high probability threat scenarios and manage the life cycle of the threat;
4. Report generation – automate reports that support post-threat investigation, regulatory compliance and update visualizations and dashboards; and,
5. Scalable, distributed architecture – the architecture must manage millions of logs per day, distribute the processing load, and with service-oriented services for transformation, event tracking, correlation, updates, remediation and visualizations.

These 5 functional requirements, or principles, are easy to write down in bullet format, but very difficult to achieve in practice. In fact, just about every SEM implementation in the marketplace today falls far short of realizing the stated goals of SEM. In my next post in this series, Security Event Management (SEM) with CEP (Part 5), I will elaborate on of why the promise of SEM is elusive and unachievable by most, if not all, current SEM vendor implementations.

Go to Security Event Management (SEM) with CEP (Part 5) – SEM Challenges.

Copyright © 2007 by Tim Bass, All Rights Reserved.

Security Event Management (SEM) with CEP (Part 3) – Trends in Cyberspace

Security Event Management (SEM) with CEP (Part 3) – Trends in Cyber Attacks, Threats and Vulnerabilities

Life in our web browser-based world is more dangerous than first meets the eye.    I don’t mention this to sound the alarm bells.  It is, however, important to understand why organizations need sophisticated event-driven cybertools to catch criminals before they do harm to us.  For example,  look at the next two charts from IBM that show critical vulnerabilities for Internet Explorer (34 total) and Firefox (64 total) in 2006.

 

The two charts above are just two examples of the unseen daily risks we face while working and playing in cyberspace – and the risk increases daily as our lives become more dependent on the net, as illustrated by the graphic below.

We can easily see from IBM’s graphic (superimposed with my curve) that the number of cyberspace vulnerabilities have been increasing exponentially since 2000.  This trend continues today and is expected to get worse.    This was the motivation for my 2000 CACM paper on next generation intrusion detection systems (which also applies to fraud detection as well as other detection-oriented event processing applications).  

Security event management is an event-driven  set of technologies envisioned to make our lives more secure in cyberspace.   In my next post in the series, Security Event Management (SEM) with CEP (Part 4), I will discuss the promise of SEM and SEM functionality.  I will then explain why current SEM implementations fall far short of the earlier SEM hype and how CEP can help.

Go to Security Event Management (SEM) with CEP (Part 4) – The 5 Principles of SEM.

Copyright © 2007 by Tim Bass, All Rights Reserved.

Security Event Management (SEM) with CEP (Part 2) – Trends in Cyberspace

Security Event Management (SEM) with CEP (Part 2) – Trends in Cyber Attacks, Threats and Vulnerabilities

It is no secret that cyberspace has become one of the the most important areas of our daily lives in the modern world. We bank, buy stocks and purchase goods on the net. We book and pay for travel on line. We pay our credit cards bills over the net. Many of us have bill paying services and all of our bills are scanned and managed in cyberspace. With Blackberry’s and the coming iPhone we send and receive email 24 hours a day, 7 days a week, from almost every modern place on the planet. We collaborate in business and share our most personal and private moments in videos and pictures. We purchase music on line and download to our iPods (and iPhones soon!). Web 2.0 for most of us is simply the commercial version of the Freedom of Information Act!

Not surprisingly, the modern day information explosion in cyberspace leads to risks and security challenges we have never seen before – and it is getting more challenging, day-by-day. For example, take a look at this chart from CERT.

Around 25 years ago computer security experts were worried about password guessing and simple back doors in software. Fifteen years ago sniffers, spoofing and denial of service attacks jumped onto the scene; 10 years ago we see cross-site scripting and distributed cyberattack tools. Today, we are menaced with distributed botnets and organized gangs of cybercriminals and terrorists. In simple terms, the more sophisticated net-citizens we become, the more sophisticated the network threats and attacks become. Risk increases with reward.

Furthermore, over time, the level of knowledge required to attack and menace net-citizens has decreased. In the past, a high degree of computer and network knowledge was required to attack our lives in cyberspace. Today, sophisticated tools and malicious code permit just about anyone to make our cyberlives miserable.

The chart below from IBM illustrates a 2006 survey of malware in the Internet.

This is an amazing chart isn’t it? In 2006 IBM identifed over 68,000 downloader malwares, over 49,000 trogans, 39,000 back doors and more. These numbers eclipse the number of computer viruses, illustrated below.

In my next post in this series, Security Event Management (SEM) with CEP (Part 3) , we will review these cybersecurity trends a little more and then dive into the motivation for SEM and SEM functionality.

Copyright © 2007 by Tim Bass, All Rights Reserved.