ГОСТ Р ИСО/МЭК 18045—2013
использовался выше. Если оценщик не может сделать заключение о том, что механизм был реализован
точным образом из-за недостаточной детализации предоставленной ему информации, то ему нужно бу
дет оценить, были ли все осуществляющий выполнение ФТБ подсистемы идентифицированы и был ли
предоставлен для этих подсистем достаточный уровень детализации.
10.8.3Подвид деятельности по оценке (ADV_TDS.3)
10.8.3.1 Цели
Цель этого подвида деятельности состоит в том, чтобы определить, обеспечено ли в проекте ОО
«Описание ОО» в терминах подсистем, достаточное для определения границ ФБО. и обеспечено ли
описание внутренней структуры ФБО в терминах модулей (и. опционально, представлений верхнего
уровня). Оценщику предоставляется подробное описание осуществляющих выполнение ФТБ модулей и
достаточный обьем информации о поддерживающих и не влияющих на выполнение ФТБ модулей,
чтобы сделать заключение о том, что ФТБ полностью и точно осуществлены: как таковой, проект ОО
предоставляет объяснение представления реализации.
10.8.3.2 Исходные данные
Свидетельствами оценки для этого подвида деятельности являются:
a) ЗБ;
b
) функциональная спецификация;
c) описание архитектуры безопасности;
d) проект ОО.
10.8.3.3 Замечания по применению
Есть три типа деятельности, которую оценщик должен предпринять относительно проекта ОО.
Во-первых, оценщик делает заключение о том, что границы ФБО описана достаточным образом. Во-
вторых. оценщик делает заключение о том. что разработчик предоставил документацию, которая соот
ветствует содержанию и требованиям представления для этой подсистемы, и эта документация совме
стима с другой документацией, предусмотреннойдля ОО. Наконец, оценщикдолжен проанализировать
информацию о проекте, включая описание осуществляющих выполнение ФТБ модулей (подробно)
и поддерживающих и не влияющих на выполнение ФТБ (менее подробно) для того, чтобы понять, ка
ким образом реализована система, и с этим пониманием удостовериться, что ИФБО в функциональной
спецификации описаны достаточным образом, и что тестовая информация в достаточной мере тести
рует ФБО (проводится в шагах оценивания класса АТЕ: Тестирование).
Важно отметить, что. в то время как разработчик обязан обеспечить полное описание ФБО (хотя
и в меньшей степени детализации для поддерживающих и не влияющих на выполнение ФТБ моду
лей. чем для осуществляющих выполнение ФТБ), предполагается, что оценщик будет
использовать собственное суждение при выполнении анализа ФБО. Хотя и ожидается, что оценщик
будет исследо вать каждый модуль, степень детализации при таком рассмотрении может быть
различной. Оценщик анализирует каждый модуль, чтобы определить степень влияния функций модуля
на безопасность си стемы; глубина анализа может изменяться в зависимости от роли модуля в
системе. Важный аспект этого анализа — то. что оценщику следует использовать другую
предоставленную ему документацию (краткую и функциональную спецификацию ОО. описание
архитектуры безопасности, документацию по внутренней структуре ФБО), чтобы сделать заключение
о том, что описанные функции правильны, и что неявное обозначение поддерживающих или не
влияющих на выполнение ФТБ модулой (см. ниже) поддерживается их ролью в системной архитектуре.
Разработчик может определять модули как обеспечивающие выполнение ФТБ. поддерживаю
щие выполнение ФТБ или не влияющие на выполнение ФТБ, но эти «категории» используются только
для того, чтобы описать количество и тип информации, которую должен предоставить
разработчик, и может использоваться для ограничения количества информации, которую должен
предоставить раз работчик в том случае, если сам процесс разработки не производит требуемую
документацию. Были модули категорированы разработчиком или нет. в обязанности оценщика
входит задача вынести за ключение о том. что в модули включена соответствующая их роли в ОО
(обеспечивающие выполнение ФТБ и т.д.) информация и получить соответствующую информацию от
разработчика в случае, если разработчик не предоставил необходимую информацию для конкретного
модуля.
10.8.3.4 ДействиеADVTDS.3.1E
ИСО/МЭК 15408-3 ADV_TDS.3.1C: В проекте должно приводиться описание структуры ОО
на уровне подсистем.
10.8.3.4.1 Шаг оценивания ADV_TDS.3-1
Оценщик должен исследовать проект ОО. чтобы сделать заключение о том. что структура всего
ОО описана в терминах подсистем.
90