ГОСТ Р ИСО/МЭК 15408-3-2013 Информационная технология (ИТ). Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности
11.6 Проект ОО (ADV_TDS)
11.6.1 Цели
В описании проекта ОО предоставляется краткое содержание описания ФБО, а также полное описание ФБО. С увеличением требуемого уровня доверия увеличивается и требуемый уровень детализации описания. При увеличении размера и сложности системы ФБО целесообразно применение различных уровней декомпозиции. Требования к проекту предназначены для предоставления такой информации (соответствующей заданному уровню доверия), чтобы можно было сделать заключение, что ФТБ реализованы.
11.6.2 Ранжирование компонентов
Компоненты в этом семействе ранжированы в зависимости от объема информации, которую требуется предоставить в отношении ФБО, и в зависимости от степени формализации, которая требуется для описания проекта.
11.6.3 Замечания по применению
Цель проектной документации состоит в предоставлении информации, достаточной для определения границ ОО и для описания того, каким образом ФБО реализуют ФТБ. Количество и структура документов по проекту будет зависеть от сложности ОО и от количества ФТБ; в общем случае для очень сложного ОО с большим числом ФТБ потребуется разработать больше проектной документации, чем для очень простого ОО, реализующего только несколько ФТБ. Для сложных ОО в плане обеспечения доверия весьма полезно применять различные уровни декомпозиции при описании проекта, тогда как для простых ОО не требуется представлять описания их реализации и на верхнем, и на нижнем уровне.
В данном семействе используются два уровня декомпозиции: на уровне подсистем и на уровне модулей. Модуль - это наиболее конкретное описание функциональных возможностей; он представляет собой описание реализации. Разработчику следует иметь возможность реализовать описанную на уровне модулей часть ОО без дополнительных проектных решений. Подсистема - это описание проекта ОО; описание на уровне подсистем помогает предоставить описание верхнего уровня того, что и каким образом выполняет данная часть ОО. Подсистема может подразделяться на подсистемы более низкого уровня или на модули. Для адекватного описания функционирования очень сложных объектов может потребоваться несколько уровней подсистем. Напротив, для описания простых ОО может не требоваться уровень подсистем; предоставить четкое описание функционирования таких ОО можно с применением модульного описания.
Применяемый в общем случае подход к разработке проектной документации заключается в том, что при увеличении уровня доверия акцент при предоставлении описания смещается от обобщенного, менее детализированного уровня описания (уровень подсистем) к более детализированному (уровень модулей). В случае, когда приемлем модульный уровень описания, поскольку ОО достаточно прост, чтобы описать его на этом уровне, но при этом для этого уровня доверия требуется описание на уровне подсистем, будет достаточно предоставить описание на уровне модуля. Однако для сложных ОО данный принцип неприменим: излишняя детализация описания на модульном уровне будет совершенно недоступной для понимания без сопроводительного описания на уровне подсистем.
Данный подход следует основной парадигме, гласящей, что предоставление дополнительной детальной информации по реализации ФБО позволит обеспечить большее доверие тому, что ФТБ верно реализованы. Кроме того, такая информация может быть использована для подтверждения этого при проведении тестирования (ATE "Тестирования").
В требованиях данного семейства термин "интерфейс" употребляется как средство взаимодействия (между двумя подсистемами или модулями) и описывает, каким образом осуществляются такие взаимодействия, аналогично детализации ИФБО в функциональной спецификации (см. ADV_FSP "Функциональная спецификация"). Термин "взаимодействие" используется для идентификации цели взаимодействия; он определяет причину взаимодействия двух подсистем или двух модулей друг с другом.
11.6.3.1 Детализация модулей и подсистем
Согласно требованиям, для подсистем и модулей должна быть предоставлена следующая подробная информация:
а) подсистемы и модули идентифицируются путем предоставления простого списка с обозначением того, чем они являются;
b) подсистемы и модули могут быть категорированы (как явным, так и неявным образом) как "осуществляющие выполнение ФТБ", "поддерживающие выполнение ФТБ", "не влияющие на выполнение ФТБ"; данные термины употребляются в том же значении, что и в семействе "Функциональная спецификация" (ADV_FSP);
c) режим функционирования подсистемы - это описание того, что именно выполняет подсистема. Режимы функционирования тоже могут подразделяться на категории: "осуществляющие выполнение ФТБ", "поддерживающие выполнение ФТБ", "не влияющие на выполнение ФТБ". При этом режим функционирования подсистемы не может быть отнесен к категории большей значимости, чем сама подсистема. Например, осуществляющая выполнение ФТБ подсистема может функционировать в режиме, осуществляющем выполнение ФТБ, а также в поддерживающем или не влияющем на ФТБ;
d) краткая информация о режиме функционирования - это обзор всех выполняемых подсистемой действий (например: "Подсистема протокола TCP собирает пакеты данных IP и связанную с ними адресную информацию в надежные информационные потоки");
e) описание режима функционирования подсистемы является объяснением всего, что выполняет данная система. Это описание следует составлять на таком уровне детализации, чтобы было легко определить, влияет ли данный режим функционирования каким-либо образом на обеспечение выполнения ФТБ;
f) в описании взаимодействий подсистем или модулей идентифицируется причина взаимодействия модулей и подсистем, а также характеризуется информация, которой они обмениваются. Не требуется представлять информацию в данном описании на таком же уровне детализации, как в спецификации интерфейсов. Например, будет достаточно указать, что: "подсистема X запрашивает блок памяти из модуля управления памятью, который отвечает на запрос путем предоставления участка распределенной памяти";
g) в описании интерфейсов предоставляется детализация того, каким образом осуществляются процессы взаимодействия между модулями. В описании интерфейсов не приводится описание причин и целей взаимодействия модулей (это описание относится к описанию взаимодействий), но детально описываются методы осуществления данного взаимодействия в терминах структуры и содержания сообщений, сигналов, процессов внутренних взаимодействий и т.д.;
h) назначение описывает, каким образом модуль выполняет свои функциональные возможности. Причем представленной детальной информации должно быть достаточно, чтобы не потребовалось дополнительных проектных решений. Следует, чтобы назначение модуля явно соответствовало представлению реализации, которым данный модуль реализуется;
i) иначе модуль описывается в терминах того, что определяется в элементе доверия.
Подсистемы и модули, как осуществляющие выполнение ФТБ, так и все остальные, более подробно объясняются в приложении А.4, "ADV_TDS: Подсистемы и модули".
11.6.4 ADV_TDS.1 Базовый проект
Зависимости: ADV_FSP.2 Детализация вопросов безопасности в функциональной спецификации
11.6.4.1 Элементы действий разработчика
11.6.4.1.1 ADV_TDS.1.1D
Разработчик должен представить проект ОО.
11.6.4.1.2 ADV_TDS.1.2D