ГОСТ Р ИСО/МЭК 15408-3 — 2008
Функциональная спецификация должнасодержатьформальное описание ФБОи ихвнешних интер
фейсов. поддержанное, где это необходимо, неформальным пояснительным текстом.
14.1.7.2.2 ADV_FSP.4.2C
Функциональная спецификация должна быть внутренне непротиворечивой.
14.1.7.2.3 ADV_FSP.4.3C
Функциональная спецификациядолжнасодержать описание назначения и методов использования
всех внешних интерфейсов ФБО, обеспечивая полнуюдетализацию всех результатов, нештатных ситуа
ций и сообщений обошибках.
14.1.7.2.4 ADV_FSP.4.4C
Функциональная спецификациядолжна полностью представить ФБО.
14.1.7.2.5 ADV_FSP.4.5C
Функциональная спецификациядолжна включатьв себяобоснование того,чтоФБО полностью пред
ставлены.
14.1.7.3 Элементы действий оценщика
14.1.7.3.1 ADV_FSP.4.1E
Оценщикдолжен подтвердить, чтопредставленная информация соответствует всем требованиям к
содержаниюи представлению свидетельств.
14.1.7.3.2 ADV_FSP.4.2E
Оценщикдолженсделать независимое заключение, что функциональная спецификация — точное и
полноеотображение функциональных требований безопасности ОО.
14.2Проект верхнего уровня (ADV_HLD)
14.2.1 Цели
Проект верхнего уровня ОО представляет описание ФБО в терминах основныхструктурных частей
(то есть подсистем) исвязывает эти части с функциями, которые они выполняют. Требования к проекту
верхнего уровня предназначены для обеспечения доверия к тому, что ОО имеет архитектуру, приемлемую
для реализации функциональных требований безопасности ОО.
Проект верхнегоуровня уточняет функциональнуюспецификацию, преобразуя ее в подсистемы. Для
каждой подсистемы ФБО проект верхнегоуровняописывает ее назначение, а также идентифицирует фун
кции безопасности, включаемые в подсистему. В проекте верхнего уровня также определяются взаимо
связи всех подсистем. Эти взаимосвязи будут представлены как внешние интерфейсы поданным, управ
лению и т.д.
14.2.2 Ранжирование компонентов
Компоненты вданном семействе ранжированы на основе степени формализации, требуемой для
проекта верхнего уровня, и на степенидетализации, требуемой для спецификаций интерфейса.
14.2.3 Замечания по применению
Ожидается, что разработчик опишет проект ФБО в терминах подсистем. Термин «подсистема» ис
пользуют здесьдля выражения идеи декомпозиции ФБО на относительно небольшое числочастей. Даже
если разработчику нетребуется иметь «подсистемы», ожидается, что он представит подобный уровень
декомпозиции. Например, проектможет быть декомпозирован путем использования «уровней», «доменов»
или «серверов».
Выражение «функциональные возможностибезопасности» используют, чтобы представить совокуп
ность выполняемых подсистемой действий, которые участвуют в осуществлении функций безопасности,
реализуемых ОО. Это разграничение сделано потому, чтосоставные части проекта, такие какподсистемы
или модули, не обязательно однозначноотождествляются с конкретными функциями безопасности. В то
время какданная подсистема может прямосоответствовать какодной, так и нескольким функциям безо
пасности. возможнотакже, что несколькоподсистем необходимо объединитьдля реализации единствен
ной функции безопасности.
Выражение «подсистема, осуществляющая ПБО» относится к подсистеме, которая прямо или кос
венно содействует осуществлению ПБО.
Элементы ADV_HLD.*.2Eданногосемействаопределяют требование вынесения оценщиком заклю
чения отом. чтопроект верхнего уровняявляется точным и полным отображением функциональных требо
ваний безопасности ОО. Это обеспечивает прямоесоответствие междуфункциональными требованиями
безопасности ООипроектом верхнего уровня вдополнениек попарным соответствиям, требуемым семей
ством ADV_RCR«Соответствие представлений». Ожидается,что оценщик использует свидетельство, вклю
ченное в ADV_RCR «Соответствие представлений», как основаниедля этого заключения, а требование
полноты предполагает соотнесение с уровнем абстракции проекта верхнего уровня.
58