Но разработка профилей защиты – дело непростое. Во-первых, их требуется очень много. Даже если взять все меры защиты из приказов ФСТЭК и перемножить их на количество классов защиты сертифицированных средств, то получается больше сотни документов. Но проблема даже не в этом. Ведь рыночных категорий ПО очень много, и границы между ними часто размыты. Более того, изменение этих границ – это оружие в конкурентной борьбе. Очень часто компании, желая обойти своих конкурентов, изобретают новую категорию или придумывают новое название для существующих, или комбинируют в одном продукте функции из разных категорий. И если для средств защиты количество категорий еще как-то можно подсчитать, то категории прикладного ПО, в котором, тем не менее, могут присутствовать функции защиты данных, которые подлежат оценке соответствия требованиям безопасности информации, просто неисчислимы. Кроме того, между началом активного использования новой категории и принятием соответствующего ей профиля защиты всегда будет задержка.
Вот почему одних только профилей защиты недостаточно. Поэтому требования ФСТЭК в виде профилей защиты и уровней доверия могут быть расширены требованиями заявителя. Эти требования составляются в виде документов. Виды этих документов перечислены в положении о сертификации. В них и описывается та часть требований, которая специфична для конкретного класса или даже продукта. Конечно, итоговые требования получаются не вполне прозрачными, сложными, но зато это дает гибкость. И можно провести сертификацию и аттестацию по требованиям безопасности информации почти для любого ПО, в котором есть что сертифицировать, то есть присутствуют функции безопасности.
Во-первых, это задание по безопасности. Бывает так, что продукт, хотя и относится к какой-то категории, для которой есть профиль защиты, имеет дополнительные функции защиты информации. Они тоже должны быть сформулированы в виде требований, на соответствие которым будут проводиться сертификационные испытания. То есть задание по безопасности дополняет профиль. Задание по безопасности – конструкторский документ, формат которого задан в ГОСТ.
Но бывает и так, что для продукта вообще нет подходящего профиля. Чаще всего это бывает с прикладным ПО, в котором есть функции защиты. Тогда требования обеспечения безопасности (защиты) информации добавляются в технические условия. Они фактически описывают продукт, его основные характеристики, в том числе функции (механизмы) защиты информации. Цель этого документа – зафиксировать заявленные характеристики продукта, на соответствие которым и будут проходить сертификационные испытания. Технические условия — это тоже конструкторский документ, его формат должен соответствовать ГОСТ 2.114-95.
Разумеется, требования заявителя к функциям защиты не могут быть какими угодно, а должны быть согласованы ФСТЭК, то есть мы имеем дело с «требованиями к требованиям». Что проверяет ФСТЭК при согласовании? Соответствие показателей функций защиты своим
методическим указаниям для государственных информационных систем (от 11 февраля 2014 года), где эти указатели расписаны шире и подробнее всего. То есть если в продукте реализована какая-то функция защиты, то берется такая же функция из методических указаний, и проверяется, чтобы функция в продукте была реализована не хуже по защищенности.