Уровень доверия

Кроме функций безопасности, в структуру документа, описывающего профиль защиты, входит раздел "Требования доверия к безопасности". Эти требования, как и функции безопасности, выбираются разработчиком профиля из "каталога" требований доверия, фактически составляющего всю третью часть "Общих критериев". Однако, в отличие от "формального" набора функций, для требований доверия в стандарте сформированы определенные наборы, которые называются "Оценочными уровнями доверия" (ОУД). Самый низкий уровень доверия - 1-й, самый высокий - 7-й.

Если провести аналогию с определениями, уже знакомыми нам по руководящим документам (РД) Гостехкомиссии РФ, то ОУД имеют много общего с уровнями проверки недекларированных возможностей (см. РД Гостехкомиссии России "Защита от несанкционированного доступа к информации. Часть 1. Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия недекларируемых возможностей").

Но по сравнению с РД в ОК значительно больше внимания уделено процедурам поставки (важно, чтобы при выполнении процедуры поставки программный продукт был защищен от подмены или модификации) и поддержке продукции. Программный продукт, который не поддерживается должным образом разработчиком, не может считаться "доверенным", не может претендовать на высокий уровень ОУД, а значит, не может применяться для защиты ценной информации.

Задание по безопасности

Если профиль защиты - это описание функционала продукта, не зависящее от его реализации и имеющее много общего с техническим заданием, то задание по безопасности содержит и список функций безопасности профиля, и описание того, как эти функции безопасности реализованы непосредственно в продукте. Определение задания по безопасности в стандарте таково: "Совокупность требований безопасности и спецификаций, предназначенная для использования в качестве основы для оценки конкретного ОО". Если продолжить аналогию с проектной документацией, то задание по безопасности имеет много общего с техническими условиями на СЗИ.

Качество жизни

При всей своей объемности и, на первый взгляд, сложности новый ГОСТ дает в руки разработчикам дополнительные, доселе недоступные возможности, демонстрируя достаточную гибкость как инструментарий. Если разработчик системы защиты считает, что его продукт пусть не намного, но все же в чем-то превосходит продукт конкурента, то он всегда может создать собственный профиль защиты (который имеет пусть не намного, но больше функций безопасности) и сертифицировать по нему свою продукцию. Кроме того, немаловажно, что гибкость ОК позволяет довольно быстро (по сравнению с разработкой прежних РД Гостехкомиссии) реагировать на появление новых информационных угроз и СЗИ, защищающих от этих угроз.

Такая гибкость имеет и свои недостатки, причем, как обычно, эти недостатки - продолжение ее достоинств. Ясно, что, следуя описанной логике создания профилей защиты, можно в скором времени "наплодить" их огромное количество. Как следствие, появится потребность в экспертах, которые будут хорошо ориентироваться в "Общих критериях", в существующих профилях, смогут разрабатывать профили защиты и задания по безопасности (а такая работа стоит отнюдь не дешево).