Политики защиты от фишинга в Microsoft 365

Совет

Знаете ли вы, что можете бесплатно опробовать функции в Microsoft Defender XDR для Office 365 плана 2? Используйте 90-дневную пробную версию Defender для Office 365 в центре пробных версий портала Microsoft Defender. Сведения о том, кто может зарегистрироваться и условия пробной версии , см. здесь.

Политики для настройки параметров защиты от фишинга доступны в организациях Microsoft 365 с Exchange Online почтовыми ящиками, автономными организациями Exchange Online Protection (EOP) без Exchange Online почтовых ящиков. Microsoft Defender для Office 365 организаций.

Ниже приведены примеры Microsoft Defender для Office 365 организаций.

Общие различия между политиками защиты от фишинга в EOP и политиками защиты от фишинга в Defender для Office 365 описаны в следующей таблице:

Функция Политики защиты от фишинга
в EOP
Политики защиты от фишинга
в Defender для Office 365
Автоматически созданная политика по умолчанию
Создание настраиваемых политик
Общие параметры политики*
Параметры подделки
Совет по безопасности первого контакта
Параметры олицетворения
Расширенные пороговые значения фишинга

* В политике по умолчанию имя и описание политики доступны только для чтения (описание пустое), и нельзя указать, к кому применяется политика (политика по умолчанию применяется ко всем получателям).

Чтобы настроить политики защиты от фишинга, ознакомьтесь со следующими статьями:

В оставшейся части этой статьи описываются параметры, доступные в политиках защиты от фишинга в EOP и Defender для Office 365.

Общие параметры политики

В политиках защиты от фишинга в EOP и Defender для Office 365 доступны следующие параметры политики:

  • Имя. Вы не можете переименовать политику защиты от фишинга по умолчанию. После создания настраиваемой политики защиты от фишинга вы не сможете переименовать политику на портале Microsoft Defender.

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

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

    • Пользователи: один или несколько почтовых ящиков, почтовых пользователей или почтовых контактов в организации.
    • Группы.
      • Члены указанных групп рассылки или групп безопасности с поддержкой почты (динамические группы рассылки не поддерживаются).
      • Указанные Группы Microsoft 365.
    • Домены: один или несколько настроенных обслуживаемых доменов в Microsoft 365. Основной адрес электронной почты получателя находится в указанном домене.

    Условие или исключение можно использовать только один раз, но условие или исключение могут содержать несколько значений:

    • Несколько значений одного условия или исключения используют логику OR (например, <recipient1> или <recipient2>):

      • Условия. Если получатель соответствует любому из указанных значений, к нему применяется политика.
      • Исключения. Если получатель соответствует любому из указанных значений, политика к ним не применяется.
    • Различные типы исключений используют логику OR (например, recipient1>,<<member of group1> или <member of domain1>). Если получатель соответствует любому из указанных значений исключений, политика к нему не применяется.

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

      • Пользователей: romain@contoso.com
      • Группы: руководители

      Политика применяется только в romain@contoso.com том случае, если он также является членом группы руководителей. В противном случае политика к нему не применяется.

    Совет

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

Параметры подделки

Спуфингом называется, если поле От адреса в сообщении электронной почты (адрес отправителя, отображаемый в почтовых клиентах) не соответствует домену источника электронной почты. Дополнительные сведения о спуфингом см. в статье Защита от спуфингов в Microsoft 365.

В политиках защиты от фишинга в EOP и Defender для Office 365 доступны следующие спуфинговые параметры:

  • Включить спуфинговую аналитику. Включает или отключает спуфинга. Рекомендуется оставить его включенным.

    Если включена подделывающая аналитика , она показывает поддельных отправителей, которые были автоматически обнаружены, разрешены или заблокированы спуфингом. Вы можете вручную переопределить вердикт спуфинга аналитики, чтобы разрешить или заблокировать обнаруженные подделанные отправители из аналитических сведений. Но в этом случае подделанный отправитель исчезает из аналитических сведений о спуфингах и отображается только на вкладке Спуфинированные отправители на странице Разрешения и блокировки клиента Списки по адресу https://security.microsoft.com/tenantAllowBlockList?viewid=SpoofItem. Вы также можете вручную создать записи разрешения или блокировки для подделанных отправителей в списке разрешенных и заблокированных клиентов, даже если они не обнаружены в аналитике спуфинга. Дополнительные сведения см. в следующих статьях:

    Примечание.

    • Защита от спуфингов включена в стандартных и строгих предустановленных политиках безопасности и включена по умолчанию в политике защиты от фишинга по умолчанию и в новых настраиваемых политиках защиты от фишинга, которые вы создаете.
    • Вам не нужно отключать защиту от спуфингов, если запись MX не указывает на Microsoft 365; Вместо этого вы включите расширенную фильтрацию для соединителей. Инструкции см. в статье Расширенная фильтрация для соединителей в Exchange Online.
    • Отключение защиты от спуфингов отключает только неявную защиту от спуфингов от составных проверок проверки подлинности . Сведения о том, как на явные проверки DMARC влияет защита от спуфингов и настройка политики DMARC исходного домена (p=quarantine или p=reject в записи DMARC TXT), см. в разделе Защита от подделки и политики DMARC отправителя.
  • Индикаторы отправителей без проверки подлинности. Доступны в разделе Советы по безопасности & индикаторы , только если включена подделательная аналитика. Дополнительные сведения см. в следующем разделе.

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

