Как подготовить компанию к фишинг-симуляции: чек-лист заказчика

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

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

Сформулируйте проверяемый вопрос

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

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

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

Назначьте людей, которые могут принять решение

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

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

Соберите аудиторию без лишних данных

Список участников должен соответствовать задаче. Общие ящики, сервисные учётные записи и люди, которые не участвуют в проверке, не стоит автоматически смешивать с персональными адресами сотрудников.

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

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

Проверьте готовность по таблице

Что подготовить	Кто обычно участвует	Что должно быть понятно к запуску
Цель проверки	Руководитель и ИБ	Какой вопрос решаем
Участники и исключения	ИБ, HR, руководители групп	Кого учитываем в результатах
Границы действий	Ответственный заказчика и исполнитель	Что разрешено и что исключено
Окно проведения	Ответственный, IT	Когда проходит проверка
Контакт для остановки	Ответственный заказчика	Кто и как принимает решение
Учёт событий	ИБ и исполнитель	Что считаем кликом, вводом и сообщением
Работа с данными	Уполномоченные специалисты компании	Состав, доступ, передача и срок хранения
Канал сообщения	ИБ или служба поддержки	Куда сотрудник сообщает о подозрении
Обучение	ИБ, HR, руководители	Как будет организован разбор
Итоговый отчёт	Руководитель и ИБ	Какие разделы и ограничения нужны

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

Определите, как будут трактоваться действия

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

Формулировка «процент кликнувших» тоже требует определения. Это уникальные люди от числа доставленных писем или другое отношение? Как учитывается сотрудник, который сначала перешёл, а потом сообщил в ИБ? Такие категории могут пересекаться.

Для сравнения волн нужно сохранить информацию о сложности сценария. NIST Phish Scale предлагает способ учитывать сложность распознавания письма при интерпретации результатов. Сам по себе одинаковый размер аудитории ещё не делает две проверки сопоставимыми.

Подготовьте завершение проекта заранее

После рассылки сотрудникам потребуется объяснение, а руководителю — план действий. Зарезервируйте время на разбор и определите, кто организует обучение. Без этого проект легко заканчивается пересылкой отчёта между отделами.

Хороший финальный вопрос: «Кто возьмёт в работу каждую рекомендацию?» Если ответов пока нет, их полезно обсудить ещё на старте. Тогда отчёт станет основой конкретных изменений.