Система сертификации средств защиты информации

• сертифицированное средство должно оставаться сопровождаемым;
• уязвимости и недостатки должны устраняться в рамках процедур поддержки безопасности;
• обновления и изменения документации должны доводиться до потребителя;
• прекращение поддержки может повлечь приостановление действия сертификата.

Это особенно важно для программных и программно-технических средств, где риск устаревания функций безопасности высок.

Уровень доверия характеризует глубину уверенности в безопасности средства и строгость требований к его разработке, испытаниям и поддержке.

• установлено 6 уровней доверия;
• 6 уровень — самый низкий, 1 уровень — самый высокий;
• уровень доверия выбирается не произвольно, а в привязке к классу/категории защищаемой системы;
• для ряда средств именно уровень доверия становится центральным критерием пригодности.

Для более высоких уровней применимость расширяется на более чувствительные контуры, включая обработку защищаемой информации более высокого уровня значимости.

• модель безопасности средства;
• описание архитектуры безопасности;
• функциональная спецификация интерфейсов и функций;
• эскизный и технический проекты;
• документация по управлению конфигурацией;
• документация по безопасной разработке;
• эксплуатационная документация пользователя и администратора.

• для средств с функцией разграничения доступа описываются политики управления доступом;
• для средств фильтрации — политики фильтрации информационных потоков;
• на более высоких уровнях доверия требуется формальное или формализованное описание и доказательство корректности условий безопасности.

1. Можно ли обойти функции безопасности средства?
2. Защищены ли сами функции безопасности от несанкционированного доступа?
3. Безопасен ли процесс инициализации и запуск средства?

• тестовая документация должна покрывать интерфейсы, подсистемы и модули — в зависимости от уровня доверия;
• испытания по выявлению уязвимостей и НДВ обязательны для всех уровней доверия;
• для 4 уровня доверия и выше существенным становится анализ скрытых каналов;
• доказательная база оформляется в протоколах и техническом заключении.

Для разработчика это означает необходимость готовить средство к внешней проверке, а не только к внутреннему QA.

Безопасная разработка и сертификация продукта связаны, но это разные объекты оценки.

• наличие руководства и документации по БРПО;
• наличие инструментальных средств разработки и анализа ПО;
• реальное выполнение процессов безопасной разработки, описанных в документации;
• реализацию процедур поддержки безопасности ПО.

Для среды РБПО базовым ориентиром выступает ГОСТ Р 56939-2024, а сама процедура сертификации процессов закреплена приказом № 240.

• система предназначена для средств, планируемых к применению в Вооружённых Силах РФ;
• функции федерального органа по сертификации выполняются в структуре Минобороны;
• есть своя процедура подачи заявки, проведения испытаний, выдачи и продления сертификатов;
• особое значение имеют режим секретности, лицензии и взаимодействие с военным представительством.

• ФСТЭК — ключевой регулятор по технической защите информации и сертификации большинства СЗИ вне криптографии;
• ФСБ — регулятор по криптографической защите информации и ряду смежных вопросов;
• Минобороны — отдельная система сертификации для средств, предназначенных для применения в Вооружённых Силах РФ.

В лекции важно не смешивать эти контуры и употреблять только краткие наименования регуляторов.

1. Наличие сертификата и его применимость к нужному контуру.
2. Схему сертификации: образец, партия или серийное производство.
3. Срок действия сертификата и актуальность технической поддержки.
4. Соответствие уровня доверия или класса требованиям объекта защиты.
5. Отсутствие ограничений по версии, составу и среде функционирования.

• смотрят только на наличие сертификата, но не на схему сертификации;
• не проверяют актуальность техподдержки и обновлений;
• используют средство вне пределов заявленной среды функционирования;
• смешивают сертификацию СЗИ с сертификацией процессов разработки;
• не связывают требования к средству с категорией или классом самой системы.

• приказ № 55 действует с изменениями 2021 и 2022 годов;
• приказ № 76 продолжает использоваться как основа привязки уровней доверия к средствам ТЗИ и средствам ОБИТ;
• приказ № 240 о сертификации процессов БРПО действует и в 2025 году в него внесены изменения;
• ГОСТ Р 56939-2024 введён в действие и применяется как основной стандарт по безопасной разработке в данном контексте;
• для ГИС действуют новые требования приказа № 117 от 11.04.2025, поэтому при учебных примерах ссылаться на приказ № 17 уже нельзя без оговорки.

1. Когда сертификат на серийное производство не гарантирует допустимость конкретной поставки?
2. Почему уровень доверия нельзя выбирать отдельно от класса или категории системы?
3. Чем сертификация процессов БРПО помогает разработчику, но не заменяет сертификацию СЗИ?
4. Какие риски возникают при прекращении технической поддержки средства?