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