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

Сертификация — это не формальность, а механизм доверия к средству защиты информации.

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

На практике для слушателя важны три вопроса: что сертифицируется, в какой системе, и для каких контуров это требуется.

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

Сама обязанность применения конкретного класса/уровня средств выводится из отраслевых требований к объекту защиты.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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