HADI: как методика из маркетинга превратилась в рабочий инструмент для борьбы с фишингом

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

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

Где стандартные тренинги по информационной безопасности дают сбой

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

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

Как применяется HADI в задачах информационной безопасности

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

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

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

Как формулировать гипотезы для симуляций

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

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

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

Как проверять гипотезы на практике

После формулирования гипотезы ИБ‑команда разрабатывает сценарий для ее проверки. Он должен имитировать реальный инцидент: канал коммуникации, формат взаимодействия с ним и возможные варианты действий у пользователя.

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

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

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

Какие данные показывают реальную уязвимость

Результаты симуляции показывают уровень устойчивости компании к фишинговым атакам. Ввод учетных данных на поддельных сайтах или открытие подозрительных вложений делает пользователя уязвимым. А сообщение о сомнительной активности, наоборот, показывает, что инцидент распознан и передан в службу безопасности. По данным Бастиона, около 16% сотрудников переходят по фишинговым ссылкам и лишь 1% сообщает о потенциально опасных письмах в ИБ‑службу. При этом именно сигналы от пользователей позволяют быстрее выявлять атаки. Обученной команде в среднем требуется около 30 минут, чтобы распознать инцидент и запустить реагирование. Без такой обратной связи системы защиты большинства организаций остаются фактически слепыми к подобным происшествиям.

Как превратить информацию в решения

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

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

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

От экспериментов к управляемой системе

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

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

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