Агрегировать данные Microsoft Sentinel с помощью правил сводки

Используйте сводные правила в Microsoft Sentinel для агрегирования больших наборов данных в фоновом режиме для более плавной работы с безопасностью на всех уровнях журналов. Сводные данные предварительно компилируются в пользовательских таблицах журналов и обеспечивают быструю производительность запросов, включая запросы, выполняемые на основе данных, производных от уровней журналов с низкими затратами. Сводные правила помогут оптимизировать ваши данные для:

• Анализ и отчеты, особенно с большими наборами данных и диапазонами времени, необходимые для анализа безопасности и инцидентов, ежемесячного или ежегодного бизнес-отчетов и т. д.
• Экономия затрат на подробные журналы, которые можно хранить на необходимый вам срок в более дешёвом уровне журналов, а также отправлять в виде суммированных данных исключительно в таблицу Аналитики для анализа и отчетов.
• Безопасность и конфиденциальность данных путем удаления или скрытия сведений о конфиденциальности в обобщенных общих данных и ограничения доступа к таблицам с необработанными данными.

Microsoft Sentinel сохраняет результаты сводных правил в пользовательских таблицах с планом данных Analytics. Дополнительные сведения о планах данных и расходах на хранение см. в таблицах журналов.

В этой статье объясняется, как создавать сводные правила или развертывать предварительно созданные шаблоны правил сводки в Microsoft Sentinel и приведены примеры распространенных сценариев использования сводных правил.

Important

После 31 марта 2027 г. Microsoft Sentinel больше не будет поддерживаться на портале Azure и будет доступен только на портале Microsoft Defender. Все клиенты, использующие Microsoft Sentinel на портале Azure, будут перенаправлены на портал Defender и будут использовать Microsoft Sentinel только на портале Defender. Начиная с июля 2025 года многие новые клиенты автоматически подключены и перенаправляются на портал Defender.

Если вы по-прежнему используете Microsoft Sentinel на портале Azure, рекомендуется приступить к планированию перехода на портал Defender , чтобы обеспечить плавный переход и воспользоваться всеми преимуществами унифицированных операций безопасности, предлагаемых Microsoft Defender. Дополнительные сведения см. в статье " Время перемещения: выход из эксплуатации портала Azure Microsoft Sentinel" для повышения безопасности.

Prerequisites

Чтобы создать сводные правила в Microsoft Sentinel, выполните следующие действия.

• Microsoft Sentinel должен быть включен как минимум в одной рабочей области и активно обрабатывать журналы.

• Вы должны иметь доступ к Microsoft Sentinel с разрешениями участника Microsoft Sentinel . Дополнительные сведения см. в статье "Роли и разрешения" в Microsoft Sentinel.

• Чтобы создать сводные правила на портале Microsoft Defender, необходимо сначала подключить рабочую область к порталу Defender. Дополнительные сведения см. в разделе "Подключение Microsoft Sentinel" к порталу Microsoft Defender.

Перед созданием правила рекомендуется экспериментировать с запросом сводного правила на странице журналов . Убедитесь, что запрос не достигает или приближается к ограничению запроса, и убедитесь, что запрос создает предполагаемую схему и ожидаемые результаты. Если запрос близок к ограничениям запроса, рассмотрите возможность использования меньшего размера binSize для обработки меньшего числа данных на ячейку. Вы также можете изменить запрос, чтобы вернуть меньше записей или удалить поля с большим объемом.

Создание нового правила сводки

Создайте новое правило сводки для объединения определенного большого набора данных в динамическую таблицу. Настройте частоту правила, чтобы определить частоту обновления агрегированного набора данных из необработанных данных.

1. Откройте мастер создания сводных правил.

   • На портале Defender выберите правила сводки конфигурации > Microsoft Sentinel>.

   • На портале Azure в меню навигации Microsoft Sentinel в разделе Конфигурация выберите Правила сводки. Рассмотрим пример.

     

2. Нажмите кнопку +Создать и введите следующие сведения:

   • Name. Введите осмысленное имя правила.

   • Description. При необходимости введите описание.

   • Целевая таблица. Определите настраиваемую таблицу журналов, в которой агрегируются данные:

     • Если вы выберете существующую настраиваемую таблицу журналов, выберите ту таблицу, которую хотите использовать.

     • Если выбрать новую настраиваемую таблицу журналов, введите понятное имя таблицы. Полное имя таблицы использует следующий синтаксис: <tableName>_CL