Защита от подделки и политики DMARC отправителя

В политиках защиты от фишинга можно контролировать p=quarantinep=reject соблюдение значений или в политиках DMARC отправителя. Если сообщение не проходит проверку DMARC, можно указать отдельные действия для p=quarantine или p=reject в политике DMARC отправителя. Используются следующие параметры:

  • Соблюдайте политику записей DMARC при обнаружении сообщения как поддела. Этот параметр включает соблюдение политики DMARC отправителя при явных сбоях проверки подлинности электронной почты. Если этот параметр выбран, доступны следующие параметры:

    • Если сообщение обнаружено как подделаное, а политика DMARC задана как p=карантин: доступные действия:
      • Поместить сообщение в карантин
      • Перемещение сообщения в папки нежелательной Email получателей
    • Если сообщение обнаружено как подделаное, а политика DMARC задана как p=reject, доступны следующие действия:
      • Поместить сообщение в карантин
      • Отклонить сообщение

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

Параметры DMARC в политике защиты от фишинга.

Связь между спуфингом аналитики и тем, соблюдаются ли политики DMARC отправителя, описана в следующей таблице:

  Включено соблюдение политики DMARC Выкл. политика "Соблюдать DMARC"
Включено спуфинга аналитики Отдельные действия при неявных и явных сбоях проверки подлинности по электронной почте:
  • Неявные сбои. Используйте параметр Если сообщение обнаружено как подделающее действие спуфинга в политике защиты от фишинга.
  • Явные сбои:
    • Политика p=quarantineDMARC. Используйте параметр Если сообщение обнаружено как спуфинго, а политика DMARC настроена как действие p=карантина в политике защиты от фишинга.
    • Политика p=rejectDMARC. Используйте параметр Если сообщение обнаружено как спуфинго, а политика DMARC настроена как действие p=reject в политике защиты от фишинга.
    • Политика p=noneDMARC: Microsoft 365 не применяет никаких действий, но другие функции защиты в стеке фильтрации по-прежнему могут реагировать на сообщение.
Если сообщение обнаружено как подделаное действием спуфинга в политике защиты от фишинга, используется для неявных и явных ошибок проверки подлинности электронной почты. Явные сбои проверки подлинности по электронной почте игнорируют p=quarantine, p=reject, p=noneили другие значения в политике DMARC.
Спуфинговая аналитика выкл. Неявные проверки проверки подлинности по электронной почте не используются.

Явные сбои проверки подлинности электронной почты:
  • Политика p=quarantineDMARC. Используйте параметр Если сообщение обнаружено как спуфинго, а политика DMARC настроена как действие p=карантина в политике защиты от фишинга.
  • Политика p=rejectDMARC. Используйте параметр Если сообщение обнаружено как спуфинго, а политика DMARC настроена как действие p=reject в политике защиты от фишинга.
  • Политика p=noneDMARC. Microsoft 365 не определяет сообщение как спуфинго, но другие функции защиты в стеке фильтрации по-прежнему могут работать с сообщением.
Неявные проверки проверки подлинности по электронной почте не используются.

Явные сбои проверки подлинности электронной почты:
  • Политика p=quarantineDMARC: сообщения помещаются в карантин.
  • Политика p=rejectDMARC: сообщения помещаются в карантин.
  • Политика p=noneDMARC: Microsoft 365 не применяет никаких действий, но другие функции защиты в стеке фильтрации по-прежнему могут реагировать на сообщение.

Примечание.

Если запись MX для домена Microsoft 365 указывает на стороннюю службу или устройство, которое находится перед Microsoft 365, параметр политики Honor DMARC применяется только в том случае, если для соединителя, получающего входящие сообщения, включена расширенная фильтрация для соединителей .

