В регламенте следует прописать следующие процедуры:

● Определение направления (вектора) фишинговой атаки. Векторами могут стать классический e-mail-канал, корпоративные и общедоступные мессенджеры, браузерные атаки с вовлечением пользователя (ClickFix и аналоги), QR-коды (квишинг), а также иные сценарии социальной инженерии, включая физический подброс зараженных носителей.

● Анализ затронутых ресурсов. На основании выявленного вектора исследуются системные журналы и данные SIEM-системы — с целью обнаружения потенциально скомпрометированных активов. Ими могут быть серверы баз данных, рабочие станции, облачные хранилища и иные элементы инфраструктуры. При подтверждении факта компрометации затронутые ресурсы необходимо изолировать — для предотвращения латерального перемещения злоумышленника.

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

В регламенте следует прописать следующие процедуры:

Цель: минимизировать последствия инцидента и оперативно восстановить процессы.

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

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

Несколько сложнее, но также решаемо — выявить всех жертв при фишинге в групповых чатах мессенджеров. Если пострадавших сотрудников установить невозможно, необходимо предупредить персонал через каналы корпоративной коммуникации. Один из основных инструментов ИБ-службы при выявлении перешедших сотрудников — анализ фишинговой ссылки через корпоративное сетевое оборудование по логам прокси, SIEM и почтового шлюза: кто и когда переходил.

Дальнейшие действия зависят от типа компрометации:

1.) Ввод данных в формы (компрометация учетных данных)

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

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

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

2.) Скачивание подозрительного файла (заражение устройства)

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

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

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

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

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

Цель: предотвратить подобные инциденты в будущем.

● Документирование инцидента. Необходимо составить отчет с указанием времени, действий команды, нанесенного ущерба и принятых мер. Если произошла утечка персональных данных — уведомить регулятора в соответствии с 152-ФЗ.

● Анализ первопричин (Root Cause Analysis). Почему атака увенчалась успехом? Причина могла быть в недостаточной осведомленности сотрудника, отсутствии у него двухфакторной аутентификации (MFA), а также в некорректных настройках почтового шлюза, позволяющих подделывать домен отправителя и пропускать фишинговые письма в контур.

● Обновление политик. По итогам разбора в политики безопасности вносятся изменения: новые правила блокировки (например, добавление вредоносных доменов и IP-адресов в черные списки), доработанные настройки почтового шлюза, внедрение MFA для критичных систем.

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