How to manage a side-by-side transition from your traditional SIEM to Azure Sentinel

August 3, 2021 TH Author Cybersecurity

With every week bringing new headlines about crippling cyberattacks, and with organizations growing increasingly distributed, security teams are constantly asked to do more with less. Moving to cloud-native security information and event management (SIEM) can help security teams analyze data with the scale of the cloud, and empowers them to focus on protecting the organization, not managing infrastructure. As the industry’s first cloud-native security operation and automated response (SIEM+SOAR), Azure Sentinel provides security analytics across the organization to fight today’s sophisticated cyber threats. It does this by collecting data across the digital estate—including on-premises systems, software as a service (SaaS) applications, and non-Microsoft cloud environments such as Amazon Web Services (AWS), Linux, or firewalls—and cross-correlating it using AI and machine learning, enabling security operations (SecOps) teams to stop threats before they do damage.

In part one of this three-part series, we explored the first three steps every SecOps team should take to help ensure a successful migration to Azure Sentinel. For part two, we’ll look at ways to manage the transitional phase of your migration. Specifically, we’ll compare the pros and cons of a short-term versus long-term side-by-side deployment, including an examination of the five types of side-by-side configurations, and which one maximizes value from both Azure Sentinel and your traditional SIEM.

What is the transitional phase in a cloud-native SIEM migration?

For an organization using an on-premises SIEM, migration to the cloud typically requires a three-stage process:

Planning and starting the migration.
Running Azure Sentinel side-by-side with your on-premises SIEM (transitional phase).
Completing the migration (moving completely off the on-premises SIEM).

Step 2, the transitional phase, involves running Azure Sentinel in a side-by-side configuration either as a short-term solution or as a medium-to-long-term operational model. Both approaches culminate in a completely cloud-hosted SIEM architecture; the difference is: how long does it serve your interests to remain tethered to your traditional SIEM?

Transitional side-by-side (recommended)

This approach involves running Azure Sentinel side-by-side with your traditional SIEM just long enough to complete the migration to Azure Sentinel.

Pros: Gives your staff time to adapt to new processes as workloads and analytics migrate. Gains deep correlation across all data sources for hunting scenarios; eliminates having to do swivel-chair analytics between SIEMs or author forwarding rules (and close investigations) in two places. Also enables your SecOps team to quickly downgrade traditional SIEM solutions, eliminating infrastructure and licensing costs.

Cons: Can require a shortened learning curve for SecOps staff.

Medium-to-long-term side-by-side

Involves leveraging both SIEMs side-by-side to analyze different subsets of data indefinitely. In this model, some organizations choose to take an extended side-by-side approach over a long period of time, or even plan to run side-by-side permanently.

Pros: Leverage Azure Sentinel’s key benefits—including AI, machine learning, and investigation capabilities—without moving completely away from your traditional SIEM. Saves money compared to your traditional SIEM by analyzing your cloud or Microsoft data in Azure Sentinel.

Cons: Separating analytics across two different databases results in greater complexity (for example split case management and investigations for multi-environment incidents). Greater staff and infrastructure costs. Requires staff to be knowledgeable in two different SIEM solutions. It also results in a much longer time to universal value for Azure Sentinel if the intention is to ultimately migrate to a single SIEM.

What’s the best approach for side-by-side SIEM deployment?

There are five basic deployment models for the side-by-side phase of the migration process. Some of these approaches may seem easier to implement but can introduce unwanted complexity in the long run. Let’s run through the advantages and drawbacks of each:

Approach 1: Moving logs from Azure Sentinel to your traditional SIEM

In this configuration, organizations use Azure Sentinel only as a log relay, forwarding logs to their existing on-premises SIEM. This approach is not recommended, since running Azure Sentinel strictly as a log-relay means you’ll continue to experience the same cost and scale challenges as with your on-premises SIEM. In addition, you’ll be paying for data ingestion in Azure Sentinel along with storage costs in your traditional SIEM. Another drawback: using Azure Sentinel merely as a log relay means you’ll miss out on Azure Sentinel’s full SIEM+SOAR capabilities, including detections, analytics, AI, investigation, and automation tools.

Approach 2: Moving logs from your traditional SIEM to Azure Sentinel

In this approach, your SecOps team forwards logs from your traditional SIEM to Azure Sentinel. For reasons similar to the above, this approach is not recommended. While you’ll be able to benefit from the full functionality of Azure Sentinel without the capacity limitations of an on-premises SIEM, your organization still will be paying for data ingestion to two different vendors. In addition to adding architecture complexity, this model can result in higher costs for your business.

Approach 3: Using Azure Sentinel and your traditional SIEM as separate solutions

In this model, your team uses Azure Sentinel to analyze cloud data while continuing to use your on-premises SIEM to analyze other data sources. This setup allows for clear boundaries regarding when to use which solution, and it avoids the duplication of costs. However, cross-correlation between the two becomes difficult; so this scenario is not recommended. In today’s landscape—where threats often move laterally across the organization—such gaps in visibility pose a significant risk.

Approach 4: Sending alerts and enriched incidents from Azure Sentinel to your traditional SIEM

In this approach, you’ll analyze cloud data in Azure Sentinel, then send the alerts generated to your traditional SIEM. There, you can continue to use your traditional SIEM as your single pane of glass and do any cross-correlation on alerts generated by Azure Sentinel. Though it avoids duplicating costs while giving you the freedom to migrate at your own pace, this configuration is still suboptimal. Simply forwarding enriched incidents to your traditional SIEM limits the value you could be getting from Azure Sentinel’s investigation, hunting, and automation capabilities.

Approach 5: Sending alerts from your traditional SIEM to Azure Sentinel

In this configuration, your SecOps team will ingest and analyze cloud data within Azure Sentinel while using the traditional SIEM to analyze on-premises data—generating alerts back to Azure Sentinel. In this way, your team is free to do cross-correlation and investigation within Azure Sentinel as your single pane of glass, and still access your traditional SIEM for deeper investigation if needed. This is our recommended side-by-side migration method because it allows you to get full value from Azure Sentinel while migrating data at a pace that’s right for your organization.

Coming soon in part 3: Use case migration

In the third and final post in this series, we’ll examine best practices for migrating your data sources and detections, including how to get the most from Azure Sentinel’s powerful automation capabilities. We’ll also offer some tips for finishing the migration and moving completely off your traditional SIEM. 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.