ГОСТ Р ИСО/МЭК 15408-3-2002 Информационная технология (ИТ). Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Требования доверия к безопасности.
ГОСТ Р ИСО/МЭК 15408-3-2002
Группа П85
ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ
МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ КРИТЕРИИ ОЦЕНКИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ
Часть 3
Требования доверия к безопасности
Information technology. Security techniques. Evaluation criteria for IT security. Part 3.
Security assurance requirements
ОКС 35.040
ОКСТУ 4002
Дата введения 2004-01-01
Предисловие
1 РАЗРАБОТАН Центром безопасности информации, 4 ЦНИИ Министерства обороны РФ, Центром "Атомзащитаинформ", ЦНИИАТОМИНФОРМ, ВНИИстандарт при участии экспертов Международной рабочей группы по Общим критериям
ВНЕСЕН Гостехкомиссией России, Техническими комитетами по стандартизации ТК 362Р "Защита информации" и ТК 22 "Информационные технологии"
2 ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 4 апреля 2002 г. N 133-ст
3 Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК 15408-3-99 "Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Требования доверия к безопасности"
4 ВВЕДЕН ВПЕРВЫЕ
Введение
Проблема обеспечения безопасности информационных технологий занимает все более значительное место в реализации компьютерных систем и сетей по мере того, как возрастает их роль в информатизации общества. Обеспечение безопасности информационных технологий (ИТ) представляет собой комплексную проблему, которая решается в направлениях совершенствования правового регулирования применения ИТ, совершенствования методов и средств их разработки, развития системы сертификации, обеспечения соответствующих организационно-технических условий эксплуатации. Ключевым аспектом решения проблемы безопасности ИТ является выработка системы требований, критериев и показателей для оценки уровня безопасности ИТ.
ГОСТ Р ИСО/МЭК 15408 содержит общие критерии оценки безопасности информационных технологий.
ГОСТ Р ИСО/МЭК 15408-1 устанавливает общий подход к формированию требований к оценке безопасности (функциональные и доверия), основные конструкции (профиль защиты, задание по безопасности) представления требований безопасности в интересах потребителей, разработчиков и оценщиков продуктов и систем ИТ. Требования безопасности объекта оценки (ОО) по методологии Общих критериев определяются исходя из целей безопасности, которые, в свою очередь, основываются на анализе назначения ОО и условий среды его использования (угроз, предложений, политики безопасности).
ГОСТ Р ИСО/МЭК 15408-2 содержит универсальный систематизированный каталог функциональных требований безопасности и предусматривает возможность их детализации и расширения по определенным правилам.
ГОСТ Р ИСО/МЭК 15408-3 включается в себя систематизированный каталог требований доверия, определяющих меры, которые должны быть приняты на всех этапах жизненного цикла продукта или системы ИТ для обеспечения уверенности в том, что они удовлетворяют предъявленным к ним функциональным требованиям. Здесь же содержатся оценочные уровни доверия, определяющие шкалу требований, которые позволяют с возрастающей степенью полноты и строгости оценить проектную, тестовую и эксплуатационную документацию, правильность реализации функций безопасности ОО, уязвимости продукта или системы ИТ, стойкость механизмов защиты и сделать заключение об уровне доверия к безопасности объекта оценки.
1 Область применения
Настоящий стандарт определяет требования доверия к безопасности и включает в себя оценочные уровни доверия (ОУД), определяющие шкалу для измерения доверия, собственно компоненты доверия, из которых составлены уровни доверия, и критерии для оценки ПЗ и ЗБ.
1.1 Структура
Настоящий стандарт состоит из следующих разделов:
1 - введение и парадигма;
2 - структура представления классов, семейств и компонентов доверия, оценочных уровней доверия и их взаимосвязь, а также краткая характеристика классов и семейств доверия, представленных в разделах 8-14;
3-5 - краткое введение в критерии оценки ПЗ и ЗБ, сопровождаемое детализированными объяснениями семейств и компонентов, которые применяют для этих оценок;
6 - детализированные определения оценочных уровней доверия;
7 - краткое введение в классы доверия;
8-14 - детализированные определения классов доверия;
15-16 - краткое введение в критерии оценки поддержки доверия с детализированными определениями применяемых семейств и компонентов.
Приложение А содержит сводку зависимостей между компонентами доверия.
Приложение Б содержит перекрестные ссылки между ОУД и компонентами доверия.
1.2 Парадигма доверия
Цель данного подраздела состоит в изложении основных принципов и подходов к установлению доверия к безопасности. Данный подраздел позволит читателю понять логику построения требований доверия в настоящем стандарте.
1.2.1 Основные принципы ГОСТ Р ИСО/МЭК 15408
Основные принципы ГОСТ Р ИСО/МЭК 15408 состоят в том, что следует четко сформулировать угрозы безопасности и положения политики безопасности организации, а достаточность предложенных мер безопасности должна быть продемонстрирована.
Более того, следует предпринять меры по уменьшению вероятности наличия уязвимостей, возможности их проявления (т.е. преднамеренного использования или непреднамеренной активизации), а также степени ущерба, который может явиться следствием проявления уязвимостей. Дополнительно следует предпринять меры для облегчения последующей идентификации уязвимостей, а также по их устранению, ослаблению и/или оповещению об их использовании или активизации.
1.2.2 Подход к доверию
Основная концепция ГОСТ Р ИСО/МЭК 15408 - обеспечение доверия, основанное на оценке (активном исследовании) продукта или системы ИТ, которым предполагается доверять. Оценка была традиционным способом обеспечения доверия и являлась основой предшествующих критериев оценки. Для согласования с существующими подходами в ГОСТ Р ИСО/МЭК 15408 принят тот же самый основной принцип. ГОСТ Р ИСО/МЭК 15408 предполагает, что проверку правильности документации и разработанного продукта или системы ИТ будут проводить опытные оценщики, уделяя особое внимание области, глубине и строгости оценки.
ГОСТ Р ИСО/МЭК 15408 не отрицает и при этом не комментирует относительные достоинства других способов получения доверия. Продолжаются исследования альтернативных путей достижения доверия. Если в результате этих исследований будут выявлены другие отработанные альтернативные подходы, то они могут в дальнейшем быть включены в ГОСТ Р ИСО/МЭК 15408, который структурно организован так, что предусматривает такую возможность.
1.2.2.1 Значимость уязвимостей
Предполагается, что имеются нарушители, которые будут пытаться активно использовать возможности нарушения политики безопасности как для получения незаконной выгоды, так и для незлонамеренных, но тем не менее опасных действий. Нарушители могут также случайно активизировать уязвимости безопасности, нанося вред организации. При необходимости обрабатывать чувствительную информацию и отсутствии в достаточной степени доверенных продуктов или систем имеется значительный риск из-за отказов ИТ. Поэтому нарушения безопасности ИТ могут вызвать значительные потери.
Нарушения безопасности ИТ возникают вследствие преднамеренного использования или случайной активизации уязвимостей при применении ИТ по назначению.
Следует предпринять ряд шагов для предотвращения уязвимостей, возникающих в продуктах и системах ИТ. По возможности уязвимости должны быть:
а) устранены, т.е. следует предпринять активные действия для выявления, а затем удаления или нейтрализации всех уязвимостей, которые могут проявиться;
б) минимизированы, т.е. следует предпринять активные действия для уменьшения до допустимого остаточного уровня возможного ущерба от любого проявления уязвимостей;
в) отслежены, т.е. следует предпринять активные действия для обнаружения любой попытки использовать оставшиеся уязвимости с тем, чтобы ограничить ущерб.
1.2.2.2 Причины уязвимостей
Уязвимости могут возникать из-за недостатков:
а) требований, т.е. продукт или система ИТ могут обладать требуемыми от них функциями и свойствами, но все же содержать уязвимости, которые делают их непригодными или неэффективными в части безопасности;
б) проектирования, т.е. продукт или система ИТ не отвечают спецификации, и/или уязвимости являются следствием некачественных стандартов проектирования или неправильных проектных решений;
в) эксплуатации, т.е. продукт или система ИТ разработаны в полном соответствии с корректными спецификациями, но уязвимости возникают как результат неадекватного управления при эксплуатации.
1.2.2.3 Доверие в ГОСТ Р ИСО/МЭК 15408
Доверие - основа для уверенности в том, что продукт или система ИТ отвечают целям безопасности. Доверие могло бы быть получено путем обращения к таким источникам, как бездоказательное утверждение, предшествующий аналогичный опыт или специфический опыт. Однако ГОСТ Р ИСО/МЭК 15408 обеспечивает доверие с использованием активного исследования. Активное исследование - это оценка продукта или системы ИТ для определения его свойств безопасности.
1.2.2.4 Доверие через оценку
Оценка является традиционным способом достижения доверия, и она положена в основу ГОСТ Р ИСО/МЭК 15408. Методы оценки могут, в частности, включать в себя:
а) анализ и проверку процессов и процедур;
б) проверку, что процессы и процедуры действительно применяются;
в) анализ соответствия между представлениями проекта ОО;
г) анализ соответствия каждого представления проекта ОО требованиям;
д) верификацию доказательств;
е) анализ руководств;
ж) анализ разработанных функциональных тестов и полученных результатов;
и) независимое функциональное тестирование;
к) анализ уязвимостей, включающий предположения о недостатках;
л) тестирование проникновения.
1.2.3 Шкала оценки доверия в ГОСТ Р ИСО/МЭК 15408
Основные принципы ГОСТ Р ИСО/МЭК 15408 содержат утверждение, что большее доверие является результатом приложения больших усилий при оценке и что цель состоит в применении минимальных усилий, требуемых для обеспечения необходимого уровня доверия. Повышение уровня усилий может быть основано на:
а) области охвата, т.е. увеличении рассматриваемой части продукта или системы ИТ;
б) глубине, т.е. детализации рассматриваемых проектных материалов и реализации;
в) строгости, т.е. применении более структурированного и формального подхода.
2 Требования доверия к безопасности
2.1 Структуры
Следующие подразделы описывают конструкции, используемые в представлении классов, семейств и компонентов доверия, оценочных уровней доверия (ОУД), и их взаимосвязь.
На рисунке 2.1 показаны требования доверия, определенные в настоящем стандарте. Наиболее общую совокупность требований доверия называют классом. Каждый класс содержит семейства доверия, которые разделены на компоненты доверия, содержащие, в свою очередь, элементы доверия. Классы и семейства используют для обеспечения таксономии классифицируемых требований доверия, в то время как компоненты применяют непосредственно для спецификации требований доверия в ПЗ/ЗБ.
Рисунок 2.1 - Иерархическая структура представления требований доверия: класс-семейство-компонент-элемент
2.1.1 Структура класса
Рисунок 2.1 иллюстрирует структуру класса доверия.
2.1.1.1 Имя класса
Каждому классу доверия присвоено уникальное имя. Имя указывает на тематические разделы, на которые распространяется данный класс доверия.
Представлена также уникальная форма имени класса доверия. Она является основным средством для ссылки на класс доверия. Принятое условное обозначение включает в себя букву "А", за которой следуют еще две буквы латинского алфавита, относящиеся к имени класса.
2.1.1.2 Представление класса
Каждый класс доверия имеет вводный подраздел, в котором описаны состав и назначение класса.
2.1.1.3 Семейства доверия
Каждый класс доверия содержит по меньшей мере одно семейство доверия. Структура семейств доверия описана в следующем пункте.
2.1.2 Структура семейства доверия
Рисунок 2.1 иллюстрирует структуру семейства доверия.
2.1.2.1 Имя семейства
Каждому семейству доверия присвоено уникальное имя. Имя содержит описательную информацию по тематическим разделам, на которые распространяется данное семейство доверия. Каждое семейство доверия размещено в пределах класса доверия, который содержит другие семейства той же направленности.
Представлена также уникальная краткая форма имени семейства доверия. Она является основным средством для ссылки на семейство доверия. Принятое условное обозначение включает в себя краткую форму имени класса и символ подчеркивания, за которым следуют три буквы латинского алфавита, относящиеся к имени семейства.
2.1.2.2 Цели
Подраздел целей семейства доверия представляет назначение семейства доверия.
В нем описаны цели, для достижения которых предназначено семейство, особенно связанные с парадигмой доверия ГОСТ Р ИСО/МЭК 15408. Описание целей для семейства доверия представлено в общем виде. Любые конкретные подробности, требуемые для достижения целей, включены в конкретный компонент доверия.
2.1.2.3 Ранжирование компонентов
Каждое семейство доверия содержит один или несколько компонентов доверия. Этот подраздел семейства доверия содержит описание имеющихся компонентов и объяснение их разграничения. Его основная цель состоит в указании различий между компонентами при принятии решения о том, что семейство является необходимой или полезной частью требований доверия для ПЗ/ЗБ.
В семействах доверия, содержащих более одного компонента, выполнено ранжирование компонентов и приведено его обоснование. Это обоснование сформулировано в терминах области применения, глубины и/или строгости.
2.1.2.4 Замечания по применению
Необязательный подраздел замечаний по применению семейства доверия содержит дополнительную информацию о семействе. Эта информация предназначена непосредственно для пользователей семейства доверия (например, разработчиков ПЗ и ЗБ, проектировщиков ОО, оценщиков). Представление неформально и включает в себя, например, предупреждения об ограничениях использования или областях, требующих особого внимания.
2.1.2.5 Компоненты доверия
Каждое семейство содержит хотя бы один компонент доверия. Структура компонентов доверия представлена в следующем пункте.
2.1.3 Структура компонента доверия
Рисунок 2.2 иллюстрирует структуру компонента доверия.
Рисунок 2.2 - Структура компонента доверия
Связь между компонентами внутри семейства показана с использованием соглашения о шрифтовом выделении. Для частей требований, которые являются новыми, расширенными или модифицированными по сравнению с требованиями предыдущего по иерархии компонента, применен полужирный шрифт. Такое же соглашение о шрифтовом выделении использовано и для зависимостей.
2.1.3.1 Идентификация компонента
Подраздел идентификации компонента содержит описательную информацию, необходимую для идентификации, категорирования, регистрации и ссылок на компонент.
Каждому компоненту доверия присвоено уникальное имя. Имя содержит информацию о тематических разделах, на которые распространяется компонент доверия. Каждый компонент входит в состав конкретного семейства доверия, с которым имеет общую цель безопасности.
Представлена также уникальная краткая форма имени компонента доверия как основной способ ссылки на компонент. Принято, что за краткой формой имени семейства ставится точка, а затем цифра. Цифры для компонентов внутри каждого семейства назначены последовательно, начиная с единицы.
2.1.3.2 Цели
Необязательный подраздел целей компонента доверия содержит конкретные цели этого компонента. Для компонентов доверия, которые имеют этот подраздел, он включает в себя конкретное назначение данного компонента и подробное разъяснение целей.
2.1.3.3 Замечания по применению
Необязательный подраздел замечаний по применению компонента доверия содержит дополнительную информацию для облегчения использования компонента.
2.1.3.4 Зависимости
Зависимости среди компонентов доверия возникают, когда компонент не самодостаточен, а предполагает присутствие другого компонента.
Для каждого компонента доверия приведен полный список зависимостей от других компонентов доверия. При отсутствии у компонента идентифицированных зависимостей вместо списка указано: "Зависимости отсутствуют". Компоненты из списка могут, в свою очередь, иметь зависимости от других компонентов.
Список зависимостей определяет минимальный набор компонентов доверия, на которые следует полагаться. Компоненты, которые иерархичны по отношению к компоненту их списка зависимостей, также могут использоваться для удовлетворения зависимости.
В отдельных ситуациях обозначенные зависимости могут быть неприменимы. Разработчик ПЗ/ЗБ может отказаться от удовлетворения зависимости, представив обоснование, почему данная зависимость неприменима.
2.1.3.5 Элементы доверия
Каждый компонент доверия содержит набор элементов доверия. Элемент доверия - требование безопасности, при дальнейшем разделении которого не изменяется значимый результат оценки. Он является наименьшим требованием безопасности, распознаваемым в настоящем стандарте.
Каждый элемент доверия принадлежит к одному из трех типов.
а) Элементы действий разработчика, определяющие действия, которые должны выполняться разработчиком. Этот набор действий далее уточняется доказательным материалом, упоминаемым в следующем наборе элементов. Требования к действиям разработчика обозначены буквой "D" после номера элемента.
б) Элементы содержания и представления свидетельств, определяющие требуемые свидетельства и отражаемую в них информацию. Требования к содержанию и представлению свидетельств обозначены буквой "С" после номера элемента.
в) Элементы действий оценщика, определяющие действия, которые должны выполняться оценщиком. Этот набор действий непосредственно включает в себя подтверждение того, что требования, предписанные элементами содержания и представления свидетельств, выполнены, а также конкретные действия и анализ, выполняемые в дополнение к уже проведенным разработчиком. Должны также выполняться не указанные явно действия оценщика, необходимые вследствие элементов действий разработчика, но не охваченные в требованиях к содержанию и представлению свидетельств. Требования к действиям оценщика обозначены буквой "Е" после номера элемента.
Действия разработчика, содержание и представление свидетельств определяют требования, предъявляемые к разработчику по демонстрации доверия к ФБО. Выполняя эти требования, разработчик может повысить уверенность в том, что ОО удовлетворяет функциональным требованиям и требованиям доверия из ПЗ или ЗБ.
Действия оценщика определяют его ответственность по двум аспектам. Первый аспект - проверка правильности ПЗ/ЗБ в соответствии с требованиями классов APE/ASE из разделов 4 и 5. Второй аспект - верификация соответствия ОО его функциональным требованиям и требованиям доверия. Демонстрируя, что ПЗ/ЗБ правильны, и их требования выполняются ОО, оценщик может предоставить основание для уверенности в том, что ОО будет отвечать поставленным целям безопасности.
Элементы действий разработчика, элементы содержания и представления свидетельств и элементы установленных действий оценщика определяют уровень его усилий, которые должны быть приложены при верификации утверждений о безопасности, сформулированных в ЗБ конкретного ОО.
2.1.4 Элементы доверия
Каждый элемент представляет собой требование для выполнения. Формулировки этих требований должны быть четкими, краткими и однозначными. Поэтому в требованиях отсутствуют составные предложения. Каждое требование изложено как отдельный элемент.
В тексте элементов использованы, как правило, термины, имеющие обычное словарное значение, которые не могут привести к неоднозначному толкованию требований.
В отличие от функциональных элементов из ГОСТ Р ИСО/МЭК 15408-2 к элементам доверия из настоящего стандарта не применимы операции назначения и выбора; однако, при необходимости, допустимо применение операции уточнения.
2.1.5 Структура ОУД
Рисунок 2.3 иллюстрирует ОУД и их структуру, определенную в настоящем стандарте. Компоненты доверия, содержание которых показано на рисунке, включены в ОУД посредством ссылок на компоненты, приведенные в настоящем стандарте.
Рисунок 2.3 - Структура ОУД
2.1.5.1 Имя ОУД
Каждому ОУД присвоено уникальное имя. Имя представляет описательную информацию о предназначении ОУД.
Представлена также уникальная краткая форма имени ОУД. Она является основным средством ссылки на ОУД.
2.1.5.2 Цели
В подразделе целей ОУД приведено назначение ОУД.
2.1.5.3 Замечания по применению
Необязательный подраздел замечаний по применению ОУД содержит информацию, представляющую интерес для пользователей ОУД (например, для разработчиков ПЗ и ЗБ, проектировщиков ОО, планирующих использование этого ОУД, оценщиков). Представление неформально и включает в себя, например, предупреждения об ограничениях использования или областях, требующих особого внимания.
2.1.5.4 Компоненты доверия
Для каждого ОУД выбран набор компонентов доверия.
Более высокий уровень доверия, чем предоставляемый данным ОУД, может быть достигнут:
а) включением дополнительных компонентов доверия из других семейств доверия;
б) заменой компонента доверия иерархичным компонентом из этого же семейства доверия.
2.1.6 Связь между требованиями и уровнями доверия
Рисунок 2.4 иллюстрирует связь между требованиями и уровнями доверия, определенными в настоящем стандарте. Компоненты доверия состоят из элементов, но последние не могут по отдельности быть включены в уровни доверия. Стрелка на рисунке отображает ссылку в ОУД на компонент доверия внутри класса, где он определен.
Рисунок 2.4 - Связь требований и уровня доверия
2.2 Классификация компонентов
Настоящий стандарт содержит классы семейств и компонентов, которые сгруппированы на основе, связанной с доверием. В начале каждого класса представлена диаграмма, которая указывает семейства в классе и компоненты в каждом семействе.
На рисунке 2.5 показан класс, содержащий одно семейство. Семейство содержит три компонента, которые являются линейно иерархичными (т.е. компонент 2 содержит более высокие требования, чем компонент 1, к конкретным действиям, приводимым свидетельствам или строгости действий и/или свидетельств). Все семейства доверия в настоящем стандарте - линейно иерархичные, хотя линейность не обязательна для семейств доверия, которые могут быть добавлены в дальнейшем.
Рисунок 2.5 - Образец декомпозиции класса
2.3 Структура класса критериев оценки профиля защиты и задания по безопасности
Требования для оценки профиля защиты и задания по безопасности трактуют как классы доверия, структура которых подобна структуре других классов доверия, описанных ниже. Отличие заключается в отсутствии подраздела ранжирования компонентов в описаниях семейств и вызвано тем, что каждое семейство имеет только один компонент.
В таблицах 3.1-3.4 приведены названия каждого из классов АРЕ И ASE, составляющих их семейств и их краткие имена. Содержание разделов ПЗ, рассматриваемых в семействах класса АРЕ, представлено в ГОСТ Р ИСО/МЭК 15408-1, приложение Б, подразделы Б.2.2-Б.2.6, а разделов ЗБ, рассматриваемых в семействах класса ASE, - в ГОСТ Р ИСО/МЭК 15408-1, приложение В, подразделы В.2.2-В.2.8.
2.4 Использование терминов в настоящем стандарте
В настоящем стандарте определенным образом используются термины, список которых приведен ниже. Они не включены в глоссарий ГОСТ Р ИСО/МЭК 15408 (раздел 2 ГОСТ Р ИСО/МЭК 15408-1), потому что являются общеупотребительными терминами, и их использование, хотя и ограничено приведенными разъяснениями, согласуется со словарными определениями. Однако именно такое толкование терминов применялось при разработке настоящего стандарта, и поэтому оно полезно для понимания. В скобках приведены эквиваленты терминов на английском языке.
верифицировать (verify): Аналогичен термину "подтверждать" ("confirm"), но имеет более глубокий смысл. При использовании в контексте действий оценщика указывает, что требуются независимые усилия оценщика.
взаимно поддерживающие (mutually supportive): Описывает взаимосвязь в группе сущностей, указывая, что последние обладают некоторыми свойствами, которые не находятся в противоречии со свойствами других сущностей и могут способствовать выполнению другими сущностями их задач. Нет необходимости определять, что каждая из рассматриваемых отдельных сущностей непосредственно поддерживает другие сущности в этой группе; достаточно, если сделано обобщенное заключение.
внутренне непротиворечивый (internally consistent): Отсутствуют очевидные противоречия между любыми аспектами сущности. Применительно к документации это означает, что в ней не может быть изложено что-либо, что может быть воспринято как противоречащее чему-то другому.
делать (независимое) заключение (determine): Требуется независимый анализ для достижения конкретного заключения. Термин отличается от "подтверждать" ("confirm") или "верифицировать" ("verify"), так как последние подразумевают, что требует проверки анализ, приведенный ранее, в то время как "делать (независимое) заключение" подразумевает совершенно независимый анализ, обычно при отсутствии любого предшествующего анализа.
демонстрировать (demonstrate): Относится к анализу, который приводит к заключению, но является менее строгим, чем "доказательство" ("proof").
доказывать (prove): Относится к формальному анализу в математическом смысле, полностью строгий во всех отношениях. Обычно используется, когда желательно показать соответствие между двумя представлениями ФБО на высоком уровне строгости.
исчерпывающий (exhaustive): Используется применительно к проведению анализа или другой деятельности. Аналогичен термину "систематический" ("systematic"), но более точен, так как указывает не только на то, что в соответствии с некоторым конкретным планом проведения анализа или другой деятельности был применен методический подход, но также и на то, что этот план достаточен для обеспечения проведения исследования по всем возможным направлениям.
логически упорядоченный (coherent): Сущность логически упорядочена и имеет очевидный смысл. Применительно к документации этот термин относится как к тексту, так и к структуре, указывая, что они понятны потенциальной аудитории.
непротиворечивый (consistent): Описывает связь между двумя или более сущностями, указывая, что между ними нет никаких явных противоречий.
обеспечивать (ensure): Подразумевает сильную причинно-следственную связь между некоторым действием и его последствиями. Часто ему предшествует термин "способствует" ("helps"), указывающий, что одно данное действие не полностью определяет последствия.
объяснять (explain): Отличается от терминов "описывать" ("describe") и "демонстрировать" ("demonstrate"). Предназначен для ответа на вопрос "Почему?" без попытки аргументировать, что ход предпринимаемых действий обязательно оптимален.
описывать (describe): Требует, чтобы некоторые конкретные подробности сущности были представлены.
подтверждать (confirm): используется для указания необходимости подробного рассмотрения чего-либо; при этом требуется независимое заключение о его достаточности. Требуемый уровень строгости зависит от характера предмета. Применим только к действиям оценщика.
полный (complete): Представлены все необходимые составляющие сущности. Применительно к документации это означает, что приведена вся необходимая информация, причем настолько детально, что на данном уровне абстракции дальнейшие пояснения не требуются.
проверять (check): Аналогичен, но менее строг, чем "подтверждать" ("confirm") или "верифицировать" ("verify"). Требует, чтобы оценщиком было сделано оперативное заключение, возможно лишь с поверхностным анализом или вообще без него.
прослеживать или сопоставлять (trace): Используется для указания, что между двумя сущностями требуется только минимальный уровень строгости неформального соответствия.
противостоять (counter): Используется в том смысле, что некоторая цель безопасности заключается в противостоянии конкретной угрозе, но не обязательно указывает в итоге на полную ее ликвидацию.
специфицировать или определять (specify): Используется в том же контексте, что и "описывать" ("describe"), но является более строгим и точным. Аналогичен термину "определять" ("define").
строгое обоснование (justification): Относится к анализу, ведущему к заключению, но является более строгим, чем термин "демонстрация" ("demonstration"), в смысле точных и подробных объяснений каждого шага логических суждений.
2.5 Классификация доверия
Классы и семейства доверия, а также их краткие имена приведены в таблице 2.1.
Таблица 2.1 - Семейства доверия
Класс доверия | Семейство доверия | Краткое имя |
АСМ Управление конфигурацией | Автоматизация УК | АСМ_AUT |
| Возможности УК
| АСМ_САР |
| Область УК | АСМ_SCP |
ADO Поставка и эксплуатация | Поставка | ADO_DEL |
| Установка, генерация и запуск
| ADO_IGS |
ADV Разработка | Функциональная спецификация | ADV_FSP |
| Проект верхнего уровня | ADV_HLD |
| Представление реализации | ADV_IMP |
| Внутренняя структура ФБО | ADV_INT |
| Проект нижнего уровня | ADV_LLD |
| Соответствие представлений | ADV_RCR |
| Моделирование политики безопасности | ADV_SPM |
AGD Руководства | Руководство администратора | AGD_ADM |
| Руководство пользователя
| AGD_USR |
ALC Поддержка жизненного цикла | Безопасность разработки | ALC_DVS |
| Устранение недостатков
| ALC_FLR |
| Определение жизненного цикла
| ALC_LCD |
| Инструментальные средства и методы
| ALC_TAT |
ATE Тестирование | Покрытие | ATE_COV |
| Глубина
| ATE_DPT |
| Функциональное тестирование
| ATE_FUN |
| Независимое тестирование | ATE_IND |
AVA Оценка уязвимостей | Анализ скрытых каналов | AVA_CCA |
| Неправильное применение
| AVA_MSU |
| Стойкость функций безопасности ОО
| AVA_SOF |
| Анализ уязвимостей | AVA_VLA |
2.6 Краткий обзор классов и семейств доверия
Ниже приведены краткие характеристики классов и семейств доверия из разделов 8-14.
2.6.1 Класс АСМ: Управление конфигурацией
Управление конфигурацией (УК) помогает обеспечить сохранение целостности ОО, устанавливая и контролируя определенный порядок процессов уточнения и модификации ОО и предоставления связанной с ними информации. УК предотвращает несанкционированную модификацию, добавление или уничтожение составляющих ОО, обеспечивая тем самым доверие, что оцениваются именно те ОО и документация, которые подготовлены к распространению.
2.6.1.1 Автоматизация УК (ACM_AUT)
Семейство "Автоматизация управления конфигурацией" устанавливает уровень автоматизации, используемый для управления элементами конфигурации.
2.6.1.2 Возможности УК (АСМ_САР)
Семейство "Возможности управления конфигурацией" определяет характеристики системы управления конфигурацией.
2.6.1.3 Область УК (ACM_SCP)
Семейство "Область управления конфигурацией" указывает на те элементы ОО, для которых необходим контроль со стороны системы управления конфигурацией.
2.6.2 Класс ADO. Поставка и эксплуатация
Класс доверия ADO определяет требования к мерам, процедурам и стандартам, применяемым для безопасной поставки, установки и эксплуатации ОО, обеспечивая, чтобы безопасность ОО не нарушалась во время его распространения, установки и эксплуатации.
2.6.2.1 Поставка (ADO_DEL)
Семейство "Поставка" распространяется на процедуры, используемые для поддержки безопасности во время передачи ОО пользователю при первоначальной поставке и последующих модификациях. Оно включает в себя специальные процедуры или действия, необходимые для демонстрации подлинности поставленного ОО. Такие процедуры и меры - основа обеспечения безопасности ОО во время передачи. Несмотря на то, что при оценке ОО не всегда может быть определено его соответствие требованиям поставки, можно оценить процедуры, предусмотренные разработчиком для распространения ОО пользователям.
2.6.2.2 Установка, генерация и запуск (ADO_IGS)
Семейство "Установка, генерация и запуск" предусматривает, чтобы копия ОО была конфигурирована и активизирована администратором так, чтобы показать те же самые свойства защиты, что и у оригинала ОО. Процедуры установки, генерации и запуска предоставляют уверенность в том, что администратор будет осведомлен о параметрах конфигурации ОО и о том, как они способны повлиять на ФБО.
2.6.3 Класс ADV. Разработка
Класс доверия ADV определяет требования для пошагового уточнения ФБО, начиная с краткой спецификации ОО в ЗБ и вплоть до фактической реализации. Каждое из получаемых представлений ФБО содержит информацию, помогающую оценщику решить, были ли выполнены функциональные требования к ОО.
2.6.3.1 Функциональная спецификация (ADV_FSP)
Функциональная спецификация описывает ФБО, и необходимо, чтобы она была полным и точным отображением функциональных требований безопасности ОО. Функциональная спецификация также детализирует внешний интерфейс ОО. Предполагают, что пользователи ОО взаимодействуют с ФБО через этот интерфейс.
2.6.3.2 Проект верхнего уровня (ADV_HLD)
Проект верхнего уровня - проектная спецификация самого высокого уровня, которая уточняет функциональную спецификацию ФБО в основных составляющих частях ФБО. Проект верхнего уровня идентифицирует базовую структуру ФБО, а также основные элементы аппаратных, программных и программно-аппаратных средств.
2.6.3.3 Представление реализации (ADV_IMP)
Представление реализации - наименее абстрактное представление ФБО. Оно фиксирует детализированное внутреннее содержание ФБО на уровне исходного текста, аппаратных схем и т.д.
2.6.3.4 Внутренняя структура ФБО (ADV_INT)
Требования к внутренней структуре ФБО определяют необходимое внутреннее структурирование ФБО.
2.6.3.5 Проект нижнего уровня (ADV_LLD)
Проект нижнего уровня - детализированная проектная спецификация, уточняющая проект верхнего уровня до уровня детализации, который может быть использован как основа для программирования и/или проектирования аппаратуры.
2.6.3.6 Соответствие представлений (ADV_RCR)
Соответствие представлений - демонстрация отображения между всеми смежными парами имеющихся представлений ФБО, от краткой спецификации ОО до наименее абстрактного из имеющихся представлений ФБО.
2.6.3.7 Моделирование политики безопасности (ADV_SPM)
Модели политики безопасности - структурные представления политик безопасности ПБО, используемые для обеспечения повышенного доверия, что функциональная спецификация соответствует политикам безопасности из ПБО и, в конечном счете, функциональным требованиям безопасности ОО. Это достигается посредством определения соответствия между функциональной спецификацией, моделью политики безопасности и моделируемыми политиками безопасности.
2.6.4 Класс AGD. Руководства
Класс доверия AGD определяет требования, направленные на обеспечение понятности, достаточности и законченности эксплуатационной документации, представляемой разработчиком. Эта документация, которая содержит две категории информации (для пользователей и администраторов), является важным фактором безопасной эксплуатации ОО.
2.6.4.1 Руководство администратора (AGD_ADM)
Требования к руководству администратора способствуют обеспечению, что ограничения среды будут поняты администраторами и операторами ОО. Руководство администратора - основное средство, имеющееся в распоряжении разработчика, для предоставления администраторам ОО детальной и точной информации о том, как осуществлять администрирование ОО безопасным способом и эффективно использовать привилегии ФБО и функции защиты.
2.6.4.2 Руководство пользователя (AGD_USP)
Требования к руководству пользователя способствуют обеспечению, что пользователи могут эксплуатировать ОО безопасным способом (например, ограничения использования, предусмотренные ПЗ или ЗБ, необходимо четко объяснить и проиллюстрировать). Руководство - основное средство, имеющееся в распоряжении разработчика, для предоставления пользователям ОО необходимой общей и специфической информации о том, как правильно использовать функции защиты ОО. В руководстве необходимо осветить два аспекта. Во-первых, требуется объяснить, что делают доступные пользователю функции безопасности и как они будут использоваться, чтобы пользователи имели возможность последовательно и действенно защищать свою информацию. Во-вторых, требуется разъяснить роль пользователя в поддержании безопасности ОО.
2.6.5 К ласе ALС. Поддержка жизненного цикла
Класс доверия ALC определяет требования доверия посредством принятия для всех этапов разработки ОО четко определенной модели жизненного цикла, включая политики и процедуры устранения недостатков, правильное использование инструментальных средств и методов, а также меры безопасности для защиты среды разработки.
2.6.5.1 Безопасность разработки (ALC_DVS)
Семейство "Безопасность разработки" охватывает физические, процедурные, относящиеся к персоналу и другие меры безопасности, используемые применительно к среде разработки. Оно также содержит требования к физической безопасности местоположения разработки и к контролю за отбором и наймом персонала разработчиков.
2.6.5.2 Устранение недостатков (ALC_FLR)
Семейство "Устранение недостатков" обеспечивает, чтобы недостатки, обнаруженные потребителями ОО, отслеживались и исправлялись, пока ОО сопровождается разработчиком. Несмотря на то, что при оценке ОО не может быть принято решение о потенциальном соответствии требованиям устранения недостатков, можно оценить политики и процедуры, которые разработчик предусмотрел для выявления и устранения недостатков и распространения исправлений потребителям.
2.6.5.3 Определение жизненного цикла (ALC_LCD)
Семейство "Определение жизненного цикла" устанавливает, что технология разработки, используемая разработчиком для создания ОО, включает в себя положения и действия, указанные в требованиях к процессу разработки и поддержке эксплуатации. Уверенность в соответствии ОО требованиям больше, когда анализ безопасности и подготовка свидетельств осуществляются на регулярной основе как неотъемлемая часть процесса разработки и поддержки эксплуатации. В задачи этого семейства не входит предопределение какого-либо конкретного процесса разработки.
2.6.5.4 Инструментальные средства и методы (ALC_TAT)
Семейство "Инструментальные средства и методы" связано с необходимостью определения инструментальных средств разработки, используемых для анализа и создания ОО. Сюда включены требования, относящиеся к инструментальным средствам разработки и опциям этих инструментальных средств, зависящим от реализации.
2.6.6 Класс ATE. Тестирование
Класс доверия ATE устанавливает требования к тестированию, которое демонстрирует, что ФБО удовлетворяют функциональным требованиям безопасности ОО.
2.6.6.1 Покрытие (ATE_COV)
Семейство "Покрытие" имеет дело с полнотой функциональных тестов, выполненных разработчиком для ОО. Оно связано со степенью тестирования функций безопасности ОО.
2.6.6.2 Глубина (ATE_DPT)
Семейство "Глубина" имеет дело с уровнем детализации, на котором разработчик проверяет ОО. Тестирование функций безопасности основано на увеличивающейся глубине информации, получаемой из анализа представлений ФБО.
2.6.6.3 Функциональное тестирование (ATE_FUN)
Семейство "Функциональное тестирование" устанавливает, что ФБО действительно демонстрируют свойства, необходимые для удовлетворения требований своего ЗБ. Функциональное тестирование обеспечивает доверие, что ФБО удовлетворяют по меньшей мере требованиям выбранных функциональных компонентов. Однако функциональные тесты не устанавливают, что ФБО не выполняют больше, чем от них ожидается. Это семейство сосредоточено на функциональном тестировании, выполняемом разработчиком.
2.6.6.4 Независимое тестирование (ATE_IND)
Семейство "Независимое тестирование" определяет степень выполнения функционального тестирования ОО кем-либо, кроме разработчика (например, третьей стороной). Это семейство повышает ценность тестирования добавлением тестов, которые дополняют тесты разработчика.
2.6.7 Класс AVA. Оценка уязвимостей.
Класс доверия AVA определяет требования, направленные на идентификацию уязвимостей, которые могут быть активизированы. Особое внимание уделено уязвимостям, которые вносятся при проектировании, эксплуатации, неправильном применении или неверной конфигурации ОО.
2.6.7.1 Анализ скрытых каналов (AVA_CCA)
Семейство "Анализ скрытых каналов" направлено на выявление и анализ непредусмотренных коммуникационных каналов, которые могут применяться для нарушения предписанной ПБО.
2.6.7.2 Неправильное применение (AVA_MSU)
Семейство "Анализ неправильного применения" позволяет выяснить, способен ли администратор или пользователь, используя руководства, определить, что ОО конфигурирован или эксплуатируется небезопасным способом.
2.6.7.3 Стойкость функций безопасности ОО (AVA_SOF)
Анализ стойкости направлен на функции безопасности ОО, которые реализованы с помощью вероятностного или перестановочного механизма (например, пароля или хэш-функции). Даже если такие функции нельзя обойти, отключить или исказить, не исключено, что их все же можно преодолеть прямой атакой. Может быть заявлен уровень или специальная метрика стойкости для каждой из этих функций. Анализ стойкости функций выполняют для принятия решения, отвечают ли такие функции сделанным заявлениям. Например, анализ стойкости механизма пароля может, показав достаточность области задания пароля, продемонстрировать, что функция, использующая этот механизм, отвечает заявленной стойкости.
2.6.7.4 Анализ уязвимостей (AVA_VLA)
Анализ уязвимостей заключается в идентификации недостатков, которые могли быть внесены на различных этапах разработки. В результате определяются тесты проникновения, позволяющие получить всю совокупность необходимой информации относительно:
1) полноты ФБО (противостоят ли ФБО всем ожидаемым угрозам?);
2) зависимостей между всеми функциями безопасности.
Эти потенциальные уязвимости оценивают посредством тестирования проникновения, позволяющим сделать заключение, могут ли они в действительности быть использованы для нарушения безопасности ОО.
2.7 Классификация поддержки
Требования по поддержке доверия, трактуемые как класс доверия, представлены с использованием структуры класса, определенной выше.
Таблица 2.2 - Декомпозиция класса АМА "Поддержка доверия"
Класс | Семейство доверия | Краткое имя |
АМА Поддержка доверия | План поддержки доверия | АМА_АМР |
| Отчет о категорировании компонентов ОО | АМА_CAT |
| Свидетельство поддержки доверия | АМА_EVD |
| Анализ влияния на безопасность | AMA_SIA |
2.8 Краткий обзор класса и семейства поддержки доверия
Ниже приведены краткие характеристики класса и семейств поддержки доверия из раздела 16.
2.8.1 Класс АМА. Поддержка доверия
Класс АМА предназначен для поддержки уровня доверия, что ОО продолжит отвечать своему ЗБ при изменениях в ОО или его среде. Каждое из семейств этого класса определяет действия разработчика и оценщика, выполняемые после того, как ОО был успешно оценен, хотя некоторые требования применимы и при оценке.
1.1.1.1* План поддержки доверия (АМА_АМР)
Семейство "План поддержки доверия" идентифицирует планы и процедуры, которые выполняет разработчик для обеспечения поддержки доверия, установленного к оцененному ОО, после изменений в ОО или его среде.
2.8.1.2 Отчет о категорировании компонентов ОО (АМА_САТ)
Семейство "Отчет о категорировании компонентов ОО" представляет категорирование компонентов ОО (например, подсистем ФБО) по их отношению к безопасности. Это категорирование занимает центральное место в анализе разработчиком влияния на безопасность.
2.8.1.3 Свидетельство поддержки доверия (AMA_EVD)
Семейство "Свидетельство поддержки доверия" направлено на то, чтобы убедиться в поддержке разработчиком доверия к ОО в соответствии с планом поддержки доверия.
2.8.1.4 Анализ влияния на безопасность (AMA_SIA)
Семейство "Анализ влияния на безопасность" направлено на то, чтобы убедиться в поддержке доверия к ОО посредством проводимого разработчиком анализа влияния на безопасность ОО всех изменений после его оценки.
3 Критерии оценки профиля защиты и задания по безопасности
3.1 Краткий обзор
Настоящий раздел знакомит с критериями оценки для ПЗ и ЗБ, полностью представленными в классах АРЕ "Оценка профиля защиты" и ASE "Оценка задания по безопасности" (разделы 4 и 5 соответственно).
Эти критерии - первые требования оценки, представленные в настоящем стандарте, потому что, как правило, оценку ПЗ и ЗБ выполняют до оценки ОО. Они играют особую роль в оценке информации об ОО и оценке функциональных требований и требований доверия для выяснения, являются ли ПЗ и ЗБ содержательной основой для оценки ОО.
Хотя данные критерии оценки несколько отличаются от требований в разделах 8-14, они представлены аналогичным образом, потому что действия разработчика и оценщика при оценке сопоставимы для ПЗ, ЗБ и ОО.
Классы для ПЗ и ЗБ отличаются от классов для ОО тем, что при оценке ПЗ или ЗБ необходимо учесть все требования классов для ПЗ или ЗБ соответственно, в то время как далеко не все требования, представленные в классах для ОО, придется учитывать при оценке конкретного ОО.
Критерии оценки для ПЗ и ЗБ основаны на информации, приведенной в приложениях Б и В ГОСТ Р ИСО/МЭК 15408-1. Там можно найти полезную информацию о происхождении требований классов АРЕ и ASE.
3.2 Краткий обзор критериев профиля защиты
3.2.1 Оценка профиля защиты
Цель оценки ПЗ - показать, что он является полным, непротиворечивым, технически правильным и поэтому пригоден для изложения требований к одному или нескольким оцениваемым ОО. Такой ПЗ может быть приемлем для включения в реестр ПЗ.
3.2.2 Соотношение с критериями оценки задания по безопасности
Как показано в приложениях Б и В ГОСТ Р ИСО/МЭК 15408-1, имеется много совпадений в структуре и содержании ПЗ, ориентированного на определенный тип ОО, и ЗБ, разработанного для конкретного ОО. Поэтому многие критерии для оценки ПЗ содержат требования, которые подобны аналогичным для ЗБ и представлены таким же образом.
3.2.3 Задачи оценщика
Оценщики ПЗ, который содержит требования только из ГОСТ Р ИСО/МЭК 15408, должны применять требования класса АРЕ, приведенные в таблице 3.1.
Таблица 3.1 - Семейства оценки профиля защиты, содержащего требования только из ГОСТ Р ИСО/МЭК 15408
Класс | Семейство | Краткое имя |
АРЕ Оценка профиля защиты | Профиль защиты, описание ОО | АРЕ_DES |
| Профиль защиты, среда безопасности | АРЕ_ENV |
| Профиль защиты, введение ПЗ | АРЕ_INT |
| Профиль защиты, цели безопасности | APE_OBJ |
| Профиль защиты, требования безопасности ИТ | APE_REQ |
Оценщики ПЗ, который содержит требования не из ГОСТ Р ИСО/МЭК 15408, должны применять требования класса АРЕ, приведенные в таблице 3.2.
Таблица 3.2 - Семейства оценки профиля защиты с требованиями, расширяющими ГОСТ Р ИСО/МЭК 15408
Класс | Семейство | Краткое имя |
АРЕ Оценка профиля защиты | Профиль защиты, описание ОО | АРЕ_DES |
| Профиль защиты, среда безопасности | АРЕ_ENV |
| Профиль защиты, введение ПЗ | АРЕ_INT |
| Профиль защиты, цели безопасности | APE_OBJ |
| Профиль защиты, требования безопасности ИТ | APE_REQ |
| Профиль защиты, требования безопасности ИТ, сформулированные в явном виде
| APE_SRE |
3.3 Краткий обзор критериев задания по безопасности
3.3.1 Оценка задания по безопасности
Цель оценки ЗБ - показать, что оно является полным, непротиворечивым, технически правильным и поэтому пригодно для использования в качестве основы при оценке соответствующего ОО.
3.3.2 Соотношение с другими критериями оценки из настоящего стандарта
При оценке ОО различают две стадии: оценка ЗБ и непосредственно оценка ОО, к которому относится данное ЗБ. Требования для оценки ЗБ полностью представлены в разделе 5, а требования для оценки ОО содержатся в разделах 8-14.
Оценка ЗБ включает в себя оценку утверждений о соответствии ПЗ. Если в ЗБ не утверждается соответствие ПЗ, то в части ЗБ "Утверждения о соответствии ПЗ" должно быть указано, что соответствие какому-либо ПЗ для ОО не утверждается.
3.3.3 Задачи оценщика
Оценщики ЗБ, которое содержит требования только из ГОСТ Р ИСО/МЭК 15408, должны применять требования класса ASE, приведенные в таблице 3.3.
Таблица 3.3 - Семейства оценки задания по безопасности, содержащего требования только из ГОСТ Р ИСО/МЭК 15408
Класс | Семейство | Краткое имя |
ASE Оценка задания по безопасности | Задание по безопасности, описание ОО | ASE_DES |
| Задание по безопасности, среда безопасности | ASE_ENV |
| Задание по безопасности, введение ЗБ | ASE_INT |
| Задание по безопасности, цели безопасности | ASE_OBJ |
| Задание по безопасности, утверждения о соответствии ПЗ | ASE_PPC |
| Задание по безопасности, требования безопасности ИТ | ASE_REQ |
| Задание по безопасности, краткая спецификация ОО | ASE_TSS |
Оценщики ЗБ, которое содержит требования не из ГОСТ Р ИСО/МЭК 15408, должны применять требования класса ASE, приведенные в таблице 3.4.
Таблица 3.4 - Семейства оценки задания по безопасности с требованиями, расширяющими ГОСТ Р ИСО/МЭК 15408
Класс | Семейство | Краткое имя |
ASE Оценка задания по безопасности | Задание по безопасности, описание ОО | ASE_DES |
| Задание по безопасности, среда безопасности | ASE_ENV |
| Задание по безопасности, введение ЗБ | ASE_INT |
| Задание по безопасности, цели безопасности | ASE_OBJ |
| Задание по безопасности, утверждения о соответствии ПЗ | ASE_PPC |
| Задание по безопасности, требования безопасности ИТ | ASE_REQ |
| Задание по безопасности, требования безопасности ИТ, сформулированные в явном виде | ASE_SRE |
| Задание по безопасности, краткая спецификация ОО | ASE_TSS |
4 Класс АРЕ. Оценка профиля защиты
Цель оценки ПЗ состоит в демонстрации, что ПЗ является полным, непротиворечивым и технически правильным. Оцененный ПЗ пригоден в качестве основы для разработки заданий по безопасности. Такой ПЗ приемлем для включения в реестр ПЗ.
На рисунке 4.1 показаны семейства этого класса.
Рисунок 4.1 - Декомпозиция класса "Оценка профиля защиты"
4.1 Описание ОО (APE_DES)
Цели
Описание ОО способствует пониманию требований безопасности ОО. Оценка описания ОО требуется, чтобы показать, что оно является логически последовательным, внутренне непротиворечивым и согласованным со всеми другими частями ПЗ.
APE_DES.1. Профиль защиты, описание ОО, требования оценки
| |||
Зависимости
| |||
APE_ENV.1
| Профиль защиты, среда безопасности, требования оценки | ||
APE_INT.1
| Профиль защиты, введение ПЗ, требования оценки | ||
APE_OBJ.1
| Профиль защиты, цели безопасности, требования оценки | ||
APE_REQ.1
| Профиль защиты, требования безопасности ИТ, требования оценки
| ||
Элементы действий разработчика | |||
APE_DES.1.1D
| Разработчик ПЗ должен представить описание ОО как часть ПЗ. | ||
Элементы содержания и представления свидетельств | |||
APE_DES.1.1C
| Описание ОО, как минимум, должно включать в себя тип продукта и общие свойства ИТ, присущие ОО. | ||
Элементы действий оценщика | |||
APE_DES.1.1E | Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. | ||
APE_DES.1.2E
| Оценщик должен подтвердить, что описание ОО является логически последовательным и внутренне непротиворечивым. | ||
APE_DES.1.3E | Оценщик должен подтвердить, что описание ОО согласуется с другими частями ПЗ. | ||
4.2 Среда безопасности (APE_ENV)
Цели
Для принятия решения о достаточности требований безопасности ИТ в ПЗ важно, чтобы решаемая задача безопасности ясно понималась всеми участниками оценки.
APE_ENV.1 Профиль защиты, среда безопасности, требования оценки
| |
Зависимости отсутствуют
| |
Элементы действий разработчика
| |
APE_ENV.1.1D
| Разработчик ПЗ должен представить изложение среды безопасности ОО как часть ПЗ. |
Элементы содержания и представления свидетельств
| |
APE_ENV.1.1C
| Изложение среды безопасности ОО должно идентифицировать и объяснить любые предположения о предполагаемом применении ОО и среде использования ОО. |
APE_ENV.1.2C
| Изложение среды безопасности ОО должно идентифицировать и объяснить любые известные или допускаемые угрозы активам, от которых будет требоваться защита посредством ОО или его среды. |
APE_ENV.1.3C
| Изложение среды безопасности ОО должно идентифицировать и объяснить каждую политику безопасности организации, соответствие которой для ОО необходимо. |
Элементы действий оценщика
| |
APE_ENV.1.1E | Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. |
APE_ENV.1.2E | Оценщик должен подтвердить, что описание среды безопасности ОО является логически последовательным и внутренне непротиворечивым. |
4.3 Введение ПЗ (APE_INT)
Цели
Введение ПЗ содержит информацию для управления документооборотом и обзорную информацию о документе, необходимую для сопровождения реестра ПЗ. Оценка введения ПЗ требуется для демонстрации, что ПЗ правильно идентифицирован и введение согласуется со всеми другими частями ЗБ.
APE_INT.1 Профиль защиты, введение ПЗ, требования оценки
| |||
Зависимости
| |||
APE_DES.1
| Профиль защиты, описание ОО, требования оценки | ||
APE_ENV.1
| Профиль защиты, среда безопасности, требования оценки | ||
APE_ODJ.1
| Профиль защиты, цели безопасности, требования оценки | ||
APE_REQ.1
| Профиль защиты, требования безопасности ИТ, требования оценки | ||
Элементы действий разработчика | |||
APE_INT.1.1D
| Разработчик ПЗ должен представить введение ПЗ как часть ПЗ. | ||
Элементы содержания и представления свидетельств | |||
APE_INT.1.1C | Введение ПЗ должно содержать данные идентификации ПЗ, которые предоставляют маркировку и описательную информацию, необходимые для идентификации, каталогизации, регистрации ПЗ и ссылок на него. | ||
APE_INT.1.2C | Введение ПЗ должно содержать аннотацию ПЗ с общей характеристикой ПЗ в описательной форме. | ||
Элементы действий оценщика | |||
APE_INT.1.1E
| Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. | ||
APE_INT.1.2E
| Оценщик должен подтвердить, что введение ПЗ является логически последовательным и внутренне непротиворечивым. | ||
APE_INT.1.3E | Оценщик должен подтвердить, что введение ПЗ согласуется с другими частями ПЗ. | ||
4.4 Цели безопасности (APE_OBJ)
Цели
Цели безопасности - краткое изложение предполагаемой реакции на задачу безопасности. Оценка целей безопасности требуется для демонстрации, что установленные цели адекватны проблеме безопасности. Существуют цели безопасности для ОО и цели безопасности для среды. Необходимо сопоставить цели безопасности для ОО и среды с идентифицированными угрозами, которым они противостоят, и/или с политикой и предположениями, которым они соответствуют
APE_OBJ.1 Профиль защиты, цели безопасности, требования оценки
| |
Зависимости
| |
APE_ENV.1 Профиль защиты, среда безопасности, требования оценки
| |
Элементы действий разработчика
| |
APE_OBJ.1.1D | Разработчик ПЗ должен представить изложение целей безопасности как часть ПЗ. |
APE_OBJ.1.2D | Разработчик ПЗ должен представить логическое обоснование целей безопасности. |
Элементы содержания и представления свидетельств
| |
APE_OBJ.1.1C | Изложение целей безопасности должно определить цели безопасности для ОО и его среды. |
APE_OBJ.1.2C | Цели безопасности для ОО должны быть четко изложены и сопоставлены с идентифицированными угрозами, которым будет противостоять ОО, и/или с политикой безопасности организации, которая будет выполняться ОО. |
APE_OBJ.1.3C | Цели безопасности для среды должны быть четко изложены и сопоставлены с теми аспектами идентифицированных угроз, которым ОО противостоит не полностью, и/или с политикой безопасности организации или предположениями, не полностью выполняемыми ОО. |
APE_OBJ.1.4C | Логическое обоснование целей безопасности должно демонстрировать, что изложенные цели безопасности пригодны для противостояния всем идентифицированным угрозам безопасности. |
APE_OBJ.1.5C | Логическое обоснование целей безопасности должно демонстрировать, что изложенные цели безопасности пригодны для охвата всех установленных положений политики безопасности организации и предположений. |
Элементы действий оценщика
| |
APE_OBJ.1.1E | Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. |
APE_OBJ.1.2E | Оценщик должен подтвердить, что описание целей безопасности является полным, логически последовательным и внутренне непротиворечивым. |
4.5 Требования безопасности ИТ (APE_REQ)
Цели
Требования безопасности ИТ, выбранные для ОО и представленные или указанные в ПЗ, необходимо оценить для подтверждения их внутренней непротиворечивости и пригодности для разработки ОО, отвечающего его целям безопасности.
Не все цели безопасности, выраженные в ПЗ, могут быть выполнены соответствующим ОО, так как некоторые ОО могут зависеть от требований безопасности ИТ, выполняемых средой ИТ. В этом случае требования безопасности ИТ, относящиеся к среде, необходимо ясно изложить и оценить в контексте требований к ОО.
Это семейство представляет требования оценки, которые позволяют оценщику принять решение, что ПЗ пригоден для использования в качестве изложения требований к оцениваемому ОО. Дополнительные критерии, необходимые для оценки требований, сформулированных в явном виде, приведены в семействе APE_SRE.
Замечания по применению
Термин "требования безопасности ИТ" подразумевает "требования безопасности ОО" с возможным включением "требований безопасности для среды ИТ".
Термин "требования безопасности ОО" подразумевает "функциональные требования безопасности ОО" и/или "требования доверия к ОО".
В компоненте APE_REQ.1 использованы несколько значений термина "appropriate" ("соответствующий", "необходимый", "приемлемый", "целесообразный") для указания, что данные элементы допускают выбор в определенных случаях. Какой выбор является приемлемым, зависит от контекста ПЗ. Подробная информация по этим аспектам содержится в приложении Б ГОСТ Р ИСО/МЭК 15408-1
APE_REQ.1 Профиль защиты, требования безопасности ИТ, требования оценки
| |
Зависимости
| |
APE_OBJ.1 Профиль защиты, цели безопасности, требования оценки
| |
Элементы действий разработчика
| |
APE_REQ.1.1D | Разработчик ПЗ должен представить изложение требований безопасности ИТ как часть ПЗ. |
APE_REQ.1.2D | Разработчик ПЗ должен представить логическое обоснование требований безопасности. |
Элементы содержания и представления свидетельств
| |
APE_REQ.1.1C | Изложение функциональных требований безопасности ОО должно идентифицировать функциональные требования безопасности ОО, составленные из компонентов функциональных требований ГОСТ Р ИСО/МЭК 15408-2. |
APE_REQ.1.2C | Изложение требований доверия к ОО должно идентифицировать требования доверия к ОО, составленные из компонентов требований доверия ГОСТ Р ИСО/МЭК 15408-3. |
APE_REQ.1.3C | В изложение требований доверия к ОО следует включить оценочный уровень доверия (ОУД), как определено в ГОСТ Р ИСО/МЭК 15408-3. |
APE_REQ.1.4C | Свидетельство должно содержать строгое обоснование, что изложение требований доверия к ОО является соответствующим. |
APE_REQ.1.5C | ПЗ должен, при необходимости, идентифицировать каждое требование безопасности для среды ИТ. |
APE_REQ.1.6C | Все завершенные операции над требованиями безопасности ИТ, включенными в ПЗ, должны быть идентифицированы. |
APE_REQ.1.7C | Любые незавершенные операции над требованиями безопасности ИТ, включенными в ПЗ, должны быть идентифицированы. |
APE_REQ.1.8C | Зависимости между требованиями безопасности ИТ, включенными в ПЗ, следует удовлетворить. |
APE_REQ.1.9C | Свидетельство должно содержать строгое обоснование каждого неудовлетворения зависимостей. |
APE_REQ.1.10C | ПЗ должен включать в себя изложение приемлемого минимального уровня стойкости функций безопасности (СФБ) для функциональных требований безопасности ОО: базовой, средней или высокой СФБ. |
APE_REQ.1.11C | ПЗ должен идентифицировать все конкретные функциональные требования безопасности ОО, для которых целесообразно явное указание стойкости функции, так же, как и конкретной метрики. |
APE_REQ.1.12C | Логическое обоснование требований безопасности должно демонстрировать, что минимальный уровень стойкости функции в ПЗ, как и каждое явное указание стойкости функции согласуются с целями безопасности ОО. |
APE_REQ.1.13C | Логическое обоснование требований безопасности должно демонстрировать, что требования безопасности ИТ пригодны для достижения целей безопасности. |
APE_REQ.1.14C | Логическое обоснование требований безопасности должно демонстрировать, что совокупность требований безопасности ИТ образует взаимно согласованное и внутреннее непротиворечивое целое. |
Элементы действий оценщика
| |
APE_REQ.1.1E | Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. |
APE_REQ.1.2E | Оценщик должен подтвердить, что описание требований безопасности ИТ является полным, логически последовательным и внутренне непротиворечивым. |
4.6 Требования безопасности ИТ, сформулированные в явном виде (APE_SRE)
Цели
Если после тщательного рассмотрения окажется, что ни один из компонентов требований ГОСТ Р ИСО/МЭК 15408-2 или настоящего стандарта не применим непосредственно ко всем или к части требований безопасности ИТ, разработчик ПЗ может сформулировать другие требования, которые не ссылаются на ГОСТ Р ИСО/МЭК 15408. Использование таких требований должно быть строго обосновано.
Это семейство содержит требования оценки, которые позволяют оценщику сделать заключение, что сформулированные в явном виде требования четко и однозначно выражены. Оценка требований, выбранных из ГОСТ Р ИСО/МЭК 15408 и используемых наряду со сформулированными в явном виде допустимыми требованиями безопасности, определяется семейством APE_REQ.
Сформулированные в явном виде требования безопасности ИТ для ОО, представленные или указанные в ПЗ, требуется оценить для демонстрации четкости и однозначности их выражения.
Замечания по применению
Формулировка в явном виде требований по структуре, сопоставимой со структурой существующих компонентов и элементов из ГОСТ Р ИСО/МЭК 15408, включает в себя выбор аналогичного маркирования, способа выражения и уровня детализации.
Использование требований ГОСТ Р ИСО/МЭК 15408 как образца означает, что требования могут быть четко идентифицированы, что они автономны, и применение каждого требования возможно и даст значимый результат оценки, основанный на анализе соответствия ОО этому конкретному требованию.
Термин "требования безопасности ИТ" подразумевает "требования безопасности ОО" с возможным включением "требований безопасности для среды ИТ".
Термин "требования безопасности ОО" подразумевает "функциональные требования безопасности ОО" и/или "требования доверия к ОО".
APE_SRE.1 Профиль защиты, требования безопасности ИТ, сформулированные в явном виде, требования оценки
| |||
Зависимости | |||
APE_REQ.1
| Профиль защиты, требования безопасности ИТ, требования оценки | ||
Элементы действий разработчика | |||
APE_SRE.1.1D | Разработчик ПЗ должен представить изложение требований безопасности ИТ как часть ПЗ. | ||
APE_SRE.1.2D | Разработчик ПЗ должен представить логическое обоснование требований безопасности. | ||
Элементы содержания и представления свидетельств | |||
APE_SRE.1.1C | Все требования безопасности ОО, которые сформулированы в явном виде без ссылки на ГОСТ Р ИСО/МЭК 15408, должны быть идентифицированы. | ||
APE_SRE.1.2C | Все требования безопасности для среды ИТ, которые сформулированы в явном виде без ссылки на ГОСТ Р ИСО/МЭК 15408, должны быть идентифицированы. | ||
APE_SRE.1.3C | Свидетельство должно содержать строгое обоснование, почему требования безопасности должны быть сформулированы в явном виде. | ||
APE_SRE.1.4C | Сформулированные в явном виде требования безопасности ИТ должны использовать компоненты, семейства и классы требований ГОСТ Р ИСО/МЭК 15408 как образец для представления. | ||
APE_SRE.1.5C | Сформулированные в явном виде требования безопасности ИТ должны быть измеримы и устанавливать объективные требования оценки, такие, что соответствие или несоответствие им ОО может быть определено и последовательно продемонстрировано. | ||
APE_SRE.1.6C | Сформулированные в явном виде требования безопасности ИТ должны быть четко и недвусмысленно выражены. | ||
APE_SRE.1.7C | Логическое обоснование требований безопасности должно демонстрировать, что требования доверия применимы и пригодны для поддержки каждого из сформулированных в явном виде функциональных требований безопасности ОО. | ||
Элементы действий оценщика | |||
APE_SRE.1.1E | Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. | ||
APE_SRE.1.2E | Оценщик должен определить, что все зависимости сформулированных в явном виде требований безопасности ИТ были идентифицированы. | ||
5 Класс ASE. Оценка задания по безопасности
Цель оценки ЗБ состоит в демонстрации, что ЗБ является полным, непротиворечивым, технически правильным и поэтому пригодно в качестве основы для оценки соответствующего ОО.
На рисунке 5.1 показаны семейства этого класса.
Рисунок 5.1 - Декомпозиция класса "Оценка задания по безопасности"
5.1 Описание ОО (ASE_DES)
Цели
Описание ОО способствует пониманию требований безопасности ОО. Оценка описания ОО требуется, чтобы показать, что оно является логически последовательным, внутренне непротиворечивым и согласованным со всеми другими частями ЗБ.
ASE_DES.1 Задание по безопасности, описание ОО, требования оценки
| ||
Зависимости | ||
ASE_ENV.1
| Задание по безопасности, среда безопасности, требования оценки | |
ASE_INT.1
| Задание по безопасности, введение ЗБ, требования оценки | |
ASE_OBJ.1
| Задание по безопасности, цели безопасности, требования оценки | |
ASE_PPC.1
| Задание по безопасности, утверждения о соответствии ПЗ, требования оценки
| |
ASE_REQ.1
| Задание по безопасности, требования безопасности ИТ, требования оценки
| |
ASE_TSS.1
| Задание по безопасности, краткая спецификация ОО, требования оценки
| |
Элементы действий разработчика
| ||
ASE_DES.1.1D
| Разработчик должен представить описание ОО как часть ЗБ. | |
Элементы содержания и представления свидетельств
| ||
ASE_DES.1.1C | Описание ОО, как минимум, должно включать в себя тип продукта или системы, а также область и ограничения применения ОО в общеупотребительных терминах как в физическом, так и в логическом смысле. | |
Элементы действий оценщика
| ||
ASE_DES.1.1E | Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. | |
ASE_DES.1.2E | Оценщик должен подтвердить, что описание ОО является логически последовательным и внутренне непротиворечивым. | |
ASE_DES.1.3E | Оценщик должен подтвердить, что описание ОО согласуется с другими частями ЗБ. | |
5.2 Среда безопасности (ASE_ENV)
Цели
Для принятия решения о достаточности требований безопасности ИТ в ЗБ важно, чтобы решаемая задача безопасности ясно принималась всеми участниками оценки.
ASE_ENV.1 Задание по безопасности, среда безопасности, требования оценки
| ||
Зависимости отсутствуют.
| ||
Элементы действий разработчика
| ||
ASE_ENV.1.1D | Разработчик должен представить изложение среды безопасности ОО как часть ЗБ. | |
Элементы содержания и представления свидетельств
| ||
ASE_ENV.1.1C | Изложение среды безопасности ОО должно идентифицировать и объяснить любые предположения о предполагаемом применении ОО и среде использования ОО. | |
ASE_ENV.1.2C | Изложение среды безопасности ОО должно идентифицировать и объяснить любые известные или допускаемые угрозы активам, от которых будет требоваться защита посредством ОО или его среды. | |
ASE_ENV.1.3C | Изложение среды безопасности ОО должно идентифицировать и объяснить каждую политику безопасности организации, соответствие которой для ОО необходимо. | |
Элементы действий оценщика
| ||
APE_ENV.1.1E | Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. | |
APE_ENV.1.2E | Оценщик должен подтвердить, что описание среды безопасности ОО является логически последовательным и внутренне непротиворечивым. | |
5.3 Введение ЗБ (ASE_INT)
Цели
Введение ЗБ содержит материалы по идентификации и индексации материалов. Оценка введения ЗБ требуется для демонстрации, что ЗБ правильно идентифицировано и введение согласуется со всеми другими частями ЗБ.
ASE_INT.1 Задание по безопасности, введение ЗБ, требования оценки
| ||
Зависимости
| ||
ASE_DES.1
| Задание по безопасности, описание ОО, требования оценки | |
ASE_ETV.1 | Задание по безопасности, среда безопасности, требования оценки
| |
ASE_OBJ.1 | Задание по безопасности, цели безопасности, требования оценки
| |
ASE_PPC.1 | Задание по безопасности, утверждения о соответствии ПЗ, требования оценки
| |
ASE_REQ.1 | Задание по безопасности, требования безопасности ИТ, требования оценки
| |
ASE_TSS.1 | Задание по безопасности, краткая спецификация ОО, требования оценки
| |
Элементы действий разработчика
| ||
ASE_INT.1.1D | Разработчик должен представить введение ЗБ как часть ЗБ.
| |
Элементы содержания и представления свидетельств
| ||
ASE_INT.1.1C | Введение ЗБ должно содержать данные идентификации ЗБ, которые предоставляют маркировку и описательную информацию, необходимые для идентификации и применения ЗБ и ОО, к которому оно относится. | |
ASE_INT.1.2C | Введение ЗБ должно содержать аннотацию ЗБ с общей характеристикой ЗБ в описательной форме. | |
ASE_INT.1.3C | Введение ЗБ должно содержать утверждение о соответствии ГОСТ Р ИСО/МЭК 15408, излагающее все оцениваемые утверждения о соответствии ОО ГОСТ Р ИСО/МЭК 15408. | |
Элементы действия оценщика
| ||
ASE_INT.1.1E | Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. | |
ASE_INT.1.2E | Оценщик должен подтвердить, что введение ЗБ является логически последовательным и внутренне непротиворечивым. | |
ASE_INT.1.3E | Оценщик должен подтвердить, что введение ЗБ согласуется с другими частями ЗБ. | |
5.4 Цели безопасности (ASE_OBJ)
Цели
Цели безопасности - краткое изложение предполагаемой реакции на задачу безопасности. Оценка целей безопасности требуется для демонстрации, что установленные цели адекватны проблеме безопасности. Существуют цели безопасности для ОО и цели безопасности для среды. Необходимо сопоставить цели безопасности для ОО и среды с идентифицированными угрозами, которым они противостоят, и/или с политикой и предположениями, которым они соответствуют.
ASE_OBJ.1 Задание по безопасности, цели безопасности, требования оценки
| ||
Зависимости
| ||
ASE_ENV.1
| Задание по безопасности, среда безопасности, требования оценки | |
Элементы действий разработчика
| ||
ASE_OBJ.1.1D | Разработчик должен представить изложение целей безопасности как часть ЗБ. | |
ASE_OBJ.1.2D | Разработчик должен представить логическое обоснование целей безопасности. | |
Элементы содержания и представления свидетельств
| ||
ASE_OBJ.1.1C | Изложение целей безопасности должно определить цели безопасности для ОО и его среды. | |
ASE_OBJ.1.2C | Цели безопасности для ОО должны быть четко изложены и сопоставлены с идентифицированными угрозами, которым будет противостоять ОО, и/или с политикой безопасности организации, которая будет выполняться ОО. | |
ASE_OBJ.1.3C | Цели безопасности для среды должны быть четко изложены и сопоставлены с теми аспектами идентифицированных угроз, которым ОО противостоит не полностью, и/или с политикой безопасности организации или предположениями, не полностью выполняемыми ОО. | |
ASE_OBJ.1.4C | Логическое обоснование целей безопасности должно демонстрировать, что изложенные цели безопасности пригодны для противостояния всем идентифицированным угрозам безопасности. | |
ASE_OBJ.1.5C | Логическое обоснование целей безопасности должно демонстрировать, что изложенные цели безопасности пригодны для охвата всех установленных положений политики безопасности организации и предположений. | |
Элементы действий оценщика
| ||
ASE_OBJ.1.1E | Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. | |
ASE_OBJ.1.2E | Оценщик должен подтвердить, что описание целей безопасности является полным, логически последовательным и внутренне непротиворечивым. | |
5.5 Утверждения о соответствии ПЗ (ASE_PPC)
Цели
Цель оценки утверждений о соответствии ПЗ состоит в том, чтобы решить, является ли ЗБ корректным отображением ПЗ.
Замечания по применению
Семейство применяют только при наличии утверждений о соответствии ПЗ. В противном случае не требуется никаких действий разработчика и оценщика.
Хотя при наличии утверждений о соответствии ПЗ необходимы дополнительные действия по оценке, затраты на оценку ЗБ обычно все-таки меньше, чем в случае, когда никакой ПЗ не применяется, потому что при оценке ЗБ можно использовать результаты оценки этого ПЗ.
ASE_PPC.1 Задание по безопасности, утверждения о соответствии ПЗ, требования оценки
| ||
Зависимости
| ||
ASE_OBJ.1 | Задание по безопасности, цели безопасности, требования оценки | |
ASE_REQ.1 | Задание по безопасности, требования безопасности ИТ, требования оценки | |
Элементы действий разработчика
| ||
ASE_PPC.1.1D | Разработчик должен представить каждое утверждение о соответствии ПЗ как часть ЗБ. | |
ASE_PPC.1.2D | Разработчик должен представить логическое обоснование утверждений о соответствии ПЗ для каждого представленного утверждения о соответствии ПЗ. | |
Элементы содержания и представления свидетельств
| ||
ASE_PPC.1.1C | Каждое утверждение о соответствии ПЗ должно идентифицировать ПЗ, соответствие которому утверждается, включая необходимые уточнения, связанные с этим утверждением. | |
ASE_PPC.1.2C | Каждое утверждение о соответствии ПЗ должно идентифицировать формулировки требований безопасности ИТ, в которых завершены разрешенные операции или иначе выполнено дальнейшее уточнение требований ПЗ. | |
ASE_PPC.1.3C | Каждое утверждение о соответствии ПЗ должно идентифицировать формулировки содержащихся в ЗБ целей безопасности и требований безопасности ИТ, которые дополняют имеющиеся в ПЗ. | |
Элементы действий оценщика
| ||
ASE_PPC.1.1E | Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. | |
ASE_PPC.1.2E | Оценщик должен подтвердить, что утверждения о соответствии профилям защиты являются корректным отображением соответствующих ПЗ. | |
5.6 Требования безопасности ИТ (ASE_REQ)
Цели
Требования безопасности ИТ, выбранные для ОО и представленные или указанные в ЗБ, необходимо оценить для подтверждения их внутренней непротиворечивости и пригодности для разработки ОО, отвечающего его целям безопасности.
Это семейство представляет требования оценки, которые позволяют оценщику принять решение, что ЗБ пригодно для использования в качестве изложения требований к соответствующему ОО. Дополнительные критерии, необходимые для оценки требований, сформулированных в явном виде, приведены в семействе ASE_SRE.
Замечания по применению
Термин "требования безопасности ИТ" подразумевает "требования безопасности ОО" с возможным включением "требований безопасности для среды ИТ".
Термин "требования безопасности ОО" подразумевает "функциональные требования безопасности ОО" и/или "требования доверия к ОО".
В компоненте ASE_REQ.1 использованы несколько значений термина "appropriate" ("соответствующий", "необходимый", "приемлемый", "целесообразный") для указания, что данные элементы допускают выбор в определенных случаях. Какой выбор является приемлемым, зависит от контекста ЗБ. Подробная информация по этим аспектам содержится в приложении В ГОСТ Р ИСО/МЭК 15408-1.
ASE_REQ.1 Задание по безопасности, требования безопасности ИТ, требования оценки
| ||
Зависимости
| ||
ASE_OBJ.1 | Задание по безопасности, цели безопасности, требования оценки | |
Элементы действий разработчика
| ||
ASE_REQ.1.1D | Разработчик должен представить изложение требований безопасности ИТ как часть ЗБ. | |
ASE_REQ.1.2D | Разработчик должен представить логическое обоснование требований безопасности. | |
Элементы содержания и представления свидетельств
| ||
ASE_REQ.1.1C
| Изложение функциональных требований безопасности ОО должно идентифицировать функциональные требования безопасности ОО, составленные из компонентов функциональных требований из ГОСТ Р ИСО/МЭК 15408-2. | |
ASE_REQ.1.2C | Изложение требований доверия к ОО должно идентифицировать требования доверия к ОО, составленные из компонентов требований доверия из ГОСТ Р ИСО/МЭК 15408-3. | |
ASE_REQ.1.3C | В изложение требований доверия к ОО следует включить оценочный уровень доверия (ОУД), как определено в ГОСТ Р ИСО/МЭК 15408-3. | |
ASE_REQ.1.4C | Свидетельство должно содержать строгое обоснование, что изложение требований доверия к ОО является соответствующим. | |
ASE_REQ.1.5C | ЗБ должно, при необходимости, идентифицировать каждое требование безопасности для среды ИТ. | |
ASE_REQ.1.6C | Операции, предусмотренные в требованиях безопасности ИТ, включенных в ЗБ, должны быть идентифицированы и выполнены. | |
ASE_REQ.1.7C | Зависимости между требованиями безопасности ИТ, включенными в ЗБ, следует удовлетворить. | |
ASE_REQ.1.8C | Свидетельство должно содержать строгое обоснование каждого неудовлетворения зависимостей. | |
ASE_REQ.1.9C | ЗБ должно включать в себя изложение приемлемого минимального уровня стойкости функций безопасности (СФБ) для функциональных требований безопасности ОО: базовой, средней или высокой СФБ. | |
ASE_REQ.1.10C | ЗБ должно идентифицировать все конкретные функциональные требования безопасности ОО, для которых целесообразно явное указание стойкости функции, так же, как и конкретной метрики. | |
ASE_REQ.1.11C | Логическое обоснование требований безопасности должно демонстрировать, что минимальный уровень стойкости функции в ЗБ, как и каждое явное указание стойкости функции согласуются с целями безопасности ОО. | |
ASE_REQ.1.12C | Логическое обоснование требований безопасности должно демонстрировать, что требования безопасности ИТ пригодны для достижения целей безопасности. | |
ASE_REQ.1.13C | Логическое обоснование требований безопасности должно демонстрировать, что совокупность требований безопасности ИТ образует взаимно согласованное и внутренне непротиворечивое целое. | |
Элементы действий оценщика
| ||
APE_REQ.1.1E | Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. | |
APE_REQ.1.2E | Оценщик должен подтвердить, что описание требований безопасности ИТ является полным, логически последовательным и внутренне непротиворечивым. | |
5.7 Требования безопасности ИТ, сформулированные в явном виде (ASE_SRE)
Цели
Если после тщательного рассмотрения окажется, что ни один из компонентов требований ГОСТ Р ИСО/МЭК 15408-2 или настоящего стандарта не применим непосредственно ко всем или к части требований безопасности ИТ, разработчик ЗБ может сформулировать другие требования, которые не ссылаются на ГОСТ Р ИСО/МЭК 15408. Использование таких требований должно быть строго обосновано.
Это семейство содержит требования оценки, которые позволяют оценщику сделать заключение, что сформулированные в явном виде требования четко и однозначно выражены. Оценка требований, выбранных из ГОСТ Р ИСО/МЭК 15408 и используемых наряду со сформулированными в явном виде допустимыми требованиями безопасности, определяется семейством ASE_REQ.
Сформулированные в явном виде требования безопасности ИТ для ОО, представленные или указанные в ЗБ, требуется оценить для демонстрации четкости и однозначности их выражения.
Замечания по применению
Формулировка в явном виде требований по структуре, сопоставимой со структурой существующих компонентов и элементов из ГОСТ Р ИСО/МЭК 15408, включает в себя выбор аналогичного маркирования, способа выражения и уровня детализации.
Использование требований ГОСТ Р ИСО/МЭК 15408 как образца означает, что требования могут быть четко идентифицированы, что они автономны, и применение каждого требования возможно и даст значимый результат оценки, основанный на изложении соответствия ОО этому конкретному требованию.
Термин "требования безопасности ИТ" подразумевает "требования безопасности ОО" с возможным включением "требований безопасности для среды ИТ".
Термин "требования безопасности ОО" подразумевает "функциональные требования безопасности ОО" и/или "требования доверия к ОО".
ASE_SRE.1 | Задание по безопасности, требования безопасности ИТ, сформулированные в явном виде, требования оценки | ||
Зависимости
| |||
ASE_REQ.2 | Задание по безопасности, требования безопасности ИТ, требования оценки | ||
Элементы действий разработчика
| |||
ASE_SRE.1.1D | Разработчик должен представить изложение требований безопасности ИТ как часть ЗБ. | ||
ASE_SRE.1.2D | Разработчик должен представить логическое обоснование требований безопасности. | ||
Элементы содержания и представления свидетельств
| |||
ASE_SRE.1.1C | Все требования безопасности ОО, которые сформулированы в явном виде без ссылки на ГОСТ Р ИСО/МЭК 15408, должны быть идентифицированы. | ||
ASE_SRE.1.2C | Все требования безопасности для среды ИТ, которые сформулированы в явном виде без ссылки на ГОСТ Р ИСО/МЭК 15408, должны быть идентифицированы. | ||
ASE_SRE.1.3C | Свидетельство должно содержать строгое обоснование, почему требования безопасности должны быть сформулированы в явном виде. | ||
ASE_SRE.1.4C | Сформулированные в явном виде требования безопасности ИТ должны использовать компоненты, семейства и классы требований ГОСТ Р ИСО/МЭК 15408 как образец для представления. | ||
ASE_SRE.1.5C | Сформулированные в явном виде требования безопасности ИТ должны быть измеримы и устанавливать объективные требования оценки, такие, что соответствие или несоответствие им ОО может быть определено и последовательно продемонстрировано. | ||
ASE_SRE.1.6C | Сформулированные в явном виде требования безопасности ИТ должны быть четко и недвусмысленно выражены. | ||
ASE_SRE.1.7C | Логическое обоснование требований безопасности должно демонстрировать, что требования доверия применимы и пригодны для поддержки каждого из сформулированных в явном виде функциональных требований безопасности ОО. | ||
Элементы действий оценщика
| |||
ASE_SRE.1.1E | Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. | ||
ASE_SRE.1.2E | Оценщик должен определить, что все зависимости сформулированных в явном виде требований безопасности ИТ были идентифицированы. | ||
5.8 Краткая спецификация ОО (ASE_TSS)
Цели
Краткая спецификация ОО предоставляет определение в самом общем виде функций безопасности, заявленных для удовлетворения функциональных требований, и мер доверия, выбранных для удовлетворения требований доверия.
Замечания по применению
Отношение между функциями безопасности ИТ и функциональными требованиями безопасности ОО может быть отношением типа "многие ко многим". Тем не менее каждая функция безопасности должна способствовать удовлетворению по меньшей мере одного требования безопасности, чтобы можно было четко определить ФБО. Функции безопасности, которые не соответствуют этому требованию, обычно необязательны. Заметим, однако, что требование, чтобы функция безопасности способствовала удовлетворению по меньшей мере одного требования безопасности, сформулировано в наиболее общем виде с тем, чтобы для всех функций безопасности, которые полезны для ОО, существовала бы возможность обоснования.
Изложение мер доверия уместно во всех случаях, когда в ЗБ включены требования доверия, не входящие в настоящий стандарт. Если требования доверия к ОО в ЗБ основаны исключительно на оценочных уровнях доверия или других компонентах доверия из настоящего стандарта, то меры доверия могут быть представлены в форме ссылки на документы, которые указывают на удовлетворение требований доверия.
В компоненте ASE_TSS.1 использованы несколько значений термина "appropriate" ("соответствующий", "необходимый") для указания, что данные элементы допускают выбор в определенных случаях. Какой выбор является приемлемым, зависит от контекста ЗБ. Подробная информация по этим аспектам содержится в приложении В ГОСТ Р ИСО/МЭК 15408-1.
ASE_TSS.1 Задание по безопасности, краткая спецификация ОО, требования оценки
| ||
Зависимости
| ||
ASE_REQ.1 | Задание по безопасности, требования безопасности ИТ, требования оценки
| |
Элементы действий разработчика
| ||
ASE_TSS.1.1D | Разработчик должен представить краткую спецификацию ОО как часть ЗБ. | |
ASE_TSS.1.2D | Разработчик должен представить логическое обоснование краткой спецификации ОО. | |
Элементы содержания и представления свидетельств
| ||
ASE_TSS.1.1C | Краткая спецификация ОО должна содержать описание функций безопасности ИТ и мер доверия к ОО. | |
ASE_TSS.1.2C | Краткая спецификация ОО должна сопоставить функции безопасности ИТ и функциональные требования безопасности ОО таким образом, чтобы можно было отметить, какие функции безопасности ИТ каким функциональным требованиям безопасности ОО удовлетворяют и что каждая функция безопасности ИТ способствует удовлетворению по меньшей мере одного функционального требования безопасности ОО. | |
ASE_TSS.1.3C | Функции безопасности ИТ должны быть определены в неформальном стиле на уровне детализации, необходимом для понимания их назначения. | |
ASE_TSS.1.4C | Все ссылки на механизмы безопасности, включенные в ЗБ, должны быть сопоставлены с соответствующими функциями безопасности так, чтобы можно было отметить, какие механизмы безопасности использованы при реализации каждой функции. | |
ASE_TSS.1.5C | Логическое обоснование краткой спецификации ОО должно демонстрировать, что функции безопасности ИТ пригодны для удовлетворения функциональных требований безопасности ОО. | |
ASE_TSS.1.6C | Логическое обоснование краткой спецификации ОО должно демонстрировать, что сочетание специфицированных функций безопасности ИТ в совокупности способно удовлетворить функциональные требования безопасности ОО. | |
ASE_TSS.1.7C | Краткая спецификация ОО должна сопоставить меры и требования доверия так, чтобы можно было отметить, какие меры способствуют удовлетворению каких требований. | |
ASE_TSS.1.8C | Логическое обоснование краткой спецификации ОО должно демонстрировать, что меры доверия удовлетворяют все требования доверия к ОО. | |
ASE_TSS.1.9C | Краткая спецификация ОО должна идентифицировать все функции безопасности ИТ, которые реализованы вероятностным или перестановочным механизмом соответственно. | |
ASE_TSS.1.10C | Краткая спецификация ОО должна установить для каждой функции безопасности ИТ, для которой это необходимо, требование стойкости функции либо по специальной метрике, либо как базовую, среднюю или высокую СФБ. | |
Элементы действий оценщика
| ||
APE_TSS.1.1E | Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. | |
АРE_TSS.1.2E | Оценщик должен подтвердить, что краткая спецификация ОО является полной, логически последовательной и внутренне непротиворечивой. | |
6 Оценочные уровни доверия
Оценочные уровни доверия (ОУД) образуют возрастающую шкалу, которая позволяет соотнести получаемый уровень доверия со стоимостью и возможностью достижения этой степени доверия. Настоящий стандарт идентифицирует разделенные понятия доверия к ОО по завершению оценки и поддержки этого доверия в процессе эксплуатации ОО.
Важно обратить внимание, что не все семейства и компоненты настоящего стандарта включены в оценочные уровни доверия. Это не означает, что они не обеспечивают значимое и полезное доверие. Напротив, ожидается, что эти семейства и их компоненты будут рассматриваться для усиления ОУД в тех ПЗ и ЗБ, для которых они полезны.
6.1 Краткий обзор оценочных уровней доверия (ОУД)
В таблице 6.1 представлено сводное описание ОУД. Графы таблицы представляют иерархически упорядоченный набор ОУД, а строки - семейства доверия. Каждый номер в образованной ими матрице идентифицирует конкретный компонент доверия, применяемый в данном случае.
Таблица 6.1 - Обзор оценочных уровней доверия
Класс доверия | Семейство доверия | Компоненты доверия из оценочного уровня доверия | ||||||
|
| ОУД1 | ОУД2 | ОУД3 | ОУД4 | ОУД5 | ОУД6 | ОУД7 |
Управление конфигурацией | ACM_AUT |
|
|
| 1 | 1 | 2 | 2 |
| АСМ_САР | 1 | 2 | 3 | 4 | 4 | 5 | 5 |
| ACM_SCP |
|
| 1 | 2 | 3 | 3 | 3 |
Поставка и эксплуатация | ADO_DEL |
| 1 | 1 | 2 | 2 | 2 | 3 |
| ADO_IGS | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
Разработка | ADV_FSP | 1 | 1 | 1 | 2 | 3 | 3 | 4 |
| ADV_HLD |
| 1 | 2 | 2 | 3 | 4 | 5 |
| ADV_IMP |
|
|
| 1 | 2 | 3 | 3 |
| ADV_INT |
|
|
|
| 1 | 2 | 3 |
| ADV _LLD |
|
|
| 1 | 1 | 2 | 2 |
| ADV_RCR | 1 | 1 | 1 | 1 | 2 | 2 | 3 |
| ADV_SPM |
|
|
| 1 | 3 | 3 | 3 |
Руководства | AGD_ADM | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| AGD_USR | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
Поддержка жизненного цикла | ALC _DVS |
|
| 1 | 1 | 1 | 2 | 2 |
| ALC_FLR |
|
|
|
|
|
|
|
| ALC_LCD |
|
|
| 1 | 2 | 2 | 3 |
| ALC_TAT |
|
|
| 1 | 2 | 3 | 3 |
Тестирование | ATE_COV |
| 1 | 2 | 2 | 2 | 3 | 3 |
| ATE_DPT |
|
| 1 | 1 | 2 | 2 | 3 |
| ATE_FUN |
| 1 | 1 | 1 | 1 | 2 | 2 |
| ATE_IND | 1 | 2 | 2 | 2 | 2 | 2 | 3 |
Оценка уязвимостей | AVA_CCA |
|
|
|
| 1 | 2 | 2 |
| AVA_MSU |
|
| 1 | 2 | 2 | 3 | 3 |
| AVA_SOF |
| 1 | 1 | 1 | 1 | 1 | 1 |
| AVA_VLA |
| 1 | 1 | 2 | 3 | 4 | 4 |
Как показано в следующем подразделе, в настоящем стандарте определены семь иерархически упорядоченных оценочных уровней доверия для ранжирования доверия к ОО. Каждый последующий ОУД представляет более высокое доверие, чем любой из предыдущих. Увеличение доверия от предыдущего ОУД к последующему достигается заменой какого-либо компонента доверия иерархичным компонентом из того же семейства доверия (т.е. увеличением строгости, области и/или глубины оценки) и добавлением компонентов из других семейств доверия (т.е. добавлением новых требований).
ОУД состоят из определенной комбинации компонентов доверия, как описано в разделе 2. Точнее, каждый ОУД включает в себя не более одного компонента каждого семейства доверия, а все зависимости каждого компонента доверия учтены.
Хотя в настоящем стандарте определены именно ОУД, можно представлять другие комбинации компонентов доверия. Специально введенное понятие "усиление" ("augmentation") допускает добавление (из семейств доверия, до этого не включенных в ОУД) или замену компонентов доверия в ОУД (другими иерархичными компонентами из того же самого семейства доверия). Из конструкций установления доверия, определенных в ГОСТ Р ИСО/МЭК 15408, только ОУД могут быть усилены. Понятие "ОУД" за исключением какого-либо составляющего его компонента доверия" не признано в ГОСТ Р ИСО/МЭК 15408 как допустимое утверждение. Вводящий усиление обязан строго обосновать полезность и дополнительную ценность добавленного к ОУД компонента доверия. ОУД может быть также расширен требованиями доверия, сформулированными в явном виде.
6.2 Детализация оценочных уровней доверия
Следующие подразделы содержат определения ОУД с использованием полужирного шрифта для выделения новых требований и их описания.
6.2.1 Оценочный уровень доверия 1 (ОУД1), предусматривающий функциональное тестирование
Цели
ОУД1 применим, когда требуется некоторая уверенность в правильном функционировании, а угрозы безопасности не рассматривают как серьезные. Он будет полезен там, где требуется независимо полученное доверие утверждению, что было уделено должное внимание защите персональных данных или подобной информации.
ОУД1 обеспечивает оценку ОО в том виде, в каком он доступен потребителю, путем независимого тестирования на соответствие спецификации и экспертизы представленной документации. Предполагается, что оценка может успешно проводиться без помощи разработчика ОО и с минимальными затратами.
При оценке на этом уровне следует представить свидетельство, что ОО функционирует в соответствии с документацией и предоставляет приемлемую защиту против идентифицированных угроз.
Компоненты доверия
ОУД1 (см. таблицу 6.2) предоставляет базовый уровень доверия посредством анализа функций безопасности с использованием для понимания режима безопасности функциональной спецификации, спецификации интерфейсов и руководств.
Таблица 6.2 - Оценочный уровень доверия 1
Класс доверия | Компоненты доверия |
Управление конфигурацией
| АСМ_САР.1 Номера версий |
Поставка и эксплуатация | ADO_IGS.1 Процедуры установки, генерации и запуска
|
Разработка
| ADV_FSP.1 Неформальная функциональная спецификация
|
| ADV_RCR.1 Неформальная демонстрация соответствия |
Руководства
| AGD_ADM.1 Руководство администратора
|
| AGD_USR.1 Руководство пользователя
|
Тестирование | ATE_IND.1 Независимое тестирование на соответствие
|
Анализ поддержан независимым тестированием ФБО.
Этот ОУД обеспечивает значимое увеличение доверия по сравнению с неоцененным продуктом или системой ИТ.
6.2.2 Оценочный уровень доверия 2 (ОУД2), предусматривающий структурное тестирование
Цели
ОУД2 содержит требование сотрудничества с разработчиком для получения информации о проекте и результатах тестирования, но при этом не следует требовать от разработчика усилий, превышающих обычную коммерческую практику. Следовательно, не требуется существенного увеличения стоимости или затрат времени.
Поэтому ОУД2 применим в случаях, когда разработчикам или пользователям требуется независимо подтверждаемый уровень доверия от невысокого до умеренного при отсутствии доступа к полной документации по разработке. Такая ситуация может возникать при обеспечении безопасности разработанных ранее (наследуемых) систем или при ограниченной доступности разработчика.
Компоненты доверия
ОУД2 (см. таблицу 6.3) обеспечивает доверие посредством анализа функций безопасности с использованием для понимания режима безопасности функциональной спецификации, спецификации интерфейсов, руководств и проекта ОО верхнего уровня.
Таблица 6.3 - Оценочный уровень доверия 2
Класс доверия | Компоненты доверия |
Управление конфигурацией | АСМ_САР.2 Элементы конфигурации |
Поставка и эксплуатация | ADO_DEL.1 Процедуры поставки |
| ADO_IGS.1 Процедуры установки, генерации и запуска |
Разработка | ADV_ESP.1 Неформальная функциональная спецификация |
| ADV_HLD.1 Описательный проект верхнего уровня |
| ADV_RCR.1 Неформальная демонстрация соответствия |
Руководства | AGD_ADM.1 Руководство администратора |
| AGD_USR.1 Руководство пользователя |
Тестирование | ATE_COV.1 Свидетельство покрытия |
| ATE_FUN.1 Функциональное тестирование |
| ATE_IND.2 Выборочное независимое тестирование |
Оценка уязвимостей | AVA_SOF.1 Оценка стойкости функции безопасности ОО |
| AVA_VLA.1 Анализ уязвимостей разработчиком |
Анализ поддержан независимым тестированием ФБО, свидетельством разработчика об испытаниях, основанных на функциональной спецификации, выборочным независимым подтверждением результатов тестирования разработчиком, анализом стойкости функций и свидетельством поиска разработчиком явных уязвимостей (например, из общедоступных источников).
ОУД2 также обеспечивает доверие посредством списка конфигурации ОО и свидетельства безопасных процедур поставки.
Этот ОУД представляет значимое увеличение доверия по сравнению с ОУД1, требуя тестирование и анализ уязвимостей разработчиком, а также независимое тестирование, основанное на более детализированных спецификациях ОО.
6.2.3 Оценочный уровень доверия 3 (ОУД3), предусматривающий методическое тестирование и проверку
Цели
ОУД3 позволяет добросовестному разработчику достичь максимального доверия путем применения надлежащего проектирования безопасности без значительного изменения существующей практики качественной разработки.
ОУД3 применим в тех случаях, когда разработчикам или пользователям требуется независимо подтверждаемый умеренный уровень доверия на основе всестороннего исследования ОО и процесса его разработки без существенных затрат на изменение технологии проектирования.
Компоненты доверия
ОУД3 (см. таблицу 6.4) обеспечивает доверие путем анализа функций безопасности с использованием для понимания режима безопасности функциональной спецификации, спецификации интерфейсов, руководства и проекта ОО верхнего уровня.
Таблица 6.4 - Оценочный уровень доверия 3
Класс доверия | Компоненты доверия |
Управление конфигурацией | АСМ_САР.3 Средства контроля авторизации
|
| ACM SCP.1 Охват УК объекта оценки
|
Поставка и эксплуатация | ADO_DEL.1 Процедуры поставки |
| ADO_IGS.1 Процедуры установки, генерации и запуска |
Разработка
| ADV_FSP.1 Неформальная функциональная спецификация |
| ADV_HLD.2 Детализация вопросов безопасности в проекте верхнего уровня |
| ADV_RCR.1 Неформальная демонстрация соответствия |
Руководства | AGD_ADM.1 Руководство администратора |
| AGD_USR.1 Руководство пользователя |
Поддержка жизненного цикла | ALC_DVS.1 Идентификация мер безопасности |
Тестирование
| ATE_COV.2 Анализ покрытия
|
| ATE_DPT.1 Тестирование: проект верхнего уровня
|
| ATE_FUN.1 Функциональное тестирование |
| ATE_IND2 Выборочное независимое тестирование |
Оценка уязвимостей
| AVA_MSU.1 Экспертиза руководств |
| AVA_SOF.1 Оценка стойкости функции безопасности ОО |
| AVA_VLA.1 Анализ уязвимостей разработчиком |
Анализ поддержан независимым тестированием ФБО, свидетельством разработчика об испытаниях, основанных на функциональной спецификации и проекте верхнего уровня, выборочным независимым подтверждением результатов тестирования разработчиком, анализом стойкости функций и свидетельством поиска разработчиком явных уязвимостей (например, из общедоступных источников).
ОУД3 также обеспечивает доверие посредством использования контроля среды разработки, управления конфигурацией ОО и свидетельства безопасных процедур поставки.
Этот ОУД представляет значимое увеличение доверия по сравнению с ОУД2, требуя более полного покрытия тестированием функций и механизмов безопасности и/или процедур безопасности, что дает некоторую уверенность в том, что в ОО не будут внесены искажения во время разработки.
6.2.4 Оценочный уровень доверия 4 (ОУД4), предусматривающий методическое проектирование, тестирование и углубленную проверку
Цели
ОУД4 позволяет разработчику достичь максимального доверия путем применения надлежащего проектирования безопасности, основанного на обычной коммерческой практике разработки, которая, даже будучи строгой, не требует глубоких специальных знаний, навыков и других ресурсов. ОУД4 - самый высокий уровень, на который, вероятно, экономически целесообразно ориентироваться при оценке уже существующих продуктов.
Поэтому ОУД4 применим, когда разработчикам или пользователям требуется независимо подтверждаемый уровень доверия от умеренного до высокого в ОО общего назначения и имеется готовность нести дополнительные, связанные с обеспечением безопасности, производственные затраты.
Компоненты доверия
ОУД4 (см. таблицу 6.5) обеспечивает доверие посредством анализа функций безопасности с использованием для понимания режима безопасности функциональной спецификации, полной спецификации интерфейсов, руководств, проекта ОО верхнего уровня и нижнего уровня, а также подмножества реализации. Доверие дополнительно достигается применением неформальной модели политики безопасности ОО.
Таблица 6.5 - Оценочный уровень доверия 4
Класс доверия | Компоненты доверия |
Управление конфигурацией | ACM_AUT.1 Частичная автоматизация УК |
| АСМ_САР.4 Поддержка генерации, процедуры приемки |
| ACM_SCP.2 Охват УК отслеживания проблем |
Поставка и эксплуатация | ADO_DEL.2 Обнаружение модификации |
| ADO_IGS.1 Процедуры установки, генерации и запуска |
Разработка
| ADV_FSP.2 Полностью определенные внешние интерфейсы |
| ADV_HLD.2 Детализация вопросов безопасности в проекте верхнего уровня |
| ADV_IMP.1 Подмножество реализации ФБО |
| ADV_LLD.1 Описательный проект нижнего уровня |
| ADV_RCR.1 Неформальная демонстрация соответствия |
| ADV_SPM.1 Неформальная модель политики безопасности ОО |
Руководства | AGD_ADM.1 Руководство администратора |
| AGD_USR.1 Руководство пользователя |
Поддержка жизненного цикла | ALC_DVS.1 Идентификация мер безопасности |
| ALC_LCD.1 Модель жизненного цикла, определенная разработчиком |
| ALC_TAT.1 Полностью определенные инструментальные средства разработки |
Тестирование
| ATE_COV.2 Анализ покрытия |
| ATE_DPT.1 Тестирование: проект верхнего уровня |
| ATE_FUN.1 Функциональное тестирование |
| ATE_IND.2 Выборочное независимое тестирование |
Оценка уязвимостей | AVA_MSU.2 Подтверждение правильности анализа |
| AVA_SOF.1 Оценка стойкости функции безопасности ОО |
| AVA_VLA.2 Независимый анализ уязвимостей |
Анализ поддержан независимым тестированием ФБО, свидетельством разработчика об испытаниях, основанных на функциональной спецификации и проекте верхнего уровня, выборочным независимым подтверждением результатов тестирования разработчиком, анализом стойкости функций, свидетельством поиска разработчиком уязвимостей и независимым анализом уязвимостей, демонстрирующим противодействие попыткам проникновения нарушителей с низким потенциалом нападения.
ОУД4 также обеспечивает доверие посредством использования контроля среды разработки и дополнительного управления конфигурацией ОО, включая автоматизацию, и свидетельства безопасных процедур поставки.
Этот ОУД представляет значимое увеличение доверия по сравнению с ОУД3, требуя более детальное описание проекта, подмножество реализации и улучшенные механизмы и/или процедуры, что дает уверенность в том, что в ОО не будут внесены искажения во время разработки или поставки.
6.2.5 Оценочный уровень доверия 5 (ОУД5), предусматривающий полуформальное проектирование и тестирование
Цели
ОУД5 позволяет разработчику достичь максимального доверия путем проектирования безопасности, основанного на строгой коммерческой практике разработки, поддержанного умеренным применением узко специализированных методов проектирования безопасности. Такие ОО будут, вероятно, проектироваться и разрабатываться с намерением достичь ОУД5. Скорее всего, дополнительные затраты, сопутствующие требованиям ОУД5 в части строгости разработки, не будут большими без учета применения специализированных методов.
Поэтому ОУД5 применим, когда разработчикам или пользователям требуется независимо получаемый высокий уровень доверия для запланированной разработки со строгим подходом к разработке, не влекущим излишних затрат на применение узко специализированных методов проектирования безопасности.
Компоненты доверия
ОУД5 (см. таблицу 6.6) обеспечивает доверие посредством анализа функций безопасности с использованием для понимания режима безопасности функциональной спецификации, полной спецификации интерфейсов, руководств, проекта ОО верхнего уровня и нижнего уровня, а также всей реализации. Доверие дополнительно достигается применением формальной модели политики безопасности ОО и полуформального представления функциональной спецификации и проекта верхнего уровня, а также полуформальной демонстрации соответствия между ними. Кроме этого, требуется модульное проектирование ОО.
Таблица 6.6 - Оценочный уровень доверия 5
Класс доверия | Компоненты доверия |
Управление конфигурацией | ACM_AUT.1 Частичная автоматизация УК |
| АСМ_САР.4 Поддержка генерации, процедуры приемки |
| ACM_SCP.3 Охват УК инструментальных средств разработки |
Поставка и эксплуатация | ADO_DEL.2 Обнаружение модификации |
| ADO_IGS.1 Процедуры установки, генерации и запуска |
Разработка
| ADV_FSP.3 Полуформальная функциональная спецификация |
| ADV_HLD.3 Полуформальный проект верхнего уровня
|
| ADV_IMP.2 Реализации ФБО
|
| ADV_INT.1 Модульность |
| ADV_LLD.1 Описательный проект нижнего уровня |
| ADV_RCR.2 Полуформальная демонстрация соответствия
|
| ADV_SPM.3 Формальная модель политики безопасности ОО
|
Руководства | AGD_ADM.1 Руководство администратора |
| AGD_USR.1 Руководство пользователя |
Поддержка жизненного цикла | ALC_DVS.1 Идентификация мер безопасности |
| ALC_LCD.2 Стандартизованная модель жизненного цикла |
| ALC_TAT.2 Соответствие стандартам реализации |
Тестирование | ATE_COV.2 Анализ покрытия |
| ATE_DPT.2 Тестирование: проект нижнего уровня |
| ATE_FUN.1 Функциональное тестирование |
| ATE_IND.2 Выборочное независимое тестирование |
Оценка уязвимостей
| AVA_CCA.1 Анализ скрытых каналов |
| AVA_MSU.2 Подтверждение правильности анализа |
| AVA_SOF. 1 Оценка стойкости функции безопасности ОО |
| AVA_VLA.3 Умеренно стойкий |
Анализ поддержан независимым тестированием ФБО, свидетельством разработчика об испытаниях, основанных на функциональной спецификации, проекте верхнего уровня и проекте нижнего уровня, выборочным независимым подтверждением результатов тестирования разработчиком, анализом стойкости функций, свидетельством поиска разработчиком уязвимостей и независимым анализом уязвимостей, демонстрирующим противодействие попыткам проникновения нарушителей с умеренным потенциалом нападения. Анализ также включает в себя проверку правильности анализа разработчиком скрытых каналов.
ОУД5 также обеспечивает доверие посредством использования контроля среды разработки и всестороннего управления конфигурацией ОО, включая автоматизацию, и свидетельства безопасных процедур поставки.
Этот ОУД представляет значимое увеличение доверия по сравнению с ОУД4, требуя полуформальное описание проекта, полную реализацию, более структурированную (и, следовательно, лучше анализируемую) архитектуру, анализ скрытых каналов и улучшенные механизмы и/или процедуры, что дает уверенность в том, что в ОО не будут внесены искажения во время разработки.
6.2.6 Оценочный уровень доверия 6 (ОУД6), предусматривающий полуформальную верификацию проекта и тестирование
Цели
ОУД6 позволяет разработчикам достичь высокого доверия путем применения специальных методов проектирования безопасности в строго контролируемой среде разработки с целью получения высококачественного ОО для защиты высоко оцениваемых активов от значительных рисков.
Поэтому ОУД6 применим для разработки безопасных ОО с целью применения в ситуациях высокого риска, где ценность защищаемых активов оправдывает дополнительные затраты.
Компоненты доверия
ОУД6 (см таблицу 6.7) обеспечивает доверие посредством анализа функций безопасности с использованием для понимания режима безопасности функциональной спецификации, полной спецификации интерфейсов, руководств, проекта ОО верхнего уровня и нижнего уровня, а также структурированного представления реализации. Доверие дополнительно достигается применением формальной модели политики безопасности ОО и полуформального представления функциональной спецификации, проекта верхнего уровня, и проекта нижнего уровня, а также полуформальной демонстрации соответствия между ними. Кроме этого, требуется модульное и иерархическое (по уровням) проектирование ОО.
Таблица 6.7 - Оценочный уровень доверия 6
Класс доверия | Компоненты доверия |
Управление конфигурацией | ACM_AUT.2 Полная автоматизация УК |
| АСМ_САР.5 Расширенная поддержка |
| ACM_SCP.3 Охват УК инструментальных средств разработки |
Поставка и эксплуатация
| ADO_DEL.2 Обнаружение модификации |
| ADO_IGS.1 Процедуры установки, генерации и запуска |
Разработка
| ADV_FSP.3 Полуформальная функциональная спецификация |
| ADV_HLD.4 Пояснения в полуформальном проекте верхнего уровня
|
| ADV_IMP.3 Структурированная реализация ФБО
|
| ADV_INT.2 Уменьшение сложности
|
| ADV_LLD.2 Полуформальный проект нижнего уровня
|
| ADV_RCR 2 Полуформальная демонстрация соответствия |
| ADV_SPM 3 Формальная модель политики безопасности ОО |
Руководства
| AGD_ADM.1 Руководство администратора |
| AGD_USR.1 Руководство пользователя |
Поддержка жизненного цикла | ALC_DVS.2 Достаточность мер безопасности |
| ALC_LCD.2 Стандартизованная модель жизненного цикла |
| ALC_ТАТ.3 Соответствие всех частей объекта оценки стандартам реализации |
Тестирование
| ATE_COV.3 Строгий анализ покрытия |
| ATE_DPT.2 Тестирование: проект нижнего уровня |
| ATE_FUN.2 Упорядоченное функциональное тестирование |
| ATE_IND.2 Выборочное независимое тестирование |
Оценка уязвимостей
| AVA_CCA.2 Систематический анализ скрытых каналов
|
| AVA_MSU.3 Анализ и тестирование опасных состояний |
| AVA_SOF.1 Оценка стойкости функции безопасности ОО |
| AVA_VLA.4 Высокостойкий |
Анализ поддержан независимым тестированием ФБО, свидетельством разработчика об испытаниях, основанных на функциональной спецификации, проекте верхнего уровня и проекте нижнего уровня, выборочным независимым подтверждением результатов тестирования разработчиком, анализом стойкости функций, свидетельством поиска разработчиком уязвимостей и независимым анализом уязвимостей, демонстрирующим противодействие попыткам проникновения нарушителей с высоким потенциалом нападения. Анализ также включает в себя проверку правильности систематического анализа разработчиком скрытых каналов.
ОУД6 также обеспечивает доверие посредством использования структурированного процесса разработки, контроля среды разработки и всестороннего управления конфигурацией ОО, включая полную автоматизацию, и свидетельства безопасных процедур поставки.
Этот ОУД представляет значимое увеличение доверия по сравнению с ОУД5, требуя всесторонний анализ, структурированное представление реализации, более стройную структуру (например, с разбиением на уровни), всесторонний независимый анализ уязвимостей, систематическую идентификацию скрытых каналов, улучшенное управление конфигурацией и улучшенный контроль среды разработки.
6.2.7 Оценочный уровень доверия 7 (ОУД7), предусматривающий формальную верификацию проекта и тестирование
Цели
ОУД7 применим при разработке безопасных ОО для использования в ситуациях чрезвычайно высокого риска и/или там, где высокая ценность активов оправдывает максимальные затраты. Практическое применение ОУД7 в настоящее время ограничено ОО, которые строго ориентированы на реализацию функциональных возможностей безопасности и для которых возможен подробный формальный анализ.
Компоненты доверия
ОУД7 (см. таблицу 6.8) обеспечивает доверие посредством анализа функций безопасности с использованием для понимания режима безопасности функциональной спецификации, полной спецификации интерфейсов, руководств, проекта ОО верхнего уровня и нижнего уровня, а также структурированного представления реализации. Доверие дополнительно достигается применением формальной модели политики безопасности ОО, формального представления функциональной спецификации и проекта верхнего уровня, полуформального представления проекта нижнего уровня, а также формальной (где это требуется) и полуформальной демонстрации соответствия между ними. Кроме этого, требуется модульное, иерархическое (по уровням) и простое проектирование ОО.
Таблица 6.8 - Оценочный уровень доверия 7
Класс доверия | Компоненты доверия |
Управление конфигурацией | ACM_AUT.2 Полная автоматизация УК |
| АСМ_САР.5 Расширенная поддержка |
| ACM_SCP.3 Охват УК инструментальных средств разработки |
Поставка и эксплуатация
| ADO_DEL.3 Предотвращение модификации |
| ADO_IGS.1 Процедуры установки, генерации и запуска
|
Разработка
| ADV_FSP.4 Формальная функциональная спецификация |
| ADV_HLD.5 Формальный проект верхнего уровня |
| ADV_IMP.3 Структурированная реализация ФБО |
| ADV_INT.3 Минимизация сложности |
| ADV_LLD.2 Полуформальный проект нижнего уровня |
| ADV_RCR.3 Формальная демонстрация соответствия |
| ADV_SPM.3 Формальная модель политики безопасности ОО |
Руководства | AGD_ADM.1 Руководство администратора |
| AGD_USR.1 Руководство пользователя |
Поддержка жизненного цикла | ALC_DVS.2 Достаточность мер безопасности |
| ALC_LCD.3 Измеримая модель жизненного цикла |
| ALC_TAT.3 Соответствие всех частей объекта оценки стандартам реализации |
Тестирование
| ATE_COV.3 Строгий анализ покрытия |
| ATE_DPT.3 Тестирование на уровне реализации |
| ATE_FUN.2 Упорядоченное функциональное тестирование |
| ATE_IND.3 Полное независимое тестирование |
Оценка уязвимостей
| AVA_CCA.2 Систематический анализ скрытых каналов |
| AVA_MSU.3 Анализ и тестирование опасных состояний |
| AVA_SOF.1 Оценка стойкости функции безопасности ОО |
| AVA_VLA.4 Высокостойкий |
Анализ поддержан независимым тестированием ФБО, свидетельством разработчика об испытаниях, основанных на функциональной спецификации, проекте верхнего уровня, проекте нижнего уровня и представлении реализации, полным независимым подтверждением результатов тестирования разработчиком, анализом стойкости функций, свидетельством поиска разработчиком уязвимостей и независимым анализом уязвимостей, демонстрирующим противодействие попыткам проникновения нарушителей с высоким потенциалом нападения. Анализ также включает в себя проверку правильности систематического анализа разработчиком скрытых каналов.
ОУД7 также обеспечивает доверие посредством использования структурированного процесса разработки, средств контроля среды разработки и всестороннего управления конфигурацией ОО, включая полную автоматизацию, и свидетельства безопасных процедур поставки.
Этот ОУД представляет значимое увеличение доверия по сравнению с ОУД6, требуя всесторонний анализ, использующий формальные представления и формальное соответствие, а также всестороннее тестирование.
7 Классы, семейства и компоненты доверия
Разделы 8-14 содержат детализированные требования, представленные во всех компонентах доверия, сгруппированных в классы и семейства в алфавитном (по-латински) порядке.
8 Класс АСМ. Управление конфигурацией
Управление конфигурацией (УК) - один из методов или способов установить, что в созданном ОО реализованы функциональные требования и спецификации. УК отвечает этим целям, предъявляя требования дисциплины и контроля в процессе уточнения и модификации ОО и связанной с ним информации. Системы УК используют для обеспечения целостности частей ОО, которые они контролируют, предоставляя метод отслеживания любых изменений, и для того, чтобы все изменения были санкционированы.
На рисунке 8.1 показаны семейства этого класса и иерархия компонентов в семействах.
Рисунок 8.1 - Декомпозиция класса "Управление конфигурацией"
8.1 Автоматизация УК (ACM_AUT)
Цель
Цель привлечения инструментальных средств автоматизации УК - повышение эффективности системы УК. Несмотря на то, что как автоматизированные, так и ручные системы УК могут быть обойдены, игнорироваться или оказываться недостаточными для предотвращения несанкционированной модификации, автоматизированные системы все же менее восприимчивы к человеческому фактору - ошибке или небрежности.
Ранжирование компонентов
Компоненты в этом семействе ранжированы на основе набора элементов конфигурации, которые управляются с применением автоматизированных средств.
Замечания по применению
ACM_AUT.1.1C содержит требование, которое связано с представлением реализации ОО. Представление реализации ОО включает в себя все аппаратные, программные и программно-аппаратные средства, которые составляют ОО по существу. В случае, когда ОО состоит только из программных средств, представление реализации может состоять исключительно из исходного и объектного кода.
ACM_AUT.1.2C содержит требование, чтобы система УК предоставила автоматизированные средства для поддержки генерации ОО. При этом требуется, чтобы система УК предоставила автоматизированные средства, содействующие принятию заключения, что при генерации ОО использованы правильные элементы конфигурации.
ACM_AUT.2.5С содержит требование, чтобы система УК предоставила автоматизированные средства, позволяющие установить различия между ОО и его предыдущей версией. Если предыдущей версии ОО не существует, разработчик все равно нуждается в предоставлении автоматизированных средств, чтобы установить различия между ОО и последующей версией ОО.
ACM_AUT.1 Частичная автоматизация УК
Цели
В средах разработки, где представление реализации является сложным или создается многими разработчиками, трудно контролировать изменения без использования автоматизированных инструментальных средств. В частности, от этих автоматизированных инструментальных средств требуется способность поддерживать многочисленные изменения, которые возникают в процессе разработки, и обеспечить санкционированность этих изменений. Целью данного компонента является обеспечение контроля представления реализации с использованием автоматизированных средств.
Зависимости
| ||
АСМ_САР.3
| Средства контроля авторизации | |
Элементы действий разработчика
| ||
ACM_AUT.1.1D
| Разработчик должен использовать систему УК. | |
ACM_AUT.1.2D
| Разработчик должен представить план УК. | |
Элементы содержания и представления свидетельств
| ||
ACM_AUT.1.1C | Система УК должна предоставить автоматизированные средства, с использованием которых в представлении реализации ОО производятся только санкционированные изменения. | |
ACM_AUT.1.2C | Система УК должна предоставить автоматизированные средства для поддержки генерации ОО. | |
ACM_AUT.1.3C | План УК должен содержать описание автоматизированных инструментальных средств, используемых в системе УК. | |
ACM_AUT.1.4C | План УК должен содержать описание, как автоматизированные инструментальные средства используются в системе УК. | |
Элементы действий оценщика
| ||
ACM_AUT.1.1E | Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. | |
ACM_AUT.2 Полная автоматизация УК
Цели
В тех средах разработки, где элементы конфигурации являются сложными или создаются многими разработчиками, трудно контролировать изменения без использования автоматизированных инструментальных средств. В частности, требуется, чтобы эти автоматизированные инструментальные средства были способны поддерживать многочисленные изменения, которые возникают в процессе разработки, и обеспечить санкционированность этих изменений. Цель данного компонента - обеспечить, чтобы все элементы конфигурации контролировались с использованием автоматизированных средств.
Применение автоматизированных средств для выявления различий между версиями ОО и определение, на какие элементы конфигурации воздействует модификация других элементов конфигурации, содействуют определению воздействия изменений на последовательные версии ОО. Это, в свою очередь, может предоставить ценную информацию, позволяющую определить, реализованы ли изменения ОО во всех элементах конфигурации, требующих согласования между собой.
Зависимости
| ||
АСМ_САР.3 | Средства контроля авторизации | |
Элементы действий разработчика
| ||
ACM_AUT.2.1D
| Разработчик должен использовать систему УК. | |
ACM_AUT.2.2D
| Разработчик должен представить план УК. | |
Элементы содержания и представления свидетельств
| ||
ACM_AUT.2.1C | Система УК должна предоставить автоматизированные средства, с использованием которых в представлении реализации ОО и во всех остальных элементах конфигурации производятся только санкционированные изменения. | |
ACM_AUT.2.2C
| Система УК должна предоставить автоматизированные средства для поддержки генерации ОО. | |
ACM_AUT.2.3C
| План УК должен содержать описание автоматизированных инструментальных средств, используемых в системе УК. | |
ACM_AUT.2.4C | План УК должен содержать описание, как автоматизированные инструментальные средства используются в системе УК. | |
ACM_AUT.2.5C | Система УК должна предоставить автоматизированные средства для выявления различий между ОО и предшествующей версией. | |
ACM_AUT.2.6C
| Система УК должна предоставить автоматизированные средства для определения всех других элементов конфигурации, на которые воздействует модификация данного элемента конфигурации. | |
Элементы действий оценщика
| ||
ACM_AUT.2.1E
| Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. | |
8.2 Возможности УК (АСМ_САР)
Цели
Возможности системы УК связаны с вероятностью того, что могут произойти случайные или несанкционированные модификации элементов конфигурации. Следует, чтобы система УК обеспечила целостность ОО, начиная с ранних этапов проектирования и на протяжении всей последующей деятельности по сопровождению.
Цели этого семейства состоят в следующем:
а) обеспечение корректности и полноты ОО к моменту представления его потребителю;
б) обеспечение, чтобы никакие элементы конфигурации не были пропущены в процессе оценки;
в) предотвращение несанкционированной модификации, добавления или удаления элементов конфигурации ОО.
Ранжирование компонентов
Компоненты в этом семействе ранжированы на основе возможностей системы УК, объема документации УК, представленной разработчиком, и того, представлено ли разработчиком строгое обоснование соответствия системы УК требованиям безопасности.
Замечания по применению
АСМ_САР.2 содержит отдельные требования, которые относятся к элементам конфигурации. Семейство ACM_SCP содержит требования по составу элементов конфигурации, отслеживаемых системой УК.
АСМ_САР.2.3С содержит требование, чтобы был представлен список конфигурации. Список конфигурации содержит все элементы конфигурации, которые сопровождаются системой УК.
АСМ_САР.2.6С содержит требование, чтобы система УК уникально идентифицировала все элементы конфигурации. Также требуется, чтобы модификация элемента конфигурации приводила к назначению нового уникального идентификатора.
АСМ_САР.3.8С содержит требование, что свидетельство должно демонстрировать функционирование системы УК в соответствии с планом УК. Примерами такого свидетельства являются как документация типа образов экрана или журнала аудита для системы УК, так и подробная демонстрация системы УК разработчиком. Оценщик является ответственным за заключение, что это свидетельство является достаточным для показа, что система УК функционирует в соответствии с планом УК.
АСМ_САР.3.9С содержит требование, чтобы было представлено свидетельство, показывающее, что все элементы конфигурации поддерживаются системой УК. Так как элементом конфигурации считается элемент, включенный в список конфигурации, это требование устанавливает, что все элементы списка конфигурации поддерживаются системой УК.
АСМ_САР.4.11C содержит требование, чтобы система УК поддерживала генерацию ОО. Для этого требуется, чтобы система УК предоставила информационные и/или электронные средства, содействующие принятию заключения, что при генерации ОО использованы правильные элементы конфигурации.
АСМ_САР.1 Номера версий
Цели
Требуется уникальная маркировка для обеспечения однозначности в определении оцениваемого экземпляра ОО. Обозначение ОО соответствующей маркировкой дает пользователям ОО возможность знать, какой экземпляр ОО они используют.
Зависимости отсутствуют.
| |
Элементы действий разработчика
| |
АСМ_САР.1.1D | Разработчик должен предоставить маркировку для ОО. |
Элементы содержания и представления свидетельств
| |
АСМ_САР.1.1С | Маркировка ОО должна быть уникальна для каждой версии ОО. |
АСМ_САР.1.2С | ОО должен быть помечен маркировкой. |
Элементы действий оценщика
| |
ACM_CAP.1.1E | Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. |
АСМ_САР.2 Элементы конфигурации
Цели
Требуется уникальная маркировка для обеспечения однозначности в определении оцениваемого экземпляра ОО. Обозначение ОО соответствующей маркировкой дает пользователям ОО возможность знать, какой экземпляр ОО они используют.
Уникальная идентификация элементов конфигурации ведет к лучшему пониманию состава ОО, что, в свою очередь, способствует определению тех элементов, на которые направлены требования оценки для ОО.
Зависимости отсутствуют.
| |
Элементы действий разработчика
| |
АСМ_САР.2.1D
| Разработчик должен предоставить маркировку для ОО. |
ACM_CAP.2.2D | Разработчик должен использовать систему УК. |
ACM_CAP.2.3D
| Разработчик должен представить документацию УК. |
Элементы содержания и представления свидетельств
| |
АСМ_САР.2.1С | Маркировка ОО должна быть уникальна для каждой версии ОО. |
АСМ_САР.2.2С
| ОО должен быть помечен маркировкой. |
АСМ_САР.2.3С | Документация УК должна включать в себя список конфигурации. |
АСМ_САР.2.4С | Список конфигурации должен содержать описание элементов конфигурации, входящих в ОО. |
АСМ_САР.2.5С | Документация УК должна содержать описание метода, используемого для уникальной идентификации элементов конфигурации. |
АСМ_САР.2.6С | Система УК должна уникально идентифицировать все элементы конфигурации. |
Элементы действий оценщика
| |
АСМ_САР.2.1Е
| Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств |
АСМ_САР.3 Средства контроля авторизации
Цели
Требуется уникальная маркировка для обеспечения однозначности в определении оцениваемого экземпляра ОО. Обозначение ОО соответствующей маркировкой дает пользователям ОО возможность знать, какой экземпляр ОО они используют.
Уникальная идентификация элементов конфигурации ведет к лучшему пониманию состава ОО, что, в свою очередь, способствует определению тех элементов, на которые направлены требования оценки для ОО.
Поддержанию целостности ОО способствуют применение средств контроля, предупреждающих выполнение несанкционированных модификаций ОО, а также обеспечение надлежащих функциональных возможностей и использование системы УК.
Зависимости
| |||
ACM_SCP.1
| Охват УК объекта оценки | ||
ALC_DVS.1 | Идентификация мер безопасности | ||
Элементы действий разработчика
| |||
АСМ_САР.3.1D | Разработчик должен предоставить маркировку для ОО. | ||
ACM_CAP.3.2D | Разработчик должен использовать систему УК. | ||
АСМ_САР.3.3D | Разработчик должен представить документацию УК. | ||
Элементы содержания и представления свидетельств
| |||
АСМ_САР.3.1С | Маркировка ОО должна быть уникальна для каждой версии ОО. | ||
ACM_CAP.3.2C | ОО должен быть помечен маркировкой. | ||
АСМ_САР.3.3С | Документация УК должна включать в себя список конфигурации и план УК. | ||
АСМ_САР.3.4С | Список конфигурации должен содержать описание элементов конфигурации, входящих в ОО. | ||
АСМ_САР.3.5С | Документация УК должна содержать описание метода, используемого для уникальной идентификации элементов конфигурации. | ||
АСМ_САР.3.6С | Система УК должна уникально идентифицировать все элементы конфигурации. | ||
АСМ_САР.3.7С | План УК должен содержать описание, как используется система УК. | ||
АСМ_САР.3.8С | Свидетельство должно демонстрировать, что система УК действует в соответствии с планом УК. | ||
АСМ_САР.3.9С | Документация УК должна содержать свидетельство, что система УК действительно сопровождала и продолжает эффективно сопровождать все элементы конфигурации. | ||
АСМ_САР.3.10С | Система УК должна предусмотреть такие меры, при которых в элементах конфигурации могут быть сделаны только санкционированные изменения. | ||
Элементы действий оценщика
| |||
АСМ_САР.3.1Е | Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. | ||
АСМ_САР.4 Поддержка генерации, процедуры приемки
Цели
Требуется уникальная маркировка для обеспечения однозначности в определении оцениваемого экземпляра ОО. Обозначение ОО соответствующей маркировкой дает пользователям ОО возможность знать, какой экземпляр ОО они используют.
Уникальная идентификация элементов конфигурации ведет к лучшему пониманию состава ОО, что, в свою очередь, способствует определению тех элементов, на которые направлены требования оценки для ОО.
Поддержанию целостности ОО способствует применение средств контроля, предупреждающих выполнение несанкционированных модификаций ОО, а также обеспечение надлежащих функциональных возможностей и использование системы УК.
Предназначение процедур приемки - подтвердить, что любое создание или модификация элементов конфигурации санкционировано.
Зависимости
| |||
ACM_SCP.1 | Охват УК объекта оценки | ||
ALC_DVS.1 | Идентификация мер безопасности | ||
Элементы действий разработчика
| |||
АСМ_САР.4.1D
| Разработчик должен предоставить маркировку для ОО. | ||
ACM_CAP.4.2D
| Разработчик должен использовать систему УК. | ||
ACM_CAP.4.3D | Разработчик должен представить документацию УК. | ||
Элементы содержания и представления свидетельств
| |||
АСМ.САР.4.1С | Маркировка ОО должна быть уникальна для каждой версии ОО. | ||
АСМ_САР.4.2С
| ОО должен быть помечен маркировкой. | ||
АСМ_САР.4.3С | Документация УК должна включать в себя список конфигурации, план УК и план приемки. | ||
АСМ_САР.4.4С | Список конфигурации должен содержать описание элементов конфигурации, входящих в ОО. | ||
АСМ_САР.4.5С | Документация УК должна содержать описание метода, используемого для уникальной идентификации элементов конфигурации. | ||
АСМ_САР.4.6С | Система УК должна уникально идентифицировать все элементы конфигурации. | ||
АСМ_САР.4.7С | План УК должен содержать описание, как используется система УК. | ||
АСМ_САР.4.8С | Свидетельство должно демонстрировать, что система УК действует в соответствии с планом УК. | ||
АСМ_САР.4.9С | Документация УК должна содержать свидетельство, что система УК действительно сопровождала и продолжает эффективно сопровождать все элементы конфигурации. | ||
АСМ_САР.4.10С | Система УК должна предусмотреть такие меры, при которых в элементах конфигурации могут быть сделаны только санкционированные изменения. | ||
АСМ_САР.4.11С | Система УК должна поддерживать генерацию ОО. | ||
АСМ_САР.4.12С | План приемки должен содержать описание процедур, используемых для приемки модифицированного или вновь созданного элемента конфигурации как части ОО. | ||
Элементы действий оценщика
| |||
АСМ_САР.4.1Е | Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств. | ||
АСМ_САР.5 Расширенная поддержка
Цели
Требуется уникальная маркировка для обеспечения однозначности в определении оцениваемого экземпляра ОО. Обозначение ОО соответствующей маркировкой дает пользователям ОО возможность знать, какой экземпляр ОО они используют.
Уникальная идентификация элементов конфигурации ведет к лучшему пониманию состава ОО, что, в свою очередь, способствует определению тех элементов, на которые направлены требования оценки для ОО.
Поддержанию целостности ОО способствуют применение средств контроля, предупреждающих выполнение несанкционированных модификаций ОО, а также обеспечение надлежащих функциональных возможностей и использование системы УК.
Для получения доступа к полной версии без ограничений вы можете выбрать подходящий тариф или активировать демо-доступ.