Классическая картина: компания покупает «умный» антифишинг, раз в год прогоняет всех через слайд-шоу с правилами, а через месяц сотрудник бухгалтерии всё равно вводит пароль на странице с логотипом родной компании. После этого ИБ-отдел вздыхает: «люди — слабое звено». Утверждение верно ровно наполовину. Слабое звено — не сотрудник, а процесс, который мы вокруг него выстроили: обучение ради галочки, проверки ради отчёта и технические контроли, которые снимают с человека ответственность, но не риск. Давайте разберёмся, что здесь реально работает, а что продаётся красиво.
Цифры вместо пресс-релизов
Verizon в отчёте DBIR 2024 оценивает долю инцидентов с участием человека (ошибка, невнимательность, обман) примерно в 68%. Точная цифра от года к году плавает, но порядок держится: большая часть взломов начинается не с нулевого дня, а с письма, звонка или аккуратно забытого доступа.
Дальше — типовая лестница. Кто-то переходит по ссылке и вводит корпоративный логин, и атакующему уже не нужен эксплойт: он заходит под легальной учётной записью, где его почти не отличают от обычного сотрудника. Именно поэтому скепсис к «серебряным пулям» оправдан — WAF и «антивирус с ИИ» плохо помогают против валидных учётных данных. Их надо ловить не сигнатурами, а поведением и правами доступа.
Как это ломает компании на самом деле
Фишинг и усталость от MFA
Сценарий, который в 2022 году прошёл по нескольким крупным компаниям, выглядел одинаково: пароль у злоумышленника уже был (утечка, переиспользование, подсмотренный ввод), оставалось закидать сотрудника запросами на подтверждение входа, пока он не нажмёт «Да» из раздражения. В Uber, Cisco и Twilio детали отличались, но суть одна: двухфакторная аутентификация была, а процесса реагирования на аномальные запросы — нет.
Практический вывод: сам факт «у нас включена двухфакторка» ничего не гарантирует. Работает связка «устойчивый к фишингу фактор (ключи FIDO2/WebAuthn, passkeys или хотя бы числовая сверка вместо кнопки «Подтвердить») + правила на подозрительные входы + быстрый способ убить активную сессию».
Пароли в таблицах, заметках и мессенджерах
Пока у сотрудника нет нормального менеджера паролей, он будет хранить их там, где удобно: в Excel на сетевой шаре, в стикерах, в переписке с коллегой. Это не злая воля — это рациональное поведение в отсутствие инструмента. Прежде чем требовать «сложные уникальные пароли», дайте место, где их можно безопасно держать, и уберите лишние системы из контура, чтобы паролей было меньше.
Личные аккаунты на рабочем устройстве
Синхронизация личного браузера или мессенджера на корпоративном ноутбуке убивает границу периметра. Один из разборов инцидента в Cisco как раз начинался с того, что корпоративные учётные данные оказались синхронизированы с личным профилем браузера. Лечится не запретами, а разделением: отдельный браузерный профиль, запрет личных аккаунтов на managed-устройствах, MDM и понятное исключение «если нужно личное — вот виртуалка».
Макросы, архивы и «документ из налоговой»
Вложения с макросами и паролями на архивах остаются рабочей схемой не потому, что она изящна, а потому, что дешёвая. Защита здесь техническая и скучная: макросы из интернета по умолчанию блокируются, исполняемые файлы и скрипты фильтруются на шлюзе, mark-of-the-web не обходится, а подозрительные домены режутся на DNS-уровне.
Почему ежегодный инструктаж не работает
- Забывание. Разовое занятие раз в год выветривается за пару месяцев — без коротких повторений и напоминаний в моменте от человека остаются общие впечатления, а не навык.
- Наказание за клик убивает отчётность. Если за ошибку «покарают», сотрудник промолчит. А в фишинге время между кликом и блокировкой рассылки решает, сколько ящиков ещё скомпрометируют.
- Абстракции вместо действий. «Не открывайте подозрительные письма» — не инструкция. Инструкция — «нажми кнопку Report, позвони в дежурную линию, дальше ничего не делай».
- Материалы не про вас. Примеры из чужих пресс-релизов не примеряются на свои процессы: люди не узнают в них свою 1С, свой портал поставщиков, свою «срочную оплату от директора».
Как выстроить процесс, а не акцию
- Дробите обучение. Вместо трёх часов раз в год — 10–15 минут в месяц по одной теме, с реальными примерами писем, которые приходили именно вашим сотрудникам.
- Симулируйте фишинг без публичной порки. Цель — научить сообщать, а не найти виноватого. Никаких рейтингов «худших отделов» на общем слайде: это гарантированно снижает число добровольных сообщений.
- Сделайте сообщение об ошибке дешёвым. Кнопка Report в почте, дежурный чат, шаблон «я ввёл пароль на странной странице» — и явное обещание, что за это не будет дисциплинарки.
- Разбирайте свои кейсы. Одно реальное письмо с разбором «что должно было насторожить» полезнее десяти западных презентаций.
- Опишите частые задачи короткими сценариями. Как передать файл с персональными данными, как выдать доступ подрядчику, как одобрить счёт — если процедуры нет, люди придумают свою, обычно через личную почту.
- Учите по ролям. Разработчику — секреты и зависимости, бухгалтерии — «смена реквизитов» и BEC-письма, руководителю — давление авторитетом и спешкой.
- Проверяйте на входе. Новый сотрудник и подрядчик проходят короткий тест до выдачи доступов, а не «потом когда-нибудь».
Про регуляторику: 152-ФЗ и приказ ФСТЭК №21 требуют назначить ответственных и регламентировать работу персонала с персональными данными, но конкретную форму обучения не навязывают. Формальную часть закрыть несложно — просто не путайте «расписался в журнале» с реальным снижением риска.
Технические контроли, которые снижают ставку на человека
Главный принцип: если ошибка одного нажатия приводит к катастрофе, виноват дизайн системы, а не человек. Что даёт эффект на практике:
- устойчивая к фишингу MFA (FIDO2-ключи, passkeys) на критичные системы — почта, VPN, админ-панели, Git;
- менеджер паролей на всех уровнях и отказ от переиспользования;
- минимальные привилегии и JIT-доступ, отдельные учётные записи администраторов;
- блокировка макросов из интернета, фильтрация исполняемых вложений, DNS-фильтрация;
- EDR с алертами на нетипичные дочерние процессы и работу с LSASS-подобным поведением;
- резервные копии по схеме 3-2-1 с неизменяемой (immutable) копией и регулярной проверкой восстановления;
- секрет-менеджмент вместо
.envв репозитории и ключей в тикетах; - условный доступ: страна, устройство, время — но без превращения в квест для людей, которые просто хотят работать.
Метрики: как понять, что это работает
«Процент прошедших обучение» — метрика для отчёта, не для управления. Смотрите на другое: доля сотрудников, которые сообщают о подозрительных письмах (должна расти), медианное время от первого сообщения до блокировки рассылки, доля критичных систем без phishing-resistant MFA, число содержательных обращений от людей в ИБ.
И осторожно с «процентом кликов» как KPI для отдела: он улучшается не только обучением, но и усложнением симуляций до нереалистичных — а это учит людей не доверять вообще ничему, включая настоящие письма от коллег.
Чек-лист на ближайший месяц
- Включить кнопку Report phishing и назначить ответственного за разбор сообщений.
- Перевести почту и VPN на устойчивую к фишингу аутентификацию.
- Разослать короткое (1 экран) правило: «сообщил о клике — проблемы нет, промолчал — проблема есть».
- Провести одну 15-минутную сессию на реальных письмах из своего же почтового шлюза.
- Заблокировать макросы и исполняемые вложения на шлюзе.
- Проверить, что восстановление из бэкапа реально делали руками за последние полгода.
- Запустить менеджер паролей на пилотной команде, а не «для всех сразу».
- Снять две метрики: доля сообщений о фишинге и время до блокировки рассылки.
Человека нельзя «залатать» тренингом, как нельзя починить архитектуру лозунгом. Работающая схема скучная: меньше систем, где нужен пароль, устойчивая двухфакторка, понятные процедуры на каждый частый сценарий и культура, в которой сообщить об ошибке выгоднее, чем её спрятать. Всё остальное — про то, чтобы отчёт выглядел красиво.
