ГОСТ Р ИСО/МЭК18045— 2008
11.6.2.3.4 Шаг оценивания 2:ADV_FSP.1-4
Оценщикдолжен исследовать функциональную спецификацию, чтобы сделать заключение, описаны
ли в ней все внешние интерфейсы функций безопасности ОО.
Для ОО. поотношению ккоторому не имеется угроз, связанных сдействиями злонамеренных пользо
вателей (т.е. в его ЗБ справедливо не включены компоненты требований из семейств FPT_PHP «Физичес
кая защита ФБО». FPT_RVM «Посредничество при обращениях» и FPT_SEP «Разделение домена»), в
функциональной спецификации (и более подробно в описаниидругих представлений ФБО) должны быть
описаны только интерфейсы ФБО.Отсутствие в ЗБкомпонентов требований из семейств FPT PHP. FPT_RVM
и FPT_SEP предполагает, что никакие способы обхода свойств безопасности не рассматриваются, а поэто
му не рассматривается какое-либо воздействие, которое другие интерфейсы могли бы оказывать на ФБО.
С другой стороны, если по отношению к ОО имеются угрозы, связанные сдействиями злонамерен
ных пользователей или обходом (т.е. в его ЗБ включены компоненты требований из семейств FPT_PHP
«Физическая защита ФБО». FPT_RVM «Посредничество при обращениях» и FPT_SEP «Разделение доме
на»), то в функциональной спецификации должны быть описаны все внешние интерфейсы, но только в
объеме, достаточном для понимания их влияния на ФБО: интерфейсы функций безопасности (т.е. интер
фейсы Ь и с на рисунке 7)должны быть описаны полностью, в то время какдругие интерфейсы описывают
только в объеме,достаточном для понимания того, что ФБО являются недоступными через рассматривае
мый интерфейс (т.е. что интерфейс относится к типу а. а не типу Ь на рисунке 7). Включение компонентов
требований из семейств FPT_PHP, FPT_RVM и FPT_SEP предполагает возможность некоторого влияния
всех интерфейсов на ФБО. Поскольку каждый внешний интерфейс — это потенциальный интерфейс ФБО,
функциональная спецификациядолжна содержать описание каждого интерфейса сдетализацией, доста
точнойдля того, чтобы оценщик мог сделать заключение, является ли интерфейс значимым сточки зрения
безопасности.
Некоторые архитектуры позволяют без особого труда предоставить такое описание интерфейсов с
достаточной степенью детализации для групп внешних интерфейсов. Например, архитектура на основе
ядра такова, что все вызовы операционной системы обрабатываются программами ядра; любые вызовы,
которые могли бы нарушить ПБО. запрашиваются программой, у которой есть соответствующие привиле
гии. Все программы, выполняемые в привилегированном режиме, должны быть включены вфункциональ
ную спецификацию. Все программы, внешние по отношению кядру и выполняемые в непривилегирован
ном режиме, не способны влиять на ПБО (т.е. такие программы являются интерфейсами типа а. а не Ь на
рисунке 7), а следовательно, могут не быть включены вфункциональную спецификацию. Несмотря на то,
что архитектура на основе ядра можетускорить понимание оценщиком описания интерфейсов, такая архи
тектура не является обязательной.
11.6.2.3.5 Шаг оценивания 2:ADV_FSP.1-5
Оценщик должен исследовать представление ИФБО. чтобы сделать заключение, адекватно ли и
правильно ли внем описан режим функционирования ОО на каждом внешнем интерфейсе, включая описа
ние результатов, нештатныхситуаций и сообщений об ошибках.
Оценивая адекватность и правильность представления интерфейсов, оценщик использует функцио
нальную спецификацию, краткую спецификацию ОО из ЗБ. руководства пользователя и администратора,
чтобы оценить следующие факторы;
a) все ли относящиеся к безопасности, вводимые пользователем параметры (или характеристики
этих параметров) определены. Для полноты необходимо, чтобы были определены параметры, которыми
пользователь не управляет непосредственно, если они могут быть использованы администраторами;
b
) все ли относящиеся к безопасности режимы функционирования ОО. описанные в рассматривае
мых руководствах, отражены при описании семантики в функциональной спецификации. Данное описание
включает в себя идентификацию режима функционирования ОО в терминах событий и влияния
каждого события. Например, если операционная система имеет развитой интерфейс файловой
системы и преду сматривает различные коды ошибокдля разных причин неоткрытия файла по запросу
(например, доступ запрещен, такого файла не существует, файл используетсядругим пользователем,
пользователю не раз решено открывать файл после 5 ч вечера и т.д.). то в функциональной
спецификациидолжно быть поясне но. когда файл открывается по запросу, а когда возвращается код
ошибки. (Хотя в функциональной специ фикации могут быть перечислены все возможные причины
ошибок, особой необходимости втакой детали зации нет.) В описание семантики должно быть включено
описание того, каким образом требования безо пасности применены к интерфейсам (например, является
ли использование интерфейса потенциально под вергаемым аудиту событием, и если да. то какая
информация может быть зафиксирована);
72