"Общие критерии", часть 2. Функциональные требования безопасности

Защита функций безопасности объекта оценки

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

Класс FPT (защита функций безопасности объекта оценки) включает шестнадцать семейств (больше, чем какой-либо другой класс   функциональных требований ), которые можно разбить на четыре группы:

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

Важнейший принцип архитектурной безопасности - невозможность обхода защитных средств. Семейство FPT_RVM ( посредничество при обращениях ) предназначено для достижения этой цели. Входящий в него единственный компонент FPT_RVM.1 (невозможность обхода политики безопасности ОО) предписывает, чтобы функции, проводящие в жизнь политику безопасности, вызывались и успешно выполнялись прежде любого другого действия, предусмотренного ПБ.

Еще один фундаментальный принцип архитектурной безопасности поддерживается семейством FPT_SEP ( разделение доменов ). Минимально необходимо отделение домена функций безопасности ( компонент FPT_SEP.1), то есть функции безопасности должны поддерживать домен безопасности, который защищает их от вмешательства не облеченных доверием субъектов и искажений с их стороны (кроме того, должно быть реализовано разделение доменов безопасности субъектов). Максимальный уровень потребует реализации полного монитора обращений ( компонент FPT_SEP.3), то есть предоставление отдельного домена той части функций безопасности, которая проводит в жизнь политики управления доступом и/или информационными потоками.

Защитой реализации функций безопасности занимаются четыре семейства. Самое простое из них (по формулировке, но не по воплощению и/или проверке), FPT_FLS ( безопасность при сбое ), содержит требование, чтобы политика безопасности не нарушалась при сбоях заданных типов.

Обеспечения высокой доступности и корректной работы функций безопасности вопреки возможным сбоям добивается и более сложное семейство FPT_RCV ( надежное восстановление ). FPT_RCV.4 (восстановление функции) предписывает, что функция безопасности либо нормально завершается, либо, для предусмотренных сценариев сбоев, восстанавливается ее устойчивое и безопасное состояние. Первые три его компонента отвечают за восстановление - ручное, автоматическое и автоматическое без недопустимой потери. Для ручного восстановления требуется, чтобы после сбоя функции безопасности перешли в режим аварийной поддержки, оставляющего возможность возврата ОО к безопасному состоянию. Автоматическое восстановление без недопустимой потери означает следующее:

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

Семействo FPT_PHP ( физическая защита ) требует наличия средств выявления и реагирования на несанкционированный физический доступ к частям ОО, участвующим в реализации функций безопасности. Компонент FPT_PHP.1 (пассивное обнаружение физического нападения) можно отнести к средствам контроля целостности, так как он требует однозначного обнаружения физического воздействия, которое может угрожать выполнению функций безопасности; информация о наличии или отсутствии подобного воздействия предоставляется по запросу. Усиливающий компонент FPT_PHP.2 (оповещение о физическом нападении) предусматривает постоянный контроль за определенными элементами и оповещение назначенного пользователя о подобных происшествиях. Наконец, компонент FPT_PHP.3 (противодействие физическому нападению) требует автоматической реакции, предотвращающей нарушение политики безопасности.

Семейство FPT_TST ( самотестирование функций безопасности ) состоит из одного компонента, но служит сразу двум целям: выполняет собственно самотестирование (при запуске, периодически, по запросу уполномоченного пользователя и т.п.), а также осуществляет контроль целостности данных и выполняемого кода функций.

Объединение в одном компоненте двух существенно разных видов требований представляется странным (тестирование имеет мало общего с контролем целостности кода и, тем более, изменяемых данных), но позволяет плавно перейти к третьей группе семейств класса 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 (метки времени) требует предоставления надежных меток времени в пределах объекта оценки. Подобные метки необходимы, например, функциям протоколирования и управления.