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