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