Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Важно!
Пользовательские обнаружения теперь — лучший способ создавать новые правила в Microsoft Sentinel SIEM и Microsoft Defender XDR. С настраиваемыми обнаружениями вы можете сократить затраты на прием данных, получить неограниченное количество обнаружений в режиме реального времени и воспользоваться бесшовной интеграцией с данными, функциями и действиями по исправлению в Defender XDR благодаря автоматическому сопоставлению сущностей. Дополнительные сведения см. в статье Пользовательские обнаружения теперь представляют собой единый интерфейс для создания обнаружений в Microsoft Defender XDR.
Хотя Microsoft Sentinel может принимать данные из подключённых источников, время ввода данных для каждого источника может различаться в разных случаях.
В этой статье описывается, как задержка приема может повлиять на запланированные правила аналитики и как их можно исправить, чтобы устранить эти пробелы.
Почему задержка является значительной
Например, можно написать пользовательское правило обнаружения, задав для параметра Выполнять запрос каждый и Данные подстановки из последних полей, чтобы правило выполнялось каждые пять минут, искать данные за последние пять минут:
Поле Данные поиска за последние задаёт параметр, называемый ретроспективным периодом. В идеале, если задержка отсутствует, это обнаружение не пропускает никаких событий, как показано на следующей схеме:
Событие поступает по мере его формирования и включается в период ретроспективного анализа.
Теперь предположим, что для источника данных возникла некоторая задержка. В этом примере предположим, что событие было сгенерировано через две минуты после его создания. Задержка составляет две минуты:
Событие создается в течение первого ретроспективного периода, но не поступает в вашу рабочую область Microsoft Sentinel при первом запуске. При следующем выполнении запланированного запроса он получает событие, но созданный по времени фильтр удаляет событие, так как оно произошло более пяти минут назад. В этом случае правило не запускает оповещение.
Как устранить задержку
Используйте следующий подход для учета задержки приема в правилах запланированной аналитики.
Примечание.
Эту проблему можно решить с помощью описанного ниже процесса или реализовать правила обнаружения почти в реальном времени (NRT) Microsoft Sentinel. Дополнительные сведения см. в статье Быстрое обнаружение угроз с помощью правил аналитики почти в реальном времени (NRT) в Microsoft Sentinel.
Чтобы устранить эту проблему, необходимо знать задержку для типа данных. В этом примере вы уже знаете, что задержка составляет две минуты.
Для собственных данных вы можете оценить задержку с помощью функции Kusto ingestion_time(), вычислив разницу между TimeGenerated и временем приема данных. Дополнительные сведения см. в разделе Вычисление задержки приема.
Определив задержку, вы можете решить проблему следующим образом:
Увеличите период «осмотра»: базовая интуиция подсказывает, что увеличение размера периода «назад» поможет. Так как период оглядки составляет пять минут, а задержка — две минуты, установка периода оглядки на семь минут поможет решить эту проблему. Например, в параметрах правила:
На приведённой ниже схеме показано, что теперь период look-pack включает пропущенное событие:
* Обработка дублирования: Увеличение ретроспективного периода само по себе может привести к дублированию, поскольку ретроспективные окна теперь перекрываются. Например, другое событие может выглядеть так, как показано на следующей схеме:
Поскольку значение события 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)
См. более подробную информацию о следующих элементах, использованных в предыдущем примере, в документации Kusto:
Вычисление задержки приема
По умолчанию правила запланированных оповещений Microsoft Sentinel настроены на пятиминутный период проверки. Однако у каждого источника данных может быть своя индивидуальная задержка поступления. При объединении нескольких типов данных необходимо понимать различные задержки для каждого типа данных, чтобы правильно настроить период оглядки.
Отчет об использовании рабочей области, доступный в Microsoft Sentinel по умолчанию, содержит панель мониторинга, на которой отображаются латентность и задержки для различных типов данных, поступающих в рабочую область.
Например, вы можете:
