Preparing for your migration from on-premises SIEM to Azure Sentinel

The pandemic of 2020 has reshaped how we engage in work, education, healthcare, and more, accelerating the widespread adoption of cloud and remote-access solutions. In today’s workplace, the security perimeter extends to the home, airports, the gym—wherever you are. To keep pace, organizations require a security solution that delivers centralized visibility and automation; one that can scale to meet their needs across a decentralized digital estate.

As a cloud-native security information and event management (SIEM) solution, Microsoft Azure Sentinel is designed to fill that need, providing the scope, flexibility, and real-time analysis that today’s business demands. In this blog series, we’ll look at planning and undertaking a migration from an on-premises SIEM to Azure Sentinel, beginning with the advantages of moving to a cloud-native SIEM, as well as preliminary steps to take before starting your migration.

Why move to a cloud-native SIEM?

Many organizations today are making do with siloed, patchwork security solutions even as cyber threats are becoming more sophisticated and relentless. As the industry’s first cloud-native SIEM and SOAR (security operation and automated response) solution on a major public cloud, Azure Sentinel uses machine learning to dramatically reduce false positives, freeing up your security operations (SecOps) team to focus on real threats.

Moving to the cloud allows for greater flexibility—data ingestion can scale up or down as needed, without requiring time-consuming and expensive infrastructure changes. Because Azure Sentinel is a cloud-native SIEM, you pay for only the resources you need. In fact, The Forrester Total Economic Impact™ (TEI) of Microsoft Azure Sentinel found that Azure Sentinel is 48 percent less expensive than traditional on-premises SIEMs. And Azure Sentinel’s AI and automation capabilities provide time-saving benefits for SecOps teams, combining low-fidelity alerts into potential high-fidelity security incidents to reduce noise and alert fatigue. The Forrester TEI study showed that deploying Azure Sentinel led to a 79 percent decrease in false positives over three years—reducing SecOps workloads and generating $2.2 million in efficiency gains.

So, when you’re ready to make your move to the cloud, how should you get started? There are a few key considerations for planning your migration journey to Azure Sentinel.

Understanding the key stages of SIEM migration

Ingesting data into Azure Sentinel only requires a few clicks. However, migrating your SIEM at scale requires some careful planning to get the most from your investment. There are three basic architecture stages of the migration process:

• On-premises SIEM architecture: The classic model with analytics and database functions both residing on-premises. This type of SIEM has limited scalability and is typically not designed with AI. Therefore, it may overwhelm your SecOps team with alerts. The on-premises SIEM can be seen as your “before” state prior to the migration.
• Side-by-side architecture: In this configuration, your on-premises SIEM and Azure Sentinel operate at the same time. Typically, the on-premises SIEM is used for local resources, while Azure Sentinel’s cloud-based analytics are used for cloud resources or new workloads. Most commonly, this state is a temporary transition period, though sometimes organizations will choose to run two SIEMs side-by-side for an extended period or indefinitely. We will be talking more about this in the next blog.
• Cloud-native architecture (full Azure Sentinel deployment): In this model, both security analytics and data storage use native cloud services. For this blog series, we are considering this to be the end state: a full Azure Sentinel deployment.

Note: the side-by-side phase can be a short-term transitional phase or a medium-to-long-term operational model, leading to a completely cloud-hosted SIEM architecture. While the short-term side-by-side transitional deployment is our recommended approach, Azure Sentinel’s cloud-native nature makes it easy to operate side-by-side with your traditional SIEM if needed—giving you the flexibility to approach migration in a way that best fits your organization.

Identify and prioritize your use cases

Before you start your migration, you will first want to identify your key core capabilities, also known as “P0 requirements.” Look at the key use cases deployed with your current SIEM, as well as the detections and capabilities that will be vital to maintaining effectiveness with your new SIEM.

The key here is not to approach migration as a 1/1 lift-and-shift. Be intentional and thoughtful about which content you migrate first, which you de-prioritize, and which might not need to be migrated at all. Your team may have an overwhelming number of detections and use cases running in your current SIEM. Use this time to decide which ones are actively useful to your business (and which do not need to be migrated). A good starting place is to look at which detections have produced results within the last year (false positive versus positive rate). Our recommendation is to focus on detections that would enforce 90 percent true positive on alert feeds.

Compare and contrast your SIEMs

Over the course of your migration, as you are running Azure Sentinel and your on-premises SIEM side-by-side, plan to continue to compare and evaluate the two SIEMs. This allows you to refine your criteria for completing the migration, as well as learn where you can extract more value through Azure Sentinel (for example, if you are planning on a long-term or indefinite side-by-side deployment). Based on Microsoft’s experience with real-world attacks, we’ve built a list of key areas to evaluate:

• Attack detection coverage: Compare how well each SIEM is able to detect the full range of attacks using MITRE ATT&CK or a similar framework.
• Responsiveness: Measure the mean time to acknowledge (MTTA)—when an alert appeared in the SIEM and when the analyst first started working on it. This will likely be similar between any SIEMs.
• Mean time to remediate (MTTR): Compare incidents investigated by each SIEM (with analysts at an equivalent skill level).
• Hunting speed and agility: Measure how fast your teams can hunt—from hypothesis to querying data, to getting the results on each SIEM.
• Capacity growth friction: Compare the level of difficulty in adding capacity as your cloud use grows. Cloud services and applications tend to generate more log data than traditional on-premises workloads.
• Security orchestration, automation, and remediation: Measure the cohesiveness and integrated toolsets in place for rapid threat remediation.

In the next two installments of this series, we’ll get more in-depth on running your legacy SIEM side by side with Azure Sentinel, as well as provide some best practices for migrating your data and what to consider when finishing your migration.

For a complete overview of the migration journey, download the white paper: Azure Sentinel Migration Fundamentals.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.

READ MORE HERE