Correlation is in the eye of the beholder
August 6, 2009
As I’ve written frequently, both privately (here) and for eIQ (link), 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.
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.
5 Reasons SIEM Projects FAIL
June 22, 2009
Based on a number of recent surveys and hearing general grumbling during my travels, the perception of SIEM has not changed much. Folks think it’s still too complex, too expensive and doesn’t provide enough value.
All of the vendors will tell you this isn’t so. They’ll point to their base of reference customers to show that the technology has gotten a lot easier and that customers are getting real value from the solutions. They are probably right. But as my driver’s education teacher told me: “You may be right, but you’ll still be dead.”
The point of my little anecdote is to remind us that the truth doesn’t really matter, the perception of SIEM’s problems are what the industry has to deal with. So in this post, I’ll hit one man’s opinion of the top 5 reasons projects and some potential solutions. And it turns out that many of the reasons projects fail have nothing to do with technology.
Reason #1: Unrealistic expectations
This is the killer. And I wish it was something that just plagued security management projects. Far too many organizations start a project without a clear understanding of what problem they are trying to solve and therefore do not have clearly defined SUCCESS CRITERIA established before they start.
This is a recipe for disaster because even if the project meets the goals in your head, other folks may have different opinions. And this has been one of the key issues with SIEM since the beginning. The technology was positioned as the Holy Grail and it just wasn’t for a lot of reasons.
So you have about 10 years worth of customers that don’t think SIEM solved their problem and their voices dramatically outweigh the quiet ones that have actually gotten value and had successful projects. As I mentioned in last week’s post (SIEM still struggles (and it’s our own fault)), we have to stop over promising and under delivering on the value of security and compliance management.
And making sure any organization undertaking a project has the right goals and realistic expectations at the front end of the process is the only way to solve this one.
Reason #2: Lack of implementation resources
No matter how you slice it, gathering data from a lot of different sources and trying to make sense of it is hard. It’s not something you buy at the local computer store, screw into your 19″ rack and let it run. And I don’t think it will ever be. The number of attack vectors is just too great.
So another reason many of these projects fail is the lack of commitment both from the customer and the vendor to devote the resources required to make the project successful. Yes, it’s going to take time (think weeks, not years) and it’s going to cost money.
No one bitches about spending 4x the cost of software licenses on services for an SAP implementation. You don’t need to spend anywhere near that multiple on SIEM services, but do plan on spending something. Or suffer the consequences.
Reason #3: Time to value too long
Finally, a technology issue. The first generation of SIEM products (many of which are still be pushed out there in the market) were built on big relational database back ends. These are big, ugly, expensive and perform like crap. When you have to bring your own DBA to the party, it ain’t going to be a clean install.
Time to value was also impacted by challenges in tuning and customizing the correlation engine and refining the reports needed for internal and external requirements. Basically it took way too long to get these things up and running (regardless of the number of bodies thrown at the problem) and that caused customers to lose faith in the value of the category.
Many of the vendors out there (including eIQ) have addressed these issues to one degree or another (we can certainly argue about the logic of front-ending a big RDBMS with a bunch of logging toasters to provide the illusion of scalability), but customers still hold onto that old perception. And perception is reality (have I said that enough times)?
Reason #4: Don’t embrace SIEM-based operational processes
Once again, this is a self-inflicted wound on the part of most customers. Basically they just want to set it and forget it. They figure it’s like an anti-spam device. Turn the knob and get out of the way. Well, not so much.
Let’s get back to the SAP analogy. No one implements SAP to overhaul their operational processes and expects it to just run, hands-off ad infinitum. These organizations build operational processes around the tool and constantly tune those processes to get the most value from automation and having an integrated view of their environment.
SIEM is no different. The organization must embrace a different way of doing business. They have to spend a large portion of their time in the interface every day and customize the user interaction model to meet with their own personal workflow. This isn’t about getting an alert in email and then riding off on the white horse to investigate the issue and repel the bad guys.
It’s about using the tool that was bought. If SIEM is shelf ware, then clearly this is project FAIL.
Reason #5: Political headwinds
Let’s wrap it up by dealing with reality for a little bit here. I’ve seen a lot of environment where other operational groups work to undermine the security team because they have data the ops groups don’t want them to have.
Like whether the network is working optimally. Or if the configurations are locked down. And how quickly patches get implemented or vulnerabilities get remediated. Not to be overly generic, but most folks aren’t big fans of being accountable and having someone else posses real data to hold their feet to the fire.
So political roadblocks are put in the way to either stonewall the data gathering efforts or challenge the accuracy of the data and the conclusions drawn by using the SIEM tool. Again, it’s hard to be a success if there are political roadblocks in the way.
Part of the implementation process MUST be a process to make sure everyone is on board and to identify these political hot buttons before they take down the project. Of course, this is easier said than done, but it’s critical. You can address all the other issues and be on the road to a successful project, only to be sent off the rails by petty politics.
Over the next few weeks, I plan to flesh out each of these reasons in much more depth with some recommendations on how to overcome each of these problems. Yes, I’m giving away some great stuff, but the more successful SIEM implementations out there, the better it is for everyone.
