«Мы тратим бюджет на шифрование и двухфакторную аутентификацию, закрывая формальные требования регулятора. Настоящая брешь не в файрволе, это типовой деловой запрос в чате от имени «аудитора» или «руководителя». Социальная инженерия работает не из-за глупости сотрудников, а из-за организационных процессов, которые делают нарушение процедур самым простым способом решить проблему.»
Тишина после шторма
В сводках ФСТЭК фигурируют массовые инциденты, связанные с фишингом через корпоративные мессенджеры. Компании фокусируются на техническом соответствии 152-ФЗ: шифрование дисков, парольные политики, формальное разграничение доступов. Это создаёт иллюзию контролируемого периметра, который на деле начинается не на межсетевом экране, а на экране смартфона сотрудника. Стандартные обучающие тесты с заведомо подозрительными сценариями не отражают реальной угрозы, где запрос выглядит как рутинная рабочая задача. Поведение человека, знающего, что его тестируют, меняется.
Эксперимент: давление авторитета и процедуры
Для оценки реального риска был смоделирован целевой сценарий социальной инженерии. Целью стали сотрудники бухгалтерии, логистики и отдела продаж, имеющие прямой доступ к 1С:Бухгалтерии и CRM. Ключевая задача — создать ситуацию, когда выполнение запроса воспринимается как часть работы, а не проверка бдительности.
Для этого в корпоративном мессенджере были созданы два аккаунта с нейтральными именами и аватарами. Один имитировал руководителя из «головного офиса», второй — внешнего аудитора.
Механика взаимодействия
Сценарий разворачивался в течение одного рабочего дня:
- Легитимация запроса: Аккаунт «руководителя» обращался к сотруднику: «Добрый день. В рамках плановой аудиторской проверки к вам сегодня обратится специалист для выборочного контроля документов в 1С. Прошу оказать содействие».
- Непосредственная атака: Через 30-60 минут аккаунт «аудитора» писал: «Здравствуйте, подключаюсь для проверки. Мне потребуется доступ к 1С. Можно получить временные гостевые учётные данные? Если их создание затруднительно, отправьте, пожалуйста, ваши логин и пароль — я оперативно изучу нужные разделы и выйду из системы».
Запрос прямого доступа к учётным данным противоречит базовым правилам, но именно эта простота и сработала.
Результаты: разрыв между знанием и действием
Из пяти проверенных сотрудников двое предоставили доступ к системам.
- Сотрудник бухгалтерии после короткого уточнения («Вы точно из проверки? Я не получал уведомления») и получения подтверждения от аккаунта «руководителя» отправил в чат свои реальные логин и пароль от 1С, сопроводив сообщением: «Вот, пароль сложный: Pr0v3rka2024!».
- Сотрудник логистики без вопросов создал в 1С нового пользователя с правами на просмотр складских документов и отправил учётные данные.
Трое отреагировали правильно: один потребовал оформления официальной заявки через Service Desk, другой позвонил своему непосредственному начальнику для устного подтверждения, третий проигнорировал запрос, сочтя его каналы и тональность неофициальными.
Решающим фактором оказалась не должность или прохождение тренингов, а личная осторожность и понимание внутренних неформальных процедур. Те, кто отказал, действовали не по письменной инструкции, а по внутреннему ощущению нарушения стандартного процесса.
Анализ провала: где оборона дала трещину
Проблема выявлена не в конкретных людях, а в организационных процессах, которые сделали такой сценарий возможным и правдоподобным.
| Уязвимость процесса | Как это эксплуатируется |
|---|---|
| Слепое доверие к «вертикали» | Упоминание руководства или аудита автоматически повышает приоритет запроса. Страх создать проблему «важному лицу» перевешивает сомнения. |
| Давление срочности | Указание «подключаюсь сегодня» не оставляет времени на верификацию через официальные каналы, выводя человека из состояния критической оценки. |
| Размытость официальных каналов | Отсутствие чёткого, известного всем алгоритма подтверждения. Как проверить аудитора? Позвонить по какому номеру? Свериться с каким документом? Отсутствие простого ответа подталкивает к быстрому неформальному решению. |
| Культура «помощи» | Внутри коллективов поощряется оперативная помощь коллегам. Запрос, сформулированный как просьба о содействии в рабочем процессе, попадает в эту категорию и не вызывает подозрений. |
Что делать: от паранойи к процедурам
Реакция на подобные эксперименты не должна сводиться к повторным тренингам. Нужны системные изменения, превращающие интуитивную осторожность в формальный и простой для выполнения регламент.
- Внедрить правило «одного канала» для критичных запросов. Установить и довести до каждого сотрудника, что любые запросы на предоставление доступа, изменение настроек или передачу данных должны приходить исключительно через одну утверждённую систему (Service Desk, корпоративный портал). Запросы в мессенджерах, по телефону или из личной почты на такие действия не выполняются.
- Создать простой чек-лист верификации. Разработать памятку из 2-3 шагов: 1) Проверить, прислан ли запрос через официальную систему. 2) Если нет — позвонить инициатору по номеру из внутреннего справочника (не по тому, что указан в сообщении). 3) В случае сомнений — уведомить службу информационной безопасности.
- Проводить необъявленные контролируемые учения. Периодически моделировать аналогичные целевые атаки в разных подразделениях. Цель — не сбор статистики провалов, а тренировка применения установленных процедур в условиях, приближенных к реальным.
- Легализовать право на отказ. Донести, что отказ выполнить подозрительный запрос, нарушающий регламент, является не проявлением некомпетентности, а прямой служебной обязанностью и будет поддерживаться руководством.
Технические меры защиты остаются фундаментом, но они бессильны, если учётные данные добровольно отправляются в чат. Угроза сместилась в область психологии и процедур. Защита теперь, это не только шифрование трафика, но и выстроенный процесс, который делает ошибку человека максимально сложной, даже если он искренне хочет помочь.