Защита функций безопасности объекта оценки
Мы продолжаем рассмотрение классов функциональных требований, направленных на достижение высокоуровневых целей безопасности.
Класс FPT (защита функций безопасности объекта оценки) включает шестнадцать семейств (больше, чем какой-либо другой класс функциональных требований), которые можно разбить на четыре группы:
-
архитектурная безопасность;
- защита реализации функций безопасности;
- защита данных функций безопасности;
- инфраструктурные требования.
Важнейший принцип архитектурной безопасности - невозможность обхода защитных средств. Семейство FPT_RVM (посредничество при обращениях) предназначено для достижения этой цели. Входящий в него единственный компонент FPT_RVM.1 (невозможность обхода политики безопасности ОО) предписывает, чтобы функции, проводящие в жизнь политику безопасности, вызывались и успешно выполнялись прежде любого другого действия, предусмотренного ПБ.
Еще один фундаментальный принцип архитектурной безопасности поддерживается семейством FPT_SEP (разделение доменов). Минимально необходимо отделение домена функций безопасности (компонент FPT_SEP.1), то есть функции безопасности должны поддерживать домен безопасности, который защищает их от вмешательства не облеченных доверием субъектов и искажений с их стороны (кроме того, должно быть реализовано разделение доменов безопасности субъектов). Максимальный уровень потребует реализации полного монитора обращений (компонент FPT_SEP.3), то есть предоставление отдельного домена той части функций безопасности, которая проводит в жизнь политики управления доступом и/или информационными потоками.
Защитой реализации функций безопасности занимаются четыре семейства. Самое простое из них (по формулировке, но не по воплощению и/или проверке), FPT_FLS (безопасность при сбое), содержит требование, чтобы политика безопасности не нарушалась при сбоях заданных типов.
Обеспечения высокой доступности и корректной работы функций безопасности вопреки возможным сбоям добивается и более сложное семейство FPT_RCV (надежное восстановление).
Объединение в одном компоненте двух существенно разных видов требований представляется странным (тестирование имеет мало общего с контролем целостности кода и, тем более, изменяемых данных), но позволяет плавно перейти к третьей группе семейств класса FPT (защита данных функций безопасности). В эту группу входят шесть семейств, три из которых, FPT_ITA, FPT_ITC и FPT_ITI, отвечают, соответственно, за доступность, конфиденциальность и целостность экспортируемых данных функций безопасности. Отметим, что доступность должна быть обеспечена с заданной вероятностью, а контроль целостности в общем случае предусматривает возможность восстановления поврежденных данных удаленным доверенным изделием ИТ.
Семейство FPT_TDC содержит требование согласованной интерпретации данных, совместно используемых функциями безопасности ОО и другим доверенным изделием ИТ. Явных требований к контролю импортируемых данных в классе FPT (в отличие от FDP) нет, хотя из соображений симметрии они, безусловно, должны присутствовать (см. выше семейства FDP_ETC и FDP_ITC).
Пятое семейство группы, FPT_ITT (передача данных функций безопасности в пределах объекта оценки), аналогично рассмотренному ранее семейству из класса защиты данных пользователя FDP_ITT (передача в пределах ОО), но не предусматривает обеспечения доступности и разделения по атрибутам при контроле целостности. Справедливости ради укажем, однако, что в компоненте FPT_ITT.3 более детально специфицированы обнаруживаемые виды нарушений целостности: модификация, подмена, перестановка, удаление данных.
Семейство FPT_TRC отвечает за согласованность данных функций безопасности при дублировании в пределах ОО. Здесь следует обратить внимание на требования элемента FPT_TRC.1.2: если части ОО, содержащие дублируемые данные, были разъединены, необходимо обеспечить согласованность таких данных после восстановления соединения перед обработкой запросов к заданным функциям безопасности. Отметим, что к взаимодействию с удаленным доверенным изделием ИТ требование согласованности данных не предъявляется.
В целом же остается неясным смысл разнесения по разным классам требований защиты данных пользователя и функций безопасности. Последние, кроме того, трактуются как одноуровневые, для них не предусмотрено разделение по атрибутам, что для сложных систем может оказаться неприемлемым.
Требования, которые мы назвали инфраструктурными, вошли в состав четырех семейств. Семейство FPT_AMT (тестирование базовой абстрактной машины) определяет требования к тестированию, демонстрирующему правильность предположений, обеспечиваемых абстрактной машиной (аппаратно-программной платформой), лежащей в основе функций безопасности.
Семейство FPT_RPL (обнаружение повторного использования) нацелено на выявление повторного использования сущностей различных типов (например, сообщений, запросов на обслуживание и ответов на запросы) и выполнение заданных ответных действий.
Семейство FPT_SSP (протокол синхронизации состояний) на самом деле содержит требования одностороннего или взаимного надежного подтверждения при обмене данными между функциями безопасности в распределенной среде.
Наконец, семейство FPT_STM (метки времени) требует предоставления надежных меток времени в пределах объекта оценки. Подобные метки необходимы, например, функциям протоколирования и управления.
