Автоматизация реагирования на угрозы в Microsoft Sentinel с помощью правил автоматизации

В этой статье объясняется, что такое правила автоматизации Microsoft Sentinel и как их использовать для реализации операций оркестрации безопасности, автоматизации и реагирования (SOAR). Правила автоматизации повышают эффективность SOC и экономят время и ресурсы.

Что такое правила автоматизации?

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

Правила автоматизации применяются к следующим категориям вариантов использования:

• Выполнение базовых задач автоматизации для обработки инцидентов без использования сборников схем. Например, вы можете:

  • Добавьте задачи по инцидентам для аналитиков.
  • Подавление шумных инцидентов.
  • Рассмотрите новые инциденты, изменив их состояние с New на Active и назначив владельца.
  • Пометка инцидентов для их классификации.
  • Эскалация инцидента путем назначения нового владельца.
  • Закройте разрешенные инциденты, указав причину и добавив примечания.

• Автоматизация ответов для нескольких правил аналитики одновременно.

• Управление порядком выполняемых действий.

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

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

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

Компоненты

Правила автоматизации состоят из нескольких компонентов:

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

Триггеры

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

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

Автоматизация на основе инцидентов или оповещений?

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

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

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

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

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

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

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

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

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

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

Условия

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

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

Триггер создания инцидента

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

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

Например, если вы определяете имя правила аналитики как Contains == Атака методом подбора на облачный компьютер, аналитическое правило с атакой методом подбора на портал Azure не соответствует условию. Однако если вы определяете имя правила аналитики как Не содержит учетные данные пользователя == Учетные данные пользователя, то условию соответствуют как атака методом подбора на облачный компьютер, так и метод подбора портал Azure правил аналитики.

Триггер обновления инцидента

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

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

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

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

Значение свойства инцидента —

• изменено (независимо от фактического значения до или после).
• изменено со значения, определенного в условии.
• изменено на значение, определенное в условии.
• добавлено в (это относится к свойствам со списком значений).

Свойство тега : отдельный объект или коллекция

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

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

Это различие имеет значение, когда ваше условие является отрицательным (не содержит), а некоторые теги в коллекции удовлетворяют условию, а другие нет.

Давайте рассмотрим пример, когда условие — тег не содержит "2024", и у вас есть два инцидента, каждый из которых имеет два тега:

В этом примере в инциденте 1:

• Если условие проверяет каждый тег по отдельности, то, так как существует по крайней мере один тег, удовлетворяющий условию (который не содержит "2024"), общее условие будет true.
• Если условие проверяет все теги в инциденте как единое целое, то, так как существует по крайней мере один тег, который не соответствует условию(который содержит "2024"), общее условие равно false.

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

Поддерживаемые свойства сущности

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

Триггер создания оповещений

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

Действия

Действия можно определить для выполнения при выполнении условий (см. выше). В правиле можно определить множество действий и выбрать порядок их выполнения (см. ниже). Следующие действия можно определить с помощью правил автоматизации без дополнительных функциональных возможностей сборника схем.

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

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

  • При изменении на "closed" укажите причину закрытия и добавление комментария. Это помогает отслеживать производительность и эффективность и точно настроить для снижения ложноположительных результатов.

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

• Назначение инцидента владельцу. Это помогает направлять типы инцидентов персоналу, наиболее подходящему для их работы, или персоналу, наиболее доступному.

• Добавление тега в инцидент. Это полезно для классификации инцидентов по субъектам, злоумышленникам или любому другому общему знаменателю.

Кроме того, можно определить действие для запуска сборника схем, чтобы выполнять более сложные действия реагирования, включая любые действия, связанные с внешними системами. Сборники схем, доступные для использования в правиле автоматизации, зависят от триггера , на котором основаны сборники схем и правило автоматизации: из правил автоматизации триггера инцидентов можно запускать только сборники схем триггера инцидента, а из правил автоматизации триггеров оповещений — только сборники схем триггеров оповещений. Можно определить несколько действий, вызывающих сборники схем, или сочетания сборников схем и других действий. Действия выполняются в том порядке, в котором они перечислены в правиле.

Сборники схем, использующие любой из версий Azure Logic Apps (Standard или Consumption), доступны для запуска из правил автоматизации.

Дата окончания срока действия

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

Порядок

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

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

Порядок правил автоматизации, добавляющих задачи инцидентов , определяет порядок, в котором задачи отображаются в данном инциденте.

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

Примечания о порядке выполнения и приоритете

