Eight Steps to Migrate Your SIEM

In a large enterprise, the ingestion of security logs, IT system logs and other data sources can easily reach a range of hundreds of thousands to millions of events each day and lead to storing terabytes of logs daily. It’s impossible for humans to manually keep up with this deluge of data, so they turn to security information and event management (SIEM) tools to do the work more efficiently.

With the relentless wave of cyberattacks and data breaches, however, the performance of legacy SIEMs is under scrutiny due to their inability to scale to detect the huge number of threats facing organizations today, and their limitations when it comes to helping security teams investigate and respond to incidents efficiently. In response to this, many enterprises are re-evaluating their SIEM and migrating to new technology. While this is exciting, migrating a SIEM is no trivial task.

Why migrate from a legacy SIEM?

The surge in cyberattacks, shortage of qualified security analysts, sheer volume of events and number of devices pumping data into the enterprise SIEM are posing several operational issues. For example, security operations center (SOC) teams universally complain about time wasted by chasing false positive alerts. The culprit for issues like this is that legacy technology in many SIEMs is completing its second full decade since it was introduced to the market. Four legacy characteristics include:

Excessive logging costs – Charging SIEM usage based on the amount of data ingested and processed is a characteristic of legacy SIEMs, but it never really made sense given that SOC teams benefit from having the most information possible about their environment to detect and investigate incidents. This licensing model penalizes SOC teams for collecting more data and limits capabilities for threat detection and creates blind spots during incident investigations.

Inability to catch unknown threats – The legacy SIEM model typically was based on correlation rules which requires analysts to know what they are looking for. But as the variety of threats has risen, a reliance on rules has left legacy SIEMs unable to detect unknown and advanced threats such as malicious insiders.

Untraceable distributed attacks – When tracking is substandard, SOC analysts get an incomplete picture of users’ activities. A common scenario is lateral movement, where an attacker first breaches a network and then moves around inside an organization, across credentials, devices or login locations. Consequently, the team misses threats and is unable to determine the full scope of attacks.

Manual investigation and remediation – When legacy SIEM technology has limited automation, the organization is faced with increased risk and longer exposure to threats. For example, every investigation requires construction of a timeline to evaluate events and understand their implications for security. For legacy SIEMs, those steps are usually manual and time consuming.

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. A few days of planning upfront can save the team weeks of time and help avoid mis-steps later in the process.

Process Flow for SIEM Migration

1. Determine SIEM Priorities - It will typically take 2-4 weeks to identify all of the stakeholders and get a consensus on your top business issues and priorities. When deciding on these priorities, the SIEM migration team must consider the organization’s risk management framework in determining priorities for the SIEM, including compliance with relevant industry guidelines, regulations and statutes.

2. 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?

Examples of typical use cases include protecting against insider threats; identifying compromised credentials, prioritizing security alerts, and more. It’s common for a legacy SIEM to have 50 or even hundreds of use cases. Replicating all legacy use cases may be unnecessary as new technology can eliminate the need to manually manage some scenarios. For example, a new SIEM can reduce the need to create and maintain correlation rules with out-of-the-box detection models.

3. Scope Data Collection Sources - The ultimate purpose of a SIEM is to allow analysts to quickly detect and remediate security threats. Having a SIEM that integrates data logs from a broad array of IT and security products is essential for effective remediation. Data sources need to map to the use cases identified in the previous step.

4. Configure Log Sources – Configuration of log sources is a non-trivial process for teams to take on themselves. Investigate provider’s ability to help with standardizing and parsing data sources if assistance if needed.

5. Prepare SIEM Content - Train SOC analysts in the approach of the new SIEM if you are moving from exclusive reliance on rules triggering alerts to models built using behavioral analytics based on machine learning. In most cases, behavioral analytics speeds detection, provides more accurate results, and enables rapid, precise response to critical incidents.

6. Define Operational Processes - Getting good results from the new SIEM will require SOC analysts to adjust their daily operating processes. Analysts will especially want to know if they have to learn a new query language. A modern SIEM often has a point-and-click interface, which alleviates the need for command line controls.

7. Establish Benchmark Criteria - Establishing benchmark criteria for the new SIEM will help your organization measure and evaluate its performance. Benchmarks should employ criteria from the management framework or frameworks currently used by your organization. This could be ISO for compliance, PCI DSS for payment security, and operational benchmarks such as search times, mean time to detection, mean time to response, number of alerts closed, and so forth. It’s important to choose metrics carefully in order to accurately gauge success. For example, a modern SIEM’s analytics will often dramatically reduce the number of alerts to be investigated compared to a legacy SIEM

8. Evaluate Next Steps - The last stage of SIEM migration is evaluating next steps like developing new use cases as business priorities change.

Conclusion

By making the decision to migrate a legacy SIEM, organizations will launch a journey touching many parts of the enterprise. The migration will entail changes to a wide array of people, process and technology.

Process is an integral part of the eight considerations, and implementation will directly affect daily roles of some stakeholders. It’s important for organizations to approach migration with a positive outlook about the new benefits that will appear as a result of this process.

By approaching security with a new SIEM, your enterprise will enable better security and compliance. As the technical enabler, the new SIEM will also help stakeholders be more productive and fruitfully engaged in this vital mission.

About the author: Trevor Daughney is Vice President of Product Marketing at Exabeam. Trevor is a marketing executive with a track record of building high performing teams to take enterprise cybersecurity SaaS and software technology and turn them into successful global businesses.

Copyright 2010 Respective Author at Infosec Island via Infosec Island Latest Articles "https://ift.tt/2ZecO9D"