What every CISO should consider before a SIEM migration
Before starting a SIEM migration, the security team must identify the data, rules, workflows and policies they need to transition to the new tool or service. Here's how to get started.
No SIEM strategy, platform or service is perfect. Enterprise needs and circumstances change. Providers and offerings evolve. New options arise. Inevitably, many organizations must eventually migrate from their existing SIEMs or SIEM providers to new ones.
Upon deciding a new SIEM is necessary, the CISO should approach implementation strategically, ensuring important data, rules, playbooks and workflows remain available during and after the transition. A successful and responsible SIEM migration also minimizes disruptions stemming from the discovery of forgotten technical integrations and undocumented use cases.
Don’t forget the data
The lifeblood of a cybersecurity operation is data: data about entities in the environment, data about what those entities are and aren't supposed to do, data about how those entities behave, data about the cybersecurity infrastructure itself and so on.
Before a SIEM migration, CISOs must lay careful plans to ensure necessary data from the old platform is preserved and usable by the new one. The following data is especially important:
Entity behavioral data. A zero-trust environment requires three kinds of data: policy data that dictates which entities are allowed to talk to each other, identity data that determines whether an entity is in fact who or what it claims to be, and behavioral data that shows how entities act in the environment and whether those actions deviate from baseline norms. While not involved in maintaining policy or identity data, the SIEM is integral to collecting behavioral data. When switching tools or providers, a CISO must ensure the security team can preserve and transfer baseline behavioral data for all entities in the environment.
Policy enforcement data. Logs showing security policy enforcement are important to incident investigations, incident response and after-incident reporting. This data should transfer to the new SIEM platform and remain available during migration. At every step of the transition, it must also be clear to the security team which platform -- old or new -- is the authoritative source.
Compliance-related data. Many organizations are required by law to maintain cybersecurity-relevant log data. For example, power utilities and telecommunications providers must be able to provide evidence that they were, at any given point in time, compliant with specific security requirements in their respective industries. Ensure continuity in compliance-related data collection and confirm that historical data from the old platform will be available after migration -- either by ingestion into the new tool or through an archival platform.
Take custom rules, playbooks and workflows with you
If data is the lifeblood of cybersecurity, automation is rapidly becoming its beating heart. Some SIEM automation includes obviously SIEM-specific things, such as -- possibly at the behest of another tool or human operator, or possibly based on the SIEM's native user and entity behavior analytics functionality -- instituting extra monitoring on a network entity that is acting unusually.
If data is the lifeblood of cybersecurity, automation is rapidly becoming its beating heart.
John BurkeResearch analyst and CTO, Nemertes Research
Less obviously, multiple facets of automation and process knowledge are often now embedded in SIEM systems and services, which -- like many cybersecurity tools -- have porous functional boundaries. SIEM platforms can play key parts in incident response, for example, and might also serve as repositories of institutional knowledge in the form of automated workflows among roles or teams. During a SIEM migration, CISOs should pay attention to preserving important automation and process information, such as the following:
Custom detection rules. SIEMs filter incoming data to look for notable events and anomalies. Any event-parsing rules the organization has developed, or that a service provider has developed on its behalf, need to be documented for replication in the new platform.
Preservation of organization-specific playbooks and workflows. Incident response playbooks define the steps that staff and automation tools should take in the event of a suspected or confirmed cybersecurity incident. Workflows automate many of the actions and processes that playbooks dictate, as well as day-to-day operational processes. Ensure all active and relevant workflows and playbook components from the old SIEM platform are replicated in the new one. Note that active and relevant are important considerations. A SIEM migration is an opportunity to prune dead wood by leaving behind workflows or playbooks that have been superseded but not yet deleted.
Minimize surprises: Forgotten integrations and unknown users
A SIEM migration stress tests how well the cybersecurity organization knows itself and the larger enterprise. Often, the actual migration process uncovers forgotten integrations with other cybersecurity systems or network management systems.
Similarly, it is not unheard of for other SIEM stakeholders in the enterprise to be flushed from the underbrush by the transition. For example, application developers might quietly lean on the SIEM in some previously undocumented way and fail to make their use case known until the migration disrupts it.
Late discovery of a group whose needs should have influenced requirements for the new SIEM might result in only a slight delay in the migration's timeline. Be warned, however, that this oversight can easily drive up expenses, especially if required features cost extra in the new platform, or if the new SIEM can't meet the group's needs -- forcing a new round of product selection.
John Burke is CTO and a research analyst at Nemertes Research. Burke joined Nemertes in 2005 with nearly two decades of technology experience. He has worked at all levels of IT, including as an end-user support specialist, programmer, system administrator, database specialist, network administrator, network architect and systems architect.
