Am I being attacked? Don't know, I forget...

Today’s attackers are very patient. The old “smash and grab,” where the attacker tries to get as much data as quickly as possible is gone. Basically because most enterprises have gotten pretty good at detecting those kinds of attacks. The correlation engines built into security information and event management systems (SIEM) are finely tuned to look for these kinds of attacks. And the attackers know that.

So like any other businessmen (and women), the bad guys have adapted. They know the defenses, so they are working around them to ensure a constant flow of stolen data. They have lots of mouths to feed, don’t you know! One of the ways they’ve adapted is to mount a low and slow attack, since they know the SIEM product can only correlate across a few days (typically 3-5) of data. So they know if they wait for 10 days between stages of their attacks, they are less likely to get caught. And more likely to keep stealing information.

It’s actually kind of dastardly ingenious. They compromise a device, turn off logging, install stuff, turn logging back on and then wait. A few days later, they go back into the machine, look for additional vulnerable devices, compromise another and then wait some more. Yes, these attacks can happen over a few months. But don’t feel bad for the attackers, I doubt a lot of them have low golf handicaps. They are working hundreds of attacks on thousands of zombies at the same time.

So how do you detect this kind of low and slow attack. Well, we’ve already discussed how to deal with the reality that logging will be turned off by the attackers. Another method we use at eIQ is to extend the correlation window. That’s right, SecureVue correlates data for up to 90 days, outside the attack windows of even the most patient attacker.

Gosh, that seems too easy. Why don’t other SIEM vendors do the same thing? Because it’s hard and it requires a purpose-built architecture to maintain that much data in memory to do correlation across that length of time. Other SIEM and log management offerings would need to totally rebuild their offerings to provide a similar capability, and we know that isn’t going to happen.

You can think of most SIEM products as having Alzheimer’s, as sad as that is. They have very limited short term memory and their long term memory is shot. And that’s what the attackers are counting on. Which is another reason that log data is not enough.

How about this eye?

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.