Skip to content

SIEM: May it Rest in Peace [When log and event data is not enough]

September 20, 2011

When SIEM launched in 2000 it promised security professionals the opportunity to collect security data from across their network; to provide a consolidated and unified view of their security position. The early tools delivered on some of this promise while attacks had common signatures – log and event data, but the simple fact is that today’s threats — from APTs that combine multiple attack vectors, to insider threats and privilege abuse, to even simplistic threats such as system mis-configurations – require more than what any one monitoring technology can provide.

Just as a few years ago when security analysts began realizing that signature-based detection technologies are an inadequate security strategy due to the advancing nature of threats, the same is being recognized today about SIEM (or at least, it is by the Fortune 1000 CISOs I talk to every day).  Security professionals realize that event-based information is only one wedge of the pie.  They also know they need to correlate log and event data with other, non-event stuff, such as asset and configuration data [and to be clear, I don’t mean the SIEM-centric “scan the logs for system changes!” approach to getting asset and config. data].

As we all know, attackers and malware clear and disable logging when they acquire privilege making this acquisition method pretty useless; it’s also important to point out that many types of configuration data — Windows registry settings, ACLs, UNIX/Linux /etc file contents, etc. are difficult, if not impossible, to natively push to logging mechanisms.)  They also need performance metrics, network traffic (flow and/or DPI), user context, and lots of other types of security data.

If you’re looking for proof that traditional SIEM tools alone no longer provide adequate protection against modern cyber threats we’ll enter the attacks on Sony, the International Monetary Fund, Epsilon, Sega, Sony (again) and the CIA as evidence.

Read part 2 – ‘A single piece of glass for all security data’ – here

2 Comments leave one →
  1. December 22, 2011 11:35 am

    I totally agree with your assessment that corporations are not seeing the benefits that they originally hoped for from SIEM.

    But I disagree with your conclusion that this is because SIEMs are deficient and thus “SEIM is dead”.

    As you say, “scanning system logs”, “registry settings” and “file content” changes are all hard to report on. True, true indeed. So why not just feed the SIEM better/richer data? Adding a log of *actual user activity* (as opposed to the system log entries that result from user actions) gives SIEM great content to report on.

    An overweight child would be much healthier if s/he were to switch from junk food to fruits and vegetables. The problem isn’t the child, the problem is the child’s diet. Same with the SIEM… feed it better data and it will give good analysis reports.

    My company (ObserveIT) has seen many of our customers salvage their SIEM investment by plugging in our User Activity Monitoring capability.

    • December 22, 2011 12:00 pm

      Certainly, getting more data into SIEM is a good thing (and as you point out, user activity data is a great example). The problem, however, lies in how the SIEM uses that data. Things like running firewall configurations, current Windows registry values, or app/database configurations are not events — they’re state data. SIEMs, unfortunately, treat *everything* as an event, even in those rare cases where they can partially collect non-event data such as configurations, asset data, performance metrics, network traffic data, etc.

      The problem with that approach is that security analysts and compliance professionals need to see data both in their appropriate context, *and* correlated to other types of data. One example of this is prescriptive configuration assessment (e.g., comparing a system to a CIS benchmark, or a DISA STIG); if you’re looking at historical events to determine when apps were installed on a host, or when configuration values changed, then the best you can identify is “what the current state of the system *should* be”, not what is actually needed (“what the current state of the system *actually is*”). SIEM simply doesn’t do this kind of analysis and reporting; anything you feed it is “just another event”.

      So yes, feeding SIEMs a richer set of data can help, but only if the SIEM knows how to use the data. Using your analogy, switching an overweight child from junk food to fruits and vegetables will only help if the child’s body knows how to properly process these new foods. The same holds true for SIEM tools, which simply don’t know how to process disparate data types in a way that provides real answers for today’s security and compliance problems… and since SIEMs are typically purchased for precisely that reason, it is indeed correct to portray them as dead.

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s

%d bloggers like this: