In part two of this three-part series, we covered the [five types of side-by-side security information and event management (SIEM) configurations]() commonly used during a long-term migration to [Microsoft Azure Sentinel](). For part three, we’ll be looking at best practices for migrating your data and detections while operating side-by-side with your on-premises SIEM, as well as ways to maximize Azure Sentinel’s powerful automation capabilities to streamline common tasks. 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]().