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