Thinking of migrating your SIEM? First read this essential advice from senior consultant Bryan Grady, who shares his top SIEM migration tips
Security information and event management (SIEM) migrations are highly complicated operations. Not only are there a huge amount of moving parts to consider, but there is also the added pressure of what’s at stake.
For example, what if you suffer downtime and are exposed to threats? What if you miss alerts during the cutover, losing valuable data? What if detection rules don’t translate or integrations break? What if bad configuration causes performance to drop and costs to spike?
The ‘what ifs’ are endless, but as long as you are prepared with the right support and expertise, it is possible to avoid the pitfalls and make your SIEM migration straightforward and stress free.
Here at NETbuilder, we have spent more than 20 years in cyber security, performing over 100 SIEM migrations for some of the biggest, most complex organizations in the world. As you can imagine, all this experience in security operations center (SOC) transformation has taught us a lot.
To help ensure you are fully prepared, we asked one of our senior consultants, Bryan Grady, to share some of the most important lessons learned during our time guiding cyber security teams through the SIEM migration process.
Pro Tips for SIEM Migration
by Bryan Grady
1. Have a Full Data Inventory Beforehand
Many organizations have no coherent picture of the different log sources they were ingesting before their SIEM migration, and that can cause problems.
They know top talkers and the sources they were substantially monitoring for their SOC, but there can be hundreds of products or log formats that have been ingested for years that nobody is actively aware of.
When planning your migration, ask yourself this:
- If the data was being ingested via a SIEM integration before, do you know what endpoint or dataset was being collected by that integration?
- How do you plan to find that out, to make sure you can ingest the same data into your new SIEM?
It’s key to know every vendor and product that was being ingested and monitored, make a list and have it ready before the SIEM migration process begins.
2. Know Who Owns Each Data Source
Building on the inventory outlined in point one, it’s important to know which teams to contact for each of those data sets.
Start by compiling the following lists:
- A contact list for the actual product ownership so that you know exactly who to talk to about getting the data routed into your new SIEM, or clarify any logging issues
- A contact list for who is utilizing and searching that data in the SIEM
Once you have these lists in place, you need to consider who is going to own the process of validating that the data looks correct. It’s essential to confirm that it meets business and security requirements in the new platform.
3. Prioritization: Both Data Sources & Use Cases
Nearly every SIEM migration happens under a degree of pressure, with a rushed cutover to get the new SIEM stood up and the old one deprecated as fast as possible.
Obviously, the goal is to get everything you need set up in the new tool, but some data, alerts, and dashboards are more important than others.
You need to know what absolutely must be ingested and set up in the new platform on the drop-dead day with the prior SIEM. And the answer cannot factually be ‘everything’.
There is nearly always bloat in a legacy SIEM, with data that isn’t being regularly searched, abandoned dashboards, or ‘nice-to-have’ alerts that trigger way too often and are just adding to SOC overload.
Solid prioritization will help to avoid this and ensure utmost efficiency both during and after the migration process.
4. Plan For the SIEM Overlap
There’s going to be a period where both SIEMs are semi-active, both ingesting data while the team validates ingest, data parsing, and the creation of alerts and dashboards in the new SIEM.
When doing so, remember these two essentials:
- Ensure you have the budget to support both platforms during that period
- Ensure the ingestion mechanism into the new SIEM doesn’t introduce resource constraints. As an example, not doing thorough architecture validation and installing a new collection agent in addition to the existing one on your servers could lead to a CPU spike that causes them to shut off
If you’re not going to ingest data into both SIEMs simultaneously, you’re accepting massive risk. This includes being unable to pre-emptively troubleshoot data ingest and parsing into the new SIEM when you do cut over the data feed, as well as the validation of created alerts and dashboards.
5. Pick New Platforms Your Team Can Own & Maintain Going Forward
Very often, clients will buy a new SIEM purely based on license, or because there are some exciting features mentioned in the marketing copy – everyone loves AI or ML-based alerting!
It’s important to emphasize that the purchase should be based on what the security team is looking for, first and foremost.
Here are some questions to keep in mind:
- Is the new SIEM too complex for your team to maintain without the ongoing assistance of a professional services (PS) organization or managed service provider (MSP)?
- Does the new SIEM have integrations for important data sources you regularly use?
- Is the cost of ownership only temporarily decreased? In other words, is the vendor giving a bargain for the first year or two, which is then guaranteed to go up in price?
- Does the new SIEM have a strong support team and a good ecosystem of PS organizations should you need some occasional extra assistance with projects?
- How is the new SIEM’s documentation and training materials?
By ensuring you do proper research and involve all the key players before making your decision, you’ll avoid potentially expensive fixes further down the line. After all, nobody wants the cost, stress, and upheaval of multiple SIEM migrations in only a few years.
6. Take the Opportunity to Recalibrate Needs
View this process not just as a cost-saving exercise to purchase a new tool with a cheaper license or some shiny new features. Use it as a chance to refocus the use of your SIEM as a truly enterprise-grade security platform.
Here are three key areas of focus:
- Stop ingesting data sources that are voluminous and not often used in alerts and important dashboards. If retention is the goal, find ways to utilize data lakes and object stores for that type of data.
- If certain logs or metrics are primarily used more for business or application performance monitoring insights, it may be worth considering routing that data to alternative platforms more tailored to those purposes, which could charge less for ingest than many SIEMs do.
- Clean up your knowledge objects. There’s no point in migrating alerts or dashboards that aren’t regularly being used/checked, or were left orphaned after team members departed the organization. If there’s lots of spare time in the SIEM migration project, it may be worth migrating those things anyway, but as mentioned above: there’s never spare time during a SIEM migration! Therefore, emphasize the critical components and then work down in severity from there.
In short, make the most of this opportunity to optimize performance long into the future.
Conclusion
We hope Bryan’s pro tips for SIEM migration have helped you prepare for the big switch. If you need further guidance on next steps, stop right there and call us for some advice.
NETbuilder has led some of the largest organizations in the world through the SIEM migration process, and we can do the same for you.
If you would like to work with Bryan or any of our highly experienced consultants, contact us today for a no-obligation chat.
If you’d like to learn more about the SIEM migration process, we have a host of content available that can help. Visit our SEIM migration resource center to learn more.
