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

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

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

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

Microsoft Defender XDR

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

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

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

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

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

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

Microsoft Sentinel

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

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

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

• Назначьте роль "Администратор безопасности" или "Оператор безопасности" в Центр администрирования Microsoft 365 в разделе Роли>Администратора безопасности.

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

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

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

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

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

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

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

2. Для обнаружения, основанных на таблицах XDR, столбец или сочетание столбцов, которые однозначно идентифицируют событие в этих таблицах:

   • Для Microsoft Defender для конечной точки таблиц Timestampстолбцы , DeviceIdи ReportId должны отображаться в одном событии.
   • Для таблиц оповещений Timestamp * должно отображаться в событии
   • Для таблиц TimestampНаблюдения* и ObservationId должны отображаться в одном и том же событии.
   • Для всех остальных и TimestampReportId должен отображаться в одном и том же событии

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

   • DeviceId
   • DeviceName
   • RemoteDeviceName
   • RecipientEmailAddress
   • SenderFromAddress (отправитель конверта или адрес Return-Path)
   • SenderMailFromAddress (адрес отправителя, отображенный клиентом электронной почты)
   • SenderObjectId
   • RecipientObjectId
   • AccountObjectId
   • AccountSid
   • AccountUpn
   • InitiatingProcessAccountSid
   • InitiatingProcessAccountUpn
   • InitiatingProcessAccountObjectId

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

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

Следующий пример запроса подсчитывает количество уникальных устройств (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

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

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

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

Частота правила

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

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

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

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

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

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

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

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

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

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

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

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

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

• AlertEvidence
• CloudAppEvents
• DeviceEvents
• DeviceFileCertificateInfo
• DeviceFileEvents
• DeviceImageLoadEvents
• DeviceLogonEvents
• DeviceNetworkEvents
• DeviceNetworkInfo
• DeviceInfo
• DeviceProcessEvents
• DeviceRegistryEvents
• EmailAttachmentInfo
• EmailEvents (кроме LatestDeliveryLocation столбцов и LatestDeliveryAction )
• EmailPostDeliveryEvents
• EmailUrlInfo
• IdentityDirectoryEvents
• IdentityLogonEvents
• IdentityQueryEvents
• UrlClickEvents

Пользовательская частота для Microsoft Sentinel данных (предварительная версия)

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

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

1. Если обнаружение выполняется чаще одного раза в день, обратный просмотр в четыре раза превышает частоту. Например, если частота составляет 20 минут, обратный просмотр составляет 80 минут.
2. Для обнаружения, которые должны выполняться один раз в день или реже, обратный просмотр составляет 30 дней. Например, если задано значение для выполнения каждые три дня, обратный просмотр составляет 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, необходимо выбрать сущности вручную.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Disable user Для параметров и Force password reset требуется идентификатор безопасности пользователя, который входит в столбцы AccountSid, InitiatingProcessAccountSid, RequestAccountSidи OnPremSid.

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

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

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

  

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

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

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

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

При настройке области можно выбрать следующее.

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

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

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

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

Обработка повторяющихся оповещений пользовательскими обнаружениями

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

См. также

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