SIEM: Out with the Old
About 4 years ago we saw the first big wave of replacements of older email security tools with a second generation we now call ‘content security’. Early email security products were deployed in-house and focused on anti-virus, anti-spam, and mail server integration. The current generation of products offered new SaaS and hybrid deployment models, technology advancements in web and content filtering, more elastic service sets, and centralized web management consoles. And let’s not forget the larger security firms with products lagging far behind the state of the art, milking their cash cows while smaller firms innovated. We see the same wave of succession right now in the SIEM market. First generation products – despite being entrenched – make customers uncomfortable enough to start asking what else is available. They are looking for better, easier, and faster. We hear numerous complaints about existing solutions: “We collect every event in the data center, but we can’t answer security questions, only run basic security reports.” “We can barely manage our SIEM today, and we plan on rolling event collection out across the rest of the organization in the coming months.” “I don’t want to manage these appliances – can this be outsourced?” “Do I really need a SIEM, or is log management and ad hoc reporting enough?” “Can we please have a tool that does what it says?” “Why is this this product so effing hard to manage?” We see new products designed to both improve scalability and come closer to real-time analysis. They can collect events from just about every type of network device and application, normalize, and provide better drill-down capabilities. And there are many new analysis features – including enrichment, attack signature patterns, and application-layer monitoring. The first generation of products are looking old and I hear more and more unhappiness with today’s entrenched solutions. I ran across Anton Chuvakin’s How to Replace a SIEM? this week. But his tips apply to a wider audience than just Cisco MARS customers kicking other vendor tires. He offers two excellent vendor migration suggestions that bear repeating. First, leave the existing system running for some time – at least through the migration. This way you are still covered during the migration, and in the event previously collected data is not compatible across systems, you can still run reports and access forensic data. I have seen cases of “rip and replace” where the old system is removed while – or even before – the new system is up and running. That means no coverage for a (potentially extended) period. I sometimes call that ‘optimism’, but you may prefer another term. The sales process is a good time to ensure your (new, hungry) vendor can run in parallel with your existing tool – don’t buy it and then let them tell you that’s an unsupported scenario. Second, have the new vendor help with setup. Deployment issues are some of the most serious problems we hear of. Hiring the vendor not only helps avoid many pitfalls, but also makes it easier and quicker to replicate the rules and reports you currently use. And during the sales process you can negotiate attractive pricing on getting the work done as a condition of the sale. But before you replace a SIEM there are a couple other things you need to consider: Post Mortem: What exactly are the problems with the existing system and what do you hope to accomplish? It’s not hard to come up with a list of problems and areas for improvement – it’s much harder to vet a new technology to confirm addresses your demands without adding its own slew of new pitfalls. The problem here is that vendors will tell you they can do whatever you ask for. Realistically, you need to check with other customers who already own and operate new products before you buy – see what their experiences have been. What you have: The SIEM you have was installed for a reason. Actually, they are normally installed for several reasons, to address a list of business and security problems which grows over time. It’s easy to forget everything your system does when its failings are so easy to see. Make sure you have a complete understanding of what issues are currently being addressed and must be replicated on the new system. This includes compliance and security functions across management, operations, and security organizations. Worse, the existing SIEM likely feeds data to other systems you forgot about. The list you build is almost always much longer than expected. The good news is this process saves time and avoids trouble down the road, and helps form RFP questions and guide proof of concept testing. You want a new product that handles your new wish list, but don’t give up on any core reasons you are already running SIEM. SIEM replacement can be easier than a first installation, but you need to leverage the knowledge you have to make it so. That may sound easy, but it takes work to gather the organizational memory you need and clearly document your goals moving forward. Share: