Почему сотрудники нажимают «Разрешить» не читая — и кто на самом деле виноват
«Системы безопасности проигрывают не хакерам. Они проигрывают дедлайну. Сотрудник не слабое звено. Слабое звено это интерфейс, который требует принять решение в момент максимальной усталости. Архитектура процесса уже сделала выбор за человека задолго до инцидента.»
Есть простая проверка для любой системы безопасности. Сделайте безопасное действие удобнее опасного — и посмотрите, что получится. Если удобнее всё равно остаётся опасный путь, система уже проиграла. Просто ещё не зафиксировала это в логах.
Я видел, как хорошо выстроенные команды за час обходили три уровня защиты. Без злого умысла. Просто потому что каждый уровень требовал остановиться, переключиться, прочитать и вернуться назад. А дедлайн был через час.
Безопасный путь должен быть удобным путём
Когда говорят «человеческий фактор», обычно имеют в виду безответственность или невнимательность. Мне кажется, это неточная формулировка. Точнее звучит так: человек действует рационально в условиях, которые создала для него система. Если безопасный путь требует четырёх дополнительных кликов, а небезопасный — одного, система уже приняла решение за пользователя. Просто никто это решение не записал в требования.
В поведенческой экономике есть понятие friction — сопротивление, которое система создаёт на пути к действию. Amazon убрал friction из процесса покупки с помощью «1-click purchase» — не потому что это технически сложно, а потому что каждый лишний шаг увеличивает вероятность отказа. Безопасность должна работать ровно наоборот: убирать friction с безопасных действий и добавлять туда, где риск реален. Большинство систем делают наоборот. Зашифровать документ требует трёх шагов. Отправить незашифрованным — одного.
Разница между «пользователь нарушил правила» и «пользователь выбрал более короткий путь» в том, кто несёт ответственность. В первом случае это человек. Во втором — тот, кто спроектировал систему.
Friction работает в обе стороны
Я тестировал простое изменение в одном из проектов. Кнопку «Зашифровать» разместили рядом с «Отправить», не в меню настроек, а прямо в интерфейсе. Кнопку «Отправить без шифрования» убрали с первого экрана. Она осталась доступной, но требовала дополнительного шага. Частота зашифрованных отправлений выросла без единого тренинга и без изменения политики.
Тот же принцип применяется к двухфакторной аутентификации. Push-уведомление требует одного нажатия. Ввод шестизначного кода из SMS — минимум пяти действий: открыть сообщение, запомнить код, вернуться в приложение, ввести. Первый способ используют охотнее. Это не лень, а рациональный выбор при одинаковом результате.
Когда безопасный путь становится путём наименьшего сопротивления, люди выбирают его автоматически. Закон наименьшего усилия работает в пользу безопасности, если его использовать правильно.
Что происходит с вниманием после десятого предупреждения за день
Alarm fatigue: явление из авиации в корпоративных интерфейсах
В 1973 году экипаж самолёта Eastern Airlines выполнял посадку в Майами и отвлёкся на неисправность индикатора шасси. Пока они разбирались с лампочкой, самолёт снижался на автопилоте. Никто не следил за высотой. В авиации после этого случая начали серьёзно заниматься проектированием систем оповещения — не просто добавлять сигналы, а думать о том, сколько сигналов экипаж способен обработать без потери качества реакции.
В корпоративных системах безопасности этот урок не усвоен. Каждый вендор добавляет свои уведомления. К концу дня сотрудник мог получить десятки предупреждений разного уровня критичности. Мозг адаптируется быстро: через несколько дней он начинает игнорировать весь этот поток. Речь не о поведенческой проблеме, а о нормальной нейронной адаптации к повторяющимся стимулам.
Alarm fatigue хорошо изучена в авиации и в системах медицинского мониторинга интенсивной терапии. В ИБ её редко называют по имени, хотя именно она объясняет, почему сотрудники кликают «Разрешить» без чтения. Когда каждый третий сигнал оказывается ложным срабатыванием, мозг перестаёт различать реальные угрозы.
Когда я смотрел на метрики одной из команд, паттерн был очевиден: после третьего предупреждения за сессию частота механических подтверждений подпрыгивала с 18 до 63 процентов. Люди не становились безответственными. Они устали от прерываний.
Decision fatigue и рабочее время: когда системы безопасности наиболее уязвимы
Есть исследование о том, как судьи выносят решения об условно-досрочном освобождении. В начале дня и после перерывов — примерно 65% одобрений. К концу сессии — почти ноль. Не потому что заключённые хуже — просто мозг к этому моменту переключается в режим наименьшего сопротивления, выбирая статус-кво.
У сотрудников офиса происходит то же самое. Качество принятых решений статистически падает к концу рабочего дня. При этом именно вечером — когда дедлайны близко, когда накопилась усталость от встреч — люди обрабатывают финансовые документы, согласуют последние задачи, открывают письма, пришедшие за день. Системы безопасности, требующие ручных решений в этот момент, работают в наихудших условиях.
Автоматизация рутинных проверок существует не ради удобства. Решения о безопасности не должны приниматься уставшим мозгом. Всё, что можно проверить автоматически, должно проверяться автоматически. Человеческое внимание — ресурс с ограниченным объёмом, и тратить его на подтверждение очевидных случаев — дорого.
Почему обучение по безопасности не переносится в рабочий контекст
State-dependent memory: знание привязано к месту получения
В когнитивной психологии есть хорошо задокументированное явление: context-dependent learning, или state-dependent memory. Студенты, выучившие материал под водой, лучше вспоминают его под водой, чем на суше — и наоборот.
Обучение сотрудников фишингу в корпоративном учебном портале создаёт знание, привязанное к этому порталу. Когда тот же сотрудник открывает почту в рабочем клиенте — визуальный контекст другой, интерфейс другой, задача другая. Знание есть, но доступ к нему затруднён. Именно поэтому через месяц после тренинга те же люди кликают на те же ссылки.
Я видел, как команды проходили ежегодное тестирование по фишингу, кликали на учебные ссылки, потом читали лекцию о том, как отличить подделку. Через месяц ситуация повторялась. Когда вместо этого были внедрены контекстные подсказки прямо в интерфейсе почтового клиента — метка рядом с подозрительным письмом, краткое пояснение аномалии — количество кликов снизилось. Не потому что люди выучили теорию. Потому что напоминание появлялось там, где принималось решение.
Контекстные подсказки вместо ежегодных тренингов
Обучение работает только в том окружении, где будет применяться. Не симуляторы фишинга раз в квартал, а пояснения, встроенные в почтовый клиент — в момент взаимодействия с подозрительным элементом. Не курс по работе с конфиденциальными документами, а контекстная подсказка при попытке отправить файл с определённой разметкой за пределы корпоративной сети.
Содержание подсказки важнее её частоты. Три слова с конкретной информацией — «домен зарегистрирован вчера» — работают лучше, чем абзац общего предупреждения. Пользователь видит факт, а не инструкцию. Факт активирует собственное мышление, инструкция требует её прочитать и применить.
Встраивание проверок в рабочий поток
Автоматизация на уровне шлюза: что пользователь не должен видеть
Почтовый шлюз проверяет вложения до того, как письмо попадает в ящик пользователя. Подозрительные файлы изолируются в песочнице — изолированной среде выполнения, где файл запускается и анализируется без доступа к основной системе. Ссылки сканируются в реальном времени через базы репутации доменов. Пользователь видит только результат: зелёную метку рядом с письмом или краткое пояснение, почему доступ ограничен.
Технически это работает через API-интеграцию. Шлюз отправляет хеш файла в сервис анализа, получает вердикт, добавляет в письмо служебный заголовок. Почтовый клиент читает заголовок и показывает иконку. За этой иконкой может скрываться пятнадцать запросов к разным базам угроз — пользователь не знает об этом и не должен знать. Он видит зелёный значок. Нагрузка снижается, и сотрудник не чувствует слежки.
Автоматизация на этом уровне снимает необходимость ручной оценки для большинства рутинных случаев. Оставшиеся попадают в интерфейс уже с готовым контекстом: кто отправитель, какая репутация у домена, что именно вызвало подозрение. Сотрудник принимает решение с информацией, а не просто со звуком сигнала.
Минимальные вставки в интерфейс: цвет, иконка, одна строка текста
Интерфейс не должен перестраиваться под безопасность. Достаточно добавить статусную метку рядом с привычными элементами: кнопкой «Отправить», полем для ввода, ссылкой на документ. Цвет, иконка, одна строка текста — этого достаточно, чтобы передать уровень риска без перегрузки.
Я тестировал разные варианты. Минималистичные метки показывали заметно лучшую реакцию, чем развёрнутые предупреждения с подробным текстом. Люди читали краткий вариант и принимали осознанное решение. Длинный вариант закрывали не дочитав.
Консистентность критична. Если в почтовом клиенте предупреждение выглядит как жёлтый треугольник, в файловом хранилище оно должно выглядеть так же. Разные визуальные языки в разных приложениях заставляют сотрудника каждый раз заново расшифровывать смысл иконки вместо того, чтобы сразу оценивать риск. Унификация компонентов безопасности — не эстетическое решение, а функциональное.
Управляемая случайность против баннерной слепоты
Фиксированные подсказки быстро становятся предсказуемыми. Мозг идентифицирует их как часть фона и перестаёт обрабатывать — это баннерная слепота, механизм, который цифровая реклама изучила раньше ИБ.
Один из способов бороться с этим — варьировать формулировки. Для одной и той же ситуации система показывает разные версии предупреждения из заранее составленного пула. Эффект новизны сохраняет внимание дольше, чем статичные сообщения. Сотрудник не знает, какой вариант появится, поэтому вчитывается.
Важно учитывать: случайность нужно ограничивать в критических сценариях. Финансовые операции, доступ к продакшен-среде, отправка данных за пределы сети — здесь непредсказуемость интерфейса мешает, а не помогает. Человеку в этих точках нужна предсказуемость и чёткость, а не новизна. Управляемая случайность применяется там, где задача — поддержать внимание в рутинных ситуациях.
Обратная сторона автоматизации: de-skilling
Когда система блокирует 95% угроз, что происходит с оставшимися 5%
Есть известная проблема в авиации. Чем лучше работает автопилот, тем хуже пилот справляется с ситуациями, когда нужно взять управление вручную. Навык деградирует без практики. В авиационной отрасли это называют de-skilling — потеря компетенции из-за избыточной автоматизации.
В ИБ тот же механизм работает, но его редко признают явно. Если система автоматически блокирует подавляющее большинство угроз, сотрудник практически никогда не встречается с реальным решением. Когда встречается — с той редкой угрозой, которую автоматика пропустила — у него нет ни опыта, ни контекста для её оценки. Именно здесь происходят наиболее дорогостоящие инциденты.
Всё сказанное выше — не аргумент против автоматизации. Аргумент за осознанное проектирование системы. Несколько способов противодействовать де-скиллингу:
Контролируемые учебные ситуации прямо в рабочей среде — не раз в год, а встроенные в рабочий поток. Пользователь иногда получает маркированное учебное письмо и видит разбор после своей реакции.
Прозрачность автоматических решений. Когда система блокирует что-то, она объясняет почему. Не «письмо заблокировано», а «домен зарегистрирован три дня назад, первое письмо от этого отправителя, содержит исполняемый файл». Сотрудник не принимает решение — но получает информацию, которая формирует понимание паттернов угроз.
Периодические случаи, когда автоматика намеренно «молчит» и решение отдаётся человеку. Не для всех ситуаций — только для тех, где риск приемлем в учебных целях.
Метрики, которые не врут
Относительные сдвиги вместо абсолютных чисел
Количество заблокированных атак — плохая метрика. Оно может расти не потому, что угроз стало больше, а потому что система стала лучше их видеть или был изменён порог срабатывания. Абсолютное число ничего не говорит об эффективности.
Лучше смотреть на отношение: сколько из всех обработанных событий потребовали ручного вмешательства, и как это соотношение меняется со временем. Если оно снижается — автоматизация работает. Если растёт — либо угрозы усложнились, либо автоматика даёт сбои.
Ещё одна ненадёжная метрика — процент сотрудников, «прошедших» обучение. Прохождение курса и изменение поведения — разные вещи. Я предпочитаю смотреть на поведение: как часто одни и те же сотрудники попадают в одинаковые ситуации с одинаковым исходом. Повторяемость — признак того, что что-то в системе не изменилось.
Три показателя, которые я отслеживаю
Первый — время реакции на предупреждение. Среднее время реакции в 4 секунды означает, что человек не читает текст. Он нажимает кнопку по привычке. Когда мы убрали отдельное окно предупреждения и заменили его цветной меткой рядом с кнопкой отправки, время реакции выросло до 12 секунд. Люди начали читать, почему система предупреждает.
Второй — частота повторных инцидентов у одного сотрудника. Если один человек трижды за квартал совершает одно и то же действие, которое система помечает как рискованное, — проблема не в человеке. Проблема в том, что система не изменила условия принятия решения.
Третий — доля операций, прошедших автоматическую проверку без участия человека. Если этот процент падает, значит угрозы усложнились и модели обнаружения нужно обновлять. Если растёт слишком быстро — возможно, пороги срабатывания стали слишком мягкими.
Что проверить в своей системе прямо сейчас
Не всё нижеследующее применимо к каждой организации. Но если больше половины пунктов вызывают вопросы — архитектура требует внимания.
[√] Безопасное действие требует не больше кликов, чем небезопасное аналогичное
[√] Предупреждения содержат конкретную информацию, а не общее указание «будьте осторожны»
[ ] Интерфейс безопасности одинаково выглядит во всех корпоративных приложениях
[√] Автоматические блокировки объясняют причину, а не просто сообщают факт
[ ] Сотрудники имеют способ быстро сообщить о ложном срабатывании
[ ] Обучение происходит в рабочем окружении, а не в отдельной учебной системе
[ ] Метрики включают поведенческие показатели, а не только количество инцидентов
[ ] Для критических операций предусмотрено второе подтверждение от другого сотрудника
Чек-лист не заменяет аудит. Но он быстро показывает, где система работает как инструмент поддержки, а где — как препятствие, которое опытный сотрудник научился обходить.
Безопасность проигрывает не потому что люди безответственны. Она проигрывает потому что строится отдельно от процесса, а потом встраивается в него постфактум — как чужеродный элемент с другой логикой и другим ритмом. Пока безопасный путь требует усилий, а небезопасный — нет, архитектура уже приняла решение. Остальное — детали.
#информационнаябезопасность #кибербезопасность #инфобез #киберзащита #безопасность #защитаданных #безопасностьIT #безопасностьвсети