Mike and I are launching our next blog series today, one we know is pretty timely from the conversations with have with organizations almost every day. The reality is that many organizations have spent millions and years trying to get productivity out of their SIEM – with mediocre results. Combined with a number of the large players being acquired by mega IT companies and taking their eyes off the ball a bit, most customers need to start asking themselves some key questions.
Is it time? Are you waving the white flag? Has your SIEM failed to perform to expectations despite your significant investment? If you are questioning whether your existing product can get the job done, you are not alone. You likely have some battle scars from the difficulty managing, scaling, and actually doing something useful with SIEM. Given the rapid evolution of SIEM/Log Management offerings – and the evolution of requirements with new application models and this cloud thing – you should be wondering whether there is a better, easier, and less expensive solution to set your needs.
As market watchers, we don’t have to be brain surgeons to notice the smaller SIEM and Log Management vendors innovating their various ways to relevance – with new deployment models, data storage practices, analysis techniques, and security features. Some vendors are actively evolving their platforms – adding new capabilities on top of what they have, evolving from SIEM features into broader security management suites. Yet there are others in the space basically “milking the cash cow” by collecting maintenance revenue, while performing the technical equivalent of “putting lipstick on a pig”. (Yes, we just used two farm animal analogies in one sentence.) You may recognize this phenomenon as the unified dashboard approach for hiding obsolescence. Or maybe “Let’s buy another start-up with a shiny object!” … to distract customers from what we haven’t done with our core product strategy.
Let’s face it – public company shareholders love milking cash cows, while minimizing additional research and development costs. Security companies (especially those acquired by mega IT) have no problem with this model. Meanwhile customers tend to end up holding the bag, with few options for getting the innovation they need. From our alarmingly consistent conversations with SIEM customers, we know it’s time to focus on this dissatisfaction and open the SIEM replacement process up to public scrutiny. Don’t be scared – in some ways SIEM replacement can be easier than the initial installation (yes, you can breathe a sigh of relief), but only if you leverage your hard-won knowledge and learn from your mistakes.
Security Management 2.0: Time to Replace Your SIEM? will take a brutally candid look at triggers for considering a new security management platform, walk through each aspect of the decision, and present a process to migrate – if the benefits of moving outweigh the risks.
In this series we will cover:
- Platform Evolution: We will discuss what we see in terms of new features, platform advancements, and deployment models that improve scalability and performance. We’ll also cover the rise of managed services to outsource, and deploying hybrid configurations.
- Requirements: We’ll examine the evolution of customer requirements in the areas of security, compliance, and operations management. We will also cover some common customer complaints, but to avoid descending into a customer gripe session, we’ll also go back and look at why some of you bought SIEM to begin with.
- Platform Evaluation: We’ll help walk through an in-depth examination of our current environment and its effectiveness. This will be a candid examination of what you have today – considering both what works and an objective assessment of what you’re unhappy about.
- Decision Process: We’ll help re-evaluate your decisions by re-examining original requirements and helping remove bias from the process as you look at shiny new features.
- Selection Process: This is an in-depth look at how to tell the difference between various vendors’ capabilities, and at which areas are key for your selection. Every vendor will tell you they are “class leading” and “innovative”, but most are not. We’ll help you cut through the BS and determine what’s what. We will also define a set of questions and evaluation criteria to help prioritize what’s important and how to weigh your decision.
- Negotiation: You will be dealing with an incumbent vendor, and possibly negotiating with a new provider. We’ll help you factor in the reality that your incumbent vendor will try to save the business, and how to leverage that as you move to solidify a new platform.
- Migration: If you are moving to something else, how do you get there? We’ll provide a set of steps for migration, examining how to manage multiple products during the migration.
Don’t assume that SIEM replacement is always the answer – that’s simply not the case. In fact, after this analysis you may feel much better about your original SIEM purchase, with a much better idea (even a plan!) to increase usage and success. But we believe you owe it to yourself and your organization to ask the right questions and to do the work to get those answers. It’s time to slay the sacred cow of your substantial SIEM investment, and figure out objectively what offers you the best fit moving forward. This research series is designed to help.
Reader interactions
5 Replies to “Security Management 2.0: Time to Replace Your SIEM? (new series)”
These are all great points. The reality is many organizations set the wrong expectations when deploying their first SIEM. A big part of the process we’re advocating is to revisit those assumptions and requirements – with the express goal of figuring out if the existing product can get there.
To @Andrew’s point, most organizations don’t have the stomach for yet another multi-year, big dollar project. And if the decision is clear that a new platform is the way to go, the team driving the project will need to have a bullet proof case.
There have been a lot of successes and failures when it comes to SIEM. The point is to go into the project understanding what problems *need* to be solved – before trying to figure out what product/service is the best fit.
So we aren’t going to go into a lot of the details about effectively deploying a SIEM. That’s not the focus of this research. I’d point folks to our work on Network Security Operations Quant, which isn’t about SIEM specifically – but talks about monitoring at a very granular – process oriented level.
Mike.
I should tie that thought off and just say, I wonder how many people will be looking for a SIEM replacement only because they have wrong expectations and practices in their current one.
Almost like bouncing around from one magic diet pill to another, looking for the easiest way to get a possibly unrealistic result with as little effort as possible, and in the end only wasting money and getting a chronic upset stomach.
Looking forward to this series!
*Effectively* deploying and operating SIEM products is that big elephant in the corner. 🙂 Not that I’d want you to cover it, but I think anyone who has deployed one knows you can’t summarize it very well at all, and every deployment will bring fresh challenges.
The best you can do is always ask whether a gathered event/generated alert will ever provide value, either for detection or for forensics. And log everything unless you truly know it is too chatty and never valuable.
Still, an IPS is more useful for alerting on typical “hacking” incidents than a SIEM. I’d even argue the “gut feelings” of an admin glancing at the raw logs and performance is more useful…
I trust that in the ‘Decision Process’ you’ll provide tips on how to convince management that the money and time sunk into the previous project was not in vain. I see this as perhaps one of the biggest show stoppers when it comes to ripping and replacing a SIEM product – especially when budget no longer exists for a project of this magnitude.
Are you guys planning to write at all about how to effectively deploy and operate SIEM products?