“Соответствие требованиям, это не про безопасность, а про управление рисками. Рисками не взлома, а проверки. Реальная защита начинается там, где заканчивается чек-лист.”
Что такое compliance и зачем он нужен
Compliance, это формальное соответствие установленным правилам, стандартам и требованиям регуляторов. В российском ИТ-контексте это прежде всего ФСТЭК, 152-ФЗ, приказы, методики и отраслевые стандарты. Его цель — доказать проверяющим органам, что организация выполняет предписанные процедуры. Это процесс документированный, измеримый и часто цикличный: подготовка, внутренний аудит, внешняя проверка, получение заключения или устранение замечаний.
Compliance создаёт базовый уровень порядка. Он задаёт минимальные рамки: нужно вести журналы, назначать ответственных, проводить оценку угроз по утверждённой методике, использовать сертифицированные средства защиты. Без этого легальная работа в ряде отраслей, особенно с госсектором или персональными данными, невозможна. Соответствие становится пропуском на рынок, условием контракта, способом снизить юридические и репутационные риски от штрафов.
Но его логика — логика отчётности. Система строится вокруг доказательств для третьей стороны, а не вокруг нейтрализации конкретных технических угроз. Успех измеряется не отсутствием инцидентов, а наличием правильно заполненных документов и галочек в отчёте.
Что такое actual security и как она работает
Actual security, или реальная безопасность,, это практическая способность системы противостоять актуальным угрозам. Её фокус — не на бумагах, а на архитектуре, коде, процессах реагирования и компетенциях команды. Это непрерывный процесс, а не событие перед проверкой.
Ключевое отличие — в динамике. Угрозы эволюционируют ежедневно: появляются новые векторы атак, эксплойты для уязвимостей, методы социальной инженерии. Реальная защита требует постоянного мониторинга, анализа инцидентов, обновления защитных механизмов и адаптации. Её нельзя «внедрить» раз и навсегда по шаблону, как типовой набор мер из приказа ФСТЭК.
Эффективность actual security измеряется метриками, которые не всегда можно красиво оформить в акт: среднее время обнаружения угрозы, среднее время реагирования, процент ложных срабатываний, глубина проникновения при тестировании на проникновение. Это история про снижение реального, а не формального ущерба.
Почему compliance не гарантирует security
Соответствие стандартам создаёт лишь иллюзию защищённости, если ограничивается формальным выполнением. Вот несколько причин разрыва.
Запаздывание требований
Регуляторные документы обновляются медленнее, чем развиваются технологии и тактики злоумышленников. Требования 152-ФЗ или базовые наборы мер ФСТЭК могут не учитывать современные облачные архитектуры, специфику контейнеризации или методы атак через цепочки поставок. Организация, полностью соответствующая устаревшему стандарту, может быть уязвима для атаки, о которой в стандарте ещё нет ни слова.
«Боксовая» проверка
Аудит на соответствие часто представляет собой проверку по чек-листу: установлен ли межсетевой экран, ведётся ли журнал, проведено ли обучение. Аудитор может не вникать в тонкости настройки этого экрана, не оценивать качество правил или не проверять, насколько журналы защищены от модификации. Главное — наличие артефакта. В результате можно иметь «установленный» но неэффективно сконфигурированный инструмент.
Подмена целей
Когда главная KPI отдела информационной безопасности — успешное прохождение проверки, вся деятельность подстраивается под эту цель. Ресурсы тратятся на красивую отчётность и имитацию бурной деятельности, а не на решение сложных технических задач по укреплению обороны. Security становится не инженерной дисциплиной, а частью бюрократии.
Типичные ловушки приоритета compliance
- Защита «на бумаге». Политика парольной сложности есть, но технически не реализована или обходится через общие учётные записи. Уязвимость формально устранена (есть акт), но патч не применён на всех контурах.
- Слепые зоны в мониторинге. Средства контроля развёрнуты только на системах, попадающих под действие регуляторики (например, где обрабатываются персональные данные). Остальная инфраструктура, включая системы разработки или управления, остаётся без внимания и может стать точкой входа.
- Культура «галочки». Сотрудники проходят ежегодное формальное обучение по ИБ, сдают тест, но не понимают сути угроз. При этом не проводится регулярное фишинг-тестирование или тренировки по реагированию на инциденты, которые реально повышают осведомлённость.
- Негибкость архитектуры. Жёсткое следование устаревшим требованиям (например, по физическому выделению сегментов) блокирует переход на более безопасные и управляемые облачные или программно-определяемые модели, которые позволяют быстрее применять политики и изолировать угрозы.
Как совместить compliance и actual security
Полный отказ от compliance невозможен в регулируемой среде. Задача — интегрировать его требования в живую систему безопасности, а не подменять одно другим.
Используйте регуляторные требования как базис, а не потолок
Рассматривайте обязательный набор мер ФСТЭК как минимальный стартовый уровень. На его основе выстраивайте дополнительные, более строгие контрмеры, ориентированные на вашу конкретную модель угроз. Если стандарт требует антивирус, внедрите EDR-систему с возможностью поведенческого анализа и расследования инцидентов. Если требуется разграничение прав, внедрите модель наименьших привилегий и регулярный пересмотр доступов.
Автоматизируйте сбор доказательств для compliance
Вместо ручного составления отчётов настройте автоматический сбор логов, конфигураций и результатов сканирований в единую платформу (SIEM или специализированное решение для GRC). Это позволит в любой момент сформировать актуальные доказательства для аудита, не отвлекая команду от оперативной работы. Так compliance становится побочным продуктом нормальной эксплуатационной деятельности.
Сместите фокус аудита с формального на содержательный
При проведении внутренних аудитов или выборе внешнего подрядчика требуйте не просто сверки со списком, а практической оценки эффективности мер. Включите в план аудита тестирование на проникновение, проверку реализованных сценариев реагирования, оценку времени обнаружения тестовых атак. Документируйте не только факт наличия инструмента, но и результаты его работы.
Говорите с бизнесом на языке рисков, а не штрафов
Обосновывайте инвестиции в security не только необходимостью избежать штрафа по 152-ФЗ, а потенциальными убытками от простоя, утечки данных, потери репутации. Сопоставьте стоимость внедрения продвинутой системы мониторинга с возможными финансовыми потерями от необнаруженного инцидента. Так безопасность станет бизнес-функцией по управлению рисками, а не центром затрат для compliance.
Что в итоге
Compliance и actual security решают разные задачи. Первое — легализует деятельность, снижает юридические риски и задаёт общий порядок. Второе — непосредственно защищает активы от атак. Опасно подменять второе первым, но и игнорировать compliance в надежде на «настоящую» безопасность — путь к административным барьерам.
Успешная стратегия — встроить формальные требования в ткань операционной безопасности, автоматизировать отчётность и всегда смотреть дальше минимального набора мер. Цель не в том, чтобы подготовиться к проверке, а в том, чтобы проверка стала лёгким формальным этапом, потому что реальная защита работает каждый день на уровне выше требуемого. Безопасность тогда становится не обузой, а конкурентным преимуществом и признаком зрелости организации.