Устранение неполадок с правилами аналитики в Microsoft Sentinel

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

Проблема: события не отображаются в результатах запроса

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

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

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

Чтобы решить эту проблему, когда для правила задан этот параметр группировки событий, Microsoft Sentinel добавляет поле OriginalQuery к результатам запроса. Ниже приведено сравнение существующего поля запроса и нового поля:

Иными словами, поле OriginalQuery ведет себя так же, как поле Запроса при настройке группирования событий по умолчанию.

Проблема: запланированное правило не было выполнено или отображается с добавлением AUTO DISABLED к имени

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

Временный сбой

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

• Выполнение запроса правила занимает слишком много времени, и время ожидания истекает.
• Проблемы с подключением между источниками данных и Log Analytics или между Log Analytics и Microsoft Sentinel.
• Любой другой новый и неизвестный сбой считается временным.

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

Постоянный сбой — правило автоматически отключено

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

• Целевая рабочая область (в которой выполнялся запрос к правилу) была удалена.
• Целевая таблица (в которой работал запрос правила) была удалена.
• Microsoft Sentinel была удалена из целевой рабочей области.
• Функция, используемая запросом правила, больше не действительна; она была изменена или удалена.
• Разрешения на один из источников данных запроса правила были изменены (см. пример).
• Один из источников данных запроса правила был удален.

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

1. Отключает правило.
2. Добавляет слова "AUTO DISABLED" в начало имени правила.
3. Добавляет причину сбоя (и отключение) в описание правила.

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

Руководители SOC должны регулярно проверять список правил на наличие автоматически отключенных правил.

Постоянный сбой из-за нехватки ресурсов

Другой вид постоянного сбоя возникает из-за неправильно построенного запроса, из-за которого правило потребляет чрезмерные вычислительные ресурсы и может отрицательно сказаться на производительности ваших систем. Когда Microsoft Sentinel определяет такое правило, он выполняет те же три действия, что и для других типов постоянных сбоев: отключает правило, добавляет "AUTO DISABLED" к имени правила и добавляет причину сбоя в описание.

Чтобы повторно включить правило, необходимо устранить проблемы в запросе, из-за чего оно использует слишком много ресурсов. Дополнительные сведения см. в разделе:

• Рекомендации по использованию запросов: документация по Kusto
• Оптимизация запросов журналов в мониторе Azure
• Учебные материалы по языку запросов Kusto Query Language

Неустранимая ошибка из-за потери доступа к подпискам и клиентам

Один из конкретных примеров, когда может произойти постоянный сбой из-за изменения разрешений на источник данных (см. список) относится к ситуации поставщика решений безопасности Майкрософт (MSSP) или любому другому сценарию, в котором правила аналитики запрашивают между подписками или клиентами.

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

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

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

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

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

• Руководство. Исследование инцидентов с помощью Microsoft Sentinel
• Навигация и исследование инцидентов в Microsoft Sentinel — предварительная версия
• Классификация и анализ данных с помощью сущностей в Microsoft Sentinel
• Руководство. Использование сборников схем с правилами автоматизации в Microsoft Sentinel

Кроме того, ознакомьтесь с примером использования настраиваемых правил аналитики при мониторинге Zoom с помощью настраиваемого соединителя.