ГОСТ Р ИСО/МЭК 18045—2013
Например, компонент FDP_ACC.1 «Ограниченное управление доступом» содержит элемент
с операцией назначения. Если бы в ЗБ содержалось, например десять правил в назначении для дан
ного компонента FDP_ACC.1. и эти правила применялись бы в определенных местах в пределах пят
надцати модулей, то для оценщика некорректно было бы проследить компонент FDP_ACC.1 к одной
подсистеме и утверждать о завершении шага оценивания. Вместо этого оценщик должен проследить
первое правило компонента FDP_ACC.1 к подсистеме А и режимам функционирования х. у и г, второе
правило компонента FDP_ACC.1 к подсистеме А и режимам функционирования х. р и q; и т. д.
10.8.1.3.2 Шаг оценивания ADV_TDS.1-8
Оценщикдолжен исследовать проект 00. чтобы сделать заключение о том, что в нем точно пред
ставлены все ФТБ.
Оценщик удостоверяется, что для каждого из ФТБ. перечисленных в подразделе ЗБ «Функци
ональные требования безопасности», есть соответствующее описание в проекте 00. которое дета
лизирует. каким образом ФБО отвечают этому требованию. Это требуется для того, чтобы оценщик
идентифицировал собрание подсистем, которые отвечают за осуществление данного функционального
требования, а затем исследовал эти подсистемы, чтобы понять, каким образом выполняется требова
ние. Наконец, оценщик оценивает точность выполнения требования.
Например, если требования в ЗБ определяют основанный на ролевой модели механизм управления
доступом, тооценщиксначала идентифицирует подсистемы, которые способствуют реализации этого ме
ханизма. Это может быть сделано с применением углубленного изучения или с применением понимания
проекта ОО или работ, полученных в предыдущих шагах оценивания. Следует отметить, что это просле
живание необходимо только для идентификации подсистем и не является полным анализом.
Следующий шаг — понять, какой из механизмов подсистемы осуществляется. Например, если
в проекте описывается реализация управления доступом, основанная на битах защиты UNIX, то проект
не является точным отражением требований по управлению доступом в ЗБ для того примера, который
использовался выше. Если оценщик не может сделать заключение о том. что механизм был реализован
точным образом из-за недостаточной детализации предоставленной ему информации, тоему нужно бу
дет оценить, были ли все осуществляющие выполнение ФТБ подсистемы идентифицированы и был
ли предоставлен для этих подсистем достаточный уровень детализации.
10.8.2Подвид деятельности по оценке (ADV_TDS.2)
10.8.2.1 Исходные данные
Свидетельствами оценки для этого подвида деятельности являются:
a) ЗБ;
b
) функциональная спецификация;
c) описание архитектуры безопасности;
d) проект 00.
10.8.2.2 Действие ADVJTDS.2.1E
ИСО/МЭК 15408-3ADV_TDS.2.1С: Впроекте должно приводиться описание структуры ООнауров
не подсистем.
10.8.2.2.1 Шаг оценивания ADV_TDS.2-1
Оценщик должен исследовать проект ОО. чтобы сделать заключение о том. что структура всего
ОО описана в терминах подсистем.
Оценщик удостоверяется, что все подсистемы ОО идентифицированы. Это «Описание ОО» будет
использоваться в качестве исходных данных для шага оценивания ADV_TDS.2-2, где идентифициро
ваны части ОО. которые составляют ФБО. Таким образом, это требование относится ко всему ОО, а
не только к ФБО.
ОО (и ФБО) может быть описан на нескольких уровнях детализации (то есть подсистем и моду
лей). В зависимости от сложности ОО его проект может быть описан в терминах подсистем и модулей,
как описано в ИСО/МЭК 15408-3. приложение А.4 ADV_TDS: «Подсистемы и модули». На этом уровне
доверия декомпозиция требуется только на уровне подсистем.
При выполнении этой деятельности оценщик исследует другие свидетельства, представлен
ные ОО (например ЗБ. пользовательское руководство оператора), чтобы сделать заключение о том,
что «Описание ОО» в таких свидетельствах совместимо с описанием, содержавшимся в проекте ОО.
ИСО/МЭК 15408-3 ADV_TDS.2.2C: В проекте должны быть идентифицированы все подсистемы
ФБО.
10.8.2.2.2 Шаг оценивания ADV_TDS.2-2
Оценщик должен исследовать проект ОО. чтобы сделать заключение о том, что все подсистемы
ФБО идентифицированы.
85