ГОСТ Р ИСО/МЭК 18045—2013
(см. ADV_FSP.1-5 для прослеживания между ФТБ для 0 0 и ИФБО). Следует учесть, что такое про
слеживание иногда необходимо представлять на уровне детализации ниже, чем уровень детализации
компонента или даже элемента требований, из-за операций (назначения, уточнения, выбора), выпол
няемых над функциональным требованием автором ЗБ.
Например, компонент FDP_ACC.1 содержит элемент с операциями назначения. Если бы в ЗБ
содержалось, например десять правил в отношении назначения для данного компонента FDP_ACC.1, и
эти правила были бы охвачены тремя различными ИФБО. то для оценщика некорректно было бы
проследить FDP_ACC.1 к ИФБО А. В и С и утверждать о завершении шага оценивания. Вместо это го
оценщик должен был бы проследить FDP_ACC.1 (правило 1) к ИФБО A: FDP_ACC.1 (правило 2) к
ИФБО В и т.д. Может иметь место и случай, когда интерфейс является интерфейсом адаптера (на
пример IOCTL) и тогда прослеживание должно быть определенным к набору параметров для данного
интерфейса.
Оценщик должен осознавать, что для требований, которые незначительно проявляются
или не проявляются вовсе на границах ФБО (например FDP_RIP), не ожидается, что эти требования
будут прослежены к ИФБО. Анализ таких требований будет выполняться в процессе анализа проекта
0 0 (ADVJTDS), когда он включен в ЗБ. Важно отметить, что так как параметры, связанные с ИФБО,
должны быть полностью специфицированы, оценщику следует быть в состоянии сделать
заключение о том. все ли аспекты ФТБ реализованы на интерфейсном уровне.
10.4.1.4.2 Шаг оценивания ADV_FSP.1-7
Оценщик должен исследовать функциональную спецификацию, чтобы сделать заключение,
что она является точным отображением ФТБ.
Для каждого функционального требования в ЗБ. которое оказывает видимый эффект на границах
ФБО. информация в связанном с ним ИФБО специфицирует требуемые функции, описанные в требова
нии. Например, если в ЗБ содержится требование наличия списков контроля доступа и единственный
ИФБО. прослеживаемый к этому требованию, специфицирует функции Unix-лодобных разрядов защи
ты, тогда функциональная спецификация не является точной в отношении требований.
Оценщик должен осознавать, что для требований, которые незначительно проявляются
или не проявляются вовсе на границах ФБО (например FDP_RIP), не ожидается, что эти требования
будут прослежены к ИФБО. Анализ таких требований будет выполняться в процессе анализа проекта
0 0 (ADV_TDS), когда он включается в ЗБ.
10.4.2Подвид деятельности по оценке (ADV_FSP.2)
10.4.2.1 Цели
Цель данного подвида деятельности — сделать заключение, предоставил ли разработчик описа
ние ИФБО в терминах их назначения, метода использования и параметров. Кроме того, для каждого
осуществляющего ФТБ интерфейса ФБО описываются действия, результаты и сообщения об ошибках,
осуществляющие выполнение ФТБ.
10.4.2.2 Исходные данные
Свидетельствами оценкидля этого подвида деятельности, требуемыми шагами оценивания, являются:
a) ЗБ;
b
) функциональная спецификация:
c) проект 00.
Свидетельствами оценки для этого подвида деятельности, которые используются в случае
их включения в ЗБ по ОО. являются:
a) описание архитектуры безопасности.
b
) руководство пользователя по эксплуатации.
10.4.2.3 Действие ADV_FSP.2.1E
ИСО/МЭК 15408-3 ADV_FSP.2.1C: В функциональной спецификации должны быть полностью
представлены ФБО.
10.4.2.3.1 Шаг оценивания ADV_FSP.2-1
Оценщик должен исследовать функциональную спецификацию, чтобы сделать заключение о том,
что в ней полностью представлены ФБО.
Идентификация ИФБО — необходимая предпосылка для всех действий данного подвида деятель
ности. Для идентификации ИФБО должны быть идентифицированы ФБО (в рамках шагов оценивания
семействаADVJTDS «Проект ОО»), Эта деятельность может быть проведена на высоком уровне, чтобы
удостовериться, что не упущены крупные группы интерфейсов (сетевых протоколов, аппаратных средств,
файлов конфигурации) или на низком уровне — как часть оценки функциональной спецификации.
58