Правила аналитики по расписанию в Microsoft Sentinel

Применяется к: Microsoft Sentinel in the Microsoft Defender portal, Microsoft Sentinel in the Azure portal

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

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

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

Важно!

После 31 марта 2027 г. Microsoft Sentinel больше не будут поддерживаться в портал Azure и будут доступны только на портале Microsoft Defender. Все клиенты, использующие Microsoft Sentinel в портал Azure, будут перенаправлены на портал Defender и будут использовать Microsoft Sentinel только на портале Defender.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Описание: Свободное текстовое описание назначения правила.

ID: GUID правила как Azure ресурса, используемого, среди прочего, в запросах и ответах API. Этот GUID назначается только при создании правила, поэтому он отображается только при редактировании существующего правила. Так как это поле доступно только для чтения, оно отображается серым цветом и не может быть изменено. Он еще не существует при создании нового правила из шаблона или с нуля.

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

Severity	Описание
Информационный	Не влияет на систему, но информация может указывать на будущие шаги, запланированные субъектом угроз.
Низкая	Непосредственное воздействие будет минимальным. Субъекту угрозы, скорее всего, потребуется выполнить несколько действий, прежде чем достичь влияния на среду.
Средний	Субъект угрозы может оказать некоторое влияние на среду с этим действием, но он будет ограничен в область или потребует дополнительных действий.
Высокий	Определяемое действие предоставляет субъекту угрозы широкий доступ для выполнения действий в среде или активируется воздействием на среду.

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

Определения серьезности для шаблонов правил аналитики 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", а столбец не существует, запрос завершается ошибкой. Чтобы защититься от этого, необходимо проецировать столбец следующим образом:

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

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

Улучшение оповещений

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

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

Существует три типа улучшений оповещений, которые можно настроить:

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

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

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

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

Пользовательские сведения

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

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

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

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

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

Примечание.

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

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

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

Setting	Поведение
Выполнение запроса каждый	Определяет интервал запроса: частоту выполнения запроса.
Данные подстановки из последнего	Определяет период обратного просмотра: период времени, охватываемый запросом.

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

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

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

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

Примечание.

Задержка приема

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

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

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

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

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

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

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

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

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

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

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

Одно оповещение
Оповещение для каждого события

Снимок экрана: примеры результатов для режима единого оповещения с запросом.

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

Подавления

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

Моделирование результатов

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

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

Снимок экрана: симуляция результатов.

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

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

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

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

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

Важно!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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