Правила запланированной аналитики в Microsoft Sentinel

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

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

• Создайте правило аналитики из шаблона: используйте логику запроса и параметры планирования и обратного просмотра, как определено в шаблоне, или настройте их для создания новых правил.

• Создайте правило аналитики с нуля: создайте собственный запрос и правило с нуля. Для этого необходимо тщательно приземлиться в обработке и анализе данных и языке запросов Kusto.

Шаблоны правил аналитики

Запросы в запланированных шаблонах правил были написаны экспертами по безопасности и обработке и анализу данных, либо от корпорации Майкрософт, либо от поставщика решения, предоставляющего шаблон.

Используйте шаблон правила аналитики, выбрав имя шаблона из списка шаблонов и создав правило на его основе.

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

При создании правила из шаблона мастер создания правил открывается на основе выбранного шаблона. Все сведения заполняются автоматически, и вы можете настроить логику и другие параметры правила, чтобы лучше соответствовать вашим потребностям. Этот процесс можно повторить, чтобы создать дополнительные правила на основе шаблона. Когда вы достигнете конца мастера создания правила, ваши настройки проверяются и создаются правила. Новые правила отображаются на вкладке "Активные правила" на странице "Аналитика ". Аналогичным образом на вкладке "Шаблоны правил " шаблон, из которого вы создали правило, теперь отображается тег In use .

Шаблоны правил аналитики постоянно поддерживаются своими авторами либо для исправления ошибок, либо для уточнения запроса. Когда шаблон получает обновление, все правила, основанные на этом шаблоне, отображаются с Update тегом, и у вас есть возможность изменить эти правила, чтобы включить изменения, внесенные в шаблон. Вы также можете вернуть любые изменения, внесенные в правило, обратно в исходную версию на основе шаблона. Дополнительные сведения см. в разделе "Управление версиями шаблонов" для правил запланированной аналитики в Microsoft Sentinel.

После ознакомления с параметрами конфигурации в этой статье см. статью "Создание правил запланированной аналитики" из шаблонов.

В остальной части этой статьи описываются все возможности настройки конфигурации правил.

Настройка правила аналитики

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

Имя и сведения о правиле аналитики

Первая страница мастера правил аналитики содержит основные сведения о правиле.

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

Описание: Описание цели правила в свободном тексте.

ИДЕНТИФИКАТОР: GUID правила в качестве ресурса Azure, используемого в запросах и ответах API, помимо прочего. Этот GUID назначается только при создании правила, поэтому он отображается только при редактировании существующего правила. Так как это поле только для чтения, оно отображается как серый и не может быть изменено. Он еще не существует при создании нового правила либо из шаблона, либо с нуля.

Суровость: Оценка для предоставления оповещений, созданных этим правилом. Серьезность действия — это вычисление потенциального негативного влияния от его происхождения.

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

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

MITRE ATT&CK: Спецификация тактики и техник атаки, представленных в виде действий, зафиксированных этим правилом. Они основаны на тактике и методах платформы MITRE ATT&CK®.

Тактика и методы MITRE ATT&CK, определенные здесь в правиле, применяются к любым оповещениям, созданным правилом. Они также применяются к любым инцидентам, созданным из этих оповещений.

Дополнительные сведения о максимизации охвата ландшафта угроз MITRE ATT&CK см. в статье "Общие сведения о охвате безопасности платформой MITRE ATT&CK®".

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

• Выберите «Отключено», и правило будет создано без запуска. Если вы хотите запустить правило, найдите его на вкладке "Активные правила " и включите его.
• Запланируйте, чтобы правило сначала выполнялось в определенной дате и времени. Этот метод в настоящее время находится в предварительной версии. См. сведения о планировании запросов далее в этой статье.

Запрос правила

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

Просмотр или ввод запроса Kusto, который анализирует необработанные данные журнала. Если вы создаете правило с нуля, рекомендуется спланировать и разработать запрос перед открытием этого мастера. Вы можете создавать и тестировать запросы на странице логов.

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

Лучшие практики для запросов правил аналитики

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

