ГОСТ Р ИСО/МЭК 18045—2013
10.8.2.2.8 Шаг оценивания ADV_.TDS.2-8
Оценщикдолжен исследовать проект ОО. чтобы сделать заключение о том, что он содержит пол
ное и точное прослеживание от ИФБО. описанных в функциональной спецификации, к подсистемам
ФБО. описанным в проекте ОО.
Описание подсистем в проекте ОО представляет описание того, каким образом ФБО реализу
ются. достаточно детально для обеспечивающих выполнение ФТБ частей ФБО. и на более высоком
уровне представления для других частей ФБО. ИФБО обеспечивают описание того, каким образом осу
ществлена реализация. Свидетельства от разработчика идентифицируют подсистему, которая вовле
чена в процесс запроса операции от ИФБО. и идентифицируют различные подсистемы, которые пре
жде всего ответственны за реализацию функций. Следует отметить, что для данного шага оценивания
не требуется предоставления полного «дерева вызовов» для каждого ИФБО.
Оценщик оценивает полноту прослеживания, удостоверяясь, что каждый ИФБО прослежен
по крайней мере к одной подсистеме. Проверка точности более сложна.
Первый аспект точности заключается в том. что каждый ИФБО прослеживается к подсистеме, на
ходящейся в пределах ФБО. Такое заключение может быть сделано при рассмотрении описания под
систем. их взаимодействия и при определении места подсистемы в архитектуре безопасности на ос
новании данной информации. Следующий аспект точности — то. что прослеживание имеет смысл.
Например, прослеживание ИФБО. обеспечивающего контроль доступа, к подсистеме, которая прове ряет
пароли, не будет являться точным. Оценщику и в этом случае следует при вынесении заключения
использовать свое суждение. Цель состоит в том, что эта информация поможет оценщику в понимании
системы, реализации выполнения ФТБ и способов, которыми сущности в пределах ФБО могут взаимо
действовать с ФБО. Большая часть оценки того, точно ли описаны ФТБ подсистемами, выполняется
при проведении других шагов оценивания.
10.8.2.3 Действие ADV_TDS.2.2E
10.8.2.3.1 Шаг оценивания ADV_TDS.2-9
Оценщикдолжен исследовать ФТБ ОО и проект ОО. чтобы сделать заключение о том, что все ФТБ
в ЗБ охвачены в проекте ОО.
Оценщик может провести прослеживание между ФТБ для ОО и проектом ОО. Это прослеживание,
вероятно, будет проводиться от функционального требования до ряда подсистем. Следует отметить,
что это прослеживание, вероятно, будет по уровню детализации ниже, чем для компонента или даже
для элемента требований, из-за операций (назначения, уточнения, выбора), которые выполняются
над функциональным требованием автором ЗБ.
Например, компонент FDP_ACC.1 «Ограниченное управление доступом» содержит элемент
с операцией назначения. Если бы в ЗБ содержалось, например десять правил в назначении для дан
ного компонента FDP_ACC.1. и эти правила применялись бы в определенных местах в пределах пят
надцати модулей, то для оценщика некорректно было бы проследить компонент FDP_ACC.1 к одной
подсистеме и утверждать о завершении шага оценивания. Вместо этого оценщик должен проследить
первое правило компонента FDP_ACC.1 к подсистеме А и режимам функционирования х.уиг; второе
правило компонента FDP_ACC.1 к подсистеме А и режимам функционирования х. р и q; и т.д.
10.8.2.3.2 Шаг оценивания ADV_TDS.2-10
Оценщикдолжен исследовать проект ОО. чтобы сделать заключение о том, что в нем точно пред
ставлены все ФТБ.
Оценщик удостоверяется, что для каждого из ФТБ. перечисленных в подразделе ЗБ «Функци
ональные требования безопасности», есть соответствующее описание в проекте ОО. которое дета
лизирует. каким образом ФБО отвечают этому требованию. Это требуется для того, чтобы оценщик
идентифицировал собрание подсистем, которые отвечают за осуществлениеданного функционального
требования, а затем исследовал эти подсистемы, чтобы понять, каким образом выполняется требова
ние. Наконец, оценщик оценивает точность выполнения требования.
Например, если требования в ЗБ определяют основанный на ролевой модели механизм управле
ния доступом, оценщик сначала идентифицирует подсистемы, которые способствуют реализации этого
механизма. Это может быть сделано с применением углубленного изучения или с применением пони
мания проекта ОО или работ, полученных в предыдущих шагах оценивания. Следует отметить, что это
прослеживание необходимо только для идентификации подсистем и не является полным анализом.
Следующий шаг — понять, какой из механизмов подсистемы осуществляется. Например, если
в проекте описывается реализация управления доступом, основанная на битах защиты UNIX, то проект
не является точным отражением требований по управлению доступом в ЗБ для того примера, который
89