Demystifying SIEM migration: Pitfalls to avoid and tips for ensuring success

Migrating to a new security information and event management (SIEM) solution can feel like a daunting task, like moving to a new house. Over the years, a lot gets accumulated and sometimes is forgotten until found in a corner. 

This blog identifies steps you can take to reduce the pain typically associated with a migration, tools that can help along the way, and questions you should ask during each phase of a migration.

Why migrate?

SIEMs are a significant investment, and once deployed, organizations typically use the same technology for many years. The solutions require a lot of time to be maintained and tuned to meet an organization’s needs, cover all necessary security use cases, ingest all required data sources, and meet any other business needs.

Over time, however, you may start to identify limitations within your SIEM that hinder your security operations team’s performance, restrict use cases or coverage due to scaling challenges, or limit you from fulfilling new business requirements or initiatives. 

[Related article: Why almost half of organizations want to replace their SIEM]

Migration phases

There are typically three stages of a SIEM migration:

1. Planning and Design
2. Execution and Implementation
3. Operationalize and Refine

Planning and Design

To ease migration, it’s crucial to invest in extensive planning. You may be tempted to “lift and shift” everything in your existing SIEM to your new one, as this might seem like the most straightforward approach. But this is not the right plan, for several reasons:

1. Every SIEM system is different. No two SIEMs are the same. They have different architectures, licensing models, data stores, features, and detection techniques. As an example, attempting to blindly copy use cases from one SIEM to another may cause frustration, as your new SIEM might offer better ways to achieve what needs to be done.

2. Requirements change over time. It’s normal for some use cases, data sources, dashboards, and reports to lose relevance or value over time. Migrating them for the sake of migrating “everything” can be a waste of resources.

3. Team members work and think differently. What used to work in the past may not be the best solution to address organizational needs or provide the best experience for teams today. Your people are the most important asset you have, and they will shape the success of your next SIEM. During planning, always remember the team's needs and skills.

The following are a few ways to avoid the above pitfalls:

1. Familiarize yourself with your new SIEM. Not every team adopting a new SIEM spends enough time learning its ins and outs. There may be a use case that was done one way on your old SIEM that  can be done differently — and more efficiently — on your new SIEM. You may have previously ingested a data source using a specific method, but your new SIEM may offer a better way. Spend time during the planning phase to closely examine what your new SIEM offers. Bookmark the documentation page, and work with the vendor to understand the resources available for learning and where you can go to ask questions.

2. Review existing use cases, data sources, detections, dashboards, and reports. If you haven’t used a data set in a while or it isn’t providing value, maybe it isn’t worth migrating it to your new SIEM. This is also true for your dashboards, reports, and detections. The same goes for any other existing use case. If it doesn’t improve your security operations center (SOC) processes or doesn’t align with new strategies, it probably isn’t worth migrating.

3. Empower your team members. Have you asked your team what’s important for them or what they need to feel successful? Unfortunately, this is often overlooked, when in reality it’s the most crucial step in ensuring a successful migration. Every practitioner has their own strengths and different ways of working that allow them to feel empowered and able to get the job done. A migration to a new SIEM is the perfect opportunity to review existing processes and methodologies and adapt them to better suit the needs and strengths of your team, or perhaps adopt new industry frameworks and tools for incident response.

Execution and Implementation

This phase of the migration is typically the longest, but it should be straightforward if proper planning was done. 

When implementing the data sources, use cases, and other elements identified during the planning phase, utilize the tools offered by your new SIEM vendor, especially for any work that might need to be done in bulk.

Below are some questions to ask as you begin your implementation:

• Do any APIs or scripts exist for automating certain tasks?
• Does your new SIEM vendor provide reusable profiles for software deployment tools like JAMF, SCCM, or Intune?
• If your new SIEM is cloud-based, are there any native cloud service provider marketplace integrations that can streamline data ingestion and simplify setup?
• Are any default dashboards or reports available to track successful data ingestion, data quality, or data schema compliance?
• For any custom detection rules or use cases being migrated, do any testing tools exist for confirming that they run as expected?

Additionally, your new SIEM vendor might have a thriving community with resources you can put to use. Don’t be afraid to reach out and ask questions to other users — it’s likely that someone has already solved a challenge you might be facing.

Operationalize and Refine

This phase covers the merging of any operating procedures with the workflows and processes provided by your new SIEM. This phase is ongoing, as procedures should be reviewed and updated regularly to enable adoption of any new SIEM features introduced with version upgrades, or if any other third-party tooling is introduced into your team’s workflows.

Here are a few tips to consider:

• To keep current with the latest features, learn how your new SIEM vendor announces releases. If you don’t, you might miss a new feature that could solve a challenge you’ve been facing. Use any feeds and email notifications available. If your vendor has an open code base, you can set up notifications for relevant pull requests or issues.
• As previously mentioned, if you’ve familiarized yourself with your new SIEM, you may identify more efficient workflows, actions, and functions available to you natively that would have previously required other tools, potentially enabling you to consolidate.
• If they are open to it, provide regular feedback to your SIEM vendor, especially if you’re using a relatively new feature or have run into a challenge that you managed to solve in a unique way. Most vendors will gladly listen to your input. This will strengthen your partnership with your SIEM vendor, supporting a successful migration and deployment.

Next steps

Check out our migration guide to learn about the features Elastic offers to help you migrate to Elastic Security, as well as several other resources to discover more about the platform.

We hope that this material helps demystify some of the typical challenges and pain points of a SIEM migration. If we can be of any further help, we invite you to join our public Slack workspace or ask any questions you may have on our Discuss forum.