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.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: