Создание настраиваемых правил обнаружения в Microsoft Defender XDR

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

Необходимые разрешения для управления настраиваемыми обнаружениями

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

Microsoft Defender XDR

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

• Параметры безопасности (управление) — пользователи с этим разрешением Microsoft Defender могут управлять параметрами безопасности на портале Microsoft Defender.

• Администратор безопасности. Пользователи с этой ролью Microsoft Entra могут управлять параметрами безопасности на портале Microsoft Defender и других порталах и службах.

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

Вы можете управлять пользовательскими обнаружениями, которые относятся к данным из определённых решений Defender, если у вас есть соответствующие разрешения для работы с ними. Например, если у вас есть только разрешения на управление Microsoft Defender для Office 365, можно создавать пользовательские обнаружения с помощью Email* таблиц, но не Identity* таблиц.

Аналогичным образом, поскольку таблица IdentityLogonEvents содержит сведения о действиях аутентификации как из Microsoft Defender for Cloud Apps, так и из Microsoft Defender for Identity, для управления пользовательскими обнаружениями, использующими запросы к этой таблице, необходимо иметь права управления для обеих служб.

Microsoft Sentinel

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

Управление необходимыми разрешениями

Для управления необходимыми разрешениями глобальный администратор может:

• Назначьте роль "Администратор безопасности" или "Оператор безопасности" в Центр администрирования Microsoft 365 в разделе Роли>Администратора безопасности.
• Проверьте параметры RBAC для Microsoft Defender для конечной точки в Microsoft Defender XDR в разделе Параметры>Разрешения>Роли. Выберите соответствующую роль, чтобы назначить разрешение на управление параметрами безопасности .

Создание настраиваемого правила обнаружения

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

• В разделе Расширенная охота — перейдите к разделу Расширенная охота, подготовьте и выполните запрос, а затем выберите Создать правило обнаружения. Такой подход позволяет проверить результаты запроса перед созданием правила.
• В списке настраиваемых обнаружений перейдите в раздел Настраиваемые правила обнаружения и выберите + Создать правило обнаружения. Этот подход открывает мастер правил напрямую, где можно написать или вставить запрос и настроить все параметры правил в одном месте.

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

1. Подготовка запроса
2. Создание правила и предоставление сведений о предупреждении
3. Задайте параметры обогащения оповещений
4. Указание действий
5. Настройка области правил
6. Просмотр и включение правила

1. Подготовьте запрос

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

Обязательные столбцы в результатах запроса

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

1. Timestamp или TimeGenerated — этот столбец задает метку времени для созданных оповещений. Если эти столбцы не проецируются из KQL, первое и последнее время события для созданного оповещения устанавливается в соответствии с окном обратного просмотра обнаружения.
2. Для таблиц Microsoft Defender для конечной точки включите DeviceId или DeviceName столбцы, чтобы убедиться, что:
   • Оповещения помечены правильной областью действия группы устройств.
   • Представление дерева процессов успешно создано.
3. Для всех остальных таблиц Defender спроецируйте Timestamp и ReportId из одного и того же события, чтобы Defender мог определить исходное событие, которое вызвало оповещение, чтобы:
   • Оповещения помечены правильной областью сущности (только для организаций, использующих области Defender XDR)
   • Представление временной шкалы оповещений полностью обогащено соответствующими данными.
4. Чтобы мастер автоматически сопоставил затронутый ресурс, включите один из следующих столбцов, содержащих надежный идентификатор затронутого ресурса:
   • Устройство:
     • DeviceId
     • DeviceName
     • RemoteDeviceName
   • Почтовый ящик:
     • RecipientEmailAddress
     • SenderFromAddress (отправитель конверта или адрес Return-Path)
     • SenderMailFromAddress (адрес отправителя, отображенный клиентом электронной почты)
     • SenderObjectId
     • RecipientObjectId
   • Учётная запись:
     • AccountObjectId
     • AccountSid
     • AccountUpn
     • InitiatingProcessAccountSid
     • InitiatingProcessAccountUpn

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

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

Следующий пример запроса подсчитывает количество уникальных устройств (DeviceId) с обнаружением антивирусной программы и использует это число для поиска только устройств с более чем пятью обнаружениями. Чтобы вернуть последний Timestamp и соответствующий ReportId, используется оператор summarize с функцией arg_max.

DeviceEvents
| where ingestion_time() > ago(1d)
| where ActionType == "AntivirusDetection"
| summarize (Timestamp, ReportId)=arg_max(Timestamp, ReportId), count() by DeviceId
| where count_ > 5

Настраиваемый столбец для определения области действия в Microsoft Sentinel

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

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

2. Создайте новое правило и предоставьте сведения об оповещении

В редакторе запросов выберите Создать правило обнаружения и укажите следующие сведения об оповещении:

• Имя обнаружения — имя правила обнаружения; сделать его уникальным.
• Частота — интервал выполнения запроса и выполнения действий. Дополнительные сведения см. в разделе "Частота правил".
• Обратный просмотр — период времени, охватываемый запросом, когда пользовательское обнаружение предназначено только для данных из Microsoft Sentinel. Дополнительные сведения см. в разделе Lookback.
• Заголовок оповещения — заголовок, отображаемый с оповещениями, активированными правилом; сделайте его уникальным и используйте обычный текст. Строки очищаются в целях безопасности, поэтому HTML, Markdown и другой код не работают. Все URL-адреса, включенные в заголовок, должны соответствовать формату кодирования процентов , чтобы они отображались должным образом.
• Серьезность — потенциальный риск компонента или действия, определяемого правилом.
• Категория — компонент угрозы или действие, определяемое правилом.
• Тактика — тактика MITRE ATT&CK, определяемая правилом, как описано в платформе MITRE ATT&CK.
• Методы — один или несколько методов атаки, определяемых правилом, как описано в платформе MITRE ATT&CK.
• Подтехники — одна или несколько подтехник атак, выявленных правилом, как описано в фреймворке MITRE ATT&CK.
• Отчет аналитики угроз . Привяжите созданное оповещение к существующему отчету аналитики угроз, чтобы оно отображалось на вкладке Связанные инциденты в аналитике угроз.
• Описание — дополнительные сведения о компоненте или действии, определяемом правилом. Строки очищаются в целях безопасности, поэтому HTML, Markdown и другой код не работают. Все URL-адреса, включенные в описание, должны соответствовать формату кодирования процентов, чтобы они отображались должным образом.
• Рекомендуемые действия — дополнительные действия, которые могут выполняться респондентами в ответ на оповещение.

Частота срабатывания правила

При сохранении нового правила оно запускается и проверяет наличие совпадений в данных за последние 30 дней. Затем правило снова выполняется через фиксированные интервалы, применяя период обратного просмотра в зависимости от выбранной частоты:

• Каждые 24 часа
• Каждые 12 часов
• Каждые 3 часа
• Каждый час
• Непрерывный (NRT) — выполняется непрерывно и проверяет данные событий по мере их сбора и обработки в режиме, близком к реальному времени (NRT). Дополнительные сведения см. в разделе Непрерывная частота (NRT).
• Пользовательский — выполняется в соответствии с выбранной частотой. Этот параметр доступен, если правило основано только на данных, которые подается в Microsoft Sentinel. Дополнительные сведения см. в разделе Настраиваемая частота для данных Microsoft Sentinel.

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

Непрерывная частота (NRT)

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

На странице пользовательских правил обнаружения можно перенести пользовательские правила обнаружения, которые подходят для частоты Continuous (NRT), выбрав Перенести сейчас:

Когда вы выбираете Мигрировать сейчас, отображается список всех совместимых правил в соответствии с их запросом KQL. Вы можете перенести только все или выбранные правила:

При нажатии кнопки Сохранить частота выбранных правил обновляется до непрерывной (NRT).

Запросы, которые можно выполнять непрерывно

Запрос можно выполнять непрерывно при условии, что:

• Запрос ссылается только на одну таблицу.
• В запросе используется оператор из списка поддерживаемых функций KQL. matches regex Для оператора регулярные выражения должны кодироваться как строковые литералы и следовать правилам цитирования строк. Например, регулярное выражение \A представлено в KQL как "\\A". Дополнительная обратная косая черта указывает на то, что другая обратная косая черта входит в состав регулярного выражения \A.
• Запрос не использует соединения, объединения или оператор externaldata.
• Запрос не содержит ни строки комментариев, ни сведений.

Таблицы с поддержкой непрерывной (NRT) частоты

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

Настраиваемая частота для данных Microsoft Sentinel

Клиенты Microsoft Sentinel, которые подключаются к Microsoft Defender, могут выбрать частоту Настраиваемая, если правило основано только на данных, которые принимает Microsoft Sentinel.

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

Ретроспектива

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

Если пользовательские обнаружения включают данные Defender XDR, применяется фиксированный ретроспективный период в зависимости от выбранной вами частоты выполнения правила:

• Для правил обнаружения, настроенных на запуск каждые 24 часа, период ретроспективного анализа составляет 30 дней.
• Для правил обнаружения, настроенных на запуск каждые 12 часов, ретроспективный период составляет 48 часов.
• Для правил обнаружения, настроенных на выполнение каждые три часа, период ретроспективного анализа составляет 12 часов.
• Для обнаружений, настроенных на ежечасный запуск, период ретроспективного анализа составляет четыре часа.

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

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

3. Определите параметры обогащения оповещений

Оповещения можно дополнить, предоставив и определив дополнительные сведения. При обогащении оповещений вы можете:

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

Создание динамического заголовка и описания оповещения

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

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

Пример: User {{AccountName}} unexpectedly signed in from {{Location}}

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

Добавление пользовательских сведений

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

В разделе Настраиваемые сведения добавьте пары «ключ — значение» для сведений, которые вы хотите отображать:

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

На следующем снимке экрана показано, как настраиваемые сведения отображаются на боковой панели оповещений:

Связывание сущностей

Определите столбцы в результатах запроса, где вы ожидаете найти основной затронутый объект. Например, запрос может возвращать адреса отправителя (SenderFromAddress или SenderMailFromAddress) и получателя (RecipientEmailAddress). Определение того, какой из этих столбцов представляет основную затронутую сущность, помогает службе собирать соответствующие оповещения, коррелировать инциденты и выбирать целевые действия по реагированию.

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

Расширенное сопоставление сущностей

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

Для Microsoft Defender XDR данных сущности выбираются автоматически. Если данные поступают из Microsoft Sentinel, необходимо выбрать сущности вручную.

Развернутый раздел Сопоставление сущностей содержит два раздела, в которых можно выбрать сущности:

• Затронутые ресурсы . Добавьте затронутые ресурсы, которые отображаются в выбранных событиях. Можно добавить следующие типы ресурсов:
  • Учетная запись
  • Устройство
  • Почтовый ящик
  • Облачное приложение
  • Ресурс Azure
  • Ресурс Amazon Web Services
  • Ресурс Google Cloud Platform
• Связанные данные — добавьте объекты, не являющиеся активами, которые присутствуют в выбранных событиях. Поддерживаемые типы сущностей:
  • Процесс
  • Файл
  • Значение реестра
  • IP
  • Приложение OAuth
  • DNS
  • Группа безопасности
  • URL-адрес
  • Почтовый кластер
  • Почтовое сообщение

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

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

4. Укажите действия

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

Действия на устройствах

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

• Изоляция устройства. Использует Microsoft Defender для конечной точки для применения полной сетевой изоляции, предотвращая подключение устройства к любому приложению или службе. Дополнительные сведения об изоляции Microsoft Defender для конечной точки компьютера.
• Собрать пакет данных для расследования — собирает данные об устройстве в ZIP-архив. Дополнительные сведения о пакете для расследования Microsoft Defender для конечных точек.
• Запуск антивирусной проверки— выполняет полную проверку Microsoft Defender антивирусной программы на устройстве.
• Инициирование исследования — инициирует автоматическое исследование на устройстве.
• Ограничение выполнения приложений . Устанавливает ограничения на устройстве, разрешающие запуск только файлов, подписанных сертификатом Майкрософт. Подробнее об ограничениях приложений в Microsoft Defender для конечных точек.

Действия в отношении файлов

• Если этот параметр выбран, к файлу можно применить действие Разрешить или заблокировать . Блокировка файлов разрешена, только если у вас есть разрешения на исправление файлов и если результаты запроса определяют идентификатор файла, например хэш SHA-1. После блокировки файла блокируются и другие экземпляры того же файла на всех устройствах. Вы можете управлять группой устройств, к которой применяется блокировка, но не конкретным устройствам.

• Если этот параметр выбран, действие Карантин файла можно применить к файлам в столбце SHA1, InitiatingProcessSHA1, SHA256или InitiatingProcessSHA256 в результатах запроса. Это действие удаляет файл из текущего расположения и помещает копию в карантин.

Действия с пользователями

• Если выбран этот параметр, действие Пометить пользователя как скомпрометированного применяется к пользователям в столбце AccountObjectId, InitiatingProcessAccountObjectId или RecipientObjectId результатов запроса. Это действие устанавливает уровень риска пользователя на "высокий" в Microsoft Entra ID, активируя соответствующие политики защиты идентификации.

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

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

• Для параметров Отключить пользователя и Сбросить проверку подлинности пользователя требуется идентификатор безопасности пользователя (SID), который есть в столбцах AccountSid, InitiatingProcessAccountSid, RequestAccountSidи OnPremSid.

• Для идентификаторов Microsoft Entra параметр AccountObjectId требуется для всех действий.

Дополнительные сведения о действиях пользователя см. в статьях Действия по исправлению в Microsoft Defender для удостоверений и Действия по исправлению в Microsoft Defender для облачных приложений.

Действия с электронной почтой

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

  

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

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

5. Установите область действия правила

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

При настройке области выберите:

• Все устройства
• Определенные группы устройств

Правило запрашивает данные только из устройств, входящих в область действия. Оно выполняет действия только на этих устройствах.

6. Просмотрите и включите правило

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

Как настраиваемые обнаружения обрабатывают дублирующиеся оповещения

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

Связанные материалы

• Обзор пользовательских обнаружений
• Управление пользовательскими обнаружениями
• Обзор расширенной охоты
• Познакомьтесь с языком запросов расширенной охоты
• Перенос запросов расширенного поиска из Microsoft Defender для конечных точек
• API Microsoft Graph Security для настраиваемых обнаружений