“Общая концепция защиты информации — бастионы на болоте. В российском ИТ-регуляторике слишком много процессов построено на ‘защищаем то, что легко защищать’, а не на ‘защищаем то, что критично’. Результат: замок красиво стоит, а страшные существа уже давно живут внутри”
.
Сертификация и валидация
Большинство документов, требуемых для аттестации объектов информатизации или сертификации средств защиты информации, представляют собой подробные перечни действий и процессов. Часто они являются отчётностью о том, как именно была построена защита, но не дают представления о её эффективности. Это процессная безопасность: мы можем задокументировать установку фаервола, но не понимаем, насколько он правильно настроен для конкретных рисков предприятия.
Практический пример: требование наличия разрешительной системы контроля доступа. Её можно внедрить и получить положительное заключение экспертизы. Но реальность в том, что такая система часто настраивается минимально — по ролевым моделям, которые не менялись годами, с избыточными правами для администраторов и отсутствием регулярного аудита фактического использования. Замок построен, но ключи от него лежат в открытом месте.
Тонкая прослойка
Оценка соответствия объекта защиты требованиям регулятора чаще всего сводится к проверке наличия документов и технических средств, внесённых в реестр ФСТЭК России. Вопросы касаются реализации и архитектуры лишь поверхностно.
Проблема в том, что уязвимость часто возникает не в отсутствии компонента, а в его неправильной интеграции или настройке. Например, система межсетевого экранирования может быть установлена, но:
- Политика пропуска трафика написана на основе принципа «всё разрешено, кроме известных угроз», а не «всё запрещено, кроме необходимого».
- Логирование событий настроено, но журналы не анализируются, а хранилище переполняется через месяц работы.
- Правила обновляются формально, без учёта изменений в сетевой топологии предприятия.
Проверка в рамках аттестационных мероприятий таких деталей обычно не затрагивает. Поэтому замок (средство защиты) присутствует, но его стены сделаны из картона.
Критерии успеха
Приоритет в работе с регуляторикой — формальное соответствие. Задача выполняется успешно, если все пункты методики проверки выполнены или имеется план мероприятий по устранению недостатков. Реальная безопасность информационных систем остаётся на втором плане.
Это приводит к парадоксу: организация может иметь полный комплект документов по защите персональных данных, но при этом база данных с этими данными доступна из интернета через устаревшую веб-форму без авторизации. Аттестация была проведена на бумаге, замок стоит на бумаге.
Пример технической реализации «на бумаге»
Требование: обеспечить контроль целостности информации. Реализация: внедрение средства контроля целостности, сертифицированного ФСТЭК России.
Что часто происходит на практике:
- Средство устанавливается на ограниченный набор систем (например, только на серверы, но не на рабочие станции).
- Проверка целостности выполняется по расписанию, но результаты проверок не анализируются, а просто хранятся.
- Критические изменения (например, модификация файлов конфигурации сетевых служб) не включены в список контролируемых объектов, потому что это требует глубокого понимания инфраструктуры.
В результате средство работает, но не выполняет свою главную функцию — раннее обнаружение атак. Целостность контролируется формально. Замок построен, но его двери открыты.
Отсутствие динамической оценки
Регуляторные проверки и внутренние аудиты в основном статичны. Они оценивают состояние системы защиты в определённый момент времени — обычно перед подачей документов или во время плановой проверки.
Информационная инфраструктура динамична: появляются новые сервисы, меняются сетевые маршруты, обновляются приложения. Угрозы также меняются. Статичная оценка не может охватить непрерывный процесс адаптации защиты к изменениям.
Пример: организация прошла аттестацию на соответствие требованиям к системе защиты информации. Через месяц в инфраструктуру был добавлен новый виртуальный сервер для тестирования, но на него не были распространены политики межсетевого экранирования и контроля доступа. Формально аттестация не нарушена, но реальный уровень защиты снизился. Волна уже подмыла фундамент замка.
Риск-ориентированный подход против процессного
Действующие методики и рекомендации регуляторов в России часто носят процессный характер. Они описывают, что нужно делать, но не дают инструментов для определения, насколько эти действия снижают конкретные риски бизнеса.
Риск-ориентированный подход начинается с анализа: какие информационные assets критичны для компании, какие угрозы им актуальны, какие векторы атак наиболее вероятны. Затем меры защиты выбираются и настраиваются именно для нейтрализации этих рисков.
В текущей парадигме последовательность обратная: сначала изучается перечень обязательных требований регулятора, затем под них подбираются средства и процессы, а оценка рисков проводится формально или вообще не проводится. Замок строится там, где регулятор сказал строить, даже если главная угроза приходит с другой стороны.
Как выглядит разница на практике
Процессный подход: «По требованию п. 5.12 необходимо обеспечить регистрацию событий. Мы внедряем SIEM-систему, собираем логи со всех источников, генерируем отчёты для проверки». Фокус на действие и отчётность.
Риск-ориентированный подход: «Основной риск — несанкционированные финансовые транзакции. Мы определяем, что ключевыми событиями для обнаружения такой атаки являются попытки доступа к платежным системам вне рабочего времени, изменения правил одобрения операций, массовый экспорт данных. Настраиваем SIEM на детектирование именно этих паттернов и строим автоматические реакции». Фокус на результат и нейтрализацию угрозы.
Переход от первого ко второму в рамках регуляторных требований сложен, потому что критерии соответствия остаются процессными. Можно построить эффективную, риск-ориентированную защиту и всё равно получить замечания по аттестации, если какой-то формальный пункт методики выполнен не в полном объёме.
Психология «галочки»
Менталитет «поставить галочку» глубоко укоренился в корпоративной культуре многих российских организаций, особенно в государственном секторе и крупных компаниях, где регуляторика является обязательной. Цель выполнения требований трансформируется из «сделать безопасно» в «получить документ».
Это создаёт замкнутый круг:
- Регулятор проверяет наличие галочек.
- Организация сосредотачивается на создании галочек.
- Реальные инциденты безопасности случаются, потому что галочки не защищают.
- Регулятор в ответ усиливает контроль за галочками (добавляет новые пункты в методики), а не за эффективностью.
Главный парадокс здесь в том, что такой подход увеличивает нагрузку на организации, но не повышает уровень безопасности. Команды тратят больше времени на документирование и отчётность, но меньше — на анализ текущих угроз и улучшение защитных механизмов.
Технологический вакуум
Большинство сертифицированных средств защиты информации в России разрабатывались и проходили сертификацию годы назад. Их архитектура и функциональность часто не соответствуют современным технологическим реалиям, например, работе в гибридных облаках, защите микросервисных архитектур или противодействию сложным целевым атакам.
Организация обязана использовать сертифицированные средства для выполнения ряда требований. В итоге она внедряет технически отсталые решения, которые слабо интегрируются с современной инфраструктурой и не могут обеспечить полноценную защиту. Замок строится из средневековых кирпичей, а угроза использует высокоточные снаряды.
Пример: требование криптографической защиты информации. Для его выполнения часто выбирается сертифицированный шифратор, который поддерживает только определённые, устаревшие алгоритмы и не имеет API для интеграции с современными системами управления ключами или облачными хранилищами. Решение работает, но создаёт узкие места и сложности в эксплуатации, которые сами становятся источником рисков.
Что можно сделать иначе
Несмотря на системные проблемы, существуют подходы, позволяющие строить защиту более устойчиво, даже в рамках регуляторных требований.
- Интеграция реального аудита в процесс: Внутренние проверки безопасности должны оценивать не только наличие средств, но и их реальную эффективность. Например, тестирование на проникновение (pentest) в рамках подготовки к аттестации может показать, какие формально выполненные требования фактически не работают.
- Фокус на критичных системах: Определите ядро информационной инфраструктуры — системы, от которых зависит непрерывность бизнеса и сохранность критичных данных. Примените к ним максимальный набор мер защиты, включая те, которые не требуются регулятором напрямую, но необходимы по логике угроз. Для менее критичных систем можно соблюдать формальные требования.
- Динамическое соответствие: Создайте внутренние процессы, которые обеспечивают распространение политик защиты на все новые компоненты инфраструктуры автоматически или по строгому регламенту. Аттестация не должна быть «моментальным снимком», она должна описывать работающий механизм поддержания уровня защиты.
- Интерпретация требований с точки зрения рисков: При реализации каждого пункта методики задавайте вопрос: «Как именно это действие снижает один из наших основных рисков?». Если ответа нет, возможно, реализация требует корректировки. Это позволяет формальные требования превращать в реальные защитные механизмы.
Цель — превратить замок из песка в крепость на скале. Это возможно, если перестать воспринимать регуляторику как сборник галочек и начать использовать её как каркас для построения индивидуальной, риск-ориентированной системы защиты.
Ключевой вывод: волна всегда придёт. Задача не в том, чтобы построить замок, который её остановит, а в том, чтобы построить его там, где он действительно нужен, и из материалов, которые действительно могут противостоять давлению.