• Установка номера заказа в правилах автоматизации определяет порядок их выполнения.
• Каждый тип триггера поддерживает собственную очередь.
• Для правил, созданных в портал Azure, поле заказа автоматически заполняется номером после наибольшего числа, используемого существующими правилами того же типа триггера.
• Однако для правил, созданных другими способами (командная строка, API и т. д.), номер заказа необходимо назначить вручную.
• Не существует механизма проверки, который бы не позволял нескольким правилам иметь один и тот же номер заказа, даже в пределах одного типа триггера.
• Вы можете разрешить двум или более правилам одного типа триггера иметь одинаковый номер заказа, если вам не важно, в каком порядке они выполняются.
• Для правил одного типа триггера с одинаковым порядковым номером подсистема выполнения случайным образом выбирает, какие правила выполняются в каком порядке.
• Для правил разных типов триггеров инцидентов сначала выполняются все применимые правила с типом триггера создания инцидента (в соответствии с номерами заказов), а затем правила с типом триггера инцидента обновляются(в соответствии с номерами заказа).
• Правила всегда выполняются последовательно, никогда не параллельно.

Распространенные варианты использования и сценарии

Задачи инцидента

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

Автоматизация инцидентов и оповещений

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

Триггер сборников схем для поставщиков Майкрософт

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

К оповещениям системы безопасности Майкрософт относятся следующие:

• Защита Microsoft Entra ID
• Microsoft Defender для облака
• Microsoft Defender for Cloud Apps
• Microsoft Defender для Office 365
• Microsoft Defender для конечной точки
• Microsoft Defender для удостоверений
• Microsoft Defender для Интернета вещей

Несколько последовательностей сборников схем и действий в одном правиле

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

Назначение одного сборника схем нескольким правилам аналитики одновременно

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

Автоматическое назначение инцидентов

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

Подавление инцидентов

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

Автоматизация с ограниченным временем

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

Автоматическое добавление тегов к инцидентам

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

Варианты использования, добавленные триггером обновления

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

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

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

Обновление оркестрации и уведомлений

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

Поддержка синхронизации с внешними системами

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

Выполнение правил автоматизации

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

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

Разрешения для правил автоматизации для запуска сборников схем

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

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

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

Разрешения в мультитенантной архитектуре

Правила автоматизации полностью поддерживают развертывания между рабочими областями и несколькими средами (в случае с несколькими средами с использованием Azure Lighthouse).

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

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

• Правило автоматизации, созданное в клиенте клиента, настраивается для запуска сборника схем, расположенного в клиенте поставщика услуг.

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

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

  Эта конфигурация используется, когда нет необходимости защищать интеллектуальную собственность. Чтобы этот сценарий работал, разрешения на выполнение сборника схем должны быть предоставлены Microsoft Sentinel в обоих клиентах. В клиенте клиента вы предоставляете их на панели Управление разрешениями сборника схем , как в приведенном выше сценарии. Чтобы предоставить соответствующие разрешения в клиенте поставщика услуг, необходимо добавить дополнительное Azure делегирование Lighthouse, которое предоставляет права доступа к приложению Azure Security Insights с ролью участника службы автоматизации Microsoft Sentinel в группе ресурсов, в которой находится сборник схем.

  Сценарий выглядит следующим образом:

  

  Ознакомьтесь с нашими инструкциями по настройке.

Создание правил автоматизации и управление ими

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

• Страница автоматизации

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

  На странице Автоматизация отображаются все правила, определенные в рабочей области, а также их состояние (включено или отключено) и к каким правилам аналитики они применяются.

  Если вам нужно правило автоматизации, которое применяется к инцидентам из Microsoft Defender XDR или из многих правил аналитики в Microsoft Sentinel, создайте его непосредственно на странице Автоматизации.

• Мастер правил аналитики

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

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

• Страница инцидентов

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

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

Правила автоматизации экспорта и импорта

Экспортируйте правила автоматизации в файлы шаблонов Azure Resource Manager (ARM) и импортируйте правила из этих файлов в рамках управления развертываниями Microsoft Sentinel в виде кода и управления ими. Действие экспорта создает JSON-файл в расположении загрузок браузера, который затем можно переименовать, переместить и иным образом обрабатывать, как и любой другой файл.

Экспортированный JSON-файл не зависит от рабочей области, поэтому его можно импортировать в другие рабочие области и даже в другие клиенты. Как код, он также может управляться версиями, обновляться и развертываться в управляемой платформе CI/CD.

Файл содержит все параметры, определенные в правиле автоматизации. Правила любого типа триггера можно экспортировать в JSON-файл.

Инструкции по экспорту и импорту правил автоматизации см. в статье Экспорт и импорт правил автоматизации Microsoft Sentinel.

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

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

• Создание и использование правил автоматизации Microsoft Sentinel для управления инцидентами.
• Используйте правила автоматизации для создания списков задач для аналитиков.
• Дополнительные сведения о расширенных параметрах автоматизации см. в статье Автоматизация реагирования на угрозы с помощью сборников схем в Microsoft Sentinel.
• Сведения о реализации сборников схем см. в статье Руководство. Использование сборников схем для автоматизации реагирования на угрозы в Microsoft Sentinel.