{"id":42396,"date":"2021-08-18T16:00:46","date_gmt":"2021-08-18T16:00:46","guid":{"rendered":"https:\/\/www.microsoft.com\/security\/blog\/?p=95700"},"modified":"2021-08-18T16:00:46","modified_gmt":"2021-08-18T16:00:46","slug":"migrating-content-from-traditional-siems-to-azure-sentinel","status":"publish","type":"post","link":"https:\/\/www.threatshub.org\/blog\/migrating-content-from-traditional-siems-to-azure-sentinel\/","title":{"rendered":"Migrating content from traditional SIEMs to Azure Sentinel"},"content":{"rendered":"
<\/div>\n
\n

In part two of this three-part series, we covered the five types of side-by-side security information and event management (SIEM) configurations<\/a> commonly used during a long-term migration to Microsoft Azure Sentinel<\/a>. For part three, we\u2019ll 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\u2019s powerful automation capabilities to streamline common tasks.<\/p>\n

The information presented here is derived from experiences we\u2019ve accumulated while assisting numerous customer migrations, as well as experiences gained by Microsoft\u2019s 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.<\/p>\n

Migrating data to Azure Sentinel<\/h2>\n

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

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

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.<\/p>\n

Migrating detection rules<\/h2>\n

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

Azure Sentinel has four built-in rule types:<\/h3>\n
    \n
  1. Alert grouping:<\/strong> Reduces alert fatigue by grouping up to 150 alerts within a given timeframe, using three alert grouping<\/a> options: matching entities, alerts triggered by the scheduled rule, and matches of specific entities.<\/li>\n
  2. Entity mapping:<\/strong> Enables your SecOps engineers to define entities to be tracked during the investigation. Entity mapping<\/a> also makes it possible for analysts to take advantage of the intuitive Investigation Graph<\/a> to reduce time and effort.<\/li>\n
  3. Evidence summary:<\/strong> Surfaces events, alerts, and bookmarks associated with a particular incident within the preview pane. Entities and tactics also show up in the incident pane\u2014providing a snapshot of essential details and enabling faster triage.<\/li>\n
  4. KQL:<\/strong> 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<\/a> or Azure Data Explorer<\/a>, this reduces the learning curve needed to query or correlate.<\/li>\n<\/ol>\n

    Because Azure Sentinel uses machine learning analytics to produce high-fidelity and actionable incidents, it\u2019s likely that some of your existing detections won\u2019t be required anymore.<\/p>\n

    Remember:<\/h3>\n