«Мы путаем соответствие и безопасность, принимая выполнение формальных требований за защиту от реального злоумышленника.»
Иллюзия безопасности через соответствие требованиям
Основная проблема современных практик в сфере информационной безопасности заключается в ошибочном отождествлении двух принципиально разных понятий. С одной стороны, существует формальное соответствие требованиям регулятора — checklist из сотен пунктов. С другой — фактическая способность системы противостоять целенаправленной атаке. Ирония в том, что выполнение первого часто создаёт ложное ощущение достижения второго. Организация получает положительное экспертное заключение и успокаивается, считая инфраструктуру защищённой. На самом деле, аттестованная система может быть уязвима для методов, не описанных ни в одном методическом документе ФСТЭК.
Происхождение compliance-фреймворков: не от угроз, а от инцидентов
Чтобы понять расхождение, нужно посмотреть, как создаются требования. Они редко рождаются из проактивного анализа будущих угроз. Чаще источником служат расследования уже произошедших инцидентов. Регулятор, анализируя конкретный случай утечки данных или отказ сервиса, формулирует правило, призванное предотвратить его повторение. В результате фреймворк представляет собой коллекцию реактивных мер, собранных за годы. Он отражает не спектр современных угроз, а историю прошлых провалов. Эволюция атак опережает этот процесс на годы.
Психология «галочки»: как это работает на практике
Механизм проверки поощряет формальный подход. Аудитор приходит с чек-листом из приказов ФСТЭК. Его задача — проверить наличие документов, настроек, записей в журналах. Вопрос «а сработает ли это в реальной атаке?» часто остаётся за рамками. Сотрудники, отвечающие за compliance, оптимизируют процессы не для повышения безопасности, а для максимально быстрого и дешёвого прохождения проверки. Возникает целая экосистема: шаблонные политики, услуги по «подготовке к аттестации», консультанты, знающие, на что смотрит конкретный эксперт.
Конкретные примеры разрыва
Требования 152-ФЗ и приказов ФСТЭК делают сильный акцент на шифровании каналов связи и хранимых данных. Это логичная реакция на перехваты трафика. Но современный злоумышленник редко идёт напролом, взламывая AES. Он ищет обходные пути.
- Сертифицированные СКЗИ в небезопасной конфигурации. ФСТЭК сертифицирует криптографическое средство, но не типовую схему его развёртывания в инфраструктуре заказчика. В результате средство используется с заводскими паролями, без ротации ключей или на виртуальной машине с доступом из интернета. Чек-лист пройден («СКЗИ применено»), а ключи шифрования скомпрометированы.
- Защита периметра вместо сегментации. Многие требования фокусируются на защите границы сети: межсетевые экраны, обнаружение вторжений. Это формирует «крепкую скорлупу и жидкую середину». Попав внутрь (через фишинг, уязвимость в веб-приложении), атакующий получает свободу передвижения по плохо сегментированной сети. Комплаенс-проверка может зафиксировать наличие МСЭ, но не проверит корректность правил и изоляцию критичных сегментов.
- Документы против действий. Существует требование о проведении учений по реагированию на инциденты. На бумаге план реагирования есть, учения проведены, акт подписан. В реальности же, при настоящей атаке выясняется, что ответственные лица не знают, где искать логи, как изолировать систему, номера телефонов поставщиков устарели. Формальность исполнения требования полностью нивелирует его практический смысл.
Что остаётся за кадром требований
Реальные угрозы часто лежат в плоскостях, слабо покрытых стандартными фреймворками.
- Человеческий фактор и социальная инженерия. Ни один приказ ФСТЭК не научит сотрудника отличать фишинговое письмо от настоящего. Требования о проведении инструктажа есть, но их результативность не измеряется. А между тем, большинство успешных атак начинаются именно с человека.
- Цепочки уязвимостей (attack chains). Отдельные требования могут закрывать конкретные уязвимости (например, обязательное обновление ОС). Но они не оценивают совокупный риск от комбинации нескольких низкоуровневых проблем в разных компонентах системы, которые вместе дают путь к полному compromise.
- Угрозы для современных технологий. Контейнеризация, микросервисная архитектура, инфраструктура как код — эти подходы создают новые attack surface. Традиционные compliance-фреймворки, сфокусированные на монолитных ИС и физических серверах, просто не имеют адекватных требований для таких сред.
Фреймворк как стартовая точка, а не финишная черта
Отказываться от compliance — не решение. В российском контексте это обязательное условие легальной деятельности. Правильный взгляд на фреймворк, это не как на конечную цель, а как на необходимый базовый уровень гигиены. Это минимальный стандарт, который задаёт фундамент, подобный правилам пожарной безопасности в здании. Наличие огнетушителей и планов эвакуации не гарантирует, что пожара не случится, но минимизирует ущерб, если он произойдёт.
Выводы из аттестации стоит использовать как входные данные для настоящей работы по безопасности. Например, выявленные в процессе подготовки недостатки сегментации сети, это не просто пункт для исправления в чек-листе, а сигнал к запуску проекта по внедрению Zero Trust-архитектуры.
Как совместить compliance и реальную безопасность
Эффективная стратегия лежит в интеграции двух процессов, а не в их противопоставлении.
- Использовать требования как драйвер для улучшений. Вместо поиска минимального пути для закрытия пункта, использовать бюджет и внимание руководства, выделенные под compliance, для внедрения по-настоящему эффективных технологий. Например, требование о контроле доступа можно выполнить дешёвыми списками ACL, а можно реализовать полноценную систему Identity and Access Management (IAM) с мандатным управлением.
- Внедрять continuous security. Безопасность, это не ежегодный аудит, а постоянный процесс. Интеграция security testing (SAST, DAST, сканирование уязвимостей) в CI/CD-конвейер, регулярные Red Team-упражнения, мониторинг угроз дают картину, не зависящую от формальных проверок.
- Измерять эффективность, а не формальность. Вместо метрик «число выполненных требований» вводить метрики безопасности: среднее время обнаружения инцидента, среднее время реагирования, процент систем, прошедших пентест. Это смещает фокус с документов на реальное состояние защищённости.
Главный сдвиг, который необходимо сделать — перестать думать, что положительное заключение по 152-ФЗ означает безопасность. Оно лишь означает, что организация выполнила определённый набор обязательных требований. Вопрос «а что происходит дальше?», это уже зона ответственности самой компании, а не регулятора. И ответ на него строится не на чтении приказов, а на анализе собственной архитектуры, модели угроз и готовности к нестандартным атакам.