A security information and event management (SIEM) platform is one of the most critical tools for securing a large enterprise. As with all technology, tools age and begin to lose their edge. Older SIEMs are struggling to make sense of millions of events and terabytes of logs every day. Human analysts struggle as older SIEMs force them to manually keep up with this deluge of data – if qualified experts can even be found. This dangerous scenario is why many organizations are looking to refresh their SIEM.
Frankly, migrating a SIEM is no trivial task. Especially for complex technology that is the lynchpin of security operations centers (SOCs). To help you prepare for the process, Exabeam offers eight strategic steps to guide SIEM migration and put your organization on a path to success. In this first post of a three-part series, we address the initial steps of preparing to migrate.
Why migrate from a legacy SIEM?
Your specific motivations may vary, but after guiding hundreds of SIEM migrations, Exabeam has noted four typical legacy characteristics that triggered an upgrade:
Excessive logging costs– Charging SIEM usage based on the amount of data ingested and processed made sense before big data. Now, having all the data processed for analysis with data science is vital. Per-usage costs create unpredictable pricing and are a disincentive for accurate threat detection.
Can’t catch unknown threats– Correlation rules underpinning the legacy SIEM model require excessive maintenance with unproductive results. Rules can’t predict everything and are blind to detecting advanced threats.
Missing distributed attacks– Legacy SIEMs provide analysts with an incomplete picture of user activities, which hampers detecting lateral movement – especially in distributed environments.
Manual investigation and remediation– Older SIEM technology limits automation, so forcing analysts to manually stitch together incident timelines increases risk and brings longer durations of exposure to threats. The reaction is to hire more analysts, but skilled experts are getting harder to find.
Solving these legacy issues is a strong motivation for SIEM migration. Before initiating the process of migration, it’s useful for stakeholders to get a big-picture sense of what these steps entail and how they may affect new workflows. Let’s look at three steps that comprise preparation for migration.
Steps for preparation
Determine SIEM priorities
Structuring SIEM priorities is important because they will determine when the migration is “done” and if it was a success. Being a strategic effort, SIEM migration will touch many areas of the enterprise so involving stakeholders is crucial.
Foremost is protecting the organization’s “crown jewels” whose compromise could result in considerable damage to the business. Examples are intellectual property (IP), customer records, financial records, personnel records, systems running critical applications, networks, security devices, and so forth.
Your organization’s risk management framework should guide determining priorities for the migration. Priorities include compliance with relevant industry guidelines, regulations and statutes. We suggest you involve relevant executives and senior managers in this phase to discover business priorities for migration. These stakeholders will have a keen interest because their job roles often are responsible to make IT drive business outcomes.
Migration does not necessarily require a wholesale replacement. It may suffice to augment the legacy SIEM with a new SIEM’s capabilities such as behavioral analytics or automated response capabilities. Or perhaps a phased approach is better, which temporarily runs the new SIEM in parallel with the old one. A pending SIEM license renewal date may also affect your decision about when to decommission and cutover. You also need to consider the destination for your SIEM migration: on-premises, a public cloud, a hybrid cloud, or to software-as-a-service (SaaS).
Timeline: Step 1 typically takes two-four weeks to identify all the stakeholders and get a consensus on your top business issues and priorities.
Select use cases
Selection of use cases for the SIEM migration should answer the question: what problems are we trying to solve with the new SIEM? Consider use cases in terms of business priority. How would an event impact the business? How often does the use case occur? Ignoring or minimizing the business aspect of use cases may seem like an obvious misstep, but it occurs frequently and will lead to disappointing results for the migration.
Examples of typical use cases include protecting against insider threats; identifying compromised credentials; detecting account creation and management; augmenting endpoint analytics; monitoring high-risk employees; and prioritizing security alerts.
It’s common for a legacy SIEM to have 50, 100 or even hundreds of use cases. A new SIEM provides technology that can manage these use cases more effectively such as by reducing the need to create and maintain correlation rules or increasing automation. Replicating all legacy use cases may be unnecessary as new technology can eliminate the need to manually manage some scenarios.
Elements for each use case must address people (who will perform the tasks), process (how the use case will be accomplished) and technology (what aspects of the new SIEM and supporting IT infrastructure will provide related functionality). Also, consider support for specific use cases that is included with the new SIEM. Exabeam provides more than 400 use case models to help accelerate this phase of migration planning for your organization.
Timeline: Step 2 typically takes two-four weeks to select the use cases for your new SIEM.
Scope data collection sources
The ultimate purpose of a SIEM is to allow analysts to quickly detect security threats and remediate them.
Having a SIEM that integrates data logs from a broad array of IT and security products is essential for effective remediation.
Each use case requires data from a list of related physical and virtual systems and applications such as servers, network devices, firewalls, endpoints, operating systems, applications, databases, directory services, information services, and other related infrastructure hosted in public, private or hybrid clouds. Also, consider contextual data sources such as human resources or a configuration management database.
The scoping process includes aligning essential log data from security and IT devices and solutions with each use case. Examples are:
- Insider threat
- Compromised credentials
- Account creation and management
- Endpoint anomalies
- Security alerts
The migration team should ensure that the systems with the required log data exist to support each respective use case. If not, the team may need to re-prioritize the order of implementing use cases.
Verify if log files are available for each of the required assets. SOC analysts do not always own systems that generate data so some negotiation with owners may be required.
It’s very important to determine how and where log data will be stored, and for how long. Storage is a huge limiting factor for legacy SIEMs. Modern SIEMs are addressing this pitfall with data lakes, sometimes with an option of being hosted in the cloud. A major benefit is that these architectures return quicker search results.
Finally, financial stakeholders will insist that the pricing model of your new SIEM can accommodate all the data you need to collect within a predictable budget.
Timeline: Step 3 typically takes four-eight weeks to map the appropriate data sources to the use cases for your new SIEM.
Proceeding to SIEM implementation
A new SIEM will unlock fresh capabilities to bring stronger security to your enterprise. We hope Exabeam will play a prominent role in your choice. Our next post in this series will look at steps for implementation of the SIEM migration. To learn more right away about migrating your SIEM, watch our webinar, “Eight Steps to Migrate Your SIEM.” Or download our white paper, Eight Steps to Migrate Your SIEM. These sources will provide you with more details to help guide the migration process.