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

• Применяется к:

  Microsoft Sentinel in the Azure portal, Microsoft Sentinel in the Microsoft Defender portal

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

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

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

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

Внимание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рекомендации по запросам правил аналитики

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

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

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

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

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

Дополнительные сведения о создании запросов Kusto см. в язык запросов Kusto в Microsoft Sentinel и рекомендации по язык запросов Kusto запросам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

  

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

Подавление

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

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

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

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

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

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

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

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

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

Внимание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• В заголовке автоматизации оповещений (классическая модель) может появиться список сборников схем, настроенных для автоматического запуска с помощью старого метода из-за нерекомендуемого в марте 2026 года. Вы не можете добавить ничего в этот список. Все сборники схем, перечисленные здесь, должны иметь правила автоматизации, созданные на основе созданного оповещения триггера, для вызова сборников схем. После этого выберите многоточие в конце строки сборника схем, перечисленных здесь, и нажмите кнопку "Удалить". Полные инструкции см . в сборниках схем оповещений 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 с применением пользовательского соединителя.