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

Статья
01/01/2025
Применяется к:

Microsoft Sentinel in the Azure portal, Microsoft Sentinel in the Microsoft Defender portal

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

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

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

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

Внимание

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

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

Необходимые компоненты

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

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

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

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

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

В портал Azure в меню навигации Microsoft Sentinel в разделе "Конфигурация" выберите "Сводка" (предварительная версия). На портале Defender выберите правила сводки конфигурации > 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-адреса, связанного с инцидентом, включая DestinationIPSourceIPMaliciousIP, , , 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): охота на определенные ioCs путем выполнения агрегированных сводных запросов, чтобы привести уникальные вхождения, а затем запрашивать только эти вхождения для ускорения результатов. В следующем примере показано, как принести уникальный 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), NoofByesTransferred = 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).

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

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

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

Необходимые компоненты

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

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

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

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

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

Обратная связь

Дополнительные ресурсы

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

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

Необходимые компоненты

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

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

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

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

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

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

Обратная связь

Дополнительные ресурсы