Клиенты могут переопределить параметр политики Honor DMARC для определенных сообщений электронной почты и (или) отправителей, используя следующие методы:

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

Индикаторы отправителей без проверки подлинности

Индикаторы отправителей без проверки подлинности являются частью параметров спуфинга, доступных в разделе Советы по безопасности & индикаторы политик защиты от фишинга в EOP и Defender для Office 365. Следующие параметры доступны только в том случае, если включен подделанный интеллект:

  • Показать (?) для не прошедших проверку подлинности отправителей для подделки. Добавляет вопросительный знак на фотографию отправителя в поле От, если сообщение не проходит проверки SPF или DKIM и сообщение не проходит DMARC или составную проверку подлинности. Если этот параметр отключен, вопросительный знак не добавляется на фотографию отправителя.

  • Показать тег via. Добавляет тег via (chris@contoso.comчерез fabrikam.com) в поле From, если домен в адресе From (отправитель сообщения, отображаемый в почтовых клиентах) отличается от домена в подписи DKIM или адреса MAIL FROM . Дополнительные сведения об этих адресах см. в статье Общие сведения о стандартах сообщений электронной почты.

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

Дополнительные сведения см. в статье Определение подозрительных сообщений в Outlook.com и Outlook в Интернете

Совет по безопасности первого контакта

Параметр Показать первый совет по безопасности контакта доступен в EOP и Defender для Office 365 организациях и не зависит от параметров интеллектуальной аналитики или олицетворения. Подсказка по безопасности отображается получателям в следующих сценариях:

  • При первом получении сообщения от отправителя
  • Они не часто получают сообщения от отправителя.

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

Первая подсказка безопасности контакта управляется значением 9,25 SFTY поля в заголовке X-Forefront-Antispam-Report сообщения. Эта функция заменяет необходимость создания правил потока обработки почты (также известных как правила транспорта), которые добавляют заголовок С именем X-MS-Exchange-EnableFirstContactSafetyTip значением Enable для сообщений, хотя эта возможность по-прежнему доступна.

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

  • Один получатель:

    Вы не часто получаете электронную почту с <адреса> электронной почты.

    Совет по безопасности первого контакта для сообщений с одним получателем

  • Несколько получателей:

    Некоторые пользователи, получившие это сообщение, не часто получают сообщения электронной почты с <адреса> электронной почты.

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

Примечание.

Если сообщение имеет несколько получателей, отображается ли подсказка и кому она основана на модели большинства. Если большинство получателей никогда или не часто получают сообщения от отправителя, затронутые получатели получат подсказку Некоторые пользователи, которые получили это сообщение... . Если вы обеспокоены тем, что такое поведение передает привычки общения одного получателя другому, не следует включать первый совет по безопасности контакта и продолжать использовать правила потока обработки почты и заголовок X-MS-Exchange-EnableFirstContactSafetyTip .

Первый совет по безопасности контакта не помечается в подписанных сообщениях S/MIME.

Эксклюзивные параметры в политиках защиты от фишинга в Microsoft Defender для Office 365

В этом разделе описываются параметры политики, доступные только в политиках защиты от фишинга в Defender для Office 365.

Примечание.

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

Параметры олицетворения в политиках защиты от фишинга в Microsoft Defender для Office 365

Олицетворение — это то, что отправитель или домен электронной почты отправителя в сообщении выглядит как настоящий отправитель или домен:

  • Пример олицетворения домена contoso.com – ćóntoso.com.
  • Олицетворение пользователя — это сочетание отображаемого имени пользователя и адреса электронной почты. Например, Валерия Барриос (vbarrios@contoso.com) может быть олицетворением Валерия Барриос, но с другим адресом электронной почты.

Примечание.

Защита олицетворения ищет похожие домены. Например, если ваш домен является contoso.com, мы проверка для разных доменов верхнего уровня (.com, .biz и т. д.), но и доменов, которые даже несколько похожи. Например, contosososo.com или contoabcdef.com могут рассматриваться как попытки олицетворения contoso.com.

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

Параметры олицетворения, описанные в следующих разделах, доступны только в политиках защиты от фишинга в Defender для Office 365.

Защита олицетворения пользователя

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

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

Примечание.

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

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

Если вы попытаетесь добавить пользователя в защиту олицетворения пользователя, если этот адрес электронной почты уже указан для защиты от олицетворения пользователя в другой политике защиты от фишинга, может появиться сообщение об ошибке "Адрес электронной почты уже существует". Эта ошибка возникает только на портале Defender. Вы не получите ошибку, если используете соответствующий параметр TargetedUsersToProtect в командлетах New-AntiPhishPolicy или Set-AntiPhishPolicy в Exchange Online PowerShell.

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

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

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

