Защита от фишинга: как защитить компанию и сотрудников

По данным Microsoft Digital Defense Report 2025, 28% расследованных Microsoft взломов начинались с фишинга или социальной инженерии.

Например, весной 2025 года злоумышленники получили доступ к системам Marks & Spencer. Они представились сотрудником подрядчика и добились сброса учетных данных через службу поддержки. 

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

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

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

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

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

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

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

В апреле 2026 года Microsoft зафиксировала фишинговую кампанию, которая затронула более 35 000 пользователей в 13 000 компаний. 

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

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

Отдельный признак — несоответствие канала запросу. 

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

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

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

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

Сообщите в ИБ или ИТ. Это может быть кнопка для отправки подозрительных писем, отдельный адрес, чат или заявка — конкретный способ компания определяет заранее.

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

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

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

Защита от фишинга строится на четырех направлениях:

Технические меры → снижают число атак и ограничивают последствия
Правила и процессы → задают порядок проверки и реагирования
Обучение сотрудников → отрабатывает действия в рабочих ситуациях
Имитированные атаки → проверяют поведение и показывают, где нужны следующие меры

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

Для корпоративной защиты:

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

Для почты, VPN, SSO и административных учетных записей выбирайте способы входа, устойчивые к фишингу, например аппаратные ключи и ключи доступа.

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

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

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

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

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

В полевом эксперименте участвовали 363 сотрудника четырех компаний. Одна группа прошла стандартное обучение по политикам ИБ, а в других к тем же правилам добавили объяснение угроз и возможных последствий нарушения. После обучения исследователи провели фишинговую проверку: по ссылке перешли 34% сотрудников из контрольной группы и 17% и 25% — из групп с дополненным обучением.

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

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

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

В статье о теории защитной мотивации мы рассказывали об исследовании, где сотрудников дважды проверяли с помощью фишинговых писем. После первой проверки участники получали обратную связь. Во второй доля тех, кто снова допустил опасное действие, снизилась с 50 до 40%, а доля сотрудников, которые сначала проигнорировали письмо, а при повторной проверке сообщили о нем в ИБ, выросла с 7 до 10%.

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

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

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

Поэтому результат защиты лучше оценивать по нескольким показателям:

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

Метрики становятся полезными, когда по ним понятно, какое решение принять. 

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

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

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

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

Запишитесь на бесплатное демо — покажем, как это работает на ваших сценариях.

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

Если перешел по ссылке

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

Если ввел учетные данные

Сразу передайте информацию в ИБ. Пароль нужно сменить, активные сессии — завершить. Также стоит проверить способы подтверждения входа, почтовые правила и выданные приложениям доступы: смены пароля может быть недостаточно, если злоумышленник уже закрепился в учетной записи.

Если ввел платежные данные

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

Если открыл или запустил файл

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

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