It’s time – you are ready. You have done the work, including revisiting your requirements, evaluating your current platform in terms of your current and emerging requirements, assessing new vendors/platforms to develop a short list and run a comprehensive proof of concept. Now it’s time to make the call. We know this is an important decision – we are here because your first attempt at this project wasn’t as successful as it needed to be. So let’s break down the decision to ensure you can make a good recommendation and feel comfortable with it.

That’s actually a good point to discuss. The output of our Security Management 2.0 process is not really a decision – it’s more of a recommendation. That’s the reality – the final decision will likely be made in the executive suite. That’s why we have focused so much on gathering data (quantitative where possible) – you will need to defend your recommendation until the purchase order is signed. And probably more afterwards.

We won’t mince words. This decision generally isn’t about the facts – especially since there is an incumbent in play, which is likely part of a big company that may have important relationships with heavies in your shop. So you need your ducks in a row and a compelling argument for any change.

But that’s still only part of the decision process. In many cases, the (perceived) failure of your existing SIEM is self-inflicted. So we also need to evaluate and explain the causes of the failed project, with assurance that they will be addressed and avoided this time. If not, your successor will be in the same boat in another 2-3 years. So before you put your neck on the chopping block and advocate for a change (if that’s what you decide), do some deep internal analysis as well.

Introspection

The first thing is to make sure you really re-examined the existing platform in terms of the original goals. Did your original goals adequately map your needs at the time, or was there stuff you did not expect? How have your goals changed over time? Be honest! This is not the time to let your ego get in the way of doing what’s right, and you need a hard and fresh look at the decision to ensure you don’t repeat previous mistakes. Did you kick off this process because you were pissed at the original vendor? Or because they got bought and seemed to forget about the platform? Do you know what it will take to get the incumbent to where it needs to be – or whether that is even possible? Is it about throwing professional services at the issues? Is there a fundamental technology problem?

Remember, there are no right or wrong answers here, but the truth will become clear when you need to sell this to management. Some of you may be worried that management will look at the need for replacement as ‘your fault’ for choosing the incumbent, so make sure you have answers to these questions and that you aren’t falling into a self-delusion trap. You need your story straight and your motivations clear.

Did you assess the issues critically the first time around? If it was a skills issue, have you addressed it? Can your folks build and maintain the platform moving forward? Or are you looking at a managed service to take that concern off the table? If it was a resource problem, do you now have enough staff for proper care and feeding? Yes, the new generation of platforms requires less expertise to keep operational, but don’t be naive – no matter what any sales rep says, you cannot simply set and forget them. Whatever you pick will require expertise to deploy, manage, tune, and analyze reports. These platforms are not self-aware – not by a long shot.

The last thing you want to do is set yourself up for failure, so make sure you ask the right questions ahead of time and be honest about the answers.

Expectations

The next main aspect of the decision is reconciling your expectations with reality. Revisiting requirements provides information on what you need the security management platform to do. You should be able to prioritize the specific use cases (compliance, security, forensics, operations), and have a pretty good feeling about whether the new platform or incumbent will be able to meet your expectations. Remember, not everything is Priority #1, so pick your top three must-have items, and prioritize the requirements.

If you are enamored with some new features of the challenger(s), will your organization be able to leverage them? Firing off alerts faster may not be helpful if your team takes a week to investigate any issues, or cannot keep up with the increased demand. The new platform’s ability to look at application and database traffic doesn’t matter if the developers won’t help you understand normal behavior to build the rule set. Fancy network flow analysis can be a productivity sink if your DNS and directory infrastructure is a mess and you can’t reliably map IP to user ID.

Or does your existing product have too many features? Yes, it does happen that some organizations simply cannot take advantage of (or even handle) complex multi-variate correlation across the enterprise. Do you need to aggregate logs because organizational politics, or your team’s resources or skill set, prevent you from getting the job done? This might be a good reason to outsource or use a managed service. There isn’t a right or a wrong answer here, only the answer. And not being honest about that answer will land you in the hotseat again.

If you kickstarted this effort because the existing product missed something and it resulted in a breach, can you honestly say the new thing would (not ‘might’) detect that attack? We have certainly seen high profile breaches result in tossing the old and bringing in the new (someone has to pay, after all), but make sure you are addressing the root cause of the real problem. And be sure you are looking at the right tool. If you were compromised by a persistent attacker, you may be looking at the wrong technology. Maybe you really need full packet capture. Maybe not, but at least ask the question.

Is is realistic to think you can deploy a common rule set across your enterprise? We’re talking about a central management and reporting capability, which doesn’t matter if every operating division maintains their own IT shop, with it own monitoring tools, and it takes an act of Congress to get them in the same room. Don’t expect people to change just because the organization gains the ability to monitor across the enterprise. Having a technical capability doesn’t mean you will have agreement on whether or how to use it. Politically, will people regard this whole project as either snooping or unwelcome interference, ensuring it is never fully deployed?

Economics

Even if your introspection and expectations are in line, there is still economic reality. IT groups need to do more with less, and that’s not changing. So you need to weigh the cost of getting your existing product functional against replacing it. Even if you want to stack the deck against the incumbent, don’t forget the cost (and time) to train your folks on the new tool – or the professional services to migrate your existing rules, data sources, and data to the new tool. If you managed to get some of that done during the proof of concept, that’s great, but there’s certain to be more as you move to full deployment.

The point here is to be sure you are comparing apples to apples. Sure the new platform may do a lot more, but at what cost? If essential reports are not getting produced, or you find yourself running on what feels like a deprecated platform, you still need to account for the purchase, maintenance, deployment, customization, and training. Make sure you are thinking about total instead of merely procurement cost. Even OpEx is real money, at least the last time we checked.

Documentation

The end goal is a recommendation, so you need to document what you think and then present it to the folks with the money. Given all we know, here is how we would structure that artifact of your decision process:

1. Requirements: Tell them what you need, and who told you that you need it. Compliance and security requirements come from different groups, so make sure these dependencies are referenced.
2. Current Product Evaluation: What works and what doesn’t work with your existing solution within the context of your requirements, both now and for the next set of use cases.
3. Challenger Assessment: Summarize the work you did to find the next platform. Which vendors did you disqualify and why – you never know if your CFO’s brother-in-law works for a vendor. What did you learn in the proof of concept? Which competitor came out on top?
4. Cost Estimate: What will it cost to move to the new platform? What is capital expense and what is operational? How does that differ from making incremental improvements to the incumbent, and what functionality are you sacrificing in the move?
5. Migration Plan: If you ultimately decide to replace the SIEM, what does the migration look like? How long will it take? Will there be a disruption of service? Will there be any exposures and for how long? You need all these answers before you pitch to the powers that be. Not to the point of building a Gantt chart – that comes at the end – but enough to answer the tough questions.
6. Recommendation: Your entire document should be building to this point, where you put the best path down on paper. If it’s a surprise to your audience, you did something wrong. This is about telling them what they already know, and making sure they have an opportunity to ask any more questions.

But even if the recommendation is in, the decision is far from done. Now you have to negotiate with the new vendor (or the incumbent) and this is when your process is most vulnerable. An incumbent losing the deal will act desperately to save it. The challengers will do likewise if they think you’re staying put or choosing a competitor. Even better, the first price estimate is rarely the best, so there is an opportunity to get some price and/or service concessions as you work on closing the deal. We’ll discuss that process in the next post.