• Длина запроса должна составлять от 1 до 10 000 символов и не может содержать "search *" или "union *". Вы можете использовать определяемые пользователем функции для преодоления ограничения длины запроса, так как одна функция может заменить десятки строк кода.

• Использование функций ADX для создания запросов Azure Data Explorer в окне запросов Log Analytics не поддерживается.

• При использовании функции bag_unpack в запросе, если вы проецируете столбцы в поля, используя "," и столбец не существует, запрос завершится ошибкой. Чтобы защититься от этого, необходимо проецировать столбец следующим образом:

  project field1 = column_ifexists("field1","")

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

• Язык запросов Kusto в Microsoft Sentinel
• Краткое руководство по KQL
• Рекомендации по запросам языка запросов Kusto

Усовершенствование оповещений

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

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

Вы можете настроить три типа улучшений генерации оповещений.

• Сопоставление сущностей
• Настраиваемые сведения
• Сведения об оповещении (также называется динамическим содержимым)

Сопоставление сущностей

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

Дополнительные сведения о сопоставлении сущностей и получении полных инструкций см. в статье "Сопоставление полей данных с сущностями в Microsoft Sentinel".

Настраиваемые сведения

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

Дополнительные сведения о отображении пользовательских сведений и получении полных инструкций см. в разделе " Сведения о пользовательском событии Surface" в оповещениях в Microsoft Sentinel.

Сведения об оповещении

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

Дополнительные сведения о настройке оповещений и получении полных инструкций см. в статье "Настройка сведений об оповещении" в Microsoft Sentinel.

Планирование запросов

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

• Допустимый диапазон для обоих этих параметров составляет от 5 минут до 14 дней.

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

Параметр "Запуск" , теперь в режиме предварительной версии, позволяет создать правило с включенным состоянием, но отложить его первое выполнение до предопределенной даты и времени. Этот параметр полезен, если требуется время выполнения правил в соответствии с тем, когда ожидается прием данных из источника, или когда аналитики SOC начинают свой рабочий день.

• Время запуска должно быть от 10 минут до 30 дней после создания правила (или включения).

• Строка текста в параметрах Начало выполнения (со значком информации слева) суммирует текущие параметры планирования запросов и обратного анализа.

  

Порог оповещения

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

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

Пороговое значение также может быть задано как максимальное число результатов или точное число.

Группирование событий

Существует два способа обработки группировки событий в оповещения:

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

• Активируйте оповещение для каждого события: Правило создает уникальное оповещение для каждого события (результата), возвращаемого запросом. Этот режим полезен, если вы хотите, чтобы события отображались по отдельности, или если вы хотите сгруппировать их по определенным параметрам — по имени пользователя, имени узла или другому. Такие параметры можно определить в запросе.

Правила аналитики могут создавать до 150 оповещений. Если для каждого события задано группирование событий, а запрос правила возвращает более 150 событий, первые 149 событий будут создавать уникальное оповещение (для 149 оповещений), а 150-е оповещение обобщает весь набор возвращаемых событий. Другими словами, 150-е оповещение — это то, что было бы создано, если группирование событий было установлено для группировки всех событий в одно оповещение.

Раздел запроса оповещения отличается в каждом из этих двух режимов. В режиме объединения всех событий в одно оповещение оповещение возвращает запрос, позволяющий просматривать все события, активирующие оповещение. Вы можете детализировать результаты запроса, чтобы просмотреть отдельные события. В режиме триггера оповещения для каждого события оповещение возвращает результат, закодированный в Base64, в области запроса. Скопируйте и запустите эти выходные данные в Log Analytics, чтобы декодировать base64 и показать исходное событие.

Триггер оповещения для каждого параметра события может вызвать проблему, из-за которой результаты запроса, как представляется, отсутствуют или отличаются от ожидаемых. Дополнительные сведения об этом сценарии см. в разделе "Устранение неполадок с правилами аналитики" в Microsoft Sentinel | Проблема. События не отображаются в результатах запроса.

Подавление

Если вы хотите, чтобы это правило прекратило выполнение на определенный период времени после создания оповещения, включите параметр "Остановить выполнение запроса после создания оповещения" Вкл.. Затем необходимо задать параметр "Остановить выполнение запроса" на количество времени, в течение которого запрос должен быть остановлен, до 24 часов.