Защита олицетворения домена

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

Примечание.

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

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

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

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

Защита олицетворения аналитики почтовых ящиков

Аналитика почтовых ящиков использует искусственный интеллект (ИИ) для определения шаблонов электронной почты пользователей с их частыми контактами.

Например, Габриэла Лауреано (glaureano@contoso.com) является генеральным директором вашей компании, поэтому вы добавляете ее в качестве защищенного отправителя в параметрах включить защиту пользователей политики. Но некоторые получатели в политике регулярно общаются с поставщиком, который также называется Габриэла Лауреано (glaureano@fabrikam.com). Так как эти получатели имеют журнал связи с glaureano@fabrikam.com, аналитика почтовых ящиков не определяет сообщения из glaureano@fabrikam.com как попытку glaureano@contoso.com олицетворения для этих получателей.

Примечание.

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

Аналитика почтовых ящиков имеет два конкретных параметра:

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

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

  • Не применяйте никаких действий: это значение по умолчанию. Это действие имеет тот же результат, что и при включенном включении функции Включить аналитику почтовых ящиков, но отключена защита от олицетворения.
  • Перенаправление сообщения на другие адреса электронной почты
  • Перемещение сообщения в папки нежелательной Email получателей
  • Карантин сообщения. Если выбрано это действие, можно также выбрать политику карантина, которая применяется к сообщениям, помещенным в карантин с помощью защиты аналитики почтовых ящиков. Политики карантина определяют, что пользователи могут делать с сообщениями в карантине, и получают ли пользователи уведомления о карантине. Дополнительные сведения см. в разделе Анатомия политики карантина.
  • Добавьте сообщение и добавьте другие адреса в строку ск.
  • Удаление сообщения перед его доставкой

Советы по безопасности олицетворения

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

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

    Этот совет по безопасности управляется значением 9,20 SFTY поля в заголовке X-Forefront-Antispam-Report сообщения. В тексте говорится:

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

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

    Этот совет по безопасности управляется значением 9,19 SFTY поля в заголовке X-Forefront-Antispam-Report сообщения. В тексте говорится:

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

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

    Адрес <email address> электронной почты содержит непредвиденные буквы или цифры. Рекомендуется не взаимодействовать с этим сообщением.

Примечание.

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

  • Сообщения, подписанные S/MIME.
  • Сообщения, разрешенные параметрами организации.

Доверенные отправители и домены

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

Примечание.

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

Если системные сообщения Microsoft 365 от следующих отправителей идентифицируются как попытки олицетворения, вы можете добавить отправителей в список доверенных отправителей:

  • noreply@email.teams.microsoft.com
  • noreply@emeaemail.teams.microsoft.com
  • no-reply@sharepointonline.com

Расширенные пороговые значения фишинга в политиках защиты от фишинга в Microsoft Defender для Office 365

Следующие расширенные пороговые значения фишинга доступны только в политиках защиты от фишинга в Defender для Office 365. Эти пороговые значения определяют конфиденциальность при применении моделей машинного обучения к сообщениям для определения фишингового вердикта:

  • 1 — стандартный. Это значение по умолчанию. Серьезность действия, выполняемого с сообщением, зависит от степени уверенности в том, что сообщение является фишинговым (низкая, средняя, высокая или очень высокая достоверность). Например, к сообщениям, которые определены как фишинг с очень высокой степенью достоверности, применяются самые серьезные действия, в то время как сообщения, которые определены как фишинг с низкой степенью достоверности, применяются менее серьезные действия.
  • 2 — агрессивные: сообщения, которые определены как фишинговые с высокой степенью достоверности, обрабатываются так, как если бы они были идентифицированы с очень высокой степенью достоверности.
  • 3 . Более агрессивные: сообщения, которые определены как фишинг со средней или высокой степенью достоверности, обрабатываются так, как если бы они были идентифицированы с очень высокой степенью достоверности.
  • 4 . Наиболее агрессивные: сообщения, которые определены как фишинг с низкой, средней или высокой степенью достоверности, обрабатываются так, как если бы они были идентифицированы с очень высокой степенью достоверности.

Вероятность ложноположительных результатов (хорошие сообщения, помеченные как плохие) увеличивается по мере увеличения этого параметра. Сведения о рекомендуемых параметрах см. в разделе Параметры политики защиты от фишинга в Microsoft Defender для Office 365.