Социотехническое тестирование проверяет не память после курса, а поведение человека и работу защитных процессов в правдоподобной ситуации. Оно приносит пользу как минимум при трёх условиях: заказчик письменно задаёт границы, тест не собирает лишние данные, а результат используют для исправления среды и обучения. Иначе полезная проверка быстро превращается в рискованный розыгрыш.
Под социотехнической проверкой обычно понимают контролируемую имитацию приёмов социальной инженерии: письмо с безопасной учебной ссылкой, звонок от вымышленного коллеги, запрос на передачу служебной информации или попытку пройти в офис по согласованному сценарию. Набор каналов зависит от цели и допуска. Отправлять фишинговое письмо по всей компании лишь потому, что это технически возможно, нельзя считать методикой.
Если задача ограничена проверкой реакции на почтовые атаки, отдельно разобрали, как провести фишинг-симуляцию для сотрудников.
Пентаст социальной инженерии: что проверяют кроме клика
В поисковых запросах встречается формулировка «пентаст социальной инженерии», хотя в профессиональной речи чаще используют «пентест». Смысл шире фишинговой рассылки. Проверка показывает, сработали ли регламенты, умеют ли сотрудники сообщать о подозрении, замечает ли служба ИБ сигнал и может ли организация остановить развитие сценария. Клик – только одно событие в этой цепочке.
NIST определяет социальную инженерию как попытку обманом получить информацию и относит её к способам проверки человеческого фактора и осведомлённости. В том же руководстве сказано, что результаты такой проверки следует использовать для улучшения безопасности организации, а не для выделения отдельных людей. Это полезная граница: фамилии нужны ограниченному кругу для разбора инцидента, руководству чаще достаточно агрегированных данных. Источник: NIST SP 800-115, раздел 5.3 – https://csrc.nist.gov/pubs/sp/800/115/final
До старта команда формулирует проверяемые гипотезы. Например:
- сотрудник распознает нетипичный запрос на смену реквизитов и проверит его по второму каналу;
- получатель отправит подозрительное письмо в службу ИБ, а не просто удалит его;
- первая линия поддержки не сбросит пароль по данным, которые можно найти в открытом доступе;
- охрана сверит посетителя с заявкой и позвонит принимающему сотруднику.
- сотрудник распознает нетипичный запрос на смену реквизитов и проверит его по второму каналу;
- получатель отправит подозрительное письмо в службу ИБ, а не просто удалит его;
- первая линия поддержки не сбросит пароль по данным, которые можно найти в открытом доступе;
- охрана сверит посетителя с заявкой и позвонит принимающему сотруднику.
Легальное тестирование на фишинг начинается до рассылки
Письменное разрешение заказчика – основа контролируемого теста, но не универсальная индульгенция. NIST SP 800-115 рекомендует до начала определить правила, зафиксировать одобрение руководства и цели, а для теста подготовить Rules of Engagement – правила проведения с разрешёнными и запрещёнными действиями. Для проверок, способных повлиять на системы и данные, NIST советует привлекать юристов ещё на этапе планирования. Источник: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-115.pdf
Если при тесте обрабатывают данные работников, юридическая служба должна определить законное основание и проверить локальные документы. Статья 5 Федерального закона № 152-ФЗ требует заранее заданной законной цели, соразмерного состава данных и ограниченного срока хранения. Статья 19 требует правовых, организационных и технических мер защиты. А статья 86 ТК РФ задаёт отдельные требования к данным работников. Ссылки: https://www.consultant.ru/document/cons_doc_LAW_61801/96fbc469f91f57235cc842a85e0516a99f23dc85/ ; https://www.consultant.ru/document/cons_doc_LAW_61801/ca9e5658710519f09ab2fdb8196fcb3eb024a051/ ; https://www.consultant.ru/document/cons_doc_LAW_34683/01f6157ff985b3cbbb50eb88fa6e26f30202532a/
Если тест проводит подрядчик, одного пункта «провести фишинг» в договоре мало. Часть 3 статьи 6 закона № 152-ФЗ требует определить в поручении перечень персональных данных, операции с ними, цели обработки, конфиденциальность и меры безопасности. Конкретную модель должен проверить юрист заказчика с учётом систем, состава участников и сценария. Источник: https://www.consultant.ru/document/cons_doc_LAW_61801/315f051396c88f1e4f827ba3f2ae313d999a1873/
В правилах проведения полезно прямо запретить:
- сбор действующих паролей, платёжных данных и содержимого личной переписки;
- использование тем о смерти, тяжёлой болезни, увольнении или личной беде без отдельной оценки риска;
- установку программ и получение доступа к системам, если это не разрешено отдельным техническим сценарием;
- публичные рейтинги сотрудников и дисциплинарные выводы по одному эпизоду;
- продолжение теста после стоп-сигнала или обнаружения реального инцидента.
- сбор действующих паролей, платёжных данных и содержимого личной переписки;
- использование тем о смерти, тяжёлой болезни, увольнении или личной беде без отдельной оценки риска;
- установку программ и получение доступа к системам, если это не разрешено отдельным техническим сценарием;
- публичные рейтинги сотрудников и дисциплинарные выводы по одному эпизоду;
- продолжение теста после стоп-сигнала или обнаружения реального инцидента.
Есть и жёсткие внешние границы. Статья 23 Конституции РФ защищает тайну переписки и иных сообщений. Статья 272 УК РФ устанавливает ответственность за неправомерный доступ к охраняемой законом компьютерной информации, если наступили указанные в статье последствия. Поэтому допуск должен исходить от владельца соответствующих систем и охватывать конкретные действия; доступ к чужой инфраструктуре или личным сообщениям нельзя молча включить в сценарий. Ссылки: https://www.consultant.ru/document/cons_doc_LAW_28399/2573feee1caecac37c442734e00215bbf1c85248/ ; https://www.consultant.ru/document/cons_doc_LAW_10699/5c337673c261a026c476d578035ce68a0ae86da0/
Методика социотехнического тестирования: от гипотезы до повторной проверки
Рабочая методика социотехнического тестирования строится вокруг наблюдаемого поведения. Мы не начинаем с вопроса «какое письмо отправить». Сначала выбираем риск: подмена реквизитов, кража учётной записи, ложный запрос руководителя, сброс пароля через поддержку или проход постороннего в офис. Затем определяем ожидаемое безопасное действие и только после этого пишем легенду.
1. Сформулировать одну проверяемую гипотезу и ожидаемое безопасное действие.
2. Определить участников, каналы, системы, исключения и критерии остановки.
3. Согласовать правила проведения с ИБ, ИТ, кадровой и юридической функциями.
4. Подготовить безопасную инфраструктуру: учебный домен, страницу без сбора паролей, журнал событий и канал срочной связи.
5. Провести ограниченный пилот и проверить, не создаёт ли сценарий технический или человеческий ущерб.
6. Запустить тест, фиксируя только заранее выбранные события.
7. Разобрать не только ошибки людей, но и реакцию почтовой защиты, поддержки, ИБ и руководителей.
8. Провести короткое обучение по наблюдаемым пробелам и повторить сопоставимый тест позже.
2. Определить участников, каналы, системы, исключения и критерии остановки.
3. Согласовать правила проведения с ИБ, ИТ, кадровой и юридической функциями.
4. Подготовить безопасную инфраструктуру: учебный домен, страницу без сбора паролей, журнал событий и канал срочной связи.
5. Провести ограниченный пилот и проверить, не создаёт ли сценарий технический или человеческий ущерб.
6. Запустить тест, фиксируя только заранее выбранные события.
7. Разобрать не только ошибки людей, но и реакцию почтовой защиты, поддержки, ИБ и руководителей.
8. Провести короткое обучение по наблюдаемым пробелам и повторить сопоставимый тест позже.
NIST делит пентест на планирование, обнаружение, атаку и отчётность. Для социотехнической проверки эту логику стоит сделать безопаснее: этап «атака» заканчивается на доказательстве гипотезы, если дальнейшее действие не разрешено. Учебная форма может зафиксировать факт попытки ввода, но не должна сохранять сам пароль. Звонок может проверить, раскроет ли сотрудник служебный факт, но тестировщик не забирает документ «для убедительности». Достаточно маркера.
В StopPhish мы связываем проверку с последующим обучением: сотруднику нужен короткий разбор конкретного сигнала, а владельцу процесса — понятная задача на исправление. Если вы планируете тест, запросите демонстрацию StopPhish.
Аудит осведомленности сотрудников: метрики без ложной точности
Аудит осведомленности сотрудников отвечает на два разных вопроса: что люди знают и что организация делает при имитации атаки. Анкета или тест знаний измеряет первое. Контролируемый сценарий – второе. Смешивать показатели опасно: сотрудник может назвать все признаки фишинга и всё же отреагировать на письмо, точно попавшее в его рабочий контекст. И наоборот.
Подробнее о том, как собирать метрики Security Awareness и превращать их в понятную отчётность для ИБ и руководства, рассказали отдельно.
Для отчёта достаточно трёх уровней:
- руководству – маршруты риска, агрегированные показатели и решения с владельцами;
- службе ИБ – события, временная шкала, работа средств защиты и процесса реагирования;
- обучению – темы, роли и действия, которые надо отработать без публичного перечисления фамилий.
- руководству – маршруты риска, агрегированные показатели и решения с владельцами;
- службе ИБ – события, временная шкала, работа средств защиты и процесса реагирования;
- обучению – темы, роли и действия, которые надо отработать без публичного перечисления фамилий.
Культура наказания портит сам датчик. Британский NCSC предупреждает о проблемах фишинговых симуляций и советует уходить от стыда и страха вокруг ошибочного клика: сотрудник должен быстро сообщать о подозрении, а не прятать ошибку. Источники: https://www.ncsc.gov.uk/guidance/phishing и https://www.ncsc.gov.uk/blog-post/telling-users-to-avoid-clicking-bad-links-still-isnt-working
Частые вопросы о социотехническом тестировании
Нужно ли заранее предупреждать всех сотрудников?
Не всегда сообщают дату и легенду конкретного теста, иначе поведение меняется. Но скрытый сценарий не отменяет правовых оснований, локальных документов и защиты данных работников. Формат информирования определяют заказчик, кадровая функция и юристы до запуска.
Можно ли собирать пароли на учебной странице?
Мы рекомендуем не принимать и не хранить действующие пароли. Для проверки достаточно безопасно зафиксировать попытку ввода или использовать явно учебное значение. Если сценарий требует большего, это уже отдельная техническая проверка с отдельным допуском и мерами защиты.
Чем пентест социальной инженерии отличается от фишинговой симуляции?
Симуляция обычно ограничена одним цифровым каналом и учебным действием. Пентест может связывать письмо, звонок, поддержку, физический доступ и реакцию ИБ. Чем шире маршрут, тем подробнее должны быть письменные границы и условия остановки.
Можно ли наказывать сотрудника за клик?
Один клик не показывает ни устойчивость человека во всех ситуациях, ни качество защиты организации. NIST советует использовать результаты для улучшения безопасности, а не для выделения отдельных людей. Трудовые решения требуют самостоятельной правовой и фактической оценки, их нельзя автоматически строить на одном учебном эпизоде.
Какая выборка нужна для проверки?
Выборка зависит от гипотезы. Для проверки процесса смены реквизитов нужны роли, которые получают такие запросы. Для общей рассылки – группы, позволяющие увидеть различия без раскрытия персональных результатов. Число участников задают до теста и не расширяют по ходу ради более заметной статистики.
Что должно быть в итоговом отчёте?
Цель и границы, сценарий, подтверждённые события, временная шкала, действия сотрудников и защитных функций, ограничения интерпретации, рекомендации, владельцы задач и срок повторной проверки. Персональные приложения, если они нужны, хранят отдельно и дают к ним ограниченный доступ.
Когда тест надо остановить?
При выходе за согласованные системы или аудиторию, техническом сбое, риске реального ущерба, обнаружении настоящей атаки, сборе незапланированных данных либо по стоп-сигналу заказчика. Условие остановки пишут заранее вместе с контактами тех, кто может принять решение.
Источники и нормативная база
- NIST SP 800-115, Technical Guide to Information Security Testing and Assessment: https://csrc.nist.gov/pubs/sp/800/115/final
- Федеральный закон № 152-ФЗ, статьи 5, 6 и 19: https://www.consultant.ru/document/cons_doc_LAW_61801/
- Трудовой кодекс РФ, статья 86: https://www.consultant.ru/document/cons_doc_LAW_34683/01f6157ff985b3cbbb50eb88fa6e26f30202532a/
- Конституция РФ, статья 23: https://www.consultant.ru/document/cons_doc_LAW_28399/2573feee1caecac37c442734e00215bbf1c85248/
- Уголовный кодекс РФ, статья 272: https://www.consultant.ru/document/cons_doc_LAW_10699/5c337673c261a026c476d578035ce68a0ae86da0/
- NCSC, Phishing attacks: defending your organisation: https://www.ncsc.gov.uk/guidance/phishing