Имитация результатов

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

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

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

Параметры инцидента

Выберите, преобразует ли Microsoft Sentinel оповещения в практические инциденты.

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

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

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

Группирование оповещений

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

Инцидент создается только после создания всех оповещений. Все оповещения добавляются в инцидент сразу после его создания.

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

Чтобы группировать оповещения вместе, задайте для параметра группирования оповещений значение "Включено".

При группировке оповещений можно учитывать несколько вариантов.

• Интервал времени: По умолчанию оповещения, которые создаются в течение 5 часов после первого оповещения в инциденте, добавляются в тот же инцидент. Через 5 часов создается новый инцидент. Этот период времени можно изменить в любом месте от 5 минут до семи дней.

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

  Вариант	Описание
  Сгруппировать оповещения в один инцидент, если все сущности совпадают	Оповещения группируются вместе, если у них одинаковые значения для каждой из сопоставленных сущностей, определённых ранее. Это рекомендуемый параметр.
  Группируйте все оповещения, активированные этим правилом, в один инцидент	Будут объединяться все оповещения, созданные этим правилом, даже если у них нет совпадающих значений.
  Группируйте оповещения в один инцидент, если выбранные объекты и детали совпадают	Оповещения группируются вместе, если они совместно используют одинаковые значения для всех сопоставленных сущностей, сведений об оповещении и настраиваемых сведений , которые вы выбираете для этого параметра. Выберите сущности и сведения из раскрывающихся списков, которые отображаются при выборе этого параметра. Этот вариант вы можете использовать, если хотите создавать отдельные инциденты в зависимости от IP-адресов источника и назначения или группировать оповещения по определенным сущностям и уровням серьезности. Примечание. При выборе этого параметра необходимо выбрать по крайней мере одну сущность или подробные сведения для правила. В противном случае проверка правила завершается ошибкой, и правило не создается.

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

  Возможность повторного открытия закрытых инцидентов недоступна при подключении Microsoft Sentinel к порталу Defender.

Автоматический ответ

Microsoft Sentinel позволяет настроить автоматические ответы, возникающие при следующем:

• Оповещение создается этим правилом аналитики.
• Инцидент создается из оповещений, созданных этим правилом аналитики.
• Инцидент обновляется с помощью оповещений, созданных этим правилом аналитики.

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

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

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

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

• Дополнительные сведения и инструкции по созданию сборников схем и правил автоматизации см. в статье "Автоматизация ответов на угрозы".

• Дополнительные сведения об использовании триггера создания инцидента, триггера обновления инцидента или триггера создания оповещения см. в статье "Использование триггеров и действий в плейбуках Microsoft Sentinel".

• В разделе Автоматизация оповещений (классическая) может появиться список плейбуков, настроенных для автоматического запуска с использованием устаревшего метода, который будет прекращен в марте 2026 года. Вы не можете добавить ничего в этот список. Все сценарии действий, перечисленные здесь, должны иметь правила автоматизации, созданные на основе триггера создающего оповещение для их вызова. После этого выберите многоточие в конце строки сборника схем, перечисленных здесь, и нажмите кнопку "Удалить". Полные инструкции см. в разделе Перенос ваших playbook Microsoft Sentinel для запуска оповещений в правила автоматизации.

Следующие шаги

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

Чтобы автоматизировать включение правил, отправьте правила в Microsoft Sentinel через API и PowerShell, несмотря на то, что это требует больше усилий. При использовании API или PowerShell необходимо сначала экспортировать правила в формат JSON и лишь затем включать их. API или PowerShell могут помочь при включении правил в нескольких экземплярах Microsoft Sentinel с одинаковыми параметрами в каждом экземпляре.

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

• Экспорт и импорт правил аналитики в шаблоны ARM и из них
• Устранение неполадок правил аналитики в Microsoft Sentinel
• Навигация и исследование инцидентов в Microsoft Sentinel
• Сущности в Microsoft Sentinel
• Руководство. Использование сборников схем с правилами автоматизации в Microsoft Sentinel

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