ГОСТ Р ИСО/МЭК 18045— 2008
С целью удостовериться, что все функциональные требования безопасности, определенные в ЗБ,
охвачены функциональной спецификацией, оценщик может построить отображение краткой спецификации 0
0 на функциональную спецификацию. Такоеотображение могло быть уже представлено самим разработ
чиком вкачестве свидетельства для удовлетворения требований соответствия представлений (ADV_RCR.‘ ); в
этом случае оценщику необходимо только верифицировать полноту данного отображения, удостоверив
шись. что все функциональные требования безопасности отображены на соответствующие представления
ИФБО в функциональной спецификации.
12.6.2.4.2 Шаг оценивания 3:ADV_FSP.1-8
Оценщикдолжен исследоватьфункциональную спецификацию, чтобы сделать заключение, является
ли она точным отображением функциональныхтребований безопасности ОО.
Для каждого интерфейса функции безопасности с конкретными характеристиками вфункциональной
спецификации должна иметься подробная информация, вточности соответствующая спецификации в ЗБ.
Например, если ЗБ содержит требования аутентификации пользователя на основе пароля длиной в восемь
символов, то ОО должен иметьвосьмисимвольные пароли; если вфункциональной спецификации описаны
шестисимвольные пароли фиксированной длины, то функциональная спецификация не является точным
отражением требований.
Для каждого интерфейса, описанного вфункциональной спецификации, который влияет на управляе
мый ресурс, оценщикделает заключение, возвращает ли интерфейс всоответствии с одним из требований
безопасности некоторый код ошибки, указывающий на возможный сбой; если код ошибки не возвращает
ся, то оценщикделает заключение, необходим ли в этом случае возврат кода ошибки. Например,
операци онная система может представлять интерфейс для ОТКРЫТИЯ управляемого объекта.
Описание этого интерфейса может включать в себя код ошибки, который указывает на то. что доступ к
объекту не был санкционирован. Если такого кода ошибки не существует, то оценщику следует
подтвердить, что это при емлемо (потому что. возможно, посредничество в доступе выполняется при
ЧТЕНИИ и ЗАПИСИ, а не при ОТКРЫТИИ).
12.6.3 Оценка проекта верхнего уровня (ADV_HLD.2)
12.6.3.1 Цели
Цель данного подвида деятельности — сделать заключение, дано ли в проекте верхнего уровня
описание ФБО в терминах основных структурных единиц (т.е. подсистем), описание интерфейсов этих
структурных единиц и является ли проект верхнего уровня корректной реализацией функциональной специ
фикации.
12.6.3.2 Исходные данные
Свидетельствами оценки для этого подвида деятельности являются:
a) ЗБ:
b
) функциональная спецификация;
c) проект верхнего уровня.
12.6.3.3 Действие ADV_HLD.2.1Е
12.6.3.3.1 Шагоценивания 3:ADV_HLD.2-1
ИСО/МЭК 15408-3 ADVJHLD.2.1C: Представление проекта верхнего уровня должно быть нефор
мальным.
Оценщик должен исследовать проект верхнего уровня, чтобы сделать заключение, содержит ли он
весь необходимый неформальный пояснительный текст.
Если весь проект верхнего уровня является неформальным, то рассматриваемый шагоценивания не
применяют и поэтому считают удовлетворенным.
Для техчастей проекта верхнего уровня, которые трудныдля понимания только на основе полуфор
мального или формального описания, необходимо вспомогательноеописание в повествовательной форме
(например, чтобы пояснить значения всех формальных обозначений).
12.6.3.3.2 Шагоценивания 3:ADV_HLD.2-2
ИСО/МЭК 15408-3 ADV_HLD.2.2C: Проект верхнего уровня должен быть внутренне непротиво
речивым.
Оценщикдолжен исследовать представление проекта верхнего уровня, чтобы сделать заключение о
его внутренней непротиворечивости.
Руководство по анализу непротиворечивости см.вА.З «Анализ непротиворечивости» (приложе
ние А).
Оценщик подтверждает правильностьспецификаций интерфейсов конкретной подсистемы, удостове
рившись. что спецификации интерфейсов согласованы с описанием предназначения данной подсистемы.
107