The information presented here is derived from experiences we’ve accumulated while assisting numerous customer migrations, as well as experiences gained by Microsoft’s own security operations center (SOC) in protecting our IT infrastructure. Typically, the migration to Azure Sentinel is undertaken in three phases: starting with data, then detection rules, and finally by automating workflows.

Migrating data to Azure Sentinel

The first time your security operations (SecOps) team logs into Azure Sentinel, they’ll find it pre-loaded with built-in data connectors that make it easy to ingest data from across your organization. Still, it’s in your interest to be selective; migration provides an opportunity to re-evaluate your security needs and leave behind content that’s no longer useful. Think holistically about your use cases, then map the data required to support them. You’ll want to identify any lingering gaps in visibility from your legacy SIEM and determine how to close them.

Most SecOps teams begin by ingesting their cloud data into Azure Sentinel. For an easy first step, Microsoft Azure Activity logs and Microsoft Office 365 audit logs are both free to ingest and give you immediate visibility into Azure and Office 365 activity. You can also ingest alerts from Microsoft Defender products, Azure Security Center, Microsoft Cloud App Security, and Azure Information Protection—all for free.

Many security teams choose to ingest enriched data from security products across the organization while using Azure Sentinel to correlate between them. This eliminates the need to ingest raw logs from the data sources, which can be costly. As you migrate your detections and build out use cases in Azure Sentinel, be sure to verify the value of any data as it relates to your key priorities.

Migrating detection rules

A key task for your migration involves translating existing detection rules to map to Azure Sentinel, which employs Kusto Query Language (KQL) and can be used easily across other Microsoft solutions, such as Microsoft Defender for Endpoint and Microsoft Application Insights.

Azure Sentinel has four built-in rule types:

1. Alert grouping: Reduces alert fatigue by grouping up to 150 alerts within a given timeframe, using three alert grouping options: matching entities, alerts triggered by the scheduled rule, and matches of specific entities.
2. Entity mapping: Enables your SecOps engineers to define entities to be tracked during the investigation. Entity mapping also makes it possible for analysts to take advantage of the intuitive Investigation Graph to reduce time and effort.
3. Evidence summary: Surfaces events, alerts, and bookmarks associated with a particular incident within the preview pane. Entities and tactics also show up in the incident pane—providing a snapshot of essential details and enabling faster triage.
4. KQL: The request is sent to a Log Analytics database and is stated in plain text, using a data-flow model that makes the syntax easy to read, author, and automate. Because several other Microsoft services also store data in Azure Log Analytics or Azure Data Explorer, this reduces the learning curve needed to query or correlate.

Because Azure Sentinel uses machine learning analytics to produce high-fidelity and actionable incidents, it’s likely that some of your existing detections won’t be required anymore.

Remember:

• Don’t migrate all the rules blindly; focus on quality, not quantity.
• Leverage available resources. Review all the Azure Sentinel built-in rules to identify out-of-the-box rules that can quickly address your use cases. Explore community resources such as SOC Prime Threat Detection Marketplace.
• Confirm connected data sources and review your data connection methods. Revisit data collection conversations to ensure data depth and breadth across the use cases you plan to detect.
• Select use cases that justify rule migration in terms of business priority and efficacy:
  • Review rules that haven’t triggered any alerts in the last 6 to 12 months.
  • Eliminate low-level threats or alerts you routinely ignore.
  • Prepare a validation process—define test scenarios and build a test script.

Maximizing automation

Automating workflows can streamline both common and critical tasks by enabling your SecOps team to group alerts into a common incident, then modify its priority. Also, automated playbooks in Azure Sentinel enable easy integration with third-party ticketing solutions, such as ServiceNow.

But automation isn’t just about running tasks in the background. From within the investigation, your team can use an automated playbook to gather additional information or apply remediation action; helping an analyst to accomplish more in less time. You’re also free to iterate and refine over time, moving to full automation for response. Browse the GitHub playbooks to get new ideas and learn about the most common automation flows.

Discontinuing your legacy SIEM

By keeping your highest priorities and defined use cases in sight, you’ll develop a sense for when you’re ready to retire your legacy SIEM and move completely to Azure Sentinel. Based on our experience, customers who feel they’re ready to switch off their old SIEM should first complete this basic checklist:

Technology

• Check critical data: Make sure sources and alerts are available in Azure Sentinel.
• Archive all records: Save critical records of past incidents and cases (raw data optional) to retain institutional history.

Processes

• Playbooks: Update investigation and hunting processes for Azure Sentinel.
• Metrics: Ensure that all key metrics can be obtained completely from Azure Sentinel. Create custom workbooks, or use built-in workbook templates to quickly gain insights as soon as you connect to data sources.
• Cases: Make sure all current cases are transferred to the new system (including required source data).

People

• SOC analysts: Make sure everyone on your team is trained on Azure Sentinel and feels comfortable leaving the legacy SIEM.

Learn more

By moving completely to Azure Sentinel, your organization may see significant savings on infrastructure, licensing, and staff hours, all while benefitting from real-time threat analysis and the easy scalability that comes with operating a cloud-native SIEM.

I hope this three-part series has helped answer some of your questions about the migration process. You can read parts one and two of the series here:

• Part 1: Preparing for your migration from on-premises SIEM to Azure Sentinel
• Part 2: How to manage a side-by-side transition from your traditional SIEM to Azure Sentinel

For a complete overview of the migration journey, as well as links to additional resources, 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.

The post Migrating content from traditional SIEMs to Azure Sentinel appeared first on Microsoft Security Blog.

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:

1. Planning and starting the migration.
2. Running Azure Sentinel side-by-side with your on-premises SIEM (transitional phase).
3. 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.

The post How to manage a side-by-side transition from your traditional SIEM to Azure Sentinel appeared first on Microsoft Security Blog.

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.

The post Preparing for your migration from on-premises SIEM to Azure Sentinel appeared first on Microsoft Security Blog.