Устранение неполадок правил аналитики в Microsoft Sentinel
В этой статье объясняется, как справиться с определенными проблемами, которые могут возникнуть при выполнении правил запланированной аналитики в Microsoft Sentinel.
Проблема. В результатах запроса не отображаются события
Если группирование событий настроено на активацию оповещения для каждого события, результаты запроса при просмотре по прошествии времени могут отсутствовать или отличаться от ожидаемого. Например, вы можете просмотреть результаты запроса позже при расследовании связанного инцидента, и в рамках этого исследования вы решили вернуться к более ранним результатам этого запроса.
Результаты автоматически сохраняются в оповещениях. Однако если результаты слишком большие, результаты не сохраняются и при просмотре результатов запроса не отображаются.
В случаях, когда задержка приема или запрос не детерминирован из-за агрегирования, результат оповещения может отличаться от результата, показанного при выполнении запроса вручную.
Чтобы устранить эту проблему, если правило имеет этот параметр группировки событий, Microsoft Sentinel добавляет поле OriginalQuery в результаты запроса. Ниже приведено сравнение существующего поля запроса и нового поля:
| Имя поля | Содержит | Выполнение запроса в этом поле Возвращаемый результат |
|---|---|---|
| Запрос | Сжатая запись события, создающего этот экземпляр оповещения. | Событие, создающее этот экземпляр оповещения; ограничено 10 килобайтами. |
| OriginalQuery | Исходный запрос, написанный в правиле аналитики. | Последнее событие в интервале времени выполнения запроса, которое соответствует параметрам, определенным запросом. |
Другими словами, поле OriginalQuery ведет себя так, как поле "Запрос" ведет себя под параметром группировки событий по умолчанию.
Ошибка: не удалось выполнить запланированное правило или оно отображается с АВТОМАТИЧЕСКИМ добавлением к имени
Очень редко, но может возникнуть такая ситуация, в которой правило запросов по расписанию не удается применить. Microsoft Sentinel сразу классифицирует все сбои на временные или постоянные, исходя из типа ошибки и обстоятельств, которые привели к нему.
Временный сбой
Временный сбой возникает из-за временных обстоятельств, которые скоро возвращаются в нормальное состояние, в то время как выполнение правила завершается успешно. Ниже приведены некоторые примеры сбоев, которые Microsoft Sentinel может классифицировать как временные.
- Запрос правила выполняется слишком долго и приводит к превышению времени ожидания.
- Проблемы с подключением Log Analytics к источникам данных или Microsoft Sentinel к Log Analytics.
- Также все новые и неизвестные сбои считаются временными.
В случае временного сбоя Microsoft Sentinel повторяет попытку применения правила после заданного интервала, который постепенно увеличивается до определенного предела. После этого правило будет снова применено только в следующее запланированное время. Правило никогда не является автоматически различаемым из-за временной ошибки.
Постоянный сбой — правило автоизменяемо
Постоянный сбой возникает из-за изменения условий, позволяющих запускать правило, которое без вмешательства человека не может вернуться к их бывшему статусу. Ниже приведены некоторые примеры сбоев, которые классифицируются как постоянные.
- Целевая рабочая область (в которой был выполнен запрос правила) была удалена.
- Целевая таблица (в которой был выполнен запрос правила) была удалена.
- Microsoft Sentinel был удален из целевой рабочей области.
- Функция, используемая запросом правила, больше не является допустимой; оно было изменено или удалено.
- Изменены разрешения на один из источников данных запроса правила (см. пример).
- Был удален один из источников данных запроса правила.
Если при определенном числе последовательных запусков одного правила происходят постоянные сбои одного и того же типа, Microsoft Sentinel прекращает попытки выполнить правило и применяет следующие действия:
- Отключает проблемное правило.
- Добавляет слова AUTO DISABLED (автоматически отключено) в начало имени этого правила.
- Добавляет причину сбоя (и отключения) в описание этого правила.
Вы можете легко определить наличие любых правил автоизменяемых, отсортируя список правил по имени. Правила авторазделения находятся в верхней части списка или в верхней части списка.
Руководители SOC должны регулярно проверка список правил для наличия правил автоизменяемых правил.
Постоянный сбой из-за утечки ресурсов
Другой вид постоянного сбоя возникает из-за неправильно созданного запроса , который приводит к тому, что правило потребляет чрезмерные вычислительные ресурсы и риски, связанные с производительностью в ваших системах. Если Microsoft Sentinel идентифицирует такое правило, оно выполняет те же три шага, которые упоминание для других типов постоянных сбоев, отключает правило, отключает имя правила и добавляет причину сбоя в описание.
Чтобы повторно включить правило, необходимо устранить проблемы в запросе, которые вызывают использование слишком большого количества ресурсов. Ознакомьтесь со следующими статьями, чтобы оптимизировать запросы Kusto:
Дополнительные сведения см. в статье "Полезные ресурсы для работы с язык запросов Kusto в Microsoft Sentinel".
Постоянный сбой из-за потери доступа между подписками и клиентами
Один из конкретных примеров, когда может произойти постоянный сбой из-за изменения разрешений в источнике данных (см. список) касается случая поставщика решений безопасности Майкрософт (MSSP) или любого другого сценария, в котором правила аналитики запрашивают запросы между подписками или клиентами.
При создании правила аналитики маркер разрешений доступа применяется к правилу и сохраняется вместе с ним. Этот маркер гарантирует, что правило может получить доступ к рабочей области, содержащей таблицы, на которые ссылается запрос правила, и что этот доступ сохраняется, даже если создатель правила теряет доступ к этой рабочей области.
Однако существует одно исключение: при создании правила для доступа к рабочим областям в других подписках или клиентах, таких как то, что происходит в случае MSSP, Microsoft Sentinel принимает дополнительные меры безопасности, чтобы предотвратить несанкционированный доступ к данным клиента. Эти типы правил имеют учетные данные пользователя, создавшего правило, примененное к ним, вместо независимого маркера доступа. Когда пользователь больше не имеет доступа к другому клиенту, правило перестает работать.
Если вы используете Microsoft Sentinel в сценарии с несколькими подписками или несколькими клиентами, и если один из аналитиков или инженеров теряет доступ к определенной рабочей области, все правила, созданные этим пользователем, перестают работать. Вы получите сообщение мониторинга работоспособности относительно "недостаточного доступа к ресурсу", и правило будет автоматически различаться в соответствии с процедурой, описанной ранее.
Дальнейшие действия
Дополнительные сведения см. в разделе:
- Руководство по исследованию инцидентов с помощью Microsoft Sentinel
- Навигация и исследование инцидентов в Microsoft Sentinel — предварительная версия
- Классификация и анализ данных с помощью сущностей в Microsoft Sentinel
- Руководство. Использование сборников схем с правилами автоматизации в Microsoft Sentinel
Кроме того, изучите пример использования настраиваемых правил аналитики для мониторинга Zoom с применением пользовательского соединителя.