— Все документы — ГОСТы — ГОСТ Р ИСО/МЭК 15408-3-2013 ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ. КРИТЕРИИ ОЦЕНКИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ. Часть 3. КОМПОНЕНТЫ ДОВЕРИЯ К БЕЗОПАСНОСТИ
ГОСТ Р ИСО/МЭК 15408-3-2013 ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ. КРИТЕРИИ ОЦЕНКИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ. Часть 3. КОМПОНЕНТЫ ДОВЕРИЯ К БЕЗОПАСНОСТИ
Добавил:
Дата: [11.02.2017]
ГОСТ Р ИСО/МЭК 15408-3-2013 ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ. КРИТЕРИИ ОЦЕНКИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ. Часть 3. КОМПОНЕНТЫ ДОВЕРИЯ К БЕЗОПАСНОСТИ
Information technology. Security techniques. Evaluation criteria for IT security. Part 3. Security assurance requirements
Дата введения - 1 сентября 2014 г.
Взамен ГОСТ Р ИСО/МЭК 15408-3-2008
Введение
Международный стандарт ISO/IEC 15408:2008 был подготовлен Совместным техническим комитетом ISO/IEC JTC 1 "Информационные технологии", Подкомитетом SC 27 "Методы и средства обеспечения безопасности ИТ". Идентичный ISO/IEC 15408:2008 текст опубликован организациями - спонсорами проекта "Общие критерии" как "Общие критерии оценки безопасности информационных технологий".
Третья редакция стандарта отменяет и заменяет вторую редакцию (ISO/IEC 15408:2005), которая подверглась технической переработке.
ИСО/МЭК 15408, идентичный ISO/IEC 15408:2008, состоит из следующих частей под общим заголовком "Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий":
Часть 1: Введение и общая модель;
Часть 2: Функциональные компоненты безопасности;
Часть 3: Компоненты доверия к безопасности.
Компоненты доверия к безопасности, которые определены в ИСО/МЭК 15408-3, являются основой для требований доверия к безопасности, отражаемых в профиле защиты (ПЗ) или в задании по безопасности (ЗБ).
Эти требования устанавливают стандартный способ выражения требований доверия для ОО. ИСО/МЭК 15408-3 представляет собой каталог компонентов, семейств и классов доверия. В ИСО/МЭК 15408-3 также определены критерии оценки для ПЗ и ЗБ и представлены оценочные уровни доверия для предопределенной в ИСО/МЭК 15408 шкалы доверия к ОО, которая называется Оценочные уровни доверия (ОУД).
Потенциальные пользователи данного международного стандарта включают потребителей, разработчиков и оценщиков безопасных продуктов ИТ. В ИСО/МЭК 15408-1 предоставлена дополнительная информация о целевой аудитории ИСО/МЭК 15408 (здесь и далее, если не указывается конкретная часть стандарта, то ссылка относится ко всем частям ИСО/МЭК 15408), а также по использованию ИСО/МЭК 15408 отдельными группами лиц, составляющими целевую аудиторию. Эти группы могут использовать данную часть ИСО/МЭК 15408 следующим образом:
a) Потребители могут использовать данную часть ИСО/МЭК 15408 при выборе компонентов для выражения требований доверия, чтобы удовлетворить цели безопасности, отраженные в ПЗ или ЗБ, и при определении требуемых уровней доверия к безопасности ОО;
b) Разработчики, которые при производстве ОО учитывают существующие или предполагаемые требования безопасности потребителей, могут обратиться к ИСО/МЭК 15408-3 при интерпретации изложения требований доверия и при определении подходов к обеспечению доверия к ОО;
c) Оценщики могут использовать требования доверия, определенные в ИСО/МЭК 15408-3, как обязательное изложение критериев оценки при определении доверия к ОО, а также при оценке ПЗ и ЗБ.
1. Область применения
Данная часть ИСО/МЭК 15408 определяет требования доверия ИСО/МЭК 15408 и включает оценочные уровни доверия (ОУД), определяющие шкалу для измерения доверия для ОО-компонентов, составные пакеты доверия (СоПД), определяющие шкалу для измерения доверия для составных ОО, отдельные компоненты доверия, из которых составлены уровни и пакеты доверия, а также критерии для оценки ПЗ и ЗБ.
2. Нормативные ссылки
Указанные в данном разделе документы являются необходимыми для применения настоящего стандарта. Для датированных ссылок используют только указанное издание. Для недатированных ссылок - последнее издание со всеми изменениями и дополнениями.
ИСО/МЭК 15408-1, Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 1: Введение и общая модель.
ИСО/МЭК 15408-2, Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2: Функциональные компоненты безопасности.
3. Термины, определения, обозначения и сокращения
В настоящем стандарте применяются термины, определения, обозначения и сокращения, приведенные в ИСО/МЭК 15408-1.
4. Краткий обзор
4.1. Структура данной части ИСО/МЭК 15408
В разделе 5 дается описание парадигмы, используемой в требованиях доверия к безопасности в ИСО/МЭК 15408-3.
В разделе 6 описывается структура представления классов, семейств и компонентов доверия, оценочных уровней доверия и их взаимосвязь, структура составных пакетов доверия. Также дается характеристика классов и семейств доверия, представленных в разделах с 9 по 16.
В разделе 7 содержится подробное описание оценочных уровней доверия (ОУД).
В разделе 8 содержится подробное описание составных пакетов доверия (СоПД).
В разделах с 9 по 16 содержится подробное описание классов доверия ИСО/МЭК 15408-3.
Приложение A содержит дальнейшие пояснения и примеры понятий, связанных с классом "Разработка".
Приложение B содержит пояснение понятий, связанных с оценкой составного ОО и классом "Композиция".
Приложение C содержит краткое описание зависимостей между компонентами доверия.
Приложение D содержит перекрестные ссылки между ПЗ, семействами и компонентами класса "Оценка профиля защиты" (APE).
Приложение E содержит перекрестные ссылки между ОУД и компонентами доверия.
Приложение F содержит перекрестные ссылки между составными пакетами доверия (СоПД) и компонентами доверия.
Приложение ДА содержит сведения о соответствии ссылочных международных стандартов ссылочным национальным стандартам Российской Федерации.
5. Парадигма доверия ИСО/МЭК 15408
Цель данного раздела состоит в изложении основных принципов и подходов к установлению доверия к безопасности. Данный раздел позволит понять логику построения требований доверия в ИСО/МЭК 15408-3.
5.1. Основные принципы ИСО/МЭК 15408
Основные принципы ИСО/МЭК 15408 состоят в том, что следует четко сформулировать угрозы безопасности и положения политики безопасности организации, а достаточность предложенных мер безопасности должна быть продемонстрирована.
Более того, следует принять меры по уменьшению вероятности наличия уязвимостей, возможности их проявления (т.е. преднамеренного использования или непреднамеренной активизации), а также степени ущерба, который может явиться следствием проявления уязвимости. Дополнительно следует предпринять меры для облегчения последующей идентификации уязвимостей, а также по их устранению, ослаблению и/или оповещению об их использовании или активизации.
5.2. Подход к доверию
Основная концепция ИСО/МЭК 15408 - обеспечение доверия, основанное на оценке (активном исследовании) продукта ИТ, который должен соответствовать определенным критериям безопасности. Оценка была традиционным способом обеспечения доверия и являлась основой предшествующих критериев оценки. Для согласования с существующими подходами в ИСО/МЭК 15408 принят тот же самый основной принцип. В ИСО/МЭК 15408 предполагается, что проверку правильности документации и разработанного продукта ИТ будут проводить опытные оценщики, уделяя особое внимание области, глубине и строгости оценки.
В ИСО/МЭК 15408 не отрицаются и не комментируются относительные достоинства других способов получения доверия. Продолжаются исследования альтернативных путей достижения доверия. Если в результате этих исследований будут выявлены другие отработанные альтернативные подходы, то они могут в дальнейшем быть включены в ИСО/МЭК 15408, который структурно организован так, что предусматривает такую возможность.
5.2.1. Значимость уязвимостей
Предполагается, что имеются нарушители, которые будут стремиться активно использовать возможности нарушения политики безопасности как для получения незаконной выгоды, так и для выполнения незлонамеренных, но, тем не менее, опасных действий. Нарушители могут также случайно активизировать уязвимости безопасности, нанося вред организации. При необходимости обрабатывать чувствительную информацию и отсутствии в достаточной степени доверенных продуктов имеется значительный риск из-за отказов ИТ. Поэтому нарушения безопасности ИТ могут вызвать значительные потери.
Нарушения безопасности ИТ возникают вследствие преднамеренного использования или непреднамеренной активации уязвимостей при применении ИТ по назначению.
Следует предпринять ряд шагов для предотвращения уязвимостей, возникающих в продуктах ИТ. По возможности уязвимости следует:
a) устранить, т.е. следует предпринять активные действия для выявления, а затем удаления или нейтрализации всех уязвимостей, которые могут проявиться;
b) минимизировать, т.е. следует предпринять активные действия для уменьшения до допустимого остаточного уровня возможного ущерба от любого проявления уязвимостей;
c) отслеживать, т.е. следует предпринять активные действия для обнаружения любой попытки использовать остаточные уязвимости с тем, чтобы ограничить ущерб.
5.2.2. Причины уязвимостей
Уязвимости могут возникать из-за недостатков:
a) требований, т.е. продукт ИТ может обладать требуемыми от него функциями и свойствами, но все же содержать уязвимости, которые делают его непригодным или неэффективным в части безопасности;
b) проектирования, т.е. продукт ИТ не отвечает спецификации, и/или уязвимости являются следствием некачественных стандартов проектирования или неправильных проектных решений;
c) эксплуатации, т.е. продукт ИТ разработан в полном соответствии с корректной спецификацией, но уязвимости возникают как результат неадекватного управления при эксплуатации.
5.2.3. Доверие в ИСО/МЭК 15408
Доверие - основа для уверенности в том, что продукт ИТ отвечает целям безопасности. Доверие могло бы быть получено путем обращения к таким источникам, как бездоказательное утверждение, предшествующий аналогичный опыт или специфический опыт. Однако ИСО/МЭК 15408 обеспечивает доверие с использованием активного исследования. Активное исследование - это оценка продукта ИТ для определения его свойств безопасности.
5.2.4. Доверие через оценку
Оценка является традиционным способом достижения доверия, и она положена в основу ИСО/МЭК 15408. Методы оценки могут, в частности, включать в себя:
a) анализ и проверку процесса (процессов) и процедуры (процедур);
b) проверку того, что процесс (процессы) и процедура (процедуры) действительно применяются;
c) анализ соответствия между представлениями проекта ОО;
d) анализ соответствия каждого представления проекта ОО требованиям;
e) верификацию доказательств;
f) анализ руководств;
g) анализ разработанных функциональных тестов и предоставленных результатов;
h) независимое функциональное тестирование;
i) анализ уязвимостей, включающий предположения о недостатках;
j) тестирование проникновения.
5.3. Шкала оценки доверия в ИСО/МЭК 15408
Основные принципы ИСО/МЭК 15408 содержат утверждение, что большее доверие является результатом приложения больших усилий при оценке, и что цель состоит в применении минимальных усилий, требуемых для обеспечения необходимого уровня доверия. Повышение уровня усилий может быть основано на
a) области охвата, т.е. увеличении рассматриваемой части продукта ИТ;
b) глубине, т.е. детализации рассматриваемых проектных материалов и реализации;
c) строгости, т.е. применении более структурированного и формального подхода.
6. Требования доверия к безопасности
6.1. Структура классов, семейств и компонентов доверия к безопасности
Следующие пункты описывают конструкции, используемые в представлении классов, семейств и компонентов доверия.
На рисунке 1 показаны требования доверия, определенные в ИСО/МЭК 15408-3. Наиболее обобщенная совокупность требований доверия называется классом. Каждый класс содержит семейства доверия, которые разделены на компоненты доверия, содержащие, в свою очередь, элементы доверия. Классы и семейства используются для обеспечения систематизации классифицируемых требований доверия, в то время как компоненты применяются для спецификации требований доверия в ПЗ/ЗБ.
6.1.1. Структура класса
Рисунок 1 иллюстрирует структуру класса доверия.
6.1.1.1. Имя класса
Каждому классу доверия присвоено уникальное имя. Имя указывает на тематические разделы, на которые распространяется данный класс доверия.
Представлена также уникальная краткая форма имени класса доверия. Она является основным средством для ссылки на класс доверия. Принятое условное обозначение включает в себя букву "A", за которой следуют еще две буквы латинского алфавита, относящиеся к имени класса.
6.1.1.2. Представление класса
Каждый класс доверия имеет вводный подраздел, в котором описаны состав и назначение класса.
6.1.1.3. Семейства доверия
Каждый класс доверия содержит, по меньшей мере, одно семейство доверия. Структура семейств доверия описана в следующем пункте.
6.1.2. Структура семейства
Рисунок 1 иллюстрирует структуру семейства доверия.
"Рис. 1. Иерархическая структура представления требований доверия: класс-семейство-компонент-элемент"
6.1.2.1. Имя семейства
Каждому семейству доверия присвоено уникальное имя. Имя содержит описательную информацию по тематическим разделам, на которые распространяется данное семейство доверия. Каждое семейство доверия размещено в пределах класса доверия, который содержит другие семейства той же направленности.
Представлена также уникальная краткая форма имени семейства доверия. Она является основным средством для ссылки на семейство доверия. Принятое условное обозначение включает в себя краткую форму имени класса и символ подчеркивания, за которым следуют три буквы латинского алфавита, относящиеся к имени семейства.
6.1.2.2. Цели
Подраздел "Цели" семейства доверия представляет назначение семейства доверия.
В нем описаны цели, для достижения которых предназначено семейство, особенно связанные с парадигмой доверия ИСО/МЭК 15408. Описание целей для семейства доверия представлено в общем виде. Любые конкретные подробности, требуемые для достижения целей, включены в конкретный компонент доверия.
6.1.2.3. Ранжирование компонентов
Каждое семейство доверия содержит один или несколько компонентов доверия. Этот подраздел семейства доверия содержит описание имеющихся компонентов и объяснение их отличительных признаков. Его основная цель состоит в указании различий между компонентами при принятии решения о том, что семейство является необходимой или полезной частью требований доверия для ПЗ/ЗБ.
В семействах доверия, содержащих более одного компонента, выполнено ранжирование компонентов и приведено его обоснование. Это обоснование сформулировано в терминах области охвата, глубины и/или строгости.
6.1.2.4. Замечания по применению
Необязательный подраздел семейства доверия "Замечания по применению" содержит дополнительную информацию о семействе. Эта информация предназначена непосредственно для пользователей семейства доверия (например, для разработчиков ПЗ и ЗБ, проектировщиков ОО, оценщиков). Представление информации неформально и включает в себя, например, предупреждения об ограничениях использования или областях, требующих особого внимания.
6.1.2.5. Компоненты доверия
Каждое семейство содержит хотя бы один компонент доверия. Структура компонентов доверия представлена в следующем пункте.
6.1.3. Структура компонента
На рисунке 2 представлена структура компонента доверия.
"Рис. 2. Структура компонента доверия"
Связи между компонентами внутри семейства показаны жирными линиями. Для частей требований, которые являются новыми, расширенными или модифицированными по сравнению с требованиями предыдущего по иерархии компонента, применен полужирный шрифт.
6.1.3.1. Идентификация компонента
Подраздел "Идентификация компонента" содержит описательную информацию, необходимую для идентификации, категорирования, регистрации и ссылок на компонент.
Каждому компоненту доверия присвоено уникальное имя. Имя содержит информацию о тематических разделах, на которые распространяется компонент доверия. Каждый компонент входит в состав конкретного семейства доверия, с которым имеет общую цель безопасности.
Представлена также уникальная краткая форма имени компонента доверия как основной способ ссылки на компонент. Принято, что за краткой формой имени семейства ставится точка, а затем цифра. Цифры для компонентов внутри каждого семейства назначены последовательно, начиная с единицы.
6.1.3.2. Цели
Необязательный подраздел "Цели" компонента доверия содержит конкретные цели для данного компонента. Для компонентов доверия, которые имеют этот подраздел, он включает в себя конкретное назначение данного компонента и более подробное разъяснение целей.
6.1.3.3. Замечания по применению
Необязательный подраздел компонента доверия "Замечания по применению", при его наличии, содержит дополнительную информацию для облегчения использования компонента.
6.1.3.4. Зависимости
Зависимости среди компонентов доверия возникают, когда компонент не самодостаточен, а зависит от наличия другого компонента.
Для каждого компонента доверия приведен полный список зависимостей от других компонентов доверия. При отсутствии у компонента идентифицированных зависимостей вместо списка может указываться: "Зависимости отсутствуют". Компоненты из списка могут, в свою очередь, иметь зависимости от других компонентов.
Список зависимостей определяет минимальный набор компонентов доверия, на которые следует полагаться. Компоненты, которые иерархичны по отношению к компоненту из списка зависимостей, также могут использоваться для удовлетворения зависимости.
В отдельных ситуациях обозначенные зависимости могут быть неприменимы. Разработчик ПЗ/ЗБ может отказаться от удовлетворения зависимости, представив обоснование, почему данная зависимость неприменима.
6.1.3.5. Элементы доверия
Каждый компонент доверия содержит набор элементов доверия. Элемент доверия представляет собой требование безопасности, при дальнейшем разделении которого не изменяется значимый результат оценки. Он является наименьшим требованием безопасности, распознаваемым в ИСО/МЭК 15408-3.
Каждый элемент доверия принадлежит к одному из трех типов:
a) Элементы действий разработчика, определяющие действия, которые должны выполняться разработчиком. Этот набор действий далее уточняется доказательным материалом, упоминаемым в последующем наборе элементов. Требования к действиям разработчика обозначены буквой "D" после номера элемента.
b) Элементы содержания и представления свидетельств, определяющие требуемые свидетельства и отражаемую в них информацию. Требования к содержанию и представлению свидетельств обозначены буквой "C" после номера элемента.
c) Элементы действий оценщика, определяющие действия, которые должны выполняться оценщиком. Этот набор действий непосредственно включает в себя подтверждение того, что требования, предписанные элементами содержания и представления свидетельств, выполнены, а также явные действия и анализ, которые должны выполняться в дополнение к уже проведенным разработчиком. Должны также выполняться неуказанные явно действия оценщика, необходимые вследствие элементов действий разработчика, но не охваченные в требованиях к содержанию и представлению свидетельств. Требования к действиям оценщика обозначаются буквой "E" после номера элемента.
Действия разработчика, содержание и представление свидетельств определяют требования доверия, которые предъявляются к разработчику при демонстрации доверия к тому, что ОО удовлетворяет ФТБ из ПЗ или ЗБ.
Действия оценщика определяют его ответственность по двум аспектам оценки. Первый аспект состоит в проверке правильности ПЗ/ЗБ в соответствии с требованиями классов APE "Оценка профиля защиты" и ASE "Оценка задания по безопасности". Второй аспект состоит в верификации соответствия ОО его функциональным требованиям и требованиям доверия. Демонстрируя, что ПЗ/ЗБ правильны и их требования выполняются ОО, оценщик может предоставить основание для уверенности в том, что ОО будет отвечать поставленным целям безопасности.
Элементы действий разработчика, элементы содержания и представления свидетельств и элементы явных действий оценщика определяют уровень его усилий, которые должны быть приложены при верификации утверждений о безопасности, сформулированных в ЗБ конкретного ОО.
6.1.4. Элементы доверия
Каждый элемент представляет собой обязательное для выполнения требование. Формулировки этих требований должны быть четкими, краткими и однозначными. Поэтому в требованиях отсутствуют составные предложения. Каждое требование изложено как отдельный элемент.
6.1.5. Классификация компонентов
В ИСО/МЭК 15408-3 содержатся классы семейств и компонентов, которые сгруппированы на основе, связанной с доверием. В начале каждого класса представлена диаграмма, на которой указываются семейства в классе и компоненты в каждом семействе.
На рисунке 3 показан класс, содержащий одно семейство. Семейство содержит три компонента, которые являются линейно иерархичными (т.е. компонент 2 содержит более высокие требования, чем компонент 1, к конкретным действиям, приводимым свидетельствам или строгости действий и/или свидетельств). Все семейства доверия в ИСО/МЭК 15408-3 - линейно иерархичные, хотя линейность необязательна для семейств доверия, которые могут быть добавлены в дальнейшем.
"Рис. 3. Образец декомпозиции класса"
6.2. Структура ОУД
Рисунок 4 иллюстрирует ОУД и их структуру, определенную в ИСО/МЭК 15408-3. Компоненты доверия, содержание которых показано на рисунке, включены в ОУД посредством ссылок на компоненты, приведенные в ИСО/МЭК 15408-3.
"Рис. 4. Структура ОУД"
6.2.1. Имя ОУД
Каждому ОУД присвоено уникальное имя. Имя представляет описательную информацию о назначении ОУД.
Представлена также уникальная краткая форма имени ОУД. Она является основным средством ссылки на ОУД.
6.2.2. Цели
В подразделе "Цели" ОУД приведено назначение ОУД.
6.2.3. Замечания по применению
Необязательный подраздел ОУД "Замечания по применению" содержит информацию, представляющую интерес для пользователей ОУД (например, для разработчиков ПЗ и ЗБ, проектировщиков ОО, планирующих использование этого ОУД, оценщиков). Представление неформально и включает в себя, например, предупреждения об ограничениях использования или областях, требующих особого внимания.
6.2.4. Компоненты доверия
Для каждого ОУД выбран набор компонентов требований доверия.
Более высокий уровень доверия, чем предоставляемый конкретным ОУД, может быть достигнут:
a) включением дополнительных компонентов требований доверия из других семейств доверия или
b) заменой компонента требований доверия иерархичным компонентом из этого же семейства требований доверия.
6.2.5. Взаимосвязь между требованиями и уровнями доверия
Рисунок 5 иллюстрирует взаимосвязь между требованиями доверия и уровнями доверия, определенными в ИСО/МЭК 15408-3. Компоненты доверия состоят из элементов, но на последние в отдельности не могут ссылаться оценочные уровни доверия. Стрелка на рисунке отображает ссылку в ОУД на компонент требований доверия внутри класса, в котором он определен.
"Рис. 5. Взаимосвязь требований и уровня доверия"
6.3. Структура СоПД
Структура СоПД аналогична структуре ОУД. Ключевое различие двух структур состоит в типе ОО, к которым они применяются; ОУД применяется к ОО-компонентам, а СоПД - ко всему составному ОО в целом.
На рисунке 6 показана структура СоПД, определенная в ИСО/МЭК 15408-3. Следует заметить, что хотя на рисунке показано содержание компонентов доверия, предполагается, что эта информация будет включаться в СоПД посредством ссылки на компоненты ИСО/МЭК 15408.
"Рис. 6. Структура СоПД"
6.3.1. Имя СоПД
Каждому СоПД присвоено уникальное имя. Имя предоставляет описательную информацию, характеризующую назначение СоПД.
Представлена также уникальная краткая форма имени СоПД. Она является основным средством ссылки на СоПД.
6.3.2. Цели
В подразделе "Цели" СоПД приведено назначение СоПД.
6.3.3. Замечания по применению
Необязательный подраздел СоПД "Замечания по применению" содержит информацию, представляющую интерес для пользователей СоПД (например, для разработчиков ПЗ и ЗБ, интеграторов составных ОО, планирующих использование этого СоПД, оценщиков). Представление неформально и включает в себя, например, предупреждения об ограничениях использования или областях, требующих особого внимания.
6.3.4. Компоненты доверия
Набор компонентов доверия установлен для каждого СоПД.
Некоторые зависимости определяют действия, выполняемые в процессе оценки конкретного зависимого компонента, на которые опираются действия по оценке составного ОО. В случае если явно не определено наличие зависимости от действий по оценке зависимого компонента, зависимость относится к другому действию по оценке составного ОО.
Более высокий уровень доверия по сравнению с конкретным СоПД достигается путем:
a) добавления компонентов доверия из других семейств доверия;
b) замены компонента доверия на более высокий по иерархии компонент из того же семейства доверия.
Компоненты класса ACO "Композиция", включенные в СоПД, не следует использовать в качестве усиления при оценке ОО-компонента, поскольку это не обеспечит значимого доверия к этому ОО-компоненту.
6.3.5. Взаимосвязь между требованиями доверия и составными пакетами доверия
На рисунке 7 показана взаимосвязь между требованиями доверия к безопасности и составными пакетами доверия, определенными в ИСО/МЭК 15408. Компоненты доверия состоят из элементов, но на последние не могут в отдельности ссылаться пакеты требований доверия. Стрелка на рисунке отображает ссылку от СоПД на компонент доверия внутри класса, в котором он определен.
"Рис. 7. Взаимосвязь между требованиями доверия и составными пакетами доверия"
7. Оценочные уровни доверия
Оценочные уровни доверия (ОУД) образуют возрастающую шкалу, которая позволяет соотнести получаемый уровень доверия со стоимостью и возможностью достижения этой степени доверия. В подходе ИСО/МЭК 15408 определяются отдельные понятия для доверия к ОО после завершения оценки и по поддержанию доверия во время эксплуатации ОО.
Важно обратить внимание, что не все семейства и компоненты ИСО/МЭК 15408 включены в оценочные уровни доверия. Это не означает, что они не обеспечивают значимое и ожидаемое доверие. Напротив, ожидается, что эти семейства и их компоненты будут использоваться для усиления ОУД в тех ПЗ и ЗБ, для которых они полезны.
7.1. Краткий обзор оценочных уровней доверия (ОУД)
В таблице 1 представлено сводное описание ОУД. Столбцы таблицы представляют иерархически упорядоченный набор ОУД, а строки - семейства доверия. Каждый номер в образованной ими матрице идентифицирует конкретный компонент доверия, применяемый в данном случае.
Как показано в следующем подразделе, в ИСО/МЭК 15408 определены семь иерархически упорядоченных оценочных уровней доверия для оценки уровня доверия к ОО. Каждый последующий ОУД представляет более высокое доверие, чем любой из предыдущих. Увеличение доверия от предыдущего ОУД к последующему достигается заменой какого-либо компонента доверия иерархичным компонентом из того же семейства доверия (т.е. увеличением строгости, области охвата и/или глубины оценки) и добавлением компонентов из других семейств доверия (т.е. добавлением новых требований).
ОУД состоят из определенной комбинации компонентов доверия, как описано в разделе 6. Точнее, каждый ОУД включает в себя не более одного компонента каждого семейства доверия, при этом учитываются все зависимости каждого компонента доверия.
Хотя в ИСО/МЭК 15408-3 определены именно ОУД, можно представлять другие комбинации компонентов доверия. Специально введенное понятие "усиление" ("augmentation") допускает добавление (из семейств доверия, не включенных в ОУД) или замену компонентов доверия в ОУД (другими, иерархичными компонентами из того же самого семейства доверия). Из конструкций установления доверия, определенных в ИСО/МЭК 15408, только ОУД могут быть усилены. Понятие "ОУД за исключением какого-либо составляющего его компонента доверия" не признано в ИСО/МЭК 15408 как допустимое. Вводящий усиление должен логически обосновать полезность и дополнительную ценность добавляемого к ОУД компонента доверия. ОУД может быть также расширен требованиями доверия, сформулированными в явном виде.
Таблица 1 - Обзор оценочных уровней доверия
|
Класс доверия |
Семейство доверия |
Компоненты доверия из оценочного уровня доверия | ||||||
|
ОУД1 |
ОУД2 |
ОУД3 |
ОУД4 |
ОУД5 |
ОУД6 |
ОУД7 | ||
|
Разработка |
ADV_ARC |
|
1 |
1 |
1 |
1 |
1 |
1 |
|
ADV_FSP |
1 |
2 |
3 |
4 |
5 |
5 |
6 | |
|
ADV_IMP |
|
|
|
1 |
1 |
2 |
2 | |
|
ADV_INT |
|
|
|
|
2 |
3 |
3 | |
|
ADV_SPM |
|
|
|
|
|
1 |
1 | |
|
ADV_TDS |
|
1 |
2 |
3 |
4 |
5 |
6 | |
|
Руководства |
AGD_OPE |
1 |
1 |
1 |
1 |
1 |
1 |
1 |
|
AGD_PRE |
1 |
1 |
1 |
1 |
1 |
1 |
1 | |
|
Поддержка жизненного цикла |
ALC_CMC |
1 |
2 |
3 |
4 |
4 |
5 |
5 |
|
ALC_CMS |
1 |
2 |
3 |
4 |
5 |
5 |
5 | |
|
ALC_DEL |
|
1 |
1 |
1 |
1 |
1 |
1 | |
|
ALC_DVS |
|
|
1 |
1 |
1 |
2 |
2 | |
|
ALC_FLR |
|
|
|
|
|
|
| |
|
ALC_LCD |
|
|
1 |
1 |
1 |
1 |
2 | |
|
ALC_TAT |
|
|
|
1 |
2 |
3 |
3 | |
|
Оценка задания по безопасности |
ASE_CCL |
|
1 |
1 |
1 |
1 |
1 |
1 |
|
ASE_ECD |
|
1 |
1 |
1 |
1 |
1 |
1 | |
|
ASE_INT |
|
1 |
1 |
1 |
1 |
1 |
1 | |
|
ASE_OBJ |
|
2 |
2 |
2 |
2 |
2 |
2 | |
|
ASE_REQ |
|
2 |
2 |
2 |
2 |
2 |
2 | |
|
ASE_SPD |
|
1 |
1 |
1 |
1 |
1 |
1 | |
|
ASE_TSS |
1 |
1 |
1 |
1 |
1 |
1 |
1 | |
|
Тестирование |
ATE_COV |
|
1 |
2 |
2 |
2 |
3 |
3 |
|
ATE_DPT |
|
|
1 |
2 |
3 |
3 |
4 | |
|
ATE_FUN |
|
1 |
1 |
1 |
1 |
2 |
2 | |
|
ATE_IND |
1 |
2 |
2 |
2 |
2 |
2 |
3 | |
|
Оценка уязвимостей |
AVA_VAN |
1 |
2 |
2 |
3 |
4 |
5 |
5 |
7.2. Детализация оценочных уровней доверия
Следующие подразделы содержат определения ОУД с использованием полужирного шрифта для выделения новых требований и их описания.
7.3. Оценочный уровень доверия 1 (ОУД1), предусматривающий функциональное тестирование
7.3.1. Цели
ОУД1 применим, когда требуется некоторая уверенность в правильном функционировании ОО, а угрозы безопасности не рассматривают как серьезные. Он будет полезен там, где требуется независимо полученное доверие утверждению, что было уделено должное внимание защите информации с низким уровнем значимости.
Для ОУД1 требуется только ЗБ с сокращенным содержанием. Можно не определять функциональные требования путем изучения угроз, ПБОр и предположений о целях безопасности; достаточно просто изложить, каким функциональным требованиям должен отвечать ОО.
ОУД1 обеспечивает оценку ОО в том виде, в каком он доступен потребителю, путем независимого тестирования на соответствие спецификации и экспертизы представленной документации руководств. Предполагается, что оценка по ОУД1 может успешно проводиться без помощи разработчика ОО и с минимальными затратами.
При оценке на этом уровне следует предоставить свидетельство, что ОО функционирует в соответствии с его документацией.
7.3.2. Компоненты доверия
ОУД1 (см. таблицу 2) предоставляет базовый уровень доверия посредством ЗБ с сокращенным содержанием и анализ ФТБ в этом ЗБ с использованием функциональной спецификации, спецификации интерфейсов и руководств для понимания режима безопасности.
Анализ поддержан поиском потенциальных уязвимостей (путем изучения общедоступной информации) с проведением независимого тестирования (функционального и тестирования проникновения) ФБО.
Также ОУД1 обеспечивает доверие благодаря уникальной идентификации ОО и документации по оценке.
Этот ОУД обеспечивает значимое увеличение доверия по сравнению с продуктом ИТ, не подвергавшимся оценке.
Таблица 2 - Оценочный уровень доверия 1
|
Класс доверия |
Компоненты доверия |
|
ADV: Разработка |
ADV_FSP.1 Базовая функциональная спецификация |
|
AGD: Руководства |
AGD_OPE.1 Руководство пользователя по эксплуатации |
|
AGD_PRE.1 Подготовительные процедуры | |
|
ALC: Поддержка жизненного цикла |
ALC_CMC.1 Маркировка ОО |
|
ALC_CMS.1 Охват УК объекта оценки | |
|
ASE: Оценка задания по безопасности |
ASE_CCL.1 Утверждения о соответствии |
|
ASE_ECD.1 Определение расширенных компонентов | |
|
ASE_INT.1 Введение ЗБ | |
|
ASE_OBJ.1 Цели безопасности для среды функционирования | |
|
ASE_REQ.1 Установленные требования безопасности | |
|
ASE_TSS.1 Краткая спецификация ОО | |
|
ATE: Тестирование |
ATE_IND.1 Независимое тестирование на соответствие |
|
AVA: Оценка уязвимостей |
AVA_VAN.1 Обзор уязвимостей |
7.4. Оценочный уровень доверия 2 (ОУД2), предусматривающий структурное тестирование
7.4.1. Цели
ОУД2 содержит требование сотрудничества с разработчиком для получения информации о проекте и результатах тестирования, но при этом не следует требовать от разработчика усилий, превышающих обычную коммерческую практику. Следовательно, не требуется существенного увеличения стоимости или затрат времени.
Поэтому ОУД2 применим, когда разработчикам или пользователям требуется независимо подтверждаемый уровень доверия от невысокого до умеренного при отсутствии доступа к полной документации по разработке. Такая ситуация может возникать при обеспечении безопасности разработанных ранее (наследуемых) систем или при ограниченной доступности разработчика.
7.4.2. Компоненты доверия
ОУД2 (см. таблицу 3) обеспечивает доверие посредством ЗБ с полным содержанием и посредством анализа выполнения ФТБ из данного ЗБ с использованием функциональной спецификации, спецификации интерфейсов, руководств, а также базового описания архитектуры ОО для понимания режима безопасности.
Анализ поддержан независимым тестированием ФБО, свидетельством разработчика о тестировании, основанном на функциональной спецификации, выборочным независимым подтверждением результатов тестирования разработчиком и анализом уязвимостей (основанным на функциональной спецификации, проекте ОО, описании архитектуры системы безопасности и документации руководств), демонстрирующим противостояние попыткам проникновения нарушителей, обладающих Базовым потенциалом нападения.
ОУД2 также обеспечивает доверие посредством использования системы управления конфигурацией ОО и свидетельства безопасных процедур поставки.
ОУД2 представляет значимое увеличение доверия по сравнению с ОУД1, требуя тестирование ОО и анализ уязвимостей разработчиком (помимо изучения общедоступных источников информации), а также независимое тестирование, основанное на более детализированных спецификациях ОО.
Таблица 3 - Оценочный уровень доверия 2
|
Класс доверия |
Компоненты доверия |
|
ADV: Разработка |
ADV_ARC.1 Описание архитектуры безопасности |
|
ADV_FSP.2 Детализация вопросов безопасности в функциональной спецификации | |
|
ADV_TDS.1 Базовый проект | |
|
AGD: Руководства |
AGD_OPE.1 Руководство пользователя по эксплуатации |
|
AGD_PRE.1 Подготовительные процедуры | |
|
ALC: Поддержка жизненного цикла |
ALC_CMC.2 Использование системы УК |
|
ALC_CMS.2 Охват УК частей ОО | |
|
ALC_DEL.1 Процедуры поставки | |
|
ASE: Оценка задания по безопасности |
ASE_CCL.1 Утверждения о соответствии |
|
ASE_ECD.1 Определение расширенных компонентов | |
|
ASE_INT.1 Введение ЗБ | |
|
ASE_OBJ.2 Цели безопасности | |
|
ASE_REQ.2 Производные требования безопасности | |
|
ASE_SPD.1 Определение проблемы безопасности | |
|
ASE_TSS.1 Краткая спецификация ОО | |
|
ATE: Тестирование |
ATE_COV.1 Свидетельство покрытия |
|
ATE_FUN.1 Функциональное тестирование | |
|
ATE_IND.2 Выборочное независимое тестирование | |
|
AVA: Оценка уязвимостей |
AVA_VAN.2 Анализ уязвимостей |
7.5. Оценочный уровень доверия 3 (ОУД3), предусматривающий методическое тестирование и проверку
7.5.1. Цели
ОУД3 позволяет добросовестному разработчику достичь максимального доверия путем применения надлежащего проектирования безопасности на стадии разработки проекта без значительного изменения существующей практики качественной разработки.
ОУД3 применим, когда разработчикам или пользователям требуется независимо подтвержденный умеренный уровень доверия на основе всестороннего исследования ОО и процесса его разработки без существенных затрат на изменение технологии проектирования.
7.5.2. Компоненты доверия
ОУД3 (см. таблицу 4) обеспечивает доверие посредством ЗБ с полным содержанием и посредством анализа выполнения ФТБ из данного ЗБ с использованием функциональной спецификации, спецификации интерфейсов, руководств и архитектурного описания проекта ОО для понимания режима безопасности.
Анализ поддержан независимым тестированием ФБО, свидетельством разработчика о тестировании, основанном на функциональной спецификации и проекте ОО, выборочным независимым подтверждением результатов тестирования разработчиком и анализом уязвимостей (основанным на представленных свидетельствах по функциональной спецификации, проекту ОО, описанию архитектуры безопасности и руководствам), демонстрирующим противостояние попыткам проникновения нарушителей, обладающих Базовым потенциалом нападения.
ОУД3 также обеспечивает доверие посредством использования мер управления средой разработки, управления конфигурацией ОО и свидетельства безопасных процедур поставки.
ОУД3 представляет значимое увеличение доверия по сравнению с ОУД2, требуя более полного покрытия тестированием функциональных возможностей и механизмов безопасности и/или процедур безопасности, что дает некоторую уверенность в том, что в ОО не будут внесены искажения во время разработки.
Таблица 4 - Оценочный уровень доверия 3
|
Класс доверия |
Компоненты доверия |
|
ADV: Разработка |
ADV_ARC.1 Описание архитектуры безопасности |
|
ADV_FSP.3 Функциональная спецификация с полной аннотацией | |
|
ADV_TDS.2 Архитектурный проект | |
|
AGD: Руководства |
AGD_OPE.1 Руководство пользователя по эксплуатации |
|
AGD_PRE.1 Подготовительные процедуры | |
|
ALC: Поддержка жизненного цикла |
ALC_CMC.3 Средства управления авторизацией |
|
ALC_CMS.3 Охват УК представления реализации | |
|
ALC_DEL.1 Процедуры поставки | |
|
ALC_DVS.1 Идентификация мер безопасности | |
|
ALC_LCD.1 Определенная разработчиком модель жизненного цикла | |
|
ASE: Оценка задания по безопасности |
ASE_CCL.1 Утверждения о соответствии |
|
ASE_ECD.1 Определение расширенных компонентов | |
|
ASE_INT.1 Введение ЗБ | |
|
ASE_OBJ.2 Цели безопасности | |
|
ASE_REQ.2 Производные требования безопасности | |
|
ASE_SPD.1 Определение проблемы безопасности | |
|
ASE_TSS.1 Краткая спецификация ОО | |
|
ATE: Тестирование |
ATE_COV.2 Анализ покрытия |
|
ATE_DPT.1 Тестирование: базовый проект | |
|
ATE_FUN.1 Функциональное тестирование | |
|
ATE_IND.2 Выборочное независимое тестирование | |
|
AVA: Оценка уязвимостей |
AVA_VAN.2 Анализ уязвимостей |
7.6. Оценочный уровень доверия 4 (ОУД4), предусматривающий методическое проектирование, тестирование и углубленную проверку
7.6.1. Цели
ОУД4 позволяет разработчику достичь максимального доверия путем применения надлежащего проектирования безопасности, основанного на хороших коммерческих практиках разработки, которые, даже будучи строгими, не требуют глубоких профессиональных знаний, навыков и других ресурсов. ОУД4 - самый высокий уровень, на который, вероятно, экономически целесообразно ориентироваться при оценке уже существующих продуктов.
Поэтому ОУД4 применим, когда разработчикам или пользователям требуется независимо подтвержденный уровень доверия от умеренного до высокого в ОО общего назначения и имеется готовность нести дополнительные, связанные с обеспечением безопасности, производственные затраты.
7.6.2. Компоненты доверия
ОУД4 (см. таблицу 5) обеспечивает доверие посредством ЗБ с полным содержанием и посредством анализа выполнения ФТБ из данного ЗБ с использованием функциональной спецификации, полной спецификации интерфейсов, руководств, описания базового модульного проекта ОО, а также подмножества реализации для понимания режима безопасности.
Анализ поддержан независимым тестированием ФБО, свидетельством разработчика о тестировании, основанном на функциональной спецификации и проекте ОО, выборочным независимым подтверждением результатов тестирования разработчиком и анализом уязвимостей (основанным на представленных свидетельствах по функциональной спецификации, проекту ОО, представлению реализации, описанию архитектуры безопасности и руководствам), демонстрирующим противостояние попыткам проникновения нарушителей, обладающих усиленным Базовым потенциалом нападения.
ОУД4 также обеспечивает доверие посредством использования мер управления средой разработки и дополнительного управления конфигурацией ОО, включая автоматизацию, и свидетельства безопасных процедур поставки.
ОУД4 представляет значимое увеличение доверия по сравнению с ОУД3, требуя более детальное описание проекта, представление реализации для всех ФБО и улучшенные механизмы и/или процедуры, что дает уверенность в том, что в ОО не будут внесены искажения во время разработки.
Таблица 5 - Оценочный уровень доверия 4
|
Класс доверия |
Компоненты доверия |
|
ADV: Разработка |
ADV_ARC.1 Описание архитектуры безопасности |
|
ADV_FSP.4 Полная функциональная спецификация | |
|
ADV_IMP.1 Представление реализации ФБО | |
|
ADV_TDS.3 Базовый модульный проект | |
|
AGD: Руководства |
AGD_OPE.1 Руководство пользователя по эксплуатации |
|
AGD_PRE.1 Подготовительные процедуры | |
|
ALC: Поддержка жизненного цикла |
ALC_CMC.4 Поддержка производства, процедуры приемки и автоматизации |
|
ALC_CMS.4 Охват УК отслеживания проблем | |
|
ALC_DEL.1 Процедуры поставки | |
|
ALC_DVS.1 Идентификация мер безопасности | |
|
ALC_LCD.1 Определенная разработчиком модель жизненного цикла | |
|
ALC_TAT.1 Полностью определенные инструментальные средства разработки | |
|
ASE: Оценка задания по безопасности |
ASE_CCL.1 Утверждения о соответствии |
|
ASE_ECD.1 Определение расширенных компонентов | |
|
ASE_INT.1 Введение ЗБ | |
|
ASE_OBJ.2 Цели безопасности | |
|
ASE_REQ.2 Производные требования безопасности | |
|
ASE_SPD.1 Определение проблемы безопасности | |
|
ASE_TSS.1 Краткая спецификация ОО | |
|
ATE: Тестирование |
ATE_COV.2 Анализ покрытия |
|
ATE_DPT.2 Тестирование: модули обеспечения безопасности | |
|
ATE_FUN.1 Функциональное тестирование | |
|
ATE_IND.2 Выборочное независимое тестирование | |
|
AVA: Оценка уязвимостей |
AVA_VAN.3 Сосредоточенный анализ уязвимостей |
7.7. Оценочный уровень доверия 5 (ОУД5), предусматривающий полуформальное проектирование и тестирование
7.7.1. Цели
ОУД5 позволяет разработчику достичь максимального доверия путем проектирования безопасности, основанного на строгой коммерческой практике разработки, поддержанного умеренным применением специализированных методов проектирования безопасности. Такие ОО будут, вероятно, проектироваться и разрабатываться с намерением достичь ОУД5. Скорее всего, дополнительные затраты, сопутствующие требованиям ОУД5 в части строгости разработки без применения специализированных методов разработки, не будут большими.
Поэтому ОУД5 применим, когда разработчикам или пользователям требуется независимо получаемый высокий уровень доверия для запланированной разработки со строгим подходом к разработке, не влекущим излишних затрат на применение узко специализированных методов проектирования безопасности.
7.7.2. Компоненты доверия
ОУД5 (см. таблицу 6) обеспечивает доверие посредством ЗБ с полным содержанием и посредством анализа выполнения ФТБ из данного ЗБ с использованием функциональной спецификации, полной спецификации интерфейсов, руководств, описания проекта ОО, а также всей его реализации для понимания режима безопасности. Кроме этого, также требуется модульное проектирование ФБО.
Анализ поддержан независимым тестированием ФБО, свидетельством разработчика о тестировании, основанном на функциональной спецификации, проекте ОО, выборочным независимым подтверждением результатов тестирования разработчиком и независимым анализом уязвимостей, демонстрирующим противостояние попыткам проникновения нарушителей с Умеренным потенциалом нападения.
ОУД5 также обеспечивает доверие посредством использования контроля среды разработки и всестороннего управления конфигурацией ОО, включая автоматизацию, и свидетельства безопасных процедур поставки.
ОУД5 представляет значимое увеличение доверия по сравнению с ОУД4, требуя полуформальное описание проекта, более структурированную (и, следовательно, лучше анализируемую) архитектуру и улучшенные механизмы и/или процедуры, что дает уверенность в том, что в ОО не будут внесены искажения во время разработки.
Таблица 6 - Оценочный уровень доверия 5
|
Класс доверия |
Компоненты доверия |
|
ADV: Разработка |
ADV_ARC.1 Описание архитектуры безопасности |
|
ADV_FSP.5 Полная полуформальная спецификация с дополнительной информацией об ошибках | |
|
ADV_IMP.1 Представление реализации ФБО | |
|
ADV_INT.2 Полностью определенная внутренняя структура | |
|
ADV_TDS.4 Полуформальный модульный проект | |
|
AGD: Руководства |
AGD_OPE.1 Руководство пользователя по эксплуатации |
|
AGD_PRE.1 Подготовительные процедуры | |
|
ALC: Поддержка жизненного цикла |
ALC_CMC.4 Поддержка производства, процедуры приемки и автоматизации |
|
ALC_CMS.5 Охват УК инструментальных средств разработки | |
|
ALC_DEL.1 Процедуры поставки | |
|
ALC_DVS.1 Идентификация мер безопасности | |
|
ALC_LCD.1 Определенная разработчиком модель жизненного цикла | |
|
ALC_TAT.2 Соответствие стандартам реализации | |
|
ASE: Оценка задания по безопасности |
ASE_CCL.1 Утверждения о соответствии |
|
ASE_ECD.1 Определение расширенных компонентов | |
|
ASE_INT.1 Введение ЗБ | |
|
ASE_OBJ.2 Цели безопасности | |
|
ASE_REQ.2 Производные требования безопасности | |
|
ASE_SPD.1 Определение проблемы безопасности | |
|
ASE_TSS.1 Краткая спецификация ОО | |
|
ATE: Тестирование |
ATE_COV.2 Анализ покрытия |
|
ATE_DPT.3 Тестирование: модульный проект | |
|
ATE_FUN.1 Функциональное тестирование | |
|
ATE_IND.2 Выборочное независимое тестирование | |
|
AVA: Оценка уязвимостей |
AVA_VAN.4 Методический анализ уязвимостей |
7.8. Оценочный уровень доверия 6 (ОУД6), предусматривающий полуформальную верификацию и тестирование проекта
7.8.1. Цели
ОУД6 позволяет разработчикам достичь высокого доверия путем применения методов проектирования безопасности в строго контролируемой среде разработки с целью получения высококачественного ОО для защиты высоко оцениваемых активов от значительных рисков.
Поэтому ОУД6 применим для разработки безопасных ОО с целью применения в условиях высокого риска, где ценность защищаемых активов оправдывает дополнительные затраты.
7.8.2. Компоненты доверия
ОУД6 (см. таблицу 7) обеспечивает доверие посредством ЗБ с полным содержанием и посредством анализа выполнения ФТБ из данного ЗБ с использованием функциональной спецификации, полной спецификации интерфейсов, руководств, проекта ОО, а также представления реализации для понимания режима безопасности. Доверие дополнительно достигается применением формальной модели выбранной политики безопасности ОО и полуформального представления функциональной спецификации, а также проекта ОО. Кроме этого, также требуется модульный и иерархический (по уровням) проект ФБО.
Анализ поддержан независимым тестированием ФБО, свидетельством разработчика о тестировании, основанном на функциональной спецификации, проекте ОО, выборочным независимым подтверждением результатов тестирования разработчиком и независимым анализом уязвимостей, демонстрирующим противостояние попыткам проникновения нарушителей с Высоким потенциалом нападения.
ОУД6 также обеспечивает доверие посредством использования структурированного процесса разработки, контроля среды разработки и всестороннего управления конфигурацией ОО, включая полную автоматизацию, и свидетельства безопасных процедур поставки.
ОУД6 представляет значимое увеличение доверия по сравнению с ОУД5, требуя проведения более всестороннего анализа, структурированное представление реализации, более стройную структуру (например, с разбиением на уровни), более всесторонний независимый анализ уязвимостей, а также улучшенное управление конфигурацией и улучшенный контроль среды разработки.
Таблица 7 - Оценочный уровень доверия 6
|
Класс доверия |
Компоненты доверия |
|
ADV: Разработка |
ADV_ARC.1 Описание архитектуры безопасности |
|
ADV_FSP.5 Полная полуформальная функциональная спецификация с дополнительной информацией об ошибках | |
|
ADV_IMP.2 Полное прослеживание представления реализации ФБО | |
|
ADV_INT.3 Минимальная сложность внутренней структуры системы | |
|
ADV_SPM.1 Формальная модель политики безопасности ОО | |
|
ADV_TDS.5 Полный полуформальный модульный проект | |
|
AGD: Руководства |
AGD_OPE.1 Руководство пользователя по эксплуатации |
|
AGD_PRE.1 Подготовительные процедуры | |
|
ALC: Поддержка жизненного цикла |
ALC_CMC.5 Расширенная поддержка |
|
ALC_CMS.5 Охват УК инструментальных средств разработки | |
|
ALC_DEL.1 Процедуры поставки | |
|
ALC_DVS.2 Достаточность мер безопасности | |
|
ALC_LCD.1 Определенная разработчиком модель жизненного цикла | |
|
ALC_TAT.3 Соответствие всех частей ОО стандартам реализации | |
|
ASE: Оценка задания по безопасности |
ASE_CCL.1 Утверждения о соответствии |
|
ASE_ECD.1 Определение расширенных компонентов | |
|
ASE_INT.1 Введение ЗБ | |
|
ASE_OBJ.2 Цели безопасности | |
|
ASE_REQ.2 Производные требования безопасности | |
|
ASE_SPD.1 Определение проблемы безопасности | |
|
ASE_TSS.1 Краткая спецификация ОО | |
|
ATE: Тестирование |
ATE_COV.3 Строгий анализ покрытия |
|
ATE_DPT.3 Тестирование: модульный проект | |
|
ATE_FUN.2 Упорядоченное функциональное тестирование | |
|
ATE_IND.3 Выборочное независимое тестирование | |
|
AVA: Оценка уязвимостей |
AVA_VAN.5 Усиленный методический анализ уязвимостей |
7.9. Оценочный уровень доверия 7 (ОУД7), предусматривающий формальную верификацию проекта и тестирование
7.9.1. Цели
ОУД7 применим при разработке безопасных ОО для использования в условиях чрезвычайно высокого риска и/или там, где высокая ценность активов оправдывает повышенные затраты. Практическое применение ОУД7 в настоящее время ограничено ОО, которые строго ориентированы на реализацию функциональных возможностей безопасности и для которых возможен всесторонний формальный анализ.
7.9.2. Компоненты доверия
ОУД7 (см. таблицу 8) обеспечивает доверие посредством ЗБ с полным содержанием и посредством анализа выполнения ФТБ из данного ЗБ с использованием функциональной спецификации, полной спецификации интерфейсов, руководств, проекта ОО, а также структурированного представления реализации. Доверие дополнительно достигается применением формальной модели выбранной политики безопасности ОО, полуформального представления функциональной спецификации и проекта ОО для понимания режима безопасности. Кроме этого, требуется также модульный, иерархический (по уровням) и простой проект ФБО.
Анализ поддержан независимым тестированием ФБО, свидетельством разработчика о тестировании, основанном на функциональной спецификации, проекте ОО и представлении реализации, полным независимым подтверждением результатов тестирования разработчиком и независимым анализом уязвимостей, демонстрирующим противостояние попыткам проникновения нарушителей с Высоким потенциалом нападения.
ОУД7 также обеспечивает доверие посредством использования структурированного процесса разработки, средств контроля среды разработки и всестороннего управления конфигурацией ОО, включая полную автоматизацию, и свидетельства безопасных процедур поставки.
ОУД7 представляет значимое увеличение доверия по сравнению с ОУД6, требуя более всесторонний анализ, использующий формальные представления и формальное соответствие, а также всестороннее тестирование.
Таблица 8 - Оценочный уровень доверия 7
|
Класс доверия |
Компоненты доверия |
|
ADV: Разработка |
ADV_ARC.1 Описание архитектуры безопасности |
|
ADV_FSP.6 Полная полуформальная функциональная спецификация с дополнительной формальной спецификацией | |
|
ADV_IMP.2 Полное прослеживание представления реализации ФБО | |
|
ADV_INT.3 Минимальная сложность внутренней структуры системы | |
|
ADV_SPM.1 Формальная модель политики безопасности ОО | |
|
ADV_TDS.6 Полный полуформальный модульный проект с формальным представлением проекта верхнего уровня | |
|
AGD: Руководства |
AGD_OPE.1 Руководство пользователя по эксплуатации |
|
AGD_PRE.1 Подготовительные процедуры | |
|
ALC: Поддержка жизненного цикла |
ALC_CMC.5 Расширенная поддержка |
|
ALC_CMS.5 Охват УК инструментальных средств разработки | |
|
ALC_DEL.1 Процедуры поставки | |
|
ALC_DVS.2 Достаточность мер безопасности | |
|
ALC_LCD.2 Измеримая модель жизненного цикла | |
|
ALC_TAT.3 Соответствие всех частей ОО стандартам реализации | |
|
ASE: Оценка задания по безопасности |
ASE_CCL.1 Утверждения о соответствии |
|
ASE_ECD.1 Определение расширенных компонентов | |
|
ASE_INT.1 Введение ЗБ | |
|
ASE_OBJ.2 Цели безопасности | |
|
ASE_REQ.2 Производные требования безопасности | |
|
ASE_SPD.1 Определение проблемы безопасности | |
|
ASE_TSS.1 Краткая спецификация ОО | |
|
ATE: Тестирование |
ATE_COV.3 Строгий анализ покрытия |
|
ATE_DPT.4 Тестирование: представление реализации | |
|
ATE_FUN.2 Упорядоченное функциональное тестирование | |
|
ATE_IND.3 Полное независимое тестирование | |
|
AVA: Оценка уязвимостей |
AVA_VAN.5 Усиленный методический анализ уязвимостей |
8. Составные пакеты доверия
Составные пакеты доверия (СоПД) образуют возрастающую шкалу, которая позволяет соотнести уровень полученного доверия с затратами и возможностью достижения этой степени доверия для составных ОО.
Важно отметить, что лишь небольшая часть семейств и компонентов доверия из ИСО/МЭК 15408-3 включена в составные пакеты доверия. Это связано с тем, что они основываются на результатах оценки ранее оцененных сущностей (базовых компонентов и зависимых компонентов) и в этой связи нельзя говорить, что они не обеспечивают значимое и требуемое доверие.
8.1. Обзор составных пакетов доверия (СоПД)
СоПД применяются к составным ОО, которые содержат компоненты, прошедшие (или проходящие) оценку как ОО-компоненты (см. приложение B). Отдельные компоненты должны быть сертифицированы по ОУД или другому пакету доверия, указанному в ЗБ. Предполагается, что базовый уровень доверия для составного ОО будет получен посредством применения ОУД1, который может быть достигнут с использованием общедоступной информации о компонентах (ОУД1 может применяться как к отдельным ОО-компонентам, так и к составным ОО). СоПД представляют альтернативный подход к получению более высоких уровней доверия для составного ОО по сравнению с применением ОУД выше ОУД1.
Хотя зависимый компонент может быть оценен с использованием ранее оцененных и сертифицированных базовых компонентов для удовлетворения требований, предъявляемых к ИТ-платформе в среде функционирования, это не обеспечивает какого-либо формального уровня доверия к взаимодействию компонентов или по отношению к учету возможного появления уязвимостей при объединении компонентов. Составные пакеты доверия учитывают такие взаимодействия и на более высоких уровнях доверия обеспечивают, что интерфейсы между компонентами являются предметом тестирования. Также выполняется анализ уязвимостей составного ОО с целью учета возможного появления уязвимостей вследствие объединения компонентов.
В таблице 9 представлен краткий обзор СоПД. В столбцах представлены иерархически упорядоченные СоПД, в строках представлены семейства доверия. Каждая цифра (при ее наличии) в полученной матрице определяет конкретный компонент доверия.
Как отмечается в следующем подразделе, в ИСО/МЭК 15408 для ранжирования доверия к составным ОО определены три иерархически упорядоченных составных пакета доверия. Они иерархически упорядочены, поскольку каждый последующий СоПД предоставляет большее доверие, чем все СоПД более низкого уровня. Увеличение доверия от СоПД к СоПД достигается путем замены компонента доверия на более высокий по иерархии компонент доверия из того же семейства доверия (т.е. усилением строгости, области охвата и/или глубины) и путем добавления компонентов доверия из других семейств доверия (т.е. путем добавления новых требований). Это приводит к более глубокому анализу композиции для определения влияния на ее оценку результатов, полученных для отдельных ОО-компонентов.
Эти СоПД состоят из соответствующей комбинации компонентов доверия, описанных в разделе 6 ИСО/МЭК 15408-3. А именно: каждый СоПД включает не более одного компонента из каждого семейства доверия, при этом все зависимости между компонентами доверия удовлетворены.
В СоПД рассматривается способность противостоять нарушителю с потенциалом нападения до Усиленного базового уровня. Это из-за того, что уровень представления информации о проекте, который может быть обеспечен через семейство ACO_DEV, ограничивает некоторые факторы, связанные с потенциалом нападения (например, знание составного ОО) и, следовательно, влияет на строгость анализа уязвимостей, проводимого оценщиком. Поэтому уровень доверия в составном ОО ограничен, хотя доверие к отдельным компонентам в рамках составного ОО может быть намного выше.
Таблица 9 - Краткий обзор составных уровней доверия
|
Класс доверия |
Семейство доверия |
Компоненты доверия в составных пакетах доверия | ||
|
СоПД-А |
СоПД-В |
СоПД-С | ||
|
Композиция |
ACO_COR |
1 |
1 |
1 |
|
АСО_СТТ |
1 |
2 |
2 | |
|
ACO_DEV |
1 |
2 |
3 | |
|
ACO_REL |
1 |
1 |
2 | |
|
ACO_VUL |
1 |
2 |
3 | |
|
Руководства |
AGD_OPE |
1 |
1 |
1 |
|
AGD_PRE |
1 |
1 |
1 | |
|
Поддержка жизненного цикла |
ALC_CMC |
1 |
1 |
1 |
|
ALC_CMS |
2 |
2 |
2 | |
|
ALC_DEL |
|
|
| |
|
ALC_DVS |
|
|
| |
|
ALC_FLR |
|
|
| |
|
ALC_LCD |
|
|
| |
|
ALC_TAT |
|
|
| |
|
Оценка задания по безопасности |
ASE_CCL |
1 |
1 |
1 |
|
ASE_ECD |
1 |
1 |
1 | |
|
ASE_INT |
1 |
1 |
1 | |
|
ASE_OBJ |
1 |
2 |
2 | |
|
ASE_REQ |
1 |
2 |
2 | |
|
ASE_SPD |
|
1 |
1 | |
|
ASE_TSS |
1 |
1 |
1 | |
8.2. Детализация составных пакетов доверия
В следующих подразделах содержатся определения СоПД, при этом различия между конкретными требованиями и описанием характеристик этих требований выделены полужирным шрифтом.
8.3. Составной уровень доверия A (СоПД-A), предусматривающий структурную композицию
8.3.1. Цели
СоПД-A применим, когда составной ОО интегрирован и требуется уверенность в корректности безопасного функционирования результирующей композиции. Это требует взаимодействия (кооперации) с разработчиком зависимого компонента по вопросам получения информации по проекту и результатов тестирования из материалов сертификации зависимого компонента без привлечения разработчика базового компонента.
Поэтому СоПД-A применим в тех случаях, когда разработчикам или пользователям требуется независимо подтвержденный уровень доверия к безопасности от низкого до умеренного при отсутствии прямой доступности полной информации о разработке.
8.3.2. Компоненты доверия
СоПД-A обеспечивает доверие путем анализа задания по безопасности для составного ОО. Для понимания режима безопасного функционирования ФТБ в ЗБ для составного ОО анализируются с использованием выходных данных оценки ОО-компонентов (например, ЗБ, руководств) и спецификации интерфейсов между ОО-компонентами в составном ОО.
Анализ поддержан независимым тестированием интерфейсов базового компонента, на которые полагаются зависимые компоненты, как описано в информации о зависимостях, свидетельстве тестирования разработчиком, базирующемся на информации о зависимостях, информации по разработке и обосновании композиции, а также выборочным независимым подтверждением результатов тестирования, выполненного разработчиком. Анализ также поддержан проводимым оценщиком кратким анализом уязвимостей составного ОО.
СоПД-A также обеспечивает доверие путем уникальной идентификации составного ОО (т.е. ИТ-части ОО и руководств).
Таблица 10 - СоПД-A
|
Класс доверия |
Компоненты доверия |
|
ACO: Композиция |
ACO_COR.1 Обоснование композиции |
|
ACO_CTT.1 Тестирование интерфейсов | |
|
ACO_DEV.1 Функциональное описание | |
|
ACO_REL.1 Базовая информация о зависимостях | |
|
ACO_VUL.1 Краткий анализ уязвимостей композиции | |
|
AGD: Руководства |
AGD_OPE.1 Руководство пользователя по эксплуатации |
|
AGD_PRE.1 Подготовительные процедуры | |
|
ALC: Поддержка жизненного цикла |
ALC_CMC.1 Маркировка ОО |
|
ALC_CMS.2 Охват УК частей ОО | |
|
ASE: Оценка задания по безопасности |
ASE_CCL.1 Утверждения о соответствии |
|
ASE_ECD.1 Определение расширенных компонентов | |
|
ASE_INT.1 Введение ЗБ | |
|
ASE_OBJ.1 Цели безопасности для среды функционирования | |
|
ASE_REQ.1 Установленные требования безопасности | |
|
ASE_TSS.1 Краткая спецификация ОО |
8.4. Составной уровень доверия B (СоПД-B), предусматривающий методическую композицию
8.4.1. Цели
СоПД-B позволяет добросовестному разработчику достигнуть максимального доверия на основе понимания на уровне подсистем влияния взаимосвязей между ОО-компонентами, включаемыми в составной ОО, при минимальной зависимости от привлечения разработчика базового компонента.
СоПД-B применим в тех случаях, когда разработчикам или пользователям требуется независимо подтвержденный умеренный уровень доверия к безопасности на основе всестороннего исследования составного ОО и процесса его разработки без существенного реинжиниринга (восстановления процесса проектирования).
8.4.2. Компоненты доверия
СоПД-B обеспечивает доверие путем анализа ЗБ с полным содержанием для составного ОО. Для понимания режима безопасного функционирования ФТБ в ЗБ для составного ОО анализируются с использованием выходных данных оценки ОО-компонентов (например, ЗБ, руководств), спецификации интерфейсов между ОО-компонентами и проекта ОО (описывающего подсистемы ФБО), содержащегося в информации по разработке композиции.
Анализ поддержан независимым тестированием интерфейсов базового компонента, на которые полагаются зависимые компоненты, как описано в информации о зависимостях (которая для данного СоПД также включает проект ОО), свидетельстве тестирования разработчиком, базирующемся на информации о зависимостях, информации по разработке и обосновании композиции ОО, а также выборочным независимым подтверждением результатов тестирования, выполненного разработчиком. Данный анализ также поддержан проводимым оценщиком анализом уязвимостей составного ОО, демонстрирующим противостояние нарушителю с Базовым потенциалом нападения.
Этот СоПД демонстрирует значительное увеличение уровня доверия по сравнению с СоПД-A, требуя более полного охвата тестированием функциональных возможностей безопасности.
Таблица 11 - СоПД-B
|
Класс доверия |
Компоненты доверия |
|
ACO: Композиция |
ACO_COR.1 Обоснование композиции |
|
ACO_CTT.2 Строгое тестирование интерфейсов | |
|
ACO_DEV.2 Базовое свидетельство по проекту | |
|
ACO_REL.1 Базовая информация о зависимостях | |
|
ACO_VUL.2 Анализ уязвимостей композиции | |
|
AGD: Руководства |
AGD_OPE.1 Руководство пользователя по эксплуатации |
|
AGD_PRE.1 Подготовительные процедуры | |
|
ALC: Поддержка жизненного цикла |
ALC_CMC.1 Маркировка ОО |
|
ALC_CMS.2 Охват УК частей ОО | |
|
ASE: Оценка задания по безопасности |
ASE_ Утверждения о соответствии |
|
ASE_ECD.1 Определение расширенных компонентов | |
|
ASE_INT.1 Введение ЗБ | |
|
ASE_OBJ.2 Цели безопасности | |
|
ASE_REQ.2 Производные требования безопасности | |
|
ASE_SPD.1 Определение проблемы безопасности | |
|
ASE_TSS.1 Краткая спецификация ОО |
8.5. Составной уровень доверия C (СоПД-C), предусматривающий методическую композицию, тестирование и проверку
8.5.1. Цели
СоПД-C позволяет разработчику достигнуть максимального доверия на основе точного анализа взаимосвязей между компонентами составного ОО, который несмотря на строгость не требует полного доступа ко всем свидетельствам базового компонента.
Поэтому СоПД-C применим, когда разработчикам или пользователям требуется независимо подтвержденный уровень доверия к безопасности от умеренного до высокого для ОО общего назначения и они готовы нести дополнительные затраты на проектирование, связанные с обеспечением безопасности.
8.5.2. Компоненты доверия
СоПД-C обеспечивает доверие путем анализа ЗБ с полным содержанием для составного ОО. Для понимания режима безопасного функционирования ФТБ в ЗБ составного ОО анализируются с использованием выходных данных оценки ОО-компонентов (например, ЗБ, руководств), спецификации интерфейсов между ОО-компонентами и проекта ОО (описывающего модули ФБО), содержащегося в информации по разработке композиции.
Анализ поддержан независимым тестированием интерфейсов базового компонента, на которые полагаются зависимые компоненты, как описано в информации о зависимостях (которая для данного СоПД также включает проект ОО), свидетельстве тестирования разработчиком, базирующемся на информации о зависимостях, информации по разработке и обосновании композиции ОО, а также выборочным независимым подтверждением результатов тестирования, выполненного разработчиком. Данный анализ также поддержан проводимым оценщиком анализом уязвимостей составного ОО, демонстрирующим противостояние нарушителю с усиленным базовым потенциалом нападения.
Этот СоПД дает значительное увеличение уровня доверия по сравнению с СоПД-B, требуя большего описания проекта и демонстрацию противостояния нарушителям с более высоким потенциалом нападения.
Таблица 12 - СоПД-C
|
Класс доверия |
Компоненты доверия |
|
ACO: Композиция |
ACO_COR.1 Обоснование композиции |
|
ACO_CTT.2 Строгое тестирование интерфейсов | |
|
ACO_DEV.3 Детализированное свидетельство по проекту | |
|
ACO_REL.2 Информация о зависимостях | |
|
ACO_VUL.3 Усиленный базовый анализ уязвимостей композиции | |
|
AGD: Руководства |
AGD_OPE.1 Руководство пользователя по эксплуатации |
|
AGD_PRE.1 Подготовительные процедуры | |
|
ALC: Поддержка жизненного цикла |
ALC_CMC.1 Маркировка ОО |
|
ALC_CMS.2 Охват УК частей ОО | |
|
ASE: Оценка задания по безопасности |
ASE_CCL.1 Утверждения о соответствии |
|
ASE_ECD.1 Определение расширенных компонентов | |
|
ASE_INT.1 Введение ЗБ | |
|
ASE_OBJ.2 Цели безопасности | |
|
ASE_REQ.2 Производные требования безопасности | |
|
ASE_SPD.1 Определение проблемы безопасности | |
|
ASE_TTS.1 Краткая спецификация ОО |
9. Класс APE: Оценка профиля защиты
Оценка ПЗ требуется для демонстрации того, что ПЗ является полным, непротиворечивым и правильным, а в случае, если ПЗ основывается на одном или нескольких других ПЗ или пакетах доверия, что этот ПЗ является корректной реализацией этих ПЗ и пакетов доверия. Эти свойства необходимы для того, чтобы ПЗ можно было использовать в качестве основы для разработки ЗБ или другого ПЗ.
Данный раздел ИСО/МЭК 15408-3 следует использовать в совокупности с приложениями A, B, C ИСО/МЭК 15408-1, в которых разъясняются некоторые принципы и понятия, описанные в данном подразделе, а также приводятся многочисленные примеры.
На рисунке 8 показаны семейства этого класса и иерархия компонентов этих семейств.
"Рис. 8. Декомпозиция класса APE "Оценка профиля защиты""
9.1. Введение ПЗ (APE_INT)
9.1.1. Цели
Цель данного семейства состоит в том, чтобы предоставить описание ОО в повествовательной форме.
Оценка "Введения ПЗ" требуется для демонстрации того, что ПЗ правильно идентифицирован, и что "Ссылка на ПЗ" и "Аннотация ОО" не противоречат друг другу.
9.1.2. APE_INT.1 Введение ПЗ
Зависимости: отсутствуют.
9.1.2.1. Элементы действий разработчика
9.1.2.1.1. APE_INT.1.1D
Разработчик ПЗ должен представить "Введение ПЗ".
9.1.2.2. Элементы содержания и представления свидетельств
9.1.2.2.1. APE_INT.1.1C
"Введение ПЗ" должно содержать "Ссылку на ПЗ" и "Аннотацию ОО".
9.1.2.2.2. APE_INT.1.2C
"Ссылка на ПЗ" должна уникально идентифицировать ПЗ.
9.1.2.2.3. APE_INT.1.3C
В "Аннотации ОО" должна быть представлена краткая информация об использовании и основных функциональных возможностях безопасности ОО.
9.1.2.2.4. APE_INT.1.4C
В "Аннотации ОО" должен быть идентифицирован тип ОО.
9.1.2.2.5. APE_INT.1.5C
В "Аннотации ОО" должны быть идентифицированы любые не входящие в ОО аппаратные, программные, а также программно-аппаратные средства, доступные для ОО.
9.1.2.3. Элементы действий оценщика
9.1.2.3.1. APE_INT.1.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
9.2. Утверждения о соответствии (APE_CCL)
9.2.1. Цели
Цель данного семейства заключается в том, чтобы сделать заключение об обоснованности утверждений о соответствии. Кроме того, в данном семействе специфицируется, соответствуют ли ЗБ и другие ПЗ данному ПЗ.
9.2.2. APE_CCL.1 Утверждения о соответствии
Зависимости: APE_INT.1 Введение ПЗ
APE_ECD.1 Определение расширенных компонентов
APE_REQ.1 Установленные требования безопасности.
9.2.2.1. Элементы действий разработчика
9.2.2.1.1. APE_CCL.1.1D
Разработчик ПЗ должен представить "Утверждение о соответствии".
9.2.2.1.2. APE_CCL.1.2D
Разработчик ПЗ должен представить "Обоснование утверждения о соответствии".
9.2.2.1.3. APE_CCL.1.3D
Разработчик ПЗ должен представить "Изложение соответствия".
9.2.2.2. Элементы содержания и представления свидетельств
9.2.2.2.1. APE_CCL.1.1C
В "Утверждения о соответствии" должно быть включено "Утверждение о соответствии ИСО/МЭК 15408", которое определяет, для какой редакции ИСО/МЭК 15408 утверждается соответствие ПЗ.
9.2.2.2.2. APE_CCL.1.2C
В "Утверждении о соответствии ИСО/МЭК 15408" должно приводиться описание соответствия ПЗ ИСО/МЭК 15408-2; ПЗ либо описывается как соответствующий требованиям ИСО/МЭК 15408-2, либо как содержащий расширенные по отношению к ИСО/МЭК 15408-2 требования.
9.2.2.2.3. APE_CCL.1.3C
В "Утверждении о соответствии ИСО/МЭК 15408" должно приводиться описание соответствия ПЗ ИСО/МЭК 15408-3; ПЗ либо описывается как соответствующий требованиям ИСО/МЭК 15408-3, либо как содержащий расширенные по отношению к ИСО/МЭК 15408-3 требования.
9.2.2.2.4. APE_CCL.1.4C
"Утверждение о соответствии ИСО/МЭК 15408" должно согласовываться с "Определением расширенных компонентов".
9.2.2.2.5. APE_CCL.1.5C
В "Утверждении о соответствии" должны быть идентифицированы все ПЗ и пакеты требований безопасности, о соответствии которым утверждается в ПЗ.
9.2.2.2.6. APE_CCL.1.6C
В "Утверждении о соответствии ПЗ пакету требований" должно приводиться описание любого соответствия ПЗ некоторому пакету требований; ПЗ либо описывается как соответствующий пакету требований, либо как содержащий расширенные по отношению к пакету требования.
9.2.2.2.7. APE_CCL.1.7C
В "Обосновании утверждений о соответствии" должно быть продемонстрировано, что тип ОО согласуется с типом ОО в тех ПЗ, о соответствии которым утверждается.
9.2.2.2.8. APE_CCL.1.8C
В "Обосновании утверждений о соответствии" должно быть продемонстрировано, что изложение определения проблемы безопасности согласуется с изложением определения проблемы безопасности тех ПЗ, о соответствии которым утверждается.
9.2.2.2.9. APE_CCL.1.9C
В "Обосновании утверждений о соответствии" должно быть продемонстрировано, что изложение "Целей безопасности" согласуется с изложением "Целей безопасности" в тех ПЗ, о соответствии которым утверждается.
9.2.2.2.10. APE_CCL.1.10C
В "Обосновании утверждений о соответствии" должно быть продемонстрировано, что изложение "Требований безопасности" согласуется с изложением "Требований безопасности" в тех ПЗ, о соответствии которым утверждается.
9.2.2.2.11. APE_CCL.1.11C
"Изложение соответствия" должно содержать описание соответствия, требуемого любыми ПЗ/ЗБ данному профилю защиты в виде строгого или демонстрируемого соответствия.
9.2.2.3. Элементы действий оценщика
9.2.2.3.1. APE_CCL.1.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
9.3. Определение проблемы безопасности (APE_SPD)
9.3.1. Цели
В данной части ПЗ определяется проблема безопасности, которая должна решаться применением ОО и его средой функционирования.
Оценка "Определения проблемы безопасности" требуется для того, чтобы продемонстрировать, что проблема безопасности данного ОО и среды его функционирования четко определена.
9.3.2. APE_SPD.1 Определение проблемы безопасности
Зависимости: отсутствуют.
9.3.2.1. Элементы действий разработчика
9.3.2.1.1. APE_SPD.1.1D
Разработчик ПЗ должен представить "Определение проблемы безопасности".
9.3.2.2. Элементы содержания и представления свидетельств
9.3.2.2.1. APE_SPD.1.1C
"Определение проблемы безопасности" должно включать в себя описание угроз.
9.3.2.2.2. APE_SPD.1.2C
Описание всех угроз должно проводиться в терминах источника угрозы, активов и негативного действия.
9.3.2.2.3. APE_SPD.1.3C
В "Определение проблемы безопасности" должно быть включено описание ПБОр.
9.3.2.2.4. APE_SPD.1.4C
"Определение проблемы безопасности" должно содержать описание предположений относительно среды функционирования ОО.
9.3.2.3. Элементы действий оценщика
9.3.2.3.1. APE_SPD.1.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
9.4. Цели безопасности (APE_OBJ)
9.4.1. Цели
Цели безопасности являются кратким изложением предполагаемой реакции на проблему безопасности, определенную в семействе доверия "Определение проблемы безопасности" (APE_SPD).
Оценка целей безопасности требуется для демонстрации того, что цели безопасности достаточно и в полной мере соответствуют "Определению проблемы безопасности", и что эта проблема четко разделена между ОО и средой его функционирования.
9.4.2. Ранжирование компонентов
Компоненты этого семейства ранжированы по следующему принципу - либо они описывают только цели безопасности для среды функционирования ОО, либо еще и цели безопасности для ОО.
9.4.3. APE_OBJ.1 Цели безопасности для среды функционирования
Зависимости: отсутствуют.
9.4.3.1. Элементы действий разработчика
9.4.3.1.1. APE_OBJ.1.1D
Разработчик ПЗ должен представить изложение "Целей безопасности".
9.4.3.2. Элементы содержания и представления свидетельств
9.4.3.2.1. APE_OBJ.1.1C
Изложение "Целей безопасности" должно включать в себя описание целей безопасности для среды функционирования ОО.
9.4.3.3. Элементы действий оценщика
9.4.3.3.1. APE_OBJ.1.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
9.4.4. APE_OBJ.2 Цели безопасности
Зависимости: APE_SPD.1 Определение проблемы безопасности.
9.4.4.1. Элементы действий разработчика
9.4.4.1.1. APE_OBJ.2.1D
Разработчик ПЗ должен представить изложение "Целей безопасности".
9.4.4.1.2. APE_OBJ.2.2D
Разработчик ПЗ должен представить "Обоснование целей безопасности".
9.4.4.2. Элементы содержания и представления свидетельств
9.4.4.2.1. APE_OBJ.2.1C
Изложение "Целей безопасности" должно включать в себя описание целей безопасности для ОО и для среды функционирования ОО.
9.4.4.2.2. APE_OBJ.2.2C
В "Обосновании целей безопасности" каждая цель безопасности для ОО должна быть прослежена к угрозам, на противостояние которым направлена эта цель безопасности, и к ПБОр, на осуществление которых направлена эта цель безопасности.
9.4.4.2.3. APE_OBJ.2.3C
В "Обосновании целей безопасности" каждая цель безопасности для ОО должна быть прослежена к угрозам, на противостояние которым направлена эта цель безопасности, к ПБОр, на осуществление которых направлена эта цель безопасности, а также к предположениям, поддерживаемым данной целью безопасности.
9.4.4.2.4. APE_OBJ.2.4C
В "Обосновании целей безопасности" должно быть продемонстрировано, что цели безопасности направлены на противостояние всем идентифицированным угрозам.
9.4.4.2.5. APE_OBJ.2.5C
В "Обосновании целей безопасности" должно быть продемонстрировано, что цели безопасности направлены на осуществление всех ПБОр.
9.4.4.2.6. APE_OBJ.2.6C
В "Обосновании целей безопасности" должно быть продемонстрировано, что цели безопасности для среды функционирования поддерживают все предположения.
9.4.4.3. Элементы действий оценщика
9.4.4.3.1. APE_OBJ.2.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
9.5. Определение расширенных компонентов (APE_ECD)
9.5.1. Цели
Расширенные требования безопасности являются требованиями, которые основываются не на компонентах ИСО/МЭК 15048-2 или ИСО/МЭК 15048-3, а на расширенных компонентах: компонентах, определяемых разработчиком ПЗ.
Оценка определения расширенных компонентов необходима для того, чтобы сделать заключение, что эти компоненты определены четко и однозначно, и что они необходимы, т.е. не могут быть в полной мере выражены через существующие компоненты ИСО/МЭК 15048-2 или ИСО/МЭК 15408-3.
9.5.2. APE_ECD.1 Определение расширенных компонентов
Зависимости: отсутствуют.
9.5.2.1. Элементы действий разработчика
9.5.2.1.1. APE_ECD.1.1D
Разработчик ПЗ должен представить изложение "Требований безопасности".
9.5.2.1.2. APE_ECD.1.2D
Разработчик ПЗ должен представить "Определение расширенных компонентов".
9.5.2.2. Элементы содержания и представления свидетельств
9.5.2.2.1. APE_ECD.1.1C
В изложении "Требований безопасности" должны быть идентифицированы все расширенные требования безопасности.
9.5.2.2.2. APE_ECD.1.2C
В "Определении расширенных компонентов" должен определяться расширенный компонент для каждого расширенного требования безопасности.
9.5.2.2.3. APE_ECD.1.3C
В "Определении расширенных компонентов" должно указываться, как каждый расширенный компонент связан с существующими компонентами, семействами и классами ИСО/МЭК 15408.
9.5.2.2.4. APE_ECD.1.4C
В "Определении расширенных компонентов" в качестве модели представления должны использоваться компоненты, семейства, классы и методология ИСО/МЭК 15408.
9.5.2.2.5. APE_ECD.1.5C
Расширенные компоненты должны состоять из измеримых объективных элементов, чтобы была возможность продемонстрировать соответствие или несоответствие этим элементам.
9.5.2.3. Элементы действий оценщика
9.5.2.3.1. APE_ECD.1.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
9.5.2.3.2. APE_ECD.1.2E
Оценщик должен подтвердить, что ни один из расширенных компонентов не может быть четко выражен с использованием существующих компонентов.
9.6. Требования безопасности (APE_REQ)
9.6.1. Цели
ФТБ формируют четкое, однозначное и технически правильное описание ожидаемого режима безопасности ОО. ТДБ формируют четкое, однозначное и технически правильное описание ожидаемых действий, которые будут предприняты для достижения доверия к ОО.
Оценка требований безопасности необходима для того, чтобы обеспечить их четкое, однозначное и технически правильное описание.
9.6.2. Ранжирование компонентов
Компоненты этого семейства ранжированы по следующему принципу - либо ФТБ устанавливаются "как есть", либо ФТБ являются производными от целей безопасности для ОО.
9.6.3. APE_REQ.1 Установленные требования безопасности
Зависимости: APE_ECD.1 Определение расширенных компонентов.
9.6.3.1. Элементы действий разработчика
9.6.3.1.1. APE_REQ.1.1D
Разработчик ПЗ должен представить изложение "Требований безопасности".
9.6.3.1.2. APE_REQ.1.2D
Разработчик ПЗ должен представить "Обоснование требований безопасности".
9.6.3.2. Элементы содержания и представления свидетельств
9.6.3.2.1. APE_REQ.1.1C
Изложение "Требований безопасности" должно содержать описание ФТБ и ТДБ.
9.6.3.2.2. APE_REQ.1.2C
Все субъекты, объекты, операции, атрибуты безопасности, внешние сущности и другие понятия, используемые в ФТБ и ТДБ, должны быть определены.
9.6.3.2.3. APE_REQ.1.3C
В изложении "Требований безопасности" должны быть идентифицированы все выполненные над требованиями безопасности операции.
9.6.3.2.4. APE_REQ.1.4C
Все операции должны выполняться правильно.
9.6.3.2.5. APE_REQ.1.5C
Каждая зависимость от "Требований безопасности" должна быть либо удовлетворена, либо должно приводиться обоснование неудовлетворения данной зависимости.
9.6.3.2.6. APE_REQ.1.6C
Изложение "Требований безопасности" должно быть внутренне непротиворечивым.
9.6.3.3. Элементы действий оценщика
9.6.3.3.1. APE_REQ.1.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
9.6.4. APE_REQ.2 Производные требования безопасности
Зависимости: APE_OBJ.2 Цели безопасности
APE_ECD.1 Определение расширенных компонентов.
9.6.4.1. Элементы действий разработчика
9.6.4.1.1. APE_REQ.2.1D
Разработчик ПЗ должен представить изложение "Требований безопасности".
9.6.4.1.2. APE_REQ.2.2D
Разработчик ПЗ должен представить "Обоснование требований безопасности".
9.6.4.2. Элементы содержания и представления свидетельств
9.6.4.2.1. APE_REQ.2.1C
Изложение "Требований безопасности" должно содержать описание ФТБ и ТДБ.
9.6.4.2.2. APE_REQ.2.2C
Все субъекты, объекты, операции, атрибуты безопасности, внешние сущности и другие понятия, используемые в ФТБ и ТДБ, должны быть определены.
9.6.4.2.3. APE_REQ.2.3C
В изложении "Требований безопасности" должны быть идентифицированы все выполненные над требованиями безопасности операции.
9.6.4.2.4. APE_REQ.2.4C
Все операции должны быть выполнены правильно.
9.6.4.2.5. APE_REQ.2.5C
Каждая зависимость от "Требований безопасности" должна быть либо удовлетворена, либо должно приводиться обоснование неудовлетворения зависимости.
9.6.4.2.6. APE_REQ.2.6C
В "Обосновании требований безопасности" должно быть представлено прослеживание каждого ФТБ к целям безопасности для ОО.
9.6.4.2.7. APE_REQ.2.7C
В "Обосновании требований безопасности" должно быть продемонстрировано, что ФТБ обеспечивают выполнение всех целей безопасности для ОО.
9.6.4.2.8. APE_REQ.2.8C
В "Обосновании требований безопасности" должно приводиться пояснение того, почему выбраны определенные ТДБ.
9.6.4.2.9. APE_REQ.2.9C
Изложение "Требований безопасности" должно быть внутренне непротиворечивым.
9.6.4.3. Элементы действий оценщика
9.6.4.3.1. APE_REQ.2.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
10. Класс ASE: Оценка задания по безопасности
Оценка ЗБ требуется для демонстрации того, что ЗБ является правильным и внутренне непротиворечивым, и если ЗБ основано на одном или более ПЗ или пакетах доверия, что ЗБ является корректной реализацией этих ПЗ и пакетов. Эти свойства необходимы для того, чтобы можно было использовать ЗБ в качестве основы при оценке ОО.
Данный раздел следует использовать в совокупности с приложениями A, B и C ИСО/МЭК 15408-1, в которых разъясняются некоторые принципы и понятия, описанные в данном подразделе, а также приводятся многочисленные примеры.
На рисунке 9 показаны семейства этого класса и иерархия компонентов этих семейств.
"Рис. 9. Декомпозиция класса ASE "Оценка ЗБ""
10.1. Введение ЗБ (ASE_INT)
10.1.1. Цели
Цель данного семейства состоит в том, чтобы описать ОО в повествовательной форме по трем уровням представления: "Ссылка на ОО", "Аннотация ОО" и "Описание ОО".
Оценка "Введения ЗБ" требуется для демонстрации правильной идентификации ЗБ и ОО, а также правильного описания ОО по трем уровням представления и непротиворечивости этих описаний друг другу.
10.1.2. ASE_INT.1 Введение ЗБ
Зависимости: отсутствуют.
10.1.2.1. Элементы действий разработчика
10.1.2.1.1. ASE_INT.1.1D
Разработчик ЗБ должен представить "Введение ЗБ".
10.1.2.2. Элементы содержания и представления свидетельств
10.1.2.2.1. ASE_INT.1.1C
"Введение ЗБ" должно содержать "Ссылку на ЗБ", "Ссылку на ОО", "Аннотацию ОО" и "Описание ОО".
10.1.2.2.2. ASE_INT.1.2C
"Ссылка на ЗБ" должна однозначно идентифицировать ЗБ.
10.1.2.2.3. ASE_INT.1.3C
"Ссылка на ОО" должна однозначно идентифицировать ОО.
10.1.2.2.4. ASE_INT.1.4C
В "Аннотации ОО" должна быть представлена краткая информация о его использовании и основных функциональных возможностях безопасности ОО.
10.1.2.2.5. ASE_INT.1.5C
В "Аннотации ОО" должен быть идентифицирован тип ОО.
10.1.2.2.6. ASE_INT.1.6C
В "Аннотации ОО" должны быть идентифицированы любые не входящие в ОО аппаратные, программные, а также программно-аппаратные средства, требуемые ОО.
10.1.2.2.7. ASE_INT.1.7C
"Описание ОО" должно включать описание физических границ ОО.
10.1.2.2.8. ASE_INT.1.8C
"Описание ОО" должно включать описание логических границ ОО.
10.1.2.3. Элементы действий оценщика
10.1.2.3.1. ASE_INT.1.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
10.1.2.3.2. ASE_INT.1.2E
Оценщик должен подтвердить, что "Ссылка на ОО", "Аннотация ОО" и "Описание ОО" не противоречат друг другу.
10.2. Утверждения о соответствии (ASE_CCL)
10.2.1. Цели
Цель данного семейства состоит в том, чтобы сделать заключение об обоснованности утверждений о соответствии. Кроме того, данное семейство определяет, каким образом утверждается о соответствии ЗБ заданному ПЗ.
10.2.2. ASE_CCL.1 Утверждения о соответствии
Зависимости: ASE_INT.1 Введение ЗБ
ASE_ECD.1 Определение расширенных компонентов
ASE_REQ.1 Установленные требования безопасности.
10.2.2.1. Элементы действий разработчика
10.2.2.1.1. ASE_CCL.1.1D
Разработчик должен представить "Утверждения о соответствии".
10.2.2.1.2. ASE_CCL.1.2D
Разработчик должен представить "Обоснование утверждений о соответствии".
10.2.2.2. Элементы содержания и представления свидетельств
10.2.2.2.1. ASE_CCL.1.1C
В "Утверждения о соответствии" должно быть включено "Утверждение о соответствии ИСО/МЭК 15408", которое определяет, для какой редакции ИСО/МЭК 15408 утверждается соответствие ЗБ и ОО.
10.2.2.2.2. ASE_CCL.1.2C
В "Утверждении о соответствии ИСО/МЭК 15408" должно приводиться описание соответствия ЗБ ИСО/МЭК 15408-2; ЗБ либо описывается как соответствующее требованиям ИСО/МЭК 15408-2, либо как содержащее расширенные по отношению к ИСО/МЭК 15408-2 требования.
10.2.2.2.3. ASE_CCL.1.3C
В "Утверждении о соответствии ИСО/МЭК 15408" должно приводиться описание соответствия ПЗ ИСО/МЭК 15408-3; ЗБ либо описывается как соответствующее требованиям ИСО/МЭК 15408-3, либо как содержащее расширенные по отношению к ИСО/МЭК 15408-3 требования.
10.2.2.2.4. ASE_CCL.1.4C
"Утверждение о соответствии ИСО/МЭК 15408" должно согласовываться с "Определением расширенных компонентов".
10.2.2.2.5. ASE_CCL.1.5C
В "Утверждении о соответствии" должны быть идентифицированы все ПЗ и пакеты требований безопасности, о соответствии которым утверждается в ЗБ.
10.2.2.2.6. ASE_CCL.1.6C
В "Утверждении о соответствии ЗБ пакету требований" должно приводиться описание любого соответствия ЗБ некоторому пакету требований; ЗБ либо описывается как соответствующее пакету требований, либо как содержащее расширенные по отношению к пакету требования.
10.2.2.2.7. ASE_CCL.1.7C
В "Обосновании утверждений о соответствии" должно быть продемонстрировано, что тип ОО согласуется с типом ОО в тех ПЗ, о соответствии которым утверждается.
10.2.2.2.8. ASE_CCL.1.8C
В "Обосновании утверждений о соответствии" должно быть продемонстрировано, что изложение "Определения проблемы безопасности" согласуется с изложением "Определения проблемы безопасности" в тех ПЗ, о соответствии которым утверждается.
10.2.2.2.9. ASE_CCL.1.9C
В "Обосновании утверждений о соответствии" должно быть продемонстрировано, что изложение "Целей безопасности" согласуется с изложением "Целей безопасности" в тех ПЗ, о соответствии которым утверждается.
10.2.2.2.10. ASE_CCL.1.10C
В "Обосновании утверждений о соответствии" должно быть продемонстрировано, что изложение "Требований безопасности" согласуется с изложением "Требований безопасности" в тех ПЗ, о соответствии которым утверждается.
10.2.2.3. Элементы действий оценщика
10.2.2.3.1. ASE_CCL.1.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
10.3. Определение проблемы безопасности (ASE_SPD)
10.3.1. Цели
В данной части ЗБ определяется проблема безопасности, которая должна решаться применением ОО и его средой функционирования.
Оценка "Определения проблемы безопасности" необходима для демонстрации того, что проблема безопасности конкретного ОО и его среды функционирования четко определена.
10.3.2. ASE_SPD.1 Определение проблемы безопасности
Зависимости: отсутствуют.
10.3.2.1. Элементы действий разработчика
10.3.2.1.1. ASE_SPD.1.1D
Разработчик должен представить "Определение проблемы безопасности".
10.3.2.2. Элементы содержания и представления свидетельств
10.3.2.2.1. ASE_SPD.1.1C
"Определение проблемы безопасности" должно включать в себя описание угроз.
10.3.2.2.2. ASE_SPD.1.2C
Описание всех угроз должно проводиться в терминах источника угрозы, активов и негативного действия.
10.3.2.2.3. ASE_SPD.1.3C
В "Определение проблемы безопасности" должно быть включено описание ПБОр.
10.3.2.2.4. ASE_SPD.1.4C
"Определение проблемы безопасности" должно содержать описание предположений относительно среды функционирования ОО.
10.3.2.3. Элементы действий оценщика
10.3.2.3.1. ASE_SPD.1.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
10.4. Цели безопасности (ASE_OBJ)
10.4.1. Цели
Цели безопасности являются кратким изложением предполагаемой реакции на проблему безопасности, определенную в семействе доверия "Определение проблемы безопасности" (ASE_SPD).
Оценка целей безопасности требуется для демонстрации того, что цели безопасности достаточно и в полной мере соответствуют "Определению проблемы безопасности", и что эта проблема четко разделена между ОО и средой его функционирования.
10.4.2. Ранжирование компонентов
Компоненты этого семейства ранжированы по следующему принципу - либо они описывают только цели безопасности для среды функционирования ОО, либо еще и цели безопасности для ОО.
10.4.3. ASE_OBJ.1 Цели безопасности для среды функционирования
Зависимости: отсутствуют.
10.4.3.1. Элементы действий разработчика
10.4.3.1.1. ASE_OBJ.1.1D
Разработчик должен представить изложение "Целей безопасности".
10.4.3.2. Элементы содержания и представления свидетельств
10.4.3.2.1. ASE_OBJ.1.1C
Изложение "Целей безопасности" должно включать в себя описание целей безопасности для среды функционирования ОО.
10.4.3.3. Элементы действий оценщика
10.4.3.3.1. ASE_OBJ.1.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
10.4.4. ASE_OBJ.2 Цели безопасности
Зависимости: ASE_SPD.1 Определение проблемы безопасности.
10.4.4.1. Элементы действий разработчика
10.4.4.1.1. ASE_OBJ.2.1D
Разработчик должен предоставить "Определение целей безопасности".
10.4.4.1.2. ASE_OBJ.2.2D
Разработчик должен предоставить "Обоснование целей безопасности".
10.4.4.2. Элементы содержания и представления свидетельств
10.4.4.2.1. ASE_OBJ.2.1C
Изложение "Целей безопасности" должно включать в себя описание целей безопасности для ОО и для среды функционирования ОО.
10.4.4.2.2. ASE_OBJ.2.2C
В "Обосновании целей безопасности" каждая цель безопасности для ОО должна быть прослежена к угрозам, на противостояние которым направлена эта цель безопасности, и к ПБОр, на осуществление которых направлена эта цель безопасности.
10.4.4.2.3. ASE_OBJ.2.3C
В "Обосновании целей безопасности" каждая цель безопасности для ОО должна быть прослежена к угрозам, на противостояние которым направлена эта цель безопасности, к ПБОр, на осуществление которых направлена эта цель безопасности, а также к предположениям, поддерживаемым данной целью безопасности.
10.4.4.2.4. ASE_OBJ.2.4C
В "Обосновании целей безопасности" должно быть продемонстрировано, что цели безопасности направлены на противостояние всем идентифицированным угрозам.
10.4.4.2.5. ASE_OBJ.2.5C
В "Обосновании целей безопасности" должно быть продемонстрировано, что цели безопасности направлены на осуществление всех ПБОр.
10.4.4.2.6. ASE_OBJ.2.6C
В "Обосновании целей безопасности" должно быть продемонстрировано, что цели безопасности для среды функционирования поддерживают все предположения.
10.4.4.3. Элементы действий оценщика
10.4.4.3.1. ASE_OBJ.2.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
10.5. Определение расширенных компонентов (ASE_ECD)
10.5.1. Цели
Расширенные требования безопасности являются требованиями, которые основываются не на компонентах функциональных требований ИСО/МЭК 15048-2 или на компонентах доверия ИСО/МЭК 15408-3, а на расширенных компонентах: компонентах, определяемых разработчиком ПЗ.
Оценка определения расширенных компонентов необходима для того, чтобы сделать заключение, что эти компоненты определены четко и однозначно, и что они необходимы, т.е. не могут быть в полной мере выражены через существующие компоненты ИСО/МЭК 15048-2 или ИСО/МЭК 15408-3.
10.5.2. ASE_ECD.1 Определение расширенных компонентов
Зависимости: отсутствуют.
10.5.2.1. Элементы действий разработчика
10.5.2.1.1. ASE_ECD.1.1D
Разработчик должен представить изложение "Требований безопасности".
10.5.2.1.2. ASE_ECD.1.2D
Разработчик должен представить "Определение расширенных компонентов".
10.5.2.2. Элементы содержания и представления свидетельств
10.5.2.2.1. ASE_ECD.1.1C
В изложении "Требований безопасности" должны быть идентифицированы все расширенные требования безопасности.
10.5.2.2.2. ASE_ECD.1.2C
В "Определении расширенных компонентов" должен определяться расширенный компонент для каждого расширенного требования безопасности.
10.5.2.2.3. ASE_ECD.1.3C
В "Определении расширенных компонентов" должно указываться, как каждый расширенный компонент связан с существующими компонентами, семействами и классами ИСО/МЭК 15408.
10.5.2.2.4. ASE_ECD.1.4C
В "Определении расширенных компонентов" должны использоваться в качестве модели представления компоненты, семейства, классы и методология ИСО/МЭК 15408.
10.5.2.2.5. ASE_ECD.1.5C
Расширенные компоненты должны состоять из измеримых объективных элементов, чтобы была возможность продемонстрировать соответствие или несоответствие этим элементам.
10.5.2.3. Элементы действий оценщика
10.5.2.3.1. ASE_ECD.1.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
10.5.2.3.2. ASE_ECD.1.2E
Оценщик должен подтвердить, что ни один из расширенных компонентов не может быть четко выражен с использованием существующих компонентов.
10.6. Требования безопасности (ASE_REQ)
10.6.1. Цели
ФТБ формируют четкое, однозначное и технически правильное описание ожидаемого режима безопасности ОО. ТДБ представляют четкое, однозначное и технически правильное описание ожидаемых действий, которые будут предприняты для достижения доверия к ОО.
Оценка требований безопасности необходима для того, чтобы обеспечить их четкое, однозначное и технически правильное описание.
10.6.2. Ранжирование компонентов
Компоненты данного семейства ранжированы в зависимости от их изложения.
10.6.3. ASE_REQ.1 Установленные требования безопасности
Зависимости: ASE_ECD.1 Определение расширенных компонентов.
10.6.3.1. Элементы действий разработчика
10.6.3.1.1. ASE_REQ.1.1D
Разработчик должен представить изложение "Требований безопасности".
10.6.3.1.2. ASE_REQ.1.2D
Разработчик должен представить "Обоснование требований безопасности".
10.6.3.2. Элементы содержания и представления свидетельств
10.6.3.2.1. ASE_REQ.1.1C
Изложение "Требований безопасности" должно содержать описание ФТБ и ТДБ.
10.6.3.2.2. ASE_REQ.1.2C
Все субъекты, объекты, операции, атрибуты безопасности, внешние сущности и другие понятия, используемые в ФТБ и ТДБ, должны быть определены.
10.6.3.2.3. ASE_REQ.1.3C
В изложении "Требований безопасности" должны быть идентифицированы все выполненные над требованиями безопасности операции.
10.6.3.2.4. ASE_REQ.1.4C
Все операции должны выполняться правильно.
10.6.3.2.5. ASE_REQ.1.5C
Каждая зависимость от требований безопасности должна быть либо удовлетворена, либо должно приводиться обоснование неудовлетворения данной зависимости.
10.6.3.2.6. ASE_REQ.1.6C
Изложение "Требований безопасности" должно быть внутренне непротиворечивым.
10.6.3.3. Элементы действий оценщика
10.6.3.3.1. ASE_REQ.1.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
10.6.4. ASE_REQ.2 Производные требования безопасности
Зависимости: ASE_OBJ.2 Цели безопасности
ASE_ECD.1 Определение расширенных компонентов.
10.6.4.1. Элементы действий разработчика
10.6.4.1.1. ASE_REQ.2.1D
Разработчик должен представить "Определение требований безопасности".
10.6.4.1.2. ASE_REQ.2.2D
Разработчик должен представить "Обоснование требований безопасности".
10.6.4.2. Элементы содержания и представления свидетельств
10.6.4.2.1. ASE_REQ.2.1C
Изложение "Требований безопасности" должно содержать описание ФТБ и ТДБ.
10.6.4.2.2. ASE_REQ.2.2C
Все субъекты, объекты, операции, атрибуты безопасности, внешние сущности и другие понятия, использующиеся в ФТБ и ТБД, должны быть определены.
10.6.4.2.3. ASE_REQ.2.3C
В изложении "Требований безопасности" должны быть идентифицированы все выполненные над требованиями безопасности операции.
10.6.4.2.4. ASE_REQ.2.4C
Все операции должны выполняться правильно.
10.6.4.2.5. ASE_REQ.2.5C
Каждая зависимость от "Требований безопасности" должна быть либо удовлетворена, либо должно приводиться обоснование неудовлетворения зависимости.
10.6.4.2.6. ASE_REQ.2.6C
В "Обосновании требований безопасности" должно быть представлено прослеживание каждого ФТБ к целям безопасности для ОО.
10.6.4.2.7. ASE_REQ.2.7C
В "Обосновании требований безопасности" должно быть продемонстрировано, что ФТБ обеспечивают выполнение всех целей безопасности для ОО.
10.6.4.2.8. ASE_REQ.2.8C
В "Обосновании требований безопасности" должно приводиться пояснение того, почему выбраны определенные ТДБ.
10.6.4.2.9. ASE_REQ.2.9C
Изложение "Требований безопасности" должно быть внутренне непротиворечивым.
10.6.4.3. Элементы действий оценщика
10.6.4.3.1. ASE_REQ.2.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
10.7. Краткая спецификация ОО (ASE_TSS)
10.7.1. Цели
Краткая спецификация ОО позволяет оценщикам и потенциальным потребителям получить общее представление о реализации ОО.
Оценка краткой спецификации ОО необходима для того, чтобы сделать заключение о том, в достаточной ли мере в ней описано, каким образом ОО:
выполняет ФТБ;
защищает себя от вмешательства, логического искажения и обхода;
а также согласуется ли краткая спецификация ОО с другими словесными описаниями ОО.
10.7.2. Ранжирование компонентов
Компоненты этого семейства ранжированы в зависимости от того, требуется ли в краткой спецификации указать только то, каким образом ОО выполняет ФТБ, или в ней необходимо указать также, каким образом ОО защищает себя от логического искажения и обхода. Это дополнительное описание может использоваться в особых случаях, когда имеется особая проблема архитектуры безопасности ОО.
10.7.3. ASE_TSS.1 Краткая спецификация ОО
Зависимости: ASE_INT.1 Введение ЗБ
ASE_REQ.1 Установленные требования безопасности
ADV_FSR.1 Базовая функциональная спецификация.
10.7.3.1. Элементы действий разработчика
10.7.3.1.1. ASE_TSS.1.1D
Разработчик должен представить краткую спецификацию ОО.
10.7.3.2. Элементы содержания и представления свидетельств
10.7.3.2.1. ASE_TSS.1.1C
Краткая спецификация ОО должна описывать, каким образом ОО выполняет каждое ФТБ.
10.7.3.3. Элементы действий оценщика
10.7.3.3.1. ASE_TSS.1.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
10.7.3.3.2. ASE_TSS.1.2E
Оценщик должен подтвердить, что краткая спецификация ОО не противоречит "Аннотации ОО" и "Описанию ОО".
10.7.4. ASE_TSS.2 Краткая спецификация ОО с аннотацией проекта архитектуры
Зависимости: ASE_INT.1 Введение ЗБ
ASE_REQ.1 Установленные требования безопасности
ADV_ARC.1 Описание архитектуры безопасности.
10.7.4.1. Элементы действий разработчика
10.7.4.1.1. ASE_TSS.2.1D
Разработчик должен представить краткую спецификацию ОО.
10.7.4.2. Элементы содержания и представления свидетельств
10.7.4.2.1. ASE_TSS.2.1C
Краткая спецификация ОО должна описывать, каким образом ОО выполняет каждое ФТБ.
10.7.4.2.2. ASE_TSS.2.2C
Краткая спецификация ОО должна описывать, каким образом ОО противостоит попыткам вмешательства и логического искажения.
10.7.4.2.3. ASE_TSS.2.3C
Краткая спецификация ОО должна описывать, каким образом ОО противостоит попыткам обхода защиты.
10.7.4.3. Элементы действий оценщика
10.7.4.3.1. ASE_TSS.2.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
10.7.4.3.2. ASE_TSS.2.2E
Оценщик должен подтвердить, что краткая спецификация ОО не противоречит "Аннотации ОО" и "Описанию ОО".
11. Класс ADV: Разработка
Требования класса "Разработка" предоставляют информацию об объекте оценки. Сведения, полученные путем изучения этой информации, служат основой для проведения анализа уязвимостей и тестирования ОО в соответствии с описанием, представленным в классах AVA "Анализ уязвимостей" и ATE "Тестирование".
Класс "Разработка" содержит шесть семейств доверия для структурирования и представления ФБО на различных уровнях детализации. Эти семейства включают в себя:
- требования к описанию (на различных уровнях детализации) проекта и реализации ФТБ (ADV_FSP "Функциональная спецификация", ADV_TDS "Проект ОО", ADV_IMP "Представление реализации");
- требования к описанию архитектурно-ориентированных особенностей разделения доменов, обеспечения собственной защиты ФБО и невозможности обхода ФБО (ADV_ARC "Архитектура безопасности);
- требования к модели политики безопасности и к прослеживанию соответствия между моделью политики безопасности и функциональной спецификацией (ADV_SPM "Моделирование политики безопасности");
- требования к внутренней структуре ФБО, которые охватывают такие аспекты, как модульность, деление на уровни и минимизацию сложности (ADV_INT "Внутренняя структура ФБО").
При документировании функциональных возможностей безопасности ОО необходимо продемонстрировать два основных свойства. Первое свойство заключается в том, что определенная функциональная возможность выполняется правильно, согласно спецификации. Второе свойство, которое несколько сложнее продемонстрировать, заключается в том, что невозможно использовать ОО так, чтобы это привело к искажению или обходу функциональных возможностей безопасности. Два этих свойства требуют применения различных подходов к их анализу, поэтому семейства класса ADV "Разработка" структурированы таким образом, чтобы поддерживать реализацию этих подходов. Семейства "Функциональная спецификация" (ADV_FSP), "Проект ОО" (ADV_TDS), "Представление реализации" (ADV_IMP) и "Моделирование политики безопасности" (ADV_SPM) направлены на представление первого свойства: спецификации функциональных возможностей безопасности. Семейства "Архитектура безопасности" (ADV_ARC) и "Внутренняя структура ФБО" (ADV_INT) направлены на представление второго свойства: спецификации проекта ОО, показывающей, что определенную функциональную возможность безопасности невозможно исказить или обойти. Следует отметить, что необходимо реализовать оба этих свойства: чем больше уверенности в том, что эти свойства реализованы, тем больше уровень доверия к ОО. Компоненты в этих семействах организованы таким образом, что при использовании компонентов, находящихся выше по иерархии, обеспечивается больший уровень доверия.
Парадигма для семейств данного класса, связанных с первым свойством, заключается в декомпозиции проекта. На самом верхнем уровне - функциональная спецификация ФБО в терминах интерфейсов ФБО (описывающая, что именно выполняют ФБО в части запросов к сервисам ФБО и реакции на эти запросы), которая проводит декомпозицию ФБО на подсистемы (в зависимости от сложности ОО и от того, какой уровень доверия необходим) и описывает то, каким образом ФБО выполняет свои функциональные возможности (на уровне детализации, соответствующем уровню доверия), а также демонстрирует реализацию ФБО. Также может быть представлена формальная модель режима безопасности. Все уровни декомпозиции используются для того, чтобы сделать заключение о полноте и точности всех прочих уровней, что обеспечивает их взаимную поддержку. Требования для различных представлений ФБО выделены в разные семейства, чтобы позволить разработчику ПЗ/ЗБ определить, какие именно представления ФБО необходимы. В соответствии с выбранным уровнем будет устанавливаться, какое доверие требуется/достигается.
На рисунке 10 показаны взаимосвязи между различными представлениями ФБО по классу ADV "Разработка", а также их взаимосвязи с другими классами. Как показано на этом рисунке, классы APE "Оценка ПЗ" и ASE "Оценка ЗБ" определяют требования соответствия между ФТБ и целями безопасности для ОО. Класс ASE "Оценка ЗБ" также определяет требования к соответствию между целями безопасности, функциональными требованиями и краткой спецификацией ОО, в которой объясняется, каким образом ОО соответствует функциональным требованиям. Действия оценщика в соответствии с элементом ALC_CMC.5.2.E включают в себя верификацию того, что ФБО, тестируемые по классам ATE "Тестирование" и AVA "Оценка уязвимостей", являются фактически теми же ФБО, которые описаны на всех уровнях декомпозиции в классе доверия ADV "Разработка".
Требования для всех других соответствий, показанных на рисунке 10, определены в классе ADV "Разработка". Семейство ADV_SPM "Моделирование политики безопасности" определяет требования к выбранным ФТБ формальной модели и предоставляет соответствие между функциональной спецификацией и формальной моделью. Каждое семейство, относящееся к конкретному представлению ФБО (т.е. ADV_FSP "Функциональная спецификация", ADV_TDS "Проект ОО" и ADV_IMP "Представление реализации"), определяет требования, относящиеся к соответствию между представлением ФБО и ФТБ. Каждый элемент декомпозиции должен точно отображать все прочие элементы (т.е. все элементы декомпозиции должны быть взаимоподдерживающими); разработчик обеспечивает прослеживание между представлениями ФБО и ФТБ в последних элементах компонентов под рубрикой "Элементы содержания и представления свидетельств" (обозначение - ".C"). Доверие относительно этого фактора достигается в процессе анализа каждого из уровней декомпозиции путем ссылки конкретного уровня на другие уровни декомпозиции (рекурсивным образом) в процессе анализа этого конкретного уровня декомпозиции; оценщик верифицирует их соответствие как часть выполнения второго элемента группы компонентов "Элементы действий оценщика" (обозначение - ".E"). Полученная от этих уровней декомпозиции информация служит основой для усилий по функциональному тестированию и тестированию проникновения.
Семейство ADV_INT "Внутренняя структура ФБО" не представлено на рисунке 10, поскольку оно связано с внутренней структурой ФБО и имеет лишь косвенное отношение к процессу уточнения представлений ФБО. Также не представлено и семейство ADV_RCR "Архитектура безопасности", которое имеет большее отношение к целостности архитектуры, чем к представлению ФБО. Оба этих семейства, ADV_INT "Внутренняя структура" и ADV_RCR "Архитектура безопасности", относятся к анализу свойства ОО, которое заключается в невозможности искажения или обхода функциональных возможностей безопасности ОО.
"Рис. 10. Взаимосвязи между компонентами класса ADV и с другими семействами"
Функциональные возможности безопасности ОО (ФБО) представляют собой совокупность всех функциональных возможностей различных частей ОО, на которых полагаются с целью осуществления ФТБ. ФБО включают в себя как функции, которые непосредственно осуществляют ФТБ, так и функции, которые, не осуществляя ФТБ непосредственно, косвенно содействуют осуществлению ФТБ. Сюда же включаются и функциональные возможности, при недостаточности или отсутствии которых возможны нарушения ФТБ. К таким функциональным возможностям относятся и те части ОО, которые на стадии запуска ОО должны привести ФБО в первоначальное безопасное состояние.
При разработке компонентов семейств класса ADV "Разработка" применялось несколько важных принципов. Эти принципы кратко рассматриваются в данном разделе, а более подробно объясняются в замечаниях по применению для семейств.
Самый важный принцип заключается в том, что при получении большего объема информации можно получить большее доверие тому, что функциональные возможности безопасности: 1) правильно реализованы, 2) не могут быть искажены, 3) не могут быть подвержены обходу. Это осуществляется путем верификации того, что документация составлена верно и не противоречит иной документации, а также посредством представления информации, которую можно использовать для подтверждения того, что проводимые тестовые испытания (как функциональное тестирование, так и тестирование проникновения) являются исчерпывающими. Это отражается в ранжировании компонентов семейств. В общем случае компоненты ранжированы в зависимости от того, какой объем информации должен быть представлен (и впоследствии проанализирован).
Хотя это справедливо не для всех ОО, но в большинстве случаев документ, описывающий функциональные возможности безопасности, является достаточно сложным, и некоторые его части требуют более тщательного изучения, чем другие. Выявление таких частей осуществляется, к сожалению, субъективным образом, поэтому терминология и компоненты доверия определяются так, что при увеличении уровня доверия ответственность за выявление тех частей ФБО, которые нужно проанализировать детально, переходит от разработчика к оценщику. Для описания данного принципа вводится специальная терминология, представленная далее. Следует отметить, что в семействах класса эта терминология используется для описания связанных с ФТБ частями ОО (т.е. для элементов и шагов оценивания семейств ADV_FSP "Функциональная спецификация", ADV_TDS "Проект ОО", ADV_IMP "Представление реализации"). Хотя общий принцип (о том, что некоторые части ОО являются более интересными для анализа) применим и к другим семействам, критерии излагаются по-разному для получения требуемого уровня доверия.
Все части ФБО являются значимыми для безопасности, что означает, что они должны обеспечивать безопасность ОО согласно ФТБ и требованиям разделения доменов и невозможности обхода ФБО. Один из аспектов важности ФБО для безопасности - в какой степени ФБО обеспечивают выполнение требований безопасности. Так как различные части ОО выполняют различные роли (или вовсе не играют никакой явной роли) в осуществлении требований безопасности, значимость этих функциональных возможностей для выполнения ФТБ можно представить в виде определенного ряда. В начале его находятся те части ОО, которые осуществляют выполнение ФТБ. Такие части непосредственно участвуют в реализации тех или иных ФТБ в ОО. Такие ФТБ относятся ко всем функциональным возможностям, которые представлены одним из ФТБ, содержащимся в ЗБ. Следует отметить, что значимость функциональных возможностей для обеспечения выполнения ФТБ невозможно выразить количественно. Например, в механизме реализации Дискреционного управления доступом (ДУД), в узком смысле к осуществлению выполнения ФТБ можно отнести несколько строк кода, которые обеспечивают проверку соответствия атрибутов безопасности субъекта атрибутам объекта. При более широком рассмотрении к этой же категории можно добавить объект программного обеспечения (например, функцию на языке программирования Си), содержащий несколько строк программного кода. При еще более широком рассмотрении туда же включаются операторы вызова функции языка программирования Си, так как именно они отвечают за обеспечение принятия решения о доступе после проверки атрибутов. Еще более широкое рассмотрение включает любой фрагмент кода в дереве вызовов (или программный эквивалент в зависимости от используемого языка программирования) данной функции языка программирования Си (например, функции сортировки, которая проводит сортировку списка контроля и управления доступом по алгоритму первого совпадения). Иногда компонент является не столько осуществляющим выполнение политики безопасности, сколько играющим роль поддержки; такие компоненты называются поддерживающими выполнение ФТБ.
Одна из характеристик функциональных возможностей, поддерживающих ФТБ, заключается в том, что они должны обеспечивать стабильную правильность реализации ФТБ посредством функционирования без ошибок. Такие функциональные возможности могут зависеть от функций, осуществляющих ФТБ, но в основном на функциональном уровне, например: управление памятью, управление буферизацией и т.д. Далее по ряду значимости для безопасности находятся функциональные возможности, называемые не влияющими на выполнение ФТБ. Они не участвуют в реализации ФТБ, а частью ФБО являются, скорее всего, из-за среды их функционирования. Это, например, любой программный код, запущенный в операционной системе в привилегированном аппаратном режиме. Его следует рассматривать как часть ФБО потому, что в случае искажения (или в случае замены вредоносным кодом) он может нарушить правильность выполнения ФТБ в силу того, что выполнялся в привилегированном режиме. Примером функциональных возможностей, не влияющих на выполнение ФТБ, может быть набор математических операций над числами с плавающей запятой, выполняемый для быстроты вычислений в режиме ядра ОС.
Семейство "Архитектура безопасности" (ADV_ARC) служит для описания требований и анализа ОО на основе свойств разделения доменов, собственной защиты ФБО и невозможности обхода ФБО. Эти свойства имеют значение для выполнения ФТБ, так как их отсутствие приведет, скорее всего, к сбою механизмов, осуществляющих реализацию ФТБ. Функциональные возможности этих свойств и проект, относящийся к ним, при этом рассматриваются не как часть описанного выше ряда значимости, а отдельно - в силу того, что они совершенно иные по сути и к их анализу предъявляются другие требования.
Разница в анализе реализации ФТБ (функциональных возможностей, осуществляющих и поддерживающих выполнение ФТБ) и реализации некоторых фундаментальных свойств безопасности ОО (к которым относится инициализация, собственная защита ФБО и невозможность обхода ФБО) заключается в том, что функциональные возможности, имеющие отношение к ФТБ, являются более или менее явными и относительно легко тестируемыми, а вышеупомянутые свойства требуют анализа гораздо более широкого набора функций на различных уровнях. Кроме того, глубина требуемого анализа данных свойств будет варьироваться в зависимости от проекта ОО. Семейства класса ADV "Разработка" обеспечивают выполнение этого отдельным семейством (ADV_ARC "Архитектура безопасности"), которое посвящено анализу требований инициализации, собственной защиты ФБО и невозможности обхода ФБО, в то время как другие семейства связаны с анализом функций, обеспечивающих поддержку выполнения ФТБ.
Даже в тех случаях, когда необходимы различные описания на разных уровнях детализации, совсем необязательно каждое представление ФБО оформлять в виде отдельного документа. Возможна ситуация, когда в одном документе выполняются требования по документированию нескольких представлений ФБО, а объединение в нем требуемой информации по каждому из этих представлений ФБО предпочтительнее, несмотря на усложнение структуры данного документа. В случае, когда несколько представлений ФБО объединены в одном документе, разработчику следует указать, какие части документа удовлетворяют определенным требованиям.
Этим классом узаконены три типа стиля изложения спецификаций: неформальный, полуформальный и формальный. Функциональная спецификация и документация по проекту ОО всегда излагаются с применением либо неформального, либо полуформального стиля изложения. Применение полуформального стиля изложения уменьшает неоднозначность в спецификациях по сравнению с неформальным стилем изложения. Кроме того, в дополнение к полуформальному представлению может потребоваться и предоставление формальной спецификации; преимущество такого требования в том, что описание ФБО несколькими способами увеличивает доверие к тому, что ФБО полно и точно определены.
Неформальную спецификацию излагают как повествовательный текст на естественном языке. Под естественным языком здесь подразумевается применение выразительных средств общения любого разговорного языка (например, английского, немецкого, русского, французского, испанского и т.д.). Неформальная спецификация не подчинена никаким нотационным или специальным ограничениям, отличным от общепринятых соглашений для этого языка (таких как грамматика и синтаксис). Хотя не применяются никакие нотационные ограничения, в неформальной спецификации все же требуется привести определения значений терминов, использование которых в контексте отличается от общепринятого.
Разница между документами неформального и полуформального стиля изложения заключается только в форматировании и способе представления: в документах полуформального стиля приводится подробный глоссарий используемых терминов и определений, применяется стандартизованная структура документа и т.д. Документы полуформального стиля изложения составляются по стандартному шаблону. В случае если документ составляется на естественном языке, в нем следует использовать соответствующие данному языку термины и определения. Кроме того, в представление могут включаться более структурированные языковые средства или схемы (например, диаграммы потока данных, диаграммы переходных состояний, диаграммы вида "объекты-отношения", схемы представления структур данных, процессов или программ). Независимо от того, основывается ли представление на диаграммах и схемах или на средствах естественного языка, при его составлении необходимо соблюдение определенных правил. Приводимый глоссарий должен содержать полные, подробные, точные и однозначные определения использованных в документе слов и словосочетаний; стандартизованная структура документа должна подразумевать, что при методологическом составлении документа особое внимание было уделено тому, чтобы он был максимально понятен. Следует отметить, что совершенно разные части ФБО могут описываться с использованием различных правил полуформального стиля изложения, касающихся оформления и систем обозначений (по крайней мере, пока количество различных полуформальных систем обозначений невелико), это не противоречит принципам полуформального изложения.
Формальную спецификацию излагают с использованием обозначений, основанных на известных математических понятиях, и обычно сопровождают вспомогательным пояснительным (неформальным) текстом. Эти математические понятия используются для определения синтаксиса и семантики системы обозначений и правил доказательства, поддерживающих логическое обоснование. Следует, чтобы в синтаксических и семантических правилах, регламентирующих формальную нотацию, определялось, как однозначно распознавать конструкции и определять их значение. Требуется свидетельство невозможности получения противоречивых выводов, а все правила, регламентирующие систему обозначений, необходимо определить или на них необходимо ссылаться.
На рисунке 11 показаны семейства данного класса и иерархия компонентов в семействах.
"Рис. 11. Декомпозиция класса ADV "Разработка""
11.1. Архитектура безопасности (ADV_ARC)
11.1.1. Цели
В настоящем семействе разработчик предоставляет "Описание архитектуры безопасности" ФБО, что позволяет провести анализ информации, который, в совокупности с другими представленными свидетельствами по ФБО, послужит подтверждением того, что ФБО обладают необходимыми свойствами. "Описание архитектуры безопасности" поддерживает выполнение неявного требования возможности анализа безопасности ОО путем изучения ФБО; в ином случае, при отсутствии полного описания архитектуры, для анализа безопасности потребуется изучение всех функциональных возможностей ОО.
11.1.2. Ранжирование компонентов
Семейство содержит только один компонент.
11.1.3. Замечания по применению
Свойства собственной защиты ФБО, разделения доменов, невозможности обхода ФБО отличаются от функций безопасности, отраженных в ФТБ ИСО/МЭК 15408-2, так как собственная защита и невозможность обхода не имеют непосредственно видимого интерфейса в ФБО. Они относятся к свойствам ФБО, которые достигаются посредством проекта ОО и ФБО и осуществляются правильной реализацией этих проектов.
Подход, использующийся в данном семействе, заключается в том, что разработчик проектирует и предоставляет ФБО, которые соответствуют вышеупомянутым свойствам, а также предоставляет свидетельства (в форме документации), объясняющие эти свойства ФБО. Объяснение приводится с тем же уровнем детализации, что и описание осуществляющих выполнение ФТБ элементов ОО в проекте ОО. В обязанности оценщика входит изучение представленных свидетельств в совокупности с другими свидетельствами по ОО и ФБО и вынесение заключения о том, достигается ли реализация заявленных свойств.
В спецификации функциональных возможностей безопасности, осуществляющих выполнение ФТБ (представленных в семействах ADV_FSP "Функциональная спецификация" и ADV_TDS "Проект ОО"), не обязательно содержится описание механизмов, обеспечивающих свойства собственной защиты и невозможности обхода (например, механизмов управления памятью). Поэтому сведения, необходимые для получения доверия тому, что эти свойства выполняются, предпочтительнее представить отдельно от декомпозиции проекта ФБО, как это представлено в семействах ADV_FSP "Функциональная спецификация" и ADV_TDS "Проект ОО". Это не подразумевает, что в "Описании архитектуры безопасности", требуемом для данного компонента, не могут использоваться сведения, представленные в проекте декомпозиции, или ссылки на него; но, скорее всего, многие детали, представленные в документации по декомпозиции, не будут значимыми для свидетельств, представленных в документе "Описание архитектуры безопасности".
Описание архитектурной целостности может быть выполнено посредством проведения разработчиком анализа уязвимостей, в процессе которого должно быть получено логическое обоснование того, что ФБО являются полными и осуществляют выполнение всех ФТБ. В случае если целостность достигается особыми механизмами безопасности, эти механизмы тестируются в части требований глубины (ATE_DPT); если целостность достигается только за счет архитектуры безопасности, режим ее безопасности будет тестироваться по требованиям части класса AVA "Требования оценки уязвимостей".
В данном семействе содержатся требования, предъявляемые к описанию архитектуры безопасности, которые относятся к принципам собственной защиты, разделения доменов и невозможности обхода, включая описание того, как эти принципы поддерживаются частями ОО, используемыми при инициализации ФБО.
Дополнительная информация по таким свойствам архитектуры безопасности, как обеспечение собственной защиты, разделения доменов и невозможности обхода, представлена в Приложении A.1, ADV_ARC "Дополнительные сведения по архитектуре безопасности".
11.1.4. ADV_ARC.1 Описание архитектуры безопасности
Зависимости: ADV_FSP.1 Базовая функциональная спецификация
ADV_TDS.1 Базовый проект.
11.1.4.1. Элементы действий разработчика
11.1.4.1.1. ADV_ARC.1.1D
Разработчик должен спроектировать ОО и обеспечить реализацию проекта таким образом, чтобы свойства безопасности ФБО невозможно было обойти.
11.1.4.1.2. ADV_ARC.1.2D
Разработчик должен спроектировать ФБО и обеспечить их реализацию таким образом, чтобы ФБО обеспечивали собственную защиту от вмешательства недоверенных сущностей.
11.1.4.1.3. ADV_ARC.1.3D
Разработчик должен предоставить "Описание архитектуры безопасности" ФБО.
11.1.4.2. Элементы содержания и представления свидетельств
11.1.4.2.1. ADV_ARC.1.1C
Уровень детализации "Описания архитектуры безопасности" должен соответствовать представленному в проектной документации по ОО описанию абстракций (элементов представления ОО), осуществляющих выполнение ФТБ.
11.1.4.2.2. ADV_ARC.1.2C
В "Описание архитектуры безопасности" должно быть включено описание доменов безопасности, обеспеченных согласованностью ФБО с ФТБ.
11.1.4.2.3. ADV_ARC.1.3C
"Описание архитектуры безопасности" должно предоставлять информацию о том, насколько процесс инициализации ФБО является защищенным.
11.1.4.2.4. ADV_ARC.1.4C
В "Описании архитектуры безопасности" должно быть продемонстрировано, что ФБО обеспечивают собственную защиту от вмешательства.
11.1.4.2.5. ADV_ARC.1.5C
В "Описании архитектуры безопасности" должно быть продемонстрировано, что ФБО не допускают возможности обхода функциональных возможностей, осуществляющих выполнение ФТБ.
11.1.4.3. Элементы действий оценщика
11.1.4.3.1. ADV_ARC.1.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
11.2. Функциональная спецификация (ADV_FSP)
11.2.1. Цели
В настоящем семействе предъявляются требования к функциональной спецификации, в которой описываются интерфейсы ФБО (ИФБО). ИФБО включают в себя все способы, которыми пользователи могут вызвать тот или иной сервис ФБО (путем предоставления информации, которая обрабатывается ФБО) и соответствующую реакцию на запросы на обслуживание. Однако в функциональной спецификации не описывается, каким образом ФБО обрабатывает эти запросы или как организована связь при запросе ФБО обслуживания из среды функционирования; эта информация представлена в семействах "Проект ОО" (ADV_TDS) и "Доверие к зависимым компонентам" (ACO_REL) соответственно.
Данное семейство обеспечивает получение доверия непосредственно путем предоставления оценщику возможности понять, как ФБО выполняют заявленные ФТБ. Кроме того, оно обеспечивает и получение доверия косвенным образом, предоставляя исходную информацию для других классов и семейств доверия:
для семейства ADV_ARC "Архитектура безопасности", в котором описание ИФБО может быть использовано для получения лучшего понимания того, каким образом ФБО защищены от искажения (например, от нарушения свойств обеспечения собственной защиты и разделения доменов) и/или обхода;
для класса ATE "Тестирование", в котором описание ИФБО предоставляет важную исходную информацию для проведения тестовых испытаний как разработчиком, так и оценщиком;
для класса AVA "Анализ уязвимостей", в котором описание ИФБО используется в процессе поиска уязвимостей.
11.2.2. Ранжирование компонентов
Компоненты настоящего семейства ранжированы в зависимости от степени формализации и детализации, требуемых для описания интерфейсов ФБО.
11.2.3. Замечания по применению
После определения ИФБО (см. приложение A.2.1, "Руководства и примеры по определению ИФБО") они описываются. Для компонентов более низкого уровня разработчики составляют документацию (а оценщики проводят оценку этой документации), направленную на описание тех аспектов ОО, которые имеют большее значение для безопасности. Определяются три категории ИФБО в зависимости от степени значимости тех сервисов, к которым эти интерфейсы предоставляют доступ для заявленных ФТБ:
если сервис, доступ к которому предоставляется интерфейсом, может быть сопоставлен с одним из ФТБ, предъявляемым к ФБО, тогда данный интерфейс относится к категории осуществляющих выполнение ФТБ. Следует отметить, что один интерфейс может обеспечивать доступ к нескольким различным сервисам и предоставлять различные результаты, некоторые из которых могут осуществлять выполнение ФТБ, а другие нет;
интерфейсы сервисов (или сервисы, доступные при обращении к связанным с ними интерфейсам), от которых зависят функциональные возможности, осуществляющие выполнение ФТБ, но при этом от них для осуществления политики безопасности ОО требуется только правильное функционирование, относятся к категории поддерживающих выполнение ФТБ;
интерфейсы сервисов, от которых никак не зависят функциональные возможности, осуществляющие выполнение ФТБ, относятся к не влияющим на выполнение ФТБ.
Следует отметить, что для того, чтобы интерфейс был отнесен к поддерживающим или не влияющим на выполнение ФТБ, он не должен включать в себя сервисы и результаты, осуществляющие выполнение ФТБ. Напротив, осуществляющий выполнение ФТБ интерфейс может включать поддерживающие выполнение ФТБ сервисы (например, возможность выставить время в системе может выполняться сервисом интерфейса, осуществляющего выполнение ФТБ, но если этот же интерфейс используется для отображения даты в системе, то этот сервис может быть исключительно поддерживающим выполнение ФТБ). В качестве яркого примера "исключительно поддерживающего выполнение ФТБ интерфейса" можно привести интерфейс системных вызовов, который используется как пользователями, так и частью ФБО, запускаемых от имени пользователей.
Чем больший объем информации предоставляется о ИФБО, тем больше приобретаемое доверие к тому, что данные интерфейсы правильно категорированы и проанализированы. Требования структурированы таким образом, что на самом низком уровне для описания интерфейсов, не влияющих на выполнение ФТБ, требуется только минимально необходимый объем информации для того, чтобы оценщик мог сделать заключение эффективным образом. Чем выше требуемый уровень доверия, тем больший объем информации предоставляется оценщику для того, чтобы у него было больше уверенности в проектировании.
Цель в определении этих категорий ("осуществляющие ФТБ", "поддерживающие ФТБ" и "не влияющие на выполнение ФТБ") и предъявлении к каждой из них различных требований (для компонентов более низкого уровня) состоит в том, чтобы предоставить в первом приближении представление о том, на что должен быть направлен анализ, и о свидетельствах, на основании которых проводится данный анализ. Если в документации, представленной разработчиком по интерфейсам ФБО, все интерфейсы описаны на уровне детализации, определенной в требованиях, предъявляемых к интерфейсам, осуществляющим выполнение ФТБ (т.е. в случае, когда документация усиливает требования), разработчику не требуется создавать отдельное свидетельство для соответствия этим требованиям. Аналогично, так как разделение интерфейсов по категориям нужно только для того, чтобы распределить виды интерфейсов по строгости предъявляемым к их описаниям требованиям, от разработчика не требуется вносить изменения в свидетельства только для того, чтобы классифицировать имеющиеся интерфейсы по описанным выше категориям. Основная цель такого разделения заключается в том, чтобы позволить разработчикам с менее развитой методологией разработки (что приводит к появлению таких недостатков, как излишне детализированная документация по проекту и интерфейсам) предоставлять только необходимые свидетельства без лишних затрат.
В последнем элементе группы ".C" ("Элементы содержания и представления свидетельств") каждого компонента семейства представлено прямое соответствие между ФТБ и функциональной спецификацией; в нем отражается, какие интерфейсы используются для выполнения каждого требуемого ФТБ. В случаях, когда в ЗБ содержатся такие функциональные требования, как представленные в ИСО/МЭК 15408-2 в компоненте "Защита остаточной информации" (FDP_RIP), функциональные возможности которых не могут проявлять себя в ИФБО, эти ФТБ должны быть определены в функциональной спецификации и/или прослеживании; включение их в функциональную спецификацию поможет обеспечить уверенность в том, что они не будут упущены из виду на более низких уровнях декомпозиции, где они будут иметь важное значение для безопасности.
11.2.3.1. Детализация интерфейсов
Предъявляются определенные требования к тому, с какой детализацией следует представлять информацию об ИФБО. Согласно этим требованиям интерфейсы специфицируются (на разных уровнях детализации) в терминах назначения интерфейса, метода использования, параметров, описаний параметров и сообщений об ошибках.
Назначение интерфейса включает в себя высокоуровневое описание основной цели интерфейса (например, обработка команд графического интерфейса пользователя, получение сетевых пакетов, обеспечение вывода на печать и т.п.).
Метод использования интерфейса описывает предполагаемый метод использования конкретного интерфейса. Такое описание рекомендуется основывать на различных взаимодействиях, которые доступны для данного интерфейса. Например, если в качестве интерфейса используется командный процессор оболочки ОС Unix, то взаимодействиями данного интерфейса будут являться команды "ls" (просмотр списка файлов), "mv" (перемещение файлов) и "cp" (копирование файлов). Метод использования для каждого взаимодействия описывает функциональные возможности данного взаимодействия (что именно оно делает), реакцию интерфейса на определенные действия (например, вызов программистом интерфейса прикладных программ, изменение пользователем операционной системы Windows настроек реестра и т.п.), а также влияние этой реакции на другие интерфейсы (например, создание записи в журнале аудита).
Параметры - это подробные исходные данные и данные на выходе интерфейса, которые управляют режимом работы интерфейса. Например, параметрами являются аргументы (независимые переменные), поставляемые интерфейсу прикладных программ; различные поля в пакетах данного сетевого протокола; индивидуальные значения ключей в реестре ОС Windows; сигналы на контактах микросхемы; параметры, которые можно присвоить команде ls и т.д. Параметры "идентифицируются" путем предоставления простого списка того, что они из себя представляют.
Описание параметра предоставляет содержательную информацию о параметре. Например, приемлемое описание параметра интерфейса foo(i) - "параметр i является целым числом, которое отражает число пользователей, вошедших в систему в настоящий момент". Описание вида "параметр i является целым числом" является неприемлемым.
Описание действий интерфейса включает в себя представление функциональных возможностей данного интерфейса (что он делает). Это описание должно быть более детализованным, чем описание назначения интерфейса, т.к. в назначении прописывается только то, для чего может потребоваться использовать данный интерфейс, а в "действиях" отражаются все выполняемые интерфейсом функции. Такие действия могут быть как относящимися к ФТБ, так и не относящимися к ним. В тех случаях, когда действия интерфейса не относятся к ФТБ, приводится их краткое описание, которое только подтверждает факт того, что действия не относятся к ФТБ.
Описание сообщений об ошибках включает в себя описание состояния, вызвавшего сообщение об ошибке, содержание сообщения и значение любых кодовых обозначений ошибок. Сообщение об ошибке генерируется ФБО для извещения о возникновении некой проблемы или нестабильности работы. Требования данного семейства предъявляются к различным видам сообщений об ошибках:
сообщение о "непосредственных" ошибках - это имеющая отношение к безопасности реакция, возникающая при вызове особого ИФБО;
"косвенную" ошибку нельзя связать с вызовом конкретного ИФБО, поскольку возникает такая ошибка из-за некоторого состояния всей системы в целом (например, из-за нехватки ресурсов, нарушения взаимодействий и т.п.). Также к косвенным ошибкам относятся все ошибки, не имеющие отношения к безопасности;
к "прочим" ошибкам относятся любые другие ошибки, которые могут встретиться в коде программы. Например, использование фрагмента кода проверки условий, который проверяет наличие логически невозможных условий (например, заключительный "else" после списка операторов "case"), обеспечивается для генерации обобщенного сообщения обо всех ошибках такого рода, присутствующих в коде; не следует, чтобы в функционирующем ОО такие сообщения об ошибках были видны пользователю.
Пример функциональной спецификации приведен в приложении A.2.3.
11.2.3.2. Компоненты данного семейства
Увеличение доверия путем увеличения полноты и точности спецификации интерфейсов отражается в документации, требуемой от разработчика, как детально описывается в иерархических компонентах данного семейства.
В компоненте ADV_FSP.1 "Базовая функциональная спецификация" единственной требуемой документацией является определение параметров всех ИФБО и высокоуровневое описание интерфейсов, осуществляющих и поддерживающих выполнение ФТБ. Для обеспечения некоторого доверия тому, что "важные" аспекты ФБО верно характеризуют все ИФБО, от разработчика требуется представить информацию о назначении и методе использования, а также о параметрах поддерживающих и осуществляющих выполнение ФТБ интерфейсов.
В компоненте ADV_FSR.2 "Детализация вопросов безопасности в функциональной спецификации" от разработчика требуется представить информацию о назначении и методах использования, а также параметры и описание параметров для всех ИФБО. Кроме того, для ИФБО, обеспечивающих безопасность, разработчик обязан описать обеспечивающие безопасность действия и сообщения о непосредственных ошибках.
В компоненте ADV_FSR.3 "Функциональная спецификация с полной аннотацией" разработчик должен, в дополнение к информации, требуемой компонентом ADV_FSP.2, предоставить в достаточном объеме информацию о действиях, поддерживающих выполнение ФТБ или не влияющих на их выполнение для того, чтобы продемонстрировать, что эти действия не являются осуществляющими выполнение ФТБ. Кроме того, разработчик должен задокументировать все сообщения о непосредственных ошибках, возникающих в результате вызова ИФБО, осуществляющих выполнение ФТБ.
В компоненте ADV_FSP.4 "Полная функциональная спецификация" описания всех ИФБО - осуществляющих, поддерживающих, не влияющих на выполнение ФТБ - должны быть представлены в равной степени детализации, включая сообщения обо всех непосредственных ошибках.
В компоненте ADV_FSP.5 "Полная полуформальная функциональная спецификация с дополнительной информацией об ошибках" в описания ИФБО также включается информация об ошибках, возникающих не в результате вызова ИФБО.
В компоненте ADV_FSP.6 "Полная полуформальная функциональная спецификация с дополнительной формальной спецификацией" в описания, помимо информации, требуемой компонентом ADV_FSP.5, включаются все остальные сообщения об ошибках. Кроме того, разработчик должен дополнительно предоставить формальное описание ИФБО. Таким образом обеспечивается альтернативное представление ИФБО, которое может помочь выявить несоответствия или неполноту спецификации.
11.2.4. ADV_FSP.1 Базовая функциональная спецификация
Зависимости: отсутствуют.
11.2.4.1. Элементы действий разработчика
11.2.4.1.1. ADV_FSP.1.1D
Разработчик должен представить функциональную спецификацию.
11.2.4.1.2. ADV_FSP.1.2D
Разработчик должен представить прослеживание функциональной спецификации к ФТБ.
11.2.4.2. Элементы содержания и представления свидетельств
11.2.4.2.1. ADV_FSP.1.1C
В функциональной спецификации должны описываться назначение и метод использования для каждого из ИФБО, осуществляющих или поддерживающих выполнение ФТБ.
11.2.4.2.2. ADV_FSP.1.2C
В функциональной спецификации должны быть идентифицированы все параметры, связанные с каждым ИФБО, осуществляющим или поддерживающим ФТБ.
11.2.4.3. ADV_FSP.1.3C
В функциональной спецификации должно приводиться обоснование неявного категорирования интерфейсов как не влияющих на выполнение ФТБ.
11.2.4.3.1. ADV_FSP.1.4C
В прослеживании соответствия должно быть продемонстрировано прослеживание ФТБ к ИФБО в функциональной спецификации.
11.2.4.4. Элементы действий оценщика
11.2.4.4.1. ADV_FSP.1.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
11.2.4.4.2. ADV_FSP.1.2E
Оценщик должен сделать независимое заключение, что функциональная спецификация является точным и полным отображением функциональных требований безопасности ОО.
11.2.5. ADV_FSP.2 Детализация вопросов безопасности в функциональной спецификации
Зависимости: ADV_TDS.1 Базовый проект.
11.2.5.1. Элементы действий разработчика
11.2.5.1.1. ADV_FSP.2.1D
Разработчик должен представить функциональную спецификацию.
11.2.5.1.2. ADV_FSP.2.2D
Разработчик должен представить прослеживание функциональной спецификации к функциональным требованиям безопасности.
11.2.5.2. Элементы содержания и представления свидетельств
11.2.5.2.1. ADV_FSP.2.1C
В функциональной спецификации должны быть полностью представлены ФБО.
11.2.5.2.2. ADV_FSP.2.2C
В функциональной спецификации должны быть описаны назначение и метод использования всех ИФБО.
11.2.5.2.3. ADV_FSP.2.3C
В функциональной спецификации должны быть идентифицированы и описаны все параметры, связанные с каждым ИФБО.
11.2.5.2.4. ADV_FSP.2.4C
Для каждого ИФБО, осуществляющего выполнение ФТБ, функциональная спецификация должна содержать описание связанных с данным ИФБО действий, осуществляющих выполнение ФТБ.
11.2.5.2.5. ADV_FSP.2.5C
Для ИФБО, осуществляющих выполнение ФТБ, функциональная спецификация должна содержать описание сообщений о непосредственных ошибках, возникающих в результате функционирования, связанного с действиями, осуществляющими выполнение ФТБ.
11.2.5.2.6. ADV_FSP.2.6C
В прослеживании соответствия должно быть продемонстрировано прослеживание ФТБ к ИФБО в функциональной спецификации.
11.2.5.3. Элементы действий оценщика
11.2.5.3.1. ADV_FSP.2.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
11.2.5.3.2. ADV_FSP.2.2E
Оценщик должен сделать независимое заключение, что функциональная спецификация является точным и полным отображением функциональных требований безопасности ОО.
11.2.6. ADV_FSP.3 Функциональная спецификация с полной аннотацией
Зависимости: ADV_TDS.1 Базовый проект.
11.2.6.1. Элементы действий разработчика
11.2.6.1.1. ADV_FSP.3.1D
Разработчик должен представить функциональную спецификацию.
11.2.6.1.2. ADV_FSP.3.2D
Разработчик должен представить прослеживание функциональной спецификации к функциональным требованиям безопасности.
11.2.6.2. Элементы содержания и представления свидетельств
11.2.6.2.1. ADV_FSP.3.1C
В функциональной спецификации должны быть полностью представлены ФБО.
11.2.6.2.2. ADV_FSP.3.2C
В функциональной спецификации должны быть описаны назначение и метод использования всех ИФБО.
11.2.6.2.3. ADV_FSP.3.3C
В функциональной спецификации должны быть идентифицированы и описаны все параметры, связанные с каждым ИФБО.
11.2.6.2.4. ADV_FSP.3.4C
Для каждого ИФБО, осуществляющего выполнение ФТБ, функциональная спецификация должна содержать описание связанных с данным ИФБО действий, осуществляющих выполнение ФТБ.
11.2.6.2.5. ADV_FSP.3.5C
Для каждого ИФБО, осуществляющего выполнение ФТБ, функциональная спецификация должна содержать описание сообщений о непосредственных ошибках, возникающих в результате влияющих на безопасность эффектов и нештатных ситуаций, связанных с вызовом данного ИФБО.
11.2.6.2.6. ADV_FSP.3.6C
В функциональной спецификации должны быть приведены все связанные с каждым ИФБО действия, поддерживающие или не влияющие на выполнение ФТБ.
11.2.6.2.7. ADV_FSP.3.7C
В прослеживании соответствия должно быть продемонстрировано прослеживание ФТБ к ИФБО в функциональной спецификации.
11.2.6.3. Элементы действий оценщика
11.2.6.3.1. ADV_FSP.3.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
11.2.6.3.2. ADV_FSP.3.2E
Оценщик должен сделать независимое заключение, что функциональная спецификация является точным и полным отображением функциональных требований безопасности ОО.
11.2.7. ADV_FSP.4 Полная функциональная спецификация
Зависимости: ADV_TDS.1 Базовый проект.
11.2.7.1. Элементы действий разработчика
11.2.7.1.1. ADV_FSP.4.1D
Разработчик должен представить функциональную спецификацию.
11.2.7.1.2. ADV_FSP.4.2D
Разработчик должен представить прослеживание функциональной спецификации к функциональным требованиям безопасности.
11.2.7.2. Элементы содержания и представления свидетельств
11.2.7.2.1. ADV_FSP.4.1C
В функциональной спецификации должны быть полностью представлены ФБО.
11.2.7.2.2. ADV_FSP.4.2C
В функциональной спецификации должны быть описаны назначение и метод использования всех ИФБО.
11.2.7.2.3. ADV_FSP.4.3C
В функциональной спецификации должны быть идентифицированы и описаны все параметры, связанные с каждым ИФБО.
11.2.7.2.4. ADV_FSP.4.4C
В функциональной спецификации должны быть описаны все действия, связанные с каждым ИФБО.
11.2.7.2.5. ADV_FSP.4.5C
Функциональная спецификация должна содержать описание сообщений обо всех непосредственных ошибках, которые могут возникнуть при вызове каждого ИФБО.
11.2.7.2.6. ADV_FSP.4.6C
В прослеживании соответствия должно быть продемонстрировано прослеживание ФТБ к ИФБО в функциональной спецификации.
11.2.7.3. Элементы действий оценщика
11.2.7.3.1. ADV_FSP.4.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
11.2.7.3.2. ADV_FSP.4.2E
Оценщик должен сделать независимое заключение, что функциональная спецификация является точным и полным отображением функциональных требований безопасности ОО.
11.2.8. ADV_FSP.5 Полная полуформальная функциональная спецификация с дополнительной информацией об ошибках
Зависимости: ADV_TDS.1 Базовый проект
ADV_IMP.1 Представление реализации ФБО.
11.2.8.1. Элементы действий разработчика
11.2.8.1.1. ADV_FSP.5.1D
Разработчик должен представить функциональную спецификацию.
11.2.8.1.2. ADV_FSP.5.2D
Разработчик должен представить прослеживание функциональной спецификации к функциональным требованиям безопасности.
11.2.8.2. Элементы содержания и представления свидетельств
11.2.8.2.1. ADV_FSP.5.1C
В функциональной спецификации должны быть полностью представлены ФБО.
11.2.8.2.2. ADV_FSP.5.2C
Функциональная спецификация должна содержать полуформальное описание ИФБО.
11.2.8.2.3. ADV_FSP.5.3C
В функциональной спецификации должны быть описаны назначение и метод использования всех ИФБО.
11.2.8.2.4. ADV_FSP.5.4C
В функциональной спецификации должны быть идентифицированы и описаны все параметры, связанные с каждым ИФБО.
11.2.8.2.5. ADV_FSP.5.5C
В функциональной спецификации должны быть описаны все действия, связанные с каждым ИФБО.
11.2.8.2.6. ADV_FSP.5.6C
Функциональная спецификация должна содержать описание сообщений обо всех непосредственных ошибках, которые могут возникнуть при вызове каждого ИФБО.
11.2.8.2.7. ADV_FSP.5.7C
Функциональная спецификация должна содержать описание всех сообщений об ошибках, возникающих не в результате вызова ИФБО.
11.2.8.2.8. ADV_FSP.5.8C
Функциональная спецификация должна содержать обоснование каждого сообщения об ошибке, содержащегося в реализации ФБО, но не являющегося результатом вызова ИФБО.
11.2.8.2.9. ADV_FSP.5.9C
В прослеживании соответствия должно быть продемонстрировано прослеживание ФТБ к ИФБО в функциональной спецификации.
11.2.8.3. Элементы действий оценщика
11.2.8.3.1. ADV_FSP.5.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
11.2.8.3.2. ADV_FSP.5.2E
Оценщик должен сделать независимое заключение, что функциональная спецификация является точным и полным отображением функциональных требований безопасности ОО.
11.2.9. ADV_FSP.6 Полная полуформальная функциональная спецификация с дополнительной формальной спецификацией
Зависимости: ADV_TDS.1 Базовый проект
ADV_IMP.1 Представление реализации ФБО.
11.2.9.1. Элементы действий разработчика
11.2.9.1.1. ADV_FSP.6.1D
Разработчик должен представить функциональную спецификацию.
11.2.9.1.2. ADV_FSP.6.2D
Разработчик должен представить формальное представление функциональной спецификации ФБО.
11.2.9.1.3. ADV_FSP.6.3D
Разработчик должен представить прослеживание функциональной спецификации к функциональным требованиям безопасности.
11.2.9.2. Элементы содержания и представления свидетельств
11.2.9.2.1. ADV_FSP.6.1C
В функциональной спецификации должны быть полностью представлены ФБО.
11.2.9.2.2. ADV_FSP.6.2C
Функциональная спецификация должна содержать формальное описание ИФБО.
11.2.9.2.3. ADV_FSP.6.3C
В функциональной спецификации должны быть описаны назначение и метод использования всех ИФБО.
11.2.9.2.4. ADV_FSP.6.4C
В функциональной спецификации должны быть идентифицированы и описаны все параметры, связанные с каждым ИФБО.
11.2.9.2.5. ADV_FSP.6.5C
В функциональной спецификации должны быть описаны все действия, связанные с каждым ИФБО.
11.2.9.2.6. ADV_FSP.6.6C
Функциональная спецификация должна содержать описание сообщений обо всех непосредственных ошибках, которые могут возникнуть при вызове каждого ИФБО.
11.2.9.2.7. ADV_FSP.6.7C
Функциональная спецификация должна содержать описание всех сообщений об ошибках, содержащихся в представлении реализации ФБО.
11.2.9.2.8. ADV_FSP.6.8C
Функциональная спецификация должна содержать обоснование каждого сообщения об ошибках, содержащегося в реализации ФБО, но при этом не описанного в функциональной спецификации, и того, почему эти сообщения об ошибках не связаны с ИФБО.
11.2.9.2.9. ADV_FSP.6.9C
В формальном представлении функциональной спецификации ФБО должно быть изложено формальное описание ИФБО, дополненное, где это необходимо, неформальным пояснительным текстом.
11.2.9.2.10. ADV_FSP.6.10C
В прослеживании соответствия должно быть продемонстрировано прослеживание ФТБ к ИФБО в функциональной спецификации.
11.2.9.3. Элементы действий оценщика
11.2.9.3.1. ADV_FSP.6.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
11.2.9.3.2. ADV_FSP.6.2E
Оценщик должен сделать независимое заключение, что функциональная спецификация является точным и полным отображением функциональных требований безопасности ОО.
11.3. Представление реализации (ADV_IMP)
11.3.1. Цели
Семейство "Представление реализации" (ADV_IMP) предназначено для того, чтобы разработчик сделал доступным представление реализации (а на более высоких уровнях - саму реализацию) ОО в форме, которая может быть проанализирована оценщиком. Представление реализации используется при проведении действий по анализу и в рамках других семейств (например, при анализе проекта ОО) для того, чтобы продемонстрировать, что ОО соответствует своему проекту, а также для создания основы для проведения исследований по другим областям оценки (например, для поиска уязвимостей). Ожидается, что представление реализации будет выполнено в такой форме, чтобы в нем были зафиксированы процессы внутреннего содержания ФБО в виде исходного текста программ, микропрограмм, схем аппаратных средств и/или программного кода модели интегральных схем или размещения данных.
11.3.2. Ранжирование компонентов
Компоненты в этом семействе ранжированы в зависимости от полноты реализации, которая прослеживается к описанию проекта ОО.
11.3.3. Замечания по применению
Примерами частей представления реализации являются: исходный текст программы или схема аппаратного средства и/или программный код модели интегральных схем или размещения данных, которые используются для построения действующего оборудования. Важно отметить, что хотя представление реализации должно быть доступно оценщику, это не подразумевает, что нужно иметь его у себя. Например, разработчик может потребовать от оценщика составить аннотацию на представление реализации на месте, указанном разработчиком.
Доступ ко всему представлению реализации предоставляется для того, чтобы обеспечить уверенность в том, что действия по анализу не будут сокращены вследствие недостаточности информации. Однако это не подразумевает, что при проведении действий по анализу исследуется все представление. Такой подход в большинстве случаев нецелесообразен; кроме того, он не предоставляет более высокого уровня доверия для ОО по сравнению с целенаправленной выборкой представления реализации. Представление реализации позволяет провести анализ других элементов декомпозиции проекта ОО (например, функциональной спецификации, проекта ОО) и получить уверенность в том, что функциональные возможности безопасности, описанные на более высоком уровне проекта, фактически реализованы в ОО. Некоторые условности в представлении реализации могут значительно усложнить или сделать невозможным определение по одному только представлению реализации того, каким будет фактический результат компиляции или процесса реализации. Например, согласно указателям для компиляторов на языке программирования Си, компиляторы включают в код или исключают из него целые участки. Поэтому для точного определения представления реализации важно, чтобы была предоставлена эта "дополнительная" информация или описание связанных с нею средств (скриптов, компиляторов и т.д.).
Прослеживание между представлением реализации и описанием проекта ОО служит для того, чтобы помочь оценщику провести анализ. В случае если проект ОО подвергается анализу вместе с соответствующими частями представления реализации, может быть достигнуто лучшее понимание внутреннего содержания ОО. Отображение представления реализации в описании проекта ОО служит в качестве указателя на представление реализации. Для компонентов низкого уровня в описании проекта ОО отображается только некое подмножество представления реализации. Из-за того, что точно неизвестно, какие части представления реализации необходимо будет отобразить в проекте ОО, разработчик может либо принять решение об отображении всего представления реализации заранее, либо подождать, пока оценщик определит, какие части представления реализации требуется отобразить.
Представление реализации выполняется разработчиком таким образом, чтобы была возможность преобразовать это представление в фактическую реализацию. Например, разработчик может работать с файлами, содержащими исходный текст программ, который потом будет скомпилирован и станет частью ФБО. Разработчик делает доступным представление реализации в том виде, в котором он его использует, благодаря чему оценщик может применять автоматизированные методы анализа. Это также повышает уверенность в том, что оцениваемое представление реализации является именно тем, которое используется при производстве ФБО (в отличие от того случая, когда оно сопровождается альтернативным форматом представления, например документом текстового процессора). Следует отметить, что разработчик может использовать различные другие формы представления реализации; они также должны прилагаться. Основная цель состоит в том, чтобы снабдить оценщика такой информацией, которая позволила бы максимизировать эффективность его усилий по анализу.
Для некоторых форм представления реализации требуется дополнительная информация, поскольку их довольно сложно понять и проанализировать. В качестве примера можно привести "скрытый" или каким-либо образом запутанный фрагмент исходного кода программы, который сложно понять и/или проанализировать. Подобные формы представления реализации чаще всего возникают, когда разработчик ОО применяет к некоторой версии представления реализации некие программы по сокрытию или запутыванию кода. В то время как представление со скрытыми участками кода является именно тем, которое будет в дальнейшем подвергнуто компиляции, а потому может быть даже ближе к реализации (по структуре), чем оригинальная версия, предоставление оценщику запутанного программного кода может привести к тому, что анализ рисков, связанных с данным представлением реализации, потребует значительно больше времени. При создании подобных форм представления в компонентах данного семейства должны быть детализированы примененные средства/алгоритмы сокрытия, что позволит снабдить оценщика представлением до применения сокрытия участков кода, а дополнительная информация может быть использована для получения уверенности в том, что процесс сокрытия участков кода не нарушил выполнения каких-либо функциональных возможностей безопасности.
11.3.4. ADV_IMP.1 Представление реализации ФБО
Зависимости: ADV_TDS.3 Базовый модульный проект
ALC_TAT.1 Полностью определенные инструментальные средства разработки.
11.3.4.1. Элементы действий разработчика
11.3.4.1.1. ADV_IMP.1.1D
Разработчик должен обеспечить представление реализации для всех ФБО.
11.3.4.1.2. ADV_IMP.1.2D
Разработчик должен обеспечить прослеживание выборки представления реализации к описанию проекта ОО.
11.3.4.2. Элементы содержания и представления свидетельств
11.3.4.2.1. ADV_IMP.1.1C
Представление реализации должно определить ФБО на таком уровне детализации, что ФБО могут быть созданы без дополнительных проектных решений.
11.3.4.2.2. ADV_IMP.1.2C
Представление реализации должно быть изложено в том виде, какой используется персоналом, занимающимся разработкой.
11.3.4.2.3. ADV_IMP.1.3C
В прослеживании между выборкой представления реализации и описанием проекта ОО должно быть продемонстрировано их соответствие.
11.3.4.3. Элементы действий оценщика
11.3.4.3.1. ADV_IMP.1.1E
Оценщик должен подтвердить, что для выборки представления реализации представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
11.3.5. ADV_IMP.2 Полное отображение представления реализации ФБО
Зависимости: ADV_TDS.3 Базовый модульный проект
ALC_TAT.1 Полностью определенные инструментальные средства разработки
ALC_CMC.5 Расширенная поддержка.
11.3.5.1. Элементы действий разработчика
11.3.5.1.1. ADV_IMP.2.1D
Разработчик должен обеспечить оценщику доступ к представлению реализации для всех ФБО.
11.3.5.1.2. ADV_IMP.2.2D
Разработчик должен обеспечить прослеживание всего представления реализации к описанию проекта ОО.
11.3.5.2. Элементы содержания и представления свидетельств
11.3.5.2.1. ADV_IMP.2.1C
Представление реализации должно определить ФБО на таком уровне детализации, что ФБО могут быть созданы без дополнительных проектных решений.
11.3.5.2.2. ADV_IMP.2.2C
Представление реализации должно быть изложено в том виде, какой используется персоналом, занимающимся разработкой.
11.3.5.2.3. ADV_IMP.2.3C
В прослеживании между всем представлением реализации и описанием проекта ОО должно быть продемонстрировано их соответствие.
11.3.5.3. Элементы действий оценщика
11.3.5.3.1. ADV_IMP.2.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
11.4. Внутренняя структура ФБО (ADV_INT)
11.4.1. Цели
Это семейство связано с оценкой внутренней структуры ФБО. ФБО с полностью определенной внутренней структурой легче реализовать, при этом меньше вероятность того, что они будут содержать недостатки, которые в дальнейшем могут привести к уязвимостям. Кроме того, их легче сопровождать без внедрения при этом недостатков.
11.4.2. Ранжирование компонентов
Компоненты этого семейства ранжированы на основе требуемой степени структурированности и минимизации сложности. Компонент ADV_INT.1 "Подмножество ФБО с полностью определенной внутренней структурой" предъявляет требования полностью определенной внутренней структуры только для некоторой выборки ФБО. Данный компонент не включается в ОУД потому, что предназначен для использования в определенных обстоятельствах (например, если заявитель особо заинтересован в реализации криптографического модуля, который изолирован от остальной части ФБО), а следовательно, невозможно его широкое применение.
На следующем уровне требования полностью определенной внутренней структуры предъявляются ко всем ФБО. И наконец, требование по минимизации сложности вводится в компонент высшего уровня.
11.4.3. Замечания по применению
Приведенные требования при применении к внутренней структуре ФБО обычно приводят к улучшениям, которые помогают и разработчику, и оценщику в понимании ФБО, а также предоставляют основу для проектирования и проведения оценки подмножества тестов. Кроме того, следует, чтобы улучшение понимания ФБО помогло разработчику упростить их сопровождение.
Требования данного семейства представляются в довольно абстрактном виде. Из-за большого разнообразия различных ОО не представляется возможным определить более точные термины, чем выражения "с полностью определенной структурой" или "минимизация сложности". Заключения о структуре и сложности выносятся на основании особых технологий, используемых в ОО. Например, программное обеспечение скорее всего будет характеризовано как имеющее полностью определенную структуру в случае, если в нем будут представлены качества и характеристики, установленные для программного обеспечения техническими дисциплинами и их стандартами. Компоненты данного семейства требуют идентификации стандартов, согласно которым будут оцениваться качества, характеризующие полноту определения и отсутствие избыточной сложности.
11.4.4. ADV_INT.1 Подмножество ФБО с полностью определенной внутренней структурой
Зависимости: ADV_IMP.1 Представление реализации ФБО
ADV_TDS.3 Базовый модульный проект
ALC_TAT.1 Полностью определенные инструментальные средства разработки.
11.4.4.1. Цели
Цель данного компонента состоит в предоставлении возможности предъявления требований к тому, чтобы некоторые части ФБО имели полностью определенную внутреннюю структуру. Компонент предназначен для того, чтобы все ФБО были спроектированы и реализованы с использованием правильных технических принципов, а анализ выполнялся только в отношении некоторого конкретного подмножества ФБО.
11.4.4.2. Замечания по применению
В данном компоненте предъявляются требования к разработчику ПЗ или ЗБ по предоставлению информации о назначении подмножества ФБО. Это подмножество может быть определено на любом уровне представления:
a) на уровне структурных элементов ФБО, как определено в проекте ОО (например: "Разработчик должен спроектировать и реализовать подсистему аудита с полностью определенной внутренней структурой");
b) на уровне реализации (например: "Разработчик должен спроектировать и реализовать файлы encrypt.c и decrypt.c таким образом, чтобы они имели полностью определенную внутреннюю структуру" или "Разработчик должен спроектировать и реализовать интегральную микросхему 6227 так, чтобы у нее имелась полностью определенная внутренняя структура").
Выполнить это путем ссылки на заявленные ФТБ не представляется возможным (например, в виде: "Разработчик должен спроектировать и реализовать ту часть ФБО, которая обеспечивает выполнение требования к анонимности согласно компоненту FPR_ANO.2 таким образом, чтобы эта часть обладала полностью определенной внутренней структурой"), поскольку такое представление не отражает, на что именно должен быть направлен анализ.
Ценность данного компонента ограничена, компонент применим в тех случаях, когда потенциально опасные пользователи/субъекты имеют ограниченный или строго контролируемый доступ к ИФБО или тогда, когда есть другие средства защиты (например, разделение доменов), которые обеспечивают, что на выбранное подмножество ФБО не могут неблагоприятно повлиять остальные ФБО (например, когда криптографические функции, которые изолированы от остальных ФБО, имеют полностью определенную внутреннюю структуру).
11.4.4.3. Элементы действий разработчика
11.4.4.3.1. ADV_INT.1.1D
Разработчик должен выполнить проектирование и реализацию [назначение: подмножество ФБО] таким образом, чтобы внутренняя структура была полностью определенной.
11.4.4.3.2. ADV_INT.1.2D
Разработчик должен представить описание и логическое обоснование внутренней структуры.
11.4.4.4. Элементы содержания и представления свидетельств
11.4.4.4.1. ADV_INT.1.1C
В логическом обосновании должно приводиться объяснение того, на основании каких характеристик оценивается "полнота определения" внутренней структуры.
11.4.4.4.2. ADV_INT.1.2C
В описании внутренней структуры ФБО должно быть продемонстрировано, что внутренняя структура заданного подмножества ФБО является полностью определенной.
11.4.4.5. Элементы действий оценщика
11.4.4.5.1. ADV_INT.1.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
11.4.5. ADV_INT.2 Полностью определенная внутренняя структура
Зависимости: ADV_IMP.1 Представление реализации ФБО
ADV_TDS.3 Базовый модульный проект
ALC_TAT.1 Полностью определенные инструментальные средства разработки.
11.4.5.1. Цели
Цель данного компонента состоит в предоставлении возможности предъявления к ФБО требований по полностью определенной внутренней структуре. Компонент предназначен для того, чтобы ФБО были спроектированы и реализованы с использованием правильных технических принципов.
11.4.5.2. Замечания по применению
Заключение о соответствии структуры требованиям принимается на основании изучения конкретных технологий, используемых в ОО. Этот компонент требует идентификации стандартов, согласно которым будут оцениваться качества, характеризующие полноту определения структуры.
11.4.5.3. Элементы действий разработчика
11.4.5.3.1. ADV_INT.2.1D
Разработчик должен выполнить проектирование и реализацию всех ФБО таким образом, чтобы их внутренняя структура была полностью определена.
11.4.5.3.2. ADV_INT.2.2D
Разработчик должен представить описание и логическое обоснование внутренней структуры.
11.4.5.4. Элементы содержания и представления свидетельств
11.4.5.4.1. ADV_INT.2.1C
В логическом обосновании должно приводиться описание характеристик, на основании которых оценивается "полнота определения" внутренней структуры.
11.4.5.4.2. ADV_INT.2.2C
В описании внутренней структуры ФБО должно быть продемонстрировано, что внутренняя структура всех ФБО является полностью определенной.
11.4.5.5. Элементы действий оценщика
11.4.5.5.1. ADV_INT.2.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
11.4.5.5.2. ADV_INT.2.2E
Оценщик должен провести анализ внутренней структуры ФБО.
11.4.6. ADV_INT.3 Минимальная сложность внутренней структуры системы
Зависимости: ADV_IMP.1 Представление реализации ФБО
ADV_TDS.3 Базовый модульный проект
ALC_TAT.1 Полностью определенные инструментальные средства разработки.
11.4.6.1. Цели
Цель данного компонента состоит в предоставлении возможности предъявления к ФБО требований по полностью определенной внутренней структуре и минимальной сложности. Компонент предназначен для того, чтобы все ФБО были спроектированы и реализованы с использованием правильных технических принципов.
11.4.6.2. Замечания по применению
Заключение о соответствии структуры требованиям и об отсутствии избыточной сложности принимается на основании изучения конкретных технологий, используемых в ОО. Этот компонент требует идентификации стандартов, согласно которым будут оцениваться качества, характеризующие полноту определения структуры и ее сложность.
11.4.6.3. Элементы действий разработчика
11.4.6.3.1. ADV_INT.3.1D
Разработчик должен выполнить проектирование и реализацию всех ФБО таким образом, чтобы их внутренняя структура была полностью определена.
11.4.6.3.2. ADV_INT.3.2D
Разработчик должен представить описание и логическое обоснование внутренней структуры.
11.4.6.4. Элементы содержания и представления свидетельств
11.4.6.4.1. ADV_INT.3.1C
В логическом обосновании должно приводиться описание характеристик, на основании которых оценивается "полнота определения" и "сложность" внутренней структуры.
11.4.6.4.2. ADV_INT.3.2C
В описании внутренней структуры ФБО должно быть продемонстрировано, что внутренняя структура всех ФБО полностью определена и не является избыточно сложной.
11.4.6.5. Элементы действий оценщика
11.4.6.5.1. ADV_INT.3.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
11.4.6.5.2. ADV_INT.3.2E
Оценщик должен провести анализ внутренней структуры всех ФБО.
11.5. Моделирование политики безопасности (ADV_SPM)
11.5.1. Цели
Цель этого семейства состоит в том, чтобы приобрести дополнительное доверие посредством разработки формальной модели политики безопасности ФБО и установления соответствия между функциональной спецификацией и этой моделью политики безопасности. Ожидается, что модель политики безопасности, сохраняя внутреннюю непротиворечивость, формально устанавливает принципы безопасности на основании их характеристик с приведением доказательств, полученных математическими методами.
11.5.2. Ранжирование компонентов
Семейство содержит только один компонент.
11.5.3. Замечания по применению
Несоответствие ОО требованиям может быть следствием либо неверного понимания требований безопасности, либо неверной их реализации. Правильное определение требований безопасности для обеспечения их лучшего понимания может быть довольно проблематичным, поскольку такое определение должно быть достаточно точным для того, чтобы предотвратить нежелательные последствия или скрытые недостатки в процессе реализации ОО. От этапа проектирования до реализации и оценки модулируемые требования безопасности могут использоваться как руководство по точному проектированию и реализации, таким образом увеличивая доверие тому, что ОО удовлетворяет модулируемым требованиям безопасности. Точность модели и разрабатываемых на ее основе руководств значительно увеличивается посредством представления модели в формальном виде и верифицирования требований безопасности по формальным доказательствам.
Разработка формальной модели политики безопасности помогает выявить и исправить неоднозначные, нецелесообразные, внутренне противоречивые или противоречащие друг другу элементы политики безопасности. После построения ОО формальная модель служит для обеспечения усилий по оценке, предоставляя оценщику для вынесения заключения информацию, позволяющую определить, насколько хорошо разработчик понял реализацию функциональных возможностей безопасности, и есть ли несоответствия между требованиями безопасности и проектом ОО. Доверие к модели поддерживается доказательством того, что в ней не содержится противоречий.
Формальная модель безопасности является точным формальным представлением важных аспектов безопасности и взаимосвязи этих аспектов с режимом функционирования ОО; в ней определяются наборы правил и практики, регулирующих, каким образом ФБО управляют системными ресурсами, защищают их и каким-либо иным образом контролируют. Модель включает в себя набор свойств и ограничений, определяющих, каким образом предотвращается возможность использования информационных и вычислительных ресурсов для нарушения ФТБ, а также убедительный набор обоснованных с технической точки зрения доводов, доказывающих, что данные свойства и ограничения играют ключевую роль в осуществлении ФТБ. К этому относятся как формальные описания функциональных возможностей безопасности, так и вспомогательный текст, объясняющий модель и представляющий среду для данной модели. Режим безопасности ФБО моделируется в терминах как режима внешнего функционирования (т.е. того, как ФБО взаимодействует с остальными частями ОО и со средой его функционирования), так и внутреннего.
Модель политики безопасности ОО выводится в неформальном виде из ее реализации посредством рассмотрения предлагаемых требований безопасности из ЗБ. Неформальное представление считается успешно осуществленным в случае, когда выполнение принципов ОО (называемых также "неизменными", "инвариантами") осуществляется его характеристиками. Цель формальных методов состоит в усилении строгости такого выполнения. Представление неформальных доводов часто приводит к наличию среди них доводов заведомо неверных и необоснованных; в особенности это касается тех случаев, когда возрастает степень влияния взаимоотношений между объектами, субъектами и операциями. С целью минимизации риска возникновения небезопасных состояний выполняется прослеживание правил и характеристик модели политики безопасности с соответствующими свойствами и характеристиками некой формальной системы, чья строгость и стойкость могут быть впоследствии использованы для получения свойств безопасности посредством теорем и формального доказательства.
В то время как термин "формальная модель политики безопасности" используется в основном в академических кругах, в ИСО/МЭК 15408 нет фиксированного определения термина "безопасность"; его значение приравнивается к изложенному в ФТБ. Таким образом, формальная модель политики безопасности является лишь формальным представлением набора изложенных ФТБ.
Термин политика безопасности традиционно ассоциируется только с политиками контроля доступа, мандатного (полномочного) или избирательного (дискреционного). Однако содержание политики безопасности не ограничивается только правилами контроля доступа; существуют также политики аудита, идентификации, аутентификации, шифрования, управления и другие требуемые в ОО политики безопасности, реализуемые в соответствии с их описаниями в ПЗ/ЗБ. Компонент ADV_SPM.1.1D предназначен для идентификации таких формально модулируемых политик.
11.5.4. ADV_SPM.1 Формальная модель политики безопасности ОО
Зависимости: ADV_FSP.4 Полная функциональная спецификация.
11.5.4.1. Элементы действий разработчика
11.5.4.1.1. ADV_SPM.1.1D
Разработчик должен представить формальную модель ПБО для [назначение: список формально моделируемых политик].
11.5.4.1.2. ADV_SPM.1.2D
Для каждой политики, охваченной формальной моделью ПБО, в модели должны быть отражены значимые фрагменты изложения ФТБ, которые составляют данную политику.
11.5.4.1.3. ADV_SPM.1.3D
Разработчик должен представить формальное доказательство соответствия между какой-либо формальной функциональной спецификацией и моделью ПБО.
11.5.4.1.4. ADV_SPM.1.4D
Разработчик должен продемонстрировать соответствие между функциональной спецификацией и моделью ПБО.
11.5.4.2. Элементы содержания и представления свидетельств
11.5.4.2.1. ADV_SPM.1.1C
Модель ПБО должна быть изложена в формальном стиле с предоставлением вспомогательного пояснительного текста согласно требованиям, и в ней должны быть идентифицированы моделируемые политики ФБО.
11.5.4.2.2. ADV_SPM.1.2C
Для всех моделируемых политик в модели ПБО должно быть определено понятие "безопасность" для данного ОО, и должно быть представлено формальное доказательство того, что ОО не может перейти в небезопасное состояние.
11.5.4.2.3. ADV_SPM.1.3C
Соответствие между моделью и функциональной спецификацией должно быть представлено на соответствующем уровне формализации.
11.5.4.2.4. ADV_SPM.1.4C
В соответствии между моделью ПБО и функциональной спецификацией должно быть продемонстрировано, что функциональная спецификация является непротиворечивой и полной относительно модели ПБО.
11.5.4.2.5. ADV_SPM.1.5C
Демонстрация соответствия между моделью ПБО и функциональной спецификацией должна показывать, что интерфейсы в функциональной спецификации являются непротиворечивыми и полными относительно политик, указанных в назначении компонента ADV_SMP.1.1D.
11.5.4.3. Элементы действий оценщика
11.5.4.3.1. ADV_SPM.1.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
11.6. Проект ОО (ADV_TDS)
11.6.1. Цели
В описании проекта ОО предоставляется краткое содержание описания ФБО, а также полное описание ФБО. С увеличением требуемого уровня доверия увеличивается и требуемый уровень детализации описания. При увеличении размера и сложности системы ФБО целесообразно применение различных уровней декомпозиции. Требования к проекту предназначены для предоставления такой информации (соответствующей заданному уровню доверия), чтобы можно было сделать заключение, что ФТБ реализованы.
11.6.2. Ранжирование компонентов
Компоненты в этом семействе ранжированы в зависимости от объема информации, которую требуется предоставить в отношении ФБО, и в зависимости от степени формализации, которая требуется для описания проекта.
11.6.3. Замечания по применению
Цель проектной документации состоит в предоставлении информации, достаточной для определения границ ОО и для описания того, каким образом ФБО реализуют ФТБ. Количество и структура документов по проекту будет зависеть от сложности ОО и от количества ФТБ; в общем случае для очень сложного ОО с большим числом ФТБ потребуется разработать больше проектной документации, чем для очень простого ОО, реализующего только несколько ФТБ. Для сложных ОО в плане обеспечения доверия весьма полезно применять различные уровни декомпозиции при описании проекта, тогда как для простых ОО не требуется представлять описания их реализации и на верхнем, и на нижнем уровне.
В данном семействе используются два уровня декомпозиции: на уровне подсистем и на уровне модулей. Модуль - это наиболее конкретное описание функциональных возможностей; он представляет собой описание реализации. Разработчику следует иметь возможность реализовать описанную на уровне модулей часть ОО без дополнительных проектных решений. Подсистема - это описание проекта ОО; описание на уровне подсистем помогает предоставить описание верхнего уровня того, что и каким образом выполняет данная часть ОО. Подсистема может подразделяться на подсистемы более низкого уровня или на модули. Для адекватного описания функционирования очень сложных объектов может потребоваться несколько уровней подсистем. Напротив, для описания простых ОО может не требоваться уровень подсистем; предоставить четкое описание функционирования таких ОО можно с применением модульного описания.
Применяемый в общем случае подход к разработке проектной документации заключается в том, что при увеличении уровня доверия акцент при предоставлении описания смещается от обобщенного, менее детализированного уровня описания (уровень подсистем) к более детализированному (уровень модулей). В случае, когда приемлем модульный уровень описания, поскольку ОО достаточно прост, чтобы описать его на этом уровне, но при этом для этого уровня доверия требуется описание на уровне подсистем, будет достаточно предоставить описание на уровне модуля. Однако для сложных ОО данный принцип неприменим: излишняя детализация описания на модульном уровне будет совершенно недоступной для понимания без сопроводительного описания на уровне подсистем.
Данный подход следует основной парадигме, гласящей, что предоставление дополнительной детальной информации по реализации ФБО позволит обеспечить большее доверие тому, что ФТБ верно реализованы. Кроме того, такая информация может быть использована для подтверждения этого при проведении тестирования (ATE "Тестирования").
В требованиях данного семейства термин "интерфейс" употребляется как средство взаимодействия (между двумя подсистемами или модулями) и описывает, каким образом осуществляются такие взаимодействия, аналогично детализации ИФБО в функциональной спецификации (см. ADV_FSP "Функциональная спецификация"). Термин "взаимодействие" используется для идентификации цели взаимодействия; он определяет причину взаимодействия двух подсистем или двух модулей друг с другом.
11.6.3.1. Детализация модулей и подсистем
Согласно требованиям для подсистем и модулей должна быть предоставлена следующая подробная информация:
a) подсистемы и модули идентифицируются путем предоставления простого списка с обозначением того, чем они являются;
b) подсистемы и модули могут быть категорированы (как явным, так и неявным образом) как "осуществляющие выполнение ФТБ", "поддерживающие выполнение ФТБ", "не влияющие на выполнение ФТБ"; данные термины употребляются в том же значении, что и в семействе "Функциональная спецификация" (ADV_FSP);
c) режим функционирования подсистемы - это описание того, что именно выполняет подсистема. Режимы функционирования тоже могут подразделяться на категории: "осуществляющие выполнение ФТБ", "поддерживающие выполнение ФТБ", "не влияющие на выполнение ФТБ". При этом режим функционирования подсистемы не может быть отнесен к категории большей значимости, чем сама подсистема. Например, осуществляющая выполнение ФТБ подсистема может функционировать в режиме, осуществляющем выполнение ФТБ, а также в поддерживающем или не влияющем на ФТБ;
d) краткая информация о режиме функционирования - это обзор всех выполняемых подсистемой действий (например: "Подсистема протокола TCP собирает пакеты данных IP и связанную с ними адресную информацию в надежные информационные потоки");
e) описание режима функционирования подсистемы является объяснением всего, что выполняет данная система. Это описание следует составлять на таком уровне детализации, чтобы было легко определить, влияет ли данный режим функционирования каким-либо образом на обеспечение выполнения ФТБ;
f) в описании взаимодействий подсистем или модулей идентифицируется причина взаимодействия модулей и подсистем, а также характеризуется информация, которой они обмениваются. Не требуется представлять информацию в данном описании на таком же уровне детализации, как в спецификации интерфейсов. Например, будет достаточно указать, что: "подсистема X запрашивает блок памяти из модуля управления памятью, который отвечает на запрос путем предоставления участка распределенной памяти";
g) в описании интерфейсов предоставляется детализация того, каким образом осуществляются процессы взаимодействия между модулями. В описании интерфейсов не приводится описание причин и целей взаимодействия модулей (это описание относится к описанию взаимодействий), но детально описываются методы осуществления данного взаимодействия в терминах структуры и содержания сообщений, сигналов, процессов внутренних взаимодействий и т.д.;
h) назначение описывает, каким образом модуль выполняет свои функциональные возможности. Причем представленной детальной информации должно быть достаточно, чтобы не потребовалось дополнительных проектных решений. Следует, чтобы назначение модуля явно соответствовало представлению реализации, которым данный модуль реализуется;
i) иначе модуль описывается в терминах того, что определяется в элементе доверия.
Подсистемы и модули, как осуществляющие выполнение ФТБ, так и все остальные, более подробно объясняются в Приложении A.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
Разработчик должен обеспечить прослеживание от ИФБО в функциональной спецификации к самому низкому уровню декомпозиции, имеющемуся в проекте ОО.
11.6.4.2. Элементы содержания и представления свидетельств
11.6.4.2.1. ADV_TDS.1.1C
В проекте должно приводиться описание структуры ОО на уровне подсистем.
11.6.4.2.2. ADV_TDS.1.2C
В проекте должны быть идентифицированы все подсистемы ФБО.
11.6.4.2.3. ADV_TDS.1.3C
В проекте должно приводиться описание режима функционирования для каждой подсистемы, поддерживающей выполнение ФТБ или не влияющей на их выполнение, с предоставлением детальной информации, достаточной для того, чтобы установить, что подсистема не является осуществляющей выполнение ФТБ.
11.6.4.2.4. ADV_TDS.1.4C
В проекте должна приводиться аннотация осуществляющих выполнение ФТБ режимов безопасности тех подсистем, которые являются осуществляющими выполнение ФТБ.
11.6.4.2.5. ADV_TDS.1.5C
В проекте должно приводиться описание взаимодействий между осуществляющими выполнение ФТБ подсистемами ФБО, а также между ними и другими подсистемами ФБО.
11.6.4.2.6. ADV_TDS.1.6C
В прослеживании должно быть продемонстрировано, что все описанные в проекте ОО режимы функционирования прослеживаются к вызывающим их ИФБО.
11.6.4.3. Элементы действий оценщика
11.6.4.3.1. ADV_TDS.1.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
11.6.4.3.2. ADV_TDS.1.2E
Оценщик должен сделать независимое заключение, что проект является точным и полным отображением всех функциональных требований безопасности.
11.6.5. ADV_TDS.2 Архитектурный проект
Зависимости: ADV_FSP.3 Функциональная спецификация с полной аннотацией.
11.6.5.1. Элементы действий разработчика
11.6.5.1.1. ADV_TDS.2.1D
Разработчик должен представить проект ОО.
11.6.5.1.2. ADV_TDS.2.2D
Разработчик должен обеспечить прослеживание ИФБО в функциональной спецификации к более низкому уровню декомпозиции, представленному в проекте ОО.
11.6.5.2. Элементы содержания и представления свидетельств
11.6.5.2.1. ADV_TDS.2.1C
В проекте должно приводиться описание структуры ОО на уровне подсистем.
11.6.5.2.2. ADV_TDS.2.2C
В проекте должны быть идентифицированы все подсистемы ФБО.
11.6.5.2.3. ADV_TDS.2.3C
В проекте должно приводиться описание режима функционирования для каждой подсистемы ФБО, не влияющей на выполнение ФТБ, с предоставлением детальной информации, достаточной для того, чтобы установить, что подсистема является не влияющей на выполнение ФТБ.
11.6.5.2.4. ADV_TDS.2.4C
В проекте должно приводиться описание осуществляющих выполнение ФТБ режимов безопасности тех подсистем, которые являются осуществляющими выполнение ФТБ.
11.6.5.2.5. ADV_TDS.2.5C
В проекте должна приводиться аннотация поддерживающих и не влияющих на выполнение ФТБ режимов безопасности тех подсистем, которые являются осуществляющими выполнение ФТБ.
11.6.5.2.6. ADV_TDS.2.6C
В проекте должна приводиться аннотация режимов безопасности тех подсистем, которые являются осуществляющими выполнение ФТБ.
11.6.5.2.7. ADV_TDS.2.7C
В проекте должно приводиться описание взаимодействий всех подсистем ФБО между собой.
11.6.5.2.8. ADV_TDS.2.8C
В прослеживании должно быть продемонстрировано, что все описанные в проекте ОО режимы функционирования прослеживаются к вызывающим их ИФБО.
11.6.5.3. Элементы действий оценщика
11.6.5.3.1. ADV_TDS.2.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
11.6.5.3.2. ADV_TDS.2.2E
Оценщик должен сделать независимое заключение, что проект является точным и полным отображением всех функциональных требований безопасности.
11.6.6. ADV_TDS.3 Базовый модульный проект
Зависимости: ADV_FSP.4 Полная функциональная спецификация.
11.6.6.1. Элементы действий разработчика
11.6.6.1.1. ADV_TDS.3.1D
Разработчик должен представить проект ОО.
11.6.6.1.2. ADV_TDS.3.2D
Разработчик должен обеспечить прослеживание ИФБО в функциональной спецификации к более низкому уровню декомпозиции, представленному в проекте ОО.
11.6.6.2. Элементы содержания и представления свидетельств
11.6.6.2.1. ADV_TDS.3.1C
В проекте должно приводиться описание структуры ОО на уровне подсистем.
11.6.6.2.2. ADV_TDS.3.2C
В проекте должно приводиться описание структуры ОО на уровне модулей.
11.6.6.2.3. ADV_TDS.3.3C
В проекте должны быть идентифицированы все подсистемы ФБО.
11.6.6.2.4. ADV_TDS.3.4C
В проекте должно приводиться описание каждой из подсистем ФБО.
11.6.6.2.5. ADV_TDS.3.5C
В проекте должно приводиться описание взаимодействий всех подсистем ФБО между собой.
11.6.6.2.6. ADV_TDS.3.6C
В проекте должно быть осуществлено прослеживание подсистем ФБО с модулями ФБО.
11.6.6.2.7. ADV_TDS.3.7C
В проекте должен быть описан каждый осуществляющий выполнение ФТБ модуль с точки зрения его назначения и взаимодействия с другими модулями.
11.6.6.2.8. ADV_TDS.3.8C
В проекте должен быть описан каждый осуществляющий выполнение ФТБ модуль с точки зрения его относящихся к ФТБ интерфейсов, значений, предоставляемых этими интерфейсами в ответ на запросы, взаимодействий с другими модулями и вызываемыми интерфейсами этих модулей.
11.6.6.2.9. ADV_TDS.3.9C
В проекте должен быть описан каждый поддерживающий и не влияющий на выполнение ФТБ модуль с точки зрения его назначения и взаимодействия с другими модулями.
11.6.6.2.10. ADV_TDS.3.10C
В прослеживании должно быть продемонстрировано, что все описанные в проекте ОО режимы функционирования прослеживаются к вызывающим их ИФБО.
11.6.6.3. Элементы действий оценщика
11.6.6.3.1. ADV_TDS.3.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
11.6.6.3.2. ADV_TDS.3.2E
Оценщик должен сделать независимое заключение, что проект является точным и полным отображением всех функциональных требований безопасности.
11.6.7. ADV_TDS.4 Полуформальный модульный проект
Зависимости: ADV_FSP.5 Полная полуформальная функциональная спецификация с дополнительной информацией об ошибках.
11.6.7.1. Элементы действий разработчика
11.6.7.1.1. ADV_TDS.4.1D
Разработчик должен представить проект ОО.
11.6.7.1.2. ADV_TDS.4.2D
Разработчик должен обеспечить прослеживание ИФБО в функциональной спецификации к более низкому уровню декомпозиции, представленному в проекте ОО.
11.6.7.2. Элементы содержания и представления свидетельств
11.6.7.2.1. ADV_TDS.4.1C
В проекте должно приводиться описание структуры ОО на уровне подсистем.
11.6.7.2.2. ADV_TDS.4.2C
В проекте должно приводиться описание структуры ОО на уровне модулей с присвоением каждому модулю категории либо осуществляющего выполнение ФТБ, либо поддерживающего, либо не влияющего на выполнение ФТБ.
11.6.7.2.3. ADV_TDS.4.3C
В проекте должны быть идентифицированы все подсистемы ФБО.
11.6.7.2.4. ADV_TDS.4.4C
В проекте должно приводиться полуформальное описание каждой из подсистем ФБО, сопровождающееся вспомогательным пояснительным неформальным текстом, если это представляется целесообразным.
11.6.7.2.5. ADV_TDS.4.5C
В проекте должно приводиться описание взаимодействий всех подсистем ФБО между собой.
11.6.7.2.6. ADV_TDS.4.6C
В проекте должно быть осуществлено прослеживание подсистем ФБО с модулями ФБО.
11.6.7.2.7. ADV_TDS.4.7C
В проекте должен быть описан каждый осуществляющий и поддерживающий выполнение ФТБ модуль с точки зрения его назначения и взаимодействия с другими модулями.
11.6.7.2.8. ADV_TDS.4.8C
В проекте должен быть описан каждый осуществляющий и поддерживающий выполнение ФТБ модуль с точки зрения относящихся к ФТБ интерфейсов, значений, предоставляемых этими интерфейсами в ответ на запросы, взаимодействий с другими модулями и вызываемыми интерфейсами этих модулей.
11.6.7.2.9. ADV_TDS.4.9C
В проекте должен быть описан каждый не влияющий на выполнение ФТБ модуль с точки зрения его назначения и взаимодействия с другими модулями.
11.6.7.2.10. ADV_TDS.4.10C
В прослеживании должно быть продемонстрировано, что все описанные в проекте ОО режимы функционирования прослеживаются к вызывающим их ИФБО.
11.6.7.3. Элементы действий оценщика
11.6.7.3.1. ADV_TDS.4.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
11.6.7.3.2. ADV_TDS.3.2E
Оценщик должен сделать независимое заключение, что проект является точным и полным отображением всех функциональных требований безопасности.
11.6.8. ADV_TDS.5 Полный полуформальный модульный проект
Зависимости: ADV_FSP.5 Полная полуформальная функциональная спецификация с дополнительной информацией об ошибках.
11.6.8.1. Элементы действий разработчика
11.6.8.1.1. ADV_TDS.5.1D
Разработчик должен представить проект ОО.
11.6.8.1.2. ADV_TDS.5.2D
Разработчик должен обеспечить прослеживание ИФБО в функциональной спецификации к более низкому уровню декомпозиции, представленному в проекте ОО.
11.6.8.2. Элементы содержания и представления свидетельств
11.6.8.2.1. ADV_TDS.5.1C
В проекте должно приводиться описание структуры ОО на уровне подсистем.
11.6.8.2.2. ADV_TDS.5.2C
В проекте должно приводиться описание структуры ОО на уровне модулей с присвоением каждому модулю категории либо осуществляющего выполнение ФТБ, либо поддерживающего, либо не влияющего на выполнение ФТБ.
11.6.8.2.3. ADV_TDS.5.3C
В проекте должны быть идентифицированы все подсистемы ФБО.
11.6.8.2.4. ADV_TDS.5.4C
В проекте должно приводиться полуформальное описание каждой из подсистем ФБО, сопровождающееся вспомогательным пояснительным неформальным текстом, если это представляется уместным.
11.6.8.2.5. ADV_TDS.5.5C
В проекте должно приводиться описание взаимодействий всех подсистем ФБО между собой.
11.6.8.2.6. ADV_TDS.5.6C
В проекте должно быть осуществлено прослеживание подсистем ФБО к модулям ФБО.
11.6.8.2.7. ADV_TDS.5.7C
В проекте должно приводиться полуформальное описание каждого модуля с точки зрения его назначения, взаимодействия с другими модулями, интерфейсов и значений, предоставляемых этими интерфейсами в ответ на запросы, а также вызываемых интерфейсов других модулей. Полуформальное описание сопровождается вспомогательным пояснительным неформальным текстом, если это представляется целесообразным.
11.6.8.2.8. ADV_TDS.5.8C
В прослеживании должно быть продемонстрировано, что все описанные в проекте ОО режимы функционирования прослеживаются к вызывающим их ИФБО.
11.6.8.3. Элементы действий оценщика
11.6.8.3.1. ADV_TDS.5.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
11.6.8.3.2. ADV_TDS.5.2E
Оценщик должен сделать независимое заключение, что проект является точным и полным отображением всех функциональных требований безопасности.
11.6.9. ADV_TDS.6 Полный полуформальный модульный проект с формальным представлением проекта на верхнем уровне
Зависимости: ADV_FSP.6 Полная полуформальная функциональная спецификация с дополнительной формальной спецификацией.
11.6.9.1. Элементы действий разработчика
11.6.9.1.1. ADV_TDS.6.1D
Разработчик должен представить проект ОО.
11.6.9.1.2. ADV_TDS.6.2D
Разработчик должен обеспечить прослеживание ИФБО в функциональной спецификации к более низкому уровню декомпозиции, представленному в проекте ОО.
11.6.9.1.3. ADV_TDS.6.3D
Разработчик должен представить формальную спецификацию подсистем ФБО.
11.6.9.1.4. ADV_TDS.6.4D
Разработчик должен представить доказательство соответствия формальных спецификаций подсистем ФБО функциональной спецификации.
11.6.9.2. Элементы содержания и представления свидетельств
11.6.9.2.1. ADV_TDS.6.1C
В проекте должно приводиться описание структуры ОО на уровне подсистем.
11.6.9.2.2. ADV_TDS.6.2C
В проекте должно приводиться описание структуры ОО на уровне модулей с присвоением каждому модулю категории либо осуществляющего выполнение ФТБ, либо поддерживающего, либо не влияющего на выполнение ФТБ.
11.6.9.2.3. ADV_TDS.6.3C
В проекте должны быть идентифицированы все подсистемы ФБО.
11.6.9.2.4. ADV_TDS.6.4C
В проекте должно приводиться полуформальное описание каждой из подсистем ФБО, сопровождающееся вспомогательным пояснительным неформальным текстом, если это представляется уместным.
11.6.9.2.5. ADV_TDS.6.5C
В проекте должно приводиться описание взаимодействий всех подсистем ФБО между собой.
11.6.9.2.6. ADV_TDS.6.6C
В проекте должно быть осуществлено прослеживание подсистем ФБО к модулям ФБО.
11.6.9.2.7. ADV_TDS.6.7C
В проекте должно приводиться описание в полуформальном стиле каждого модуля с точки зрения его назначения, взаимодействия с другими модулями, интерфейсов и значений, предоставляемых этими интерфейсами в ответ на запросы, а также вызываемых интерфейсов других модулей. Полуформальное описание сопровождается вспомогательным пояснительным неформальным текстом, если это представляется уместным.
11.6.9.2.8. ADV_TDS.6.8C
Формальная спецификация подсистем ФБО должна содержать формальное описание ФБО и сопровождаться вспомогательным пояснительным неформальным текстом, если это представляется уместным.
11.6.9.2.9. ADV_TDS.6.9C
В прослеживании должно быть продемонстрировано, что все описанные в проекте ОО режимы функционирования прослеживаются к вызывающим их ИФБО.
11.6.9.2.10. ADV_TDS.6.10C
В свидетельстве о соответствии формальных спецификаций подсистем ФБО функциональной спецификации должно быть продемонстрировано, что все описанные в проекте ОО режимы функционирования являются правильным и полным отображением вызывающих их ИФБО.
11.6.9.3. Элементы действий оценщика
11.6.9.3.1. ADV_TDS.6.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
11.6.9.3.2. ADV_TDS.6.2E
Оценщик должен сделать независимое заключение, что проект является точным и полным отображением всех функциональных требований безопасности.
12. Класс AGD: Руководства
Класс "Руководства" предоставляет требования к документации руководств для всех пользовательских ролей. Для безопасной подготовки и безопасного функционирования ОО необходимо описать все существенные аспекты, относящиеся к безопасному применению ОО. В данном классе также рассматриваются случаи непреднамеренных неточностей конфигурации или ошибок эксплуатации ОО.
Во многих случаях уместно предоставление отдельных руководств по подготовительным процедурам и эксплуатации ОО или даже отдельных руководств для различных пользовательских ролей: конечных пользователей, администраторов, программистов - разработчиков приложений, использующих программные и аппаратные интерфейсы и т.д.
Класс "Руководства" подразделяется на два семейства: касающееся руководства пользователя по подготовительным процедурам (что должно делаться для перевода поставленного ОО в оцененную конфигурацию в среде его функционирования, как описано в ЗБ) и руководства пользователя по эксплуатации (что должно делаться в процессе функционирования ОО в его оцененной конфигурации).
На рисунке 12 показаны семейства этого класса и иерархия компонентов в семействах.
"Рис. 12. Декомпозиция класса AGD "Руководства""
12.1. Руководство пользователя по эксплуатации (AGD_OPE)
12.1.1. Цели
Руководство пользователя по эксплуатации относится к печатным документам, которые предназначены для использования всеми пользователями оцененной конфигурации ОО: конечными пользователями, лицами, ответственными за правильное обслуживание и администрирование ОО с целью максимизации безопасности, а также другими лицами (например программистами), использующими внешние интерфейсы ОО. Руководство пользователя по эксплуатации описывает функции, предоставляемые ФБО, содержит инструкции и рекомендации по безопасности (включая предупреждения), способствующие пониманию ФБО и содержащие информацию, критически важную для безопасности, а также критически важные для обеспечения безопасного состояния действия. Не рекомендуется, чтобы в руководствах были неточные и необоснованные инструкции; для всех режимов функционирования следует назначить процедуры безопасности. Следует, чтобы небезопасные состояния выявлялись без затруднений.
Руководство пользователя по эксплуатации обеспечивает некоторую степень доверия к тому, что санкционированные пользователи (не являющиеся злоумышленниками), администраторы, поставщики приложений и другие лица, использующие внешние интерфейсы ОО, имеют представление о безопасном функционировании ОО и будут использовать ОО по назначению. Оценка руководства пользователя включает проверку того, может ли ОО функционировать в небезопасном режиме таким образом, что пользователь при этом будет обоснованно полагать, что функционирование происходит в безопасном режиме. Целью является минимизация рисков человеческого фактора или других ошибок при эксплуатации, которые могут повлечь деактивацию, недоступность или сбой активации функций безопасности, что, в свою очередь, приведет к невыявленному небезопасному состоянию.
12.1.2. Ранжирование компонентов
Это семейство содержит только один компонент.
12.1.3. Замечания по применению
В ОО могут быть различные роли или группы пользователей, которые могут взаимодействовать с ФБО. Эти роли или группы пользователей следует учитывать в руководстве пользователя по эксплуатации. Пользователи могут быть разделены на администраторов и лиц, не являющихся администраторами, а могут быть разделены и с точки зрения функциональных обязанностей на лиц, ответственных за получение, приемку, установку и обслуживание ОО, разработчиков приложений, проверяющих, аудиторов, администраторов, конечных пользователей. Каждая роль может объединять в себе обширный набор прав, а может включать одиночное право.
Требования элемента AGD_OPE.1.1C охватывают тот аспект, что в руководстве пользователя должны быть отражены соответствующим образом все описанные в ПЗ/ЗБ предупреждения пользователям ОО, относящиеся к определению проблемы безопасности и к целям безопасности для среды функционирования.
Концепция безопасных значений, используемая в элементе AGD_OPE.1.3C, значима, если пользователь управляет параметрами безопасности. В руководстве необходимо представить безопасные и потенциально опасные значения для таких параметров.
В элементе AGD_OPE.1.4C содержится требование, чтобы в руководстве пользователя было описание соответствующей реакции на все события, имеющие значение для безопасности. Хотя многие имеющие значение для безопасности события являются результатом выполнения функций, это не всегда так (например, переполнение журнала аудита, обнаружение вторжения). Кроме того, событие, имеющее значение для безопасности, может происходить в результате выполнения определенной последовательности функций или наоборот: несколько имеющих значение для безопасности событий могут быть вызваны выполнением одной функции.
В элементе AGD_OPE.1.7C содержится требование, чтобы руководство пользователя было четким и обоснованным. Нечеткие и необоснованные инструкции могут ввести пользователя ОО в заблуждение в отношении состояния безопасности ОО: пользователь будет считать, что ОО находится в безопасном состоянии, тогда как это не так.
Примером нечеткой инструкции может служить описание отдельной инструкции руководства, которая может быть двояко истолкована, что может привести к небезопасному состоянию.
Примером необоснованной инструкции может служить рекомендация следовать настолько усложненной процедуре, что нецелесообразно ожидать от пользователей выполнения данной рекомендации.
12.1.4. AGD_OPE.1 Руководство пользователя по эксплуатации
Зависимости: ADV_FSP.1 Базовая функциональная спецификация.
12.1.4.1. Элементы действий разработчика
12.1.4.1.1. AGD_OPE.1.1D
Разработчик должен представить руководство пользователя по эксплуатации.
12.1.4.2. Элементы содержания и представления свидетельств
12.1.4.2.1. AGD_OPE.1.1C
В руководстве пользователя по эксплуатации для каждой пользовательской роли должно быть представлено описание доступных пользователям функций, возможных прав и обязанностей, которыми следует управлять в защищенной среде функционирования, а также уместных предупреждений.
12.1.4.2.2. AGD_OPE.1.2C
В руководстве пользователя по эксплуатации в рамках каждой пользовательской роли должно быть представлено описание принципов безопасной работы с предоставленными в ОО интерфейсами.
12.1.4.2.3. AGD_OPE.1.3C
В руководстве пользователя по эксплуатации должно быть представлено описание доступных для каждой пользовательской роли функций и интерфейсов, особенно всех параметров безопасности под управлением пользователя, с указанием безопасных значений, если это уместно.
12.1.4.2.4. AGD_OPE.1.4C
В руководстве пользователя по эксплуатации для каждой пользовательской роли должно быть представлено четкое представление каждого типа имеющих значение для безопасности событий, связанных с доступными пользователю обязательными для выполнения функциями, включая изменение характеристик безопасности сущностей, находящихся под управлением ФБО.
12.1.4.2.5. AGD_OPE.1.5C
В руководстве пользователя по эксплуатации должны быть идентифицированы все возможные режимы работы ОО (включая операции после сбоев и ошибок эксплуатации), их последствия и участие в обеспечении безопасного функционирования.
12.1.4.2.6. AGD_OPE.1.6C
В руководстве пользователя по эксплуатации для каждой пользовательской роли должно быть описание всех мер безопасности, предназначенных для выполнения целей безопасности для среды функционирования согласно описанию в ЗБ.
12.1.4.2.7. AGD_OPE.1.7C
Руководство пользователя по эксплуатации должно быть четким и обоснованным.
12.1.4.3. Элементы действий оценщика
12.1.4.3.1. AGD_OPE1.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
12.2. Подготовительные процедуры (AGD_PRE)
12.2.1. Цели
Подготовительные процедуры необходимы для обеспечения того, что ОО был получен и установлен безопасным образом в соответствии с намерениями разработчика. Требования к подготовительным процедурам направлены на безопасный переход от поставленного ОО к его первоначальной среде функционирования. Это включает также и исследование на предмет возможности конфигурации или установки ОО небезопасным образом, при котором пользователь будет обоснованно считать, что ОО находится в безопасном состоянии.
12.2.2. Ранжирование компонентов
Это семейство содержит только один компонент.
12.2.3. Замечания по применению
Необходимо учитывать, что применение данных требований будет варьироваться в зависимости от таких аспектов, как предоставлен ли ОО в рабочем состоянии или он установлен в месте размещения владельца ОО на месте владельца и т.п.
Первый процесс, который охватывают подготовительные процедуры, состоит в безопасной приемке потребителем полученного ОО в соответствии с процедурами поставки разработчика. Даже если разработчик не определил процедуры поставки, безопасность приемки все равно должна быть обеспечена.
Установка ОО включает преобразование среды его функционирования в состояние, удовлетворяющее целям безопасности для среды функционирования, изложенным в ЗБ.
Возможна также ситуация, когда установка не требуется, например, для смарт-карт. В этом случае необязательно требовать и анализировать процедуры установки.
Требования этого семейства доверия представлены отдельно от требований семейства "Руководство пользователя по эксплуатации" (AGD_OPE) в силу малой употребимости, а возможно, и вовсе однократного применения подготовительных процедур.
12.2.4. AGD_PRE.1 Подготовительные процедуры
Зависимости: отсутствуют.
12.2.4.1. Элементы действий разработчика
12.2.4.1.1. AGD_PRE.1.1D
Разработчик должен предоставить ОО вместе с подготовительными процедурами.
12.2.4.2. Элементы содержания и представления свидетельств
12.2.4.2.1. AGD_PRE.1.1C
В подготовительных процедурах должны описываться все шаги, необходимые для безопасной приемки поставленного ОО в соответствии с процедурами поставки разработчика.
12.2.4.2.2. AGD_PRE.1.2C
В подготовительных процедурах должны описываться все необходимые шаги для безопасной установки ОО и безопасной подготовки среды функционирования в соответствии с целями безопасности для среды функционирования, описанными в ЗБ.
12.2.4.3. Элементы действий оценщика
12.2.4.3.1. AGD_PRE.1.1E
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
12.2.4.3.2. AGD_PRE.1.2E
Оценщик должен использовать подготовительные процедуры для подтверждения того, что ОО может быть безопасно подготовлен к работе.
13. Класс ALC: Поддержка жизненного цикла
(Нет голосов) |
-
12.04.2024
Названы города России с самым доступным жильем
Городом с самыми дешевыми квартирами в новостройках оказался Воронеж
-
12.04.2024
Россиянам назвали лучшее время для продажи дачи
Аналитик Гутман: период с мая по июль является лучшим периодом для продажи дачи
-
12.04.2024
Предсказано будущее рынка жилья в России
«МК»: в России не отменят льготную ипотеку
-
12.04.2024
В Москве подешевела аренда квартир
Аренда квартир в Москве подешевела на 10 %
-
22.03.2024
Хуснуллин назвал необходимый размер ставки по ипотеке
Вице-премьер Хуснуллин: ставка по ипотеке должна быть пять процентов