3. Рекомендуется включить параметры диагностики SummaryLogs в рабочей области, чтобы получить видимость для предыдущих запусков и сбоев. Если параметры диагностики SummaryLogs не включены, вам будет предложено включить их в области параметров диагностики .

   Если параметры диагностики SummaryLogs уже включены, но вы хотите изменить параметры, выберите "Настроить расширенные параметры диагностики". Когда вы вернетесь на страницу мастера сводных правил , обязательно выберите "Обновить ", чтобы обновить сведения о параметрах.

   Important

   Параметр диагностики SummaryLogs влечет дополнительные затраты. Дополнительные сведения см. в разделе "Параметры диагностики" в Azure Monitor.

4. Нажмите кнопку "Далее": задайте логику >сводки для продолжения.

5. На странице "Задать сводную логику" введите сводный запрос. Например, чтобы суммировать данные из Google Cloud Platform, может потребоваться ввести следующее:

   GCPAuditLogs
   | where ServiceName == 'pubsub.googleapis.com'
   | summarize count() by Severity
   

   Дополнительные сведения см. в примерах сценариев сводных правил и языка запросов Kusto (KQL) в Azure Monitor.

6. Выберите результаты предварительного просмотра , чтобы показать пример данных, которые вы собираете с настроенным запросом.

7. В области планирования запросов определите следующие сведения:

   • Как часто требуется запустить правило
   • Хотите ли вы, чтобы правило выполнялось с какой-либо задержкой, в минутах
   • Если вы хотите, чтобы правило начинало действовать

   Время, указанное в расписании, основано на timegenerated столбце в ваших данных

8. Нажмите кнопку "Далее": проверка и создание >>файла "Сохранить ", чтобы завершить сводное правило.

Существующие правила сводки перечислены на странице "Сводные правила ", где можно просмотреть состояние правила. Для каждого правила выберите меню параметров в конце строки, чтобы выполнить любое из следующих действий:

• Просмотр текущих данных правила на странице журналов, как если бы вы сразу выполняли запрос.
• Просмотр журнала выполнения для выбранного правила
• Отключите или включите правило.
• Изменение конфигурации правила

Чтобы удалить правило, выберите строку правила и нажмите кнопку "Удалить " в верхней части страницы.

Note

Azure Monitor также поддерживает создание сводных правил с помощью API или шаблона Azure Resource Monitor (ARM). Дополнительные сведения см. в разделе "Создание или обновление сводного правила".

Развертывание предварительно настроенных шаблонов правил сводки

Шаблоны сводных правил — это предварительно созданные сводные правила, которые можно развернуть as-is или настроить в соответствии с вашими потребностями.

Чтобы развернуть шаблон сводного правила, выполните приведенные ниже действия.

1. Откройте концентратор контента и отфильтруйте тип контента по правилам сводки , чтобы просмотреть доступные шаблоны правил сводки.

   

2. Выберите шаблон сводного правила.

   Откроется панель со сведениями о шаблоне сводного правила, отображая такие поля, как описание, сводный запрос и целевая таблица.

   

3. Выберите "Установить", чтобы установить шаблон.

4. Перейдите на вкладку "Шаблоны " на странице "Сводные правила " и выберите установленное правило сводки.

   

5. Выберите "Создать" , чтобы открыть мастер сводных правил, где все поля предварительно заполнены.

6. Перейдите к мастеру сводного правила и нажмите Сохранить, чтобы применить сводное правило.

   Дополнительные сведения о мастере сводных правил см. в разделе "Создание нового сводного правила".

Примеры сценариев сводного правила в Microsoft Sentinel

В этом разделе рассматриваются распространенные сценарии создания правил сводки в Microsoft Sentinel и рекомендации по настройке каждого правила. Дополнительные сведения и примеры см. в статье "Сводка сведений из необработанных данных на вспомогательной таблице в таблицу аналитики в Microsoft Sentinel" и "Источники журналов для использования при приеме вспомогательных журналов".

Быстро найти вредоносный IP-адрес в сетевом трафике

Сценарий: вы охотник за угрозами, и одна из целей вашей команды заключается в выявлении всех случаев, когда вредоносный IP-адрес взаимодействовал в журналах сетевого трафика во время активного инцидента в течение последних 90 дней.

Проблема: Microsoft Sentinel в настоящее время принимает несколько терабайтов сетевых журналов в день. Вам нужно быстро просматривать их, чтобы найти соответствия для вредоносного IP-адреса.

Решение. Для выполнения следующих действий рекомендуется использовать правила сводки.

1. Создайте сводный набор данных для каждого IP-адреса, связанного с инцидентом, включая SourceIP, DestinationIP, MaliciousIP, и RemoteIP, каждый из которых перечисляет важные атрибуты, такие как IPType, FirstTimeSeen и LastTimeSeen.

   Сводный набор данных позволяет быстро искать определенный IP-адрес и сузить диапазон времени, в котором найден IP-адрес. Это можно сделать, даже если поисковые события произошли более 90 дней назад, что выходит за пределы срока хранения их рабочей области.

   В этом примере настройте сводку для ежедневного выполнения, чтобы запрос каждый день добавлял новые сводные записи до истечения срока действия.

