Skip to content

Correlation Is In the Eye of the Beholder

August 6, 2009

As I’ve written frequently, one of the key issues with the SIEM market has been the failure to meet customer expectations. A lot of that has to do with correlation, or lack thereof.

Just to refresh our minds, the idea of correlation originated very early on IT management disciplines and involved the need to take events from lots of different places and make sense of them. The need for correlation has become acute over the past few years as the velocity of everything has increased. IT systems are deployed faster to more customers providing access to private and sensitive data. Those systems create attack vectors and present potential exploits to allow the leakage of said data.

Compounding this are today’s attacks designed to circumvent traditional defenses and stay “under the radar,” so the perpetrators can continually mine an organization for more sensitive data. The ability to cloak an attack has also improved, mostly through the use of compromised machines (zombies) as proxies to undertake the attackers dastardly tidings. So not only is more sensitive data available for compromise, it’s easier to attack and harder to track the attackers. No wonder so many security folks are miserable.

All this activity results in more stuff to track and inevitable causes more noise than ever before. Noise is the security professionals arch-enemy because we only have 18-20 hours a day to investigate potential security issues. Who needs sleep anyway? If we wanted to investigate every potential attack, we’d have to deploy that time expander and get maybe 50-60 hours of activity into each day.

That’s right, we need to be more efficient, without sacrificing effectiveness. The only way I know to do this is to automate as much as possible and that’s where correlation comes in. If we can have a machine looking at all the data, matching patterns and highlighting potential issues, we can focus our (human) efforts on only the attacks that represent the biggest chance of compromise.

Which is the crux of the issue. How do you define those patterns that potentially represent a significant attack? I could lie to you (like most vendors in the space) and talk about how wonderful my widget is OOTB (out of the box capabilities) and how all you have to do is plug it in and it’ll tell you exactly what’s happening. I could, but it would be the wrong thing to do.

The right thing to do is to manage your expectations appropriately. Every vendor’s OOTB capabilities are a STARTING POINT. eIQ ships with 250+ pre-built correlation policies. Quite a few will be appropriate for your environment. Others will not. And the only way to figure out which is which is to analyze the data and refine the policies.

The idea of a “self-tuning” SIEM is hogwash. Yes, by analyzing data, baselines can be determined and a set of initial policies be deployed. But those policies need to be fine tuned and revisited frequently. Not because they are wrong, but because the world is a dynamic place and things change – frequently. Which means your security monitoring must change frequently as well.

The reality is if more customers went into a SIEM project understanding that correlation is like a funnel and at first the top of the funnel is big. Over time (and with effort) the funnel can be narrowed, until things change and then you have to recalibrate and refine. Over and over again. Yes, it’s a treadmill, but so is everything in security.

Effective correlation is possible. And with the right expectations and resources, it’s even probable. But not if you expect it to happen OOTB.

No comments yet

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: