eIQviews

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.