Защита корпоративной почты от фишинга: как сравнить решения

С чего начинается проблема: фишинг и потери от ошибок фильтра

Фишинг редко выглядит как явная подделка. Чаще это обычное письмо: счет, просьба «проверить доступ», уведомление от банка или «срочное» сообщение от руководителя. Даже при настроенной защите корпоративной почты часть атак все равно просачивается. Злоумышленники подстраиваются под ваши процессы и стиль переписки.

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

Не менее опасна обратная сторона: ложные срабатывания. Когда фильтр блокирует нормальные письма или отправляет их в карантин, бизнес платит дважды. Срываются дедлайны, поставщики не получают ответы, продажи теряют заявки, бухгалтерия не видит счета, а IT тратит время на ручную разборку. Со временем люди перестают доверять защите и ищут обходные пути: пересылают на личную почту, просят «отпустить письмо», игнорируют предупреждения.

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

Обычно компании выбирают один из подходов: специализированные почтовые шлюзы или облачные фильтры, встроенная защита в экосистеме Microsoft (Microsoft Defender for Office 365) или комбинированная схема с несколькими слоями.

Сравнение стоит начинать не с «у кого больше функций», а с цены ошибки: сколько стоит один пропущенный фишинг и сколько стоит одно лишнее ложное срабатывание в вашей ежедневной переписке.

Подходы к защите почты: шлюз, облако и встроенные средства

Защита корпоративной почты от фишинга чаще всего строится одним из трех способов: отдельный шлюз перед вашей почтой, облачный сервис, который встраивается в поток писем, или средства самой почтовой платформы (например, Microsoft Defender for Office 365 для Microsoft 365).

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

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

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

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

Чтобы сравнение было корректным, уравняйте то, что можно уравнять: одинаковые тестовые письма, одинаковые политики карантина, одинаковый список доверенных отправителей и одинаковый процесс «разблокировать по запросу». Качество при этом все равно зависит от вашей среды: доля внешней переписки, типы пользователей, используемые клиенты (Outlook, мобильные), привычки сотрудников (например, пересылка счетов и сканов).

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

Как подготовить честное сравнение решений

Честное сравнение начинается с договоренностей. Иначе пилот быстро превращается в спор вкусов: одному важно «чтобы ничего не пропускало», другому - «чтобы не мешало работать». В защите почты обе цели важны, но их нужно заранее разложить на измеримые критерии.

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

Заранее зафиксируйте рамки теста:

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

Выберите период так, чтобы увидеть разные сценарии. Обычно 2-6 недель хватает, чтобы поймать «обычную» почту, пики рассылок и несколько реальных попыток фишинга. Пилот на пару дней часто дает красивую статистику, которая разваливается на первой рабочей неделе.

Назначьте роли и правила решения спорных случаев:

• ИБ задает критерии риска, приоритеты и итоговую оценку.
• Почтовые админы отвечают за маршрутизацию, политики и журналирование.
• Service Desk принимает обращения пользователей и делает первичную классификацию.
• Владельцы бизнес-процессов подтверждают, что важные письма не ломают работу.

Простой пример: финансы жалуются, что «пропали счета от поставщика». Без владельца процесса вы не поймете, это допустимая задержка ради безопасности или недопустимый простой, который нужно компенсировать правилами и понятным процессом разбора.

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

Тестовый набор должен быть похож на реальный поток. Иначе решения покажут «красивые» результаты на искусственных примерах, а в живой работе появятся сюрпризы.

Соберите письма за одинаковый период (например, 2-4 недели) и из разных подразделений. В набор обычно стоит включить входящую почту от внешних отправителей, внутреннюю переписку, исходящие письма (чтобы увидеть, что ломается из-за правил), массовые уведомления и «бизнес-критичные» шаблоны: счета, акты, КП, логистику.

Дальше самое важное - конфиденциальность. Хранить содержимое в открытом виде не нужно. Сохраните смысловые признаки, а данные обезличьте:

• замените ФИО, телефоны, ИИН, номера договоров на нейтральные маски;
• оставьте тему письма, тип вложения (PDF, DOCX, ZIP) и размер;
• сохраните домен отправителя и цепочку пересылок, но уберите локальную часть адреса;
• зафиксируйте наличие ссылок и их домены, не сохраняя персональные параметры.

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

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

Метрики: как измерить false positive и false negative

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

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

Дальше определите, что считается false positive. Ошибка - это не «письмо не понравилось пользователю», а письмо, которое по вашей политике должно было быть доставлено без ущерба бизнесу. Полезно сразу разбить ошибки по источникам и типам: госорганы, банки, поставщики, внутренние уведомления, сервисные рассылки.

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

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

Пошаговый план пилота на реальном трафике

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

Начните с безопасного формата: параллельный режим (письма доставляются, но дополнительно анализируются вторым решением) или пилотная группа. Для пилота обычно достаточно 5-10% сотрудников, где есть типичные сценарии: бухгалтерия, закупки, HR, IT и руководство.

Дальше держитесь простого плана:

1. Включите параллельный режим или пилотную группу так, чтобы основной поток не ломался для всей компании.
2. Настройте максимально одинаковые политики: спам, фишинг, вложения, ссылки, карантин, уведомления. Где одинаковости нет, зафиксируйте различия письменно.
3. Определите эскалацию: кто принимает решение «разблокировать или нет» и за сколько времени. Для писем на финансы и кадры полезно заранее задать более строгий порядок.
4. Каждый день снимайте статистику и собирайте примеры: что попало в карантин, что было пропущено, на что жаловались пользователи. Сохраняйте не только числа, но и несколько реальных писем для разбора.
5. Раз в неделю проводите калибровку: исправляйте правила по найденным ошибкам и проверяйте, не ухудшили ли вы другие метрики.

Практический пример: бухгалтер получает «счет от поставщика» с вложением. Решение A отправило письмо в карантин, решение B пропустило, сотрудник пожаловался в IT. По процессу это письмо в течение часа смотрит ИБ, сверяет отправителя и цепочку переписки, решает, можно ли выпускать, и фиксирует причину в журнале пилота.

Процесс расследований: от репорта сотрудника до закрытия инцидента

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

Единый вход для сообщений

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

Когда репорт пришел, соберите данные сразу, пока письмо не удалили и ссылки не «протухли». Минимальный набор, который обычно закрывает большую часть вопросов:

• полные заголовки письма (headers) и исходник (eml);
• вложения в оригинале (без открытия);
• все URL из письма (включая кнопки);
• короткий скрин и описание: «что просили сделать»;
• бизнес-контекст: ожидаемый ли это счет, кто «отправитель» по версии сотрудника.

Стандартные решения и фиксация причины

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

Отдельно ведите базу решений: почему письмо признали фишингом или легитимным, какие признаки сработали, и 1-2 примера для обучения. Это снижает споры между ИБ и бизнесом и ускоряет разбор повторяющихся случаев.

Чтобы сократить ручной труд, заранее настройте шаблоны ответов и очереди (например, «финансы», «кадры», «IT»), а также уровни приоритета. Письмо «от директора» с просьбой срочно оплатить счет должно проверяться быстрее, чем внешняя маркетинговая рассылка.

Частые ошибки при сравнении Proofpoint, Barracuda и Defender

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

Вторая ловушка - желание любой ценой снизить жалобы пользователей на «лишние блокировки». Когда в пилоте начинают массово добавлять отправителей и домены в allow list, фильтр быстро теряет смысл. Да, false positive падает, но вместе с ним падает и реальная защита.

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

Что чаще всего портит результаты пилота

• разные правила и разные режимы (карантин, «пометить», «удалить») для каждого решения;
• слишком много исключений ради спокойствия пользователей;
• оценка «сколько заблокировано» без проверки, были ли это реальные угрозы;
• тест только на внешней почте без типовых легитимных потоков: счета, HR-рассылки, тендеры, внутренние уведомления;
• не назначены роли: кто может разблокировать письмо, кто подтверждает риск и какие причины считаются допустимыми.

Пример, где сравнение ломается

Финансовый отдел получает счет от поставщика с вложением, а параллельно приходит фишинг под «IT-службу» с просьбой срочно «обновить пароль». Если в пилоте исключили домен поставщика целиком, счет всегда пройдет. Но вместе с ним может пройти и подмена через похожий домен или компрометированную почту.

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

Короткий чеклист перед выбором решения

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

Опишите цели пилота в цифрах. Например: «снизить долю пропущенных фишинговых писем в 2 раза» и «держать блокировки легитимных писем не выше 0,1% для счетов, договоров и писем от госорганов». Без границ любая команда в конце скажет, что результат «в целом нормальный».

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

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

На выходе у вас должен быть понятный набор артефактов:

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

Если хотя бы один пункт «плавает», пилот почти всегда заканчивается спором, а не выбором.

Пример сценария: счет от поставщика и фишинг под IT-службу

Понедельник, утро. Бухгалтерия жалуется, что «пропали счета»: поставщик отправил инвойсы, но часть писем не дошла. Почти одновременно несколько сотрудников получают письмо якобы от IT-службы: «Срок действия пароля истек, обновите пароль по ссылке». Это типичная ситуация, где защита должна быть точной, но не мешать работе.

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

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

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

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

Итог удобнее оформлять не как спор «кто победил», а как список изменений процесса: на каких условиях делаются исключения для счетов, какие правила усиливаются для писем «от IT», как сотрудники репортят подозрительные письма, какие уведомления и предупреждения стоит переписать, чтобы люди их не игнорировали.

Что делать дальше: внедрение, контроль качества и поддержка

После пилота зафиксируйте результаты так, чтобы их одинаково понял бизнес, IT и ИБ. Самый практичный формат - одна таблица с метриками (false positive и false negative), примерами писем, на которых решения ошибались, и трудозатратами: сколько времени ушло на разбор, настройку исключений и общение с пользователями.

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

Зафиксируйте регламенты, чтобы не «лечить» инциденты вручную каждый раз:

• как обрабатывается карантин и кто может выпускать письма;
• как оформляются исключения и когда они пересматриваются;
• сроки реакции на репорт сотрудника и на массовую рассылку;
• как вы объясняете бизнесу блокировки и причины;
• как ведется журнал изменений: что меняли, почему и какой был эффект.

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

Если вы хотите провести пилот «на ваших письмах» и не тратить недели на организационные детали, это часто отдают системному интегратору. Например, GSE.kz (gse.kz) помогает спроектировать и внедрить ИТ и ИБ-решения, настроить процессы расследований и организовать дальнейшую поддержку, включая круглосуточное сопровождение через сервисную сеть.