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

Обработка задержки приема данных в запланированных правилах аналитики

  • Статья

Хотя Microsoft Sentinel может принимать данные из различных источников, время приема для каждого источника данных зависит от обстоятельств.

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

Почему важна задержка

Например, можно написать пользовательское правило обнаружения, настроив поля Выполнение запроса каждые и Данные поиска за последние, чтобы правило выполнялось каждые пять минут, выполняя поиск данных за последние пять минут:

Снимок экрана: мастер правил аналитики — окно создания правила.

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

Схема, показывающая пятиминутное окно ретроспективного просмотра.

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

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

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

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

Как обрабатывать задержку

Примечание.

Вы можете решить проблему с помощью описанного ниже процесса или применить правила обнаружения Microsoft Sentinel практически в реальном времени. Дополнительные сведения см. в разделе Быстрое обнаружение угроз с помощью правил аналитики практически в реальном времени (NRT) в Microsoft Sentinel.

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

Для своих данных вы можете определить задержку с помощью функции Kusto ingestion_time() и вычислить разницу между TimeGenerated (временем создания) и временем приема. Дополнительные сведения см. в разделе Вычисление задержки приема.

После определения задержки можно решить проблему следующим образом:

  • Увеличьте ретроспективные период. Интуиция подсказывает, что следует увеличить ретроспективный период. Так как ваш ретроспективный период составляет пять минут, а задержка — две минуты, можно решить проблему, установив для ретроспективного периода значение семь минут. Например, в параметрах правила:

    Снимок экрана, на котором показано, как задать для окна значение 7 минут.

    На следующей схеме показано, что ретроспективный период теперь включает пропущенное событие:

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

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

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

    Так как значение TimeGenerated события присутствует в обоих ретроспективных периодах, событие запускает два предупреждения. Необходимо найти способ решить проблему дублирования.

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

    Это можно сделать, задав ingestion_time() > ago(5m) вместо исходного правила look-back = 5m. Этот параметр связывает событие с первым ретроспективным периодом. Например:

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

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

    Схема, показывающая, как установка ограничения назад фиксирует событие.

В следующем примере запроса в общих чертах описано решение проблем с задержкой приема:

let ingestion_delay = 2min;
let rule_look_back = 5min;
CommonSecurityLog
| where TimeGenerated >= ago(ingestion_delay + rule_look_back)
| where ingestion_time() > ago(rule_look_back)

Расчет задержки приема

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

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

Например:

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

Дальнейшие действия

Дополнительные сведения см. в разделе: