ИБ-защита есть только на бумаге? Проверьте её годовым тестом

«У нас в компании уже несколько лет есть ИБ-департамент. Он закупает DLP, тратит бюджет на пентесты и пишет отчёты для регуляторов. Но когда я через одного из работников скопировал открытый Excel с зарплатами всего отдела и через день положил его на стол начальнику ИБ, они не отреагировали. Ни одна система не сработала. Значит, все эти годы мы защищали не информацию, а красивые отчёты. Есть простой способ это проверить — метод «годового теста». Он занимает день и показывает, есть ли у вас реальная защита или только её видимость.»

Что такое метод «годового теста»?

Метод «годового теста», это практическое упражнение для проверки реальной, а не декларативной эффективности службы информационной безопасности. Его суть не в поиске сложных уязвимостей, а в симуляции самого распространённого и критичного инцидента: утечки конфиденциальных данных изнутри организации. Тест моделирует действия не злонамеренного хакера, а рядового сотрудника, который по неосторожности или из любопытства может вынести важные данные.

Цель теста — ответить на один вопрос: заметит ли ваша ИБ-служба факт утечки, и как быстро она на него среагирует. Если система DLP, мониторинг событий безопасности и процессы реагирования работают, они должны сработать на относительно простой сценарий. Если нет — значит, защита существует только на бумаге и в отчётах для ФСТЭК.

Почему обычный аудит и пентест этого не покажут?

Традиционные проверки часто смотрят на проблему под другим углом:

Аудит на соответствие 152-ФЗ и приказам ФСТЭК проверяет наличие документов, политик, настроек и журналов. Он подтверждает, что у вас есть «билет» на эксплуатацию системы. Но он не проверяет, сработает ли эта система в реальной ситуации. Можно пройти аудит с отличной оценкой, имея DLP, которая молчит на 90% инцидентов.
Тест на проникновение (пентест) обычно имитирует атаку извне: поиск уязвимостей в вебе, попытки получить доступ к сети. Хороший пентестер может найти путь к доменному контроллеру, но он редко фокусируется на том, что происходит после получения доступа обычного пользователя — на краже конкретных файлов.
Проверка DLP «в лоб» часто делается штатными силами: сотрудник ИБ пытается отправить тестовый документ с ключевыми словами. Проблема в том, что он знает все шаблоны и правила, знает, что его ловят, и использует «чистые» каналы. Это не имитирует реальное поведение.

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

Пошаговый план проведения теста за один день

Тест можно провести самостоятельно, получив одобрение первого лица или руководителя службы безопасности. Важно: это не «провокация» против коллег, а учебная проверка процессов. Действуйте по следующему алгоритму.

Этап 1: Подготовка (Утро)

Выберите «приманку». Вам понадобится тестовый файл с данными, которые должны триггерить DLP и являются критичными для компании. Идеальный вариант — фиктивный файл с данными, похожими на реальные, но не являющимися таковыми (например, старый, уже опубликованный прейскурант, помеченный грифом «Конфиденциально», или файл с вымышленными паспортными данными по стандартному шаблону).
Определите канал утечки. Выберите самый обычный канал, который не заблокирован, но должен мониториться: корпоративная почта (вложение), копирование на личную флешку, отправка через веб-почту в браузере (mail.ru, gmail.com), загрузка файла в облачное хранилище или мессенджер в веб-версии.
Создайте точку контроля. Решите, куда «утекут» данные. Лучше всего использовать контролируемый внешний ресурс, который вы сами создадите на время теста, например, простой веб-сервер с функцией загрузки файлов.

Этап 2: Исполнение (Обеденное время)

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

Этап 3: Наблюдение и фиксация (Весь оставшийся день)

После совершения действия ваша задача — ждать и наблюдать. Фиксируйте:

Приходит ли автоматическое оповещение от SIEM или DLP в течение часа?
Звонит ли или пишет ли вам кто-то из ИБ-департамента с вопросами в течение 4-6 часов?
Был ли заблокирован канал передачи? Был ли пользователь, от имени которого действовали, отключён от сети?
К концу рабочего дня вам должен поступить официальный запрос от службы безопасности. Если его нет — тест провален.

Что делать с результатами?

Результат может быть один из двух, и оба — ценны.

Вариант 1: Система сработала (Идеальный сценарий)

Если в течение нескольких часов вы получили реакцию, поздравляем. Значит, у вас работают:

Детектирование: DLP или система мониторинга корректно распознала конфиденциальные данные.
Корреляция и оповещение: SIEM-система или аналитик связали событие с инцидентом и подняли тревогу.
Процесс реагирования: У ИБ-службы есть регламент, кто и как действует при таком инциденте, и они ему следуют.

В этом случае тест становится отличной учебной тренировкой для всех. Обсудите с ИБ, как прошло реагирование, и найдите точки для улучшения скорости или точности.

Вариант 2: Система не сработала (Наиболее вероятный)

Если день прошёл, а звонка так и не было, у вас есть неопровержимый факт. Теперь нужно не обвинять отдел, а разбираться в причинах. Соберите встречу с руководителем ИБ и обсудите по пунктам:

Почему не сработало детектирование? Возможно, в DLP не загружены актуальные шаблоны на ваши типы данных. Или анализ содержимого отключён для некоторых каналов (например, для веб-почты). Или правило настроено слишком строго и пропускает файлы без точного совпадения.
Почему не сработало оповещение? Может быть, событие попало в лог, но в SIEM нет коррелирующего правила на такую последовательность. Или оповещения уходят в общую почтовую ленту, которую никто не читает в реальном времени.
Почему не сработал процесс? Самый частый корень проблемы. Нет чёткого назначения ответственного за инциденты такого типа. Нет регламента, обязывающего аналитика позвонить или написать сразу после обнаружения. Сотрудники боятся «ложных срабатываний» и предпочитают долго анализировать.

Этот разговор станет основой для реального улучшения системы безопасности, а не для формального закрытия очередного пункта плана ФСТЭК.

Как метод связан с требованиями регуляторов?

На первый взгляд, метод выглядит как внутренняя импровизация. На деле он прямо вытекает из духа требований 152-ФЗ и документов ФСТЭК.

Приказ ФСТЭК №21 требует не просто наличия средств защиты информации, а оценки их эффективности. Годовой тест — и есть такая оценка в самой практической форме.
Требования к мониторингу инцидентов и реагированию на них подразумевают, что процессы отлажены и работают. Тест проверяет именно это.
Регулярные тренировки и проверки готовности рекомендованы всеми современными стандартами (включая отечественные). Этот метод — готовая схема для такой тренировки.

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

Какие риски нужно учесть?

Проведение теста требует осторожности, чтобы не навредить рабочим процессам и репутации.

Полное информирование руководства. Тест должен быть санкционирован на самом высоком уровне, доступном в вашей зоне ответственности. Это защитит вас от обвинений в самоуправстве или шпионаже.
Использование тестовых данных. Никогда не используйте реальные персональные данные или настоящую коммерческую тайну. Создавайте файлы-приманки, которые юридически ни к чему не обязывают. Это принципиально важно для соблюдения 152-ФЗ.
Контролируемая «точка утечки». Данные не должны уходить в открытый интернет или к третьим лицам. Используйте свой сервер, который будет уничтожен после теста.
Обязательный разбор полётов. Независимо от результата, итогом должна быть рабочая встреча, а не разборка. Цель — улучшение системы, а не поиск виноватых.

Что дальше? Встраиваем метод в процессы

Один удачный (или неудачный) тест, это только начало. Чтобы защита стала живой, метод нужно институционализировать.

Внесите в план работ ИБ-службы регулярные (например, раз в квартал) «контрольные закупки» — тесты на утечку через разные каналы: почта, USB, облака, мессенджеры.
Разработайте библиотеку тестовых файлов под разные типы защищаемой информации: персональные данные, финансовые отчёты, проектная документация.
Создайте формальный регламент проведения, утверждённый руководством. Это уберёт лишние вопросы и превратит тест из «инициативы снизу» в стандартную операционную процедуру.
Используйте результаты для тонкой настройки DLP и SIEM. Каждый проваленный тест указывает на слепое пятно в правилах. Его нужно закрывать.

Когда ваш ИБ-департамент начнёт ожидать такие проверки и сам будет их инициировать, это станет лучшим признаком того, что он перешёл от защиты отчётов к защите информации. В конечном счёте, именно это и требуется по закону.