2. Создайте правило аналитики , которое выполняется менее чем за две минуты в сводном наборе данных, быстро проверив определенный диапазон времени, когда вредоносный IP-адрес взаимодействует с корпоративной сетью.

   Не забудьте настроить интервалы запуска как минимум до пяти минут, чтобы обработать сводные данные разного объема. Это гарантирует отсутствие потерь даже при задержке обработки событий.

   Рассмотрим пример.

   let csl_columnmatch=(column_name: string) {
   summarized_CommonSecurityLog
   | where isnotempty(column_name)
   | extend
       Date = format_datetime(TimeGenerated, "yyyy-MM-dd"),
       IPaddress = column_ifexists(column_name, ""),
       FieldName = column_name
   | extend IPType = iff(ipv4_is_private(IPaddress) == true, "Private", "Public")
   | where isnotempty(IPaddress)
   | project Date, TimeGenerated, IPaddress, FieldName, IPType, DeviceVendor
   | summarize count(), FirstTimeSeen = min(TimeGenerated), LastTimeSeen = min(TimeGenerated) by Date, IPaddress, FieldName, IPType, DeviceVendor
   };
   union csl_columnmatch("SourceIP")
       , csl_columnmatch("DestinationIP") 
       , csl_columnmatch("MaliciousIP")
       , csl_columnmatch("RemoteIP")
   // Further summarization can be done per IPaddress to remove duplicates per day on larger timeframe for the first run
   | summarize make_set(FieldName), make_set(DeviceVendor) by IPType, IPaddress
   

3. Выполните последующий поиск или корреляцию с другими данными , чтобы завершить историю атаки.

Создание оповещений о совпадениях аналитики угроз с сетевыми данными

Создание оповещений о совпадениях аналитики угроз с шумными, большими объемами и данными сети с низким уровнем безопасности.

Сценарий: Необходимо создать правило аналитики для журналов брандмауэра, чтобы сопоставить доменные имена в системе, которые были посещены, с перечнем доменных имен угрожающей аналитики.

Большинство источников данных — это необработанные журналы, которые являются шумными и имеют большой объем, но имеют меньшую ценность для безопасности, включая IP-адреса, трафик брандмауэра Azure, трафик Fortigate и т. д. Общий объём составляет около 1 ТБ в день.

Проблема. Создание отдельных правил требует нескольких приложений логики, требующих дополнительных затрат на настройку и обслуживание.

Решение. Для выполнения следующих действий рекомендуется использовать правила сводки.

1. Создайте сводное правило:

   1. Расширьте запрос, чтобы извлечь ключевые поля, такие как исходный адрес, адрес назначения и порт назначения из таблицы CommonSecurityLog_CL, которая представляет собой CommonSecurityLog с включённым вспомогательным планом.

   2. Выполните внутренний поиск по активным индикаторам аналитики угроз, чтобы определить совпадения с нашим исходным адресом. Это позволяет сопоставлять ваши данные с известными угрозами.

   3. Соответствующие сведения о проекте, включая время создания, тип действия и все ip-адреса вредоносных источников, а также сведения о назначении. Задайте частоту выполнения запроса и целевую таблицу, например MaliciousIPDetection . Результаты в этой таблице находятся на уровне аналитики и оплачиваются соответствующим образом.

2. Создайте оповещение:

   Создание правила аналитики в Microsoft Sentinel, которое оповещает на основе результатов из таблицы MaliciousIPDetection . Этот шаг имеет решающее значение для упреждающего обнаружения угроз и реагирования на инциденты.

Пример сводного правила:

CommonSecurityLog_CL​
| extend sourceAddress = tostring(parse_json(Message).sourceAddress), destinationAddress = tostring(parse_json(Message).destinationAddress), destinationPort = tostring(parse_json(Message).destinationPort)​
| lookup kind=inner (ThreatIntelligenceIndicator | where Active == true ) on $left.sourceAddress == $right.NetworkIP​
| project TimeGenerated, Activity, Message, DeviceVendor, DeviceProduct, sourceMaliciousIP =sourceAddress, destinationAddress, destinationPort

Связанный контент

• Агрегирование данных в рабочей области Log Analytics с использованием правил суммирования
• Планирование затрат и знакомство с ценами и выставлением счетов Microsoft Sentinel
• Источники журналов для использования при интеграции вспомогательных журналов
• Сводные правила: ограничения и лимиты