Агрегировать данные Microsoft Sentinel с помощью обзорных правил (режим предварительного просмотра)

Статья
2025-04-03
Применяется к: Microsoft Sentinel in the Microsoft Defender portal, Microsoft Sentinel in the Azure portal

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

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

Доступ к результатам сводных правил через язык запросов Kusto (KQL) для обнаружения, расследования, поиска угроз и составления отчетов. Используйте сводные результаты правила в течение более длительных периодов в исторических исследованиях, охоте и действиях соответствия требованиям.

Результаты выполнения сводных правил хранятся в отдельных таблицах в рамках плана данных Аналитики и оплачиваются соответствующим образом. Дополнительные сведения о планах данных и затратах на хранение см. в статье "Выбор плана таблицы на основе шаблонов использования в рабочей области Log Analytics"

Внимание

Сводные правила в настоящее время находятся в предварительной версии. Дополнительные условия использования для предварительных версий Microsoft Azure см. в дополнительных юридических терминах, применимых к функциям Azure, которые находятся в бета-версии, предварительной версии или в противном случае еще не выпущены в общую доступность.

Microsoft Sentinel общедоступен в единой платформе операций безопасности Майкрософт на портале Microsoft Defender, в том числе для клиентов без XDR Microsoft Defender или лицензии E5. Для получения дополнительной информации см. Microsoft Sentinel в портале Microsoft Defender.

Предварительные условия

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

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

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

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

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

На портале Defender выберите Microsoft Sentinel > Сводка конфигурации > правила (предварительная версия). На портале Azure в меню навигации Microsoft Sentinel, в разделе "Конфигурация", выберите "Сводные правила (предварительная версия)". Например:
Нажмите кнопку +Создать и введите следующие сведения:
- Имя. Введите осмысленное имя правила.
- Описание. При необходимости введите описание.
- Целевая таблица. Определите настраиваемую таблицу журналов, в которой агрегируются данные:
  - Если вы выберете существующую настраиваемую таблицу журналов, выберите ту таблицу, которую хотите использовать.
  - Если выбрать новую настраиваемую таблицу журналов, введите понятное имя таблицы. Полное имя таблицы использует следующий синтаксис: <tableName>_CL
Мы рекомендуем включить параметры диагностики SummaryLogs в вашей рабочей области, чтобы получить видимость для предыдущих процессов и неудач. Если параметры диагностики SummaryLogs не включены, вам будет предложено включить их в области параметров диагностики .

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

Внимание

Параметры диагностики SummaryLogs имеют дополнительные затраты. Дополнительные сведения см. в разделе "Параметры диагностики" в Azure Monitor.
Нажмите кнопку "Далее": задайте логику >сводки для продолжения.
На странице "Задать сводную логику" введите сводный запрос. Например, чтобы извлечь содержимое из Google Cloud Platform, может потребоваться ввести следующее:
```
GCPAuditLogs
| where ServiceName == 'pubsub.googleapis.com'
| summarize count() by Severity
```
Дополнительные сведения см. в примерах сценариев сводных правил и языка запросов Kusto (KQL) в Azure Monitor.
Выберите результаты предварительного просмотра , чтобы показать пример данных, которые вы собираете с настроенным запросом.
В области планирования запросов определите следующие сведения:
- Как часто требуется запустить правило
- Хотите ли вы, чтобы правило выполнялось с какой-либо задержкой, в минутах
- Если вы хотите, чтобы правило начинало действовать
Время, указанное в расписании, основано на timegenerated столбце в ваших данных
Нажмите кнопку "Далее": проверка и создание >>файла "Сохранить ", чтобы завершить сводное правило.

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

Создайте правило аналитики , которое выполняется менее чем за две минуты в сводном наборе данных, быстро проверив определенный диапазон времени, когда вредоносный 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

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

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

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

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

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

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

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

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

Создание правила аналитики в 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

Использование сводных правил с вспомогательными журналами (пример процесса)

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

Настройте настраиваемый соединитель CEF из Logstash:
1. Разверните следующий шаблон ARM в рабочей области Microsoft Sentinel, чтобы создать настраиваемую таблицу с правилами сбора данных (DCR) и конечной точкой сбора данных (DCE):
2. Обратите внимание на следующие сведения из выходных данных шаблона ARM:
  - tenant_id
  - data_collection_endpoint
  - dcr_immutable_id
  - dcr_stream_name
3. Создайте приложение Microsoft Entra и запишите идентификатор клиента и секрет приложения. Дополнительные сведения см. в руководстве по отправке данных в журналы Azure Monitor с помощью API приема журналов (портал Azure).
4. Используйте наш пример скрипта для обновления файла конфигурации Logstash. Обновления настраивают Logstash для отправки журналов CEF в настраиваемую таблицу, созданную шаблоном ARM, преобразуя данные JSON в формат DCR. В этом сценарии обязательно замените значения заполнителей собственными значениями для пользовательской таблицы и созданного ранее приложения Microsoft Entra.
Убедитесь, что данные CEF будут передаваться из Logstash, как ожидалось. Например, в Microsoft Sentinel перейдите на страницу журналов и выполните следующий запрос:
```
CefAux_CL
| take 10
```
Создавайте сводные правила для агрегирования ваших данных CEF. Например:
- Индикатор компрометации (IoC) данных: Поиск конкретных IoC путём выполнения агрегированных сводных запросов для выявления уникальных вхождений, а затем запрос только этих вхождений для ускорения получения результатов. В следующем примере показано, как предоставить уникальный Source Ip канал данных вместе с другими метаданными, которые затем можно использовать для поиска IoC.
```
// Daily Network traffic trend Per Destination IP along with Data transfer stats 
// Frequency - Daily - Maintain 30 day or 60 Day History. 
  Custom_CommonSecurityLog 
  | extend Day = format_datetime(TimeGenerated, "yyyy-MM-dd") 
  | summarize Count= count(), DistinctSourceIps = dcount(SourceIP), NoofBytesTransferred = sum(SentBytes), NoofBytesReceived = sum(ReceivedBytes)  
  by Day,DestinationIp, DeviceVendor 
```
- Запрос сводной базы данных для обнаружения аномалий. Вместо выполнения запросов к большим историческим периодам, таким как 30 или 60 дней, рекомендуется принять данные в пользовательские журналы, а затем только запрашивать сводные базовые данные, например для обнаружения аномалий временных рядов. Например:
```
// Time series data for Firewall traffic logs 
let starttime = 14d; 
let endtime = 1d; 
let timeframe = 1h; 
let TimeSeriesData =  
Custom_CommonSecurityLog 
  | where TimeGenerated between (startofday(ago(starttime))..startofday(ago(endtime))) 
  | where isnotempty(DestinationIP) and isnotempty(SourceIP) 
  | where ipv4_is_private(DestinationIP) == false 
  | project TimeGenerated, SentBytes, DeviceVendor 
  | make-series TotalBytesSent=sum(SentBytes) on TimeGenerated from startofday(ago(starttime)) to startofday(ago(endtime)) step timeframe by DeviceVendor 
```

Дополнительные сведения о следующих элементах, используемых в предыдущих примерах, см. в документации Kusto:

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

Другие ресурсы:

Поделиться через