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

Постоянный сбой из-за потери доступа между подписками и арендаторами

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

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

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

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

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

Дополнительные сведения см. в указанных ниже статьях.

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

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