by Dr. Anton Chuvakin
Ouch! That “Venus” SIEM appliance that we got with routers has finally croaked. That piece of PHP brilliance that pre-pre-previous security engineer wrote has been buried under the thick pile of XML. That managed SIEM provider has annoyed us one last time.
What do the above situations have in common? The unfortunate time to replace your SIEM has come. What to expect, apart from copious amounts of pain? This post will shed some light on this conundrum, based on author’s experiences.
First, it goes without saying that it is better to choose the right SIEM the first time (e.g. see “On Choosing SIEM” and other posts mentioned below) than to migrate from a SIEM that has been collecting logs (and dust) for a few years. However, you might not have any say in the matter – you might have inherited it, your “evil boss” might have procured the previous SIEM without asking you or you might have built it yourself after a particularly bad hangover… Also, your organization might have simply outgrown the SIEM or your early generation SIEM vendor has not kept up with innovation in the space. In any case, you have a SIEM and you need a new one.
Let’s look at the good side of the situation:
- It is very likely that you learned some super-valuable lessons from your previous SIEM experience (other people have to hire consultants to get to those lessons) and now can avoid the common purchasing process pitfalls (some discussed here, BTW)
- You have much more confidence while discussing confusing SIEM features with vendors – speaking from your previous SIEM experience (this alone will make your new SIEM purchase process much less painful)
- You have some semblance of the logging policy across the systems that log into SIEM – that puts you ahead of those organizations who are just getting their first SIEM or log management tool
- It is possible that you built some operational procedures around SIEM (such as for PCI DSS log review or other purposes) and those would be handy for a new SIEM as well
- If you have to write an RFP (as I discuss here), the chances are that your new RFP would be MUCH better and more likely to result in a good vendor short list
- Treat this situation as positive, think “I now know more than 90% of people buying a SIEM, thus my new SIEM project will be a success”
A few things to avoid and pay attention to:
- Suppress that “I’d buy anything but this crap” mentality – think “what problems will a new SIEM solve or solve better?”
- Avoid taking shortcuts (such as not doing a PoC); you are more knowledgeable, but not prescient…
How might a migration process look like? This assumes that you have already selected a new product, tested it in the lab and are ready for production deployment.
- Prepare to run both products for some time – this might range from a few weeks to months
- Draft the new SIEM vendor to help you migrate the data; after all, they are getting the prize
- Potentially, be prepared to keep the old SIEM running (without paying for the support contract, of course) or at least keep the old data backups – this becomes important if complete data migration is impossible due to architecture differences between the new and old SIEMs. Ideally, your log management tool will hold raw log backups and so keeping the old SIEM in operation won’t be needed.
- One of the biggest migration efforts will be migrating SIEM content: reports, rules, views, alerts, etc. As well all know, such content is not really portable across SIEMs and you should be prepared to simply recreate all the custom content AND all the default content that you used in the the old SIEM and that the new SIEM might lack.
By the way, I have seen more than a few organizations start from an open source SIEM or home-grown log management tool, learn all the lessons they can without paying any license fees – and then migrate to a commercial SIEM tool. Their projects are successful more often than just pure “buy commercial SIEM on day 1” projects and this might be a model to follow (I once called this “build then buy” approach)
Dr. Anton Chuvakin
.
Parses the new BTF-specific syslogs that provide visibility into blocked site traffic 
Posts
