Автоматизация реагирования на угрозы в Microsoft Sentinel с помощью правил автоматизации
Эта статья содержит сведения о правилах автоматизации Microsoft Sentinel, а также о том, как с их помощью реализовать операции оркестрации средств обеспечения безопасности, автоматизации и реагирования (SOAR), чтобы в конечном счете повысить эффективность SOC, а заодно сэкономить время и ресурсы.
Внимание
Microsoft Sentinel доступен в рамках общедоступной предварительной версии для единой платформы операций безопасности на портале Microsoft Defender. Дополнительные сведения см . на портале Microsoft Defender в Microsoft Sentinel.
Что такое правила автоматизации?
Правила автоматизации — это способ централизованного управления автоматизацией в Microsoft Sentinel, позволяющий определять и координировать небольшой набор правил, которые применяются в разных сценариях.
Правила автоматизации применяются к следующим категориям вариантов использования:
Выполнение основных задач автоматизации для обработки инцидентов без использования сборников схем. Например:
- Добавьте задачи инцидентов для следующих аналитиков.
- Подавление инцидентов с помехами.
- Рассмотрение новых инцидентов путем изменения их состояния с "Новый" на "Активный" и назначения владельца.
- Добавление меток к инцидентам, чтобы классифицировать их.
- Эскалация инцидента путем назначения нового владельца.
- Закрытие разрешенных инцидентов путем указания причины и добавления комментариев.
Автоматизировать ответы для нескольких правил аналитики одновременно.
Управлять порядком выполняемых действий.
Анализ содержимого инцидента (оповещений, сущностей и других свойств) и выполнение дальнейших действий путем вызова сборника схем.
Правила автоматизации также могут быть механизмом, с помощью которого выполняется сборник схем в ответ на оповещение, не связанное с инцидентом.
Вкратце, правила автоматизации модернизируют использование автоматизации в Microsoft Sentinel, позволяя упростить сложные рабочие процессы для оркестрации реагирования на угрозы.
Компоненты
Правила автоматизации состоят из нескольких компонентов.
- Триггеры, определяющие, какое событие инцидента вызовет выполнение правила при условии, что...
- Условия, определяющие точные обстоятельства, в которых правило будет запускаться и выполняться...
- Действия по изменению инцидента некоторым образом или вызову сборника схем.
Триггеры
Правила автоматизации активируются при создании или обновлении инцидента или при создании оповещения. Помните, что инциденты включают оповещения, и что оповещения и инциденты можно создавать с помощью правил аналитики, из которых существует несколько типов, как описано в статье "Обнаружение угроз со встроенными правилами аналитики в Microsoft Sentinel".
В следующей таблице показаны различные возможные сценарии, которые приводят к запуску правила автоматизации.
| Тип триггера | События, вызывающие выполнение правила |
|---|---|
| При создании инцидента | Единая платформа операций безопасности в Microsoft Defender: Microsoft Sentinel не подключен к унифицированной платформе: |
| При обновлении инцидента | |
| При создании оповещения |
Автоматизация осуществляется на основе инцидентов или оповещений?
Теперь, когда автоматизация инцидентов и оповещений обрабатывается централизованно правилами автоматизации, а также сборниками схем, следует выбрать, когда следует использовать каждое из средств.
В большинстве случаев предпочтительным подходом является автоматизация, активируемая инцидентами. В Microsoft Sentinel инцидент представляет собой "папку дела" — объединение всех доказательств для определенного расследования. Это контейнер для оповещений, сущностей, комментариев, совместной работы и других артефактов. В отличие от оповещений, которые являются отдельными доказательствами, инциденты могут изменяться, имеют актуальное состояние и могут обогащаться комментариями, тегами и закладками. Инцидент позволяет отслеживать историю атаки, которая продолжает развиваться при добавлении новых оповещений.
По этим причинам рациональнее строить автоматизацию на основе инцидентов. Наиболее подходящий способ создания сборников схем — на основе триггера инцидента Microsoft Sentinel в Azure Logic Apps.
Основная причина использования автоматизации, активируемой оповещением, заключается в том, чтобы отвечать на оповещения, созданные правилами аналитики, которые не создают инциденты (т. е. при отключении созданияинцидентов на вкладке "Параметры инцидента" мастера правил аналитики).
Эта причина особенно актуальна, если рабочая область Microsoft Sentinel подключена к единой платформе операций безопасности, так как все инциденты создаются в XDR в Microsoft Defender, поэтому правила создания инцидентов в Microsoft Sentinel должны быть отключены.
Даже без подключения к единому порталу вы можете в любом случае решить использовать автоматизацию с активацией оповещений, если вы хотите использовать другую внешнюю логику, чтобы определить, создаются ли инциденты из оповещений, а также как и как оповещения группируются в инциденты. Например:
Сборник схем может активироваться оповещением, с которым не связан инцидент. Он может обогащать оповещение сведениями из других источников и на основе внешней логики решать, следует ли создавать инцидент.
Сборник схем может активироваться оповещением и вместо создания инцидента находить соответствующий существующий инцидент, к которому будет добавлено оповещение. Узнайте больше о расширении инцидентов.
Сборник схем может активироваться оповещением и уведомлять сотрудников SOC об этом оповещении, чтобы команда могла решить, следует ли создавать инцидент.
Сборник схем может активироваться оповещением и отправлять это оповещение во внешнюю систему билетов для создания инцидента и управления им, причем для каждого оповещения создается новый билет.
Примечание.
Автоматизация с активацией оповещений доступна только для оповещений, созданных правилами аналитики Scheduled и NRT. Оповещения, создаваемые правилами аналитики отдела безопасности Майкрософт, не поддерживаются.
Аналогичным образом автоматизация, активироваемая оповещением для оповещений, созданных XDR в Microsoft Defender, недоступна на единой платформе операций безопасности на портале Microsoft Defender.
Дополнительные сведения см. в разделе автоматизации с помощью единой платформы операций безопасности.
Условия
Для управления запуском действий (см. ниже) можно задавать сложные наборы условий. К этим условиям относятся событие, которое активирует правило (создание или обновление инцидента, создание оповещения), состояния или значения свойств инцидента и свойств сущности (только для триггера инцидента), а также правило аналитики или правила, создающие инцидент либо оповещение.
При активации правило автоматизации проверяет инцидент или оповещение активации на соответствие условиям, определенным в правиле. Для инцидентов условия на основе свойств оцениваются в соответствии с текущим состоянием свойства на момент вычисления или в соответствии с изменениями состояния свойства (см. ниже). Так как одиночное событие создания или обновления инцидента может активировать несколько правил автоматизации, порядок их выполнения (см. ниже) имеет значение при определении результата оценки условий. Действия, определенные в правиле, будут выполняться только в том случае, если выполнены все условия.
Триггер создания инцидента
Для правил, определенных с помощью триггера При создании инцидента, можно определить условия, которые проверяют текущее состояние значений заданного списка свойств инцидента с помощью одного или нескольких из следующих операторов.
Значение свойства инцидента
- равно или не равно значению, определенному в условии;
- содержит или не содержит значение, определенное в условии;
- начинается или не начинается со значения, определенного в условии;
- заканчивается или не заканчивается значением, определенным в условии.
Текущее состояние в этом контексте относится к моменту вычисления условия, т. е. к моменту запуска правила автоматизации. Если в ответ на создание этого инцидента определяется более одного правила автоматизации, то изменения, внесенные в инцидент правилом автоматизации, выполненным ранее, считаются для правил, выполняемых позже, текущим состоянием.
Триггер обновления инцидента
К условиям, вычисленным в правилах, определенных с помощью триггера При обновлении инцидента, относятся все условия в списке для триггера создания инцидента. Однако триггер обновления содержит дополнительные свойства, которые можно вычислить.
Одно из этих свойств — Кем обновлено. Это свойство позволяет отслеживать тип источника, который внес изменение в инцидент. Вы можете создать условие, оценивающее, был ли инцидент обновлен одним из следующих значений, в зависимости от того, подключена ли рабочая область к единой платформе операций безопасности:
- Приложение, включая приложения на порталах Azure и Defender.
- Пользователь, включая изменения, внесенные пользователями на порталах Azure и Defender.
- AIR для обновлений путем автоматического исследования и реагирования в Microsoft Defender для Office 365
- Группирование оповещений (которое добавило оповещения в инцидент), включая группировки оповещений, выполненные как правилами аналитики, так и встроенной логикой корреляции XDR в Microsoft Defender
- Сборник схем
- Правило автоматизации
- Другое, если ни одно из указанных выше значений не применяется
С помощью этого условия можно, например, указать, что это правило автоматизации будет выполняться при внесении в инцидент любых изменений за исключением случаев, когда их вносит другое правило автоматизации.
Более того, триггер обновления также использует другие операторы, которые проверяют изменения состояния в значениях свойств инцидента, а также их текущее состояние. Условие изменения состояния будет выполнено, если:
значение свойства инцидента было
- изменено (независимо от фактического значения до или после);
- изменено со значения, определенного в условии;
- изменено на значение, определенное в условии;
- добавлено (это относится к свойствам со списком значений).
Свойство тега : отдельная коллекция и коллекция
Тег свойства инцидента — это коллекция отдельных элементов— один инцидент может применять к нему несколько тегов. Вы можете определить условия, которые проверка каждый тег в коллекции по отдельности и условия, которые проверка коллекцию тегов в виде единицы.
- Все отдельные операторы тегов проверка условие для каждого тега в коллекции. Оценка имеет значение true , если по крайней мере один тег удовлетворяет условию.
- Коллекция всех операторов тегов проверка условие для коллекции тегов в виде одной единицы. Оценка имеет значение true , только если коллекция в целом удовлетворяет условию.
Это различие имеет значение, когда ваше условие является отрицательным (не содержит), а некоторые теги в коллекции удовлетворяют условию, а другие — нет.
Давайте рассмотрим пример, в котором находится условие, тег не содержит "2024", и у вас есть два инцидента, каждый из которых содержит два тега:
| \Инцидентов ▶ Условие \ |
Инцидент 1 Тег 1: 2024 Тег 2: 2023 |
Инцидент 2 Тег 1: 2023 Тег 2: 2022 |
|---|---|---|
| Любой отдельный тег не содержит "2024" |
TRUE | TRUE |
| Коллекция всех тегов не содержит "2024" |
FALSE | TRUE |
В этом примере в инциденте 1:
- Если условие проверка каждый тег по отдельности, то так как есть по крайней мере один тег, удовлетворяющий условию (который не содержит "2024"), общее условие имеет значение true.
- Если условие проверка все теги в инциденте в виде одной единицы, то так как есть по крайней мере один тег, который не удовлетворяет условию (который содержит "2024"), общее условие равно false.
В инциденте 2 результат будет одинаковым, независимо от того, какой тип условия определен.
Триггер создания оповещения
В настоящее время единственным условием, которое можно настроить для триггера создания оповещения, является набор правил аналитики, для которых будет выполняться правило автоматизации.
Действия
Можно задавать запуск действий при выполнении условий (см. выше). В правиле можно определить множество действий, а также выбрать порядок их выполнения (см. ниже). Следующие действия можно определить с помощью правил автоматизации без использования дополнительных функциональных возможностей сборника схем.
Добавление задачи в инцидент — вы можете создать проверка список задач для аналитиков, которые следует выполнять во всех процессах обработки, расследования и исправления инцидента, чтобы убедиться, что критически важные шаги не пропущены.
Изменение состояния инцидента с поддержанием рабочего процесса в актуальном состоянии.
- Когда состояние изменяется на «Закрыто», указывается причина закрытия и добавляется комментарий. Это позволяет следить за производительностью и эффективностью, а также выполнять точную настройку для сокращения числа ложноположительных результатов.
Изменение серьезности инцидента: можно переоценивать и изменять приоритеты в зависимости от наличия, отсутствия, значений или атрибутов сущностей, вовлеченных в инцидент.
Назначение инцидента владельцу: помогает направлять типы инцидентов сотрудникам, которые наилучшим образом подходят для работы с ними, или самым свободным сотрудникам.
Добавление тега к инциденту. Полезно при классификации инцидентов по темам, злоумышленникам или другим общим чертам.
Кроме того, можно определить действие для запуска сборника схем, чтобы выполнять более сложные ответные действия, в том числе все действия, затрагивающие внешние системы. Сборники схем, доступные для использования в правиле автоматизации, зависят от триггера, на котором основаны сборники схем и правило автоматизации: из правил автоматизации, активируемых инцидентом, можно запускать только сборники схем, активируемые инцидентом, а из правил автоматизации, активируемых оповещением, можно запускать только сборники схем, активируемые оповещением. Вы можете определить несколько действий, которые вызывают сборники схем или сочетания сборников схем и других действий. Действия будут выполняться в том порядке, в котором они перечислены в правиле.
Сборники схем с использованием любой версии Azure Logic Apps (стандартный или потребления) будут доступны для запуска из правил автоматизации.
Срок действия
Можно определить дату окончания срока действия правила автоматизации. По прошествии этой даты правило будет отключено. Это полезно при обработке (т. е. закрытии) "пропускаемых" инцидентов, вызванных запланированными, ограниченными по времени действиями, такими как тест на проникновение.
Порядок
Можно определить порядок, в котором будут выполняться правила автоматизации. Последующие правила автоматизации будут оценивать условия инцидента в соответствии с его состоянием после принятия мер предыдущими правилами автоматизации.
Например, если "Первое правило автоматизации" изменило серьезность инцидента со средней на низкую, а "Второе правило автоматизации" по определению выполняется только для инцидентов со средним или более высоким уровнем серьезности, выполняться для этого инцидента оно не будет.
Порядок правил автоматизации, добавляющих задачи инцидентов, определяет порядок отображения задач в данном инциденте.
Правила, основанные на триггере обновления, имеют собственную отдельную очередь заказов. Если такие правила активируются для только что созданного инцидента (изменением, внесенным другим правилом автоматизации), они будут выполняться только после выполнения всех применимых правил на основе триггера создания.
Заметки о порядке выполнения и приоритете
- Задание номера заказа в правилах автоматизации определяет их порядок выполнения.
- Каждый тип триггера поддерживает собственную очередь.
- Для правил, созданных в портал Azure, поле заказа будет автоматически заполнено номером, следующим самым высоким числом, используемым существующими правилами одного и того же типа триггера.
- Однако для правил, созданных другими способами (командная строка, API и т. д.), номер заказа должен быть назначен вручную.
- Механизм проверки не позволяет нескольким правилам иметь один и тот же номер заказа, даже в одном типе триггера.
- Вы можете разрешить два или более правил одного типа триггера иметь одинаковый номер заказа, если вы не заботитесь о том, в каком порядке они выполняются.
- Для правил одного и того же типа триггера с одинаковым порядковым номером подсистема выполнения случайным образом выбирает, какие правила будут выполняться в каком порядке.
- Для правил разных типов триггеров инцидентов все применимые правила с типом триггера создания инцидента будут выполняться сначала (в соответствии с их номерами заказа), а затем только правила с типом триггера обновления инцидента (в соответствии с их номерами заказа).
- Правила всегда выполняются последовательно, никогда не параллельно.
Примечание.
После подключения к единой платформе операций безопасности при внесении нескольких изменений в один и тот же инцидент в течение пяти-десяти минут один обновление отправляется в Microsoft Sentinel с единственным последним изменением.
Распространенные варианты использования и сценарии
Задачи инцидента
Правила автоматизации позволяют стандартизировать и формализировать шаги, необходимые для обработки, расследования и исправления инцидентов, создавая задачи , которые можно применять к одному инциденту, между группами инцидентов или ко всем инцидентам в соответствии с условиями, заданными в правиле автоматизации и логике обнаружения угроз в базовых правилах аналитики. Задачи, применяемые к инциденту, отображаются на странице инцидента, поэтому аналитики имеют весь список действий, которые они должны предпринять, прямо перед ними, и не пропустит каких-либо критически важных шагов.
Автоматизация с активацией инцидентом и оповещением
Правила автоматизации можно активировать путем создания или обновления инцидентов, а также создания оповещений. Во всех случаях могут активироваться цепочки автоматического реагирования, которые могут включать сборники схем (требуются специальные разрешения).
Активация сборников схем для поставщиков Майкрософт
Правила автоматизации позволяют автоматизировать обработку оповещений системы безопасности Майкрософт путем применения к инцидентам, созданным на основе оповещений. Правила автоматизации могут вызывать сборники схем (требуются специальные разрешения) и передавать им инциденты и все сведения о них, в том числе оповещения и сущности. Как правило, рекомендации Microsoft Sentinel предписывают использовать очередь инцидентов в качестве фокуса операций безопасности.
Ниже представлены некоторые оповещения системы безопасности Microsoft.
- Защита идентификации Microsoft Entra
- Microsoft Defender для облака
- Microsoft Defender для облачных приложений
- Microsoft Defender для Office 365;
- Защитник Майкрософт для конечных точек
- Microsoft Defender для удостоверений
- Microsoft Defender для Интернета вещей
Несколько последовательных сборников схем или действий в одном правиле
Теперь можно практически полностью контролировать порядок выполнения действий и сборников схем в одном правиле автоматизации. Вы также управляете порядком выполнения самих правил автоматизации. Это позволяет значительно упрощать сборники схем, сокращая их до одной задачи или небольшой, простой последовательности задач и объединяя эти небольшие сборники схем в разных сочетаниях в различных правилах автоматизации.
Одновременное назначение одного сборника схем нескольким правилам аналитики
Если имеется задача, которую необходимо автоматизировать для всех правил аналитики, — скажем, создание запроса в службу поддержки во внешней системе использования билетов, — можно применить один сборник схем к любому или всем правилам аналитики — включая все будущие правила — одновременно. Это существенно сокращает время выполнения простых, но однообразных действий по обслуживанию.
Автоматическое назначение инцидентов
Можно автоматически назначать инциденты правильному владельцу. Если в вашем SOC есть аналитик, специализирующийся на определенной платформе, все инциденты, связанные с этой платформой, можно автоматически назначать этому аналитику.
Подавление инцидентов
С помощью правил можно автоматически разрешать инциденты с известными ложноположительными или неопасными положительными результатами без использования сборников схем. Например, при выполнении тестов на проникновение, выполнении планового обслуживания или обновлений или процедур автоматизации тестирования может быть создано множество ложных положительных инцидентов, которые soC хочет игнорировать. Правило автоматизации с ограничением по времени может автоматически закрывать эти инциденты по мере их создания, одновременно добавляя к ним в качестве тега дескриптор причины создания.
Ограниченная по времени автоматизация
Для правил автоматизации можно добавлять даты окончания срока действия. Могут возникнуть случаи, отличные от подавления инцидентов, которые гарантируют ограниченное время автоматизации. Может потребоваться назначить определенный тип инцидента конкретному пользователю (например, интернатору или консультанту) для определенного периода времени. Если интервал времени известен заранее, это правило можно отключать, когда оно теряет актуальность, причем специально помнить об этом не нужно.
Автоматическое добавление тегов к инцидентам
Можно автоматически добавлять к инцидентам текстовые теги, чтобы группировать или классифицировать их в соответствии с какими-либо условиями.
Варианты использования, добавленные триггером обновления
Теперь, когда изменения, внесенные в инциденты, могут активировать правила автоматизации, автоматизации подлежит все больше сценариев.
Расширение автоматизации по мере развития инцидента
Триггер обновления можно использовать для применения многих описанных выше вариантов использования к инцидентам по мере их исследования и добавления аналитиками оповещений, комментариев и тегов. Управляйте группированием оповещений в инцидентах.
Оркестрация обновлений и уведомление об обновлениях
Сообщите различным командам и другим сотрудникам о внесении изменений в инциденты, чтобы они не пропустили критически важные обновления. Передавайте инциденты на обработку путем назначения им новых владельцев и информирования новых владельцев о своих назначениях. Контролируйте время и способ повторного открытия инцидентов.
Поддержка синхронизации с внешними системами
Если вы использовали сборники схем для создания во внешних системах билетов при создании инцидентов, можно использовать правило автоматизации update-trigger для вызова сборника схем, который обновит эти билеты.
Выполнение правил автоматизации
Правила автоматизации выполняются последовательно в соответствии с порядком, который вы установите. Каждое правило автоматизации выполняется после завершения предыдущего. В рамках правила автоматизации все действия выполняются последовательно в том порядке, в котором они определены.
Действия сборника схем в правиле автоматизации могут обрабатываться по-разному в некоторых случаях в соответствии со следующими критериями:
| Время выполнения сборника схем | Правило автоматизации переходит к следующему действию... |
|---|---|
| Меньше секунды | Непосредственно после завершения выполнения сборника схем |
| Менее двух минут | До двух минут после начала работы сборника схем, но после завершения выполнения сборника схем не более 10 секунд |
| Более двух минут | Две минуты после начала работы сборника схем, независимо от того, был ли она выполнен |
Разрешения на выполнение сборников схем для правил автоматизации
При выполнении сборника схем правило автоматизации Microsoft Sentinel использует специальную учетную запись службы Microsoft Sentinel, наделенную полномочиями для выполнения этого действия. Использование этой учетной записи (в отличие от учетной записи пользователя) повышает уровень безопасности службы.
Чтобы правило автоматизации могло выполнять сборник схем, этой учетной записи необходимо предоставить явные разрешения для группы ресурсов, в которой находится сборник схем. На этом этапе любое правило автоматизации сможет выполнять любые сборники схем в этой группе ресурсов.
При настройке правила автоматизации и добавлении действия выполнения сборника схем появляется раскрывающийся список сборников схем. Сборники схем, на которые у 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 в разделе "Правила автоматизации" можно просматривать, изменять и создавать правила автоматизации, которые применяются к определенному правилу аналитики, созданному или редактируемом в мастере.
Обратите внимание, что при создании правила автоматизации на панели Создание правила автоматизации условие правила аналитики отображается как недоступное, поскольку оно уже настроено для применения только к правилу аналитики, которое вы редактируете в мастере. Все остальные параметры конфигурации по-прежнему доступны.
Страница "Инциденты"
Вы также можете создать правило автоматизации на странице "Инциденты ", чтобы ответить на один повторяющийся инцидент. Это полезно при создании правила подавления для автоматического закрытия "пропускаемых" инцидентов.
При создании правила автоматизации на панели Создание правила автоматизации все поля будут заполнены значениями из инцидента. Правилу присваивается то же самое имя, что и инциденту, после чего оно применяется к правилу аналитики, создавшему инцидент, а все доступные сущности в инциденте используются в качестве условий правила. Кроме того, для правила предлагается действие подавления (закрытие) по умолчанию и дата окончания срока действия. Добавлять или удалять условия и действия, а также изменять дату окончания срока действия можно по своему усмотрению.
Следующие шаги
В этом документе представлены сведения о том, как правила автоматизации позволяют централизованно управлять автоматизацией реагирования на инциденты и оповещения Microsoft Sentinel.
- Создание и использование правил автоматизации Microsoft Sentinel для управления инцидентами
- Используйте правила автоматизации для создания списков задач для аналитиков.
- Дополнительные сведения о расширенных параметрах автоматизации см. в статье Автоматизация реагирования на угрозы с помощью сборников схем в Microsoft Sentinel.
- Справку по реализации сборников схем см. в разделе Учебник: использование сборников схем для автоматизации реагирования на угрозы в Microsoft Sentinel.