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

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

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

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

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

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

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

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

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

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

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

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

Компоненты

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

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

Триггеры

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Условия

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Действия

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

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

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

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

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

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

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

Если ваше рабочее пространство подключено к порталу Microsoft Defender, Simple Flows (предварительная версия) предоставляет больше готовых действий, которые можно использовать непосредственно в мастере правил автоматизации без написания сценария. Доступные действия включают отправить письмо о создании/обновлении обращения или превышении SLA, обновить обращение, добавить задачу и обновить оповещение.

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

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

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

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

Заказ

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

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

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

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

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

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

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

Задачи по инциденту

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

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

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

Запуск сценариев для поставщиков Microsoft

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

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

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

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

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

Назначьте один сценарий сразу нескольким правилам аналитики

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При настройке правила автоматизации и добавлении действия запустить сборник схем появляется выпадающий список сборников схем. Сценарии автоматизации, к которым у 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.