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

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

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

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

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

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

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

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

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

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

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

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

Компоненты

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

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

Триггеры

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

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

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

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

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

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

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

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

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

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

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

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

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

Условия

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

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

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

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

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

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

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

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

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

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

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

значение свойства инцидента было

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

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

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

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

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

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

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

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

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

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

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

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

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

Действия

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

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

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

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

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

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

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

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

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

Срок действия

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

Порядок

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

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

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

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

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

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

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

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

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

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

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

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

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

Ниже представлены некоторые оповещения системы безопасности Microsoft.

• Защита идентификации Microsoft Entra
• Microsoft Defender для облака
• Microsoft Defender для облачных приложений
• Microsoft Defender для Office 365
• Защитник Майкрософт для конечных точек
• Microsoft Defender для удостоверений
• Microsoft Defender для Интернета вещей

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

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

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

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

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

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

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

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

Ограниченная по времени автоматизация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  

  См. в наших инструкциях по настройке.

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

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

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

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

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

  Если вам требуется правило автоматизации, которое применяется к инцидентам из XDR в Microsoft Defender или из многих правил аналитики в 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.