ГОСТ Р ИСО/МЭК 15408-3 — 2008
Описание архитектуры должно показать, что взаимные связи были минимизированы, и содержать
логическоеобоснованиеоставшихся связей.
14.4.6.3.6 ADVJNT.3.6C
Описание архитектуры должносодержать изложение, каким образом все ФБО структурированы для
минимизации сложности.
14.4.6.3.7 ADVJNT.3.7C
Описание архитектуры должно содержать логическое обоснование включения в ФБО
каждого модуля, не участвующего в осуществлении ПБО.
14.4.6.4 Элементы действий оценщика
14.4.6.4.1 ADVJNT.3.1E
Оценщикдолжен подтвердить, чтопредставленная информация соответствует всем требованиям к
содержанию ипредставлению свидетельств.
14.4.6.4.2 ADVJNT.3.2E
Оценщик должен сделать независимое заключение о том. что ипроект нижнегоуровня, ипредстав
ление реализации согласуютсяс описанием архитектуры.
14.4.6.4.3 ADVJNT.3.3E
Оценщик должен подтвердить, что части ФБО, осуществляющие какие-либо политики управ
ления доступом и/или информационными потоками, достаточно просты для анализа.
14.5 Проект нижнего уровня (ADVJ.LD)
14.5.1 Цели
Проект нижнего уровня ОО содержит описание внутреннегосодержания ФБО в терминах модулей,
их взаимосвязей и зависимостей. Проект нижнего уровня обеспечиваетдоверие ктому, что подсистемы
ФБО были правильно и эффективно уточнены.
Для каждогомодуля ФБО проект нижнего уровня описывает назначение, функции, интерфейсы, за
висимости и реализацию всех функций, участвующих восуществлении ПБО.
14.5.2 Ранжирование компонентов
Компоненты в этом семействе ранжированы наосновестепени формализации, требуемой для проек
та нижнего уровня, истепенидетализации,требуемой для спецификаций интерфейсов.
14.5.3 Замечания по применению
Выражение «модуль, осуществляющий ПБО» относится клюбому модулю, на который необходимо
полагатьсядля корректногоосуществления ПБО.
Выражение «функциональные возможностибезопасности» используют, чтобы представить совокуп
ность выполняемых модулем действий, которые участвуют в осуществлении функций безопасности, реа
лизуемыхОО. Данное разграничение сделано потому,что модули не обязательнооднозначноотождеств
ляютсяс конкретными функциями безопасности. В то время какданный модуль может прямо соответство
вать какодной, так и нескольким функциям безопасности, возможно также, что несколько модулей необхо
димообъединить для реализации единственной функции безопасности.
Элементы ADV_LLD.*.6C содержат требование, чтобы проект нижнего уровня содержал описание
того, какобеспечивается каждая из функций, осуществляющих ПБО. Смысл этого требования состоит в
том. чтобы проект нижнегоуровня содержал описание планируемой реализации каждого модуля, исходя
из перспективы проекта.
Элементы ADV_LLD.‘.2Eэтогосемействаопределяют требование вынесения оценщиком независи
мого заключения о том. что проект нижнего уровня является точным и полным отображением функцио
нальных требований безопасности ОО. Этим обеспечивается прямоесоответствие между функциональны
митребованиями безопасности ОО ипроектом нижнегоуровня вдополнение к попарным соответствиям,
требуемым семейством ADV_RCR «Соответствие представлений». Ожидается, чтооценщикиспользует
свидетельство, включенное в ADV_RCR «Соответствие представлений», как основание для этого заклю
чения. а требование полноты предполагает соотнесениесуровнем абстракции проекта нижнего уровня.
ADV_LLD.2.9C содержит требование полного представления интерфейсов модулей. Этимбудет обес
печена необходимая детализациядля поддержки какполного тестирования ОО (сиспользованием компо
нентов из семейства ATE_DPT «Глубина»), так иоценки уязвимостей.
Применительно к уровнюформализации проекта нижнегоуровня неформальный, полуформальный
и формальный проекты рассматривают как иерархичные посути. Так. элементADV_LLD.1.1C может быть
удовлетворен использованием полуформального или формального проекта нижнего уровня, а элемент
ADVJ.LD.2.1C — формальногопроекта нижнего уровня.
68