Миграция на Microsoft Defender для Office 365 — этап 3. Подключение

Область применения


Этап 1. Подготовка.
Этап 1. Подготовка
Этап 2. Настройка.
Этап 2. Настройка
Этап 3. Подключение.
Этап 3. Подключение
Вы здесь!

Добро пожаловать в этап 3. Адаптациямиграции к Microsoft Defender для Office 365! Этот этап миграции включает в себя следующие шаги.

  1. Начало подключения команд безопасности
  2. (Необязательно) Освобождение пользователей пилотного проекта от фильтрации по существующей службе защиты
  3. Настройка спуфинга аналитики
  4. Настройка защиты олицетворения и аналитики почтовых ящиков
  5. Использование данных из сообщений, сообщаемого пользователем, для измерения и настройки
  6. (Необязательно) Добавление дополнительных пользователей в пилотный проект и итерации
  7. Расширение защиты Microsoft 365 для всех пользователей и отключение правила потока обработки почты SCL=-1
  8. Переключение записей MX

Шаг 1. Начало подключения команд безопасности

Если в вашей организации есть группа реагирования на вопросы безопасности, пришло время начать интеграцию Microsoft Defender для Office 365 в процессы реагирования, включая системы обработки запросов. Это целая тема сама по себе, но иногда ее упускают из виду. Заблаговременное привлечение группы реагирования на вопросы безопасности обеспечит готовность вашей организации к борьбе с угрозами при переключении записей MX. Реагирование на инциденты должно быть хорошо подготовлено для выполнения следующих задач:

Если ваша организация приобрела Microsoft Defender для Office 365 план 2, ей следует начать знакомство с такими функциями, как Обозреватель угроз, Расширенная охота и Инциденты. Соответствующие учебные материалы см. в разделе https://aka.ms/mdoninja.

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

SIEM/SOAR

Дополнительные сведения об интеграции с SIEM/SOAR см. в следующих статьях:

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

Роли RBAC

Разрешения в Defender для Office 365 основаны на управлении доступом на основе ролей (RBAC) и описаны в разделе Разрешения на портале Microsoft 365 Defender. Следует помнить о следующих важных моментах:

  • Azure AD роли предоставляют разрешения для всех рабочих нагрузок в Microsoft 365. Например, если добавить пользователя к администратору безопасности в портал Azure, он будет иметь разрешения администратора безопасности везде.
  • & Email роли совместной работы на портале Microsoft 365 Defender предоставляют разрешения порталу Microsoft 365 Defender и Портал соответствия требованиям Microsoft Purview. Например, если вы добавите пользователя в администратор безопасности на портале Microsoft 365 Defender, он имеет доступ к администратору безопасности только на портале Microsoft 365 Defender и Портал соответствия требованиям Microsoft Purview.
  • Многие функции портала Microsoft 365 Defender основаны на командлетах PowerShell Exchange Online и поэтому требуют членства в соответствующих ролях (технически, группах ролей) в Exchange Online (в частности, для доступа к соответствующей Exchange Online). Командлеты PowerShell).
  • На портале Microsoft 365 Defender есть Email & роли совместной работы, которые не имеют эквивалента Azure AD ролям и важны для операций безопасности (например, роль предварительного просмотра и роли "Поиск и очистка").

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

Шаг 2. (Необязательно) Освобождение пользователей пилотного проекта от фильтрации по существующей службе защиты

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

Примечание.

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

Шаг 3. Настройка спуфинга аналитики

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

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

  • Источники сообщений, которые находятся за пределами диапазонов IP-адресов, определенных в разделе Расширенная фильтрация для соединителей.
  • Источники сообщений с наибольшим количеством сообщений.
  • Источники сообщений, которые оказывают наибольшее влияние на вашу организацию.

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

Шаг 4. Настройка защиты олицетворения и аналитики почтовых ящиков

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

  • Защита олицетворения пользователя. Сообщение помещалось в карантин как для стандартных, так и для строгих.
  • Защита олицетворения домена. В карантине сообщение будет помещено в режим "Стандартный" и "Строгий".
  • Защита аналитики почтовых ящиков: перемещение сообщения в папки нежелательной Email получателей для стандартного; Поместите сообщение в карантин в строгом режиме.

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

Примечание.

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

Настройка аналитики почтовых ящиков

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

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

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

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

Сведения об изменении политик см. в статье Настройка политик защиты от фишинга в Defender для Office 365.

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

