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

  • Применяется к: Microsoft Defender XDR, Microsoft Sentinel in the Microsoft Defender portal, Microsoft Defender for Endpoint Plan 2

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

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

Для управления пользовательскими обнаружениями требуются роли, которые позволяют управлять данными, предназначенными для этих обнаружений. Например, для управления пользовательскими обнаружениями в нескольких источниках данных (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 Defender для конечной точки, если RBAC включен.

Microsoft Sentinel

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

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

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

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

Важно!

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

Примечание.

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

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

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

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

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

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

Важно!

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

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

Чтобы создать пользовательское правило обнаружения с помощью 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.

Важно!

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

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

Совет

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

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

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

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

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

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

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

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

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

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

Совет

Совпадите фильтры времени в запросе с периодом обратного просмотра. Результаты за пределами периода обратного просмотра игнорируются.

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

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

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

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

Снимок экрана: кнопка

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

Снимок экрана: запросы, совместимые с непрерывной частотой при расширенной охоте.

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

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

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

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

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

Microsoft Defender XDR Microsoft Sentinel
  • AlertEvidence
  • CloudAppEvents
  • DeviceEvents
  • DeviceFileCertificateInfo
  • DeviceFileEvents
  • DeviceImageLoadEvents
  • DeviceLogonEvents
  • DeviceNetworkEvents
  • DeviceNetworkInfo
  • DeviceInfo
  • DeviceProcessEvents
  • DeviceRegistryEvents
  • EmailAttachmentInfo
  • EmailEvents (кроме LatestDeliveryLocation столбцов и LatestDeliveryAction )
  • EmailPostDeliveryEvents
  • EmailUrlInfo
  • IdentityDirectoryEvents
  • IdentityLogonEvents
  • IdentityQueryEvents
  • UrlClickEvents
  • ABAPAuditLog_C
  • ABAPChangeDocsLog_CL
  • AuditLogs
  • AWSCloudTrail
  • AWSGuardDuty
  • AzureActivity
  • CommonSecurityLog
  • GCPAuditLogs
  • MicrosoftGraphActivityLogs
  • OfficeActivity
  • Okta_CL
  • OktaV2_CL
  • ProofpointPOD
  • ProofPointTAPClicksPermitted_CL
  • ProofPointTAPMessagesDelivered_CL
  • SecurityAlert
  • SecurityEvent
  • SigninLogs
 

Примечание.

Только общедоступные столбцы поддерживают непрерывную (NRT) частоту.

Пользовательская частота Microsoft Sentinel данных

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

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

Снимок экрана, на котором показан параметр Настраиваемая частота в руководстве по настройке настраиваемых обнаружений.

Важно!

При выборе настраиваемой частоты Defender извлекает данные из Microsoft Sentinel. Это условие означает, что:

  1. Данные должны быть доступны в Microsoft Sentinel.
  2. Defender XDR данные не поддерживают определение области, так как Microsoft Sentinel не поддерживает определение области.

Обратный просмотр

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

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

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

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

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

Важно!

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

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

3. Определение сведений об обогащении оповещений

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

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

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

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

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

Примечание.

В каждом поле можно ссылаться до трех столбцов.

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

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

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

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

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

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

Снимок экрана, на котором показан параметр Пользовательские сведения в мастере пользовательских обнаружений.

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

Снимок экрана: настраиваемые сведения, отображаемые на боковой панели оповещений портала Defender.

Важно!

Настраиваемые сведения имеют следующие ограничения.

  1. Каждое правило ограничено до 20 пар "ключ—значение" настраиваемых сведений.
  2. Совокупный размер всех пользовательских сведений и их значений в одном оповещении составляет 4 КБ. Если размер настраиваемого массива сведений превышает это ограничение, из оповещения удаляется весь массив пользовательских сведений.

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

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

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

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

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

Примечание.

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

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

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

Примечание.

В настоящее время можно сопоставить только ресурсы как затронутые сущности.

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

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

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

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

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

Снимок экрана: действия для пользовательского обнаружения на портале Microsoft Defender.

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

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

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

  • Если этот параметр выбран, к файлу можно применить действие Разрешить или заблокировать . Блокировка файлов разрешена, только если у вас есть разрешения на исправление файлов и если результаты запроса определяют идентификатор файла, например хэш 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 for Cloud Apps.

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

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

    Снимок экрана: параметр папки Снимок экрана: параметр папки

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

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

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

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

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

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

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

Примечание.

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

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

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

Важно!

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

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

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

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

См. также

Совет

Хотите узнать больше? Общайтесь с членами сообщества Microsoft Security в нашем техническом сообществе: Microsoft Defender XDR Tech Community.

  • Last updated on