Настройка защиты олицетворения пользователя

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

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

Сведения об изменении политик см. в статье Настройка политик защиты от фишинга в Defender для Office 365.

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

Настройка защиты олицетворения домена

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

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

Сведения об изменении политик см. в статье Настройка политик защиты от фишинга в Defender для Office 365.

Наблюдайте за результатами и при необходимости вносите любые корректировки.

Шаг 5. Использование данных из сообщений, сообщаемого пользователем, для измерения и настройки

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

Используйте следующие функции для мониторинга и итерации параметров защиты в Defender для Office 365:

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

Шаг 6. (Необязательно) Добавление дополнительных пользователей в пилотный проект и выполнение итерации

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

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

    • Переопределяет в отчете о состоянии защиты от угроз.
    • Фильтр в обозревателе угроз для идентификации сообщений.
    • Фильтр в разделе Расширенная охота для идентификации сообщений.

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

  • Также рекомендуется изучить ненужные переопределения. Иными словами, посмотрите на вердикты, которые Microsoft 365 предоставила бы в сообщениях. Если Microsoft365 вынес правильный вердикт, то потребность в переопределении значительно уменьшается или устраняется.

Шаг 7. Расширение защиты Microsoft 365 для всех пользователей и отключение правила потока обработки почты SCL=-1

Выполните действия, описанные в этом разделе, когда вы будете готовы переключить записи MX на Microsoft 365.

  1. Распространение пилотных политик на всю организацию. По сути, это можно сделать разными способами:

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

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

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

  2. Отключите правило потока обработки почты SCL=-1 (его можно отключить, не удаляя).

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

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

Шаг 8. Переключение записей MX

Примечание.

  • При переключении записи MX для домена может потребоваться до 48 часов для распространения изменений в Интернете.
  • Мы рекомендуем снизить значение TTL записей DNS, чтобы обеспечить более быстрый ответ и возможный откат (при необходимости). Вы можете вернуться к исходному значению срока жизни после завершения переключения и проверки.
  • Рекомендуется начать с изменения доменов, которые используются реже. Перед переходом на более крупные домены можно приостановить и отслеживать. Однако даже в этом случае следует убедиться, что все пользователи и домены охвачены политиками, так как вторичные домены SMTP разрешаются в первичные домены до применения политики.
  • Несколько записей MX для одного домена технически будут работать, что позволяет использовать разделенную маршрутизацию при условии, что вы выполнили все рекомендации, приведенные в этой статье. В частности, следует убедиться, что политики применяются ко всем пользователям, что правило потока обработки почты SCL=-1 применяется только к почте, которая проходит через существующую службу защиты, как описано в разделе Настройка Шаг 3. Обслуживание или создание правила потока обработки почты SCL=-1. Однако в этой конфигурации реализовано поведение, которое значительно усложняет устранение неполадок, поэтому мы обычно не рекомендуем его, особенно в течение длительных периодов времени.
  • Перед переключением записей MX убедитесь, что следующие параметры не включены для входящего соединителя из службы защиты в Microsoft 365. Как правило, соединитель будет иметь один или несколько из следующих параметров:
    • и требуют, чтобы имя субъекта в сертификате, используемом партнером для проверки подлинности с помощью Office 365 соответствовало этому доменному имени (RestrictDomainsToCertificate).
    • Отклонить сообщения электронной почты, если они не отправляются из этого диапазона IP-адресов (RestrictDomainsToIPAddresses). Если тип соединителя — Partner и любой из этих параметров включен, доставка почты в домены завершится ошибкой после переключения записей MX. Перед продолжением необходимо отключить эти параметры. Если соединитель является локальным соединителем, используемым для гибридного использования, изменять локальный соединитель не требуется. Но вы по-прежнему можете проверить наличие соединителя партнера .
  • Если текущий шлюз почты также обеспечивает проверку получателя, может потребоваться убедиться, что домен настроен как полномочный в Microsoft 365. Это может предотвратить ненужную передачу сообщений.

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

Не стесняйтесь приостановить и оценить здесь в любой момент. Но помните: после отключения правила потока обработки почты SCL=-1 пользователи могут иметь два разных способа проверки ложноположительных результатов. Чем раньше вы сможете обеспечить единый и согласованный интерфейс, тем счастливее ваши пользователи и группы поддержки будут, когда им придется устранять проблемы с отсутствующим сообщением.

Дальнейшие действия

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

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