351735622

ФЕДЕРАЛЬНОЕ АГЕНТСТВО
ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ
НАЦИОНАЛЬНЫЙ
СТАНДАРТ
РОССИЙСКОЙ
ФЕДЕРАЦИИ
ГОСТ Р ИСО/МЭК 15408-
1-20ХХ
(проект,
первая редакция)
Информационная технология
МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ.
КРИТЕРИИ ОЦЕНКИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ
ТЕХНОЛОГИЙ
Ч а с т ь 1.
Введение и общая модель
ISO/IEC 15408-1:2022
INFORMATION SECURITY, CYBERSECURITY AND PRIVACY PROTECTIONEVALUATION CRITERIA FOR IT SECURITYPART 1. INTRODUCTION AND GENERAL MODEL
(IDT)
Москва
Российский институт стандартизации
202Х
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Предисловие
1 РАЗРАБОТАН Федеральной службой по техническому и экспортному контролю
(ФСТЭК России), Обществом с ограниченной ответственностью «Центр безопасности ин­
формации» (ООО «ЦБИ»), Федеральным автономным учреждением «Государственный
научно-исследовательский испытательный институт проблем технической защиты ин­
Федеральной
формации
службы
по
и
техническому
контролю»
экспортному
(ФАУ «ГНИИИ ПТЗИ ФСТЭК России»)
2 ВНЕСЕН Техническим
по
комитетом
ТК 362
стандартизации
«Защита
информации»
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по
№
техническому регулированию и метрологии от
4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 15408­
«Информационная
1:2022
кибербезопасность
безопасность,
и
защита
конфиденциальности. Критерии оценки безопасности информационных технологий. Часть
1. Введение и общая модель» (ISO/IEC 15408-1:2022 «Information security, cybersecurity
and privacy protection - Evaluation criteria for IT security - Part 1: Introduction and general
model».
При
настоящего
применении
стандарта
рекомендуется
использовать
вместо ссылочных международных стандартов соответствующие им национальные
стандарты Российской Федерации.
ВЗАМЕН ГОСТ Р ИСО/МЭК 15408-1-2013
5
Правила применения настоящего стандарта установлены в
статье
26
Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской
Федерации». Информация об изменениях к настоящему стандарту публикуется в
ежегодном (по состоянию на 1 января текущего года) информационном указателе
«Национальные стандарты», а официальный текст изменений и поправок - в
ежемесячном информационном указателе «Национальные стандарты». В случае
пересмотра
(замены)
уведомление
будет
информационного
или отмены настоящего
опубликовано
указателя
в
стандарта
ближайшем
«Национальные
соответствующее
выпуске
стандарты».
ежемесячного
Соответствующая
информация, уведомление и тексты размещаются также в информационной системе
общего
пользования
-
на
официальном
сайте
Федерального
агентства
техническому регулированию и метрологии в сети Интернет (www.rst.gov.ru)
II
по
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
© Оформление. ФГБУ «РСТ», 202Х
Настоящий стандарт не может быть полностью или частично воспроизведен,
тиражирован и распространен в качестве официального издания без разрешения
Федерального агентства по техническому регулированию и метрологии
III
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Содержание
1 Область применения..............................................................................................................
2 Нормативные ссылки............................................................................................................
3 Термины и определения.......................................................................................................
4 Сокращения, обозначения....................................................................................................
5 Обзор.......................................................................................................................................
6 Общая модель.......................................................................................................................
7 Специфицирование требований безопасности...................................................................
8 Компоненты безопасности....................................................................................................
9 Пакеты.....................................................................................................................................
10 Профили защиты.................................................................................................................
11 Модульная конфигурация требований..............................................................................
12 Задание по безопасности...................................................................................................
13 Оценка и результаты оценки..............................................................................................
14 Объединение доверия........................................................................................................
Приложение А (обязательное) Спецификация пакетов.........................................................
Приложение В (обязательное) Спецификация профилей защиты........................................
Приложение С (обязательное) Спецификация ПЗ-модулей и ПЗ-конфигураций...............
Приложение D (обязательное) Спецификация заданий по безопасности и ЗБ с прямым
обоснованием ........................................................................
Приложение Е (обязательное) Соответствие ПЗ/ПЗ-конфигурации....................................
Библиография............................................................................................................................
IV
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Введение
Настоящая часть ИСО/МЭК 15408 обеспечивает сопоставимость результатов неза­
висимых оценок безопасности. В ИСО/МЭК 15408 это достигается предоставлением еди­
ного набора требований к функциональным возможностям безопасности продуктов ИТ и к
мерам доверия, применяемым к этим продуктам ИТ при оценке безопасности. Данные
продукты ИТ могут быть реализованы в виде аппаратного, программно-аппаратного или
программного обеспечения.
В процессе оценки достигается определенный уровень уверенности в том, что
функциональные возможности безопасности таких продуктов ИТ, а также меры доверия,
предпринятые по отношению к таким продуктам ИТ, отвечают предъявляемым требова­
ниям. Результаты оценки могут помочь потребителям решить, отвечают ли продукты ИТ
их потребностям в безопасности.
Серия ИСО/МЭК 15408 полезна в качестве руководства при разработке, оценке
и/или приобретении продуктов ИТ с функциональными возможностями безопасности.
В ИСО/МЭК 15408 предусмотрена гибкость, допускающая применение конкретных
методов оценки по отношению к свойствам безопасности продуктов ИТ. Пользователи
настоящего стандарта должны исключить возможность неправильного использования
указанной гибкости стандарта. Например, использование ИСО/МЭК 15408 в сочетании с
неподходящими методами оценки, неприменимыми свойствами безопасности или ненад­
лежащими продуктами ИТ может привести к незначимым результатам оценки.
Следовательно, тот факт, что продукт ИТ был оценен, имеет значение только в
контексте оцененных свойств безопасности и методов оценки, которые использовались.
Органам оценки рекомендуется тщательно проверить продукты, свойства и методы, что­
бы сделать заключение, что оценка обеспечивает значимые результаты. Кроме того, по­
требителям оцененных продуктов рекомендуется тщательно рассмотреть этот контекст,
чтобы сделать заключение, является ли оцененный продукт соответствующим и приме­
нимым для их конкретной ситуации и потребностей.
ИСО/МЭК 15408 направлен на защиту информации от несанкционированного рас­
крытия, модификации или потери возможности ее использования. Категории защиты, от­
носящиеся к этим трем типам нарушения безопасности, обычно называют конфиденци­
альностью, целостностью и доступностью соответственно. ИСО/МЭК 15408 может быть
также применим к тем аспектам безопасности ИТ, которые выходят за пределы этих трех
V
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
категорий. ИСО/МЭК 15408 применим к рискам, возникающим в результате действий че­
ловека (злоумышленных или иных), и к рискам, возникающим в результате действий, не
связанных с человеком.
Некоторые
вопросы
рассматриваются
как лежащие
вне
области
действия
ИСО/МЭК 15408, поскольку они требуют привлечения специальных методов или являют­
ся смежными по отношению к безопасности ИТ. Часть из них перечислена ниже:
серия ИСО/МЭК 15408 не содержит критериев оценки безопасности, касающихся
административных мер безопасности, непосредственно не относящихся к функциональ­
ным возможностям безопасности ИТ. Известно, однако, что безопасность в значительной
степени может быть достигнута или поддерживаться административными мерами, такими
как организационные меры, меры управления персоналом, меры управления физической
защитой и процедурные меры;
в серии ИСО/МЭК 15408 не рассматривается методология оценки, в рамках кото­
рой могут применяться конкретные критерии;
Примечание - Данная методология приведена в ИСО/МЭК 18045. ИСО/МЭК 15408-4 может
быть использован для получения дальнейших действий и методов оценки на основе стандарта ИСО/МЭК
18045.
в ИСО/МЭК 15408 не рассматривается административно-правовая структура, в
рамках которой критерии могут применяться органами оценки. Тем не менее, ожидается,
что серия ИСО/МЭК 15408 будет использоваться в целях оценки в контексте такой струк­
туры;
процедуры использования результатов оценки при аттестации находятся вне обла­
сти действия серии ИСО/МЭК 15408. Аттестация является административным процессом,
посредством которого предоставляются полномочия на использование продуктов ИТ (или
их совокупности) в конкретной среде функционирования, включая все их части, не свя­
занные с ИТ. Результаты процесса оценки являются исходными данными для процесса
аттестации. Однако, поскольку для оценки не связанных с ИТ свойств, а также их соотне­
сения с аспектами безопасности ИТ более приемлемы другие способы, аттестующие
должны применять для этих аспектов отдельные положения.
Критерии для оценки специфических качеств криптографических алгоритмов не
входят в ИСО/МЭК 15408.
VI
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Информационная технология
МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ
КРИТЕРИИ ОЦЕНКИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ
ТЕХНОЛОГИЙ
Ч а с т ь 1. Введение и общая модель
Information technology. Security techniques. Evaluation criteria for IT security.
Part 1. Introduction and general model
Дата введения -
1 Область применения
Настоящий стандарт устанавливает основные понятия и принципы оценки без­
опасности ИТ, а также определяет общую модель оценки, которые представлены в
разных частях стандарта, предназначенного в целом для использования в качестве ос­
новы при оценке характеристик безопасности продуктов ИТ.
В данном стандарте представлен краткий обзор и описание всех частей
ИСО/МЭК 15408; определены термины и сокращения, используемые во всех частях
стандарта; установлено основное понятие объекта оценки (ОО), контекста оценки, опи­
сана целевая аудитория, которой адресованы критерии оценки. Представлены основ­
ные концепции безопасности, необходимые для оценки продуктов ИТ.
В стандарте представлены:
- ключевые концепции профилей защиты (ПЗ), модулей ПЗ, конфигураций ПЗ,
пакетов, заданий по безопасности (ЗБ) и типов соответствия;
-
описание организации компонентов безопасности;
- различные операции, с помощью которых функциональные компоненты и ком­
поненты доверия, указанные в ИСО/МЭК 15408-2 и ИСО/МЭК 15408-3, могут быть
адаптированы с использованием разрешенных операций над ними;
-
общая информация о методах оценки, приведенных в ИСО/МЭК 18045;
- руководство по применению ИСО/МЭК 15408-4 с целью разработки методов
оценки и деятельности по оценке, основанных на ИСО/МЭК 18045;
1
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
- общая информация о предопределенных оценочных уровнях доверия (ОУД),
определенных в ИСО/МЭК 15408-5; и
-
информация о масштабах систем оценки.
2 Нормативные ссылки
Указанные в данном разделе документы являются необходимыми для примене­
ния настоящего стандарта. Для датированных ссылок используют только указанное из­
дание. Для недатированных ссылок - последнее издание со всеми изменениями и до­
полнениями.
ИСО/МЭК 15408-2. Информационная технология. Методы и средства обеспече­
ния безопасности.
Критерии оценки безопасности информационных технологий.
Часть 2. Функциональные компоненты безопасности;
ИСО/МЭК 15408-3. Информационная технология. Методы и средства обеспече­
ния безопасности.
Критерии оценки безопасности информационных технологий.
Часть 3. Компоненты доверия к безопасности;
ИСО/МЭК 15408-5. Информационная технология. Методы и средства обеспече­
ния безопасности.
Критерии оценки безопасности информационных технологий.
Часть 5. Предопределенные пакеты требований безопасности;
ИСО/МЭК 18045. Информационная технология. Методы и средства обеспечения
безопасности. Критерии оценки безопасности информационных технологий. Методоло­
гия оценки безопасности информационных технологий.
Примечание - При
пользовании
настоящим
стандартом
целесообразно
проверить
действие ссылочных стандартов в информационной системе общего пользования - на официальном
сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по
ежегодному информационному указателю «Национальные стандарты», который опубликован по
состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя
«Национальные стандарты» за текущий год. Если заменен ссылочный стандарт, на который дана
недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом
всех внесенных в данную версию изменений. Если заменен ссылочный стандарт, на который дана
датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годом
утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный стандарт, на
который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана
ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный
стандарт отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять
в части, не затрагивающей эту ссылку.
2
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
3 Термины и определения
В настоящем стандарте применены термины и определения, приведенные в
ИСО/МЭК 24765, ИСО/МЭК 15408-2, ИСО/МЭК 15408-3, ИСО/МЭК 18045, а также дру­
гие.
ИСО и МЭК поддерживают терминологические базы данных для использования
в стандартизации по следующим адресам:
- Интернет-платформа ИСО: доступна по адресу http://www.iso.org/obp
- МЭК Электропедия: доступно на http://www.electropedia.org/
3.1 действие: Элемент действия оценщика или разработчика ИСО/МЭК 15408-3.
Примечание - Эти действия либо явно указаны как действия оценщика, либо неявно вы­
текают из действий разработчика (подразумеваемые действия оценщика) в рамках компонентов доверия
ИСО/МЭК 15408-3.
3.2 администратор: Сущность, имеющая определенный уровень доверия по от­
ношению ко всем политикам, реализуемым ФБО.
Примечание - Не все ПЗ или ЗБ предполагают одинаковый уровень доверия для адми­
нистраторов. Обычно предполагается, что администраторы всегда придерживаются политик в ЗБ ОО.
Некоторые из этих политик могут быть связаны с функциональными возможностями ОО, а другие - со
средой функционирования.
3.3 негативное действие: Действие, выполняемое источником угрозы по отно­
шению к активам.
3.4 актив: Сущность, предположительно представляющая ценность для вла­
дельца ОО.
3.5 назначение: Спецификация определенного параметра в функциональном
компоненте или компоненте доверия.
3.6 доверие: Основание для уверенности в том, что ОО отвечает конкретным
ФТБ.
3.7 пакет доверия: Именованный набор требований доверия к безопасности.
Примечание - Пример: «Оценочный уровень доверия 3».
3.8 потенциал атаки: Мера усилий, затрачиваемых при использовании уязвимо­
сти ОО.
Примечание - Усилия выражаются как функция свойств, связанных с нарушителем
(например, опыт, ресурсы и мотивация), и свойств, связанных с самой уязвимостью (например: окно
возможностей, время воздействия).
3
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
3.9 поверхность атаки: Набор логических или физических интерфейсов к цели,
состоящий из точек, через которые может быть осуществлена попытка доступа к цели
и ее функциям.
Примечания
1
Частью физической поверхности атаки для устройства является корпус платежного терминала.
2 Протоколы связи, доступные для подключения к сетевому устройству, являются частью логиче­
ской поверхности атаки для этого сетевого устройства.
3.10 расширение: Добавление к определенному пакету одного или нескольких
требований.
Примечания
1 В случае с функциональным пакетом такое расширение рассматривается только в контексте
одного пакета, но не в контексте других пакетов, ПЗ или ЗБ.
2
В случае с пакетом доверия, расширение относится к одному или нескольким ТДБ.
3.11 уполномоченный пользователь: Сущность, которой в соответствии сФТБ
разрешено выполнять определенную операцию в отношении ОО.
3.12 базовый компонент: Независимая сущность в многокомпонентном продук­
те, предоставляющий услуги и ресурсы одному или нескольким зависимым компонен­
там.
Примечание - В частности, это относится к «составным ОО» и «составным продуктам /
составным ОО».
3.13 базовый профиль защиты: Профиль защиты, указанный в ПЗ-модуле, как
часть базы ПЗ-модуля этого ПЗ-модуля, используется в качестве основы для создания
ПЗ-конфигурации.
3.14 базовый модуль ПЗ: ПЗ-модуль, указанный в другом ПЗ-модуле, как часть
базы ПЗ-модуля этого ПЗ-модуля, используемого в качестве основы для создания ПЗ-
конфигурации.
Примечание - Обозначение базового ПЗ-модуля в определенном ПЗ-модуле неявно
включает в себя базу ПЗ- модуля ПЗ.
3.15 базовый ОО: Базовый компонент, который сам является предметом оцен­
ки.
Примечание - В частности, это относится к «составным ОО» и «составным продуктам /
составным ОО».
3.16 класс: Совокупность семейств, объединенных общим назначением, указан­
ных в ИСО/МЭК 15408-2 и ИСО/МЭК 15408-3, которые разделяют общую направлен­
ность.
4
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
3.17 компонент: Наименьший выбираемый набор элементов, на котором могут
быть основаны требования.
3.18 компонент <состав>: Сущность, которая представляет ресурсы и услуги в
определенном продукте.
3.19 компонентный: ОО, являющийся компонентом другого составного ОО.
3.20 составной пакет доверия: Пакет доверия, состоящий из компонентов, пре­
имущественно взятых из класса АСО, представляющий точку на предопределенной
шкале доверия композиции доверия к составу.
3.21 составной ОО: ОО, состоящий только из двух или более отдельно иденти­
фицированных компонентов с отношениями безопасности между их ФБО.
Примечание - Каждый из отдельно идентифицированных компонентов сам по себе явля­
ется ОО.
3.22 составная оценка: Оценка составного ОО с использованием специальной
техники оценки, применимой к составным ОО.
Примечание - Этот метод оценки относится к классу доверия АСО, который определен в
ИСО/МЭК 15408-3.
3.23 композиционная оценка: Оценка комплекса ОО/продукт с использованием
метода составной оценки.
Примечание - Этот метод оценки относится к семействам доверия, связанным с СОМР,
которые указаны в стандарте ИСО/МЭК 15408-3 для классов ADV, ALC, ASE, АТЕ и AVA.
3.24 составной продукт: Продукт, состоящий из двух или более компонентов,
которые могут быть организованы в два уровня: уровень одного уже оцененного базо­
вого компонента (базовый ОО) и уровень одного зависимого компонента.
3.25 композиционный ОО: Часть составного продукта, включающая базовый
ОО и зависимый компонент.
Примечания
1 Зависимый компонент в составном ОО может состоять из одного или нескольких зависимых
компонентов. Для упрощения они рассматриваются как «один зависимый компонент».
2 Композиционный ОО может содержать части, независимые от базового компонента или базо­
вого ОО соответственно. Для упрощения такие части считаются принадлежащими зависимому компо­
ненту.
3 При
поэтапном
подходе
составная
оценка
может
применяться
к
многокомпонентно-
му/многослойному продукту столько раз, сколько необходимо.
3.26 управление конфигурациями: Дисциплина, применяющая техническое и
административное руководство и наблюдение, чтобы: идентифицировать и документи­
ровать функциональные и физические характеристики элемента конфигурации, кон­
5
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
тролировать изменения этих характеристик, регистрировать и сообщать о состоянии
обработки изменений и реализации, а также проверять соответствие установленным
требованиям.
3.27 система управления конфигурациями: Набор процедур и инструментов
(включая их документацию), используемых разработчиком для разработки и поддержа­
ния конфигураций своих продуктов в течение их жизненного цикла.
Примечание - Системы управления конфигурацией могут иметь разную степень строго­
сти и функциональность. На более высоких уровнях системы управления конфигурацией могут быть ав­
томатизированы с устранением недостатков, контролем изменений и другими механизмами прослежи­
вания.
3.28 противодействовать: Действовать или реагировать на конкретную угрозу
таким образом, чтобы угроза была устранена или смягчена.
3.29 доказуемое соответствие: Связь между ПЗ/ЗБ и или ЗБ и конфигурацией
ПЗ, при которой ЗБ обеспечивает решение общей проблемы безопасности, опреде­
ленной в ПЗ, при которой ПЗ/ЗБ обеспечивает эквивалентное или более ограничитель­
ное решение общей проблемы безопасности в конфигурации ПЗ/ЗБ.
3.30 зависимость: Такая взаимосвязь между компонентами, когда ПЗ, ЗБ, функ­
циональный пакет или пакет доверия, включающий некий компонент, также включает
любые другие компоненты, которые определены как зависимые или включают обосно­
вания того, почему они таковыми не являются.
3.31 зависимый компонент: Зависимая сущность в многокомпонентном продук­
те, который полагается на предоставление услуг и ресурсов одним или несколькими
базовыми компонентами.
Примечание - В частности, это относится к «составным ОО» и «составным продуктам/составным ОО».
3.32 зависимый ОО: Зависимый компонент, который сам является объектом
оценки.
Примечание - Это
относится
к
«составным
ОО»,
но
не
к
«составным
продук-
там/составным ОО».
3.33 разработчик: Организация, ответственная за разработку ОО.
3.34 прямое обоснование: Тип профиля защиты, ПЗ-модуля или задания по
безопасности, в котором элементы ОПБ непосредственно сопоставляются с ФТБ и,
возможно, с целями безопасности для среды функционирования.
Примечание - Прямое обоснование не включает цели безопасности для ОО.
6
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
3.35 элемент: Неделимое изложение некоторой потребности в безопасности,
присвоенное ТДБ или ФТБ.
3.36 сущность: Идентифицируемый элемент, который описывается набором или
подборкой свойств.
Примечание - Сущности включают субъекты, пользователи (включая сторонние ИТпродукты), объекты, информацию, сеансы и/или ресурсы.
3.37 оценивание: Процедура оценивания ПЗ-конфигурации, ПЗ, ЗБ или ОО в
сравнении с определенными критериями.
3.38 оценочное действие: Методика проверки, полученная из единиц измере­
ния выполненной работы, определенных в ИСО/МЭК 18045.
Примечание - Концепция оценочных действий и объединение оценочных действий в “ме­
тоды оценивания” изложена в ИСО/МЭК 15408-4.
3.39 оценочный уровень доверия: Правильно сформированный пакет требо­
ваний безопасности, определенных ИСО/МЭК 15408-3 и взятых из ИСО/МЭК 15408-5,
представляющий некоторое положение на предопределенной шкале доверия.
3.40 орган по оцениванию: Орган, осуществляющий систему оценивания.
Примечание - Применяя систему оценки, орган по оцениванию устанавливает стандарты
и контролирует качество оценивания, проводимых органами в конкретной системе сертификации.
3.41 метод оценивания: Совокупность одного или нескольких оценочных дей­
ствий, производных от рабочих единиц ИСО/МЭК 18045 для применения в определен­
ном контексте.
3.42 система оценивания: Правила, процедуры и менеджмент проведения оце­
нивания безопасности ИТ-продуктов, реализуемые во всех частях ИСО/МЭК 15408.
Примечания
1 Частью системы оценивания обычно является административно-правовая структура. Такая
структура не входит в сферу применения ИСО/МЭК 15408.
2 Цель схемы оценивания - поддержание высоких стандартов компетентности и беспристрастно­
сти, а также обеспечение последовательности оценивания.
3 Система оценивания обычно устанавливается органом оценивания, который определяет среду
оценки, включая критерии и методологию, необходимые для проведения оценивания безопасности ИТ.
3.43 технический отчет об оценивании: Документация общего заключения и
его обоснования, подготовленная оценщиком и представленная в орган оценивания.
3.44 технический отчет об оценивании для составного технического отчета
об оценивании: Документация, предназначенная для использования в рамках подхо­
да к составному оцениванию и полученная оценщиком базового компонента из полного
отчета для оцениваемого базового компонента.
7
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Примечания
1 Отчет для составного оценивания принадлежит базовому компоненту и его оцениванию и ис­
пользуется для оценивания составного продукта с таким базовым компонентом при использовании под­
хода составного оценивания.
2 Отчет для составного оценивания, относящегося к базовому компоненту, составляется для
предоставления достаточной информации для составного оценивания составного продукта, которая
включает такой уже оцененный базовый компонент. Это позволяет оценщику составного продукта и со­
ответствующему органу оценивания составного продукта понять пути атаки и тесты, которые были рас­
смотрены и выполнены для базового компонента, а также эффективность контрмер, реализованных ба­
зовым компонентом.
3.45 оценщик: Лицо, назначенное для проведения оценивания в соответствии с
данным стандартом оценивания и связанной с ним методологией оценивания.
Примечание - Примером стандартов оценивания оценки является серия ИСО/МЭК 15408
с соответствующей методологией оценки, приведенной в ИСО/МЭК 18045.
3.46 точное соответствие: Требование безопасности, разработанное в соответ­
ствии с правилами, приведенными в ИСО/МЭК 15408-1, но не указанное в какой-либо
части иерархических отношений серии ИСО/МЭК 15408 между ПЗ или конфигурацией и
ЗБ, в которых сформулированы все требования ЗБ только из конфигурации ПЗ/ПЗ.
Примечание - ЗБ может заявлять о точном соответствии одному или нескольким ПЗ, но
только одной конфигурации ПЗ,
3.47 используемая уязвимость: Слабое место ОО, которое может быть ис­
пользована для нарушения ФТБ в среде функционирования ОО.
3.48 расширенное требование безопасности: Требование безопасности, раз­
работанное в соответствии с правилами, приведенными в ИСО/МЭК 15408-1, но не
указанное ни в одной части серии ИСО/МЭК 15408.
Примечания
1 Расширенным требованием безопасности может быть ТДБ или ФТБ.
2 Определения расширенных требований безопасности даны в расширенных определениях ком­
понентов.
3.49 внешняя сущность - пользователь: Техническая антропогенная система
или один из ее компонентов, взаимодействующий с ОО за пределами ОО.
3.50 семейство: Набор компонентов, которые имеют схожую цель, но различа­
ются акцентированием или строгостью.
3.51 функциональный пакет: Именованный набор функциональных требований
безопасности, которые могут сопровождаться ОПБ и целями безопасности, выведен­
ными из этого ПБОр.
8
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
3.52 глобальный пакет доверия: Пакет доверия, который применяется ко все­
му ОО при оценивании с несколькими довериями.
Примечание - Глобальный пакет доверия может содержать расширенные компоненты
доверия.
3.53 руководящая документация: Документация, содержащая описание по­
ставки, подготовки, работы, управления и/или использования ОО.
3.54 представление реализации: Наименее абстрактное представление ФБО, в
частности то, которое используется для создания самих ФБО без дальнейшей дора­
ботки проекта.
Примечание - Исходный код, который затем компилируется, или чертеж оборудования,
который используется для создания реального оборудования, являются примерами частей представле­
ния реализации.
3.55 внутренне непротиворечивый: Характеризует отсутствие очевидных про­
тиворечий между любыми аспектами сущности.
Примечание - Применительно к документации это означает, что в ней не может быть из­
ложено что-либо, воспринимаемое как противоречащее чему-то другому.
3.56 интерпретация: Уточнение или ужесточение требований серии ИСО/МЭК
15408 или системных требований.
3.57 итерация: Использование одного и того же компонента для выражения двух
или более различных требований.
3.58 разделение на уровни: Метод проектирования, при котором отдельные
группы компонентов иерархически организованы для выполнения отдельных обязан­
ностей таким образом, что группа компонентов зависит от групп компонентов, распо­
ложенных ниже нее в иерархии служб, и предоставляет свои услуги группам компонен­
тов, расположенным выше нее.
3.59 модуль: Архитектурная единица, указанная на уровне, подходящем для ее
реализации.
Примечания
1 Свойства, относящиеся к разделению ОО на модули, описаны в ИСО/МЭК 15408-3, в семей­
ствах ADV_TDS и ADVJNT.
2 Термин применяется в стандарте 18045.
3.60 многоуровневая оценка доверия: Оценивание ОО с использованием ПЗ,
где каждый компонент связан со своим собственным набором требований доверия.
Примечание - По крайней мере, один из компонентов ПЗ- конфигурации содержит набор
требований доверия, отличный от других.
9
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
3.61 объект: Сущность в ОО, которая содержит или получает информацию и над
которой субъекты выполняют операции.
3.62 операция: Конкретный тип действия, выполняемого субъектом над объек­
том.
3.63 среда функционирования: Среда, в которой работает ОО, состоящая из
всего, что находится за пределами границ ОО.
3.64 дополнительные (опциональные) функциональное требование без­
опасности: ФТБ в профиле защиты, функциональном пакете или ПЗ-модуле, которое
вносит вклад в заявленный аспект описания проблемы безопасности ПЗ, но включение
которого в список ФТБ соответствующих ПЗ или ЗБ не является обязательным.
Примечание - Дополнительное (опциональное) ФТБ может быть связано с соответству­
ющими угрозами элементов ОПБ и/или ПБОр, указанные в основной части ПЗ, функционального пакета
или ПЗ-модуля, или ссылаться на связанные элементы/цели ПБОр, которые сами по себе являются до­
полнительным (в том, что они адресованы исключительно дополнительным ФТБ).
3.65 политика обеспечения безопасности организаций: Совокупность правил,
процедур или руководящих принципов в области безопасности для организаций.
Примечание - Политика может относиться к конкретной оперативной среде.
3.66 общее заключение: Заявление оценщика в отношении результата оцени­
вания.
Примечание - Заявление может быть выражено как «прошел» или «не прошел».
3.67 потенциальная уязвимость: Предполагаемое, но не подтвержденное сла­
бое место.
Примечание - Предположение возникает в силу постулируемого пути атаки для наруше­
ния ФТБ.
3.68 профиль защиты: Независимое от реализации изложение требований без­
опасности для определенного типа ОО.
3.69 конфигурация профиля защиты: Независимое от реализации заявление о
потребностях в безопасности для типа ОО, содержащего по меньшей мере один ПЗ и
дополнительный непустой набор ПЗ и ПЗ-модулей (с соответствующими базами ПЗ -
модулей).
3.70 конфигурации профиля защиты: ПЗ или ПЗ-модуль, включенный в ПЗ-
конфигурацию.
3.71 профиль защиты - модуль (ПЗ-модуль): Независимое от реализации из­
ложение требований безопасности для типа ОО, дополняющего один или несколько
базовых профилей защиты и, возможно, некоторые базовые ПЗ-модули.
10
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
3.72 база профилей защиты - модулей (база ПЗ-модулей): Набор ПЗ-модулей
и/или ПЗ,
определенных ПЗ-модулем в качестве основы для построения ПЗ-
конфигурации.
Примечание - Понятие базы ПЗ-модуля является итеративным в том смысле, что база
определенного ПЗ-модуля может содержать другой ПЗ-модуль со своей собственной базой, причем эта
база содержит определенный ПЗ-модуль и т.д. Однако эта «цепочка» заканчивается ПЗ модулем, в ос­
нове которого только ПЗ.
3.73 уточнение: Добавление деталей в компонент безопасности.
3.74 остаточная уязвимость: Слабое место, которое не может быть использо­
вано в среде функционирования ОО, но может быть использовано для нарушения ФТБ
нарушителем с большим потенциалом атаки, чем ожидается в среде функционирова­
ния ОО.
3.75 роль: Предопределенная совокупность правил, устанавливающих допусти­
мое взаимодействие между пользователем и ОО.
3.76 требование доверия к безопасности: Требование безопасности, которое
относится к условиям и процессам разработки и поставки ОО, а также к действиям,
требуемым от оценщиков в отношении свидетельств, полученных из этих условий и
процессов.
3.77 атрибут безопасности: Свойство субъектов, пользователей, объектов, ин­
формации, сеансов и/или ресурсов, которые используются при определении ФТБ, и
значения которых используются при осуществлении ФТБ.
Примечание - Пользователи могут включать сторонние ИТ-продукты.
3.78 функциональное требование безопасности: Требование безопасности,
которое способствует выполнению определения проблемы безопасности (ОПБ) ОО,
как определено в конкретном ЗБ или в ПЗ.
Примечание - Функциональное требование безопасности может рассматриваться напря­
мую, как в модели непосредственного обоснования, или косвенно, через цели безопасности для ОО, как
в общей модели.
3.79 цель безопасности: Изложенное намерение противостоять идентифициро­
ванным угрозам и/или удовлетворять установленной политике безопасности организа­
ции и/или предположениям.
3.80 определение проблемы безопасности: Формально определяет характер
и область безопасности, для которой предназначен ОО.
Примечания
11
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
1 Это заявление состоит из комбинации угроз, которым должен противодействовать ОО и его
среда, ПБОр (политики безопасности организации), обеспечиваемых ОО и его средой, и допущений, ко­
торые поддерживаются для среды функционирования ОО.
2
Элементы ПБОр включают угрозы и предположения.
3.81 требование безопасности: Требование, изложенное на стандартизирован­
ном языке 15408, которое является частью спецификации безопасности ОО, как опре­
делено в конкретном ЗБ или в ПЗ.
3.82 задание по безопасности: Зависящее от реализации изложение требова­
ний безопасности для ОО, основанное на определении проблемы безопасности.
3.83 выбор: Спецификация одного или нескольких элементов из списка в ком­
поненте.
3.84 основанное на выборе функциональное требование безопасности:
ФТБ в ПЗ, ПЗ-модуле или функциональном пакете, который способствует заявленному
аспекту определения проблемы безопасности ПЗ, ПЗ-модуля или функционального па­
кета, который должен быть включен в соответствующий ПЗ или ЗБ, если избранник
выбора указан в ПЗ/ПЗ-модуль/функциональный пакет указывает, что у него есть свя­
занное с ним основанное на выборе ФТБ.
3.85 одноуровневая оценка доверия: Оценивание ОО с применением одного
набора требований доверия.
3.86 строгое соответствие: Иерархические отношения между ПЗ и ПЗ/ЗБ, где
все требования в ПЗ также существуют в ПЗ/ЗБ.
Примечание - Это отношение можно перефразировать как «ЗБ содержит все утвержде­
ния, которые есть в ПЗ, но может содержать больше». Ожидается, что строгое соответствие будет ис­
пользоваться для строгих требований, которые должны выполняться единым образом.
3.87 под-ФБО: Объединенные функциональные возможности всего оборудова­
ния, программного обеспечения и микропрограмм ОО, который зависят от правильного
применения ФТБ, определенных в одном компоненте ПЗ-конфигурации.
Примечания
1 Этот набор ФТБ соответствует зависимостям, целям и элементам ОПБ в компоненте ПЗконфигурации.
2 Понятие под-ФБО применяется в связи со спецификацией и оцениванием ПЗ-конфигураций и
соответствующих ЗБ. Его можно использовать в подходе с одним уровнем доверия, но его следует ис­
пользовать в подходе с многоуровневым доверием: под-ФБО должны быть определены в конфигурации
ПЗ с многоуровневым доверием и в соответствующих ЗБ с многоуровневым доверием.
3 Каждая под-ФБО связана со своим собственным набором ТДБ в ПЗ-конфигурациях/ЗБ с много­
уровневым доверием. В остальной части стандарта набор ТДБ может быть пакетом доверий.
4
12
Под-ФБО имеет характеристики ОО.
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
3.88
субъект: Сущность в ОО, которая выполняет операции с объектами.
3.89 адаптация: Добавление одного или более функциональных требований к
функциональному пакету и/или добавление одного или более вариантов выбора в ФТБ
в функциональном пакете.
Примечания
1 Такая адаптация рассматривается только в контексте одного пакета и не рассматривается в
контексте других пакетов, ПЗ или ПЗ-модулей.
2
Выбранные параметры в ФТБ могут быть заменены дополнительными выборами.
3 Выборы могут быть добавлены только для пакетов, заявленных ПЗ или ПЗ-модулями. ЗБ не
может утверждать соответствие адаптированного имени пакета пакету.
3.90 объект оценки: Набор программного обеспечения, прошивки и/или аппа­
ратных средств, возможно, сопровождаемый руководством, который является предме­
том оценки.
3.91 источник угрозы: Сущность, обладающая потенциалом выполнения нега­
тивных действий по отношению к активам, защищенным ОО.
3.92 функциональные возможности безопасности ОО: Объединенные функ­
циональные возможности всех аппаратных средств, программного обеспечения и мик­
ропрограмм ОО, которые зависят от правильного применения ФТБ.
3.93
тип ОО: Набор характеристик, общих для определенной группы ОО.
Примечание - Тип ОО может быть более подробно определен в ПЗ.
3.94 трансляция: Излагает процесс описания требований безопасности на стан­
дартизированном языке.
Примечание - Использование термина «трансляция» в этом контексте не является бук­
вальным и не означает, что каждое ФТБ, выраженное на стандартизованном языке, также может быть
траслировано обратно в цели безопасности.
3.95 уязвимость: Слабое место ОО, которое может быть использовано для
нарушения ФТБ в среде функционирования.
4 Сокращения, обозначения
В настоящем стандарте применены термины, определения и сокращения, при­
веденные в ИСО/МЭК 15408-1, ИСО/МЭК 15408-3, ИСО/МЭК 18045, а также другие.
API
- прикладной программный интерфейс;
CD
- компакт-диск
DAC - дискреционное управление доступом
DPA - дифференциальный анализ мощности
13
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
DRBG - детерминированный генератор случайных битов
ЕА
- оценочная деятельность
EMS - электромагнитный спектр
GUI
- графический интерфейс пользователя
HSM - аппаратный модуль безопасности
HTTPS - безопасность протокола передачи гипертекста
IP
- протокол Интернета
IPsec - безопасность IP (протокол)
LDAP - протокол легкого доступа к каталогам
МАС - обязательный контроль доступа
MBps - мегабайтов в секунду
ОТР - одноразово программируемый
PCI
- подсоединение периферийного компонента
PKI
- инфраструктура открытых ключей
RAM - оперативная память
RBG - генератор случайных битов
RNG - генератор случайных чисел
RPC - удаленный вызов процедур
SPA - простой анализ мощности
SSH - протокол SSH
TCP
- протокол управления передачей
TLS
- безопасность уровня передачи
TSFI - интерфейс ФБО
USB - универсальная последовательная шина
VPN - виртуальная частная сеть
14
Гб
- гигабайт (Гб)
ГГц
- гигагерц (Гц)
ГПД
- глобальный пакет доверия
ДС
- доказуемое соответствие
ЗБ
- задание по безопасности
ИС
- интегральная схема
ИТ
- информационные технологии
Мб
- мегабайт (Мб)
МО
- метод оценивания
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
ОН
- отчет о наблюдении
ОО
- объект оценки
ОПБ - определение проблемы безопасности
ОС
- операционная система
ОУД - оценочный уровень доверия
ПБОр - политика безопасности организации
ПД
- пакет доверия
ПДЗБ - пакет доверия к заданию по безопасности
ПЗ
- профиль защиты
ПЗА - пакет доверия к профилю защиты
ПК
- персональный компьютер
ПФБ - политика функции безопасности
СПД - составной пакет доверия
СПДП - составной пакет доверия к продукту
СС
- строгое соответствие
ТДБ
- требование доверия к безопасности
ТОО - технический отчет об оценивании
ТС
- точное соответствие
УВВ
- управление вводом-выводом
УК
- управление конфигурацией
ФБО - функция возможности безопасности ОО
ФТБ - функциональное требование безопасности
5 Обзор
5.1 Общие положения
В данном разделе представлены основные концепции серии ИСО/МЭК 15408. Он
определяет концепцию объекта оценки (ОО), целевую аудиторию серии ИСО/МЭК
15408 и подход, используемый для представления материала в серии ИСО/МЭК 15408.
5.2 Описание серии ИСО/МЭК 15408
5.2.1 Общие положения
Серия ИСО/МЭК 15408 представлена как набор отдельных, но взаимосвязанных
частей, как указано ниже:
15
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
ИСО/МЭК 15408-1 «Введение и общая модель» - это введение в серию
ИСО/МЭК 15408. Эта часть определяет общие концепции и принципы оценки безопас­
ности ИТ и представляет общую модель оценки;
ИСО/МЭК 15408-2 «Функциональные компоненты безопасности» устанавли­
вает набор функциональных компонентов, которые служат стандартными шаблонами,
на которых основаны функциональные требования безопасности ОО. ИСО/МЭК 15408­
2 каталогизирует набор функциональных компонентов безопасности и систематизирует
их по семействам и классам;
ИСО/МЭК 15408-3 «Компоненты доверия безопасности» устанавливает набор
компонентов доверия, которые служат в качестве стандартных шаблонов, на которых
основаны требования доверия к ОО. ИСО/МЭК 15408-3 каталогизирует набор компо­
нентов обеспечения безопасности и систематизирует их по семействам и классам;
ИСО/МЭК 15408-4 «Структура спецификации методов и действий оценки»
представляет стандартизированную структуру спецификации методов и оценочных
действий, которые могут быть включены в ПЗ, ЗБ и любые документы, поддерживаю­
щие их, для использования оценщиками в поддержке оценок с использованием моде­
ли, описанной в других частях ИСО/МЭК 15408. ИСО/МЭК 18045 является базовым для
ИСО/МЭК 15408-4;
ИСО/МЭК 15408-5 «Предопределенные пакеты требований безопасности»
представляет пакеты доверия безопасности и функциональных требований безопасно­
сти, которые были определены как целесообразные для поддержки общего использо­
вания заинтересованными сторонами. Примеры представленных пакетов включают
оценочные уровни доверия (СУД) и составные пакеты доверия (СПД).
При применении серии ИСО/МЭК 15408 необходимо предоставить обоснование,
если рекомендуемый вариант не был выбран.
В поддержку серии ИСО/МЭК 15408 были опубликованы другие документы. Спи­
сок подтверждающих документов представлен в библиографии.
Примечание - ИСО/МЭК 18045 предоставляет базовую методологию оценки безопасно­
сти ИТ, выполняемой в соответствии с серией ИСО/МЭК 15408.
5.2.2 Аудитория
Существует пять основных групп, которые в целом заинтересованы в оценива­
нии свойств безопасности ОО: потребители (заказчики), разработчики, технические ра­
бочие группы, оценщики и другие. Информация, представленная в серии ИСО/МЭК
15408, была структурирована для осуществления потребностей всех этих групп, кото16
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
рые считаются основными пользователями серии ИСО/МЭК 15408. Группы воспользо­
ваться критериями, изложенными в пунктах с 5.2.2 по 5.2.6.
5.2.2.1 Потребители (заказчики)
Серия ИСО/МЭК 15408 разработана с целью удовлетворения оцениванием по­
требностей заказчиков, поскольку это основная цель и обоснование процесса оценива­
ния.
Заказчики могут использовать результаты оценок, чтобы решить, удовлетворяет
ли ОО их потребностям в безопасности. Эти потребности в безопасности обычно вы­
являются как в результате анализа рисков, так и в результате определения политики.
Заказчики также могут использовать результаты оценки для определения, отвечает ли
ОО их потребностям в безопасности.
Серия ИСО/МЭК 15408 предоставляет заказчикам, особенно представителям
групп потребителей и заинтересованных сообществ, независимую от реализации
структуру, называемую ПЗ, в которой они могут однозначно выразить свои требования
к безопасности.
5.2.2.2 Разработчики
Серия ИСО/МЭК 15408 предназначена для оказания поддержки разработчиков
продуктов ИТ в подготовке и помощи в оценке их ОО, а также в определении требова­
ний безопасности, которым должны удовлетворять эти ОО. Эти требования содержат­
ся в зависящей от реализации конфигурации, называемой заданием по безопасности
(ЗБ). Это ЗБ может соответствовать одному или нескольким ПЗ для демонстрации, что
ОО удовлетворяет требованиям безопасности потребителей, изложенным в этих ПЗ.
Затем серию ИСО/МЭК 15408 можно использовать для определения ответствен­
ности и действий по предоставлению доказательств, необходимых для способствова­
ния оцениванию соответствия ОО этим требованиям. Она также определяет содержа­
ние и представление этих доказательств.
5.2.2.3 Технические рабочие группы
Серия ИСО/МЭК 15408 предназначена для поддержки технических рабочих
групп при подготовке и разработке ПЗ, ПЗ-модулей, ПЗ-конфигураций, пакетов и вспо­
могательных документов или руководств. Технические рабочие группы могут состоять
из заинтересованных сторон, включая потребителей (заказчиков), разработчиков,
оценщиков и ученых.
5.2.2.4 Оценщики
17
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Серия ИСО/МЭК 15408 содержит критерии, которые должны использоваться
оценщиками при формировании заключений о соответствии ОО, ЗБ, ПЗ и ПЗконфигураций их требованиям безопасности. Серия ИСО/МЭК 15408 содержит описа­
ние общей совокупности действий, которые должен выполнить оценщик.
Примечание - Серия ИСО/МЭК 15408 не уточняет процедуры, которым необходимо сле­
довать при выполнении этих действий. Более подробную информацию об этих процедурах можно найти
в разделе 13.
5.2.2.5 Иные
Хотя серия ИСО/МЭК 15408 ориентирована на спецификацию и оценку свойств
безопасности ИТ для ОО, она также может быть полезна в качестве справочного мате­
риала для всех сторон, заинтересованных в безопасности ИТ или несущих ответствен­
ность за нее. Некоторыми из дополнительных заинтересованных групп, которым может
быть полезна информация, содержащаяся в серии стандартов ИСО/МЭК 15408, явля­
ются:
а) обслуживающий персонал системы и сотрудники обеспечения безопасности
системы, ответственные за определение и соблюдение политик и требований безопас­
ности ИТ организации;
Ь) аудиторы, как внутренние, так и внешние, ответственные за оценку адекватно­
сти безопасности ИТ-решения (которое может состоять из ОО или содержать его);
с) архитекторы и проектировщики системы безопасности, ответственные за спе­
цификацию свойств безопасности продуктов ИТ;
d) уполномоченные организации, ответственные за принятие решения по ис­
пользованию ИТ в определенной среде;
е)
инициаторы оценки, ответственные за запрос и поддержку оценивания;
f) органы оценки, ответственные за управление программами оценки безопасно­
сти ИТ и надзор за ними;
д) ученые, которые проводят исследования по теме ИТ-безопасности.
В таблице 1 представлено для каждой группы аудитории, какие части ИСО/МЭК
15408 представляют для нее интерес.
Таблица 1 - Дорожная карта к «Критериям оценки ИТ-безопасности»
Потребители
(заказчики)
Часть 1
18
Следует исполь­
зовать для спра­
вочной информа­
ции, справочных
Разработчики
Следует исполь­
зовать для спра­
вочной информа­
ции, справочных
Технические
рабочие груп­
пы
Следует исполь­
зовать для спра­
вочной информа­
ции, справочных
Оценщики
Другие
Следует исполь­
зовать для спра­
вочной информа­
ции, справочных
Можно использо­
вать для спра­
вочной информа­
ции, справочных
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
целей и для ру­
ководства
по
структуре
ПЗБ,
ПЗ-модулей, ПЗ конфигураций, ЗБ
и их комбинации.
Необходимо ис­
пользовать
для
разработки спе­
цификаций без­
опасности
и
определений
проблем
без­
опасности
для
ОО.
Часть 2 Должна исполь­
зоваться в каче­
стве руководства
и
справочника
при формулиро­
вании
функцио­
нальных требо­
ваний безопасно­
сти для среды
рисков.
Часть 3 Должна исполь­
зоваться
каче­
стве руководства
и
справочника
при определении
доверия к без­
опасности, необ­
ходимого
для
среды рисков.
Часть 4 Следует исполь­
зовать как спра­
вочную
инфор­
мацию в структу­
ре методов оце­
нивания
и/или
оценочных дей­
ствиях.
целей и для ру­
ководства
по
структуре
ПЗБ,
ПЗ-модулей, ПЗ конфигураций, ЗБ
и их комбинации.
Должна исполь­
зоваться для
разработки спе­
цификаций без­
опасности для
ОО.
целей и для ру­
ководства
по
структуре
ПЗБ,
ПЗ-модулей, ПЗ конфигураций, ЗБ
и их комбинации.
Должна исполь­
зоваться для
разработки спе­
цификаций без­
опасности паке­
тов, ПЗ, ПЗ- мо­
дулей и ПЗ- кон­
фигураций.
целей и для ру­
ководства
по
структуре ПЗ, ПЗмодулей, ПЗ конфигураций, ЗБ
и их комбинации
Должна исполь­
зоваться при
оценивании ПЗ,
ПЗ- конфигура­
ций и ЗБ.
целей и для ру­
ководства
по
структуре
ПЗБ,
ПЗ-модулей, ПЗ конфигураций, ЗБ
и их комбинации
Должна исполь­
зоваться в каче­
стве справочника
при интерпрета­
ции
изложения
функциональных
компонентов
в
пакетах, ПЗ и ПЗмодулях.
Должна исполь­
зоваться при раз­
работке ЗБ.
Можно использо­
вать при форму­
лировании функ­
циональных воз­
можностей
ИТпродуктов.
Должна исполь­
зоваться при ин­
терпретации из­
ложений компо­
нентов доверия к
безопасности
в
пакетах, ПЗ, ПЗмодулях и ПЗконфигурациях.
Должна исполь­
зоваться при раз­
работке ЗБ.
Можно использо­
вать при форму­
лировании
или
улучшении про­
цессов разработ­
ки.
Следует исполь­
зовать как спра­
вочную
инфор­
мацию и руковод­
ство в структуре
методов
оцени­
вания и/или оце­
ночных действи­
ях.
Должна исполь­
зоваться
при
формулировании
функциональных
компонентов без­
опасности в паке­
тах, ПЗ и ПЗ- мо­
дулях.
Должна исполь­
зоваться
при
оценивании
функциональных
компонентов без­
опасности в паке­
тах, ПЗ и ПЗ- мо­
дулях или функ­
циональных тре­
бований безопас­
ности в ЗБ.
Можно использо­
вать для ссылки
при
анализе
функциональных
компонентов без­
опасности в паке­
тах, ПЗ и ПЗ- мо­
дулях или функ­
циональных тре­
бований безопас­
ности в ЗБ.
Может использо­
ваться для ссыл­
ки при формули­
ровании изложе­
ния компонентов
доверия к без­
опасности в паке­
тах, ПЗ, ПЗ- мо­
дулях и ПЗ- кон­
фигурациях.
Может использо­
ваться для ссыл­
ки при оценива­
нии
функцио­
нальных компо­
нентов безопас­
ности в пакетах,
ПЗ, ПЗ- модулях
и ПЗ- конфигура­
циях или требо­
ваниях доверия к
безопасности
в
ЗБ.
Может использо­
ваться для ссыл­
ки при анализе
функциональных
компонентов без­
опасности в паке­
тах, ПЗ и ПЗ- мо­
дулях и ПЗ- кон­
фигурациях или
требованиях до­
верия к безопас­
ности в ЗБ.
Следует исполь­
зовать как спра­
вочную
инфор­
мацию и руковод­
ство в структуре
методов оцени­
вания и/или оце­
ночных действи­
ях.
Следует исполь­
зовать как спра­
вочную
инфор­
мацию и руковод­
ство в структуре
методов оцени­
вания и/или оце­
ночных действи­
ях.
Может использо­
ваться как спра­
вочная информа­
ция и руковод­
ство в структуре
методов
оцени­
вания и/или оце­
ночных действи­
ях.
19
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Часть 5 Следует исполь­
зовать как спра­
вочную
инфор­
мацию при опре­
делении
содер­
жания
любых
предопределен­
ных пакетов тре­
бований безопас­
ности
Должна исполь­
зоваться при раз­
работке
ЗБ,
утверждающих о
соответствии
предопределен­
ным пакетам тре­
бований безопас­
ности
Должна исполь­
зоваться
как
справочная
ин­
формация
при
подготовке
ОО
для оценивания
предопределен­
ным пакетам тре­
бований безопас­
ности
Должна исполь­
зоваться при раз­
работке, ПЗ, ПЗмодулей и ПЗконфигураций,
утверждающих о
соответствии
предопределен­
ным пакетам тре­
бований безопас­
ности
соответ­
ствии
Следует исполь­
зовать при фор­
мулировании кон­
кретных методов
оценивания и/или
оценочных дей­
ствий.
Должна исполь­
зоваться
как
справочная
ин­
формация
при
оценивании ПЗ,
ПЗ- модулей и
ПЗконфигура­
ций
или
ЗБ,
утверждающих о
соответствии
предопределен­
ным пакетам тре­
бований безопас­
ности
соответ­
ствии .
Может использо­
ваться как спра­
вочная информа­
ция при опреде­
лении содержа­
ния любых пред­
определенных
пакетов требова­
ний
безопасно­
сти.
5.2 Объект оценки (ОО)
5.3.1 Общие положения
Серия ИСО/МЭК 15408 является гибкой в отношении того, что нужно оценивать,
и поэтому не привязана к границам ИТ-продуктов, как это обычно понимается. Поэтому
в контексте оценивания в серии ИСО/МЭК 15408 используется термин “ОО” (объект
оценки).
Хотя бывают случаи, когда ОО представлен полным ИТ-продуктом, это не всегда
так. ОО может быть ИТ-продуктом, частью ИТ-продукта, набором ИТ-продуктов, уни­
кальной технологией, которую никогда нельзя превратить в продукт, или их комбина­
цией.
Что касается серии ИСО/МЭК 15408, точное соотношение между ОО и любыми
ИТ-продуктами значимо только в одном аспекте: оценивание ОО, содержащего только
часть ИТ-продукта, не должна быть неправильно понята как оценка всего ИТ-продукта.
Например, ОО включают устройства, характеризующиеся небольшим количе­
ством интерфейсов, уменьшенной поверхностью атаки и хорошо известной цепочкой
поставок:
- сетевое устройство;
- приложение программного обеспечения;
- операционная система;
20
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
- система виртуализации;
- интегральная схема;
- сопроцессор интегральной схемы;
- приложение для мобильного устройства;
- сервер базы данных, исключающее удаленное клиентское программное обес­
печение, обычно связанное с этим приложением базы данных.
ОО также могут быть более сложными, характеризующимися большим интер­
фейсом/ большими интерфейсами и/или количеством компонентов, множеством этапов
производства/интеграции, и продуктами, обновляемыми на месте, такими как:
- локальная сеть, включающая все терминалы, серверы, сетевое оборудование и
программное обеспечение;
- мобильное устройство;
- шлюзы и хабы;
- прикладное программное обеспечение;
- многофункциональное устройство, например, многофункциональный принтер;
- аппаратный модуль безопасности.
5.3.2 Границы ОО
Концепция границы ОО является фундаментальной для спецификации ЗБ.
ОО может быть законченным продуктом ИТ (или продуктами), частью продукта
ИТ или состоять из различных компонентов. В ЗБ должна быть четко изложена физи­
ческая и логическая область применения ОО при его доставке заказчику.
Любые части продукта ИТ, которые не входят в границы ОО, не оцениваются и
называются частями продукта ИТ, не относящимися к ОО.
5.3.3 Различные представления ОО
В серии ИСО/МЭК 15408 ОО может встречаться в нескольких представлениях,
связанных с критериями доверия:
Примечание - Эти критерии доверия включают тестирование (АТЕ) и анализ уязвимостей
(AVA), для которых требуются образцы ОО, некоторый проект (ADV_IMP), который требует представле­
ния реализации, например, исходный код, и жизненный цикл (ALC), для которого требуется список кон­
фигурации ОО.
Пример представления ОО для ОО программного обеспечения:
- список файлов в системе управления конфигурацией;
- единственная мастер-копия, которая только что была скомпилирована;
- исходный код конкретной версии дистрибутива с открытым исходным кодом;
21
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
- коробка с физическими носителями и инструкцией, готовая к отправке заказчи­
ку;
- бинарный файл, доступный для безопасной загрузки;
- установленная и рабочая версия представления ОО аппаратного обеспечения:
- макет интегральной схемы;
- карты памяти;
- подложки;
- модули.
Все они считаются ОО, и везде, где термин «ОО» используется в серии
ИСО/МЭК 15408, контекст определяет представление.
5.3.4 Различные конфигурации ОО
Как правило, ИТ-продукты можно конфигурировать разными способами с вклю­
чением или блокированием различных опций. Во время оценки, выполняемой в соот­
ветствии с серией ИСО/МЭК 15408, будет определено, соответствует ли ОО опреде­
ленным требованиям. Часто часть с руководством ограничивает возможные конфигу­
рации ОО. То есть руководство для ОО может отличаться от общего руководства по
продукту ИТ.
ИТ-продукт операционной системы: этот продукт можно настроить разными спо­
собами, включая типы пользователей, количество пользователей, типы разрешен-
ных/запрещенных внешних подключений, задействованные/блокированные параметры
и т.д.
В целом, если ИТ-продукт содержит ОО или является им, конфигурация продук­
та должна контролироваться гораздо более жестко, поскольку некоторые параметры
конфигурации могут привести к появлению ОО, не отвечающего требованиям.
По этой причине существует ожидаемое различие между документацией для
общего ИТ-продукта, которая может допускать множество конфигураций; и документа­
цию с руководством для ОО, которая может допускать только одну конфигурацию или
набор конфигураций, которые не отличаются в отношении безопасности.
Примечание - Если документация с руководством для ОО допускает более одной конфи­
гурации, эти конфигурации в совокупности называются «ОО», и каждая конфигурация должна соответ­
ствовать требованиям, предъявляемым к ОО.
5.3.5 Среда функционирования ОО
Все, что находится за пределами ОО, относится к среде функционирования ОО.
В случае, когда ОО является частью продукта ИТ, продукт ИТ может иметь части, не
22
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
относящиеся к ОО. Такие части, не относящиеся к ОО, также являются частью среды
функционирования ОО.
ЗБ должно содержать описание допущений и определять цели безопасности для
среды функционирования, которые вместе с функциональными возможностями без­
опасности, предоставляемыми самим ОО, необходимы для смягчения угроз и обеспе­
чения соблюдения политик безопасности организации.
Задание по безопасности для среды функционирования могут поддерживать
функциональные возможности обеспечения безопасности ОО.
ЗБ должно сформулировать четкие требования к среде функционирования ОО,
чтобы предоставить пользователю информацию, достаточную для использования оце­
ненного ОО.
5.4 Представление материала в настоящем стандарте
Общая модель представлена в разделе 6, в котором объясняются концепции,
относящиеся к оценке функциональных возможностей обеспечения безопасности ИТ-
продуктов, определению проблемы безопасности и спецификации требований без­
опасности, связанных с решением проблемы безопасности. Введены концепции, отно­
сящиеся к спецификации требований безопасности, пакетов, ПЗ, ПЗ-модулей и ПЗ-
конфигураций, которые связаны с потребностями заказчиков с аналогичными пробле­
мами безопасности.
Объяснение средств определения требований безопасности и завершения ком­
понентов безопасности, предусмотренные в ИСО/МЭК 15408-2 и ИСО/МЭК 15408-3,
дано в разделах 7 и 8.
Объяснение требований и рекомендаций для основных конфигураций пакетов,
ПЗ-модулей, ПЗ-конфигураций и ЗБ содержится в разделах 9, 10, 11 и п. 11.3.3.
Требования и рекомендации по оценке и результатам оценки для ОО, ЗБ, ПЗ и
ПЗ-конфигураций содержатся в разделе 13.
Наконец, тема формирования доверия содержатся в разделе 14.
6 Общая модель
6.1 Справочная информация
В этом подразделе представлены общие концепции, используемые повсеместно
в серии стандартов ИСО/МЭК 15408, включая контекст, в котором эти концепции долж­
ны использоваться, и подход к их применению. ИСО/МЭК 15408-2, ИСО/МЭК 15408-3,
23
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
ИСО/МЭК 15408-4 и ИСО/МЭК 15408-5 расширяют область применения этих концепций
и предполагают использование описанного здесь подхода. Кроме того, для пользова­
телей серии ИСО/МЭК 15408, которые намереваются выполнять оценочные действия,
применим ИСО/МЭК 18045.
В серии стандартов ИСО/МЭК 15408 безопасность обсуждается с использовани­
ем определенного набора концепций безопасности и терминологии. Предпосылкой для
эффективного использования серии ИСО/МЭК 15408 является знание этих концепций
и терминологии. Однако сами по себе концепции не предназначены для ограничения
класса проблем ИТ-безопасности, к которым применима серия ИСО/МЭК 15408. В раз­
деле 6 предполагается, что читатель обладает знаниями в области ИТ-безопасности, и
он не предназначен для использования в качестве учебного пособия в этой области.
6.2 Активы и меры безопасности
Безопасность связана с защитой активов в среде функционирования.
Примером актива является содержимое файла или сервера.
Примеры среды функционирования в контексте такого актива:
- центр обработки данных, в котором установлен сервер;
- компьютерная сеть, подключенная к Интернету, которая соединяет сервер со
всем миром;
- ЛВС, которая соединяет сервер с другими серверами и / или рабочими станци­
ями;
- повседневная среда пользователя, использующего информацию с сервера или
конкретного файла;
- общая офисная среда, которая обеспечивает средства связи с сервером и/или
конкретным файлом.
Многие активы представлены в виде информации, которая хранится, обрабаты­
вается и передается продуктами ИТ таким образом, чтобы удовлетворить требования
владельцев этой информации. Владельцы информации вправе требовать, чтобы До­
ступность, распространение и модификация любой такой информации строго контро­
лировались и активы были защищены от угроз средствами безопасности. Рисунок 1
иллюстрирует высокоуровневые понятия безопасности и их взаимосвязь.
Примечание - ИСО/МЭК 27001 представляет требования к созданию, внедрению, под­
держке и постоянному улучшению системы менеджмента информационной безопасности, включая спе­
цификацию средств безопасности.
24
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Оценивают
Владельцы
Хотят минимизировать
Предпринимают
Контрмеры
Чтобы понизить
Источника угроз
(нарушители)
Риск
Которые
повышают
Порождают
Для
Активы
Угрозы
Для
Хотят злоупотребить и/или могут нанести ущерб
Рисунок 1 - Концепции безопасности и их взаимосвязь
Защита представляющих интерес активов является обязанностью владельцев,
которые определяют ценность этих активов. Фактические или предполагаемые источ­
ники угрозы также могут оценивать активы и стремиться злоупотреблять активами спо­
собом, противоречащим интересам их владельца.
Примерами источников угроз являются хакеры, нарушители, пользователи, не
являющиеся нарушителями, которые иногда допускают ошибки, компьютерные про­
цессы и аварии.
Владельцы активов будут воспринимать такие угрозы как потенциальную воз­
можность нанесения такого ущерба активам, при котором ценность активов для вла­
дельцев уменьшилась бы. Специфичный для безопасности ущерб обычно состоит в
следующем (но не ограничивается этим): потеря конфиденциальности активов, потеря
целостности активов или потеря Доступности активов.
Таким образом, эти угрозы создают риски для активов, зависящие от вероятно­
сти реализации угрозы и ущерба активам при реализации рассматриваемой угрозы.
Для того чтобы уменьшить риски для активов, реализуются средства безопасности.
Эти средства безопасности могут включать ИТ- средства безопасности контрмеры (та-
25
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
кие как межсетевые экраны и смарт-карты) и несвязанные с ИТ средства безопасности
(такие как охрана и процедуры). Более широкое рассмотрение средств безопасности
(мер безопасности), а также способов их реализации и управления ими представлено в
ИСО/МЭК 27001 и ИСО/МЭК 27002.
Поскольку за активы могут нести (несут) ответственность их владельцы, то им
следует иметь возможность отстаивать принятое решение о приемлемости риска для
активов, создаваемого угрозами.
При отстаивании этого решения должна иметься возможность продемонстриро ­
вать два важных момента, что:
- средства безопасности являются достаточными, если они выполняют то, что
для них заявлено, и угрозам, направленным на активы, обеспечивается противостоя­
ние;
- средства безопасности являются корректными, если они выполняют то, что для
них заявлено;
Многие владельцы активов не имеют знаний, опыта или ресурсов, необходимых
для вынесения заключения о достаточности и корректности средств безопасности, и
при этом они не всегда могут захотеть полагаться исключительно на утверждения раз­
работчиков этих контрмер. Вследствие этого данные потребители могут захотеть по­
высить свою уверенность в достаточности и корректности некоторых или всех средств
безопасности путем заказа оценки этих контрмер.
Рисунок 2 иллюстрирует концепции оценивания, изложенные в данном разделе,
и их взаимосвязь.
26
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Оценка
Обеспечивает
Владельцы
Требуют
Уверенность
Что
Являются
Контрмеры
Достаточные
И, таким
образом,
минимизируют
Являются
Корректные
Риск
И, таким
— образом, —
минимизируют
Для
Активы
Рисунок 2 - Концепции оценивания и их взаимосвязь
При оценивании достаточности средств безопасности контрмер анализируется
через конфигурацию, называемую заданием по безопасности ЗБ).
6.3 Ключевые конфигурации парадигмы серии ИСО/МЭК 15408
6.3.1 Общие положения
В серии ИСО/МЭК 15408 определена гибкая структура оценивания продуктов ИТ.
Чтобы группы потребителей и технические сообщества могли выражать свои по­
требности в безопасности и облегчить создание соответствующих документов, в кото­
рых выражены эти потребности, в парадигме предусмотрены пять конфигураций: па­
кет, ПЗ, ПЗ-модуль, ПЗ-конфигурация и ЗБ.
Поскольку оценка может потребоваться для удовлетворения различных потреб­
ностей потребителей (заказчиков) в доверии, стандарт предоставляет различные ин­
струменты, включая хорошо сформированные компоненты доверия к безопасности
(ИСО/МЭК 15408-3), а также механизм определения расширенных компонентов дове­
рия (ИСО/МЭК 15408-1).
27
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Пользователи данного стандарта также могут выбирать из предопределенных
пакетов, включая пакеты для оценочных уровней доверия (на основе ИСО/МЭК 15408­
5), или из структуры определения методов и действий оценки (ИСО/МЭК 15408-4), а
также соответствующей методологии оценки (на основе ИСО/МЭК 18045).
6.3.2 Типы соответствия
Для удовлетворения потребностей потребителей (заказчиков) были определены
три различных типа соответствия ПЗ и ПЗ-конфигурациям Это точное, строгое и дока­
зуемое соответствие. Они подробно изложены в Приложении Е.
Тип соответствия должен указываться в ПЗ, ПЗ-модулях и ПЗ-конфигурациях.
Соответствие ПЗ и ПЗ-конфигурациям по их типам соответствия заявляется в
ЗБ. ПЗ могут также заявлять о соответствии другим ПЗ в соответствии с их типом соот­
ветствия.
Типы соответствия, заявления о соответствии и взаимосвязь типов соответствия
ПЗ, ПЗ-модулей и ПЗ-конфигураций изложены в Приложении Е, которое должно ис­
пользоваться вместе с разделами стандарта.
6.3.3 Сообщение требований безопасности
6.3.3.1 Пакеты
Пакеты описывают набор связанных требований безопасности, которые часто
используются вместе. Пакеты часто предназначаются для повторного использования,
обеспечивая некоторую сопоставимость между теми ПЗ, ПЗ-модулями и ЗБ, которые
их используют.
Функциональные пакеты безопасности могут использоваться для определения
протоколов безопасности или других функциональных концепций безопасности.
Пакеты доверия к безопасности могут использоваться для определения условий
и процессов, таких как спецификация, проектирование, разработка, тестирование и по­
ставка, в соответствии с которыми разрабатывается и конфигурируется ОО.
Основные требования к пакетам можно найти в разделе 9, а в Приложении А
представлена Дополнительная информация и требования к пакетам, которая должна
использоваться вместе с разделами стандарта.
В ИСО/МЭК 15408-3 предоставлены критерии оценки и особые требования для
оцениваемых модулей ЗБ, ПЗ и ПЗ-модулей, которые могут использовать пакеты, а
ИСО/МЭК 15408-5 представляет некоторые предопределенные пакеты доверия, кото­
рые могут использоваться в ПЗ, ПЗ- модулях, ПЗ-конфигурациях, а также разработчи­
ками ЗБ.
28
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
6.3.3.2 Профили защиты (ПЗ)
ПЗ описывают тип ОО, а также требования доверия к безопасности (ТДБ) и
функциональные требования безопасности (ФТБ), которые, как ожидается, будут
предоставлены для этого типа ОО.
ПЗ на основе других ПЗ могут использоваться для дальнейшего уточнения типа
ОО. ПЗ могут принимать как стандартный подход, так и подход прямого обоснования.
Основные требования к ПЗ можно найти в разделе 10, а дополнительную ин­
формацию в Приложении В, которая должна использоваться вместе с разделами этого
стандарта.
Критерии оценки ПЗ представлены в ИСО/МЭК 15408-3.
6.3.3.3 ПЗ-модули и ПЗ-конфигурации
ПЗ- конфигурации построены на концепциях ПЗ и ПЗ-модуля.
ПЗ-модуль может использоваться для уточнения общего типа ОО базового ПЗ
или для добавления требований безопасности для конкретных технологий, которые мо­
гут быть необязательно связаны с типом ОО, определенным в базовых ПЗ. ПЗ-модули
также могут быть основаны на других ПЗ-модулях. Кроме того, ПЗ-конфигурации со­
стоят из типа ОО и набора требований, определенных в нескольких ПЗ и, возможно,
ПЗ-модулях (это компоненты ПЗ-конфигурации).
Эта концепция более подробно описана в разделе 11 и Приложении С.
ПЗ-модуль описывает, например, функциональные требования безопасности
для технологии Bluetooth. Другой ПЗ-модуль описывает функциональные требования
безопасности
для
клиентов
беспроводной
локальной
сети.
Используя
ПЗ-
конфигурацию, требования к функциям безопасности для каждой из этих технологий
могут быть объединены с ПЗ, описывающими тип ОО, например, ПЗ операционной си­
стемы или ПЗ мобильного устройства. В этом контексте ПЗ, описывающий тип ОО,
называется базовым ПЗ. ПЗ-конфигурация описывает, какие ПЗ и ПЗ-модули объеди­
нены для представления спецификации, включающей все требования, приведенные в
соответствующих ПЗ и ПЗ-модулях.
В этом примере можно указать шесть ПЗ-конфигураций:
а) операционная система с Bluetooth
b) операционная система с беспроводным клиентом,
с) операционная система с Bluetooth и беспроводным клиентом,
d) мобильное устройство с Bluetooth,
е) мобильное устройство с беспроводным клиентом,
29
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
f) мобильное устройство с Bluetooth и беспроводным клиентом.
6.3.3.4 Задания по безопасности
6.3.3.4.1 Общие положения
В С.3.3.4 представлен упрощенный вид конфигурации ЗБ. Более подробное и
полное описание концепции ЗБ и требований к содержанию можно найти в 11.3.3 и
Приложении D, которые должны использоваться вместе с разделами стандарта.
ИСО/МЭК 15408-3 содержит критерии оценки и особые требования к ЗБ, прохо­
дящим оценивание.
6.3.3.4.2 Назначение ЗБ
ЗБ является основным документом, который начинается с определения пробле­
мы безопасности (ОПБ) для ОО. Оно включает в себя спецификацию активов, которые
подлежат защите, и угроз этим активам. Затем в ЗБ рассматриваются любые соответ­
ствующие допущения и описываются средства безопасности, которые должны быть в
наличии, чтобы продемонстрировать, что этим угрозам оказывается противодействие.
Если средства безопасности выполняют то, что, как о них заявлено, они должны вы­
полнять, угрозам оказывается противодействие.
Двумя группами средств безопасности являются:
а) цели безопасности ОО: они описывают средства безопасности, корректность
которых будет определяться при оценке;
Ь) цели безопасности для среды функционирования: они описывают меры без­
опасности, корректность которых не будет определяться при оценке.
Причинами этого разделения являются:
- серия ИСО/МЭК 15408 подходит для оценки корректности сред разработки и
производства ИТ и их продукции и управления жизненным циклом продукта. В соответ­
ствии с этим стандартом средства безопасности, необходимые для среды функциони­
рования, выходят за рамки оценки.
- оценка правильности мер безопасности требует времени и денег, что, возмож­
но, делает невозможным оценку правильности всех мер безопасности;
- оценка корректности средств безопасности требует времени и денег, что, воз­
можно, делает невозможным оценку правильности всех средств безопасности;
- корректность некоторых средств безопасности уже могла быть оценена при
другой оценке. Поэтому повторная оценка этой корректности нерентабельна.
ЗБ дополнительно детализирует цели безопасности для ОО посредством опре­
деления функциональных требований безопасности (ФТБ). Эти ФТБ должны быть
30
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
сформулированы на стандартном языке, описанном в ИСО/МЭК 15408-2, для обеспе­
чения точности и облегчения сопоставимости.
Таким образом, ЗБ демонстрирует, что:
-
ФТБ соответствуют целям безопасности ОО;
- цели безопасности ОО и цели безопасности для среды функционирования от­
носятся к ОПБ и, в частности, противодействуют угрозам;
- и, следовательно, ФТБ и цели безопасности для среды функционирования от­
носятся к ОПБ и, в частности, противодействуют угрозам;
Из этого следует, что корректный ОО, то есть ОО, который соответствует ФТБ, в
сочетании с корректной средой функционирования, которая отвечает целям безопас­
ности для среды функционирования, будет противостоять угрозам. В п. 6.3.3.4.3 и
6.3.3.4.4 корректность ОО и корректность среды функционирования обсуждаются от­
дельно.
В некоторых случаях уместно определение цели безопасности, в которой не ука­
заны цели безопасности ОО и которые напрямую сопоставляют ФТБ с определением
проблемы безопасности (ОПБ). Это «прямое обоснование» ЗБ, которое подробно объ­
ясняется в п. 11.3.3 и Приложении D.
ЗБ может быть определено как отдельный документ для конкретного ОО или
может соответствовать существующей ПЗ-конфигурации или одному или нескольким
уже существующим ПЗ. Эти документы позволяют делать общие определения типа
ОО, обеспечивая сопоставимость результатов оценки между ОО, а также повышение
эффективности.
Пакеты, ПЗ, ПЗ-модули и ПЗ-конфигурации, которые могут способствовать спе­
цификации ЗБ, представлены в п. 6.3.3.1,6.3.3.2 и 6.3.3.3.
6.3.3.4.3 Корректность ОО
ОО может быть неправильно спроектирован и реализован и, следовательно, со­
держать ошибки, которые приводят к появлению уязвимостей. Используя эти уязвимо­
сти, нарушители могут нанести ущерб активам и/или злоупотребить ими.
Эти уязвимости могут быть вызваны ошибками проектирования, случайными
ошибками, допущенными во время разработки, преднамеренным добавлением вредо­
носного кода, плохим управлением конфигурацией и т.д.
Для определения корректности ОО, могут быть выполнены различные действия,
такие как:
- тестирование ОО;
31
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
- изучение различных проектных представлений ОО;
- исследование физической безопасности для среды разработки ОО.
Для определения корректности ЗБ предоставляет структурированное описание
этих действий в форме требований обеспечения безопасности (ТДБ). Эти ТДБ должны
быть сформулированы на стандартном языке, описанном в ИСО/МЭК 15408-3, для
обеспечения точности и облегчения сопоставимости.
Если ТДБ выполняются, существует уверенность в правильности ОО, и поэтому
вероятность того, что ОО будет содержать уязвимости, которые могут быть использо­
ваны нарушителями, меньше. Степень доверия к корректности ОО определяется са­
мими ТДБ.
6.3.3.4.4 Корректность среды функционирования
Среда функционирования также может быть неправильно спроектирована и реа­
лизована и может, таким образом, содержать ошибки, которые ведут к уязвимостям.
Посредством использования этих уязвимостей, нарушители могут причинить ущерб ак­
тивам и/или злоупотребить ими.
Однако в ИСО/МЭК 15408 доверие не приобретается при рассмотрении коррект­
ности среды функционирования. Или, другими словами, среда функционирования не
оценивается.
Что касается оценки, предполагается, что рабочая среда является корректным
воплощением целей безопасности для среды функционирования.
Это не мешает потребителю ОО использовать другие методы определения кор­
ректности конкретной среды функционирования.
Если для ОО типа "ОС" установлены цели безопасности для среды функциони­
рования: "Среда функционирования должна обеспечивать, что сущности из недове­
ренной сети могут осуществлять доступ к ОО только по протоколу FTP", то потреби­
тель мог бы выбрать оцененный межсетевой экран и конфигурировать его так, чтобы к
ОО был разрешен доступ только по протоколу FTP.
Если для ОО установлены цели безопасности для среды функционирования:
"Среда функционирования должна обеспечивать, что никто из всего административно­
го персонала не будет вести себя злонамеренно", то потребитель мог бы адаптировать
свои контракты с административным персоналом для включения штрафных санкций за
злонамеренное поведение, но это решение не является частью оценки в соответствии
с ИСО/МЭК 15408.
Примером недоверенной сети является интернет.
32
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
6.3.4 Удовлетворение потребностей потребителей (заказчиков)
6.3.4.1 Общие положения
Потребители (заказчики) могут иметь разные способы получения доверия к тому,
что продукты, которые они используют, связаны с ОПБ. Эти способы представлены в
п. 6.3.4.2 и 6.3.4.3. Более того, ИСО/МЭК 15408-4 предоставляет методы для опреде­
ления конкретных действий по оценке требований доверия.
6.3.4.2 Одноуровневая оценка доверия
Одноуровневая оценка доверия - это тип оценки, который был детально опреде­
лен в предыдущих редакциях настоящего стандарта. При одноуровневой оценке дове­
рия ко всему ОО применяется единый набор требований доверия.
Парадигма одноуровневой оценки доверия:
- требует, чтобы весь ОО подчинялся одним и тем же требованиям доверия к
безопасности;
- используется, когда единый набор требований доверия к безопасности соизме­
рим с потребностями безопасности ОО.
Одноуровневая оценка доверия основана на ЗБ, которое может заявлять о соот­
ветствии ПЗ или ПЗ-конфигурации, но зависит от всех заявленных ПЗ или компонентов
ПЗ-конфигурации, определяющих идентичные наборы или расширенные наборы ком­
понентов доверия к безопасности. Оценка, основанная на ЗБ, которое не содержит ни­
каких утверждений о соответствии ПЗ или определенной ПЗ-конфигурации, по своей
природе является одноуровневой оценкой доверия.
6.3.4.3 Многоуровневая оценка доверия
Парадигма многоуровневой оценки доверия состоит в применении различных
требований доверия к разным частям ФБО (под-ФБО) при одновременном применении
глобального набора ТДБ для всего ОО.
Парадигма многоуровневой оценки доверия:
- рассматривает разнородные ИТ-продукты, где разные потребности в безопас­
ности требуют разного доверия в рамках единой оценки;
- обеспечивает соответствие многоуровневых требований доверия потребностям
безопасности ИТ-продукта.
Технически многоуровневая оценка доверия действует по ЗБ, которое соответ­
ствует одной (и только одной) ПЗ-конфигурации с многоуровневым доверием. ПЗ-
конфигурация с многоуровневым доверием обеспечивает соответствие применения
различных требований доверия к различным частям ФБО их потребностями в безопас33
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
ности. В этом подходе к оценке каждая под-ФБО обеспечивает выполнение некоторых
функций безопасности, например, протокола аутентификации, политики межсетевого
экрана, процесс загрузки, и в некоторых случаях под-ФБО могут быть связаны с под­
множеством компонентов ОО, например, библиотекой или устройством чтения карт.
Парадигма многоуровневого доверия актуальна, в частности, в следующих ситу­
ациях:
- продукт, в котором некоторые функции безопасности нуждаются в большей
степени доверия, чем остальные, например, основной блок хранения и обработки, мо­
дуль безопасной загрузки и т.д.;
- продукт, в котором некоторые части функциональных возможностей безопасно­
сти не требуют такой же высокой оценки качества, как другие более открытые части,
например, интернет-шлюз с поддержкой протоколов виртуальных частных сетей;
- семейство продуктов, в котором некоторые функции безопасности совместно
используются всеми продуктами с одинаковым доверием, а некоторые функции без­
опасности реализованы по-разному для разных сценариев использования, например, в
защищенном от подделки модуле или в программном модуле, или продукты массового
распространения, требующих иного доверия;
Примером может служить семейство устройств биометрической аутентификации
с функциями сравнения на устройстве и централизованно, либо и тем, и другим. Это
может привести к появлению ПЗ для устройства аутентификации, исключая функцию
согласования, и двух ПЗ-модулей для различных типов функций согласования, каждый
со специальным набором требований доверия. Для устройства можно определить три
ПЗ-конфигурации: ПЗ с каждым из ПЗ-модулей, ПЗ с обоими ПЗ-модулями. Аналогич­
ная ситуация возникает, например, для семейства мобильных приложений, которое ис­
пользует либо программную библиотеку, защищенную с помощью методов «Белого
ящика», либо аппаратную библиотеку, либо семейство платежных терминалов со
устройствами считывания ИС и/или магнитной полосы;
- многоуровневое доверие также актуально для продуктов, утверждающих о со­
ответствии различным ПЗ с разными пакетами доверия: путем определения и оценки
ПЗ-конфигурации парадигма многоуровневого доверия позволяет лучше контролиро­
вать возможные несоответствия между этими ПЗ. Типичным примером является оцен­
ка электронных паспортов, осуществляющих как базовый контроль, так и расширенный
контроль доступа, поскольку эти механизмы контроля доступа подвержены различным
проблемам безопасности и требованиям доверия.
34
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
7 Специфицирование требований безопасности
7.1 Определение проблемы безопасности
7.1.1 Общие положения
ОПБ определяет проблему безопасности, которая может возникнуть в ПЗ, ПЗмодулях и ЗБ и должна быть решена. ОПБ для серии ИСО/МЭК 15408 аксиоматична.
То есть процесс получения ОПБ выходит за рамки серии стандартов ИСО/МЭК 15408.
Элементы ОПБ могут быть связаны с конфигурациями или требованиями, кото­
рые являются дополнительными для данного типа ОО, например, в случае, когда ОО
является распределенным, или если указаны дополнительные функциональные тре­
бования (как указано в п.7.3.2.6.1). Это разрешено, если дополнительный характер
элементов ПБОр (и любые связанные с ними цели и функциональные требования)
определены, как указано в стандарте.
Элементы ОПБ могут быть связаны с конфигурациями или требованиями, кото­
рые являются дополнительными для данного типа ОО, например, в случае, когда ОО
является распределенным, или если обозначены дополнительные функциональные
требования (как указано в п.7.3.2.6.1). Это разрешено, если идентифицирован допол­
нительный характер элементов ОПБ (и любые связанные с ними цели и функциональ­
ные требования), как указано в стандарте.
Примечания
1 Полезность результатов оценки сильно зависит от качества ПБОр. Поэтому часто стоит потра­
тить значительные ресурсы и использовать четко определенные процессы и анализы для получения хо­
рошей ПБОр. Руководство по получению ПБОр содержится в ИСО/МЭК 15446.
2 Согласно ИСО/МЭК 15408-3 не обязательно иметь утверждения во всех разделах, ПЗ с угроза­
ми не обязательно должен иметь ПБОр и наоборот. Также любой ПЗ может опускать предположения.
3 Если ОО физически распределен, может быть лучше обсудить соответствующие угрозы, ПБОр
и предположения отдельно для отдельных доменов среды функционирования ОО.
7
.1.2 Угрозы
В этом разделе ПБОр описываются угрозы, которым должен противостоять ОО,
его среда функционирования или их комбинация.
Угроза состоит из неблагоприятных действий, выполняемых источником угрозы в
отношении определенного актива.
Неблагоприятные действия влияют на одно или несколько свойств актива, кото­
рые определяют ценность этого актива.
35
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Источники угроз могут быть описаны как отдельные субъекты, но в некоторых
случаях может быть лучше описать их как типы субъектов, группы субъектов и т.д.
Примеры источников угроз:
- хакеры;
- пользователи;
- компьютерные процессы;
- несчастные случаи.
Источники угроз могут быть дополнительно определены такими атрибутами, как
опыт, ресурсы, возможности и мотивация.
Примерами угроз являются:
- оплачиваемый хакер (со значительным опытом, стандартным оборудованием)
удаленно копирует конфиденциальные файлы из сети компании;
- вредоносное программное обеспечение, серьезно снижающее производитель­
ность глобальной сети;
- системный администратор, нарушающий конфиденциальность пользователей;
а также
- нарушитель в Интернете, осуществляющий перехват конфиденциальных элек­
тронных сообщений.
7.1.3 Политики безопасности организации (ПБОр)
В этом разделе описываются ПБОр, которые должны выполняться ОО, его сре­
дой функционирования или их комбинацией.
ПБОр содержат правила, процедуры или руководящие принципы безопасности,
налагаемые в среде функционирования. ПБОр могут быть созданы организацией, кон­
тролирующей среду функционирования ОО, либо законодательными или регулирую­
щими органами. ПБОр могут применяться к ОО и/или рабочей среде ОО.
Примерами ПБОр являются:
“Только пользователи с привилегиями системного администратора и соответ­
ствующим допуском могут управлять файловым сервером отдела»;
7.1.4 Предположения
В данном разделе ПБОр описываются предположения, которые сделаны в от­
ношении среды функционирования для обеспечения функций безопасности. Если ОО
находится в среде функционирования, которая не соответствует этим предположени­
ям, ОО может оказаться не в состоянии обеспечить все свои функциональные возмож36
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
ности безопасности. Предположения могут делаться в отношении физических, кадро­
вых характеристик и связности среды функционирования.
Примеры предположений:
- предположения относительно части продукта, не относящейся к ОО;
- предполагается, что ОО будет интегрирован в устройство, обеспечивающее
основанный на аппаратном обеспечении корень доверия;
- предположения о физических аспектах среды функционирования;
- предполагается, что ОО будет размещен в помещении, спроектированном та­
ким образом, чтобы минимизировать электромагнитное излучение;
- предполагается, что консоли администратора ОО будут размещены в зоне с
ограниченным доступом;
- предположения о кадровых аспектах среды функционирования;
- предполагается, что пользователи ОО будут в достаточной степени обучены
для работы с ОО;
- предполагается, что пользователи ОО утверждены для получения информа­
ции, которая классифицируется как национальная тайна;
- предполагается, что пользователи ОО не будут записывать свои пароли;
- предположения об аспектах связности среды функционирования;
- предполагается, что для работы с ОО имеется рабочая станция ПК с не менее,
чем 10 ГБ дискового пространства;
- предполагается, что ОО является единственной версией, не связанной с ОС,
работающей на этой рабочей станции;
- предполагается, что ОО не будет подключен к ненадежной сети.
Примечание - Во время оценки эти предположения считаются верными: они никоим об­
разом не проверяются. По этим причинам предположения можно делать только в отношении среды
функционирования. Предположения никогда не могут быть сделаны в отношении поведения ОО, потому
что оценка состоит из оценивания утверждений, сделанных в отношении ОО, а не путем предположения,
что утверждения в отношении ОО истинны. Тем не менее, оценки ЗБ, ПЗ и ПЗ-конфигураций помогают
обнаружить нереалистичные предположения в отношении типа ОО и среды функционирования, которые
могут стать неприемлемыми.
7.2 Цели безопасности
7.2.1 Общие положения
Цели безопасности - это краткое изложение предполагаемого решения пробле­
мы безопасности. У целей безопасности тройная роль:
37
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
предоставить высокоуровневое на естественном языке описание решения про­
блемы. Цели безопасности состоят из совокупности утверждений без чрезмерно боль­
ших подробностей, которые вместе формируют высокоуровневое решение проблемы
безопасности. Уровень абстракции целей безопасности должен быть таким, чтобы они
были ясными и понятными для хорошо осведомленных потенциальных потребителей
ОО. Цели безопасности излагаются на естественном языке;
разделить данное решение на две части, отражающие роли ОО и его среды
функционирования в решении каждой части проблемы. В ЗБ высокоуровневое реше­
ние проблемы, которое описывается целями безопасности, делится на две части. Эти
частичные решения названы целями безопасности для ОО и целями безопасности для
среды функционирования;
- продемонстрировать, что эти частичные решения формируют полное решение
проблемы.
7.2.2 Цели безопасности для ОО
ОО обеспечивает функциональные возможности безопасности для решения не­
которой части проблемы, обозначенной определением проблемы безопасности. Дан­
ная частичное решение названо целями безопасности для ОО и состоит из совокупно­
сти целей, которые должны быть достигнуты ОО, чтобы решить свою часть проблемы.
Примеры целей безопасности для ОО:
- «ОО должен обеспечивать конфиденциальность содержания всех файлов, пе­
редаваемых между ним и сервером»;
- ОО должен выполнять идентификацию и аутентификацию всех пользователей
до предоставления им доступа к сервису передачи информации, предоставляемого
ОО;
- ОО должен ограничивать доступ пользователей к данным согласно политике
доступа к данным, описанной в Приложении 3 к ЗБ.
Если ОО является физически распределенным, может оказаться предпочти­
тельным разделить подраздел ЗБ, содержащий цели безопасности для ОО, на не­
сколько пунктов, чтобы учесть это.
При физическом распределении ОО для отражения этого может быть лучше
разделить раздел, содержащий цели безопасности для ОО, на несколько подразделов.
Примечание - В ЗБ прямого обоснования цели безопасности для ОО не включены: см.
D.4.
7.2.3 Цели безопасности для среды функционирования
38
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
В среде функционирования ОО применяются технические и процедурные меры
для поддержки ОО в отношении корректной реализации его функциональных возмож­
ностей безопасности (которые определены целями безопасности для ОО). Данная
часть решения проблемы названа целями безопасности для среды функционирования
и состоит из совокупности утверждений, описывающих цели, которые должны быть до­
стигнуты средой функционирования.
Примеры целей безопасности для среды функционирования:
- «В среде функционирования должно быть предоставлено автоматизированное
рабочее место с установленной ОС Windows для функционирования ОО на его базе»;
- «В среде функционирования должно быть обеспечено, чтобы все пользователи
ОО были соответствующим образом обучены до того, как им будет разрешено рабо­
тать с ОО;
- «Среда функционирования ОО должна ограничить физический доступ к ОО,
разрешая такой доступ только персоналу, выполняющему функции администраторов, и
персоналу технической поддержки в сопровождении административного персонала»;
- «Среда функционирования должна обеспечить конфиденциальность журналов
аудита, полученных от ОО, на сервер аудита».
Если среда функционирования ОО состоит из нескольких физических объектов,
каждый из которых обладает разными характеристиками, для отражения этого может
быть целесообразно разделить раздел, содержащий цели безопасности для среды
функционирования, на несколько пунктов.
Компоненты третьей стороны, которые не должны оцениваться из-за недоступ­
ности доказательств оценки, включаются в среду, а цели безопасности для среды
функционирования должны включать в себя то, что компонент третьей стороны рабо­
тает, как задумано.
7.2.4 Связь между целями безопасности и ПБОр
ЗБ, ПЗ, ПЗ-модули и пакеты также содержат обоснование целей безопасности,
состоящее из двух разделов:
а) прослеживание, показывающее, какие цели безопасности относятся к каким
элементам ОПБ;
Ь) набор обоснований, показывающий, что все элементы ОПБ эффективно ре­
шаются целями безопасности.
Примечание - ВПЗ «Прямое обоснование» не включено обоснование целей безопасно­
сти в ОО: см. D.4.
39
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Угроза «Т17: источник угрозы X считывает конфиденциальную информацию при
передаче между А и В», цель безопасности для ОО: «: ОТ12: ОО должен обеспечивать
сохранение конфиденциальности всей информация, передаваемой между А и В при
помощи ОТ12», и демонстрация «ОТ12 непосредственно противостоит Т17».
7.2.5 Прослеживание связи между целями безопасности и ОПБ
Прослеживание показывает обратную связь целей безопасности с элементами
ОПБ и что:
а) ложные цели отсутствуют;
Примечание - Каждая цель безопасности связана как минимум с одним элементом ОПБ.
Ь) определение проблемы безопасности охвачено полностью;
Примечание - Каждый элемент ОПБ имеет как минимум одну связанную с ним цель без­
опасности.
с) прослеживание корректно.
Поскольку ОО всегда делает предположения относительно среды функциониро­
вания, цели безопасности для ОО не отслеживаются к предположениям. Прослежива­
ния, допустимые по ИСО/МЭК 15408-3, показаны на рисунке 3.
Определение проблем безопасности
Угрозы
Пол итика
безопасности
организации
Цели безопасности
для ОО
Предложения
Цели безопасности
для среды
функционирования
Рисунок 3 - Прослеживания между целями безопасности и ОПБ
Несколько целей безопасности можно отследить к одной и той же угрозе, указы­
вая на то, что комбинация этих целей безопасности противодействует этой угрозе.
Аналогичный аргумент справедлив для ОПБ и предположений.
7.2.6 Обоснование прослеживания
Обоснование целей безопасности также демонстрирует эффективность просле­
живания: все указанные угрозы, ПБОр и предположения рассматриваются (то есть им
оказывается противодействие, они применяются и поддерживаются соответственно),
40
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
если все цели безопасности, отслеживаемые до конкретной угрозы, ПБОр или предпо­
ложения, достигнуты.
Эта демонстрация анализирует воздействие достижения соответствующих це­
лей безопасности на противодействие угрозам, выполнение ПБОр и поддержку пред­
положений и приводит к выводу, что это действительно так.
В некоторых случаях, когда части ПБОр очень похожи на некоторые цели без­
опасности, демонстрация может быть несложной.
7.2.7 О противодействии угрозам
Противодействие угрозе не обязательно означает устранение этой угрозы, это
также может означать достаточное снижение вероятности реализации этой угрозы или
достаточное смягчение связанного с ней риска.
Примеры устранения угрозы:
- лишение источника угрозы возможности выполнить неблагоприятное действие;
- перемещение, изменение или защита актива таким образом, чтобы неблаго­
приятное действие больше не было к нему применимо;
- удаление источника угрозы.
Например, удаление машин из сети, которые часто вызывают сбои в этой сети.
Примеры снижения вероятности реализации угрозы:
- ограничение способности источника угрозы совершать неблагоприятные дей­
ствия;
- ограничение возможности выполнения неблагоприятного действия источника
угрозы;
- снижение вероятности успешного выполнения неблагоприятного действия;
- снижение мотивации к выполнению неблагоприятного действия источника угро­
зы путем его сдерживания;
- необходимость большего опыта или больших ресурсов от источника угрозы.
Примеры смягчения последствий угрозы:
- частое резервное копирование актива;
- создание запасных копий актива;
- страхование актива;
- обеспечение успешного своевременного обнаружения неблагоприятных дей­
ствий с целью принятия к ним соответствующих мер.
7.2.8 Цели безопасности: заключение
41
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Основываясь на целях безопасности и их обосновании, делается следующий
вывод: если все цели безопасности достигнуты, то проблема безопасности, как опре­
делено в определении проблемы безопасности, решена: всем угрозам противодей­
ствуют, все ПБОр выполняются, и все предположения поддержаны.
Примечание - Это определение поддерживается семейством АЭЕ_ОПБ в ИСО/МЭК
15408-3.
7.3 Требования безопасности
7.3.1 Общие положения
Как упомянуто в п. 6.3.3.4 и 6.3.3, пакеты, ПЗ, ПЗ-модули, ПЗ-конфигурации и ЗБ
определяют подробные требования безопасности, применимые к ОО, которые были
выведены из заявленных ПБОр. Функциональные требования безопасности и требова­
ния обеспечения безопасности должны быть взяты из компонентов безопасности,
определенных в ИСО/МЭК 15408-2 и ИСО/МЭК 15408-3 соответственно, которые яв­
ляются шаблоном требований безопасности, написанных на стандартизованном языке.
Процесс получения требования безопасности из компонента безопасности включает в
себя «переваривание компонентов» и известен как «завершение».
Примечание - В разделе 7 термин «разработчик» включает разработчиков ЗБ, ПЗ, ПЗ-
модулей, ПЗ-конфигураций и пакетов.
Требования безопасности указаны в результате описания в ЗБ и, возможно, ПЗ,
ПЗ-модуль и пакеты. Требования безопасности определяются путем выбора компонен­
тов, указанных в 15408-2, ИСО/МЭК 15408-3 или определенных как расширенные ком­
поненты в соответствии с 8.4. В процессе адаптации используются операции из 8.2.
Требования безопасности указаны как результат описания в ЗБ и, возможно, ПЗ,
ПЗ- модуль и пакетов. Требования безопасности определяются путем выбора компо­
нентов, указанных в ИСО/МЭК 15408-2, ИСО/МЭК 15408-3 или определенных как рас­
ширенные компоненты в соответствии с подразделом 8.4. В процессе адаптации ис­
пользуются операции из подраздела 8.2.
Требования безопасности состоят из двух групп:
а) функциональных требований безопасности (ФТБ): описание того, как ОО об­
ращается к ПБОр на стандартизованном языке;
Ь) требования доверия к безопасности (ФТБ): описание того, каким образом
должно быть получено доверие к тому, что ОО удовлетворяет ФТБ.
Примечание - ФТБ касаются соответствия ОО стандарту ЗБ. ФТБ не играют никакой ро­
ли в сфере действия ОПБ, которое входит в сферу действия целей безопасности и функциональных
требований безопасности.
42
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Эти две группы рассматриваются в п. 7.3.2 и 7.3.3.
7.3.2 Функциональные требования безопасности
7.3.2.1 Общие положения
ФТБ вносят вклад в выполнение определения проблемы безопасности (ПБОр)
ОО и относятся к задачам безопасности, определенным для ОО. Обычно они находят­
ся на более детальном уровне абстракции, но они должны быть полным переводом
(цели для ОО безопасности должны быть полностью решены). Серия ИСО/МЭК 15408
требует этого перевода на стандартизованный язык по следующим причинам:
- дать точное описание того, что подлежит оценке. Поскольку цели безопасности
для ОО обычно формулируются на естественном языке, перевод их на стандартизиро­
ванный язык способствует более точному описанию функциональных возможностей
ОО;
- дать сопоставление двух ЗБ. В то время как различные разработчики ЗБ могут
использовать различную терминологию при описании целей безопасности, стандарти­
зированный язык обеспечивает использование единой терминологии и понятий при из­
ложении требований безопасности. Это позволяет легко сравнивать ЗБ;
- дать точное описание того, что подлежит оценке. Этот стандартизированный
язык требует использования одной и той же терминологии и концепций. Это позволяет
сравнивать ЗБ, даже если разработчики используют разную терминологию при описа­
нии своих ПБОр и целей безопасности (такой ситуации не возникает, если ЗБ соответ­
ствуют одной и той же ПЗ или ПЗ-конфигурации).
В контексте ПЗ и ПЗ-модулей ФТБ не должны зависеть от какого-либо конкретно­
го технического решения (реализации).
В документах не требуется перевод целей безопасности для среды функциони­
рования, потому что она не оценивается и, следовательно, не требует описания, пред­
назначенного для ее оценки.
Примечания
1 Пункты, относящиеся к оценке безопасности систем см. в Библиографии.
2 Может случиться так, что части среды функционирования оцениваются при другой оценке, но
это выходит за рамки настоящего стандарта.
Для ОО операционной системы может потребоваться наличие межсетевого
экрана в его среде функционирования другая оценка может впоследствии оценить
межсетевой экран, но эта оценка не имеет ничего общего с оценкой ОО ОС.
7 .3.2.2 Как поддерживается этот перевод
43
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Серия ИСО/МЭК 15408 поддерживает этот перевод тремя способами:
а) путем предоставления заранее определенного «языка», предназначенного
для точного описания того, что подлежит оценке. Язык определяется как набор компо­
нентов, определенных в ИСО/МЭК 15408-2. Использование языка для четко опреде­
ленного перевода целей безопасности для ОО в ФТБ является обязательным, хотя
существуют некоторые исключения, приведенные в п.8.4;
Ь) путем предоставления операций: механизмов, которые позволяют разработ­
чику пакета, ЗБ, ПЗ или ПЗ-модуля заполнять и изменять ФТБ, чтобы обеспечить бо­
лее точный перевод целей безопасности для ОО или типа ОО. В данном Документе
определены четыре разрешенные операции: присвоение, выбор, итерация и уточне­
ние. Они изложены ниже в п.8.2;
с) путем предоставления зависимостей: механизма, который поддерживает бо­
лее полный перевод в ФТБ. В языке ИСО/МЭК 15408-2 ФТБ может зависеть от других
ФТБ. Это означает, что если ЗБ использует определенное ФТБ, ему обычно необходи­
мо использовать и эти другие ФТБ. Это затрудняет разработчику ЗБ возможность про­
пустить включение необходимых ФТБ и тем самым улучшает полноту ЗБ. Зависимости
описаны далее в п.8.3.
7.3.2.3 Взаимосвязь между ФТБ и целями безопасности
Пакеты, ПЗ, ПЗ-модули и ЗБ содержат обоснование требований безопасности,
включающее два пункта, касающихся ФТБ:
- прослеживание, показывающее, какие ФТБ какие цели безопасности для ОО
учитывают;
- совокупность логических обоснований, показывающих, что все цели безопасно­
сти для ОО надлежащим образом учтены в ФТБ.
Примечание - В подходе Прямое обоснование представлено прослеживание ФТБ к ОПБ.
7.3.2.4 Прослеживание между ФТБ и целями безопасности для ОО
Прослеживание показывает, как ФТБ прослеживаются ДО целей безопасности
для ОО следующим образом:
а) отсутствие ложных ФТБ: каждое ФТБ прослеживается как минимум до одной
цели безопасности;
Ь) завершены по отношению к целям безопасности для ОО: каждая цель без­
опасности для ОО прослеживается, по крайней мере, к одной ФТБ.
44
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Несколько ФТБ могут прослеживаться к одной и той же цели безопасности для
ОО, указывая, что комбинация этих требований безопасности соответствует этой цели
безопасности для ОО.
7.3.2.5 Обоснование прослеживания
Обоснование функциональных требований безопасности демонстрирует, что
прослеживание является эффективным: если все ФТБ, прослеживающие конкретную
цель безопасности для ОО, выполнены, эта цель безопасности для ОО достигнута.
Эта демонстрация анализирует влияние выполнения соответствующих ФТБ на
достижение целей безопасности для ОО и приводит к выводу, что это действительно
так.
7.3.2.6 Специальные типы ФТБ
ФТБ могут быть обозначены в пакетах, ПЗ и ПЗ-модулях как необязательные
требования или требования на основе выбора.
7.3.2.6.1 Необязательные требования
Необязательные требования являются «необязательными» в том смысле, что их
не нужно включать в ПЗ/ЗБ для утверждения ПЗ/ЗБ о соответствии (любого типа)
определенному ПЗ или ПЗ-конфигурации.
Пакеты, ПЗ и ПЗ-модули могут определять необязательные требования по одной
из двум категориям. Каждая категория явно указана разработчиком.
Первая категория необязательных требований - факультативные требования.
Требования этой категории необязательно включать в ПЗ/ЗБ утверждения о соответ­
ствии (любому типу) ПЗ или ПЗ-конфигурации, в которых определено требование. В
этом случае необязательно включение в ПЗ/ЗБ данного требования, даже если ОО ре­
ализует функцию, указанную в требовании.
Вторая категория необязательных требований - условная. Если ОО реализует
указанную функцию, то необязательное требование должно быть включено в ПЗ/ЗБ.
Если ОО не реализует функцию, включенную в дополнительное требование, то это
требование не включается в ПЗ/ЗБ.
Примечание - Необязательные требования могут быть записаны как реакция на элемен­
ты ОПБ, которые существуют в пакете, ПЗ или ПЗ-модуле, или элементы ПБОр, которые особо ассоции­
рованы с требованием. Такие ассоциации обозначены в пакете, ПЗ или ПЗ-модуле. Пакет Прямое обос­
нование, ПЗ, ПЗ-модуль или ЗБ не определяют цели безопасности для необязательных требований, ко­
торые имеют ассоциированные элементы ПБОр, в то время как обычный пакет, ПЗ, ПЗ-модуль или ЗБ
включает цели безопасности для ассоциированных ФТБ и элементов ПБОр.
7.3.2.6.2 Требования, основанные на выборе
45
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Пакеты, ПЗ и ПЗ-модули могут идентифицировать набор ФТБ на основе выбора.
В этом случае разработчик дополнительно обеспечивает, что пакет/ПЗ/ПЗ-модуль чет­
ко обозначат зависимости между конкретным выбором в некоем функциональном ком­
поненте безопасности и/или ФТБ, включенным в пакет/ПЗ/ПЗ-модуль, и связанным с
ним основанным на выборе ФТБ, которые должны быть включены, если этот выбор бу­
дет выбран другим разработчиком ПЗ/ЗБ. Объяснение этому дано в п. 8.2.4.2.
7.3.3 Требования доверия к безопасности (ТДБ)
7.3.3.1 Общие положения
ТДБ представляют собой описание того, как должен оцениваться ОО, который
может быть определен в пакетах, ПЗ, ПЗ-модулях, ПЗ-конфигурациях и ЗБ. В этом
описании используется стандартизованный язык по двум причинам:
- для предоставления точного описания того, как должен оцениваться ОО;
- для сравнения двух ЗБ. Стандартизованный язык требует использования оди­
наковых терминологии и концепций.
Стандартизованный
язык
представлен
компонентами,
определенными
в
ИСО/МЭК 15408-3, а определение разрешенных операций дано в разделе 8. Использо­
вание языка является обязательным, хотя существуют некоторые исключения. Серия
ИСО/МЭК 15408 улучшает язык двумя способами:
а) путем предоставления операций: механизмов, которые позволяют разработ­
чику пакета/ПЗ/ПЗ-модуля/ПЗ-конфигурации/ЗБ изменять ТДБ. Серия ИСО/МЭК 15408
содержит четыре операции: назначение, выбор, итерация и уточнение. Они ниже в 8.2;
Ь) путем предоставления зависимостей: механизм, который обеспечивает согла­
сованный выбор из других ФТБ для завершения зависимого ТДБ. На языке ИСО/МЭК
15408-3 определенное может зависеть от других ТДБ. Это означает, что если па-
кет/ПЗ/ПЗ-модуль/ПЗ-конфигурация/ЗБ использует это ТДБ, ему, как правило, также
необходимо использовать эти другие ТДБ. Это значительно затрудняет разработчику
возможность упущения из виду включения необходимых ТДБ и тем самым улучшает
полноту пакетов, ЗБ, ПЗ, ПЗ-модулей и ПЗ-конфигураций. Зависимости описаны далее
в 8.3;
Примечание - В ТДБ, определенных в стандарте ИСО/МЭК 15408-3, не используются
назначения или выборы. Однако можно определить расширенные компоненты доверия, которые позво­
ляют выполнять эти операции.
7.3.3.2 ТДБ и обоснование требований безопасности
46
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Пакеты доверия, ПЗ, ПЗ-модули, ПЗ-конфигурации и ЗБ также содержат обосно­
вание требований безопасности, которое объясняет, почему выбранный набор(ы) ТДБ
считается подходящим.
Примечание - В случае точного соответствия ПЗ-модуль наследует ТДБ от своей базы
ПЗ-модулей, поэтому обоснование ТДБ не требуется.
ТДБ способствует уверенности заказчика в оценке. Многие ТДБ, приведенные в
стандарте ИСО/МЭК 15408-3, относятся к процессам проектирования и разработки, ис­
пользуемым разработчиком при реализации ОО, и к тестированию разработчиков. Не­
которые ТДБ относятся к оперативным ОО, таким как безопасный процесс доставки и
устранение дефектов. Некоторые ТДБ относятся конкретно к оценке анализа уязвимо­
стей оценщиком и независимому функциональному тестированию и тестированию на
проникновение.
Примером несоответствия в выборе ТДБ является то, что в ПБОр упоминаются
угрозы, в которых источник угрозы имеет существенные возможности, и при этом в ТДБ
включен анализ уязвимости с низким уровнем (или без него) (AVA_VAN).
7.3.4 Требования безопасности: вывод
В разделе ПБОр функционального пакета/ПЗ/ПЗ-модуля/ЗБ проблема безопас­
ности определяется как состоящая из элементов ОПБ: угроз, ПБОр и предположений.
В разделе целей безопасности функционального пакета/ПЗ/ПЗ-модуля/ЗБ решение
представлено в виде двух решений:
- цели обеспечения безопасности для ОО;
- цели обеспечения безопасности для среды функционирования.
Кроме того, логическое обоснование целей безопасности приводится для под­
тверждения того, что проблема безопасности решена, если достигнуты все цели без­
опасности.
В разделе требования к безопасности цели безопасности для ОО переводятся в
ФТБ, и приводится обоснование требований безопасности, показывающее, что, если
все ФТБ соблюдены, все цели безопасности для ОО достигнуты.
Кроме того, предоставляется набор ТДБ, чтобы показать, как оценивается ОО,
наряду с объяснением выбора этих ТДБ. Набор ТДБ должен соответствовать ожидани­
ям безопасности, вытекающим из ОПБ. Объяснение выбора ТДБ должно содержаться
в обосновании ТДБ.
Сама среда функционирования не входит в сферу оценки, хотя, когда класс до­
верия AGD включен в ЗБ, руководство ОО должно полностью отражать эти цели без47
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
опасности для среды функционирования и оценивается как часть оценивания с ис­
пользованием класса AGD.
Все вышесказанное объединяется в утверждение: “Если все ФТБ и ТДБ удовле­
творены и все цели безопасности для среды функционирования достигнуты, то суще­
ствует доверие к тому, что проблема безопасности, определенная в ASE_SPD, реше­
на: все угрозы устранены, все ПБОр выполняются, и все предположения подтвержде­
ны”. Это проиллюстрировано на рисунке 4.
Определение проблем безопасности
Угрозы
Пол итика
безопасности
организации
Предположения
Цели безопасности
для ОО
Цели безопасности
для среды
функционирования
Функциональные
требования
безопасности
Требования доверия
к безопасности
Рисунок 4 - Взаимосвязи между ПБОр, целями безопасности и требованиями безопас­
ности
Степень доверия, полученная в результате оценивания, определяется ТДБ, и
описание того, является ли эта степень доверия достаточной для заказчиков, исполь­
зующих ЗБ, содержится в пояснении, данном для выбора этих ТДБ.
8 Компоненты безопасности
8.1 Иерархическая структура компонентов безопасности
8.1.1 Общие положения
ИСО/МЭК 15408-2 и ИСО/МЭК 15408-3 предоставляют каталоги компонентов
безопасности, которые должны использоваться при определении требований безопас­
ности. Каталоги организовали компоненты в иерархическую структуру на четырех
уровнях:
48
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
- классы, состоящие из семейств;
- семейства, состоящие из компонентов;
- компоненты, состоящие из элементов;
- элементы, которые не имеют составных частей.
8.1.2 Класс
Требования
к функциональным
классам
приведены
в п. 6.1.2
стандарта
ИСО/МЭК 15408-2, требования к классам доверия приведены в подразделе 6.2 стан­
дарта ИСО/МЭК 15408-3.
Класс состоит из набора семейств.
Примером класса является класс “FIA: Идентификация и аутентификация”, кото­
рый ориентирован на идентификацию пользователей, аутентификацию пользователей
и привязку пользователей и субъектов.
8.1.3 Семейство
Требования к функциональным семействам приведены в п. 6.1.3 стандарта
ИСО/МЭК 15408-2. Требования к семействам доверия приведены в подразделе 6.3
стандарта ИСО/МЭК 15408-3.
Семейство состоит из набора компонентов.
Примером
семейства
является
семейство
“Аутентификация
пользователя
(FIA_UAU)”, которое является частью класса "FIA: Идентификация и аутентификация”.
Это семейство сосредоточено на аутентификации пользователей.
8.1.4 Компонент
Требования к структуре функциональных компонентов приведены в п. 6.1.4
стандарта ИСО/МЭК 15408-2, Требования к компонентам доверия приведены в под­
разделе 6.4 стандарта ИСО/МЭК 15408-3.
Компонент состоит из набора элементов.
Примером компонента является “FIA_UAU.3 Недопустимая аутентификация”, ко­
торая концентрируется на неподделываемой аутентификации.
8.1.5 Элемент
Требования к функциональным элементам приведены в п. 6.1.4 стандарта
ИСО/МЭК 15408-2. Требования к элементам обеспечения приведены в подразделе 6.5
стандарта ИСО/МЭК 15408-3.
Примером элемента является “FIA_UAU.3.2”, который концентрируется на
предотвращении использования скопированных аутентификационных данных.
8.2
Операции
49
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
8.2.1 Общие положения
ИСО/МЭК 15408-2 и ИСО/МЭК 15408-3 представляют каталоги компонентов без­
опасности, и настоящий стандарт предоставляет разработчикам возможность расши­
рять каталоги компонентов при некоторых обстоятельствах. Применяя операции к ком­
понентам безопасности, эти компоненты могут быть точно адаптированы к потребно­
стям разработчика при разработке ПЗ, ПЗ-модулей, пакетов и ЗБ.
Компоненты безопасности могут использоваться точно так, как определено в
стандартах ИСО/МЭК 15408-2 и ИСО/МЭК 15408-3, или они могут быть адаптированы
посредством использования разрешенных операций.
При использовании операций разработчик должен следить за тем, чтобы удо­
влетворялись потребности зависимостей других требований, зависящих от требования.
Разрешенные операции выбираются из следующего набора:
а) итерация: позволяет использовать компонент более одного раза с различны­
ми операциями;
Ь)
назначение: позволяет задавать параметры;
с)
выбор: позволяет указать один или несколько элементов из списка; и
d)
уточнение: позволяет добавлять подробности.
Операции назначения и выбора разрешены только в тех случаях, когда это кон­
кретно указано в компоненте. Итерация и уточнение разрешены для всех требований
безопасности. Эти операции более подробно описаны ниже.
Приложения ИСО/МЭК 15408-2 содержат руководство по правильному заверше­
нию отбора и назначений. В этом руководстве содержатся инструкции о том, как вы­
полнять операции, и этим инструкциям следует следовать, если отклонение от них не
обосновано разработчиком:
- “Отсутствует” применяется только в качестве опции для завершения выбора,
если это явно указано;
В списках, предоставленных для завершения отбора, не должно быть параметра
“Отсутствует” пустыми. Если выбран параметр “Отсутствует”, не могут быть выбраны
никакие дополнительные параметры выбора. Если “Отсутствует” не указано в качестве
опции в выборе, допустимо комбинировать варианты выбора в выборе с “и” и “или”, ес­
ли в выборе явно не указано “выбрать один из следующего”.
При необходимости операции выбора могут быть объединены итерацией. В этом
случае применимость параметра, выбранного для каждой итерации, не должна пере­
50
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
крывать предмет другого итерационного выбора, поскольку они предназначены для ис­
ключения.
- для завершения назначений
необходимо ознакомиться с приложениями
ИСО/МЭК 15408-2, чтобы определить, когда “Отсутствует” будет действительным за­
вершением.
8.2.2 Итерация
Операцию "итерация" можно выполнить по отношению к любому компоненту.
Разработчик ПЗ/ЗБ выполняет операцию "итерация" путем включения нескольких тре­
бований, основанных на одном и том же компоненте. Каждая итерация компонента
должна отличаться от всех других итераций компонента, что реализуется завершением
по-другому операций "назначение" и "выбор" или применением по-другому операции
"уточнение".
Различные итерации следует уникально идентифицировать, чтобы обеспечить
четкое обоснование и прослеживаемость от этих требований или к ним. Идентифика­
торы итерации должны быть понятны читателям.
Повторение дважды компонента FCS_COP.1 для того, чтобы потребовать реали­
зации двух различных алгоритмов.
Примечание - Иногда операцию итерации можно использовать с компонентами, когда
также можно выполнить операцию назначения с рядом или списком значений вместо их повторения. В
этом случае разработчик может выбрать наиболее приемлемую альтернативу, учитывая, существует ли
необходимость в предоставлении всего обоснования ряда значений или необходимо иметь отдельное
обоснование для каждого из них. Разработчик учитывает, требуются ли отдельное прослеживание для
этих значений.
8.2.3 Назначение
Операция назначения осуществляется, когда данный компонент содержит эле­
мент с параметром, который может быть задан разработчиком. Параметром может
быть ничем не ограниченная переменная или правило, которое ограничивает перемен­
ную конкретным диапазоном значений.
Всякий раз, когда элемент в ПЗ, ПЗ-модуле или пакете в ПЗ/ПЗ-модуле содержит
назначение, должен выполнить одно из четырех действий:
а) оставить назначение незавершенным;
Разработчик может включить FIA_AFL.1.2 в ПЗ, ПЗ-Модуль или пакет.
“Когда было сделано или превышено определенное количество неудачных по­
пыток аутентификации, ФБО должна [назначение: список действий]”.
В этом случае разработчик ЗБ мог бы завершить FIA_AFL.1.2 таким образом:
51
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
“Когда было сделано или превышено определенное количество неудачных по­
пыток аутентификации, ФБО должна предотвратить привязку внешней сущности к ка­
кому-либо субъекту в будущем”.
Ь) завершить назначение;
Разработчик может включить FIA_AFL.1.2 в ПЗ, ПЗ-Модуль или пакет.
“Когда определенное количество неудачных попыток аутентификации было вы­
полнено или превышено, ФБО должна предотвратить привязку внешнего объекта к ка­
кому-либо субъекту в будущем”.
а) сузить назначение, чтобы еще больше ограничить допустимый диапазон зна­
чений;
Разработчик может включить FIA_AFL.1.1 в ПЗ, ПЗ-модуль или пакет.
“ФБО должна обнаруживать, когда [назначение: положительное целое число]
происходят неудачные попытки аутентификации ...”
В этом случае разработчик ЗБ может завершить FIA_AFL.1.1 таким образом:
“ ФБО должна обнаруживать, когда происходят 3 неудачные попытки аутентифи­
кации ...”
Ь)
преобразуйте назначение в выбор, тем самым сужая назначение.
Разработчик может включить FIA_AFL.1.2 в ПЗ, ПЗ-модуль или пакет.
“Когда определенное количество неудачных попыток аутентификации было совершено или пре­
вышено, ФБО должна [выбор: предотвратить привязку пользователя к какому-либо субъекту в
будущем, уведомить администратора].”_____________________________________________________
В этом случае разработчик ЗБ может завершить FIA_AFL.1.2 следующим обра­
зом:
“Когда определенное количество неудачных попыток аутентификации было совершено или превышено,
ФБО должна предотвратить привязку пользователя к какому-либо субъекту в будущем.”______________
Разработчик ЗБ должен завершить все назначения.
Значения, выбранные в вариантах Ь) и с), должны соответствовать указанному
типу, требуемому назначением.
Когда задание должно быть выполнено с определенным набором, разработчику
следует предоставить описание набора, из которого могут быть получены элементы
набора, поскольку ясно, какие субъекты имеются в виду.
Когда набор - это “субъекты”:
- все субъекты;
- все субъекты типа X;
- все субъекты, кроме субъекта А.
8.2.4 Выбор
52
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
8.2.4.1 Общие положения
Операция выбора выполняется, когда данный компонент содержит элемент, ко­
гда разработчик должен сделать выбор из нескольких элементов.
Всякий раз, когда элемент в ПЗ, ПЗ-модуле или пакете содержит выделение,
разработчик может выполнить одно из трех действий:
а) оставить выбор незавершенным;
Ь) завершить выбор, выбрав один или несколько элементов;
с) ограничить выбор, удалив некоторые варианты, но оставив два или более.
Всякий раз, когда элемент в ПЗ, ПЗ-модуле или пакете содержит выбор, разра­
ботчик ЗБ должен завершить этот выбор, как указано выше в Ь). Варианты а) и с) для
ЗБ не допускаются.
Элемент или элементы, выбранные в п Ь) и с), должны быть взяты из элементов,
указанных в выборе.
Примером элемента с выбором является:
FPT_TST.1.1 “ФБО должна выполнить набор самотестирования [выбор: во вре­
мя первоначального запуска, периодически во время нормальной работы, по запросу
авторизованного пользователя, при условиях [назначение: условия, при которых долж­
но выполняться самотестирование]] для демонстрации корректной работы...”
8.2.4.2 Основанные на выборе функциональные компоненты и ФТБ
ПЗ, ПЗ-модуль или пакет могут определять набор функциональных компонентов
безопасности и/или ФТБ, называемых основанные на выборе ФТБ. Этот набор компо­
нентов и/или ФТБ связан с выбором, сделанным в другом компоненте и/или ФТБ в ПЗ,
ПЗ-модуле или пакете. Родственные основанные на выборе компоненты и/или ФТБ
должны быть включены в ПЗ, ПЗ-модуль, пакет или ЗБ, если:
- выбранный компонент, идентифицированный в ПЗ, ПЗ-модуле или пакете, ука­
зывает, что он имеет ассоциированное основанное на выборе ФТБ; и
-
этот выбор сделан разработчиком.
ПЗ, ПЗ-модуль или пакет могут быть организованы таким образом, чтобы осно­
ванные на выборе компоненты и/или ФТБ были сгруппированы вместе.
В случае, если разработчику надо оставить операцию выбора незавершенной,
он должен оставить основанные на выборе компоненты и/или ФТБ без изменений.
В случае, когда автору надо завершить выбор, разработчики должны включить
основанные на правильном выборе компоненты и/или ФТБ в перечень ФТБ для ПЗ, ПЗ-
модуля, пакета или ЗБ.
53
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
В случае, когда операция выбора должна быть ограничена, т.е. удаляются неко­
торые, но не все основанные на выборе элементы, разработчик должен удалить все
основанные на выборе компоненты и/или ФТБ из перечня, соответствующего вариан­
там, удаленным из выбора.
Ниже приведен еще один пример такого:
FTPJTC.1.1 ФБО должна быть в состоянии использовать [выбор: IPSec, SSH, TLS, HTTPS] для обеспе­
чения надежного канала связи между...
Примечание о применении:
При выборе для FTPJTC.1.1 разработчик ЗБ выбирает механизм или механизмы, поддерживаемые
ОО, а затем обеспечивает включение основанных на выборе требований в Приложение В ПЗ, которые
соответствуют выбранному механизму или механизмам, в ЗБ.
И Приложении В примера ПЗ:
Если разработчик ЗБ выбирает “IPSec” в FTPJTC.1.1, в ЗБ включаются следующие ФТБ : FCS_IPSEC.1
[•••]______________________________________________________________________________________
Пример основанного на выборе ФТБ, где ФТБ _1ТС.1.1-это ФТБ результатом, а
FCS_IPSEC.1 - это основанное на выборе ФТБ.
8.2.4.3 Уточнение
Операция уточнения может быть выполнена по любому требованию. Разработ­
чик выполняет уточнение, изменяя это требование.
Примечание - Серия уточненных операций итерации может использоваться для охвата
всех субъектов, объектов, операций, атрибутов безопасности и/или внешних сущностей, там, где каждое
отдельное уточнение этого не делает.
Первое правило для уточнения состоит в том, что ОО, удовлетворяющий уточ­
ненному требованию, также соответствует неуточненному требованию в контексте ПЗ,
ПЗ-модуля, пакета или ЗБ. То есть уточненное требование должно быть “строже”, чем
первоначальное требование. Если уточнение не соответствует этому правилу, полу­
ченное в результате уточнение считается расширенным требованием и должно рас­
сматриваться как таковое в соответствии с подразделом 7.3.
Примером действительного уточнения является:
FIA_UAU.2.1 “ФБО должна требовать успешной аутентификации каждого пользователя, прежде
чем разрешать любые другие действия, связанные с ФБО, от имени пользователя”, уточняется
ДО “ФБО должна требовать, чтобы каждый пользователь был успешно аутентифицирован по
имени пользователя/паролю, прежде чем разрешать любые другие действия, связанные с ФБО,
от имени пользователя”
Единственным исключением из правила является то, что разработчик может
уточнять ФТБ для применения только к некоторым, но не всем субъектам, объектам,
операциям, атрибутам безопасности и/или внешним сущностям. Однако, это исключе­
ние не применяется для уточнения ФТБ, которые взяты из ПЗ, ПЗ-модулей или пакета,
к которым утверждается соответствие; эти ФТБ не должно быть утонченным для при54
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
менения к меньшему количеству субъектов, объектов, операций, атрибутов безопасно­
сти и/или внешних сущностей, чем количеству ФТБ в исходном ПЗ, ПЗ-модуле или па­
кете.
Примером такого исключения является:
FIA_UAU.2.1 “Т ФБО должна требовать, чтобы каждый пользователь был успешно аутентифици­
рован, прежде чем разрешать любые другие действия, связанные с ФБО, от имени пользовате­
ля”. уточняется ДО “ФБО должна требовать успешной аутентификации каждого пользователя из
интернета, прежде чем разрешать любые другие действия, связанные с ФБО, от имени пользова­
теля.”
Вторым правилом уточнения является то, что уточнение должно быть связано с
исходным компонентом.
Примечание - Уточнение компонента аудита Дополнительным элементом по предот­
вращению электромагнитного излучения не допускается.
Особым случаем уточнения является редакторское уточнение, когда в требова­
ние может быть внесено небольшое изменение, т.е. перефразирование предложения
для более правильного изложения, с точки зрения правил русского языка.
Примером редакторского уточнения является:
ФТБ FPT_FLS.1, “ФБО должны продолжать сохранять безопасное состояние при возникновении следу­
ющих сбоев: выход из строя одного ЦП или даже FPT_FLS.1, “ФБО должны продолжать сохранять
безопасное состояние при сбое ЦП”.__________________________________________________________
8.3 Зависимости между компонентами
Между компонентами могут существовать зависимости. Зависимости возникают,
когда компонент не является самодостаточным и для обеспечения функциональности
или доверия к безопасности зависит от наличия какого - либо другого компонента.
Функциональные компоненты в стандарте ИСО/МЭК 15408-2 обычно зависят от
других функциональных компонентов. Некоторые компоненты обеспечения в стандарте
ИСО/МЭК 15408-3 также имеют зависимости, которые, в свою очередь, могут зависеть
от других компонентов стандарта ИСО/МЭК 15408-3.
Также могут быть определены зависимости ИСО/МЭК 15408-2 от компонентов
ИСО/МЭК 15408-3. Расширенные функциональные компоненты/компоненты доверия
могут аналогичным образом определять зависимости.
Описания зависимостей компонентов определяются путем ознакомления с опре­
делениями компонентов, приведенными в стандартах ИСО/МЭК 15408-2, ИСО/МЭК
15408-3 или расширенном определении компонентов. Чтобы обеспечить полноту тре­
бований безопасности ОО, зависимости должны выполняться, когда требования, осно­
ванные на компонентах с зависимостями, включены в ПЗ, ПЗ-модули, пакеты или ЗБ.
Зависимости также следует учитывать при создании пакетов.
55
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Другими словами, если компонент А зависит от компонента В, это означает, что
всякий раз, когда ПЗ, ПЗ - модуль, пакет или содержат требование безопасности, осно­
ванное на компоненте А, ПЗ, ПЗ-модуль, пакет или ЗБ также должны содержать одно
из следующего:
а) требование безопасности, основанное на компоненте В;
Ь) требование безопасности, основанное на компоненте, который иерархически
выше В;
с) обоснование того, почему ПЗ, ПЗ-модуль, пакет или ЗБ не содержит требова­
ний безопасности, основанных на компоненте В.
В случаях а) и Ь), когда требование безопасности не включено из-за определен­
ной зависимости, может потребоваться выполнение операций (назначение, итерация,
уточнение, выбор) по этому требованию безопасности особым образом, чтобы убе­
диться, что оно действительно удовлетворяет зависимость.
В случае с) обоснование того, что требование безопасности не включено, долж­
но включать либо:
- почему зависимость не является необходимой или полезной; либо
- учтена средой функционирования ОО, и в этом случае в обосновании должно
быть изложено, как цели безопасности для среды функционирования учитывают эту
зависимость; или
что зависимость была учтена другими ФТБ неким другим образом (расширенные
ФТБ, комбинации ФТБ и т.д.).
8.4 Расширенные компоненты
8.4.1 Общие положения
Требования безопасности должны основываться на компонентах из ИСО/МЭК
15408-2 или ИСО/МЭК 15408-3 с двумя исключениями:
а) существуют цели безопасности для ОО, которые не могут быть преобразова­
ны в ФТБ с использованием компонентов из 15408-2);
Ь) цель безопасности для ОО может быть выражена в ФТБ на основе компонен­
тов из ИСО/МЭК 15408-2 и/или ИСО/МЭК 15408-3, но только с большими трудностями
и/или сложностями, и существуют требования третьей стороны, которые нельзя пере­
вести в ТДБ, используя компоненты из ИСО/МЭК 15408-3.
В обоих случаях от разработчика ПЗ/ЗБ требуется определить новые компонен­
ты, называемые расширенными компонентами. Точно определенный расширенный
56
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
компонент необходим для обеспечения контекста и значения расширенных ФТБ или
ТДБ, основанных на этом компоненте.
После корректного определения новых компонентов разработчик может затем
базировать одно или более ФТБ или ТДБ на этих вновь определенных расширенных
компонентах и использовать их таким же образом, как и другие ФТБ и ТДБ. С этого мо­
мента не существует каких-либо различий между ФТБ и ТДБ, основанными на
ИСО/МЭК 15408, и ФТБ и ТДБ, основанными на расширенных компонентах. С этого
момента и далее нет четкого разделения между ФТБ и ТДБ, выведенных из серии
стандартов ИСО/МЭК 15408, и ФТБ и ТДБ, основанных на расширенных компонентах.
Дополнительные требования к расширенным компонентам изложены в семей­
ствах "Определение расширенных компонентов" (APE_ECD) и "Определение расши­
ренных компонентов" (ASE_ECD) ИСО/МЭК 15408-3. Дополнительная информация по
расширенным компонентам содержится в D.3.6.
8.4.2 Определение расширенных компонентов
Всякий раз, когда автор пакета, ПЗ, ПЗ-модуля или ЗБ определяет расширенный
компонент, это должно быть сделано аналогично существующим компонентам серии
ИСО/МЭК 15408: четким, однозначным и поддающимся оценке (можно систематически
демонстрировать, выполняется ли требование, основанное на этом компоненте, для
ОО). Расширенные компоненты должны использовать маркировку, способ выражения и
уровень детализации, аналогичные существующим компонентам серии ИСО/МЭК
15408.
Разработчик также должен убедиться, что все применимые зависимости расши­
ренного компонента включены в определение этого расширенного компонента.
Примерами возможных зависимостей являются:
а) если расширенный компонент относится к аудиту, возможно, потребуется
включение зависимостей от компонентов класса FAU: Аудит безопасности;
Ь) если расширенный компонент изменяет данные или осуществляет доступ к
ним, может потребоваться включить зависимости от компонентов семейства политики
контроля доступа (FDP_ACC);
с) если расширенный компонент использует конкретное описание проекта, может
потребоваться включение зависимостей от семейства ADV: Разработка.
В случае с расширенным функциональным компонентом разработчик также дол­
жен включить любую применимую информацию об аудите и связанных с ним операци­
ях в определение компонента, аналогично существующим компонентам ИСО/МЭК
57
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
15408-2. В случае с расширенным компонентом доверия разработчик может также
представить подходящую методологию оценивания компонента, аналогичную методу,
представленному в стандарте ИСО/МЭК 18045.
Расширенные компоненты могут быть размещены в существующих семействах,
и в этом случае разработчик должен показать, как эти семейства изменяются. Если они
не вписываются в существующую семейство, они должны быть размещены в новое
семейство. Новые семейства должны быть определены аналогично тем, которые при­
ведены в стандартах ИСО/МЭК 15408-2 или ИСО/МЭК 15408-3.
Новые семейства могут быть помещены в существующие классы, и в этом слу­
чае разработчик должен показать, как меняются эти классы. Если они не вписываются
в существующий класс, они должны быть помещены в новый класс. Новые классы
должны быть определены аналогично тем,
которые определены в стандартах
ИСО/МЭК 15408-2 или ИСО/МЭК 15408-3.
9 Пакеты
9.1 Общие положения
Пакет - это именованный набор требований безопасности.
Пакет может быть определен любой стороной и предназначен для многократного
использования. Для этой цели он должен включать требования, которые в сочетании
являются полезными и эффективными.
Если два или более пакетов связаны друг с другом, они могут быть представле­
ны как часть семейства пакетов, см. А. 2.
Пакеты могут быть утверждены ПЗ, ПЗ-модулями, ПЗ-конфигурациями и ЗБ и
использоваться для создания более крупных пакетов. Разработчики не должны пере­
именовывать утвержденные или использованные пакеты.
Пакеты могут использоваться при создании более крупных пакетов, ПЗ и ЗБ. В
настоящее время не существует критериев оценки пакетов, поэтому любой набор ФТБ
или ТДБ может быть пакетом.
Примерами пакетов доверия являются оценочные уровни доверия (СУД), опре­
деленные в ИСО/МЭК 15408-3.
Примечания
1 Хотя в серии ИСО/МЭК 15408 не приведены отдельные критерии оценки пакетов, поскольку та­
кие пакеты включены в ПЗ, ПЗ-модуль или ЗБ, они будут оцениваться с использованием критериев АРЕ,
АСЕ или ASE.
58
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
2 ИСО/МЭК 15408-5 предоставляет часто используемые пакеты, такие как оценочные уровни до­
верия (ОУД), которые были предварительно определены и могут использоваться разработчиками ПЗ,
ПЗ-модулей, ПЗ-конфигураций или ЗБ.
3 Функциональные пакеты не могут быть утверждены непосредственно ПЗ-конфигурацией; они
должны быть частью компонента ПЗ-конфигурации.
Дополнительная информация о пакетах приведена в Приложении А.
9
.2 Типы пакетов
9.2.1 Общие положения
Пакеты делятся на:
- функциональные пакеты, включающие функциональные компоненты или тре­
бования, но не компоненты или требования доверия;
- пакеты доверия, включающие компоненты или требования доверия, но не
функциональные компоненты или требования.
Смешанные пакеты, включающие как ФТБ, так и ТДБ, недопустимы.
Все пакеты должны включать:
а) идентификацию пакета с указанием уникального имени, краткого имени, вер­
сии, даты, спонсора и соответствующих частей редакции серии ИСО/МЭК 15408;
Ь)
тип пакета, будь это пакет доверия или функциональный пакет;
с)
краткое содержание с его описанием;
d) примечания о применении, описывающие дополнительную информацию в от­
ношении пакета;
е) определение метода(ов) оценки и/или видов деятельности, если такие мето-
ды/виды деятельности оценки из стандарта ИСО/МЭК 18045 были указаны;
f)
один или несколько компонентов или требований безопасности;
д) если были указаны расширенные компоненты, то пакет включает в себя их
определение;
h) обоснование компонента, в котором содержится обоснование выбора функци­
ональных компонентов/требований или компонентов/требований доверия, включенных
в пакет.
9.2.2 Пакеты доверия
Пакет доверия содержит набор компонентов или требований доверия, которые
могут быть взяты из стандарта ИСО/МЭК 15408-3, могут быть расширенными компо­
нентами обеспечения или могут представлять собой некоторую комбинацию того и дру­
гого.
59
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Пакет доверия не должен включать в себя ПБОр или цели безопасности, а также
какие-либо функциональные компоненты или требования безопасности.
Пакеты доверия могут использоваться в рамках ПЗ, ПЗ - модулей, ПЗ - конфигу­
раций и ЗБ. Набор предопределенных иерархических пакетов доверия приведен в
стандарте ИСО/МЭК 15408-5.
Оценочные уровни обеспечения оценки (ОУД), определенные в стандарте
ИСО/МЭК 15408-5, состоят из ТДБ, взятых из стандарта ИСО/МЭК 15408-3. ОУД - это
заранее определенные пакеты доверия к безопасности.
9.2.3 Функциональные пакеты
Функциональный пакет содержит набор функциональных компонентов или тре­
бований, которые могут быть взяты из стандарта ИСО/МЭК 15408-2, могут быть рас­
ширенными функциональными компонентами или требованиями, или некоторой ком­
бинацией того и другого.
Функциональный пакет может включать в себя ПБОр и цели безопасности, взя­
тые из этого ОПБ. Если пакет содержит определение ПБОр, то должны быть указаны
цели безопасности функционального пакета. Цели включают цели безопасности для
ОО (они опущены, если используется Прямое обоснование), цели безопасности для
среды функционирования и обоснование целей безопасности.
Функциональные пакеты могут использоваться в ПЗ, ПЗ-модулях и ЗБ в качестве
средства структурирования функций безопасности в строительные блоки.
Функциональные пакеты могут иметь зависимости от других функциональных па­
кетов. Такие зависимости должны быть задокументированы в функциональном пакете,
а также могут быть задокументированы в ПЗ, ПЗ-модуле или ЗБ.
Функциональный пакет содержит набор функциональных компонентов или тре­
бований, которые могут быть взяты из стандарта ИСО/МЭК 15408-2, или которые могут
быть расширенными функциональными компонентами или требованиями, или некото­
рой комбинацией того и другого.
Функциональный пакет может включать в себя ПБОр и цели безопасности, выте­
кающие из этого ПБОр. Если пакет определяет ПБОр, то должны быть указаны цели
безопасности функционального пакета. Цели включают цели безопасности для ОО
(они опущены, если используется Прямое обоснование), цели безопасности для среды
функционирования и обоснование целей безопасности.
Функциональные пакеты могут использоваться в ПЗ, ПЗ-модулях и ЗБ в качестве
средства структурирования функций безопасности в строительные блоки.
60
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Функциональные пакеты могут иметь зависимости от других функциональных па­
кетов. Такие зависимости должны быть задокументированы в функциональном пакете,
а также могут быть задокументированы в ПЗ, ПЗ-модуле или ЗБ.
ПЗ определяет и включает функциональный пакет А; пакет А не имеет зависи­
мостей. Функциональные пакеты В, С и D определены в другом месте. Пакет D не име­
ет зависимостей, но пакет С зависит от пакета В. Затем ЗБ может заявлять о соответ­
ствии следующим комбинациям ПЗ и пакетов:
- ЗБ заявляет о соответствии ПЗ (который включает функциональный пакет А);
- ЗБ заявляет о соответствии ПЗ и функциональному пакету В;
- ЗБ заявляет о соответствии ПЗ и функциональным пакетам В и С;
- ЗБ заявляет о соответствии ПЗ и функциональному пакету D;
- ЗБ заявляет о соответствии ПЗ и функциональным пакетам В, С и D. Не разре­
шено следующее:
- ЗБ заявляет о соответствии ПЗ и функциональному пакету С (это не допускает­
ся, поскольку пакет С зависит от пакета В, поэтому он не может быть заявлен незави­
симо).
9.3 Зависимости пакетов
Пакет может не удовлетворять всем зависимостям содержащихся в нем компо­
нентов.
Однако
зависимости
должны
соответствовать
ПЗ,
ПЗ-модулю,
ПЗ-
конфигурации или ЗБ, которые включает пакет. Это означает, что автор несет ответ­
ственность за то, чтобы либо обеспечить соблюдение всех зависимостей, либо вклю­
чить обоснование, объясняющее, почему эти зависимости не соблюдаются. Это объ­
ясняется в разделе 8.3.
9.4 Метод(ы) оценки и виды деятельности
Пакеты могут включать методы/мероприятия оценки, которые были получены из
стандарта ИСО/МЭК 18045. Если для оценки упаковки должны использоваться методы
оценки/оценочные мероприятия, основанные на стандарте ИСО/МЭК 18045, то они
должны быть указаны в соответствующем разделе требований безопасности путем
включения заявления в следующей форме:
«Для этого пакета требуется применения методов оценки/оценочных действий,
определенных в <ссылке(ах)>».
В этом заявлении <ссылка> заменяется идентификацией местоположения соот­
ветствующих методов оценки и действий по оценке. Эта ссылка может относиться к до­
кументу, содержащему пакет, или к одному или нескольким отдельным документам.
61
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Примечание - ИСО/МЭК 15408-4 обеспечивает основу для выполнения таких выводов.
10 Профили защиты
10.1 Общие положения
ПЗ предназначен для описания общего типа ОО. Следовательно, ПЗ можно ис­
пользовать:
- в качестве шаблона ЗБ для любых ОО, соответствующих типу ОО ПЗ;
- в качестве шаблона для других ПЗ с целью дальнейшего уточнения типа ОО;
- в качестве основы для ПЗ-модуля, в этом контексте он известен как базовый
ПЗ. Подробное описание ПЗ приведено в Приложении В.
Примечание - ЗБ содержит описание требований к конкретному ОО и обычно спонсиру­
ется разработчиком этого ОО.
10.2 Введение в ПЗ
Введение в ПЗ должно включать ссылочный идентификатор для ПЗ.
Примечание - Ссылочный идентификатор для ПЗ должен быть уникальным в каталоге.
Введение в ПЗ должно включать обзор ПЗ, включая описание типа ОО.
Типом ОО может быть «Межсетевой экран». Усовершенствованным типом ОО
может быть «межсетевые экраны с проверкой состояния». Конкретным ОО, связанным
с этим типом ОО, может быть «Межсетевой экран MinuteGap v18.5».
ПЗ содержит описание общих требований к типам ОО и поэтому обычно иниции­
руется:
- сообществом технических пользователей, стремящихся прийти к консенсусу по
требованиям для данного типа ОО;
- разработчик ОО или группа разработчиков аналогичных ОО, желающих устано­
вить минимальные базовые показатели для этого типа ОО;
- орган власти или крупная корпорация, определяющая свои требования без­
опасности как часть процесса закупки.
10.3 Заявления и утверждения о соответствии
В этом подразделе использование курсивного текста означает буквальный текст,
который должен появиться в тексте ПЗ. Заявления о соответствии ПЗ:
а) должны указывать издание соответствующих частей серии ИСО/МЭК 15408, о
соответствии которым заявляет ПЗ;
Ь)
должны описывать соответствие ИСО/МЭК 15408-2 или как:
«Соответствующее ИСО/МЭК 15408-2»;
62
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
ПЗ соответствует ИСО/МЭК 15408-2, если все ФТБ в этом ПЗ основаны только
на функциональных компонентах в ИСО/МЭК 15408-2; или
«ИСО/МЭК 15408-2 расширенное».
ПЗ является расширенным в 15408-2, если хотя бы одно ФТБ в этом ПЗ не осно­
вано на функциональных компонентах в ИСО/МЭК 15408-2.
с)
должен описывать соответствие ИСО/МЭК 15408-3 либо как;
«Соответствующее ИСО/МЭК 15408-3»;
А ПЗ является соответствующим ИСО/МЭК 15408-3, если все ТДБ в этом ПЗ ос­
нованы только на компонентах доверия ПЗ в ИСО/МЭК 15408-3; либо
«ИСО/МЭК 15408-3 расширенное».
ПЗ является расширенным в ИСО/МЭК 15408-3, если хотя бы одно ТДБ не осно­
вано на компонентах доверия в ИСО/МЭК 15408-3;
с) может также включать заявление о соответствии в отношении других ПЗ:
«Соответствующее ПЗ»;
ПЗ является соответствующим ПЗ, когда оно соответствует другому (другим)
конкретному(конкретным) ПЗ может включать заявление о соответствии пакету;
В ПЗ может быть заявлено более одного пакета.
Если сделано заявление в отношении пакета, оно должно состоять из одного из
следующих утверждений для заявления по каждому пакету:
«Соответствующее Пакету»;
ПЗ является соответствующим пакету, если:
- для функциональных пакетов все составные части (ПБОр, цели безопасности и
ФТБ) функционального пакета присутствуют в соответствующих частях ПЗ без измене­
ний;
-
для пакетов доверия ТДБ этого ПЗ идентичны ТДБ в пакете доверия;
- ПЗ, который ограничивает выбор некоторых ФТБ в пакете, может по-прежнему
утверждать, что он соответствует пакету;
«Увеличенный пакет»;
ПЗ заявляет об увеличении пакета, если:
- для функциональных пакетов все составные части (ПБОр, цели безопасности и
ФТБ) этого ПЗ содержат все составные части, указанные в функциональном пакете, но
должны иметь по крайней мере одно дополнительное ФТБ или одно ФТБ, которое
иерархически выше, чем ФТБ в функциональном пакете;
63
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
- для пакетов доверия этого ПЗ содержат все ТДБ в пакете доверия, но имеют по
крайней мере одно дополнительное ТДБ или одно ТДБ, которое иерархически выше,
чем ТДБ в пакете доверия.
«Адаптированный Пакет».
ПЗ заявляет об адаптации пакета, если:
- для функциональных пакетов все составные части (ПБОр, цели безопасности и
ФТБ) этого ПЗ содержат все составные части, указанные в функциональном пакете, но
должны иметь дополнительные элементы выбора для ФТБ с существующими выбор­
ками в пакете и, необязательно, по крайней мере, одно дополнительное ФТБ и/или од­
но ФТБ, которое иерархически выше, чем ФТБ в функциональном пакете;
-
пакеты доверия и ЗБ не должны заявлять (или выполнять) адаптацию.
В ПЗ могут быть заявлены несколько пакетов.
Если ПЗ заявляют о строгом или доказуемом соответствии ПЗ они также не
должны заявлять о соответствии пакетам, заявленным в ПЗ, о соответствии которым
они заявляют, если только ПЗ не дополняет пакет. ПЗ заявляет, что <пакет> увеличен
только в том случае, если ПЗ увеличивает пакеты сверх того, что заявлено ПЗ, о соот­
ветствии которому он заявляет.
Примечание - ПЗне могут заявлять о точном соответствии ПЗ.
f) ПЗ должны содержать обоснование заявления о соответствии;
В обосновании заявления о соответствии содержится описание причин и логиче­
ская основа для выбора разработчиками заявлений и утверждения о соответствии.
д) ПЗ должны предоставить утверждение о соответствии.
В утверждении о соответствии должно быть описание способа, посредством ко­
торого другие ПЗ или ЗБ должны соответствовать данному ПЗ. Заявление о соответ­
ствии должно быть одним из следующего:
«Точное соответствие»;
Если ПЗ заявляет о необходимости точного соответствия, ЗБ должно точно со­
ответствовать ПЗ. То есть соответствующее ЗБ должно содержать ПБОр и цели, иден­
тичные ПЗ, и тот же набор ФТБ ПЗ со всеми разрешенными назначениями и выборами;
«Строгое соответствие»;
Если в ПЗ указано, что требуется строгое соответствие, ПЗ/ЗБ должны строго
соответствовать ПЗ. То есть соответствующие ПЗ/ЗБ должны содержать надмножество
ПБОр ПЗ, целей и ФТБ, где новые допущения (если таковые имеются) не ослабляют
64
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
ПБОр ПЗ, и все ФТБ для всех ПЗ имеют свои назначения и выбор без изменений или
там, где это подходит, разрешен;
«Доказуемое соответствие».
Если ПЗ заявляет, что требуется доказуемое соответствие, ПЗ/ЗБ должны соот­
ветствовать ПЗ строгим или доказуемым образом. То есть соответствующие ПЗ/ЗБ
должны содержать ПБОр, набор целей и набор ФТБ, которые эквивалентны расширен­
ному набору ПБОр ПЗ, целей и ФТБ, где новые допущения (если таковые имеются) не
ослабляют ПБОр ПЗ, и где набор соответствующих ПЗ/ЗБ ФТБ подразумевает ФТБ ПЗ.
Строгое соответствие позволяет соответствующему ПЗ/ЗБ не добавлять какие-
либо элементы в ПБОр ПЗ, набор целей и ФТБ, т.е. расширенный набор, определен­
ный в ПЗ/ЗБ, может быть идентичен ПЗ, со всеми разрешенными ФТБ;
Доказуемое соответствие позволяет соответствующему ПЗ/ЗБ использовать
разные, но эквивалентные утверждения, а также просто определять расширенный
набор, как в случае строгого соответствия, без изменения утверждений, приведенных в
ПЗ.
Примечания
1 Другими словами, ПЗ/ЗБ разрешается демонстрировать соответствие ПЗ только в том случае,
если ПЗ явно позволяет это.
2 ПЗ-модули и ПЗ-конфигурации не могут претендовать на соответствие ПЗ. Для получения до­
полнительной информации см. подразделы 11.2 и 11.3.
Утверждение о соответствии может также включать ссылку на любые методы/действия оценки, которые были взяты из ИСО/МЭК 18045. Если методы оцен-
ки/оценочные действия, которые были получены из ИСО/МЭК 18045, должны исполь­
зоваться для оценки ПЗ, то они должны быть идентифицированы с соответствующим
разделом требований безопасности, включив заявление в следующей форме:
«Этот ПЗ требует использования методов оценки/оценочных действий, опреде­
ленных в <ссылке (ах)>».
В этом утверждении <ссылка> заменяется указанием местоположения соответ­
ствующих методов оценки и действий по оценке. Эта ссылка может относиться к доку­
менту, содержащему ПЗ, или к одному или нескольким отдельным документам.
Примечание - ПЗ/ЗБ либо соответствует ПЗ, либо нет. Серия ИСО/МЭК 15408 не при­
знает «частичное» соответствие. Следовательно, разработчик ПЗ несет ответственность за обеспечение
того, чтобы ПЗ не был чрезмерно затруднительным, запрещая разработчикам ПЗ/ЗБ заявлять о соответ­
ствии ПЗ. Дополнительную информацию о заявлениях о соответствии и заявлениях для ПЗ см. В При­
ложении В.
65
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
10.4
Требования доверия к безопасности
ПЗ, соответствующий ИСО/МЭК ИС 15408-3 (возможно, расширенный), должен
определять набор ТДБ, применимых ко всему ОО.
ПЗ может определять отличительное имя для набора применимых ТДБ. Однако,
если набор ТДБ представляет собой (расширенный) предопределенный ОУД (ОУД1 ОУД7) или (расширенный) пакет доверия, определенный в применяемой внешней
ссылке, то должно использоваться то же имя.
Примечание - Предварительно определенные ОУД приведены в ИСО/МЭК 15408-5.
10.5 Дополнительные требования, общие для строгого и доказуемого соот­
ветствия
10.5.1 Заявления и утверждения о соответствии
Если ПЗ/ЗБ заявляет о строгом или демонстрируемом соответствии нескольким
ПЗ, он должен соответствовать каждому ПЗ способом, указанным в этом ПЗ; то есть
либо строго, либо доказуемо. Это означает, что ПЗ/ЗБ может строго соответствовать
одним ПЗ и доказуемо другим ПЗ.
ПЗ/ЗБ соответствует определенному ПЗ, если данные ПЗ/ЗБ эквивалентны или
более ограничительны, чем этот ПЗ, то есть, если:
- все ОО, которые соответствуют ПЗ/ЗБ, также соответствуют ПЗ; а также
- все среды функционирования, соответствующие ПЗ, также соответствуют
ПЗ/ЗБ.
Другими словами, ПЗ/ЗБ должен предъявлять такие же или больше требований к
ОО и такие же или меньшие условия к среде функционирования ОО.
Это общее утверждение применимо к различным конфигурациям ПЗ/ЗБ, а имен­
но к определению проблемы безопасности, целям безопасности для ОО, целям без­
опасности для среды, а также функциональным требованиям безопасности и требова­
ниям доверия к безопасности.
10.5.2 Определение проблемы безопасности
Обоснование соответствия в ПЗ/ЗБ должно демонстрировать, что ПБОр в ПЗ/ЗБ
эквивалентна или более ограничительна, чем ПБОр в ПЗ. Это означает, что:
- все ОО, которые соответствуют ПБОр в ПЗ/ЗБ, также соответствуют ПБОр в
ПЗ;
- все среды функционирования, которые соответствуют ПБОр в ПЗ, также соот­
ветствуют ПБОр в ПЗ/ЗБ.
10.5.3 Цели безопасности
66
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Обоснование соответствия в ПЗ/ЗБ должно продемонстрировать, что цели без­
опасности в ПЗ/ЗБ эквивалентны или содержат больше ограничений, чем цели без­
опасности в ПЗ. Это означает, что:
- ОО, которые соответствуют целям безопасности для ОО в ПЗ/ЗБ, также соот­
ветствуют целям безопасности для ОО в ПЗ;
- среды функционирования, которые соответствуют целям безопасности для
среды функционирования в ПЗ, также соответствуют целям безопасности для среды
функционирования в ПЗ/ЗБ. Обоснование соответствия в ПЗ/ЗБ должно продемон­
стрировать, что ПБОр в ПЗ/ЗБ эквивалентна или более ограничительна, чем ПБОр в
ПЗ. Это означает, что:
-
все ОО, которые соответствуют ОПБ в ПЗ/ЗБ, также соответствуют ПБОр в ПЗ;
- все рабочие среды, которые соответствуют ПБОр в ПЗ, также соответствуют
ПБОр в ПЗ/ЗБ.
10.5.4 Цели безопасности
- среды функционирования, которые соответствуют целям безопасности для
среды функционирования в ПЗ, также соответствуют целям безопасности для среды
функционирования в ПЗ/ЗБ.
10.6 Дополнительные требования, специфические для строгого соответ­
ствия
10.6.1 Требования к определению проблемы безопасности
ПЗ/ЗБ должны содержать ПБОр ПЗ и может обозначать дополнительные угрозы
и ПБОр; он должен содержать все допущения, определенные в ПЗ, с двумя возможны­
ми исключениями, как объясняется в следующих двух пунктах;
- допущение (или часть предположения), указанное в ПЗ, может быть исключено
из ПЗ/ЗБ, если все цели безопасности для среды функционирования, определенные в
ПЗ, касающимся этого предположения (или этой части предположения), заменены це­
лями безопасности для ОО в ПЗ/ЗБ;
- новое предположение может быть добавлено в ПЗ/ЗБ к набору предположений,
определенных в ПЗ, если это новое предположение не уменьшает угрозу (или часть
угрозы), которая должна быть учтена целями безопасности для ОО в ПЗ, и если это
предположение не соответствует ПБОр (или части ПБОр), которая должна быть учтена
целями безопасности для ОО в ПЗ;
10.6.2 Требования к целям безопасности
ПЗ/ЗБ:
67
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
- должен содержать все цели безопасности для ОО ПЗ, но может определять до­
полнительные цели безопасности для ОО;
- должен содержать все цели безопасности для среды функционирования, как
определено в ПЗ, за двумя исключениями, как объяснено в следующих двух пунктах
списка;
- может указывать, что определенные цели безопасности для среды функциони­
рования в ПЗ являются целями безопасности для ОО в ПЗ/ЗБ. Это называется пере­
назначением цели безопасности. Если цель безопасности переназначена целям без­
опасности для ОО, обоснование целей безопасности должно четко указывать, какое
допущение/ПБОр или часть допущения/ПБОр больше не требуется;
- может определять дополнительные цели безопасности для среды функциони­
рования, если эти новые цели не уменьшают угрозу (или часть угрозы), которая должна
быть устранена целями безопасности ОО в ПЗ, и если эти новые цели не соответству­
ют ПБОр (или части ПБОр), предназначенной для решения целями безопасности ОО в
ПЗ.
10.6.3 Требования к требованиям безопасности
ПЗ/ЗБ:
- должен содержать все ФТБ и ТДБ в ПЗ;
- может требовать дополнительных или более сильных по иерархии ФТБ и ТДБ.
Завершение операций в должно быть внутренне согласовано с завершением операций
в ПЗ; либо в ПЗ/ЗБ будет использоваться то же завершение, что и в ПЗ, либо такое, ко­
торое делает требование более строгим.
Примечание - Применяются правила уточнения.
10.7 Дополнительные требования, специфические для доказуемого соот­
ветствия
Доказуемое соответствие позволяет разработчику ПЗ описать общую проблему
безопасности, которую необходимо решить, и предоставить общие рекомендации по
требованиям, необходимые для ее решения, зная, что, вероятно, существует более
одного способа определения решения.
ПЗ/ЗБ должен содержать обоснование того, почему ПЗ/ЗБ считается «эквива­
лентным или более ограничительным», чем ПЗ.
10.8 Дополнительные требования, специфические для точного соответ­
ствия
10.8.1 Общие положения
68
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Точное соответствие используется, когда разработчику ПЗ необходимо прокон­
тролировать, какое ЗБ может заявить о соответствии в отношении написанного им ПЗ.
Оно используется в случаях, когда разработчик ПЗ требует, чтобы ЗБ, заявляющие о
соответствии ПЗ, не включали дополнительных, целей безопасности или требований,
которые не были учтены разработчиком ПЗ.
В ПЗ, который требует точного соответствия в своем утверждении о соответ­
ствии, могут быть определены необязательные ФТБ и любые элементы ПБОр, которые
требуются для поддержки этих ФТБ. Затем ЗБ (или ПЗ-модуль) может включать эти
необязательные ФТБ (и любые требуемые элементы ПБОр) в свой набор требований,
сохраняя при этом свое точное заявление о точном соответствии.
ПЗ с типом точного соответствия не должен заявлять о соответствии каким-либо
другим ПЗ любого типа соответствия. ПЗ с типом точного соответствия не должен
включаться в ПЗ-конфигурацию, которая также включает ПЗ или ПЗ-модули со строгим
или доказуемым типом соответствия.
Примечание - Это связано с тем, что невозможно заявить о соответствии как строгому/
доказуемому соответствию ПЗ, так и точному соответствию ПЗ, поскольку это означало бы добавление
требований или элементов ПБОр к точному соответствию ПЗ, что явно запрещает эту операцию.
В «простом» случае, когда ЗБ заявляет о точном соответствии ПЗ, нет двусмыс­
ленности, соответствует ли ЗБ в точности или нет, поскольку соответствие между
ПБОр, целями безопасности, ФТБ и ТДБ демонстрируется во время оценки без необ­
ходимости искать входные данные разработчика ПЗ.
Однако допускаются и другие случаи, когда несколько наборов элементов ПБОр,
целей безопасности и ФТБ могут быть объединены; в этих случаях требуются меха­
низмы, которые сохраняют способность разработчиков ПЗ с точным соответствием
управлять заявлением о соответствии с их ПЗ. Эти механизмы описаны в следующих
подразделах.
Сложный случай может быть, если ПЗ-модуль стремится использовать ПЗ в ка­
честве своего базового ПЗ, или если ЗБ заявляет о соответствии двум ПЗ.
Примечание - Если ПЗ требует точного соответствия, то в соответствующем ЗБ разре­
шены только те ФТБ и ТДБ, указанные этим ПЗ. Эти требования безопасности связаны с ПБОр и целями
безопасности, указанными в ПЗ, которые также включены в соответствующие ЗБ. ФТБ в точном соответ­
ствии ПЗ можно повторять и уточнять (как указано в ИСО/МЭК 18045 для ASE_CCL.1-12).
10.8.2 Заявления и утверждения о соответствии
Если ПЗ требует точного соответствия в своем заявлении о соответствии, то
69
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
а) ПЗ должен включать заявление о разрешении, в котором указывается, какие
другие ПЗ и ПЗ-модули разрешено включать в заявление о соответствии вместе с ПЗ;
Ь) все дополнительные ПЗ, точное соответствие которым ЗБ может требовать,
также должны иметь требование точного соответствия; а также
с) все дополнительные ПЗ, соответствие которым заявлено ЗБ, должны иденти­
фицировать ПЗ в своих соответствующих утверждениях, разрешенных с помощью;
d) все дополнительные ПЗ-модули, заявленные через ПЗ-конфигурацию, должны
идентифицировать ПЗ в своих соответствующих разрешенных утверждениях.
Если ПЗ требует точного соответствия в своем утверждении о соответствии, то:
а) ПЗ должен включать утверждение о разрешении, в котором указывается, ка­
кие другие ПЗ и ПЗ-модули разрешено включать в заявление о соответствии наряду с
ПЗ;
Ь) все дополнительные ПЗ, точное соответствие которым ЗБ может требовать,
также должны иметь требование точного соответствия; а также
с) все дополнительные ПЗ, соответствие которым заявлено ЗБ, должны иденти­
фицировать ПЗ в своих соответствующих разрешенных утверждениях;
d) все дополнительные ПЗ-модули, заявленные через ПЗ-конфигурацию, должны
идентифицировать ПЗ в своих соответствующих разрешенных утверждениях.
Примечание - ПЗ-модулю не надо идентифицировать свою собственные базовые ПЗ/ПЗ-
модули в утверждении о соответствии, однако базовый ПЗ-модуль должен быть идентифицирован во
введении к ПЗ-модулю.
10.8.3 Применение ПЗ
Если ПЗ/ЗБ заявляет о своем соответствии одному или нескольким ПЗ и, воз­
можно, одному или нескольким пакетам, оценка этого ПЗ/ЗБ будет включать демон­
страцию того, что ПЗ/ЗБ фактически соответствует заявленным ПЗ и/или пакетам. По­
дробная информация об этом определении соответствия приведена в Приложениях А
и В.
Это позволяет выполнить следующий процесс:
а) организация, стремящаяся приобрести определенный тип продукта безопас­
ности ИТ, формулирует свои потребности в безопасности в ПЗ, затем оценивает этот
ПЗ и публикует его;
Ь) разработчик берет этот ПЗ, разрабатывает ЗБ, в котором заявляется о соот­
ветствии ПЗ, и оценивает это ЗБ;
70
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
с) затем разработчик создает ОО (или использует существующий) и оценивает
его в сравнении с ЗБ.
В результате оцениваемый ОО соответствует требованиям организации, опре­
деленным в ПЗ, и поэтому организация может быть уверена, что ОО удовлетворяет ее
потребностям в безопасности. Аналогичные рассуждения относятся к пакетам.
10.9 Заявления и утверждения о соответствии в случае с несколькими ПЗ
10.9.1 Общие положения
Серия ИСО/МЭК 15408 позволяет как ЗБ, так и ПЗ заявлять о соответствии не­
скольким ПЗ. Случай, когда ЗБ заявляет о соответствии нескольким ПЗ, рассматрива­
ется в 11.3.3. В 10.10 рассматривается случай, когда ПЗ заявляет о соответствии не­
скольким ПЗ.
10.9.2 Если указано строгое или доказуемое соответствие
Разрешение ПЗ заявлять о соответствии нескольким ПЗ позволяет строить це­
почки ПЗ, где каждый ПЗ в цепочке основан на предыдущем ПЗ).
ПЗ для интегральной схемы и для ОС смарт-карты могут использоваться для со­
здания смарт-карты ПЗ (ИС и ОС), которая заявляет о соответствии обоим. В свою
очередь, этот ПЗ смарт-карты может быть использован для разработки конкретных ПЗ
для различных вариантов использования, например, карты тахографа, платежной кар­
ты, электронного паспорта и т.д. Затем разработчик может создать ЗБ, соответствую­
щее любому из этих ПЗ.
10.9.3 Если указано точное соответствие
ПЗ не должен заявлять о точном соответствии другому ПЗ или комбинации ПЗ.
Примечание - В случаях, когда требуется такая комбинация функциональных возможно­
стей, это может быть достигнуто путем создания ПЗ-конфигурации, состоящей из ПЗ, соответствие кото­
рым желательно заявить.
11 Модульная конфигурация требований
11.1 Общие положения
Чтобы получить модульное описание функций безопасности ОО, ЗБ могут заяв­
лять о соответствии ПЗ-конфигурации вместо ПЗ. Такие ПЗ-конфигурации состоят из
набора ПЗ и ПЗ-модулей, которые содержат базу ПЗ-модулей.
ПЗ-конфигурации могут быть сконструированы для размещения оценок с единым
или многоуровневым доверием. При оценке с единым доверием единый набор требо­
ваний доверия ПЗ применяется ко всем компонентам ПЗ-конфигурации. При много71
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
уровневой оценке доверия существует единый глобальный набор требований доверия,
который применяется ко всем компонентам ПЗ-конфигурации, но, кроме того, каждый
компонент (ПЗ или ПЗ-модуль) имеет свой собственный набор требований доверия,
которым он соответствует. В следующих разделах представлены подробности, связан­
ные с содержанием этих двух методов оценки; Фактические особенности оценки с ис­
пользованием этих методов рассматриваются в разделе 13.
11.2 ПЗ-модули
11.2.1 Общие положения
ПЗ-модуль - это внутренне согласованный набор элементов ПБОр, целей без­
опасности для ОО и среды функционирования, а также функциональных требований
безопасности, определенных в контексте одного или нескольких ПЗ и, возможно, дру­
гих ПЗ-модулей.
В отличие от ПЗ, ПЗ-модули адресуются к тем функциям безопасности данного
типа ОО, которые не могут требоваться единообразно для всех продуктов этого типа
ОО.
В
отличие
от
ПЗ,
ПЗ-модули
должны
использоваться
только
в
ПЗ-
конфигурациях. ПЗ/ЗБ не может напрямую заявлять о соответствии ПЗ-модулю.
Примерами функций, которые не могут требоваться единообразно для всех про­
дуктов в рамках определенного типа ОО, является аутентификация с использованием
биометрии, функции безопасности Bluetooth и клиенты беспроводной локальной сети.
11.2.2 База ПЗ-модуля
Данный ПЗ-модуль определяет одну или несколько баз ПЗ-модулей, состоящих
из набора ПЗ и, возможно, других ПЗ-модулей. Каждый раз, когда данный ПЗ-модуль
используется в ПЗ-конфигурации, требуется одна из его баз ПЗ-модулей. См. Раздел
10 и Приложение В.
11.2.3 Требования для ПЗ-модулей
11.2.3.1 Общие положения
ПЗ-модуль должен идентифицироваться ссылочным идентификатором.
Примечание - Ссылочный идентификатор ПЗ-модуля должен быть уникальным в катало­
ге.
ПЗ-модуль должен определять одну или несколько баз ПЗ-модулей, которые мо­
гут потребоваться для использования с ПЗ-модулем в ПЗ-конфигурации.
ПЗ-модуль должен определять типы ОО относительно каждой из его баз ПЗмодулей.
72
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
ПЗ-модуль может вводить новые элементы ПБОр и цели, а также может уточ­
нять некоторые из элементов ПБОр или целей своих ПЗ-модулей.
ПЗ-модуль должен определять непустой набор ФТБ, которые являются уточне­
нием ФТБ баз ПЗ-модуля или новыми ФТБ.
ЗБ, которое заявляет о соответствии ПЗ-конфигурации, включающей данный ПЗ-
модуль, затем должно включать элементы ПБОр ПЗ-модуля, цели безопасности и ФТБ,
объединенные с теми из базы ПЗ-модуля, которые принадлежат ПЗ-конфигурации.
Примечание - Тип ОО, определенный в ПЗ-модуле, может дополнять тип ОО, опреде­
ленный в каждой из его баз ПЗ-модулей.
ПЗ-модуль должен быть идентифицирован ссылочным идентификатором.
Примечание - Справочный идентификатор ПЗ-модуля должен быть уникальным в ката­
логе.
ПЗ-модуль должен определять дону или несколько ПЗ-модульных баз, которые
могут потребоваться для использования с ПЗ-модулем в ПЗ-конфигурации.
ПЗ-модуль должен определять типы ОО относительно каждой из его баз ПЗмодуля.
ПЗ-модуль может вводить новые ОПБ-элементы и цели, а также может уточнять
некоторые из ОПБ-элементов или целей своего ПЗ-А. ПЗ-модуль должен обеспечивать
согласованное обоснование, обеспечивающее, что объединение элементов, опреде­
ленных в ПЗ-модуле и в каждой базе ПЗ-модуля не приводят к противоречию.
Примечания
1 В ПЗ-модуле с прямым обоснованием цели безопасности для ОО не включены.
2 Оценка одного ПЗ-модуля не имеет смысла. ПЗ-модуль должен оцениваться как часть ПЗ-
конфигурации, по крайней мере, с одной базой ПЗ-модуля.
Дополнительная информация о ПЗ-модулях приведена в С.1.
1 1.2.3.2 Прямое обоснование
ПЗ-модуль может использовать метод прямого обоснования при условии, что его
база(ы) ПЗ-модуля также использует метод прямого обоснования.
1 1.2.3.3 Заявления и утверждения о соответствии
В этом подпункте курсивом указывается буквальный текст, который должен сто­
ять в тексте ПЗ-модуля. Заявления о соответствии ПЗ-модуля:
а) должны указывать редакцию соответствующих частей серии ИСО/МЭК 15408,
о соответствии которым заявляет ПЗ-модуль;
Ь)
должен описывать соответствие ИСО/МЭК 15408-2 как:
- «Соответствующий ИСО/МЭК 15408-2»; или
73
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Примечание - ПЗ-модуль соответствует ИСО/МЭК 15408-2, если все ФТБ в этом ПЗ-
модуле основаны только на функциональных компонентах в ИСО/МЭК 15408-2.
“Расширенный ИСО/МЭК 15408-2”.
Примечание - ПЗ-модуль является расширенным в 15408-2, если хотя бы одно ФТБ в
этом ПЗ-модуле не основано на функциональных компонентах в ИСО/МЭК 15408-2.
с) может включать заявление о соответствии, сделанное в отношении функцио­
нальных пакетов. ПЗ-модуль может заявлять о более одном функциональном пакете;
Примечание - ПЗ-модуль не заявляет о соответствии функциональному пакету, который
уже заявлен одним из ПЗ или ПЗ-модулей в базах ПЗ-модуля. Исключением из этого правила является
ситуация, когда ПЗ-модуль дополняет или адаптирует функциональный пакет в том виде, в каком он
представлен в его базе ПЗ-модуля; в этом случае ПЗ-модуль будет заявлять функциональный пакет как
«Пакет расширенный» или «Пакетный адаптированный» (как соответствующий) в своем заявлении о со­
ответствии своего пакета.
Если заявлено о функциональном пакете, оно должно состоять из одного из сле­
дующих утверждений для каждого пакета:
- «Соответствующий пакету»;
ПЗ-модуль соответствует пакету, если все составные части функционального па­
кета, включая ПБОр, цели безопасности и ФТБ этого функционального пакета, присут­
ствуют в соответствующих частях ПЗ-модуля без изменений.
- «Расширенный пакет»;
ПЗ-модуль заявляет о расширении пакета, если все составные части функцио­
нального пакета, включая ПБОр, цели безопасности и ФТБ, содержащиеся в ПЗмодуле, идентичны указанным в функциональном пакете, но также должны содержать:
по крайней мере, одно ФТБ, которое является дополнительным или иерархически бо­
лее высоким, чем ФТБ в функциональном пакете.
- «Пакет адаптирован».
ПЗ-модуль заявляет об адаптации пакета, если все составные части функцио­
нального пакета, включая ПБОр, цели безопасности и ФТБ, содержащиеся в ПЗмодуле, идентичны указанным в функциональном пакете, но должны иметь дополни­
тельные элементы выбора для ФТБ с существующими вариантами выбора в пакете и,
необязательно, по крайней мере, одно дополнительное ФТБ и/или одно ФТБ, которое
иерархически выше, чем ФТБ в функциональном пакете;
Ь) должны включать заявление о соответствии ИСО/МЭК 15408-3. Заявление о
соответствии ИСО/МЭК 15408-3 должно быть;
- «Соответствующий ИСО/МЭК 15408-3»; или
74
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
ПЗ-модуль соответствует ИСО/МЭК 15408-3, если все ТДБ в этом ПЗ-модуле ос­
нованы только на компонентах доверия из ИСО/МЭК 15408-3.
- «расширенный ИСО/МЭК 15408-3».
ПЗ-модуль является расширенным по ИСО/МЭК 15408-3, если хотя бы одно ТДБ
в этом ПЗ-модуле не основан на компонентах доверия из ИСО/МЭК 15408-3;
- может включать заявление о соответствии, сделанное в отношении пакетов до­
верия.
ПЗ-модуль может заявлять о нескольких пакетах доверия. Допускается дублиро­
вание заявленных пакетов доверия; по конфигурации более высокое ТДБ имеет прио­
ритет над другим и применяется в ПЗ-конфигурации.
В случаях строгого и доказуемого соответствия ПЗ-модуль может заявлять о со­
ответствии более чем одному пакету доверия, например, пакет на основе ALC и пакет
на основе ADV.
Если сделано заявление о соответствии пакету, оно должно состоять из одного
из следующих утверждений для каждого пакета:
- «Соответствующий пакету»;
ПЗ-модуль является соответствующим пакету доверия, если все составные ча­
сти пакета доверия присутствуют в ПЗ-модуле без изменений.
- «Расширенный пакет».
ПЗ-модуль заявляет о расширении пакета доверия, если все составные части
пакета доверия, содержащиеся в ПЗ-модуле, идентичны тем, которые указаны в пакете
доверия, но он также должен содержать по крайней мере одно ТДБ, которое является
дополнительным или иерархически более высоким, чем те ТДБ, содержащиеся в паке­
те;
Заявление о соответствии ПЗ-модуля:
а) должно предоставлять утверждение о соответствии, которое описывает то, как
ЗБ должны соответствовать этому ПЗ-модулю как части ПЗ-конфигурации. Заявление о
соответствии должно быть одним из следующих:
“Точное соответствие”;
ПЗ-модуль требует точного соответствия тогда и только тогда, когда вся его база
(ы) ПЗ-модуля имеют точное соответствие. ЗБ должен точно соответствовать ПЗмодулю как части ПЗ-конфигурации. Кроме того:
75
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
- утверждение о разрешении должно указывать, какие другие ПЗ и ПЗ-модули
(которые не входят в набор баз ПЗ-модулей) разрешено использовать в ПЗконфигурации с этим ПЗ-модулем;
- каждый ПЗ и ПЗ-модуль в базе ПЗ-модуля для определяемого ПЗ-модуля, а
также все дополнительные ПЗ и ПЗ-модули (которых нет в базе ПЗ-модуля), которые
разрешено указывать с помощью ПЗ-модуля в ПЗ-конфигурации, должны идентифици­
ровать определяемый ПЗ-модуль в их соответствующих утверждениях о разрешении.
-
все ссылочные базы ПЗ-модуля также должны требовать точного соответствия
“Строгое соответствие”;
Если ПЗ-модуль заявляет, что требуется строгое соответствие, ЗБ должно стро­
го соответствовать ПЗ-модулю как части ПЗ-конфигурации;
-
«Доказуемое соответствие».
Если ПЗ-модуль заявляет о необходимости доказуемого соответствия, ЗБ долж­
но соответствовать ПЗ-модулю как части ПЗ-конфигурации, строгим или доказуемым
образом. ЗБ может соответствовать ПЗ-модулю как часть ПЗ-конфигурации доказуе­
мым образом, если ПЗ-модуль явно разрешает это.
Примечания
1 ПЗ-модуль может требовать строгого или доказуемого соответствия, хотя не все его базы ПЗмодулей требуют строгого или доказуемого очевидного соответствия. Комбинация доказуемого и строго­
го соответствия подтверждается в оценке ПЗ-конфигурации.
2 Явное заявление о строгом или очевидном соответствии позволяет спонсорам делать наибо­
лее подходящие заявления в каждом ПЗ-модуле, независимо от его базы (баз) ПЗ-модуля.
3
Базы ПЗ-модулей не нужно указывать в утверждении о соответствии ПЗ-модулей.
Ь) может также включать ссылку на любые методы/действия оценки, которые
были взяты из ИСО/МЭК 18045.
Если для оценки ПЗ-модуля должны использоваться методы оценки/оценочные
действия, взятые из ИСО/МЭК 18045, то они должны быть идентифицированы с соот­
ветствующим разделом требований безопасности, включая утверждение в следующей
форме:
«Этот ПЗ-модуль требует использования методов оценки/оценочных действий,
определенных в <ссылка (и)>.»
В этом утверждении <ссылка> заменяется указанием местоположения соответ­
ствующих методов оценки и действий по оценке. Эта ссылка может относиться к доку­
менту, содержащему ПЗ-модуль, или к одному или нескольким отдельным документам.
76
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Для получения дополнительной информации и требований к типам соответствия,
заявлениям и заявлениям для ПЗ-модулей см. Приложение С, которое должно исполь­
зоваться вместе с разделами стандарта.
11.2.3.4 Требования доверия
ПЗ-модуль должен определять набор ТДБ, которые относятся к ФБО, опреде­
ленным в ПЗ-модуле, которые могут быть либо унаследованы от базы (баз) ПЗ-модуля,
либо явно объявлены разработчиков ПЗ-модуля.
ПЗ-модуль может определять отличительное имя для своего набора ТДБ. Одна­
ко, если ПЗ-модуль объявляет (расширенный) предопределенный ОУД (ОУД1-ОУД7)
или (расширенный) пакет доверия, определенный во внешней ссылке, или наследует
набор ТДБ от своей базы (баз) ПЗ-модуля, тогда должно использоваться то же имя.
ПЗ-модуль должен обеспечивать обоснование доверия, которое оправдывает
внутреннюю непротиворечивость его набора ТДБ, а именно:
- согласованность набора ТДБ с моделью угрозы, определенной в ПБОр ПЗмодуля;
- если ПЗ-модуль не наследует свой набор ТДБ от своей ПЗ-модульной базы
(баз), согласованность набора ТДБ со всеми наборами ТДБ, определенными в базе(ах)
ПЗ-модуля, отсутствует.
Примечания
1 Под согласованностью понимается отсутствие противоречий. Примером несоответствия между
ТДБ и ПБОр может быть рассмотрение высококвалифицированных источников угроз вместе с низким
уровнем AVA_VAN, который не может рассматривать эти источники угроз по определению.
2 Обоснование доверия в ПЗ-модуле обеспечивает, что набор ТДБ, определенных в ПЗ-модуле,
не причинит ущерба безопасности, предполагаемой для активов, которые совместно используются ПЗмодулем и его базой (базами) ПЗ-модуля (если общие активы существуют).
3 Обоснование доверия на уровне ПЗ-модуля вносит свой вклад, но его недостаточно для обес­
печения согласованности требований доверия на уровне ПЗ-конфигурации. См. п. 11.3.2.4.
4 Обоснование доверия может зависеть от взаимосвязи набора ТДБ в ПЗ-модуле с заранее
определенными ОУД для демонстрации внутренней согласованности.
1
1.3 ПЗ-конфигурации
11.3.1 Общие положения
ПЗ-конфигурация - это спецификация построения набора требований, о соответ­
ствии которым может быть заявлено.
ПЗ-конфигурация
предназначена
для
описания
общего
типа
ОО.
ПЗ-
конфигурация:
77
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
- может использоваться в качестве шаблона ЗБ для любых ОО, соответствую­
щих типу ОО ПЗ-Конфигурации;
- не может использоваться в качестве шаблона ЗБ для других ПЗ-конфигураций,
ПЗ или ПЗ-модулей.
ПЗ-конфигурация
содержит
набор
ПЗ
и
ПЗ-модулей
(компоненты
ПЗ-
конфигурации) и не может заявлять о соответствии каким-либо функциональным паке­
там, кроме как косвенно через свои ПЗ/ПЗ-модули. ПЗ-конфигурации могут содержать
ТДБ и заявлять о соответствии пакетам доверия.
Выделяются два типа ПЗ-конфигураций, каждый из которых имеет разные тре­
бования к своей конфигурации и применяется в зависимости от потребностей заказчи­
ка. Это:
- ПЗ-конфигурация с единым доверием: здесь описывается тип конфигурации, в
котором ТДБ в наборе, применяемом к компонентам ПЗ-конфигурации, идентичны.
- ПЗ-конфигурация с многоуровневым доверием: описывает тип конфигурации, в
котором ТДБ в компонентах ПЗ-конфигурации не идентичны.
11.3.2 Требования к ПЗ-конфигурациям
11.3.2.1 Общие положения
ПЗ-конфигурация
предназначена
для
описания
общего
типа
ОО.
ПЗ-
конфигурация должна быть обозначена ссылкой.
Примечание - Ссылочный идентификатор для ПЗ-конфигурации в каталоге должен быть
уникальным.
ПЗ-конфигурация
должна
определять
утверждение
компонентов
ПЗ-
конфигурации, перечень, который однозначно идентифицирует все ПЗ-модули и ПЗмодули, составляющие, по ссылке, ПЗ-конфигурацию. ПЗ-конфигурация должна со­
держать один ПЗ и как минимум еще один компонент ПЗ-конфигурации. Он может со­
держать ПЗ-модуль при условии, что одна из баз ПЗ-модуля также включена в ПЗ-
конфигурацию. Она может содержать ПЗ, не связанные с ПЗ-модулем.
ПЗ-конфигурация должна определять тип ОО, к которому она относится.
ПЗ-конфигурация содержит в точности, посредством ссылки, ПБОр, цели без­
опасности, ФТБ и функциональные пакеты, определенные в ее компонентах; специфи­
кация любого Дополнительного элемента должна выполняться в одном из ее компо­
нентов.
78
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
ПЗ-конфигурация должна обеспечивать логическое обоснование, обеспечиваю­
щее, что объединение элементов, определенных в ее компонентах, не приведет к про­
тиворечию.
ПЗ-конфигурация с многоуровневым доверием должна описывать организацию
ФБО с точки зрения под-ФБО, которые определены в ее компонентах, и должна опре­
делять для каждой под-ФБО набор ТДБ, который согласуется с соответствующим ком­
понентом.
Примечание - В случае ПЗ-конфигурации с несколькими уровнями доверия, содержащей
один ПЗ и один ПЗ-модуль с разными наборами ТДБ, организация ФБО следующая: ФБО представляют
собой объединение ТДБ, определенных в ПЗ и в ПЗ-модуле, и имеются две под-ФБО, которые состоят
из ФБО ПЗ и ФБО ПЗ-модуля. Та же самая организация действительна для ПЗ-конфигурации, состоя­
щей из двух ПЗ, которые определяют две под-ФБО.
Под-ФБО, содержащиеся в ПЗ-конфигурации с несколькими уровнями доверия,
могут частично дублироваться. Это не влияет на применимые требования доверия:
каждая под-ФБО должна оцениваться в сравнении с собственным набором ТДБ. Это
означает, что дублируемые части могут оцениваться по многим наборам требований
доверия.
ПЗ-конфигурация:
- может использоваться в контексте подхода прямого обоснования, описанного в
В.5 и С.2.3. В этом случае все компоненты ПЗ-конфигурации также должны использо­
вать подход прямого обоснования;
- не должны содержать никакого дополнительного контента, кроме описанного в
стандарте.
11.3.2.2 Утверждение о компонентах
ПЗ-конфигурация
- должна идентифицировать все компоненты ПЗ-конфигурации в утверждении о
компонентах описании компонентов. В утверждении о компонентах должен быть указан
один ПЗ и как минимум еще один компонент;
Примечание - Описание компонентов дополнительно изложено в С.3.3.
-
не должна заявлять о соответствии другой ПЗ-конфигурации;
Примечание - При желании эффект может быть достигнут путем прямого включения
всех компонентов из обеих ПЗ-конфигураций в одну новую определенную ПЗ-конфигурацию, где можно
проверять и поддерживать точное соответствие.
79
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
- должна включать базы всех ПЗ-модулей, входящих в ПЗ-конфигурацию. Если
ПЗ-модуль определяет альтернативные наборы баз ПЗ-модуля, то в ПЗ-конфигурации
должен использоваться только один из этих наборов;
-
может выбрать больше ПЗ, чем база ПЗ-модулей;
- для ПЗ-конфигураций с одним доверием может идентифицировать под-ФБО,
которые соответствуют каждому компоненту, определенному ПЗ-конфигурацией;
- для ПЗ-конфигураций с несколькими уровнями доверия должна идентифициро­
вать под-ФБО, которое соответствует каждому компоненту, определенному ПЗконфигурацией.
Для ПЗ-конфигурации, которая требует точного соответствия, все компоненты
ПЗ-конфигурации должны указывать друг друга в своих соответствующих разрешенных
утверждениях.
Примечание - Исключением из перечня в разрешенном утверждении является то, что
ПЗ-модуль не должен перечислять какие-либо ПЗ-модули или ПЗ-модули, содержащиеся в его базе ПЗ-
модулей, в своем разрешенном утверждении (поскольку они явно разрешены в силу тот факта, что они
являются базой для ПЗ-модуля).
11.3.2.3 Заявления о соответствии и утверждения о соответствии
В этом подпункте использование курсивного текста означает буквальный текст,
который должен стоять в тексте ПЗ- конфигурации.
В заявлениях о соответствии ПЗ-конфигурации:
а) должны быть указаны редакции соответствующих частей серии ИСО/МЭК
15408, о соответствии которым заявляют компоненты ПЗ-конфигурации.
Ь) должно быть описание соответствия ИСО/МЭК 15408-2 (функциональные тре­
бования безопасности) как:
- «Соответствует ИСО/МЭК 15408-2»; или
ПЗ-конфигурация соответствует ИСО/МЭК 15408-2, если все ПЗ и ПЗ-модули в
ПЗ- конфигурации соответствуют ИСО/МЭК 15408-2.
- «ИСО/МЭК 15408-2 расширенный».
ПЗ-конфигурация является расширенной ИСО/МЭК 15408-2, если хотя бы один
ПЗ или ПЗ-модуль не основан на функциональных компонентах в ИСО/МЭК 15408-2.
с) должно быть описание соответствия ИСО/МЭК 15408-3 (требования доверия к
безопасности) как:
- «Соответствует ИСО/МЭК 15408-3»; или
80
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
ПЗ-конфигурация соответствует ИСО/МЭК 15408-3, если все ТДБ в этой ПЗ-
конфигурации, которые могут быть просто унаследованы от ее компонентов, основаны
только на компонентах доверия в ИСО/МЭК 15408-3; или
- «ИСО/МЭК 15408-2 расширенный».
ПЗ-конфигурация является расширенной ИСО/МЭК 15408-3, если хотя бы одно
ТДБ которое может быть просто унаследовано от ее компонентов, не основано только
на компонентах доверия в ИСО/МЭК 15408-3.
d)
может включать заявление о соответствии пакету доверия;
В ПЗ-конфигурации может быть заявлено несколько пакетов. Если сделано за­
явление о соответствии определенному пакету доверия, оно должно состоять из одно­
го из следующих утверждений для каждого заявления о пакете:
- «Соответствие пакету»;
ПЗ-конфигурация
соответствует
пакету
доверия,
если
ТДБ
этой
ПЗ-
конфигурации, которая может быть унаследована от ее компонентов, идентичны ТДБ в
пакете доверия.
“увеличенный пакет”.
ПЗ-конфигурация заявляет о расширении пакета доверия, если: ТДБ этой ПЗ-
конфигурации, которые могут быть унаследованы от ее компонентов, содержат все
ТДБ в пакете доверия, но имеют, по крайней мере, одно дополнительное ТДБ или одно
ТДБ, которое иерархически выше, чем ТДБ в пакете доверия.
е) не должно быть включено заявление о соответствии функциональному пакету.
Соответствие функциональным пакетам может быть заявлено компонентами ПЗКонфигурации;
f) не должно быть включено заявление о соответствии в отношении других ПЗконфигураций, ПЗ или ПЗ-модулей;
ПЗ-конфигурация должна содержать заявление о соответствии, которое описы­
вает способ, которым ЗБ должны соответствовать этой ПЗ-конфигурации:
а) для ПЗ-конфигурации, в которой все ее ПЗ и ПЗ-модули имеют один и тот же
тип соответствия, в заявлении о соответствии должен быть указан один тип соответ­
ствия, который является одним из:
- «Точное соответствие»;
Если в ПЗ-конфигурации указано, что требуется точное соответствие, ЗБ должно
точно соответствовать ПЗ-конфигурации.
- «Строгое соответствие»;
81
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Если в ПЗ-конфигурации указано, что требуется строгое соответствие, ЗБ долж­
но строго соответствовать ПЗ-конфигурации.
- «Доказуемое соответствие».
для ПЗ-конфигурации, где для ПЗ и ПЗ-модулей не требуется одинаковый тип
соответствия, в заявлении о соответствии должен быть указан перечень типов соот­
ветствия, которые требуются для каждого из ПЗ и ПЗ-модулей, составляющих ПЗ-
конфигурацию. ЗБ должно соответствовать ПЗ-конфигурации путем обеспечения соот­
ветствия каждому из ПЗ и ПЗ-модулей в соответствии с их требованиями.
Примечания
1 Это относится только к строгому и доказуемому соответствию, поскольку сочетание точного со­
ответствия с другими типами соответствия не допускается в ПЗ-конфигурации.
2 Совместимость многоуровневого соответствия должна быть подтверждена при оценке ЗБ та­
ким же образом, как если ЗБ заявляет о соответствии нескольким ПЗ, требующим различного соответ­
ствия.
с) может также включать ссылку на любые методы/ действия оценки, которые
были взяты из ИСО/МЭК 18045. Если методы/действия оценки, которые были получе­
ны из ИСО/МЭК 18045, связаны с ПЗ-конфигурацией, то утверждение о соответствии
должно также включать утверждение заявление в следующей форме:
«Эта ПЗ-конфигурация требует использования методов оценки/действий оценки,
определенных в<ссылка>.»
В этом заявлении <ссылка> заменяется указанием местоположения соответ­
ствующих методов оценки и действий по оценке. Эта ссылка может относиться к самой
ПЗ-конфигурации или к одному или нескольким отдельным документам.
Примечания
1 Спецификация дополнительных методов оценки/действий оценки, относящихся к одному или
нескольким компонентам ПЗ-конфигурации, разрешена только для ПЗ-конфигураций строгого или дока­
зуемого типа соответствия.
2 В случае точного соответствия, описанном в С.2.2.5, существуют последствия заявлений о со­
ответствии в ПЗ-модулях.
11.3.2.4 Требования доверия
ПЗ-конфигурация должна обеспечивать заявление ТДБ, в котором определены
применимые требования доверия и связанное с ними обоснование.
ПЗ-конфигурация с одним доверием должна определять единый набор ТДБ для
всех компонентов ПЗ-конфигурации. В случае точного соответствия этот набор ТДБ
должен
быть
идентично
объявленным
ТДБ
в
отдельных
компонентах
ПЗ-
конфигурации. В случае строгого и доказуемого соответствия этот набор ТДБ должен
82
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
быть идентичен или дополнять те ТДБ, которые заявлены в отдельных компонентах
ПЗ-конфигурации.
ПЗ-конфигурация с несколькими уровнями довериями должна определять:
- глобальный набор ТДБ, который относится ко всему ОО. В случае точного со­
ответствия этот набор ТДБ должен быть идентичен общему набору ТДБ в отдельных
компонентах ПЗ-конфигурации. В случае строгого или доказуемого соответствия этот
набор ТДБ должен быть идентичен общее подмножество ТДБ в отдельных компонен­
тах ПЗ-конфигурации или увеличивать его;
- набор применяемых ТДБ для каждой под-ФБО. В случае точного соответствия
этот набор ТДБ должен быть идентичен набору ТДБ, объявленному в компоненте ПЗконфигурация для под-ФБО. В случае строгого и доказуемого соответствия он должен
быть
идентичен
или дополнять
набор ТДБ,
объявленных
в
компоненте
ПЗ-
конфигурация для под-ФБО.
ПЗ-конфигурация может использовать предопределенные ОУД (ОУД1 - ОУД7),
указанные в ИСО/МЭК 15408-5, пакеты доверия, определенные во внешних ссылках,
и/или ТДБ, определенные в самой ПЗ-конфигурации, для определения ее утверждения
ТДБ.
ПЗ-конфигурация должна содержать утверждение ТДБ, в котором определены
применимые требования доверия и связанное с ними обоснование.
Примечание - Оценка с несколькими уровнями доверия позволяет использовать не­
сколько предопределенных ОУД. Однако по тем же причинам, что и для ПЗ в общей модели, ПЗ-
конфигурации могут заявлять наборы ТДБ, которые отличаются от предварительно определенных ОУД
и/или содержат расширенные ТДБ.
ПЗ-конфигурация может определять отличительные имена для наборов ТДБ, ко­
торые относятся ко всему ОО и к каждой под-ФБО. Однако использование (расширен­
ного) предопределенного ОУД или (расширенного) пакета доверия, определенных в
одном из компонентов ПЗ-конфигурации или в другой внешней ссылке, требует ис­
пользования того же имени.
ПЗ-конфигурация с несколькими уровнями доверия должна содержать обоснова­
ние доверия к:
- согласованности глобального набора ТДБ по отношению к моделям угроз, как
определено в ПБОр ПЗ и ПЗ-модулей в ПЗ-конфигурации; а также
- согласованности друг с другом глобального набора ТДБ и всех наборов ТДБ
для под-ФБО.
83
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
При построении глобального набора ТДБ для случая точного соответствия раз­
работчик ПЗ-конфигурации с несколькими уровнями доверия выбирает иерархически
самое низкое ТДБ, если подчиненные ФБО определяют иерархически разные ТДБ.
Например, если есть три под- ФБО с ADV_FSP.1, ADV_FSP.2 и ADV_FSP.3, соответ­
ственно, то глобальный набор ТДБ будет содержать ADV_FSP.1. Однако, если одно из
под-ФБО не содержит компонент ADV_FSP, то ADV_FSP не будет в глобальном наборе
ТДБ. Для случая строгого/доказуемого соответствия разработчик ПЗ-конфигурации с
многоуровневым доверием может выбрать ADV_FSP.1 или более высокий компонент,
тем самым увеличивая требования доверия для некоторых из его под-ФБО (даже в
случае, когда под-ФБО не определяют никакого компонента ADV_FSP) при условии по­
следовательности обоснование доверия.
Примечания
1 В большинстве случаев (и всегда в случае точного соответствия) глобальный набор ТДБ может
быть построен как общий набор ТДБ, который применяется ко всем под-ФБО. Однако, поскольку это слу­
чай ЗБ в общей модели, ПЗ-конфигурация (со строгим или доказуемым типом соответствия) может по­
требовать дополнительных или более высоких ТДБ. Оценка ПЗ-конфигурации обеспечивает последова­
тельность утверждения аналогично общей модели соответствия двум или более ПЗ, определяющим
разные наборы ТДБ, и аналогично подходу для ЗБ с несколькими уровнями доверия, который может
расширять наборы ТДБ, определенные в ПЗ-конфигурации, о соответствии которым заявляет ЗБ.
2 ПЗ-конфигурация не может предъявлять меньших требований доверия в качестве глобального
набора ТДБ/пакета доверия, чем требования, содержащиеся в общем наборе ТДБ, которые распростра­
няются на все под-ФБО.
3 Обоснование доверия ПЗ-конфигурации способствует обеспечению того, чтобы несколько
наборов ТДБ не подрывали безопасность, ожидаемую для активов, которые совместно используются
между ПЗ и ПЗ-модулями в ПЗ-конфигурации. Обоснование доверия ПЗ-конфигурации основывается на
обоснованиях доверия, приведенные в модулях ПЗ и ПЗ и/или повторно использует их.
4 . Для ПЗ-конфигураций сточным соответствием увеличение ТДБ для каждого под-ФБО (при по­
мощи ПЗ-конфигурации) не допускается.
Если указаны дополнительные ТДБ или ТДБ заменены иерархически более вы­
сокими ТДБ, то любые производные методы оценки/оценочные действия, требуемые
компонентами ПЗ-конфигурации, должны быть учтены в обосновании доверия, чтобы
продемонстрировать,
что
методы
оценки/оценочные
действия,
требуемые
ПЗ-
конфигурацией:
- по-прежнему адекватны, т.е. новое ТДБ не влияет на методы оценки/оценочные
действия в компонентах и доверие, которые они обеспечивают; или
- были внесены определенные уточнения в исходные методы оценки/оценочные
действия в компонентах, чтобы результирующие методы оценки/оценочные действия,
84
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
необходимые для ПЗ-конфигурации, обеспечивали доверие, которое является таким
же или более высоким, чем исходные методы оценки/оценочные действия, применяе­
мые к компонентам; или
- были пополнены дополнительными методы оценки/оценочные действия, чтобы
результирующие МС/ДО обеспечивали доверие, которое является таким же или более
высоким, чем исходные МС/ДО, применяемые к компонентам.
Действие, которое было проверкой документации для более низкого ТДБ, но где
может потребоваться дополнительное тестирование для иерархически более высокого
ТДБ, может дополнить первоначальные оценочные действия документации дополни­
тельными действиями по оценке, которые требуют тестирования.
На рисунке 5 показан пример ПЗ-конфигурации с несколькими уровнями доверия
с одним ПЗ, А и двумя ПЗ-модулями, X и Y. Это иллюстрирует построение по умолча­
нию глобального набора ТДБ для всего ОО, который состоит из ТДБ, т.е. общего набо­
ра ТДБ каждого из компонентов ПЗ-конфигурации А, X и Y. В этом примере наборы
ТДБ, которые применяются к под-ФБО, определенным в А, X и Y, также неизменны.
Примечание - Правила позволяют увеличивать наборы ТДБ.
85
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
,
ПЗ-конфигурация AXY
।
।
Перечень компонентов
ПЗА, ПЗ-модуль X, ПЗ-модуль Y
।
।
Изложение соответствия
ПЗд-> строгое, ПЗ-модульх-> строгое, ПЗ-модульу-> Демонстрируемое
।
।
।
।
।
।
Глобальный (характерный) ТДБС
под-ФБОд -> (ТДБс. ТДБа)
под-ФБОх —> (ТДБс, ТДБх)
под-ФБОу —> (ТДБс, ТДБу)
Обоснование многоуровневого доверия
Основано на обосновании^ обоснованиих, обоснованииу,
ПЗ-модуль X
ПЗ-модуль Y
База ПЗ-модуля: ПЗ А
Утверждение о соответствии:
База ПЗ-модуля: ПЗ А
Утверждение о соответствии:
Изложение соответствия
Строгое соответствие
Изложение соответствия
Строгое соответствие
Требования доверия
ТДБС ТДБх
Требования доверия
ТДБс ТДБу
Обоснование доверия
Обоснованиех
Обоснование доверия
Обоснованиеу
ПЗА
Утверждение о соответствии:
Изложение соответствия
Строгое соответствие
Требования доверия
ТДБС ТДБд
Обоснование доверия
Обоснованиед
Рисунок 5 - Пример ПЗ-конфигурации
11.3.3 Применение ПЗ-конфигураций
На рисунке 6 показано использование ПЗ-конфигураций с одним и несколькими
уровнями довериями. На рисунке 7 представлена подробная информация о компонен­
тах ПЗ-конфигурации. На рисунке 8 показаны классы доверия, которые используются
для оценки ПЗ, ПЗ-конфигураций и ЗБ.
86
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Соответствие одному или нескольким ПЗ?
Да
Использование ПЗ-модуля или многоуровневого доверия?
Нет
Да
Использование ПЗ-конфигурации
Использование ПЗ
См. рисунок «Построение ПЗ-конфигурации»
Нет
Набор 1
ТД_Б_
ПЗ конфигурация является с многоуровневым
доверием, когда ПЗ и ПЗ-модулей есть свои
собственные наборы различных ТДБ
Должен быть определен глобальный
(характерный) пакет доверия: надмножество
наименьшего подмножества наборов ТДБ
Исключения:
Если все компоненты ПЗ-конфигурации имеют
одинаковый набор ТДБ, то это рассматривается
как случай одноуровневого доверия
I
ПЗ может определять
различные наборы
ТДБ
Многоуровневая
Одноуровневая,
автономный 3
/ПЗ соответствует*
ПЗ-конфигурации
с одноуровневым
доверием
ЗБ соответствует ПЗ
ПЗ соответствует ПЗ-конфигурации с
многоуровневым доверием
Глобальны
)
I
(1-п)
|
(характерный)
I Наборы ТДБ |
;_ пакецдовеция___ ,
(
------------------------ Л
।
Набор ТДБ
I
Набор ТДБ
I Набор ТДБ ]
к____________ ,
I
______________ J
Только один
набор ТДБ
Всегда случай
использования
одноуровневого
доверия
Независимо от типа
соответствия, набор из
ТДБ задания по
безопасное™ должен
быть надмножеством
наборов ПЗ требований
доверия к безопасности
Всегда случай
использования
Случай
использования
ЗБ может дополнить
набор ТДБ
компонентов ПЗконфигурации, чтобы
вернуться к варианту
использования
одноуровневого
доверия
одноуровневого
доверия
Исключение:
в точном соответствии
дополнении ТДБ не
допускается
одноуровневого
доверия
Одноуровневая
оценка доверия к
ОО
ЗБ в
парадигме
многоуровн
евой
оценки
доверия
Многоуровневая
оценка доверия к
ОО
(опциональные или требуемые)
Методы оценки определяются в соответсвии с
ГОСТ ИСО/МЭК 18045, плюс дополнительные
ч______ методы и действия по оценки_______
Рисунок 6 - Применение ПЗ-конфигураций с одним и несколькими уровнями доверия
87
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Построение ПЗ-конфигурации со строгими/демонстрируемыми
типами соответствия
содержит не менее двух компонентов ПЗ-конфигурации, в том числе
1 ПЗ
(0..п)
базовый ПЗ
(0..п)
другой ПЗ
возможно - или *
]
=
Набор ТДБ
{ Набор ТДБ 1
------ Т
ВОЗМОЖНО = или *
(0..п)
ПЗ-модуль
возможно = или Ф
Набор ТДБ
Построение ПЗ-конфигурации сточными
типами соответствия
содержит не менее двух компонентов ПЗ-конфигурации, в том числе
1 ПЗ
(0..п)
базовый ПЗ
Набор ТДБ .....
(0..п)
другой ПЗ
{ Набор ТДБ
(0..п)
ПЗ-модуль
Рисунок 7 - Комбинация компонентов ПЗ
88
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Соответствие одному или
нескольким ПЗ?
Да
Нет
Использование ПЗ-модуля и (или) многоуровневого
доверия ?_
Нет
С использованием ПЗ
Да
С использованием ПЗ-конфигурации
ПЗ-конфигурация с
одноуровневым
доверием
ЗБ с
одноуровневым
доверием
ЗБ с
одноуровневым
доверием,
соответствующее
нескольким ПЗ
Одноуровневая
оценка доверия
ОО
ПЗ-конфигурация с
многоуровневым
доверием
ЗБ с
одноуровневым
доверием,
ЗБ с
одноуровневым
доверием,
ЗБ с
многоуровневым
доверием,
соответствующее
ПЗ-конфигурации с
одноуровневым
доверием
соответствующее
ПЗ-конфигурации с
многоуровневым
доверием
соответствующее
ПЗ-конфигурации с
многоуровневым
доверием
Многоуровневая
оценка доверия
ОО
Рисунок 8 - Классы доверия, применяемые для оценивания ПЗ, ПЗ-конфигураций и ЗБ
89
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
12 Задание по безопасности
12.1 Общие положения
ЗБ является документом, в котором содержится описание конкретного ОО, тре­
бования соответствия, применимые к оценке ОО, проблема безопасности, которую
необходимо решить, цели безопасности для ОО и его среды функционирования, тре­
бования безопасности, применимые к решению заявленной проблемы безопасности, и
дополнительные материалы, необходимые для описания ОО в достаточной степени
для оценки. ЗБ, как правило, основаны на ПЗ или ПЗ-конфигурациях, которые описы­
вают проблему безопасности и требования к безопасности для типа ОО, соответству­
ющего конкретному ОО.
ЗБ обычно создается разработчиком, и его аудитория включает оценщиков, ор­
ганы по сертификации и конечных пользователей оцениваемого ОО.
Дополнительная информация о ЗБ содержится в Приложении D, которое должно
использоваться в сочетании с положениями настоящего документа.
12.2 Заявления и утверждения о соответствии
В данном подразделе использование курсивного текста указывает на букваль­
ный текст, который должен быть применен в тексте ЗБ. В заявлениях ЗБ о соответ­
ствии:
а) должно быть указание редакции соответствующих частей серии ИСО/МЭК
15408, которым соответствует требование ЗБ;
Ь) должно быть описание соответствия стандарту ИСО/МЭК 15408-2 (функцио­
нальные требования безопасности) как либо:
- “Соответствие стандарту ИСО/МЭК 15408-2”
ЗБ соответствует стандарту ИСО/МЭК 15408-2, если все ФТБ в этом ЗБ основа­
ны только на функциональных компонентах стандарта ИСО/МЭК 15408-2, или
- “Расширенный для ИСО/МЭК 15408-2”.
ЗБ является расширенным для ИСО/МЭК 15408-2, если хотя бы одно ФТБ в этом
ЗБ не основано на функциональных компонентах ИСО/МЭК 15408-2.
Примечание - Когда ОО успешно оценивается для ЗБ, любые утверждения ЗБ о соот­
ветствии также относятся к ОО. Таким образом, ОО также может заявлять о соответствии стандарту
ИСО/МЭК 15408-2.
с) должно быть описание соответствия стандарту ИСО/МЭК 15408-3 (требования
доверия к безопасности) как либо:
90
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
- "Соответствие стандарту ИСО/МЭК 15408-3”;
ЗБ соответствует стандарту ИСО/МЭК 15408-3, если все ТДБ в этом стандарте
основаны только на компонентах доверия в стандарте ИСО/МЭК 15408-3, или
- “Расширенный для ИСО/МЭК 15408-3”.
ЗБ является расширенным для ИСО/МЭК 15408-3, если хотя бы одно ТДБ в этом
ЗБ не основано на компонентах доверия в стандарте ИСО/МЭК 15408-3.
d) может включать требование о соответствии, сделанное в отношении пакетов.
Если предъявляется заявление о соответствии пакету, оно должно состоять из
одного из следующих требований для каждого пакета:
- “Соответствие пакету";
ЗБ соответствует пакету, если:
- для функциональных пакетов все составные части (ПБОр, цели безопасности и
ФТБ) функционального пакета присутствуют в соответствующих частях ЗБ без измене­
ний;
- для пакетов доверия. ТДБ этого ЗБ идентичны ТДБ в пакете доверия.
- “Увеличение пакета”
ЗБ заявляет увеличение пакета, если:
- для функциональных пакетов, все составные части (ПБОр, цели безопасности и
ФТБ) функционального пакета присутствуют в соответствующих частях ЗБ, но ЗБ со­
держит по крайней мере одно дополнительное ФТБ или ФТБ, которое иерархически
выше, чем ФТБ в пакете;
- для пакетов доверия, ЗБ содержит все ТДБ в пакете доверия, но содержит по
крайней мере одно дополнительное ТДБ или одно ТДБ, которое иерархически выше,
чем ТДБ в пакете доверия.
- “адаптированный пакет”
ЗБ не должны требовать адаптации или выполнять ее.
В одном пакете может быть заявлено более одного пакета.
Если ЗБ заявляют о точном соответствии ПЗ, они не должны заявлять о соответ­
ствии каким-либо пакетам, включая любые пакеты, заявленные ПЗ.
Если ЗБ заявляют о строгом или очевидном соответствии ПЗ, они не должны
также заявлять о соответствии упаковкам, заявленным в ПЗ, если только ЗБ не увели­
чивает пакет, как заявлено в ПЗ. То есть ПЗ может заявлять о пакете как о <package> соответствующем, <раскаде>-увеличенном или <раскаде>-адаптированном, но если
ЗБ сам не дополняет соответствующую/расширенную/адаптированную версию пакета в
91
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
ПЗ, то оно не будет заявлять о соответствии упаковке. ЗБ заявляет <пакет> - дополня­
ется только в том случае, если ЗБ увеличивает количество пакетов сверх того, что за­
явлено ПЗ.
Если ЗБ заявляют о соответствии ПЗ-конфигурации, они также не должны заяв­
лять о соответствии каким-либо функциональным пакетам, включая любые функцио­
нальные пакеты, заявленные компонентами ПЗ-конфигурации.
Если
ЗБ
заявляют
о
строгом
или
соответствии
демонстрируемом
ПЗ-
конфигурации, они не должны также заявлять о соответствии пакетам доверия, заяв­
ленным в ПЗ-конфигурации, если ЗБ не увеличивает пакет, заявленный в ПЗконфигурации. То есть ПЗ-конфигурация может заявить о пакете доверия как <пакет> соответствующем или <пакет>-увеличенным, но если ЗБ сам по себе не увеличивает
соответствующую/увеличенную версию пакета в ПЗ-конфигурации, тогда он будет не
заявлять о соответствии пакету доверия. ЗБ заявляет, что <пакет> -увеличенным толь­
ко в том случае, если ЗБ увеличивает пакет доверия сверх того, что заявлено ПЗ-
конфигурацией.
Примечание - Для точного соответствия разрешается заявлять о соответствии ПЗ, кото­
рый заявляет о соответствии пакету или ПЗ-конфигурации, в которой есть компоненты, заявляющие о
соответствии пакету, но не отраженные в заявлении ЗБ о соответствии.
а) может также включать заявление о соответствии в отношении ПЗ:
- «Соответствующий ПЗ»;
ПЗ или ОО соответствует конкретному (конкретным) ПЗ.
ЗБ с прямым обоснованием может заявлять только о соответствии одному или
нескольким другим ПЗ с прямым обоснованием. (См. Приложение В)
а)
может также
включать
заявление о
соответствии
в
отношении
ПЗ-
конфигураций:
- ЗБ может заявить о соответствии только одной ПЗ-Конфигурации;
- ЗБ с прямым обоснованием должен заявлять о соответствии ПЗ-конфигурации
только в том случае, если эта ПЗ-конфигурация использует метод прямого обоснова­
ния.
Примечания
1 Оценка ПЗ-конфигурации может быть выполнена заранее, независимо от любой оценки про­
дукта. В качестве альтернативы, оценка ПЗ-конфигурации может выполняться во время оценки соответ­
ствующего ЗБ перед оценкой заявления о соответствии ЗБ. См. 13.3 для обсуждения оценки ПЗконфигураций.
92
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
2 ПЗ-модули используются для создания определенных ПЗ-конфигураций поверх одной или не­
скольких баз ПЗ-модулей. Следовательно, ПЗ-модули должны использоваться только ЗБ через заявлен­
ные ПЗ-конфигурации.
Ь)
если методы оценки/оценочные действия, которые были получены из
ИСО/МЭК 18045, указаны в утверждении о соответствии любого пакета, ПЗ, ПЗ-модуля
или ПЗ-конфигурации, соответствие которым заявлено в ЗБ, то заявление о соответ­
ствии также должно включить заявление в следующей форме:
«ОО оценивается с использованием методов оценки/оценочных действий, опре­
деленных в <ссылка>».
В этом заявлении <ссылка> заменяется указанием местоположения соответ­
ствующих методов оценки и оценочных действий.
От ЗБ, которые ссылаются на методы/оценочных действия, не требуется вос­
произведение текста методов /оценочных действий в рамках ЗБ.
ЗБ должно делать заявление о соответствии только для методов оцен­
ки/оценочных действий,
которые
включены
в
пакет,
ПЗ,
ПЗ-модуль
или
ПЗ-
конфигурацию, заявленные ЗБ.
Примечания
1 Напоминаем читателю, что может случиться так, что ЗБ заявляет об отсутствии ПЗ или ПЗконфигурации, но все же может напрямую указать пакет.
2 ЗБ может заявлять о соответствии нескольким ПЗ. Если один из таких ПЗ имеет точный тип со­
ответствия, то все ПЗ должны иметь точный тип соответствия. В противном случае, ПЗ могут иметь
смесь строгих и доказуемых типов, и согласованность комбинации доказуемого и строгого соответствия
должна быть подтверждена в рамках оценки ЗБ.
Для получения дополнительной информации и требований к заявлениям ЗБ о
соответствии см. Приложение D.
Дополнительную информацию и требования к типам соответствия см. в Прило­
жении Е.
12.3 Требования доверия
ЗБ, содержащее заявление о соответствии ИСО/МЭК 15408-3 (возможно, расши­
ренному), должно определять глобальный набор ТДБ, который применяется к ОО.
ЗБ может определить отличительное имя для набора применимых ТДБ. Однако
использование (увеличенного) заранее определенного ОУД или (увеличенного) пакета
доверия, определенного в применимой внешней ссылке, требует использования того
же имени.
93
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Если указаны дополнительные ТДБ или ТДБ заменены иерархически более вы­
сокими ТДБ в ЗБ, то любые производные методы оценки/оценочные действия должны
быть рассмотрены в обосновании доверия, чтобы продемонстрировать, что методы
оценки/оценочные действия, используемые ЗБ:
- по-прежнему адекватны, т.е. новое ТДБ не влияет на МО/ОД, указанные для
использования в ЗБ, и доверия, которые они предоставляют; или
- были внесены определенные уточнения в исходные МО/ОД, указанные ЗБ,
чтобы результирующие МО/ОД, необходимые для ЗБ, обеспечивали доверие, которое
является таким же или выше, чем исходные МО/ОД, указанные в ЗБ; или
- были обеспечены дополнительными МО/ОД, чтобы результирующие МО/ОД
обеспечивали доверие, которое является таким же или выше, чем исходные МО/ОД,
представленные ЗБ.
- если указаны дополнительные ТДБ или ТДБ заменены иерархически более вы­
сокими ТДБ в ЗБ, то в обосновании доверия должны быть рассмотрены любые произ­
водные методы оценки/оценочные действия, чтобы продемонстрировать, что методы
оценки/оценочные действия, используемые ЗБ; или
- все еще адекватны, т.е. новое ТДБ не влияет на МО/ОД, указанные для исполь­
зования в ЗБ, и доверие, которые они обеспечивают; или
- были учтены определенными уточнениям исходных МО/ОД, указанных в ЗБ, так
что результирующие МО/ОД, требуемые для ЗБ, генерируют такое же или более высо­
кое доверие, чем исходные МО/ОД, примененные к ЗБ; или
- были пополнены дополнительными МО/ОД, чтобы результирующие МО/ОД ге­
нерировали такую же или более высокую степень доверия, чем исходные МО/ОД, при­
меняемые к ЗБ.
Деятельность, которая заключалась в проверке документации на предмет нали­
чия более низкого ТДБ, но где может потребоваться дополнительное тестирование для
иерархически более высокого ТДБ, может дополнить действия по оценке исходной до­
кументации дополнительными оценочными действиями, которые требуют тестирова­
ния.
12.4 Дополнительные требования для случая точного соответствия
12.4.1 Дополнительные требования к заявлению о соответствии
ЗБ не должно заявлять о точном соответствии ПЗ/ПЗ-конфигурации и, в то же
время, другим ПЗ, которые не относятся к точному типу соответствия, то есть ПЗ / ПЗ94
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
конфигурация точного соответствия не должна сочетаться со строгим или доказуемым
соответствием.
12.4.2 Дополнительные требования к ПБОр
ЗБ, заявляющее о точном соответствии:
- должно содержать ПБОр всех пакетов и ПЗ или ПЗ-конфигурации, о точном со­
ответствии которым оно заявляет, включая все элементы ПБОр;
- не должно включать какие-либо элементы ПБОр, отсутствующие в пакетах или
ПЗ/ПЗ-конфигурациях, о точном соответствии которым оно заявляет.
Примечание - ПБОр, которая создается в ЗБ из ПЗ-конфигурации, содержит в точности
те элементы ПБОр, которые присутствуют в компонентах ПЗ-конфигурации (ПЗ-модули и ПЗ-модули).
Следует отметить, что компоненты ПЗ-конфигурации могут объединяться с целью изменения или устра­
нения элементов ПБОр (например, допущение в базовом ПЗ может стать угрозой, которой противодей­
ствует ПЗ-модуль наверху этого базового ПЗ), поэтому в результате ЗБ рассматривает такие модифика­
ции. См. 11.3.
12.4.3 Дополнительные требования к целям безопасности
Дополнительными требованиями к целям безопасности являются следующие:
- должно содержать все цели безопасности для ОО, указанные во всех ПЗ, соот­
ветствие которым он заявляет;
-
ЗБ, заявляющее о точном соответствии;
- не должно содержать дополнительные цели безопасности для среды функцио­
нирования, которые отсутствуют в комбинации ПЗ, о соответствие которым оно заяв­
ляет;
То же относится к ПЗ-конфигурациям. Цели безопасности, которые создаются в
ЗБ из ПЗ-конфигурации, содержат в точности цели безопасности, имеющиеся в компо­
нентах ПЗ-конфигурации. Следует отметить, что компоненты ПЗ-конфигурации могут
объединяться для изменения или устранения целей безопасности (например, цель
безопасности для среды в базовом ПЗ может стать целью безопасности ОО в ПЗ-
модуле, использующем эту базовую ПЗ), поэтому итоговое ЗБ отражает такого рода
модификации.
12.4.4 Дополнительные требования к требованиям безопасности
ЗБ должен содержать все ТДБ, имеющиеся в ПЗ, и все ТДБ, имеющиеся в ком­
понентах ПЗ-конфигурации, за следующими исключениями:
- разработчики ЗБ не должны включать дополнительные или иерархически бо­
лее высокие требования безопасности;
95
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
- ФТБ, обозначенные в ПЗ или ПЗ-модулях, как необязательные, должны быть
исключены, если выбор, требующий их включения, не выбран разработчиком ЗБ
ФТБ, обозначенные как дополнительные ФТБ в ПЗ или ПЗ-модулях, могут быть
включены или исключены при сохранении заявления о точном соответствии.
Примечания
1 ТДБ в ПЗ точного соответствии могут повторяться и уточняться (как указано в ИСО/МЭК 18045
для ASE_CCL.1-12).
2
Дополнительную информацию о необязательных и основанных на выборе ФТБ см. в 7.3.2.6.
3 Дополнительную информацию о соответствии ПЗ см. в Приложении Е для получения дополни­
тельной информации о соответствии ПЗ.
1
2.5 Дополнительные требования в случае с многоуровневым доверием
ЗБ должно заявлять о соответствия только одной конфигурации ПЗ с многоуров­
невым доверием и никаким другим ПЗ или конфигурациям ПЗ.
ЗБ с многоуровневым доверием должно организовать ФТБ в под-ФБО и заявлять
об определенном наборе ФТБ для каждой из под-ФБО и глобальном наборе ТДБ для
всего ОО: это может быть достигнуто исключительно за счет соответствия ПЗконфигурации с многоуровневым доверием. Структура ФТБ, определенная в ЗБ,
наследуется от ПЗ-конфигурации, и наборы ТДБ, которые соответствуют им в ЗБ, либо
идентичны тем, которые определены в ПЗ-конфигурации, либо увеличены.
ЗБ с многоуровневым доверием может расширить ПЗ-конфигурацию с много­
уровневым доверием (строгого или доказуемого типа соответствия) дополнительными
ФТБ (и по мере необходимости связанными с ними ПБОр и целями безопасности), что­
бы каждый новый элемент завершался как минимум в одном ПЗ, ПЗ-модуле или ПЗконфигурации при условии соблюдения требуемых правил соответствия. То есть новые
ФТБ направлены на расширение под- ФБО,
определенных компонентами ПЗ-
конфигурации. Как следствие, расширенные под-ФБО подчиняются набору ТДБ, как
определено в исходных ПЗ/ПЗ-модулях.
ЗБ с многоуровневым доверием может расширять ПЗ-конфигурацию с много­
уровневым доверием (строгого или доказуемого типа соответствия) дополнительными
ФТБ (и, при необходимости, соответствующими ПБОр и целями безопасности), так что
каждый новый элемент завершается как минимум в одном ПЗ, ПЗ-модуле или ПЗконфигурации при соблюдении требуемых правил соответствия. То есть новые ФТБ
нацелены на расширение под-ФБО, определенных компонентами ПЗ-конфигурации.
Как следствие, расширенные под-ФТБ подчиняются набору ТДБ, как определено в ис­
ходных ПЗ/ПЗ-модулях.
96
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
ЗБ с многоуровневым доверием может заявлять наборы ТДБ, определенные в
ПЗ-конфигурации с многоуровневым доверием, или, в случае строгого или доказуемого
типа соответствия, может служить основанием для заявления «увеличенных» наборов
ТДБ, подобных ЗБ в общей модели.
Чтобы соответствовать двум или более ПЗ согласно их соответствующим набо­
рам ТДБ, ПЗ-конфигурация с многоуровневым доверием, состоящая из ПЗ, должна
быть определена и заявлена ЗБ.
ЗБ, которое заявляет о соответствии с ПЗ-конфигурацией с многоуровневым до­
верием и дополняет все применяемые наборы ТДБ для получения такого же набора
ТДБ для всего ОО и всех под-ФБО, становится ЗБ с одним доверим. В этом случае
оценка ОО должна следовать методу оценки одного доверия. Это разрешено только
для ПЗ-конфигураций строгого или доказуемого типа соответствия.
ЗБ, которое заявляет о соответствии нескольким ПЗ, может определять только
глобальный набор ТДБ, который относится ко всему ОО, тем самым создавая ЗБ с од­
ной доверием. В отношении ПЗ применяются правила ASE по обеспечению согласо­
ванности требований доверия ЗБ с одним доверием.
ЗБ, которое заявляет о соответствии одной ПЗ-конфигурацией с одним довери­
ем, т.е. определяет только один набор ТДБ для всего ОО и его частей, не может стать
ЗБ с многоуровневым доверием. Причина в том, что правила согласованности с много­
уровневым доверием определены на уровне ПЗ-конфигурации. Для этого необходимо
определить и оценить ПЗ-конфигурацию с многоуровневым доверием, производную из
ПЗ-конфигурации.
Для получения дополнительной информации о ПЗ-конфигурациях с многоуров­
невым доверием и ЗБ см. п. 12.4.2. ЗБ, заявляющее о соответствии ПЗ-конфигурации с
многоуровневым доверием, может стать ЗБ с многоуровневым доверием, определяя
для каждой под-ФБО применимый набор ТДБ. Это будет либо тот же набор ТДБ, уна­
следованный от ПЗ-конфигурации, либо более крупный набор (увеличение, действи­
тельное только в случаях строгого и доказуемого соответствия), что требует обновле­
ния обоснования доверия, предоставленного в ПЗ-конфигурации.
ЗБ с многоуровневым доверием может определять отличительные имена для
наборов ТДБ, которые применяются ко всему ОО и к каждому под-ФБО. Имена должны
соответствовать именам, указанным в ПЗ-конфигурации. Использование (увеличенно­
го) предопределенного ОУД или (увеличенного) пакета доверия, определенных во
внешней ссылке, требует использования того же имени.
97
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
ЗБ с многоуровневым доверием, которое заявляет о строгом или доказуемым
соответствии ПЗ-конфигурации и расширяет наборы ТДБ ПЗ-конфигурации, о соответ­
ствии которым оно заявляет, должно обеспечивать обоснование доверия, которое
оправдывает согласованность расширения.
ЗБ с многоуровневым доверием должно соответствовать всем без исключения
отдельным типам соответствия, которые указаны в утверждении о соответствии ПЗконфигурации с многоуровневым доверием.
Примечание - ЗБ, заявляющее о соответствии более чем одному ПЗ, может определять
только глобальный набор ТДБ, который относится ко ОО в целом. В таком случае для обеспечения со­
гласованности требований доверия ЗБ в отношении ПЗ применяются правила ASE.
На рисунке 9 показан пример ЗБ с многоуровневым доверием, которое заявляет
о соответствии ПЗ-конфигурации «AXY», состоящей из ПЗ А и двух ПЗ-модулей X и Y.
Структура ФТБ состоит из под-ФБО, определенных в А, X и Y. Глобальный набор ТДБ и
несколько
наборов ТДБ,
которые
применимых к
конфигурации без каких-либо увеличений.
98
под-ФБО,
поступают
из
ПЗ-
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Задание по безопасности
Утверждение о соответствии
ПЗ-конфигурация AXY
ПЗА-> строгое, ПЗ-модульх-> строгое, ПЗ-модульу ->,£
Требования доверия
Глобальный (характерный) ТДБС
под-ФБОа-> (ТДБс.ТДБа)
под-ФБОх-> (ТДБс.ТДБх)
под-ФБОу-> (ТДБс.ТДБу)
Обоснование многоуровневого доверия
Основано на обосновании AXY
ОО
ПЗ-конфигурациЯ'АХУ
Перечень компонентЬв
ПЗА, П3-модуль X, П3*-модуль Y
I» I
•
Изложение соответствия
ПЗА-> строгое, ПЗ-модульх-> строгое, ПЗ-мадульу-> Демонстрируемое
II *
•
Глобальный (характерный) ТДБС
под-ФБОа-> (ТДБс.ТДБд)
под-ФБОх -> (ТДБС ТДБх)
под-ФБОу -> (ТДБс,Т^Бу)
Обоснование многоуровневого доверия
•
Основано на обоснойаниид, обоснованиих, обоснованииу,
ПЗА
ПЗ-модуль X
ПЗ-модуль Y
Рисунок 9 - Пример ЗБ с многоуровневым доверием
99
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
13 Оценка и результаты оценки
13.1 Общие положения
В данном разделе представлены ожидаемые результаты оценок ПЗ, ПЗконфигурации и ЗБ/ОО, выполненных в соответствии с ИСО/МЭК 18045 и/или дополни­
тельными методами оценки и оценочными действиями.
Цель оценки состоит в том, чтобы получить объективные и воспроизводимые ре­
зультаты, которые могут быть приведены в качестве доказательства, даже при отсут­
ствии абсолютной объективной шкалы для представления результатов оценки без­
опасности.
Примечание - Часто необходим компромисс между соответствующим современным тех­
ническим уровнем и достаточным уровнем повторяемости. Поэтому такие свойства, как объективность и
повторяемость, не рассматриваются стандартом как абсолютные, а скорее как цели, которые могут быть
достигнуты различными способами. Например, стандарт ИСО/МЭК 15408-4 предусматривает одну из
таких структур сохранения объективности и повторяемости при выводе оценочных действий из стандар­
та ИСО/МЭК 18045.
Результат оценки представляет собой результаты определенного вида исследо­
вания защитных свойств ОО. Такой результат автоматически не гарантирует пригод­
ность для использования в какой-либо конкретной среде применения. Решение о при­
нятии ОО для использования в конкретной среде применения основано на рассмотре­
нии многих проблем обеспечения безопасности, включая результаты оценки.
На рисунке 10 показаны различные оценки, необходимые для обеспечения уве­
ренности в результатах оценки для ОО.
100
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Оценить
ПЗ
/Оценить^
ПЗконфигура
\ цию У
Результаты
оценки ПЗ
Результаты
оценки ПЗконфигурации
э
Оцененный ПЗ
Оцененная ПЗконфигурация
Результаты
оценки ОО
Реестр ПЗконфигурац₽
Результаты
оценки ЗБ
Оцененное ЗБ
Оценить
ОО
Реестр ПЗ
*
Оценить
ЗБ
Оцененный ОО
Реестр ОО
Рисунок 10 - Процесс оценки
Серия стандартов ИСО/МЭК 15408 дает критерии для четырех типов оценки:
а) оценка ПЗ, основанная на классе АРЕ, приведенном в ИСО/МЭК 15408-3, из­
ложена в 13.3;
Ь) оценка
ПЗ-конфигурации,
основанная
на
классе
АСЕ,
приведенном
в
ИСО/МЭК 15408-3, изложена в 13.3;
с) оценка ЗБ, основанная на классе ASE, приведенном в ИСО/МЭК 15408-3, из­
ложена в 13.4;
d) оценка ОО, основанная на оцененном ЗБ и критериях оценки требований без­
опасности, заявленных ЗБ, изложена в 13.5.
Оценка ПЗ и ПЗ-конфигурации обеспечивает уверенность в том, что ПЗ и/или
ПЗ-конфигурация соответствует требованиям серии ИСО/МЭК 15408. Каталоги ПЗ и
ПЗ-конфигураций могут утверждаться уполномоченными органами или теми, кто опре­
деляют критерии для включения в каталог.
Примечание - Критерии включения в каталог не входят в область применения стандар­
тов серии ИСО/МЭК 15408.
101
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
ПЗ-модули
оцениваются
только
как
часть
оценки,
основанной
на
ПЗ-
конфигурации. Пакеты оцениваются только как часть оценки ПЗ-конфигурации, ПЗ или
ЗБ.
Примечание - На практике ЗБ, заявляющее о соответствии некоторым неоцененным ПЗ-
конфигурациями, все же может быть оценено путем выполнения сначала оценки ПЗ-конфигурации.
Оценка ЗБ приводит к промежуточному результату, который используется в рам­
ках оценки ОО. По желанию, ЗБ могут быть разработаны с заявлением о соответствии
пакетам, ПЗ и ПЗ-конфигурациям.
Оценки ЗБ/ОО могут привести к каталогам оцененных ОО. Во многих случаях эти
каталоги относятся к продуктам ИТ, из которых происходят ОО, а не к конкретным ОО.
Следовательно, наличие ИТ-продукта в каталоге не может толковаться как означаю­
щее, что весь ИТ-продукт был оценен; вместо этого фактическое ЗБ определяет фак­
тическую степень оценки ОО.
Примеры таких каталогов см. в библиографии
13.2 Контекст оценки
Для достижения большей сопоставимости результатов оценки следует прово­
дить в рамках схемы оценки.
Примечание - В серии стандартов ИСО/МЭК 15408 не устанавливаются требования к та­
ким схемам оценки.
Поддержка большей сопоставимости результатов оценки также достигается за
счет использования общих методов оценки, дающих эти результаты оценки. Использо­
вание общей методологии оценки способствует повторяемости и объективности ре­
зультатов, но само по себе недостаточно. Многие критерии оценки требуют использо­
вания экспертных оценок и базовых знаний, для которых труднее добиться согласо­
ванности. Чтобы повысить непротиворечивость полученных результатов оценки, окон­
чательные результаты оценки могут быть представлены в процессе сертификации.
Примечание - Серия стандартов ИСО/МЭК 15408 не содержит требований к оценке ком­
петентности разработчиков или оценщиков. ИСО/МЭК 19896-3 устанавливает требования к компетент­
ности для оценщиков по ИСО/МЭК 15408, которые могут использоваться в качестве поддержки в про­
цессе оценки. Однако в нем рассматриваются только базовые методологические навыки и не рассмат­
ривается способ оценки:
- специфические для технологий знания и навыки, такие как те, которые требуются для выполне­
ния оценки ADV, АТЕ или AVA_VAN для данного типа продукта;
-
102
отраслевые знания, которые обычно требуются для выполнения оценки ASE, АРЕ или АСЕ.
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Кроме того, определенные навыки, необходимые для оценки, проводимой в соответствии с
ИСО/МЭК 15408, могут потребовать дополнительных методов оценки компетентности. Например, для
оценки навыков, связанных с формальными методами.
Для серии стандартов ИСО/МЭК 15408 общая методология оценки безопасности ИТ приведена в
ИСО/МЭК 18045. Более конкретные методы и действия оценки могут быть получены из ИСО/МЭК 18045
с использованием структуры, приведенной в ИСО/МЭК 15408-4, путем уточнения стандартных компонен­
тов доверия или определения компонентов расширенного доверия.
Разработчикам ПЗ может потребоваться дополнить общую методологию оценки безопасности
ИТ, приведенную в ИСО/МЭК 18045, методом, который включает действия по оценке, специфические
для определенной технологии.
Процесс сертификации, не входящий в область применения серии ИСО/МЭК
15408, может включать независимую проверку результатов оценки, ведущую к выпуску
окончательного сертификата или утверждения, которые могут быть опубликованы.
Процесс сертификации является средством достижения большей согласованности в
применении критериев безопасности ИТ.
13.3 Оценка ПЗ и ПЗ-конфигураций
Создание ПЗ или ПЗ на основе оцененной ПЗ/ПЗ-конфигурации дает два пре­
имущества:
- гораздо меньше риска того, что в ПЗ/ПЗ-конфигурации есть ошибки, двусмыс­
ленности или пропуски. Если во время оценки этих ПЗ/ПЗ-конфигурации, во время
написания или оценки нового ЗБ были обнаружены какие-либо проблемы с этим, мо­
жет пройти значительное время, прежде чем ПЗ/ПЗ-конфигурация будет исправлена;
- при оценке новой ПЗ/ПЗ-конфигурации можно повторно использовать результа­
ты предыдущей оценки, что приводит к меньшим усилиям, затрачиваемым на оценку
новой ПЗ / ПЗ-конфигурации.
Если требуется оценка ПЗ, следует использовать критерии АРЕ, приведенные в
15408-3.
Если требуется оценка ПЗ-конфигурации, следует использовать критерии АСЕ,
приведенные в ИСО/МЭК 15408-3.
Цель таких оценок - продемонстрировать, что ПЗ или ПЗ-конфигурация являются
полной, внутренне непротиворечивыми, технически надежными и пригодными для ис­
пользования в качестве шаблона для построения ЗБ или другого ПЗ.
Метод представления результатов оценки для ПЗ и ПЗ-конфигураций изложен в
подразд еле13.7.
Примечание - ПЗ-модули не оцениваются отдельно; они оцениваются в ходе оценки ПЗ-
Конфигурации, которая их использует.
103
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
13.4 Оценка ЗБ
Оценка ЗБ определяет достаточность ОО, среды функционирования и внутрен­
нюю согласованность описаний и требований, которые он содержит.
Оценка ЗБ должна выполняться в соответствии с критериями оценки ASE, опре­
деленными в ИСО/МЭК 15408-3. Методы и действия, используемые для выполнения
критериев ASE, определяются методологией оценки, связанной с ЗБ, которая указана в
ИСО/МЭК 18045, или методами оценки/ оценочными действиями, вытекающими из
ИСО/МЭК 18045. Подтверждение производных методов оценки/оценочных действий
находится вне области применения стандартов ИСО/МЭК 15408 и ИСО/МЭК 18045.
Примечание - Пользователи настоящего стандарта/серии стандартов должны знать, что
схемы оценки не всегда подтверждают необходимость использования определенных методов оцен­
ки/оценочных действий. ЗБ может потребовать методов оценки/оценочных действий, и схема оценки
может принять решение не проводить оценки в соответствии с этим ЗБ.
Описание метода изложения результатов оценки ЗБ содержится в 13.7. Эти ре­
зультаты также идентифицируют любые ПЗ и пакет(ы), о соответствии которым заяв­
лено в ЗБ.
13.5 Оценка ОО
Оценка ОО определяет соответствие ОО критериям, определенным в ЗБ. Как
было сказано ранее, оценка ОО не определяет корректность среды функционирования.
Оценка ОО более сложна. Основными входными данными для оценки ОО явля­
ются свидетельства оценки, которые включают в себя ОО и ЗБ, но обычно также вклю­
чают входные данные из среды разработки, такие как проектная документация или ре­
зультаты тестирования разработчика.
Оценка ОО состоит из сопоставления ТДБ (из ЗБ) со свидетельством оценки.
Метод применения конкретного ТДБ к ОО определяется ИСО/МЭК 18045 и методами
оценки/оценочными действиями, основанными на ИСО/МЭК 18045. Подтверждение
производных методов оценки/оценочных действий находится вне области применения
стандартов ИСО/МЭК 15408 и ИСО/МЭК 18045. Пользователи настоящего стандар­
та/серии стандартов должны знать, что схемы оценки не всегда подтверждают исполь­
зование определенных методов оценки/оценочных действий. ЗБ может потребовать
методы оценки/оценочные действия, и схема оценки может принять решение не про­
водить оценки в соответствии с этим ЗБ.
104
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
То, как документируются результаты применения ТДБ, какие отчеты должны
быть созданы и с какой степенью детализации, определяется как используемой мето­
дологией оценки, так и схемой оценки, по которой проводится оценка.
Оценка ОО может проводиться после завершения разработки ОО или парал­
лельно с ней при условии, что для этой оценки выбраны соответствующие компоненты
доверия.
Метод представления результатов оценки ЗБ/ОО описан в 13.7.
13.6 Методы оценки и оценочные действия
Общие методы и действия по оценке ИТ для каждого из классов доверия к без­
опасности, указанных в ИСО/МЭК 15408-3, представлены в ИСО/МЭК 18045. Методы
оценки и оценочные действия, приведенные в ИСО/МЭК 18045, являются высокоуров­
невыми и в зависимости от типа технологий, уровня доверия или описанной проблемы
безопасности может потребоваться предоставление более конкретных методов оценки
и действий.
То, как документируются результаты применения ТДБ, какие отчеты должны
быть созданы и с какой степенью детализации, определяется как используемой мето­
дологией оценки, так и схемой оценки, по которой проводится оценка.
Такие методы оценки/оценочные действия, которые были взяты из 18045, могут
быть опубликованы либо как включение в ПЗ, ПЗ-модули и пакеты, либо как отдельные
сопроводительные документы.
13.7 Результаты оценки
13.7.1 Результаты оценки ПЗ
Результаты оценки ПЗ должны включать «Заявление о соответствии» согласно
10.3.
Примечание - В ИСО/МЭК 15408-3 представлены критерии оценки ПЗ в классе АРЕ.
13.7.2 Результаты оценки ПЗ-конфигурации
Результаты оценки ПЗ-конфигурации должны включать «заявление о соответ­
ствии» в соответствии с 11.3.
После оценки ПЗ-конфигурации оценка ЗБ может основываться на результатах
оценки ПЗ-конфигурации.
Примечания
1 ИСО/МЭК 15408-3 предоставляет критерии оценки для ПЗ-конфигураций в классе АСЕ.
2 Оценка ПЗ-конфигурации может проводиться в двух ситуациях, не влияющих на методологию
оценки:
- независимо от какой-либо другой оценки продукта;
105
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
- в качестве первого шага оценки ЗБ, заявляющего о соответствии ПЗ-конфигурации. В против­
ном случае заявление о соответствии не имеет смысла, и оценка ЗБ в этом аспекте не удалась бы.
13.7.3 Результаты оценки ЗБ/ОО
13.7.3.1 Общие положения
Результаты оценки ЗБ должны включать «Заявление о соответствии», как опре­
делено в 12.2.
Для успешной оценки ОО требуется успешная оценка ЗБ. Результатом процесса
оценки ОО является либо:
- утверждение о том, что все ТДБ выполнены, и, следовательно, существует
определенный уровень уверенности в том, что ОО соответствует требованиям ФТБ,
как указано в ЗБ;
- утверждение о том, что не все ТДБ были выполнены и, следовательно, не су­
ществует определенного уровня уверенности в том, что ОО соответствует требовани­
ям ТДБ, как указано в ЗБ.
Примечание - В некоторых случаях результаты оценки впоследствии используются в
процессе сертификации, но этот процесс сертификации выходит за рамки серии стандартов ИСО/МЭК
15408.
Если оценка ОО привела к заявлению о прохождении, базовый продукт может
иметь право на включение в каталог успешно оцененных продуктов.
13.7.3.2 Использование результатов оценки ЗБ/ОО
После оценки ЗБ и ОО владельцы активов могут быть уверены, как определено в
ЗБ, в том, что ОО вместе с средой функционирования противодействует заявленным
угрозам. Результаты оценки могут использоваться владельцем актива как часть реше­
ния о принятии риска, связанного с воздействием угроз на активы.
Тем не менее, заказчики должны тщательно проверять:
а) соответствие ПБОр в ЗБ их собственной проблеме безопасности;
соответствие их сред функционирования (или они могут быть приведены в соот­
ветствие) целям безопасности для среды функционирования, описанным в ЗБ;
с) соблюдение всех руководящих документов, предоставленных разработчиком в
контексте оценки ОО, во время установки, конфигурации и эксплуатации ОО.
Если какое-либо из этих условий не выполняется, нельзя полагаться на соответ­
ствующее доверие, и результаты оценки должны быть соответствующим образом рас­
смотрены при принятии решения о принятии риска.
Кроме того, как только оцениваемый ОО находится в эксплуатации, вероятна
идентификация ранее неизвестных ошибок или уязвимостей в ОО. В этом случае раз106
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
работник может исправить ОО (устранить уязвимости) или изменить ЗБ таким образом,
чтобы исключить вновь идентифицированные уязвимости из области оценки. В любом
случае предыдущие результаты оценки больше не могут быть действительными.
Примечание - Для поддержания доверия необходима повторная оценка. Для этой пере­
оценки можно использовать серию стандартов ИСО/МЭК 15408, но подробности процедуры переоценки
не входят в область применения настоящего стандарта.
13.8 Многоуровневая оценка доверия
Для ПЗ-конфигурации с многоуровневым доверием требования АСЕ, приведен­
ные в ИСО/МЭК 15408-3, обеспечивают, что комбинация различных наборов ТДБ не
подорвет ожидаемую безопасность базовых активов, как определено в ПБОр ПЗ и ПЗ-
модули, составляющие ПЗ-конфигурацию.
Для ЗБ с многоуровневым доверием требования ASE, приведенные в ИСО/МЭК
15408-3, обеспечивают, что ЗБ соответствует ПЗ-конфигурации с многоуровневым до­
верием, которая удовлетворяет требованиям доверия АСЕ. Это означает, что органи­
зация ФБО в под-ФБО и наборы ТДБ, которые к ним относятся, согласуются с ПЗконфигурацией. Для каждого под-ФБО это означает, что ЗБ с многоуровневым довери­
ем заявляет набор идентичных ТДБ или является дополнением набора ТДБ, опреде­
ленных в ПЗ-конфигурации для соответствующего компонента (ПЗ или ПЗ-модуль).
Общая модель стандарта, применяемая при многоуровневой оценке доверия,
требует, чтобы для обеспечения безопасности ОО оценщик проводил оценку ФБО. В
контексте многоуровневого доверия оценщик все же учитывает воздействие на ОО в
целом оценки каждого из под-ФБО.
На практике многоуровневую оценку доверия можно рассматривать как несколь­
ко оценок одного и того же ОО согласно разным ПЗ. Многоуровневая оценка доверия
добавляет проверки непротиворечивости, которые необходимы обеспечения возмож­
ности проведения совместно этих оценок. Это, в частности, означает, что набор ТДБ,
связанный с под-ФБО, не влияет на другие под-ФБО. Следовательно, на свидетель­
ство, требуемое для ТДБ одного под-ФБО, не могут отрицательно повлиять ТДБ, кото­
рые были выбраны для других под-ФБО.
Представим, что ПЗ-конфигурация выбирает AVA_VAN.3 для одной под-ФБО.
Тогда по зависимости потребуется ADV_TDS.3. Оценка ADV_TDS.3 для этих под-ФБО
по определению будет учитывать все подсистемы ОО, независимо от уровней
ADV_TDS других под-ФБО, определенных в ОО.
107
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Многоуровневая оценка доверия ОО, который соответствует ЗБ с многоуровне­
вым доверием, состоит из оценки всего ОО в сравнении с глобальным набором ТДБ и
оценки каждого из под-ФБО в сравнении с соответствующими наборами ТДБ, как опре­
делено в ЗБ. Порядок действий по оценке остается на усмотрение оценщика. Наибо­
лее подходящий порядок зависит от таких факторов, как фактическая структура ФБО с
точки зрения под-ФБО и разницы между глобальным набором ТДБ и наборами ТДБ,
которые применяются к под-ФБО.
Ограничение многоуровневой оценки доверия объектами оценки (и ЗБ), которые
соответствуют одной ПЗ-конфигурации с многоуровневым доверием, и определение
правил согласованности с многоуровневым доверием в АСЕ позволяют ограничить
воздействие на другие классы доверия. Проведение многоуровневой оценки доверия
заключается в проведении единообразной интерпретации всех классов доверия, опре­
деленных в ИСО/МЭК 18405: в контексте многоуровневой оценки доверия всякий раз,
когда в ТДБ упоминается «ОО», он относится ко всему ОО. Всякий раз, когда в ТДБ
упоминаются «ФБО», это относится к под-ФБО, к которому относится ТДБ.
Примечание - ЗБ с многоуровневым доверием отражает организацию ФБО в под-ФБО,
определенных в ПЗ-конфигурации, соответствие которой заявлено в ЗБ. Эта организация ФБО не опи­
сывает организацию реализации ОО в подсистемах и модулях, а скорее связывает данный набор функ­
ций безопасности (под-ФБО) с конкретными требованиями доверия. Может случиться так, что под-ФБО
реализованы разными наборами подсистем/модулей, но также может быть некоторая степень совпаде­
ния: подсистема или модуль могут реализовывать функции, принадлежащие двум разным под-ФБО. Это
означает, что два набора ТДБ относятся к общей подсистеме или модулю (т.е. применяется объедине­
ние наборов ТДБ). В обоих случаях для каждой под-ФБО все остальные под-ФБО принадлежат ОО, и
соответствующие подсистемы/модули должны оцениваться через призму требований под-ФБО.
14 Объединение доверия
14.1 Общие положения
ИТ-продукты почти всегда состоят из нескольких компонентов, при этом некото­
рые из них оцениваются, а некоторые нет. Независимые компоненты продукта часто
оцениваются отдельно, и возникает вопрос об объединении доверия к безопасности
отдельных компонентов с целью определения доверия к безопасности всего продукта.
Программное обеспечение состоит из оцененного оборудования для создания
ИТ-продукта.
Объединение доверия зависит от:
- типа объединения;
108
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
- политик функций безопасности и политики безопасности организации, на кото­
рых основывалась оценка компонентов;
-
заявленного доверия к безопасности, например, уровня доверия;
-
общих политик безопасности для всего продукта.
Понятия моделей объединения изложены в подразделе 14.2. Методы оценки, с
помощью которых может быть обеспечено доверие к безопасности в таких моделях
объединения, приведены в подразделе 14.3. Соображения относительно повторного
использования результатов оценки, относящихся к отдельным компонентам продукта в
подходе к объединению, рассматриваются в подразделе 14.4. В подразделе 14.5 рас­
сматривается взаимосвязь между подходами комплексной оценки и многоуровневой
оценки доверия.
14.2 Модели объединения
14.2.1 Многоуровневая модель объединения
В этом типе объединения один компонент располагается над другим, как пред­
ставлено на рисунке 11.
«Зависимый» компонент «Б»
«Основной» компонент «А»
Рисунок 11 - Многоуровневая модель объединения
В отношении многоуровневой модели объединения сделаны следующие допу­
щения:
- базовый компонент не зависит от зависимого компонента;
- базовый компонент изменяется зависимым компонентом;
- зависимый компонент использует функциональные возможности базового ком­
понента, но не наоборот.
Тем, кто осуществляет подобное объединение, следует учитывать, что:
- зависимый компонент может зависеть от других функций, кроме функций без­
опасности, в рамках оценки базового компонента;
- два примера приведены для пояснения модели многоуровневого объединения,
представленного на рисунке 11.
109
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Первым и основным примером является смарт-карта, где метод оценки был
определен для модели многоуровневого объединения. В этом контексте смарт-карта
состоит из двух частей:
- часть аппаратной интегральной схемы (ИС) (как базовый компонент); а также
- программная часть над ним (как зависимый компонент).
Программная часть может зависеть от функции, которая не относится к оценива­
емой функциональности безопасности базового оборудования. Однако в целом почти
все инструкции оборудования являются частью функций безопасности оборудования и
используются для реализации функций безопасности программной части.
Программная часть смарт-карты потенциально многоуровневая, состоящая из:
- уровня «операционная система» с возможно интегрированной аппликативной
функцией (в качестве базового компонента); и
- уровня «приложения» над ним, который содержит различные приложения (как
зависимый компонент). Все эти части могут быть разработаны разными субъектами с
конкретными целями.
Приложения, выполняемые на персональном компьютере, следуют тому же
принципу, при этом операционная система (ОС) выступает в качестве базового компо­
нента, а уровень приложений - в качестве зависимого компонента: приложение исполь­
зует идентификацию и аутентификацию, предоставляемую ОС, создает свои собствен­
ные объекты на основе на вершине файловой системы ОС, строит свою собственную
структуру распространения поверх управления и разделения адресного пространства
ОС, и обеспечивает выполнение определенных свойств (например, отказоустойчиво­
сти, управления информационными потоками). Если ОС уже была оценена, то функци­
ональные возможности безопасности уровня распространения могут быть разбиты на
оцененные функциональные возможности безопасности базового компонента. Там, где
это невозможно, зависимый компонент сам реализует функции безопасности. Кроме
того, зависимый компонент может зависеть от функций, которые не принадлежат оце­
ненным функциональным возможностям безопасности нижележащего базового компо­
нента.
14.2.2 Сеть или модель двунаправленного объединения
В этом типе объединения компонент использует определенные функции другого
компонента через некий канал связи, как показано на рисунке 12.
110
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Компонент
«А»
Компонент
«Б»
Рисунок 12 - Сетевая модель или модель двунаправленного объединения
В отношении сетевой модели или модели двунаправленного объединения сде­
ланы следующие допущения:
- подробно описаны взаимозависимости безопасности;
- оба продукта разделены таким образом, что нет иного канала или воздействия,
кроме предопределенного;
- оба продукта используют функции, необходимые для защиты канала связи;
- функции.
Если такого рода проблемы выявлены, то они должны быть четко задокументи­
рованы вместе с определением соответствующих смягчающих мер контроля.
Примечания
1 Приложение (компонент «А»), использующее функцию внешнего сервера LDAP (компонент
«В»). Тем, кто используют такое объединение, следует учитывать, что функции безопасности могут не
подходить друг к другу.
2 Контроль доступа может быть основан на разных объектах: предположения, сделанные в от­
ношении компонента, могут быть неверными.
3 Предположение о защите критических данных, передаваемых другому компоненту: функцио­
нальность безопасности может иметь нежелательные побочные эффекты.
1
4.2.3 Встроенная модель объединения
В этом типе объединения компонент используется как часть более крупного ком­
понента или продукта, как показано на рисунке 13. В отношении сетевой или двуна­
правленной модели объединения сделаны следующие допущения:
Основной
компонент «Б»
Незначительный
компонент «А»
Рисунок 13 - Встроенная модель объединения
- каждая часть может влиять на другую через каналы и интерфейсы, отличные от
предполагаемых.
111
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Библиотека или подсистема, обеспечивающая определенные функции безопас­
ности как часть более крупного продукта.
Те, кто выполняет такую композицию, должны учитывать, что из-за отсутствия
разделения компоненты потенциально:
-
обходят функции безопасности других компонентов;
- изменяют функции безопасности и политику безопасности других компонентов
и всего продукта;
-
вводят ряд серьезных побочных эффектов.
Примечание - Если указано разделение, описание критериев оценки DV_ARC приведено
в ИСО/МЭК 15408-3.
14.3 Методы оценки для обеспечения доверия в композиционных моделях
14.3.1 Общие
Для достижения надежных и повторяемых результатов оценки продуктов ИТ
(ОО), в которых используются модели объединения, описанные в п. 14.2, необходим
соответствующий подходящим образом определенный метод оценки.
В п. 14.3.2 и 14.3.3 рассматриваются методы оценки для модели слоистой ком­
позиции. 14.3.2 описывает, как класс АСО, определенный в ИСО/МЭК 15408-3, может
использоваться для составных ОО, а в 14.3.3 предоставляется метод оценки состав­
ных продуктов, который уже широко применяется в отрасли и демонстрирует много­
численные преимущества (см. 14.3.3.1).
Две другие модели композиции (т.е. двунаправленная и встроенная) не рассмат­
риваются явно конфигурациями, определенными в серии стандартов ИСО/МЭК 15408.
14.3.2 Класс АСО для составных ОО
Класс АСО, указанный в ИСО/МЭК 15408-3, относится к ОО, состоящему из двух
ОО, с использованием многоуровневой модели композиции, как описано в п. 14.2, оба
из которых оценивались отдельно. Эти компонентные ОО можно описать как базовый
ОО и зависимый ОО, как показано на рисунке 14. В таком случае класс АСО использу­
ется для оценки составного ОО.
Оценка такого составного ОО состоит из оценки взаимодействия между обоими
ОО, в результате чего происходит повторное использование результатов оценки как
базового, так и зависимого ОО.
ИСО/МЭК 15408-5 предоставляет заранее определенные составные пакеты до­
верия (СПД), которые могут использоваться для определения уровня доверия состав­
ного ОО.
112
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Класс АСО применим вплоть до уровня доверия «улучшенный базовый».
Композиционный ОО
Зависимый ОО
Базовый ОО
Рисунок 14 -Составленный ОО оценивается на примере класса АСО
14.3.3 Композиционная оценка для композиционных изделий
14.3.3.1 Общие положения
Метод составной оценки относится к модели многоуровневой композиции для
композиционных изделий, как описано в 14.2, и предназначена для выполнения следу­
ющих целей:
- самостоятельно выполнять оценку базового компонента для обращения к не­
скольким зависимым компонентам и клиентам;
- создавать один или несколько зависимых компонентов для использования с
оцениваемым базовым компонентом;
- устанавливать один зависимый компонент на оцениваемый базовый компонент,
чтобы уменьшить усилия по оценке, сохраняя высокий уровень доверия.
Метод составной оценки описывает способ передачи знаний и повторного ис­
пользования доказательств для достижения этих целей.
Связанные с СОМР семейства доверия, указанные в ИСО/ МЭК 15408-3 для
классов ADV, ALC, ASE, АТЕ и AVA, предоставляют критерии оценки, относящиеся к
составным продуктам, использующим эту многоуровневую модель.
14.3.3.2 Цели
113
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Этот метод составления доверия применяется к многоуровневым продуктам, ко­
торые включают один независимо оцениваемый базовый компонент и один зависимый
компонент.
Примечание - Зависимый компонент потенциально состоит из одного или нескольких за­
висимых подкомпонентов. Для упрощения в дальнейшем они рассматриваются как «один зависимый
компонент».
Составной продукт состоит из объединения уже оцененного базового компонента
(включая его базовый ОО) и зависимого компонента. Таким образом, базовый ОО яв­
ляется частью составного ОО. В методе составной оценки повторно используются ре­
зультаты оценки, уже полученные для базового ОО, а оценка зависимого компонента
выполняется в рамках оценки составного продукта, при этом особое внимание уделя­
ется оценке взаимосвязи между базовым ОО и зависимым компонентом. Следова­
тельно, уровень доверия заявлен и относится к составному продукту в целом, а не
только к зависимому компоненту.
Составной продукт с его базовым компонентом (включая базовый ОО) и зависи­
мым компонентом предназначен для эффективной оценки. С целью оптимизации оцен­
ки такого составного продукта разработан конкретный метод составной оценки.
В отличие от оценки на основе АСО, это позволяет проводить прямое сравнение
с аналогичными продуктами, которые оцениваются сразу, без использования методов
составления. Более того, нет никаких ограничений в по отношению к уровню доверия,
т.е. составной продукт может претендовать на любой предопределенный СУД или чет­
ко определенный пакет доверия, включая устойчивость к «высокому базовому потен­
циалу атаки», как определено в AVA_VAN.5 ИСО/МЭК 15408-3 тогда как АСО ограни­
чивается требованиями СПД к «высокому базовому потенциалу атаки. Целью является
не определение дополнительного класса доверия, а определение дополнительных
требований доверия для составной оценки.
14.3.3.3 Проектирование составного продукта и составного ОО
Составной продукт состоит из одного базового компонента (включая его базовый
ОО) и одного зависимого компонента, посредством чего с учетом аспектов оценки при­
меняются следующие правила и ограничения для составного продукта и его составной
части ОО:
- базовый компонент создает базовый независимый уровень составного продукта
и содержит базовый ОО. Базовый компонент с его базовым ОО уже должен быть оце­
нен;
114
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
- зависимый компонент образует надэлементарный слой составного продукта,
который зависит от базового компонента и который должен оцениваться в рамках
оценки композиционного изделия;
- составной ОО является частью составного продукта и охватывает весь зависи­
мый компонент, а базовый ОО; более подробно, требуется надмножество базовых
функциональных возможностей ОО для корректного и безопасного исполнения состав­
ного продукта;
Примечание - Составной ОО может содержать части, независимые от базового компо-
нента/базового ОО. Для упрощения такие части считаются принадлежащими зависимому компоненту.
- зависимый компонент не может полагаться на функциональные возможности
базового компонента, которые находятся в базовом компоненте, но лежат за предела­
ми базового ОО (то есть функциональные возможности в части базового компонента,
не относящейся к ОО);
- часть составного продукта, не относящаяся к ОО, может использовать базовые
функциональные возможности компонентов, в частности базовые функциональные
возможности ОО. Как обычно, составная оценка должна определить, что эта часть со­
ставного продукта, не относящаяся к ОО, не мешает зависимому компоненту - ни
напрямую, ни посредством использования функций базового компонента;
- части составного продукта, не относящиеся к ОО, в частности части оценивае­
мого базового компонента, не относящиеся к ОО (т.е. части базового компонента, ле­
жащие вне базового ОО), считаются частью среды функционирования составного ОО.
Примечания
1 Составная оценка применима независимо от оценочного уровня доверия (ОУД) для намеченно­
го составного продукта. Если некоторые действия по оценке не подлежат применению из-за выбранного
ОУД, они также не будут применяться.
2 Настоящий стандарт касается только случаев, когда уровень доверия базового компонента эк­
вивалентен уровню составной оценки или выше его.
3 В случае, когда и базовый компонент, и зависимый компонент уже были оценены с использова­
нием серии ИСО/МЭК 15408, работа по составной оценке потенциально зависит от результатов, уже по­
лученных как из предыдущей оценки базового компонента, так и из предыдущей оценки зависимого ком­
понента. Тем не менее, цель составной оценки, определенная в стандарте, еще не достигнута.
На рисунке 15 показана общая конфигурация и разбиение составного продукта и
составного ОО на уровни в рамках метода составной оценки.
115
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Граница
композиционного ОО
(красный) \
Композиционный продукт
Зависимый компонент
Базовый компонент
Часть композиционного
продукта, не относящегося к ОО
Часть базового продукта,
не относящегося к ОО
Граница
базового
продукта
Граница
композиционного
продукта
Граница базового ОО
(красная точка)
Рисунок 15 - Составная оценка
Несколько шагов составления могут следовать друг за другом. Другими словами,
базовый компонент сам по себе может быть составным продуктом, состоящим из соб­
ственного уже оцененного базового компонента и зависимого компонента.
1
4.3.3.4 Роли
Оценку проходят базовый компонент и составной продукт, точнее базовый и со­
ставной ОО. Следовательно, у них обоих есть спонсор, разработчик, оценщик и орган
по оценке.
Для модели составной оценки, относящейся к оценке составного продукта, ожи­
дается предварительная окончательная оценка базового компонента с его базовым
ОО. Составная оценка выполняет оценку составного продукта путем повторного ис­
пользования результатов оценки уже оцененного базового компонента. Следователь­
но, оценка составного продукта фокусируется на оценке зависимого компонента, вклю­
чая его связь с базовым компонентом, и, таким образом, принимает во внимание базо­
вый ОО с соответствующими результатами оценки.
На практике разработчика составного продукта нет, поскольку составной продукт
является результатом интеграции зависимого компонента и базового компонента. Вме­
сто этого соответствующие роли, связанные с разработкой, здесь следующие:
разработчик зависимого компонента, ответственный за реализацию зависимого
компонента (и других частей составного продукта, не относящихся к ОО, если это воз­
можно);
116
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
- разработчик базового компонента, ответственный за реализацию базового ком­
понента; а также
- интегратор составного продукта, ответственный за интеграцию базового и за­
висимого компонентов.
Чтобы обратиться к этой модели ролей, метод составной оценки определяет до­
полнительные оценочные действия для вышеупомянутого разработчика зависимых
компонентов, разработчика базовых компонентов и интегратора составных продуктов.
Примечания
1 Как уже упоминалось, зависимый компонент может быть подвергнут отдельной оценке, но
оценщик и оценивающий орган этой предыдущей оценки в ней не участвуют. Если бы базовый компо­
нент и зависимый компонент оценивались отдельно, у каждого из них были бы спонсор, разработчик,
оценщик и орган по оценке.
2 Как и в общих случаях, некоторые задействованные субъекты могут быть одними и теми же.
Контекст составной оценки также приводит к конкретным случаям, когда субъекты выполняют несколько
ролей. Каждая оценка связывает определенные организации или персонал с этими общими ролями.
Например:
- разработчик базового компонента также может быть спонсором базового компонента;
- орган по оценке базового компонента также может быть органом по оценке составного продук­
та.
3 Интегратор составного продукта выполняет другую роль, чем разработчик. Хотя этот интегра­
тор в некоторых случаях также может быть одним из разработчиков, определенных ранее, это не всегда
так.
Пример иллюстрирует роль интегратора составного продукта:
- собственные смарт-карты: базовый компонент, лежащий в основе, представляет собой инте­
гральную схему, а разработчик базового компонента - производитель интегральной схемы (чипа); зави­
симый компонент - это операционная система карты и ее приложение (я), а разработчик зависимого ком­
понента - это разработчик операционной системы смарт-карты и приложения (приложений). В этом слу­
чае роль интегратора составного продукта играют:
-
производитель микросхемы встраивает ядро операционной системы в ПЗУ микросхемы, затем:
- производитель карты обычно загружает некоторые части операционной системы и приложения
в NV-память (EEPROM и / или Flash) чипа.
-устройства с поддержкой технологии Java Card: базовый компонент - это система Java Card
(среда выполнения Java Card, виртуальная машина и API) на кристалле, а разработчик базового компо­
нента - производитель/эмитент карты; зависимый компонент - это апплет Java Card, который может быть
разработан разработчиком апплета, играющим роль разработчика зависимого компонента. В этом слу­
чае роль интегратора составного продукта может играть поставщик услуг домена/приложения или дове­
ренный центр, загружающий сертификат и часто персонализирующий карту в электронном виде
14.3.3.5 Элементы действий и требуемая информация
117
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Чтобы дать возможность оценить составной продукт, метод составной оценки
выявляет два основных набора проблем, что приводит к появлению следующих пра­
вил:
- составной продукт может быть небезопасным из-за пробелов в определении,
интеграции или тестировании механизмов безопасности базового и зависимого компо­
нентов. В частности, должны быть соблюдены следующие свойства:
- активы, которые должны быть защищены, являются активами конечного со­
ставного продукта, определенными в специализированном ЗБ составного продукта;
- механизмы безопасности, задействованные в защите этих активов, обеспечи­
ваются базовым компонентом и зависимым компонентом;
- некоторые механизмы безопасности и услуги безопасности, предоставляемые
базовым компонентом, могут требовать настройки, программирования или активации,
как это разрешено для базового ОО зависимым компонентом;
-
оценка выполняется и проверяется на конечном композиционном продукте.
Для этого метода составной оценки определяет конкретные элементы действий,
которые должны выполняться участниками, участвующими в оценке базового компо­
нента, а также в разработке зависимого компонента и в оценке составного продукта.
- вышеупомянутые элементы действия потенциально невозможно выполнить изза отсутствия обмена информацией между участниками. Чтобы избежать этого, метод
составной оценки явно определяет, какая информация требуется для каждого элемен­
та действия.
Таблицы 2 и 3 определяют, какие ТДБ должны быть выбраны в ЗБ составного
продукта, а также информация, которая должна быть доступна разработчику зависимо­
го компонента, оценщику составного продукта и органу по оценке составного продукта,
чтобы разрешить и поддержать составную оценку.
Таблица 2 - Информация, предоставляемая разработчику зависимого компонен­
та
ТДБ, определяющие эле­
менты действий
Согласованность Цели
обеспечения безопасности
составного продукта
(ASE_COMP)
118
Требуемая информация
ЗБ базового компонента.
Информация для создания ЗБ
составного продукта и обес­
печения согласованности
определения безопасности
между базовым и зависимым
компонентами.
Информация, относящаяся к
механизмам безопасности
базового компонента и серви-
Составитель информации
Разработчик базового ком­
понента
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Соответствие составному
проекту (ADV_COMP)
сам безопасности, которыми
зависимый компонент должен
управлять или использовать.
Информация (обычно в форме
просто руководства или руко­
водства пользователя), отно­
сящаяся к механизмам без­
опасности базового компонента
и услугам безопасности, кото­
рыми зависимый компонент
должен управлять или исполь­
зовать.
Разработчик базового
компонента
Потенциально для выполнения составной оценки составного продукта, которая
объединяет такой оцененный базовый компонент, оценщику составного продукта не
нужны все подробные результаты оценки базового компонента. Однако для повторного
использования результатов оценки базового компонента оценщику составного продук­
та необходима дополнительная информация о мерах доверия, когда базовый компо­
нент и зависимый компонент мешают. В частности, для проверки соответствия зависи­
мого компонента требованиям безопасности, налагаемым базовым компонентом, и для
анализа уязвимости составного продукта оценщик составного продукта использует ру­
ководство пользователя оцененного базового компонента, соответствующий отчет ор­
гана оценки базового компонента (т.е. отчет об оцененном продукте, который подтвер­
ждает принятие результатов оценки, предоставленных оценщиком) и так называемый
отчет для составной оценки, описанный в 14.3.3.6.
В целом, для использования методики составной оценки, помимо стандартного
объема информации, требуемого пакетом доверия, выбранным для составной оценки
(например, ОУД), необходимо следующее, указанное в таблице 3.
Таблица 3 - Информация, которая должна быть предоставлена оценщику со­
ставных продуктов и органу по оценке составных продуктов
ТДБ, определяющие
элементы действий
Согласованность
Цели обеспече­
ния безопасно­
сти составного
продукта
(ASE_COMP)
Интеграция составных
частей и проверка со­
гласованности проце-
Требуемая информация
ЗБ базового компонента.
Информация, относящаяся к составным продук­
там, для обеспечения согласованности опреде­
ления безопасности между базовым и зависимым
компонентами.
Информация, относящаяся к механизмам без­
опасности базового компонента и сервисам без­
опасности, которыми зависимый компонент дол­
жен управлять или использовать.
ЗБ составного продукта (включая информацию о
совместимости ЗБ составного продукта с ЗБ ба­
зового компонента).
Составное свидетельство конфигурации.
Организационное свидетельство правильности
версии на основе списков конфигурации, содер-
Составитель
информации
Разработчик базового
компонента
Разработчик
зависимого
компонента
Интегратор
составного
продукта
119
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
дур доставки
(ALC_COMP)
Соответствие со­
ставному проекту
(ADV_COMP)
Составное функцио­
нальное тестирование
(АТЕ_СОМР)
Составная оценка уяз­
вимости (AVA_COMP)
120
жащих однозначную информацию о версии оце­
ниваемого базового компонента и зависимого
компонента, интегрированного в конечный со­
ставной продукт. Элементы свидетельства того,
что меры безопасности, предписанные разработ­
чиком базового компонента и разработчиком за­
висимого компонента, фактически применяются
интегратором составного продукта.
Доказательства приемки-доставки.
Информация о соответствии процедур поставки
разработчика базового компонента и разработчи­
ка зависимого компонента процедуре приемки
интегратора составного продукта.
Организационное свидетельство того, что компо­
ненты (зависимый компонент и базовый компо­
нент), передаваемые от субъекта к другому, без­
опасным образом получаются, принимаются и
параметризуются.
Базовые требования и рекомендации по интегра­
ции, связанные с компонентами, обычно включа­
ющие руководство пользователя.
Отчет для составной оценки.
Базовые требования и рекомендации по интегра­
ции.
Доказательства соответствия конфигурации.
Доказательства того, что составной продукт со­
ответствует базовым требованиям и рекоменда­
циям по интеграции, связанным с компонентами.
Он включает в себя элементы свидетельств того,
как требования к проекту зависимого компонента,
налагаемые руководством пользователя базово­
го компонента и отчетом органа по оценке базо­
вого компонента, выполняются в составном про­
дукте. Если такое требование не было выполне­
но, здесь должно быть дано обоснование того,
что выбранная реализация составного продукта
все еще безопасна.
Отчет об оценке базового компонента, состав­
ленный органом по оценке базового компонента.
(Дополнительно) Базовые требования и реко­
мендации по интеграции компонентов
Образцы составных продуктов, пригодные для
тестирования.
Отчет для составной оценки.
Свидетельство, позволяющее оценщику состав­
ного продукта и соответствующему органу оценки
понять пути атаки и тесты, которые были рас­
смотрены и выполнены для базового компонента,
и эффективность контрмер, реализованных базо­
вым компонентом, а также объяснения, связан­
ные с остаточными уязвимостями базового ком­
понента. компонент, связанные с рекомендация­
ми по интеграции, включенными в руководство
пользователя базового компонента.
Отчет об оценке базового компонента, состав­
ленный органом по оценке базового компонента.
(Дополнительно) Базовые требования и реко­
мендации по интеграции, связанные с компонен­
тами, обязательства, информация об уязвимо-
Интегратор
составного
продукта
Разработчик
зависимого
компонента
Разработчик базового
компонента
Разработчик базового
компонента
Интегратор со­
ставного про­
дукта Разработ­
чик зависимого
компонента
Орган по оценке ба­
зового компонента
Интегратор
составного
продукта
Разработчик базового
компонента
Орган по оценке ба­
зового компонента
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
стях.
Руководство пользователя по базовым компонен­
там.
Разработчик базового
компонента
Примечания
1 Отчет для оценки базового компонента, составленный органом по оценке базового компонента,
также может быть актуальным для ТДБ ASE_COMP, ALC_COMP и АТЕ_СОМР, даже если он непосред­
ственно не рассматривается в таблице 3.
2 В случае объединения термин «разработчик» нуждается в дальнейшем разъяснении с целью
различения действующих лиц. Здесь разработчик базового компонента, разработчик зависимого компо­
нента и интегратор составного продукта могут быть разными субъектами. Аналогичным образом, необ­
ходимо провести дополнительное различие между различными участвующими субъектами для терминов
«оценщик» и «орган по оценке (схема оценки)».
3 В случае, когда уже были оценены и базовый компонент, и зависимый компонент, возможно,
будет достаточно сокращенного количества действий по оценке с учетом результатов оценки, уже полу­
ченных из предыдущей оценки зависимого компонента. Тем не менее, по-прежнему необходимо выпол­
нение задач составной оценки, определенные в настоящем стандарте, Примером является смарт-карта.
Архитектура смарт-карты состоит из аппаратной платформы и программного приложения над платфор­
мой. В этом случае платформа является базовым компонентом, а приложение - зависимым компонен­
том. При составной оценке платформа уже оценена, приложение оценивается как часть составной оцен­
ки, и результаты оценки платформы используются повторно.
Аппаратная платформа обеспечивает функции, поддерживающие защиту акти­
вов составного продукта, но поведение составного продукта зависит от программного
приложения, которое должно использовать, корректировать и активировать функции
безопасности.
Таким образом, результаты оценки аппаратной платформы обычно содержат
конкретные рекомендации по безопасности и условия для реализации программного
обеспечения. Составная оценка включает проверку того, что комбинация обоих компо­
нентов не приводит к какой-либо уязвимости, которая может использоваться.
Предлагается метод составной оценки и связанные с ним действия по оценке,
которые включают точные рабочие единицы с четкими формулировками информации,
требуемой от разработчика платформы, и обеспечивают согласованную «структуру»
для передачи информации от оценщика платформы к оценщику составного продукта.
Необходимая информация уже доступна в задачах оценки платформы, и от раз­
работчика платформы не требуется дополнительные действия.
Для класса разработки ADV дополнительных требований нет.
Руководство пользователя (AGD) по платформе рассматривается на ранних эта­
пах разработки составного продукта и содержит информацию по всем требуемым ин­
терфейсам.
121
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Разработка и оценка составного продукта зависят от правильной реализации
проверенных интерфейсов платформы.
В объем составной оценки входит надлежащее использование всех соответ­
ствующих интерфейсов между платформой и приложением.
Тестирование (АТЕ) и оценка уязвимости (AVA) выполняются на составном про­
дукте с использованием имеющихся результатов оценки платформы.
1
4.3.3.6 Технический отчет о комплексной оценке
14.3.3.6.1 Назначение документа
Документ для составной оценки состоит из технического отчета об оценке, отно­
сящегося к базовому компоненту и его оценке, для предоставления достаточной ин­
формации для составной оценки с таким уже оцененным базовым компонентом.
Примечание - Стандартный отчет обычно содержит служебную информацию о базовом
компоненте и его оценке, которая не может быть опубликована. Следовательно, такой полный отчет,
возможно, не подходит для внешнего пользования. Информация, представленная в отчете для состав­
ной оценки, содержит значимое подмножество информации, представленной в полном отчете базового
компонента для поддержки составной оценки.
Цель отчета для составной оценки - дать возможность оценщику составного
продукта и органу оценки составного продукта понять пути атаки и тесты, которые были
рассмотрены и выполнены в отношении базового компонента, а также эффективность
контрмер, реализованных базовым компонентом.
Примечание - Содержание отчета для составной оценки обеспечивает необходимый ба­
ланс между защитой служебной информации разработчика базового компонента и/или оценщика базо­
вого компонента, с одной стороны, и предоставлением достаточной информации для оценщика состав­
ного продукта и органа по оценке составного продукта с другой стороны.
14.3.3.6.2 Процедура
Отчет для составной оценки создается оценщиком базового компонента на ос­
нове результатов оценки базового компонента и выводится из полного отчета, связан­
ного с оценкой базового компонента.
Отчет для составной оценки является частью оценки базового компонента. От­
чет для составной оценки предоставляется и проверяется по запросу спонсора оценки
базового компонента. В отчете центра оценки базового компонента по базовому ком­
поненту, в частности, декларируется принятие отчета для составной оценки всеми сто­
ронами, участвующими в оценке базового компонента (т.е. оценщиком базового компо­
нента, органом оценки базового компонента, разработчиком базового компонента и
спонсором оценки базового компонента). Такое заявление о валидации для отчета для
122
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
составной оценки, в частности, включает согласованность отчет для составной оценки
с исходным отчетом. В отчете центра оценки базовых компонентов для базового ком­
понента делается ссылка на отчет для составной оценки для дальнейшего повторного
использования.
Для повторного использования отчет для составной оценки в составной оценке
требуется предварительное принятие отчета для составной оценки органом оценки ба­
зовых компонентов. Отчет для составной оценки предоставляется оценщику составно­
го продукта и органу оценки составного продукта для использования в составной оцен­
ке.
Для отчета для составной оценки, как части оценки базового компонента, оцен­
щиком базового компонента и органом оценки базового компонента обеспечивается
предоставление в отчете для составной оценки достаточной информации с учетом об­
щей оценки и предполагаемого безопасного использования базового компонента в со­
ставных продуктах.
В случае, если после принятия отчета для составной оценки обнаруживаются
проблемы безопасности для базового компонента, которые недостаточно решены в от­
чете для составной оценки, тогда центр оценки базового компонента принимает реше­
ние о действиях, которые необходимо предпринять. Это может включать соответству­
ющее обновление отчета для составной оценки и последующую проверку этого обнов­
ленного отчета для составной оценки.
Для отчета для составной оценки, как части оценки базового компонента, обес­
печивается оценщиком базового компонента и органом оценки базового компонента,
что в отчете для составной оценки предоставляется достаточная информация с учетом
общей оценки и предполагаемого безопасного использования базового компонента в
композиционные изделия.
В случае обнаруживаются проблемы безопасности для базового компонента по­
сле принятия отчета для составной оценки, которые недостаточно решены в отчете
для составной оценки, тогда орган оценки базового компонента принимает решение о
необходимых действиях. Они могут включать соответствующее обновление отчета для
составной оценки и последующую проверку этого обновленного отчета для составной
оценки.
Кроме того, как часть оценки базового компонента оценщик базового компонента
обеспечивает, что рекомендации для базового компонента в соответствующем отчете
для составной оценки согласованы и закончены в отношении требований, представ123
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
ленных в руководстве пользователя базового компонента. Если обнаруживаются ка­
кие-либо несоответствия (включая отсутствующие требования), которые не допускают­
ся до выпуска отчета органа оценки для базового компонента, то орган оценки базово­
го компонента может добавить дополнительную информацию для разработчика зави­
симого компонента в отчет органа оценки базового компонента.
При составной оценке, если текущий базовый компонент сам полагается на
предыдущую составную оценку и если существует прямой интерфейс между зависи­
мым компонентом текущей оценки и предыдущим базовым компонентом, то отчет для
составной оценки предыдущей составной оценки также предоставляется действующе­
му оценщику составного продукта и органу по оценке составного продукта.
14.3.3.6.3 Обмен отчетами по составной оценке
Отчет для составной оценки создается и поддерживается оценщиком базовых
компонентов. Однако для комплексной оценки разработчик базового компонента явля­
ется контактным лицом для разработчика зависимого компонента.
Для доставки отчета для составной оценки контактной точке с оценщиком со­
ставного продукта разработчик зависимого компонента связывается с разработчиком
базового компонента. Разработчик базового компонента проверяет свои правила
управления конфиденциальностью, чтобы определить, возможна ли доставка. При
необходимости, чтобы узнать о намерении доставки отчета для составной оценки, раз­
работчик базового компонента связывается с органом по оценке базового компонента.
Чтобы запросить предоставление (используя безопасный метод и распространяя
только отмеченные версии) отчета для составной оценки в указанную контактную точку
оценщика составного продукта, разработчик базового компонента связывается с оцен­
щиком базового компонента. Если предоставление разрешено, либо оценщик базового
компонента, либо разработчик базового компонента отправляют отчет для составной
оценки оценщику составного продукта в зависимости от соглашений между этими дву­
мя сторонами. Процесс предоставления отчета для составной оценки зависит от
(обычно договорного) соглашения между разработчиком базового компонента и оцен­
щиком базового компонента, что может привести к отклонениям от описанной процеду­
ры. Отчет для составной оценки также доставляется в орган по оценке составного про­
дукта с использованием процедуры обмена, аналогичной для его предоставления спе­
циалисту по оценке составного продукта.
При необходимости оценщик базового компонента и оценщик составного продук­
та обмениваются дополнительной или более подробной информацией. Это всегда
124
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
находится под контролем разработчика базового компонента. В случае уточнения ос­
новными сторонами являются оценщик базового компонента и оценщик составного
продукта. Если требуется дополнительное заявление, обеспечивающее уверенность,
то в обмене также участвует орган по оценке базовых компонентов.
Важно, чтобы при многостороннем обмене информацией учитывались все выяв­
ленные средства контроля для обмена и защиты информации.
14.3.3.6.4 Содержание отчета для составной оценки
Информация, которую необходимо предоставить в отчете для составной оценки,
включает:
а) информацию об оцениваемом базовом компоненте;
Этот раздел отчета должен предоставлять формальную информацию об оценке
базового компонента, включая:
- информацию о версии отчета;
- однозначную идентификацию базового компонента;
- идентификаторы разработчика и спонсора базовых компонентов;
- идентификационные данные оценщика базовых компонентов и ответственного
за оценку базовых компонентов;
- степень достоверности оценки базового компонента;
- формальные результаты оценки, например, прошел/не прошел;
- ссылку на отчет, относящийся к базовому компоненту и его оценке.
Ь) Этот раздел отчета должен предоставить высокоуровневое описание базового
компонента и его основных компонентов на основе результатов разработок, требуемых
классом доверия ADV.
Цель этого раздела - охарактеризовать степень архитектурного разделения ос­
новных компонентов базового компонента, показать возможные технические зависимо­
сти между базовым компонентом и зависимым компонентом, использующим этот базо­
вый компонент, и описать механизмы безопасности базового компонента, охваченные
оценкой базового компонента.
с) информация об оцененной конфигурации базового компонента;
Этот раздел отчета должен содержать информацию об оцененной конфигурации
базового компонента, указанного в списке конфигураций разработчика или соответ­
ствующих частях по мере необходимости или в каждом конкретном случае. Базовый
компонент должен быть однозначно идентифицируемым, и эта идентификация должна
125
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
быть связана с оцениваемой конфигурацией, как указано в отчете органа оценки базо­
вого компонента по данному базовому компоненту.
Если это необходимо, должны быть объяснены настройки параметров генерации
и установки, которые имеют отношение к безопасности базового компонента, и должно
быть указано их воздействие на защиту от атак (например, пределы счетчика). Это
должно включать в себя методы, позволяющие разработчику зависимого компонента и
оценщику зависимого компонента проверять значения этих параметров настройки,
чтобы обеспечить использование ожидаемой оцененной конфигурации.
Это свидетельство может включать в себя процедуры установки, генерации и
запуска базового компонента, как описано в соответствующем руководстве пользова­
теля, чтобы обеспечить, что базовый компонент настроен безопасным образом.
d) информация о процедурах доставки, задействованных площадках разработки
и производстве и обмене данными;
Для поддержки составной оценки необходимы как свидетельства оценки проце­
дур поставки базового компонента и процедур приемки зависимого компонента, так и
соответствующие данные, которые необходимо интегрировать во время разработки и
производства.
Отчет для составной оценки должен предоставлять обзор сайтов, участвующих в
разработке и производстве базового компонента, включая роль каждого сайта и дату
последнего аудита.
е) информация о тестировании на проникновение базового компонента, включая
рассмотренные пути атаки и сводку результатов тестирования; информация о тестиро­
вании на проникновение вспомогательных функций в базовом компоненте;
Данный раздел отчета должен предоставлять информацию о независимом ана­
лизе уязвимостей, выполненном для базового компонента оценщиком базового компо­
нента с учетом рассмотренных сценариев атак, выполненном тестировании на проник­
новение и ссылку на соответствующий рейтинг (котировку) потенциала атаки.
Информация о тестировании на проникновение должна включать:
- сводку, показывающая все методы атак, которые были рассмотрены в ходе
анализа уязвимостей,
126
-
детали, необходимые для понимания рассмотренных сценариев/путей атак,
-
оценки выполненных тестов на проникновение и их результаты.
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Описания сценария атаки должны содержать достаточно подробностей, чтобы
помочь оценщику составного продукта воспроизвести атаки, которые требуют дополни­
тельных мер противодействия в составном продукте.
Если потенциальная уязвимость базового компонента должна быть устранена
путем выполнения руководства по базовому компоненту, это должно быть четко указа­
но в резюме, включая ссылку на конкретный раздел в руководстве или, если возможно,
на определенный пункт руководства.
f) замечания и рекомендации;
Руководство пользователя оцененного базового компонента должно содержать
всю информацию, необходимую для использования базового компонента безопасным
способом, как определено в целях безопасности базового компонента, в частности,
включая информацию о том, как избежать остаточных уязвимостей и неожиданного по­
ведения. Оценщик базового компонента должен обеспечивать наличие в отчете только
рекомендаций по безопасному использованию базового компонента, которые в руко­
водстве пользователя базового компонента рассматриваются как требования. Оцен­
щик базового компонента должен обеспечивать согласованность руководства пользо­
вателя базового компонента и рекомендаций в отчете и достаточную конкретность
требований руководства пользователя, чтобы позволить разработчику зависимого ком­
понента выполнить анализ соответствия проекта.
Однако в некоторых случаях может потребоваться дополнительная подробная
информация помимо руководства по базовому компоненту, чтобы позволить оценщику
составного продукта выполнить составную оценку, например:
- замечаний по результатам оценки базового компонента (например, конфигура­
ция конкретного базового компонента для оценки базового компонента);
- рекомендации/условия для оценщика составного продукта: конкретная инфор­
мация об использовании результатов оценки базового компонента (например, о спе­
цифических испытаниях, необходимых во время составной оценки).
Любое такое замечание или рекомендация/условие исходит от оценщика базово­
го компонента и/или органа по оценке базового компонента.
Отчет не предназначен для воспроизведения информации (например, текстовых
копий) из других доступных свидетельств базовых компонентов, таких как ЗБ и руко­
водство. Однако составная оценка подтверждается ссылками на соответствующие
разделы таких базовых свидетельств компонентов.
14.3.3.7 Отчеты и их достоверность
127
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Результаты составной оценки предоставляются органу по оценке составного
продукта в форме технического отчета об оценке составного продукта. Этот отчет по
составному продукту должен содержать, помимо прочей информации, окончательное
общее заключение по составной оценке, основанной на частичных заключениях по
каждому компоненту доверия, входящему в область текущей составной оценки. Ис­
пользование метода составной оценки должно быть учтено в отчете составного про­
дукта и, если это возможно, в отчете по составному продукту органа по оценке состав­
ного продукта.
Поскольку составной продукт и его составная оценка охватывают базовый ком­
понент и связанную с ним оценку, составная оценка связана с достоверностью и акту­
альностью отчета органа по оценке базового компонента для базового компонента.
Оценщику составного продукта и органу, осуществляющему оценку составного продук­
та, необходим действующий и обновленный отчет органа по оценке базового компо­
нента по данному базовому компоненту или, как минимум, оценка органа по оценке ба­
зового компонента статуса доклада органа оценки, о котором идет речь.
Примечания
1 Орган по оценке составного продукта обычно запрашивает повторную оценку базового компо­
нента, если отчет для составной оценки базового компонента недействителен или не обновлен, и, сле­
довательно, не подходит для повторного использования в составной оценке, в частности, из-за его
(устаревшего или недостаточного) анализа уязвимостей и тестирования на проникновение. Эта пере­
оценка состоит из переоценивания базового компонента с акцентом на возобновление анализа уязвимо­
стей и тестирования на проникновение (процесс наблюдения) или, в качестве альтернативы, утвержде­
ния заявления о подтверждении органа оценки базового компонента.
2 Если отчет для составной оценки базового компонента был разработан до представления свя­
занных с ним задач составной оценки и тем самым возникло серьезное изменение в совершении акту­
альных атак на базовый компонент (например, значительное изменение в методах или рейтингах атак),
то органу оценки составного продукта потенциально может потребоваться переоценка или переоценивание базового компонента с акцентом, в частности, на новые проблемы, связанные с атаками.
3 Правила, определяющие достоверность и актуальность отчетов (здесь, в частности, связанные
с отчетом органа по оценке компонентов по данному базовому компоненту и отчету для составной оцен­
ки), определяются соответствующей схемой оценки и могут быть связаны со специально определенным
сроком действия.
4 Если оценщик составного продукта обнаруживает какие-либо отказы, возникшие в результате
тестирования базового компонента (например, уязвимости из-за улучшенных методов или технологий
атак), эти результаты сообщаются органу, оценивающему составной продукт. Затем орган по оценке со­
ставного продукта предпринимает соответствующие шаги вместе с органом по оценке базовых компо­
нентов, например, потребовать переоценку или переоценивание базового компонента.
128
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
В случае, если весь составной продукт представлен как цепочка составных про­
дуктов, построенных друг над другом (например, сам базовый компонент уже является
составным продуктом), необходим аспект обоснованности и актуальности каждого от­
чета для составной оценки и отчет органа оценки, используемый в этой цепочке со­
ставных продуктов. Кроме того, при повторном использовании результатов в составной
оценке всего составного продукта учитываются все зависимости от отчета для состав­
ной оценки низкого уровня до отчета для составной оценки высокого уровня.
Примечание - В отчете органа по оценке продукта декларируется принятие оценки про­
дукта и ее результатов соответствующим органом по оценке (т.е. дается принятие соответствующего
технического отчета об оценке органом по оценке). В частности, в таком отчете декларируется, что
оценка продукта проводилась в соответствии с ИСО/МЭК 15408.
Достоверность, действительность и актуальность отчета о базовом компоненте
органа по оценке базового компонента и отчета для составной оценки для текущего со­
ставного продукта и его составной оценки подтверждаются отчетом органа по оценке
составного продукта для составного продукта. Сюда входит включает определение и
принятие эквивалентности отдельных компонентов доверия (и, следовательно, уров­
ней доверия), принадлежащих разным версиям ИСО/МЭК 15408 и 18405, если оценка
базового компонента была выполнена в соответствии с версией ИСО/МЭК 15408 и
18045, отличной от версии для текущей составной оценки.
Орган по оценке составного продукта выдает отчет по составному продукту, ес­
ли:
- окончательное общее заключение по составной оценке в отчете составного
продукта положительно;
- достоверность, обоснованность и актуальность отчета по базовому компоненту
органа по оценке базового компонента и отчета для составной оценки подтверждены
для настоящего составного продукта и его составной оценки органом по оценке со­
ставного продукта.
14.4 Требования к оценке с использованием методов составления
14.4.1 Повторное использование результатов оценки
При составлении компонентов ИТ-продукта возможно, что отдельные компонен­
ты продукта уже были оценены, и поэтому уже существующие результаты оценки для
таких компонентов могут быть использованы повторно. Однако обычно требуются до­
полнительные действия по оценке, которые проводятся для подтверждения доверия к
безопасности всего ИТ-продукта.
129
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Для повторного использования результатов оценки и свидетельств, относящихся
к таким компонентам продукта ИТ (ОО), требуется их доступность для оценки всего
продукта ИТ (ОО).
В п. 14.3.2 и 14.3.3 рассматриваются методы оценки для модели многоуровнево­
го составления. В п. 14.3.2 дано описание применения класса АСО, определенного в
ИСО/МЭК 15408-3 для составных ОО, а в п. 14.3.3 метод оценки составных продуктов.
Повторное использование результатов оценки и свидетельств компонентов про­
дукта ИТ (ОО) зависит от следующего:
- модели состава, используемой для продукта ИТ (ОО);
- доверия к безопасности, которое должно быть заявлено для всего продукта ИТ
(ОО), в частности, в отношении его компонентов и их доверия к безопасности;
- свойств безопасности, заявленных для ИТ-продукта (ОО) и его компонентов.
Примерами свойств безопасности являются разграничение, управление инфор­
мационным потоком и отказоустойчивость.
14.4.2 Проблемы оценки композиции
14.4.2.1 Обоснование состава
При составлении ИТ-продукта (ОО) из компонентов с использованием модели
состава, как описано в подразделе 14.2 и с использованием методов составления для
его оценки, для оценки продукта ИТ должно быть предоставлено обоснование состава
(например, в ЗБ композиционного/составного продукта). Это включает анализ как ми­
нимум:
- модели состава, используемой для продукта ИТ (ОО);
- доверия к безопасности, которое должно быть заявлено для всего ОО, в част­
ности, в отношении его компонентов и их доверия к безопасности;
- интерфейсов, зависимостей компонентов и их функциональности;
- возможности комбинирования политик функций безопасности и организацион­
ных политик безопасности компонентов;
- сохранения защитных свойств компонентов;
- для модели встроенной композиции аспектов корректности.
14.4.2.2 Анализ уязвимостей
Продукт ИТ, составленный из компонентов с использованием модели состава,
как описано в подразделе 14.2, и методов составления для его оценки, должен пройти
анализ уязвимостей в соответствии с классом AVA, указанным в ИСО/МЭК 15408-3, с
учетом предлагаемого уровня доверия к оценке для ИТ. Несмотря на то, что можно по130
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
вторно использовать результаты анализа уязвимостей из компонентов, необходимо
разработать и выполнить дополнительные действия по анализу уязвимостей для всего
продукта ИТ (ОО).
Анализ уязвимостей должен быть разработан с учетом анализа продукта ИТ с
его компонентами.
14.4.2.3 Тестирование
Продукт ИТ, составленный из компонентов с использованием модели состава,
описанной в 14.2, и методов составления для его оценки, должен пройти дополнитель­
ное тестирование с использованием класса АТЕ, указанного в ИСО/МЭК 15408-3. Хотя
можно повторно использовать результаты оценки тестирования компонентов, необхо­
димо разработать и провести дополнительные тесты для всего продукта ИТ (ОО).
Тестирование должно разрабатываться с учетом анализа продукта ИТ и его ком­
понентов.
14.4.2.4 Использование класса АСО для составных ОО
В ИСО/МЭК 15408-3 дано описание класса АСО, который обеспечивает компо­
ненты доверия к безопасности, предназначенные для использования при оценке со­
ставных ОО.
В ИСО/МЭК 15408-5 предоставлено семейство предопределенных пакетов дове­
рия для составных ОО (составные пакеты доверия (СПД)), которые уравновешивают
полученный уровень доверия со стоимостью и осуществимостью получения такого до­
верия для составных ОО.
Составные пакеты доверия предназначены для обеспечения доверия к тому, что
составление была выполнено корректно, с указанной строгостью и с учетом предло­
женного уровня доверия к оценке для составного ИТ-продукта.
14.4.2.5 Использование метода составной оценки для составных изделий
В ИСО/МЭК 15408-3 содержится описание семейства СОМР в различных клас­
сах доверия, которые предоставляют компоненты доверия, предназначенные для ис­
пользования при поддержке оценки составных продуктов. Эти семейства СОМР созда­
ны как семейства доверия, которые надлежащим образом дополняют другие уже суще­
ствующие семейства доверия, определенные в ИСО/МЭК 15408-3, для решения спе­
цифических для составных частей аспектов и проблем оценки.
Семейства СОМР разработаны для обеспечения доверия к тому, что составле­
ние было выполнено корректно, с указанной строгостью и с учетом предлагаемого
уровня доверия к оценке составного продукта.
131
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Для использования метода составной оценки для оценки составного продукта
требуется уже оцененный базовый компонент, сопровождаемый соответствующим от­
четом для составной оценки и действующим отчетом центра оценки базовых компо­
нентов.
14.5 Оценка композиции и многоуровневая оценка доверия
Понятия композиции и многоуровневого доверия предназначены на решение
разных задач. Таким образом, составные и композиционные оценки относятся к про­
цессам оценки, которые особенно подходят для многосубъектных ОО и позволяют по­
вторно использовать результаты предыдущих оценок, в то время как многоуровневое
доверие относится к свойству некоторых ОО в контексте конкретной проблемы без­
опасности и среды функционирования.
Оценка по составу относится к ОО с цепочкой поставок и/или интеграции, кото­
рая потенциально включает несколько сторон, где каждая сторона берет на себя оцен­
ку функции безопасности, которую они разрабатывают. Серия ИСО/МЭК 15408 стан­
дартизирует два подхода к повторному использованию результатов оценки в процессе
оценки:
а) составная оценка позволяет получить составной уровень доверия для ОО из
отдельных уровней доверия его взаимодействующих под-ОО;
Ь) составная оценка позволяет получить оценочный уровень доверия для много­
уровневого ОО поэтапно, когда сначала оценивается базовый уровень, а затем оцени­
ваются интегрированные зависимый и базовый уровни путем повторного использова­
ния результатов оценки базового уровня.
Многоуровневая оценка доверия ориентирована на ОО, где разные потребности
в доверии применяются для разных частей функций безопасности (под-ФБО), обеспе­
чивая при этом глобальный уровень доверия для всего ОО. До введения многоуровне­
вого доверия такие потребности вынуждали бы спонсора провести несколько оценок
одного и того же ОО для разных ЗБ. Используя эту концепцию, серия ИСО/МЭК 15408
стандартизирует и оптимизирует этот процесс.
С точки зрения ОО/ФБО многоуровневая оценка доверия относится к любой ар­
хитектуре, тогда как оценка по составу относится к конкретным архитектурам: состав­
ная оценка относится к ОО, который состоит из нескольких взаимодействующих под-
ОО, а составная оценка относится к ОО, где зависимый уровень опирается на базовый
уровень.
132
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
С точки зрения ОО/ФБО многоуровневая оценка доверия относится к любой ар­
хитектуре, тогда как оценка по составу относится к конкретным архитектурам: состав­
ная оценка относится к ОО, который состоит из нескольких взаимодействующих под-
ОО, а композиционная оценка относится к ОО, где зависимый уровень опирается на
базовый уровень.
На практике многоуровневая оценка доверия и оценка композиции могут исполь­
зоваться вместе при оценке.
133
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Приложение А
(обязательное)
Спецификация пакетов
А.1 Цель и структура данного приложения
Цель этого приложения - предоставить дополнительную информацию о специ­
фикации пакетов.
Примечание - ИСО/МЭК 15408-3
не дает определение критериев оценки
пакетов,
поскольку пакеты не оцениваются в отдельности. Оценка пакетов подразумевается после того, как пакет
включен в ПЗ, ПЗ-модуль или ЗБ.
А.2 Семейства пакетов
А.2.1 Общие положения
На рисунке А.1 представлена структура семейства пакетов. Ниже рассматрива­
ется каждая ее часть.
А.2.2 Имя семейства пакетов
Пакеты со связанными с ними целями представлены как семейство пакетов. В
этом случае имя семейства пакетов является обязательным, и спонсор семейства па­
кетов старается присвоить ему уникальное имя.
А.2.3 Обзор семейства пакетов
Пакеты, представленные как семейство, содержат раздел, с обзором семейства,
описывающим семейство на высоком уровне.
А.2.4 Цели семейства пакетов
В разделе "Цели" семейства пакетов представлено назначение семейства.
А.2.5 Пакеты
Как описано ниже, в семейство пакетов включены один или несколько пакетов.
Пакеты ТДБ и пакеты ФТБ не смешиваются в одном и том же семействе пакетов.
А.З Пакеты
А.3.1 Обязательное содержимое пакета
А.3.1.1 Идентификация пакета
Идентификация пакета включает:
а) имя пакета. Имя предоставляет уникальную описательную информацию о
предназначении пакета;
134
Ь)
информацию о версии пакета;
с)
дату последнего обновления;
d)
спонсора;
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
ссылку на используемую редакцию серии ИСО/МЭК 15408.
е)
Пакет также может иметь краткое имя.
Семейство пакетов (доверия)
Семейство пакетов (функциональный)
Имя семейства пакетов
Имя семейства пакетов
Обзор семейства пакетов
Обзор семейства пакетов
Цели семейства пакетов
Цели семейства пакетов
Функциональные пакеты
Пакет доверия
Тип пакета
Тип пакета
Обзор пакета
Обзор пакета
ТГпрёдёленйё проблемь””]
1.--- 6e3004CEQGTM. - - - - J
•
Цели безопасности
Замечания по применению
Замечания по применению
Компоненты доверия к
безопасности
Функциональные
компоненты безопасности
Идентификация
методов/действий
по оценке
Идентификация
методов/действий
по оценке
Идентификация
компонентов
доверия
Идентификация
функциональных
компонентов
■
•
■
• ” б п редел ё н ия”рас шире иных” "
■
компонентов
!
• ”бп редел ё н ия”ра с шй рё иных” "
■
компонентов
!
Обоснование компонента
Обоснование компонента
Рисунок А.1 - Структура семейства пакетов доверия или функциональных пакетов
135
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Оценочный уровень доверия также обозначается как “ОУД 1”.
Примечание - Для
пакетов,
определенных
в
ИСО/МЭК
15408-5,
пункты
Ь)
-
е)
подразумеваются в информации о редакции ИСО/МЭК 15408-5.
А.3.1.2 Тип пакета
Пакеты идентифицируются как один из следующих типов:
а) функциональный пакет; или
Ь) пакет доверия.
А.3.1.3 Обзор пакетов
Пакеты содержат раздел, дающий общий обзор и назначение пакета.
А.3.1.4 Примечания по применению
Примечания по применению не являются обязательными за следующими исклю­
чениями:
- для функциональных пакетов любые дополнительные требования аудита и
управления, относящиеся к ФТБ, включенным в пакет, должны быть указаны в разделе
примечаний по применению;
- функциональные пакеты могут зависеть от других функциональных пакетов.
Такие зависимости должны быть документированы в функциональном пакете, а также
могут быть документированы в ПЗ, ПЗ-модуле или ЗБ.
Функциональные пакеты могут также определять компоненты, зависимости кото­
рых не удовлетворяются пакетом, но, как предполагается, удовлетворяются другим па­
кетом, ПЗ, ПЗ-модулем или ЗБ, который использует пакет.
Пакет, который содержит спецификацию протокола (например, TLS), где в пакете
указаны компоненты ФТБ более высокого уровня, а примитивы не указаны.
В этом случае необязательный список зависимых компонентов может быть
предоставлен в разделе «Примечания к публикации» функционального пакета и может
включать
дополнительную
информацию,
такую
как любые
требуемые
выбор-
ки/назначения для этих ФТБ.
Примечание - К пользователям пакетов относятся разработчики ПЗ, ПЗ-модулей, других
пакетов и ЗБ, интеграторы и оценщики.
А.3.1.5 Компоненты (ФТБ или ТДБ)
Приведены требования безопасности, входящие в пакет. В данном пункте также
приводится обоснование выбора требований.
136
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Требования безопасности могут быть основаны на выборе. См. 8.2.4.2. В функ­
циональных пакетах также могут быть указаны необязательные функциональные тре­
бования безопасности (а также, если требуется, поддерживающие элементы ОПБ и
цели).
А.3.2 Необязательное содержимое пакета
А.3.2.1 Определение проблемы безопасности (функциональные пакеты)
В пакетах доверия этот раздел отсутствует. Он может быть включен в функцио­
нальные пакеты.
В этот раздел включены любые элементы ОПБ, описывающие проблему без­
опасности, которая решается функциональным пакетом. В него могут быть определены
элементы ОПБ, связанные с необязательными ФТБ. Для идентификации целей без­
опасности (если это возможно) должны использоваться примечания по применению и
ФТБ, с которыми связаны необязательные элементы ОПБ.
А.3.2.2 Цели безопасности (функциональные пакеты)
Пакеты доверия не должны содержать этот раздел. Он может быть включен в
функциональные пакеты.
В функциональный пакет, используемый для прямого обоснования ПЗ/ПЗмодулей/ЗБ, цели безопасности ОО не должны включаться.
В разделе «Цели безопасности» функционального пакета представлены все до­
полнительные цели безопасности ОО или задачи безопасности для среды функциони­
рования, полученные из ОПБ. В этом разделе могут быть определены цели безопасно­
сти для ОО, связанные с необязательными ФТБ. Для идентификации элементов ОПБ и
ФТБ должны использоваться примечания по применению, с которыми связаны допол­
нительные цели безопасности.
А.3.2.3 Примечания по применению
Включение в пакет примечаний по применению необязательно. См. А.3.1.4.
Раздел примечаний к приложению может также содержать информацию, пред­
ставляющую особый интерес для пользователей пакета. Она носит неформальный ха­
рактер и включает, например, предупреждения об ограничениях использования и об­
ластях, требующих особого внимания.
А.3.2.4 Расширенные определения компонентов
Пакет может содержать расширенные компоненты. В этом случае пакеты содер­
жат раздел с расширенными определениями компонентов.
137
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Пакеты могут включать методы оценки/оценочные действия, которые были за­
имствованы из ИСО/МЭК 18045. Если включены методы оценки/оценочные действия
включены, включены в раздел требований безопасности пакета должны быть заявле­
ние или заявления о соответствии. (См. 9.4). Методы оценки/оценочные действия
оценки могут быть представлены либо в документе пакета, либо могут содержать
ссылки на внешние документы.
138
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Приложение В
(обязательное)
Спецификация профилей защиты
В.1 Цель и структура данного приложения
Целью данного приложения является краткое изложение структуры и ожидаемо­
го содержания ПЗ.
Примечания
1 Данное приложение не определяет требований к оценке ПЗ. Критерии оценки ПЗ содержатся в
классе АРЕ, приведенном в ИСО/МЭК 15408-3.
2 В данном приложении не приводятся требования к спецификации ПЗ-конфигураций и ПЗ-
модулей. Они находятся в Приложении С.
Это приложение состоит из следующих основных частей:
а) спецификация ПЗ.
Оно кратко изложено в В.2. и включает:
- как пользоваться ПЗ;
- ограничения по использованию ПЗ.
Ь) что должен содержать ПЗ;
Все это кратко изложено в В.З и более подробно описано в В.3.2 - В.3.7, где опи­
сывается обязательное содержание ПЗ, взаимосвязи между этим содержанием и при­
водятся примеры.
с) заявление о соответствии стандартам;
В В.4 дано описание, каким образом автор ПЗ может заявить, что ОО должен со­
ответствовать определенному стандарту.
d) прямое обоснование ПЗ.
ПЗ с прямым обоснованием - это ПЗ, в которых угрозы и политика безопасности
организации в ОПБ переносятся непосредственно на ФТБ и, возможно, на цели без­
опасности для среды функционирования. Они подробно изложены в В.5.
В.2 Спецификация ПЗ
В.2.1 Как пользоваться ПЗ
ПЗ обычно является заявлением о потребностях, когда сообщество пользовате­
лей, регулирующий орган или группа разработчиков определяют общий набор требо­
ваний безопасности. ПЗ дает потребителям возможность обратиться к этому набору и
облегчает будущую оценку этих потребностей.
Поэтому ПЗ обычно используется как:
139
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
- часть спецификации требований для конкретного потребителя или группы по­
требителей, которые будут рассматривать возможность покупки определенного типа
ИТ-продукта только в том случае, если он соответствует ПЗ;
- часть постановления конкретного регулирующего органа, который разрешает
использование определенного типа ИТ-продукта только в том случае, если он соответ­
ствует ПЗ;
- для решения общей проблемы безопасности, представляемой множеством по­
требителей и часто определяемой группой, состоящей из нескольких разработчиков
ИТ-продуктов, которые затем производят ИТ-продукты этого типа для удовлетворения
потребностей своего общего рынка, хотя это не исключает возможности других приме­
нений
В.2.2 Ограничения по использованию ПЗ
Две из многих ролей, которые ПЗ не выполняет, это:
- полная спецификация;
ПЗ разработан как спецификация безопасности, а не как общая спецификация.
Не будучи связаны с безопасностью, таким свойствам, как совместимость, физический
размер и вес, требуемое напряжение и т.д., не следует быть частью ПЗ. Это означает,
что в целом ПЗ является только частью полной спецификации.
- спецификация отдельного продукта.
В отличие от ЗБ, ПЗ предназначен для описания определенного типа ИТ-
продукта, а не отдельного продукта. Когда описывается только один продукт, для этой
цели лучше использовать ЗБ.
В.З Обязательное содержимое ПЗ
В.3.1 Общие положения
Существуют два типа ПЗ. Во-первых, «обычный» ПЗ, который представляет со­
бой ПЗ, который включает в себя полное содержание, как описано в п. В.3.2 - В.3.7. Вовторых, в некоторых случаях разработчик ПЗ может составить ПЗ с прямым обоснова­
нием, которое имеет другое содержание по сравнению с ПЗ, которые содержат цели
безопасности для ОО. ПЗ с прямым обоснованием, а также причины и обстоятельства,
в которых они используются, подробно описаны в части В.5. Все остальные части этого
приложения предполагают ПЗ с полным содержанием.
На рисунке В.1 показано содержание ПЗ, приведенного в ИСО/МЭК 15408-3. Ри­
сунок В.1 может также использоваться в качестве структурной схемы ПЗ, хотя допу­
стимы альтернативные конфигурации. Например, если обоснование требований без140
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
опасности является особенно громоздким, его можно было бы включить в приложение
ПЗ, а не в раздел требований безопасности. Отдельные разделы ПЗ и содержание
этих разделов кратко излагаются ниже и объясняются более подробно в п. В.3.2 - В.3.7.
Профиль защиты
Введение в ПЗ
Соответствие
Определение проблемы
безопасности
Цели безопасности
Определение расширенных
компонентов
Требования доверия
Ссылка на ПЗ
Обзор ПЗ
Утверждения о соответствии:
Требование стандарта (Ссылка на
применяемые ИСО/МЭК 15408 и ИСО/
МЭК 18045 стандарты, ИСО/МЭК
15408-2, ИСО/МЭК 15408-3
(соответствующий/расширенный))
Требование(я) ПЗ
Требование(я) пакета
Обоснование утверждений о
соответствии
Изложение соответствия:
Ссылка(и) на методы/действия по
оценке
Типы соответствия для ПЗ и ЗБ,
полученных из ПЗ
Утверждение "разрешено совместно
применять"
Угрозы
Политика безопасности организации
Допущения
Цели безопасности для ОО
Цели безопасности для среды
функционирования
Обоснование целей безопасности
Определение расширенных
компонентов
Функциональные требования
безопасности
Требования доверия к безопасности
Обоснование требований доверия
Дополнительно (опционально):
методы/действия по оценке
Рисунок В.1 - Содержание профиля защиты
141
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
ПЗ содержит:
введение в ПЗ, содержащее ссылку на ПЗ и повествовательное описание типа
ОО;
Ь) заявления о соответствии, показывающие:
- какая редакция соответствующих частей серии ИСО/МЭК 15408 применима;
- соответствие ИСО/МЭК 15408-2 и ИСО/МЭК 15408-3 (соответствующее или
расширенное);
- заявляет ли ПЗ о соответствии каким-либо другим ПЗ и/или пакетам, и если со­
ответствует, то каким именно и тип заявленного соответствия.
с) утверждение о соответствии, содержащее:
- ссылку на любой метод (ы) оценки и/или оценочные действия, которые были
взяты из ИСО/МЭК 18045;
Примечание - В ПЗ или в сопутствующий вспомогательный документ может быть
дополнительно включена подробная информация о любых методах оценки/оценочных действиях.
- в случае точного соответствия, заявление с указанием ПЗ и ПЗ- модулей, кото­
рые могут использоваться вместе с ПЗ, появляется в этом разделе ПЗ.
-
требуемый тип соответствия ЗБ и других производных от него ПЗ.
с) определение проблемы безопасности с указанием угроз, ПБОр и предположе­
ний;
d) цели безопасности, показывающие, как решение проблемы безопасности раз­
деляется между целями безопасности для среды функционирования и, необязательно,
целями безопасности для ОО;
е) определение(я) расширенных компонентов, где могут быть определены новые
компоненты (т.е. те, которые не включены в ИСО/МЭК И 15408-2 или ИСО/МЭК 15408­
3). Эти новые компоненты необходимы для определения расширенных функциональ­
ных требований и требований расширенного доверия;
f) требования безопасности, в которых предоставляется перевод целей безопас­
ности для ОО на стандартизованный язык. Этот стандартизированный язык представ­
лен в форме ФТБ. Кроме того, этот раздел ПЗ определяет ТДБ;
В.3.2 Введение в ПЗ (APE_INT)
В.3.2.1 Общие положения
Введение в ПЗ излагает ОО в повествовательной форме на двух уровнях аб­
стракции:
а) ссылку на ПЗ, которая обеспечивает идентификационный материал для ПЗ;
142
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Ь) обзор ОО, в котором кратко описывается ОО.
В.3.2.2 Ссылка на ПЗ
ПЗ содержит четкую ссылку, которая идентифицирует этот конкретный ПЗ. Ти­
пичная ссылка на ПЗ состоит из названия, версии, спонсоров и даты публикации.
Примечание - Здесь проводится различие между спонсором ПЗ, то есть организацией,
ответственной за ее разработку, и разработчиком ПЗ, который является субъектом, ответственным за ее
производство.
Ссылка должна быть уникальной, чтобы можно было отличить разные ПЗ и раз­
ные версии одного и того же ПЗ. Ссылка ПЗ облегчает индексацию и ссылки на ПЗ и
его включение в каталоги ПЗ.
В.3.2.3 Обзор ПЗ
В. 3.2.3.1 Общие положения
Обзор ПЗ ориентирован на потенциальных потребителей определенного типа
ОО, которые просматривают каталоги ПЗ, могущие удовлетворить спецификациям их
потребностей в безопасности.
Обзор ПЗ также предназначен для разработчиков, которые могут использовать
ПЗ при разработке ОО или адаптации существующих продуктов.
Типичный объем обзора ПЗ составляет несколько абзацев.
С этой целью в обзоре ПЗ содержится краткое описание использования ОО и его
основных функций безопасности, идентификации типа ОО и идентификации любого
основного
не
относящегося
к
ОО
аппаратного/программного
обеспече-
ния/микропрограммного обеспечения, доступного для ОО.
В.3.2.3.2 Использование и основные функции безопасности типа ОО
Описание использования и основных функций безопасности типа ОО предназна­
чено для того, чтобы дать очень общее представление о том, на что способен ОО и
для чего он может использоваться. Этот раздел предназначен для разработчиков ПЗ,
разработчиков ОО или потенциальных потребителей ОО и описывает использование
типов ОО и основных функций безопасности с точки зрения бизнес-операций с исполь­
зованием языка, понятного потребителям ОО.
В. 3.2.3.3 Тип ОО
В обзоре ОО идентифицируется общий тип ОО, к которому обращается ПЗ, та­
кой как: межсетевой экран, смарт-карта, интрасеть, веб-сервер, база данных, веб­
сервер, мобильное устройство и база данных и т.д. Определение типа ОО часто вклю­
чает характеристику границ программного и аппаратного обеспечения ОО.
143
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Этот пример описания типа ОО взят из профиля защиты ИС безопасности:
«Объект оценки (ОО) - это интегральная схема безопасности (ИС безопасности), кото­
рая состоит из блока обработки, компонентов безопасности, портов ввода-вывода (кон­
такт, бесконтактные или аналоговые интерфейсы, такие как USB, ММС), а также энер­
гозависимую и энергонезависимую память (оборудование). ОО может также включать в
себя собственное специализированное программное обеспечение ИС разработчи-
ка/производителя ИС, если оно поставляется производителем ИС. Все другое про­
граммное обеспечение, работающее на ИС безопасности, называется встроенным про­
граммным обеспечением ИС безопасности и не является частью ОО».
В.3.2 .3.4 Доступное
аппаратное/программное
обеспечение/
микропро­
граммное обеспечение, не связанное с ОО
В то время как некоторые ОО не полагаются на другие ИТ, многие ОО, особенно
программные ОО, полагаются на дополнительное оборудование, программное обеспе­
чение и/или микропрограммное обеспечение, не связанные с ними. В последнем слу­
чае для идентификации аппаратного/программного обеспечения/микропрограмм, не
связанных с ОО, требуется обзор ПЗ.
Поскольку ПЗ написан не для конкретного продукта, во многих случаях можно
дать только общее представление о доступном оборудовании/программном обеспече-
нии/прошивке. В некоторых других случаях может быть предоставлена более конкрет­
ная информация.
Примером, где предоставляется более конкретная информация, может быть
спецификация требований для конкретного потребителя, платформа которого уже из­
вестна.
Примеры идентификации оборудования/программного обеспечения/прошивки
включают:
- отсутствует (для полностью автономного ОО);
- стандартный ПК с двухъядерным процессором с тактовой частотой 2,10 ГГц
или выше и оперативной памятью 4 ГБ или более, работающий под управлением опе­
рационной системы Yaiza для профессионалов, версии 53.0, обновления 6Ь, с или 7,
или версии 54.0;
- стандартный 64-разрядный сервер с двумя четырехъядерными процессорами и
16 ГБ или более ОЗУ, работающий под управлением операционной системы Yaiza,
серверной версии 7.0 с обновлением 6d и графической карты WonderMagic 12.0 с 1.01
набором драйверов WM;
144
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
- микросхема CleverCard SB17067;
- интегральная схема CleverCard SB17067 под управлением операционной си­
стемы смарт-карт QuickOS версии 12.0;
- мобильная ОС Yaiza 3.1.6 на смартфонах и планшетах с процессором FP9.
В.3.3
Заявления о соответствии и утверждение о соответствии (APE_CCL)
В.3.3.1 Общие положения
В разделе заявлений о соответствии ПЗ дано описание, как ПЗ:
- указывает применимую редакцию соответствующих частей серии ИСО/МЭК
15408;
- соответствует ИСО/МЭК 15408-2 и ИСО/МЭК 15408-3 (т.е. соответствует или
расширен);
-
заявляет другие ПЗ (при их наличии);
-
заявляет пакеты (при их наличии);
Описание того, как ПЗ соответствует серии ИСО/МЭК 15408, состоит из двух
пунктов: используемая редакция соответствующей части серии ИСО/МЭК 15408 и то,
содержит ли ПЗ расширенные требования безопасности (см. 10.3 и D.3.6).
Описание соответствия, заявленное ПЗ другим ПЗ, означает, что ПЗ перечисля­
ет любые другие ПЗ, соответствие которым заявлено. Также указывается тип заявлен­
ного соответствия. Для объяснения этого см. 10.3.
Описание соответствия ПЗ пакетам означает, что в ПЗ перечислены пакеты, со­
ответствие которым заявлено. Для объяснения этого см. 10.3.
Примечания
1 Использование заявлений о соответствии в ПЗ-модулях см. в С.2.2.5.
2 Использование заявлений о соответствии в прямом обосновании ПЗ см. в В.5.2.
В разделе заявлений о соответствии ПЗ дано описание, как ПЗ:
- ссылается на любой метод (ы) оценки и/или оценочные действия, производные
от ИСО/МЭК 18405;
- может использоваться совместно с другими ПЗ и ПЗ-модулями в ПЗконфигурации. В случае точного соответствия требуется утверждение о соответствии.
В заявлении о соответствии ссылки на методы оценки/оценочные действия
означают, что ПЗ предоставляет ссылки на метод (ы) оценки и/или оценочные дей­
ствия (МО/ОД), которые будут использоваться во время оценки на основе ЗБ, заявля­
ющего о соответствии ПЗ. Эти методы оценки и оценочные действия могут быть вклю­
чены непосредственно в ПЗ или могут быть найдены в справочном сопроводительном
145
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
документе. Нет необходимости воспроизводить текст этих методов оценки и мероприя­
тий в ПЗ. См. 10.3.
Если для оценки ПЗ должны использоваться методы оценки/оценочные дей­
ствия, которые были взяты из ИСО/МЭК 18045, то они должны быть идентифицирова­
ны в соответствующем разделе требований безопасности путем включения утвержде­
ния в следующей форме:
«Этот ПЗ требует использования методов оценки/оценочных действий, опреде­
ленных в <ссылка (и)>».
В этом утверждении <reference> заменяется указанием местонахождения соот­
ветствующих методов оценки и оценочных действий. Эта ссылка может относиться к
документу, содержащему ПЗ, или к одному или нескольким отдельным документам.
Примечание - Как указано в 13.5, в некоторых случаях схемы оценки не всегда
подтверждают использование конкретных МО/ОД.
Тип соответствия в ПЗ указывает, как ЗБ и/или другие ПЗ должны соответство­
вать данному ПЗ. Разработчик ПЗ выбирает, требуется ли «точное», «строгое» или
«доказуемое» соответствие.
В.3.3.2 Точное соответствие
При выборе точного соответствия разработчик ПЗ должен, где применимо, ука­
зать следующую информацию в разрешенном заявлении в разделе заявлений о соот­
ветствии ПЗ:
- другие ПЗ, которые могут использоваться либо ЗБ на основе этого ПЗ, либо ис­
пользоваться в ПЗ-конфигурации с этим ПЗ;
- ПЗ-модули, которые могут указывать этот ПЗ в базе этого ПЗ-модуля, или кото­
рые могут присутствовать в ПЗ-конфигурации, которая также включает ПЗ.
Примечания
1 Если ни один из вышеперечисленных вариантов не используется, то ЗБ может самостоятельно
заявлять о точном соответствии только ПЗ.
2
ПЗ не может претендовать на точное соответствие другому ПЗ.
В.3.4
Определение проблемы безопасности (АРЕ_ОПБ)
Информацию и требования к ОПБ, включая угрозы, предположения и политики
безопасности организации (ПБОр), см. в 7.1
В.3.5
Цели безопасности (APE_OBJ)
Информацию и требования к целям безопасности, включая цели безопасности
для ОО и цели безопасности для среды функционирования, см. в 7.2.
146
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Примечание - В случае с прямым обоснованием
цели безопасности для
ОО не
включаются.
В.3.6
Определение расширенных компонентов (APE_ECD)
Во многих случаях требования безопасности в ПЗ основаны на компонентах,
приведенных в ИСО/МЭК 15408-2 или ИСО/МЭК 15408-3 (см. В.3.7). Однако в некото­
рых случаях в ПЗ могут быть требования, не основанные на компонентах в ИСО/МЭК И
15408-2 или ИСО/МЭК 15408-3. В этих случаях должны быть определены новые ком­
поненты, то есть расширенные компоненты, и их определение должно быть дано в
разделе «Определение расширенных компонентов». Дополнительную информацию см.
в 8.4.
Примечание - Этот
раздел
предназначен
для
содержания
только
расширенных
компонентов, а не расширенных требований, которые основаны на расширенных компонентах.
Расширенные требования включены в раздел требований безопасности, как описано в В.3.7, и затем для
всех целей обрабатываются идентично требованиям, основанным на компонентах, приведенных в
ИСО/МЭК 15408-2 или ИСО/МЭК 15408-3.
В.3.7
Требования безопасности (APE_REQ)
В.3.7.1 Общие положения
Требования безопасности состоят из двух групп требований:
а) функциональные требования безопасности (ФТБ): перевод целей безопасно­
сти для ОО на стандартизованный язык;
Ь) требования доверия к безопасности (ТДБ): описание того, как можно получить
уверенность в том, что ОО соответствует требованиям ФТБ.
Эти две группы рассматриваются в 7.3.
В.3.7.2 Включение требований в ПЗ
Для ПЗ со строгим соответствием другому ПЗ должны быть включены все требо­
вания этого ПЗ, а дополнительные требования могут быть включены в соответствую­
щий ПЗ.
Для ПЗ с доказуемым соответствием другому ПЗ должны быть включены все
требования этого ПЗ, или в соответствующем ПЗ должно быть дано обоснование, объ­
ясняющее, как они выполняются иным образом.
В ПЗ всех видов соответствия (точное, строгое и доказуемое) могут быть вклю­
чены следующие типы дискреционных требований:
Если ПЗ содержит необязательные требования, ПЗ с соответствием может реа­
лизовать эти требования, обязательно включив любые требуемые элементы ОПБ, свя­
занные с этими требованиями. Это может быть сделано независимо от соответствия
147
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
требованиям ПЗ. Исключение дополнительных ФТБ не является «частичным соответ­
ствием» ПЗ и, следовательно, разрешен.
В.4 Ссылка на другие стандарты в ПЗ
В некоторых случаях разработчику ПЗ необходимо сослаться на внешний стан­
дарт, такой как конкретный стандарт или протокол. Серия ИСО/МЭК 15408 позволяет
сделать это двумя способами:
а) в качестве политики безопасности организации (или ее части);
Существует национальный стандарт, определяющий, как следует выбирать па­
роли, и это может быть указано в ПЗ как политика безопасности организации. Это мо­
жет привести к цели для среды (например, если пользователям ОО необходимо вы­
брать пароли соответствующим образом), или это может привести к целям безопасно­
сти для ОО, а затем к соответствующим ФТБ (вероятно, класса FIA), если пароли гене­
рируются ОО. В обоих случаях обоснование разработчика ПЗ должно сделать правдо­
подобным пригодность целей безопасности для ОО и ФТБ для выполнения ОПБ.
Оценщик проверит, действительно ли это правдоподобно (и для этого может принять
решение изучить стандарт), реализуется ли ОПБ с помощью ФТБ, как объяснено ниже.
Ь) в качестве технического стандарта, используемого при уточнении компонента
или требования безопасности;
Если требуется ссылка только на определенную часть стандарта, эта часть
должна быть однозначно указана в уточнении ФТБ.
Примечание - Напоминаем разработчику ПЗ, что ссылка на стандарт в ФТБ может воз­
ложить значительную нагрузку на разработчика ОО, который соответствует ПЗ (в зависимости от разме­
ра и сложности стандарта и требуемого доверия), и что может быть более целесообразно, чтобы затре­
бовать альтернативные (не связанные с СС) способы оценки соответствия этому стандарту.
В.5 ПЗ с прямым обоснованием
В.5.1 Общие положения
При разработке ПЗ учитываются ЗБ, которые будут составлены с ПЗ в качестве
основы. Как отмечено в части D.4, в некоторых случаях желательно составить ПЗ, ко­
торый поддерживает спецификацию ЗБ с прямым обоснованием.
Целью ПЗ с прямым обоснованием является минимизация уровня косвенности
между ОПБ, любыми целями безопасности для среды функционирования и ФТБ.
В некоторых ситуациях уместно опустить определение целей безопасности ОО.
В этом случае ФТБ, дополненные описаниями на естественном языке, и цели для сре­
ды напрямую отображают ОПБ.
148
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
ПЗ с прямым обоснованием состоит из следующего:
а) введения ПЗ, состоящего из ссылки на ПЗ и обзора ОО;
Ь) заявления о соответствии;
с) целей безопасности для среды функционирования;
d) ФТБ и ТДБ (включая определение расширенных компонентов) и обоснование
требований безопасности (только если зависимости не удовлетворены).
Содержание ПЗ с прямым обоснованием показано на рисунке В.2.
149
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Профиль защиты
(Прямое обоснование)
Введение в ПЗ
Соответствия
Определение проблемы
безопасности
Цели безопасности
Определение расширенных
компонентов
Требования доверия
Ссылка на ПЗ
Обзор ПЗ
Утверждения о соответствии:
Требование стандарта (Ссылка на
применяемые ИСО/МЭК 15408 и ИСО/
МЭК 18045 стандарты, ИСО/МЭК 15408­
2, ИСО/МЭК 15408-3
(соответствующий/расширенный))
Тип соответствия (точный, строго
демонстрируемый)
Требования ПЗ (Только прямое
обоснование ПЗ)
Требование(я) пакета
Обоснование соответствия
Изложение соответствия:
Ссылки на методы/действия по оценке
Типы соответствия для ПЗ и ЗБ,
полученных из ПЗ
Утверждение "разрешено совместно
применять"
Угрозы
Политика безопасности организации
Предложения безопасности
Цели безопасности для среды
функционирования
Обоснование целей безопасности
Определение расширенных
компонентов
Функциональные требования
безопасности
Требования доверия к безопасности
Обоснование требований доверия
Дополнительно (опционально):
методы/действия по оценке
Рисунок В.2 - Содержание ПЗ с прямым обоснованием
В.5.2 Заявления о соответствии (APE_CCL) для ПЗ с прямым обоснованием
ПЗ с прямым обоснованием должен заявлять о соответствии только другому ПЗ
с прямым обоснованием.
В.5.3 Цели безопасности (APE_OBJ) для ПЗ с прямым обоснованием
150
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
ПЗ с прямым обоснованием имеет следующие отличия в отношении целей без­
опасности по сравнению с ПЗ, который содержит цели безопасности для ОО:
- не включены цели безопасности для ОО. По-прежнему должно быть описание
целей безопасности для среды функционирования;
- обоснование целей безопасности включено только для целей безопасности для
среды функционирования, поскольку в ПЗ отсутствуют цели безопасности ОО;
-
требования безопасности (APE_REQ) для ПЗ с прямым обоснованием
Включено обоснование требований безопасности, которое напрямую сопостав­
ляет ФТБ и любые цели безопасности для среды функционирования с элементами
ОПБ. Рекомендуется, чтобы эта часть обоснования требований безопасности распола­
галась непосредственно под каждой из угроз, ПБОр и предположений в разделе ОПБ.
Как и в обычных ПЗ, логическое обоснование требований безопасности также должно
обосновывать любые неудовлетворенные зависимости ФТБ; эта часть обоснования
обычно располагается после определения ФТБ.
В.6 Необязательное содержание ПЗ
ПЗ могут включать методы оценки/оценочные действия, основанные на стандар­
те ИСО/МЭК 18405. Методы оценки/оценочные действия, связанные с ПЗ, указаны в
разделе заявлений о соответствии ПЗ. См. раздел 10.3.
Если разработчик ПЗ решит включить в ПЗ какие-либо методы оценки и/или оце­
ночные действия, то они могут быть описаны либо в (отдельном) сопроводительном
документе, либо в разделе требований безопасности ПЗ вместе с соответствующим
требованием безопасности.
151
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Приложение С
(обязательное)
Спецификация ПЗ-модулей и ПЗ-конфигураций
С.1 Цель и структура данного приложения annex
Целью данного приложения является обобщение структуры и ожидаемое содер­
жание ПЗ-модулей и ПЗ-конфигураций.
Примечание - Это приложение не определяет требований к оценке ПЗ-конфигураций.
Критерии оценки ПЗ-конфигурации содержатся в классе АСЕ, приведенном в ИСО/МЭК 15408-3.
С.2 Спецификация ПЗ-модулей
С.2.1 Использование ПЗ-модулей
ПЗ-модулем является заявление о безопасности группы пользователей или раз­
работчиков, регулирующих органов, администрации или любого другого объекта, удо­
влетворяющего конкретным потребностям потребителей. ПЗ-модуль дополняет один
или несколько ПЗ и, по выбору, другие ПЗ-модули, которые называются «базой ПЗ-
модуля» данного ПЗ-модуля, и позволяет потребителям ссылаться на это утвержде­
ние, облегчает его оценку и сравнение соответствующих оцененных ОО. ПЗ-модуль
может использоваться только в ПЗ-конфигурации, которая включает эту ПЗ-модульную
базу.
Примечание - Базовый ПЗ - это ПЗ, который требуется для ПЗ-модуля. Базовый ПЗ-
модуль - это ПЗ-модуль, который вместе со своей базой ПЗ-модулем требуется другому ПЗ-модулю.
С.2.2 Обязательное содержание ПЗ-модуля
С.2.2.1 Общие положения
На рисунке С.1 представлено содержание ПЗ-модуля.
152
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
ПЗ-модуль
Ссылка на ПЗ-модуль
Введение в ПЗ-модуль
— Идентификация базы ПЗ ПЗ-модуля
Обзор 00
Обоснование согласованности
—
Обоснование
согласованности с
ПЗ-модулями базы
Утверждения о соответствии:
Требование стандарта (Ссылка на
применяемые ИСО/МЭК 15408 и ИСО/
МЭК 18045 стандарты, ИСО/МЭК 15408­
2, ИСО/МЭК 15408-3
(соответствующий/расширенный))
Тип соответствия (точный, строго
демонстрируемый)
Требование(я) пакета
Обоснование соответствия
Изложение соответствия:
Ссылка(и) на методы/действия по
оценке
Типы соответствия для ПЗ и ЗБ,
полученных из ПЗ
Утверждение "разрешено совместно
применять"
Соответствие
Определение проблемы
безопасности
Цели безопасности
Определение расширенных
компонентов
Требование безопасности
Угрозы
Политики безопасности организации
Допущения
Цели безопасности для 00
Цели безопасности для среды
функционирования
Обоснование целей безопасности
Определение расширенных
компонентов
Функциональные требования
безопасности
Требования доверия к безопасности
Обоснование требований доверия
Дополнительно (опционально):
методы/действия по оценке
Рисунок С.1 - Содержание ПЗ-модуля
Содержание
ПЗ-модуля
кратко
изложено
ниже
и
подробно
поясняется
в
п. С.2.2.2 - С.2.3. ПЗ-модуль содержит:
153
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
- введение, которое идентифицирует ПЗ-модуль, идентифицирует базу ПЗмодуля, на которой он основан, и предоставляет описание ОО в его среде, которое со­
ответствует описаниям, лежащим в основе базы ПЗ-модуля;
- обоснование непротиворечивости, которое устанавливает соответствие между
ПЗ-модулем и его базой;
- заявление о соответствии в отношении редакции стандартов серии ИСО/МЭК
15408, заявление о соответствии и, в случае точного соответствия, заявления о допу­
стимости;
- определение проблемы безопасности с угрозами, предположениями и полити­
ками безопасности организации;
- раздел целей безопасности, представляющий решение проблемы безопасно­
сти с точки зрения целей для ОО и его среды функционирования;
- определение необязательных расширенных функциональных компонентов, в
котором
представлены
новые функциональные компоненты,
не
включенные
в
ИСО/МЭК 15408-2;
раздел функциональных требований безопасности со стандартизированным из­
ложением целей безопасности ОО;
- раздел требований доверия к безопасности, за исключением точного соответ­
ствия, когда ТДБ наследуются от базовых ПЗ.
С.2.2.2 Введение в ПЗ-модуль
С.2.2.2.1 Ссылка на ПЗ-модуль
Введение в ПЗ-модуль дает четкую и недвусмысленную ссылку, которая позво­
ляет идентифицировать ПЗ-модуль. Типичная ссылка делается на название ПЗ-модуля
и версию документа, спонсоров и дату публикации.
Ссылку на ПЗ-модуль можно использовать для индексации документа в катало­
гах ПЗ.
С.2.2.2.2 Идентификация базы ПЗ-модуля
Во введении к ПЗ-модулю обозначена его база. Идентификация состоит из пе­
речня ссылок.
ПЗ-модуль, который требуется использовать с базой ПЗ-модуля, скажем {В1 ...,
Вп}, предоставит идентификационный список следующей формы:
Вг ... AND ... Bn with n > 1
С.2.2.3 Введение в ПЗ-модуль
С.2.2.3.1 Ссылка на ПЗ- модуль
154
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Данный набор ПЗ/ПЗ-модулей должен быть замкнутым, то есть для любого ПЗмодуля Bi его собственная База должна принадлежать набору {В1 ... Вп}.
Примечание - Это означает, что набор {В1 ..., Вп} либо не содержит какого-либо ПЗмодуля, либо содержит по крайней мере один ПЗ-модуль, для которого требуется только базовые ПЗ, но
никакой другой базовый ПЗ-модуль.
ПЗ-модуль может также допускать альтернативные наборы базового ПЗ-модуля,
например, {S1 ... Sk}; в этом случае в идентификационном списке указано:
... OR ... Sk with k > 1
Развернутой формой идентификации альтернативных комплектов Базы ПЗ-
модуля является:
(В± ... AND ... Bni) ... OR ... (В± ... AND ... Bnk)with k > 1 and ni > 1
Примечание - ПЗ-модуль, в котором указан список, составленный по OR, эквивалентен
количеству ПЗ-модулей, равному количеству элементов Si в списке.
То есть список, составленный по OR (ИЛИ) - это ярлык, позволяющий избежать
определения и поддержки аналогичных ПЗ-модулей для других целей.
С.2.2.3.2 Обзор ОО
Обзор ОО ПЗ-модуля может завершать обзоры ОО базы ПЗ-модуля при условии
согласованности между ПЗ-модулем и его базой;
- тип ОО ПЗ-модуля может быть или таким же, как у базы ПЗ-модуля, или может
иметь особенности, необходимые для соответствия назначению ПЗ-модуля;
- ПЗ-модуль может иметь дополнительные возможности использования и основ­
ные функции безопасности в дополнение к указанным в базе ПЗ-модуля;
- ПЗ-модуль может специфицировать конкретное оборудование, программное
обеспечение и/или микропрограммное обеспечение, не относящееся к ОО, в соответ­
ствии с заявлением в базе ПЗ-модуля.
В ПЗ-модуле возможность дополнить обзор ОО базы ПЗ-модуля имеет то же
значение, что и в ПЗ или ЗБ, которые дополняют обзор ОО другого ПЗ, соответствие
которому они заявляют.
Утверждение обзора ОО в ПЗ-модуле может быть дано ссылкой, если оно такое
же, как и в его базе ПЗ-модуля, т.е. при отсутствии добавления. ПЗ-модуль может
предоставить столько же конкретных обзоров ОО, сколько базы альтернативных ПЗмодулей.
С.2.2.4 Обоснование согласованности
ПЗ-модуль должен содержать логическое обоснование по отношению к его базе.
155
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Если в ПЗ-модуле указаны альтернативные базы ПЗ-модулей, то в ПЗ-модуле
должно быть указано количество обоснований согласованности, равное количеству
альтернативных баз ПЗ-модулей.
Анализ согласованности для каждой базы ПЗ-модуля должен выполняться по
типу ОО, ОПБ, целям и функциональным требованиям безопасности. В конечном итоге
цель состоит в том, чтобы продемонстрировать, что ОО может соответствовать описа­
ниям типов ОО, приведенным в базе ПЗ-модуля и в ПЗ-модуле, и удовлетворять всем
функциональным требованиям безопасности, указанным в ПЗ-модуле и его базе.
Обоснование согласованности должно демонстрировать, что объединение ОПБ, целей
и функциональных требований безопасности, определенных в ПЗ-модуле и его базе,
не приводит к противоречию.
Для обоснования согласованности можно использовать таблицы соответствия
между ОПБ/целями/ФТБ вместе с текстовыми обоснованиями.
С.2.2.5 Обоснование доверия
Обоснование доверия должно демонстрировать согласованность адаптируемого
набора ТДБ, который может быть унаследован от его базовых ПЗ, с ОПБ, определен­
ным в ПЗ-модуле. То есть требования доверия и модель угроз не противоречат друг
ДРУГУ.
Если ПЗ-Модуль не наследует свой набор ТДБ от своего базового ПЗ, то обос­
нование доверия должно демонстрировать, что требования доверия в ПЗ-Модуле и в
его Базе не противоречат друг другу в отношении общих активов, которые являются
общими для ПЗ-модуля и его базы.
С.2.2.6 Заявления о соответствии и утверждение о соответствии
С.2.2.6.1 Общие положения
Данный раздел ПЗ-модуля должен быть включен для всех ПЗ-модулей и содер­
жать описание, как ПЗ-модуль соответствует:
- ИСО/МЭК 15408-2, ИСО/МЭК 15408-3, их редакции и любому использованию
расширенных требований безопасности;
-
функциональным пакетам и пакетам доверия.
ПЗ-модуль не должен заявлять о соответствии какому-либо ПЗ, другому ПЗ-
модулю или ПЗ-конфигурации.
В заявлении о соответствии ПЗ-модуль указывается требуемый тип соответ­
ствия. Точное соответствие наследуется от базовых ПЗ и требует, чтобы все базы ПЗмодулей также имели точное соответствие. Заявление о соответствии ПЗ-модуля мо156
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
жет также определять любые методы оценки/оценочные действия оценки, которые
необходимо использовать с ним.
Если для оценки ПЗ-модуля должны использоваться методы оценки/оценочные
действия, которые были взяты из ИСО/МЭК 18045, то они должны быть идентифици­
рованы с соответствующим разделом требований безопасности, включая заявление в
следующей форме:
«Данный ПЗ-модуль требует использования методов оценки/оценочных дей­
ствий, определенных в <ссылка>».
Где <ссылка> заменяется указанием местонахождения методов оценки и оце­
ночных действий, связанных с ПЗ-модулем. Эта ссылка может относиться к документу,
содержащему пакет, или к одному или нескольким отдельным документам.
Примечание - Методы оценки/мероприятия по оценке могут быть включены либо в сам
модуль, либо включены путем ссылки на один или несколько отдельных документов, описывающих их.
С.2.2.6.2 Точное соответствие
В случае точного соответствия разрешенное заявление также включает иденти­
фикацию ПЗ-модулей и ПЗ-модулей, отличных от набора ПЗ-модулей базы ПЗ-модуля,
которым разрешено использоваться в ПЗ-конфигурациях с этим ПЗ-модулем.
Примечания
1 Все компоненты ПЗ-конфигурации, которая требует точного соответствия, также должны
требовать точного соответствия в своих утверждениях о соответствии.
2 Это поддерживает концепцию точного соответствия, которую разработчики ПЗ-модуля могут
контролировать то, какие другие требования могут быть указаны в сочетании с требованиями,
указанными в их ПЗ-модуле.
На рисунке С.2 показано, как заявления и утверждения о соответствии наследу­
ются в случае точного соответствия с единственным доверием.
157
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
ПЗ-модуль
Базовый ПЗ-модуль
Унаследованный
Утверждение пакетов
доверия
Изложения
соответствия
(точное)
Унаследованный
г
Утверждение пакетов
доверия
•
Изложения
соответствия
(точное)
Рисунок С.2 - Наследованные заявления и утверждения о соответствии для случая
точного соответствия
Примечание - При применении точного соответствия МО/ОД не могут быть определены в
ПЗ-конфигурации
(т.е.
используемые
МО/ОД
идентифицируются
только
в
ПЗ
и
ПЗ-модулях,
используемых в ПЗ-конфигурации).
С.2.2.7 Определение проблемы безопасности
В данном разделе определяется проблема безопасности,
решаемая ПЗ-
модулем. Он может содержать все типы элементов ОПБ, то есть предположения, угро­
зы и политики безопасности организации.
ПЗ-модуль определяет проблему безопасности во взаимосвязи с проблемой
безопасности базы ПЗ-модуля и определением ОО и его среды, приведенным во вве­
дении к ПЗ-модулю.
Каждый элемент ОПБ может как исходить из базы ПЗ-модуля, так и быть совер­
шенно новым. Пусть элемент «Е» является элементом ОПБ ПЗ-модуля, тогда имеет
место один из следующих случаев:
- «Е» относится к идентифицированной базе ПЗ-модуля; достаточно ссылки на
элемент ОПБ;
-
«Е» является уточнением элемента ОПБ базы ПЗ-модуля;
- «Е» является новым элементом ОПБ, связанным с дополнительными функция­
ми ОО или его среды.
Примечания
1 Уточненные элементы ОПБ могут рассматриваться как новые элементы ОПБ без какого-либо
влияния на значение ОПБ.
158
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
2 Также, как и ЗБ, ПЗ-модуль может вводить допущения при условии, что они охватывают
аспекты, выходящие за рамки базы ПЗ-модуля.
С.2.2.8 Цели безопасности
В данном разделе определены цели безопасности для ОО и среды функциони­
рования ОО.
ПЗ-модуль определяет новые цели безопасности в контексте целей безопасно­
сти базы ПЗ-модулей.
Каждая цель безопасности может как исходить из базы ПЗ-модуля, так и быть
совершенно новой. Пусть цель безопасности “О” является целью ПЗ-модуля, тогда
имеет место один из следующих случаев:
“О” относится к базе ПЗ-модулей; достаточно ссылки на цель безопасности;
“О” является уточнением цели безопасности базы ПЗ-модуля;
“О” является новой целью, введенной ПЗ-модулем.
Примечание - С уточненными целями можно обращаться как с новыми целями без како­
го-либо влияния на значение всего набора целей.
ПЗ-модуль может вводить новые цели для среды функционирования ОО, только
если они затрагивают аспекты, выходящие за рамки базы ПЗ-модулей.
В случае, когда ПЗ-модуль уточняет тип ОО, некоторые цели безопасности для
среды базы ПЗ-модуля могут стать целями безопасности для ОО в ПЗ-модуле.
В данном разделе также определяется обоснование между ОПБ и целями без­
опасности ПЗ-модуля, которое состоит из отображения, которое отслеживает ОПБ ПЗмодуля в соответствии с их целями безопасности наряду с обоснованием, демонстри­
рующим, что эффективность отслеживания, как указано в п. 7.2.5. Более того, отобра­
жение должно показать не только то, что все элементы охвачены ОПБ, но и отсутствие
бесполезной цели безопасности.
Может случиться так, что некоторые цели безопасности ПЗ-Модуля охватывают
также элементы ОПБ базы ПЗ-модуля, которые не принадлежат ОПБ самого ПЗ-
модуля. Эта информация необязательна, но может быть предоставлена в примечаниях
к применению.
С.2.2.9 Определение расширенных функциональных компонентов
Данный раздел идентичен разделу расширенных компонентов ПЗ и ЗБ, указан­
ному в В.3.6.
С.2.2.10 Требования безопасности
Требования безопасности состоят из двух групп требований:
159
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
а) функциональные требования безопасности (ФТБ);
Перевод целей безопасности для ОО на стандартизованный язык;
Ь) требования доверия к безопасности (ТДБ).
Описание того, как обеспечить доверие к тому, что ОО соответствует ФТБ.
Эти две группы обсуждаются в подразделе 7.3.
С.2.2.10.1. Функциональные требования безопасности
В данном разделе определены функциональные требования безопасности для
ОО во взаимосвязи с набором целей безопасности ОО в ПЗ-модуле и с функциональ­
ными требованиями безопасности базы ПЗ-модулей.
Каждое функциональное требование безопасности может исходить из базы ПЗ-
модуля или быть совершенно новым. Пусть «R» - функциональное требование без­
опасности ПЗ-модуля, тогда имеет место один из следующих случаев:
- «R» относится к ПЗ-модульной базе; достаточно ссылки на требование;
- «R» - это уточнение ФТБ в базе ПЗ-модуля;
- «R» - новое требование, введенное ПЗ-модулем.
Примечание - С уточненными требованиями можно обращаться как с новыми без какого-
либо влияния на смысл всего набора требований.
В этом разделе также определяется обоснование между ФТБ и целями безопас­
ности ОО ПЗ-модуля, которое состоит из отображения, которое отслеживает ФТБ до
целей ОО ПЗ-модуля, и обоснования, демонстрирующего эффективность отслежива­
ния, как указано в 7.2.5. Более того, отображение должно показать не только то, что
все цели ОО выполнены, но и отсутствие бесполезных функциональных требований
безопасности.
Может случиться так, что некоторые ФТБ ПЗ-модуля охватывают также цели
безопасности ОО базы ПЗ-модуля, которые не относятся к самому ПЗ-модулю. Эта
информация необязательна, но может быть предоставлена в примечаниях к примене­
нию.
ПЗ-модули могут определять и включать необязательные ФТБ (и любые требуе­
мые элементы ОПБ), как ранее указано для ПЗ в В.3.7.
С.2.2.10.2 Требования доверия к безопасности
ПЗ-модуль определяет набор ТДБ,
которые будут использоваться в ПЗ-
конфигурациях, включающих этот ПЗ-модуль. Обоснование доверия, описанное в
С.2.2.4. обеспечивает согласованность этого набора ТДБ с базой ПЗ-модуля.
160
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
ПЗ-модуль, использующий единое доверие, наследует набор ТДБ, включая лю­
бые пакеты доверия, такие как предварительно определенные ОУД, из своей базы ПЗ-
модуля. Вопрос об элементах ПЗ-модуля с логическим оператором AND с разными
ТДБ должен быть решен и решен таким же образом, как ПЗ, соответствующий всем
этим ПЗ, решает эту проблему.
С.2.3 ПЗ-модули с прямым обоснованием
ПЗ-модули могут быть составлены с намерением использовать их с компонента­
ми в их базе, которые также используют метод прямого обоснования. В этом случае
цели безопасности для ОО не включаются в ПЗ-модуль, а могут быть включены цели
безопасности для среды функционирования ОО.
Содержимое ПЗ-модуля с прямым обоснованием показано на рисунке С.З.
161
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
ПЗ-модуль
(Прямое обоснование)
Введение в ПЗ-модуль
Обоснование согласованности
Соответствие
Определение проблемы
безопасности
Цели безопасности
Ссылка на ПЗ-модуль
Идентификация базы ПЗ ПЗ-модуля
Обзор ОО
Обоснование
согласованности с
ПЗ-модулями базы
Утверждения о соответствии:
Требование стандарта (Ссылка на
применяемые ИСО/МЭК 15408 и ИСО/
МЭК 18045 стандарты, ИСО/МЭК 15408
2, ИСО/МЭК 15408-3
(соответствующий/расширенный))
Тип соответствия (точный, строго
демонстрируемый)
Требование(я) пакета
Обоснование соответствия
Изложение соответствия:
Ссылка(и) на методы/действия по
оценке
Типы соответствия для ПЗ и ЗБ,
полученных из ПЗ
Утверждение "разрешено совместно
применять"
Угрозы
Политики безопасности организации
Допущения
Цели безопасности для среды
функционирования
Обоснование целей безопасности
—
Определение расширенных
компонентов
Требование безопасности
Определение расширенных
компонентов
Функциональные требования
безопасности
Требования доверия к безопасности
Обоснование требований доверия
Дополнительно (опционально):
методы/действия по оценке
Рисунок С.З - Содержимое ПЗ-модуля с прямым обоснованием
С.2.4 Руководство по включению элементов ОПБ из базы ПЗ-модуля
Чтобы ограничить объем информации, содержащейся в ПЗ-модуле, разработчик
ПЗ-модуля применяет следующие правила:
162
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
пусть Е, О и R относятся к ОПБ, целям безопасности и функциональным требо­
ваниям безопасности ПЗ/ПЗ-модуля Q, соответственно, причем R отражается в О, а
отражается О в Е.
Пусть М будет ПЗ-модулем и Q относится к базе ПЗ-модуля М.
М должен удовлетворять следующему условию: Е, О, R и отображения между
ними должны принадлежать М только в том случае, если хотя бы один из этих элемен­
тов связан с новым элементом в М, т.е.
- либо существует новый элемент Е' ОПБ в М, так что О сопоставляется с Е'; или
- в М появилась новая цель О ', так что О' с Е 'или R сопоставляется с О'; или
- есть новое требование R 'в М так, что R‘ сопоставляется с О.
To-есть ПЗ-модуль не будет содержать частей базы ПЗ-модуля, если они не тре­
буются для удовлетворения новых потребностей. Здесь уточненные элементы счита­
ются новыми.
С.2.5 Необязательное содержимое ПЗ-модуля
ПЗ-модули могут произвольно включать в себя методы оценки/оценочные дей­
ствия, основанные на ИСО/МЭК 18045. Методы оценки/оценочные действия, связан­
ные с ПЗ-модулем, указаны в разделе заявлений о соответствии. См. 11.2.3.3.
Если разработчик ПЗ-модуля решает включить в ПЗ-модуль какие-либо методы
оценки/оценочные действия, то они могут быть представлены либо в разделе требова­
ний безопасности с соответствующими требованиями безопасности, либо в любом дру­
гом подходящем разделе или внешнем документе. Примечания к ПЗ, если они умест­
ны, должны быть связаны со специальными требованиями к ПЗ-модулю.
С.З Спецификация ПЗ-конфигураций
С.3.1 Общие положения
Содержание ПЗ-конфигурации обобщено ниже на рисунке С.4 и подробно объ­
яснено в частях приложения от С.3.2 по С.3.7.
163
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
ПЗ-конфигурация
Введение в ПЗ-модуль
Изложение компонентов ПЗконфигурации
Обоснование согласованности
ПЗ-конфигурации
ИзложениеПЗ-конфигу рации
Изложение ТДБ ПЗконфигурации
Ссылка на ПЗ-модуль
Обзор ОО (тип ОО, организация
(структура) ФБО в под-ФБО
Перечень компонентов
(ПЗ и ПЗ-модуль)
Обоснование согласованности в
отношении компонентов
Утверждения о соответствии:
Требование стандарта (Ссылка на
применяемые ИСО/МЭК 15408 и ИСО/
МЭК 18045 стандарты, ИСО/МЭК
15408-2, ИСО/МЭК 15408-3
(соответствуюиций/расширенный))
Тип соответствия (точный, строгий,
демонстрируемый)
Требование(я) пакета
Изложение соответствия:
Ссылка(и) на методы/действия по
оценке
Глобальные (характерные) пакеты
доверия
Наборы ТДБ для под-ФБО (только с
многоуровневым доверием)
Обоснование доверия (только с
многоуровневым доверием)
Рисунок С.4 - Содержание ПЗ-конфигурации
ПЗ-конфигурация содержит:
- ссылку, однозначно идентифицирующую ПЗ-конфигурацию;
- заявление о компонентах, которое идентифицирует ПЗ и ПЗ-модули, составля­
ющие ПЗ-конфигурацию, включая всю базу ПЗ-модулей, необходимую для определе­
ния закрытого набора компонентов;
- заявление о соответствии, которое определяет редакцию соответствующих ча­
стей серии ИСО/МЭК 15408, соответствие ИСО/МЭК 15408-2 и ИСО/МЭК 15408-3, со­
ответствие пакетам доверия и заявление о соответствии, которое определяет, должно
ли быть соответствие ЗБ данной ПЗ-конфигурации точным, строгим, доказуемым или
сочетанием строгого и доказуемого, унаследованным от его набора компонентов, и
любых применимых методов оценки/оценочных действий;
164
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
- описание типа ОО;
- описание организации ФБО исходя из под-ФБО, определенных компонентами
ПЗ-конфигурации;
- утверждение ТДБ, определяющее набор ТДБ, применимых ко всему ОО. В слу­
чае с многоуровневым доверием утверждение ТДБ включает в себя наборы ТДБ, кото­
рые относятся к под-ФБО, определенным в компонентах ПЗ-конфигурации. Утвержде­
ние ТДБ также включает обоснование доверия для обеспечения согласованности меж­
ду ПЗ-конфигурацией и ее компонентами.
Примечание - Пакетом доверия может быть ОУД, взятый из ИСО/МЭК 15408-5.
С.3.2 Ссылка на ПЗ-конфигурацию
Ссылка на ПЗ-конфигурацию обеспечивает четкую и однозначную идентифика­
цию, обычно состоящую из названия, номера версии, разработчика и даты публикации.
Ссылка на ПЗ-конфигурация может использоваться для индексации документа в
каталогах.
С.3.3 Утверждение о компонентах
Утверждение о компонентах ПЗ-конфигурации идентифицирует ПЗ-модули и ПЗмодули, составляющие ПЗ-конфигурацию.
Утверждение о компонентах ПЗ-конфигурации должно включать базу ПЗ-модуля,
требуемую для указанных ПЗ-модулей. Если для ПЗ-модуля указаны альтернативные
базы ПЗ-модуля, только одна из них должна указываться в ПЗ-конфигурации.
Примечание - ПЗ-конфигурации прямо не заявляют о соответствии функциональным
пакетам, независимо оттого, заявлены они одним из их компонентов или нет.
В случае с многоуровневым доверием описание компонентов ПЗ-конфигурации
должно обеспечивать организацию ФБО с точки зрения под-ФБО, определенных ком­
понентами ПЗ-конфигурации.
С.3.4 Обзор ОО
Обзор ОО ПЗ-конфигурации должен содержать:
- тип ОО ПЗ-конфигурации, который будет использоваться ЗБ, заявляющим о
соответствии ПЗ-конфигурации;
-
ожидаемое использование и основные функции безопасности ОО;
- доступное аппаратное обеспечение, программное обеспечение и / или микро­
программное обеспечение, не относящееся к ОО (если это возможно).
С.3.5 Обоснование согласованности
165
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
ПЗ-конфигурация должна представлять обоснование согласованности, чтобы
обеспечить совместимость комбинации компонентов.
Обоснование согласованности должно демонстрировать, что обзор ОО согласу­
ется с обзором ОО компонентов ПЗ-конфигурации и что объединение ОПБ, целей и
функциональных требований безопасности, определенных в этих компонентах, не при­
водит к противоречию.
В обосновании согласованности могут использоваться таблицы соответствия
между ОПБ/ целями/ФТБ вместе с текстовыми обоснованиями.
С.3.6 Заявление о соответствии и утверждение о соответствии
С.3.6.1 Заявление о соответствии стандартам серии ИСО/МЭК 15408
Редакция соответствующих частей стандартов серии ИСО/МЭК 15408, примени­
мых к ПЗ-конфигурации.
С.3.6.2 Тип соответствия
Соответствие данной ПЗ-конфигурации ЗБ должно быть точным, строгим или до­
казуемым; или сочетанием строгого и доказуемого, если ПЗ-Конфигурация содержит
компоненты обоих типов соответствия.
Любое ЗБ, заявляющая о соответствии ПЗ-конфигурации, должно соответство­
вать типу соответствия, требуемому в утверждении о соответствии ПЗ-конфигурации
С.3.6.3 Заявление о соответствии пакетам доверия
Заявление о соответствии может включать заявление о соответствии пакету до­
верия, описывающее любое соответствие ПЗ-конфигурации пакету доверия. В ПЗ-
Конфигурации может быть заявлено более одного пакета.
С.3.6.4 Заявление о ссылках на методы оценки/оценочные действия
Заявление о соответствии МО/ОД ПЗ-конфигурации может также определять
любые методы оценки/оценочные действия, которые необходимо использовать с ним.
ПЗ-конфигурация, которая относится к типу строгого или доказуемому соответ­
ствия (но не к точному типу соответствия),
может определять методы оцен­
ки/оценочные действия / в дополнение к тем, которые указаны в компонентах ПЗ-
конфигурации.
С.3.6.5 Дополнительные требования к точному соответствию
Если ПЗ-конфигурация указывает точное соответствие как тип ее соответствия в
своем заявлении о соответствии, то:
- если какой-либо компонент в ПЗ-конфигурации требует точного соответствия,
тогда все остальные компоненты в ПЗ-конфигурации также должны требовать точного
166
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
соответствия, и в заявлении о соответствии ПЗ-конфигурации должно быть указано
точное соответствие;
- в соответствующем разрешенном заявлении в разделе заявлений о соответ­
ствии все компоненты в ПЗ-Конфигурации должны позволять всем другим компонентам
в ПЗ-конфигурации использоваться вместе в ПЗ-конфигурации;
Примечание - ПЗ-модуль не должен включать свою собственную базу ПЗ-модуля в его
разрешенном заявлении, потому что они неявно разрешены. Пример представлен на рисунке С.5.
- МО/ОД, которые применяются в ПЗ-конфигурации, должны быть только теми,
которые содержатся в компонентах ПЗ-конфигурации; никакие дополнительные мето­
ды оценки/ оценочные действия компонентов ПЗ-конфигурации или их модификация не
допускаются.
ГпЗ-конфигурация ВСХУ
। Изложение соответствия: точное соответствие
ПЗ-модуль X
ПЗ-модуль Y
Утверждение о соответствии:
Утверждение о соответствии:
Изложение соответствия:
Изложение соответствия:
(наследованный: точное
соответствие)
(наследованный: точное
соответствие)
Утверждение «разрешено
совместно применять»:
Утверждение «разрешено
совместно применять»:
•
ПЗ-модуль X
•
ПЗ-модуль Y
Набор базового ПЗ
ПЗ в
ПЗ в
Утверждение о соответствии:
Утверждение о соответствии:
Изложение соответствия:
Изложение соответствия:
Точное соответствие
Точное соответствие
Утверждение «разрешено
совместно применять»:
• ПЗ-модуль X
Утверждение «разрешено
совместно применять»:
•
ПЗ В
•
ПЗ-модуль X
•
ПЗ-модуль Y
•
ПЗ-модуль Y
Рисунок С.5 - ПЗ-конфигурация и точное соответствие
167
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
ПЗ-конфигурация требует точного соответствия в своем заявлении о соответ­
ствии, так как это соответствие требуется в обоих базовых ПЗ и, следовательно,
наследуется ПЗ-модулями. Оба ПЗ-модуля X и Y имеют одинаковый набор базовых
ПЗ: ПЗ В и ПЗ С, и оба требуют точного соответствия. Следующие утверждения (пока­
занные на диаграмме) должны быть верными тому, чтобы это была конфигурация с за­
явлением о соответствии типа «точного»:
а) ПЗ-модули наследуют заявление о соответствии от своих базовых ПЗ, поэто­
му в их заявлении о соответствии соответствие является точным;
Ь) ПЗ-конфигурация должна требовать точного соответствия, поскольку точного
соответствия требуют ПЗ-модули;
d) ПЗ В должен указать в своем утверждении о соответствии, что его разрешено
использовать с ПЗ С, ПЗ-модулем X и ПЗ-модулем Y;
е) ПЗ С должен указать в своем утверждении о соответствии, что его разрешено
использовать с ПЗ В, ПЗ-модулем X и ПЗ-модулем Y;
ПЗ-модуль X указать в своем утверждении о соответствии, что его разрешено
использовать с ПЗ-модулем Y;
ПЗ-модуль Y указать в своем утверждении о соответствии, что его разрешено
использовать с ПЗ-модулем X;
С.3.7 Заявление ТДБ
В заявлении ТДБ для ПЗ-конфигурации указывается набор ТДБ, применимых к
оценке ОО, указанного ЗБ, который заявляет о соответствии этой ПЗ-конфигурации. В
случае с многоуровневым доверием, когда компоненты ПЗ-конфигурации несут разные
наборы ТДБ, ПЗ-конфигурация должна определять набор ТДБ, который применяется к
каждому из под-ФБО, определенных этими компонентами.
Набор ТДБ, который распространяется на весь ОО, называется пакетом гло­
бального доверия.
В случае соответствия доказуемого или строгого типа пакет глобального доверия
представляет собой надмножество общего подмножества ТДБ, которое применяется к
каждому из компонентов ПЗ-конфигураций.
В случае соответствия точного типа пакет глобального доверия представляет
собой минимальный общий набор ТДБ для компонентов ПЗ-конфигурации; никакое
увеличение не допускается.
168
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
В ПЗ-конфигурации набор ТДБ, который применяется к каждой из под-ФБО, либо
идентичен
набору
ТДБ,
определенным
в
соответствующем
компоненте
ПЗ-
конфигурации, либо является расширением этого набора.
Примером набора ТДБ является пакет доверия ОУД, предопределенный в
ИСО/МЭК 15408-5.
ПЗ-конфигурация должна обеспечивать обоснование доверия для демонстрации
согласованности применяемого набора ТДБ с теми, которые определены в его компо­
нентах, в частности, в отношении общих активов. Кроме того, в обосновании доверия
рассматривается размещение МО/ ОД в компонентах ПЗ-конфигурации в случае, когда
ТДБ были расширены на уровне ПЗ-конфигурации или были указаны дополнительные
МО/ ОД на уровне ПЗ-конфигурации.
Примечание - Обоснование доверия ПЗ-конфигурации должно распространить анализ,
приведенный в ПЗ-модулях, на все компоненты ПЗ-конфигурации вместе. Обычно это делается путем
разворачивания элементов ОПБ компонентов ПЗ-конфигурации и анализа наборов ТДБ, применимых к
каждому активу.
169
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Приложение D
(обязательное)
Спецификация заданий по безопасности и ЗБ с прямым обоснованием
D.1 Цель и структура данного приложения
Цель данного приложения является обобщение структуры и ожидаемого содер­
жания ЗБ.
Поскольку ПЗ и ЗБ в значительной степени совпадают, в данном приложении ос­
новное внимание уделяется различиям между ПЗ и ЗБ. Материал, идентичный для ЗБ
и ПЗ, изложен в Приложении В.
Примечание - Данное приложение не содержит определение требований к оценке ЗБ.
Критерии оценки ЗБ находятся в классе ASE в ИСО/МЭК 15408-3.
Данное приложение состоит из четырех основных частей:
а) как пользоваться ЗБ;
Использование ЗБ кратко изложено в части D.2. Здесь описывается, как следует
использовать ЗБ, а также некоторые вопросы, на которые можно ответить с помощью
ЗБ.
Ь) что должно содержать ЗБ;
Содержание ЗБ подробно описано в части D.3. Здесь излагается обязательное
содержание ЗБ, взаимосвязь между этим содержанием и приводятся примеры.
с) заявление о соответствии стандартам;
В части D.5 дано описание, как разработчик ЗБ может заявить, что ОО соответ­
ствует определенному стандарту.
d) прямое обоснование ЗБ.
ЗБ с прямым обоснованием - это ЗБ, в которых ФТБ и, возможно, цели безопас­
ности для среды функционирования перенесены непосредственно в элементы ОПБ.
D.4 может применяться к ЗБ с прямым обоснованием.
D.2 Использование ЗБ
D.2.1 Как использовать ЗБ
Типичный ЗБ выполняет две роли:
а) перед оценкой и в ходе оценки ЗБ указывает, «что следует оценивать». В этой
роли ЗБ служит основой для соглашения между разработчиком и оценщиком о точных
свойствах безопасности ОО и точной области оценки. Техническая корректность и пол­
нота являются основными проблемами для этой роли. Описание использования ЗБ да­
но в D.3.2 и D.3.5;
170
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Ь) после оценки в ЗБ указывается, «что было оценено». В этой роли ЗБ служит
основой для соглашения между разработчиком или перепродавцом ОО и потенциаль­
ным потребителем ОО. ЗБ содержит описание точных свойств безопасности ОО аб­
страктным образом, и потенциальный потребитель может полагаться на это описание,
поскольку ОО был оценен на соответствие ЗБ. Простота использования и понятность -
основные проблемы для этой роли. D.2.3 описывает, как ЗБ используется в этой роли.
D.2.2 Как не использовать ЗБ
Одной из многих ролей, которые ЗБ не следует выполнять, является:
- полная спецификация:
ЗБ является спецификацией безопасности, а не полной спецификацией. Если
они не связаны с безопасностью, такие свойства, как функциональная совместимость,
физический размер и вес, требуемое напряжение и т.д., не должны быть частью ЗБ.
Это означает, что в целом ЗБ может быть частью полной спецификации, но не самой
полной спецификацией.
D.2.3 Вопросы, на которые можно ответить с помощью ЗБ
После оценки ЗБ указывает, «что было оценено». В этой роли ЗБ служит осно­
вой для соглашения между разработчиком или перепродавцом ОО и потенциальным
потребителем ОО. Таким образом, ЗБ может ответить на следующие (и другие) вопро­
сы:
а) как найти нужное ЗБ/ОО с учетом множества существующих ЗБ/ОО?;
Этот вопрос рассматривается в обзоре ОО, в котором дается краткое (несколько
абзацев) резюме ОО;
Ь) вписывается ли данный ОО в существующую ИТ-инфраструктуру?;
Этот вопрос рассматривается в обзоре ОО, который определяет основные эле­
менты аппаратного/микропрограммного обеспечения/программного обеспечения, не­
обходимые для работы ОО;
с) соответствует ли данный ОО существующей среде функционирования?;
Этот вопрос решается в целях безопасности для среды функционирования, ко­
торые определяют все ограничения, которые ОО накладывает на среду для ее функ­
ционирования;
d) что делает ОО (заинтересованный читатель)?;
Этот вопрос рассматривается в обзоре ОО, в котором дается краткое (несколько
абзацев) резюме ОО;
е) что делает ОО (потенциальный потребитель)?;
171
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Этот вопрос рассматривается в описании ОО, которое дает менее краткое (не­
сколько страниц) резюме ОО;
f) что делает ОО (технический)?;
Этот вопрос рассматривается в краткой спецификации ОО, которая обеспечива­
ет высокоуровневое описание механизмов, используемых ОО;
д) что делает ОО (эксперт)?;
Этот вопрос рассматривается в ФТБ, которые предоставляют абстрактное высо­
котехнологичное описание, и в краткой спецификации ОО, которая предоставляют до­
полнительные детали;
h) решает ли ОО проблему, как это определено органом власти/организацией?;
Если орган власти/организация определили пакеты и/или
ПЗ
и/или ПЗ-
конфигурации для определения этого решения, то ответ можно найти в разделе «За­
явления о соответствии» ЗБ,
в котором перечислены все пакеты,
ПЗ и ПЗ-
конфигурации, которым соответствует ЗБ;
i) решает ли ОО проблему безопасности (эксперт)?;
Каким угрозам противостоит ОО? Какую политику безопасности организации он
применяет? Какие предположения он делает о среде функционирования? На эти во­
просы отвечает определение проблемы безопасности;
j) насколько я могу доверять ОО?
Это можно найти в ТДБ в разделе требований безопасности, содержащем тре­
бования доверия, которые использовались для оценки ОО, и, следовательно, доверие,
которое оценка обеспечивает к правильности ОО.
D.3 Обязательное содержание ЗБ
D.3.1 Общие положения
Существуют два типа ЗБ. Во-первых, «обычное» ЗБ, которое представляет со­
бой ЗБ с полным содержанием, как описано в D.3.3 - D.3.7.2. Во-вторых, в некоторых
случаях разработчик ЗБ может использовать ЗБ с прямым обоснованием, которое не
устанавливает цели безопасности для ОО. ЗБ с прямым обоснованием, а также причи­
ны и обстоятельства, в которых они используются, подробно описаны в D.4. Все
остальные части этого приложения предполагают ЗБ с полным содержанием.
На рисунке D.1 показано содержание ЗБ, приведенное в ИСО/МЭК 15408-3.
172
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Задание по
безопасности
Введение ЗБ
Ссылка на ЗБ
Ссылка на ОО
Обзор ОО
Организация (структура) под-ФБО
(только с многоуровневым доверием)
Описание ОО
Соответствие
Утверждения о соответствии:
Требование стандарта (Ссылка на
применяемые ИСО/МЭК 15408 и ИСО/
МЭК 18045 стандарты, ИСО/МЭК 15408­
2, ИСО/МЭК 15408-3
(соответствующий/расширенный))
Тип соответствия (точный, строго
демонстрируемый)
ПЗ-конфигурация(и)
ПЗ
Пакет(ы)
Обоснование соответствия
Изложение соответствия:
Ссылка(и) на методы/действия по
оценке
Угрозы
Политики безопасности организации
Допущения
Определение проблемы
безопасности
Цели безопасности для ОО
Цели безопасности для среды
функционирования
Обоснование целей безопасности
Цели безопасности
Определение расширенных
компонентов
Определение расширенных
компонентов
—
Функциональные требования
безопасности
Требования доверия к безопасности
Обоснование требований безопасности
Требования безопасности
—
Краткая спецификация ОО
•
Краткая спецификация ОО
Рисунок D.1 - Содержание ЗБ
Рисунок D.1 также может использоваться в качестве структурной схемы ЗБ, хотя
допустимы альтернативные структуры. Например, если обоснование требований без­
опасности является особенно объемистым, его можно включить в приложение ЗБ, а не
173
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
в раздел требований безопасности. Отдельные разделы ЗБ и содержание этих разде­
лов кратко излагаются ниже и объясняются более подробно в D.3.3 - D.3.7.2. ЗБ со­
держит:
а) введение в ЗБ, содержащее три повествовательных описания ОО на разных
уровнях абстракции;
Ь) заявление о соответствии, в котором указывается соответствие ЗБ релевант­
ной редакции ИСО/МЭК 15408-2 и ИСО/МЭК И 15408-3; показывается, заявляет ли ЗБ
о соответствии каким-либо ПЗ, ПЗ-конфигурациям и/или пакетам, и если это так, ука­
зываются конкретные ПЗ, ПЗ-конфигурации и/или пакеты, методы оценки/оценочные
действия и типы заявленного соответствия;
с)
определение проблем безопасности с указанием угроз, ПБО и предположений
d) цели безопасности, показывающие, как решение проблемы безопасности раз­
деляется между целями безопасности для ОО и целями безопасности для среды
функционирования ОО;
е) определения расширенных компонентов (необязательные), где могут быть
определены новые компоненты (т.е. те, которые не включены в ИСО/МЭК 15408-2 или
ИСО/МЭК 15408-3). Эти новые компоненты необходимы для определения расширен­
ных функциональных требований и требований расширенного доверия;
f) требования безопасности, в которых предоставляется перевод целей безопас­
ности для ОО на стандартизованный язык. Этот стандартизированный язык имеет
форму ФТБ. Кроме того, в этом разделе дано определение ТДБ;
д) краткую спецификацию ОО, показывающую, как ФТБ реализованы в ОО.
D.3.2 Введение в ЗБ (ASE_INT)
D.3.2.1 Общие положения
Введение ЗБ описывает ОО в повествовательной форме на трех уровнях аб­
стракции:
а) ссылка на ЗБ и ссылка на ОО, которые предоставляют идентификационный
материал для ЗБ и ОО, на которые ссылается ЗБ:
Ь)
обзор ОО, в котором кратко описывается ОО;
с)
описание ОО, которое описывает ОО более подробно.
D.3.2.2 Ссылка на ЗБ и ссылка на ОО
Ссылка на ЗБ и ссылка на ОО упрощают индексацию и ссылки на ЗБ и ОО, а
также их включение в каталоги.
174
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
ЗБ содержит четкую ссылку на ЗБ, которая идентифицирует это конкретное ЗБ.
Типичная ссылка на ЗБ состоит из названия, версии, спонсоров и даты публикации.
Примером ссылки на ЗБ является «База данных MauveRAM ST, версия 1.3, груп­
па спецификаций MauveCorp, 11 октября 2017 года».
ЗБ также содержит ссылку на ОО, которая идентифицирует ОО, заявляющий о
соответствии ЗБ. Типичная ссылка на ОО состоит из имени разработчика, названия ОО
и номера версии ОО. Одиночный ОО может оцениваться несколько раз, например,
разными потребителями этого ОО, и, следовательно, иметь несколько ЗБ, связанных с
этой ссылкой.
Примером ссылки на ОО является «MauveCorp MauveRAM Database v5.12».
Если ОО построен из одного или нескольких общеизвестных продуктов, разре­
шается отразить это в ссылке на ОО путем ссылки на название (а) продукта. Однако
это не должно использоваться для введения потребителей в заблуждение: ситуации,
когда основные части или функции безопасности не были учтены при оценке, но ссыл­
ка на ОО не отражает этого, не допускаются.
Если ОО состоит из одного или нескольких общеизвестных продуктов, допустимо
отражение этого в ссылке на ОО путем ссылки на название продукта(ов). Однако это
не должно вводить потребителей в заблуждение: ситуации, когда основные части или
функции безопасности не были учтены при оценке, но ссылка на ОО не отражает этого,
не допускаются.
D.3.2.3 Обзор ОО
D.3.2.3.1 Общие положения
Обзор ОО предназначен для потенциальных потребителей ОО, которые про­
сматривают каталоги оцениваемых ОО/продуктов, чтобы найти ОО, которые отвечают
их требованиям безопасности и поддерживаются их аппаратным, программным и мик­
ропрограммным обеспечением. Типичный объем обзора ОО составляет несколько аб­
зацев.
С этой целью в обзоре ОО кратко описывается использование ОО и его основ­
ные функции безопасности, определяется тип ОО и указываются все основные аппа­
ратные средства/программное обеспечение/встроенные программы, не относящиеся к
ОО, но необходимые для него.
В случае ЗБ с многоуровневым доверием обзор ОО также предоставляет орга­
низацию ФБО в терминах под-ФБО, определенных в ПЗ-конфигурации, о соответствии
которой утверждает ЗБ.
175
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
D.3.2.3.2 Использование и основные функции безопасности ОО
Описание использования и основных функций безопасности ОО предназначено
для того, чтобы дать очень общее представление о том, на что способен ОО с точки
зрения безопасности и для чего он может использоваться в контексте безопасности.
Этот раздел ЗБ написан для (потенциальных) потребителей ОО и описывает исполь­
зование ОО и основные функции безопасности с точки зрения бизнес-операций с ис­
пользованием языка, понятного потребителям ОО.
Например, «База данных MauveCorp MauveRAM v5.12 - это многопользователь­
ская база данных, предназначенная для использования в сетевой среде. Это позволя­
ет 1024 пользователям одновременно быть активными. Он позволяет выполнять
аутентификацию по паролю/токену и биометрическую аутентификацию, защищает от
случайного повреждения данных и может отменить десять тысяч транзакций. Ее функ­
ции аудита легко конфигурируются, что позволяет проводить подробный аудит некото­
рых пользователей и транзакций, защищая при этом конфиденциальность других поль­
зователей и транзакций».
D.3.2.3.3 Тип ОО
Обзор ОО определяет тип ОО, такой как: межсетевой экран, смарт-карта, модем,
интрасеть, веб-сервер, база данных, веб-сервер и база данных, локальная сеть, ло­
кальная сеть с веб-сервером и базой данных и т.д.
В случае, если ОО не относится к легкодоступному типу, можно использовать
тип ОО «отсутствует».
Идентификация типа ОО не должна вводить потребителей в заблуждение.
Примеры включают:
- ОО типа ATM-карты, который не поддерживает какие-либо функции идентификации/аутентификации;
- ОО типа межсетевого экрана, который не поддерживает почти повсеместно ис­
пользуемые протоколы;
- ОО типа PKI (инфраструктура сертификации открытых ключей), не имеющий
функции отзыва сертификата.
- можно ожидать работы ОО в определенных средах функционирования из-за
своего типа ОО, но он не может этого сделать:
- ОО типа операционной системы ПК, которая не может безопасно функциониро­
вать, если ПК не имеет сетевого подключения, флэш-накопителя и CD/DVD-плеера;
176
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
- межсетевой экран, который не может безопасно работать, если все пользова­
тели, которые могут подключаться через этот межсетевой экран, не являются безопас­
ными.
D.3.2.3.4 Требуемое оборудование/программное обеспечение/прошивка, не
относящиеся к ОО
Поскольку некоторые ОО не полагаются на другие ИТ, многие ОО (особенно про­
граммные ОО) полагаются на дополнительное, не относящееся к ОО, аппаратное
обеспечение, программное обеспечение и/или прошивку. В последнем случае для
идентификации таких аппаратных средств, программного обеспечения и/или прошивки,
не относящихся к ОО, требуется обзор ОО. Полная и детальная идентификация до­
полнительного оборудования, программного обеспечения и/или прошивки не требует­
ся, но идентификация должна быть достаточно подробной, чтобы потенциальные по­
требители могли определить основные аппаратные средства, программное обеспече­
ние и/или прошивку, необходимые для использования ОО.
Примерами идентификации оборудования/программного обеспечения/прошивки
являются:
- стандартный ПК с двухъядерным 2,10 ГГц или более быстрым процессором и 4
ГБ или более ОЗУ, использующее операционную систему Yaiza для профессионалов,
версия 53.0 Update 6b, с или 7, или версия 54.0;
- стандартный 64-разрядный сервер с двумя четырехъядерными процессорами и
16 ГБ или более ОЗУ, использующий операционную систему Yaiza, серверной версии
7.0 Update 6d и графической карты WonderMagic 12.0 с набором драйверов 1.0 WM;
-
микросхема CleverCard SB17067;
- интегральная схема CleverCard SB17067, использующая версию 12.0 операци­
онной системы смарт-карт QuickOS;
- установка в декабре 2020 года ЛВС аппарата генерального директора Депар­
тамента дорожного движения.
D .3.2.3.5 Организация ФБО в под-ФБО в случае наличия многоуровневого
доверия
ЗБ с многоуровневым доверием, т.е. ЗБ, которое заявляет о соответствии ПЗ-
конфигурации с многоуровневым доверием и которое определяет несколько наборов
ТДБ для различных под-ФБО, должно наследовать организацию ФБО в под-ФБО из ПЗ-
конфигурации.
177
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
В обзоре ОО описывается такая организация, возможно, с подробностями о фак­
тическом ОО.
В обзоре ОО содержится описание такой организация, возможно, с подробно­
стями о фактическом ОО.
D.3.2.4 Описание ОО
Описание ОО - это повествовательное описание ОО, занимающее несколько
страниц. Описание ОО дает оценщикам и потенциальным потребителям общее пред­
ставление о возможностях обеспечения безопасности ОО с большими подробностями,
чем это было представлено в обзоре ОО. Описание ОО может также использоваться
для изложения более широкого контекста применения, в который впишется ОО.
В описании ОО рассматривается физическая область действия ОО: перечень
всех аппаратных средств, программно-аппаратных средств, программного обеспечения
и руководств, составляющих ОО. Этот перечень должен быть составлен на уровне де­
тализации, достаточном для получения читателем общего представления об этих ча­
стях.
В описании ОО должна также рассматриваться логическая область действия ОО,
включая основные функции ОО, и содержаться краткое описание функций безопасно­
сти (ФБО).
Предоставленное описание должно быть на уровне детализации, достаточном
для получения читателем общего представления об этих функциях. Предполагается,
что это описание будет более подробным, чем описание основных функций безопасно­
сти в обзоре ОО.
Важным свойством физических и логических областей действия является то, что
они описывают ОО таким образом, что не остается сомнений в том, принадлежит ли
определенная часть или функция ОО или эта часть или функция находится вне ОО.
Это особенно важно, когда ОО интегрирован с объектами, не относящимися к ОО, и не
может быть легко отделен от них.
Примеры интеграции ОО с объектами, не относящимися к ОО:
-
ОО является сопроцессором ИС смарт-карты, а не всей ИС;
-
ОО представляет собой ИС смарт-карты, за исключением процессора;
- ОО является
частью трансляции сетевых адресов межсетевого экрана
MinuteGap v28.2.
В некоторых случаях компоненты третьей стороны могут представлять практиче­
ские трудности при получении доказательств.
178
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Пример отсутствия недоступности достаточных свидетельств третьих сторон для
оценки включает случаи, когда исходный код, проектная документация или свидетель­
ства тестирования не могут быть предоставлены разработчику ОО.
D.3.3 Заявления о соответствии (ASE_CCL)
Раздел ЗБ заявлений о соответствии содержит описание, как ЗБ соответствует
стандартам серии ИСО/МЭК 15408, пакетам, ПЗ и ПЗ-конфигурациям. Он аналогичен
разделу ПЗ заявлений о соответствии, изложенному в В.3.3, за одним исключением: в
ЗБ нет утверждения о соответствии, поскольку ЗБ не разрешено заявлять о соответ­
ствии другому ЗБ.
Дополнительное различие между ЗБ, заявляющим о соответствии ПЗ, и ЗБ, за­
являющим о соответствии с ПЗ-конфигурацией, заключается в том, что хотя ЗБ может
заявлять о соответствии нескольким ПЗ и может дополнять функциональные пакеты в
ПЗ и даже заявлять о соответствии как ПЗ, так и функциональному пакету, оно может
заявлять о соответствии только одной ПЗ-конфигурации и никаким дополнительным
ПЗ-конфигурациям, ПЗ или функциональным пакетам.
D.3.4 Определение проблемы безопасности (ASE_SPD)
Раздел ОПБ ЗБ описывает, как ЗБ ставит проблему безопасности, которую необ­
ходимо решить. Он идентичен разделу ОПБ ПЗ, изложенному в В.3.4.
ЗБ, который соответствует ПЗ и/или ПЗ-конфигурации, включает все элементы
ОПБ, определенные в компонентах этих ПЗ и ПЗ-конфигураций. Может случиться так,
что допущение в компоненте ПЗ или ПЗ- конфигурации может стать целью ОО в ЗБ.
D.3.5 Цели безопасности (ASE_OBJ)
Этот раздел ЗБ идентичен разделу целей безопасности ПЗ, как изложено в В.3.5
и В.5.
ЗБ, который соответствует ПЗ и/или ПЗ-конфигурации, включает в себя все це­
ли, определенные в компонентах этих ПЗ и ПЗ-конфигураций. Может случиться так, что
цели для среды функционирования ОО в компоненте ПЗ или ПЗ-конфигурации могут
стать целью для ОО в ЗБ.
D.3.6 Определение расширенных компонентов (ASE_ECD)
Этот раздел ЗБ идентичен разделу расширенных компонентов ПЗ, как изложено
в В.3.6.
D.3.7 Требования безопасности (ASE_REQ)
D.3.7.1 Функциональные требования безопасности
D.3.7.1.1 Общие положения
179
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Данный раздел ЗБ идентичен разделу требований безопасности ПЗ, как изложе­
но в В.3.7, за исключением того, что спецификация ФТБ на основе выбора и дополни­
тельных требований не применима в ЗБ, поскольку все ФТБ должны быть полностью
подтверждены.
ЗБ, которое соответствует ПЗ и/или ПЗ-конфигурации, включает в себя все ФТБ,
определенные в компонентах этих ПЗ и ПЗ-конфигураций.
D.3.7.1.2 Включение требований в ЗБ
В ЗБ с точным соответствием ПЗ должны быть включены все требования ПЗ.
Требования, отсутствующие в ПЗ, не включаются в ЗБ.
В ЗБ со строгим соответствием ПЗ должны быть включены все требования ПЗ.
В ЗБ с доказуемым соответствием ПЗ должны быть включены все требования из
ПЗ, или в ЗБ должно быть дано обоснование, объясняющее, как они выполняются
иным образом.
В ЗБ со строгим или доказуемым соответствием ПЗ могут быть включены допол­
нительные требования, отсутствующие в ПЗ, при условии, что они поддерживают до­
полнительные цели безопасности/включают дополнительные угрозы.
Для ЗБ, заявляющих о соответствии ПЗ-конфигурации, действуют те же правила,
что и для соответствия ПЗ. В этом случае требования берутся из компонентов ПЗ-
конфигурации, то есть ее ПЗ и ПЗ-модулей. Если ПЗ-конфигурация содержит компо­
ненты, требующие другого типа соответствия (только строгого и доказуемого, посколь­
ку точное соответствие не может быть объединено с другими типами), ЗБ соответству­
ет каждому из компонентов (ПЗ и ПЗ-модулям) тем способом, который они требуют, а
именно, либо строгого, либо доказуемого.
Если ЗБ заявляет о соответствии ПЗ или ПЗ-конфигурации, а ПЗ или компоненты
ПЗ-конфигурации содержат необязательные требования, ЗБ может конкретизировать
эти требования, обязательно включив любые требуемые элементы ОПБ, связанные с
этими требованиями. Это может быть сделано независимо от соответствия требовани­
ям ПЗ или ПЗ-конфигурации. Опускание необязательных ФТБ в ЗБ не является «ча­
стичным соответствием» ПЗ или ПЗ-конфигурации и, следовательно, допустимо.
Затем соответствие стандарту как часть выполнения ОО ФТБ оценивается од­
ним из следующих способов:
- если для ФТБ была определена явное оценочная деятельность, то выполняют­
ся действия оценщика из этой оценочной деятельности;
180
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
- если для ФТБ не была определена явное оценочная деятельность, то впослед­
ствии соответствие определяется, как если бы полный текст стандарта был включен
как часть ФТБ, включая ТДБ, которые были выбраны для ЗБ.
D.3.7.2 Требования доверия к безопасности
В ЗБ определен набор ТДБ, применимых к оценке ОО.
Если ЗБ соответствует ПЗ или ПЗ-конфигурации, то набор ТДБ должен соответ­
ствовать ПЗ или ПЗ-конфигурации.
Если ЗБ соответствует ПЗ-конфигурации с многоуровневым доверием, то либо:
- в ЗБ существует один набор ТДБ для всего ОО и ФБО (в соответствии с гло­
бальным пакетом доверия, определенным в ПЗ-конфигурации). В этом случае ОО
должен быть оценен в соответствии с подходом с единым доверием
ЗБ определяет глобальный набор ТДБ, который относится ко всему ОО, и набо­
ры ТДБ, которые относятся к каждому из под-ФБО, определенных в ПЗ-конфигурации
(в соответствии с наборами ТДБ, определенными в ПЗ-конфигурации). В этом случае
ОО должен быть оценен в соответствии с методом многоуровневого доверия.
ЗБ с многоуровневым доверием и ЗБ, которые дополняют ТДБ конфигураций
ПЗ/ПЗ, которым они соответствуют, должны обеспечивать обоснование доверия для
демонстрации согласованности наборов ТДБ.
D.3.8 Краткая спецификация ОО (ASE_TSS)
Целью краткой спецификации ОО является предоставление потенциальным по­
требителям ОО описания того, как ОО удовлетворяет всем ФТБ. Краткая специфика­
ция ОО предоставляет общие технические механизмы, которые ОО использует для
этой цели. Уровень детализации этого описания должен быть достаточным, чтобы поз­
волить потенциальным потребителям понять общую форму и реализацию ОО.
TSS включает описание на естественном языке выполнения функциональных
требований безопасности, в части которого излагается, как ФТБ объединяются для
обеспечения функции безопасности с точки зрения архитектуры, которая является ви­
димой (наблюдаемой) для администраторов и других пользователей, или с точки зре­
ния внутренних особенностей или свойств.
Ниже приведены примеры внутренних особенностей:
-
недоступность остаточных данных при перераспределении ресурса;
-
скрытые условия сбоя входа в систему/ аутентификации паролей;
-
оценка скрытого биометрического сравнения.
181
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Если ОО является ПК с Интернетом, а ФТБ содержат FIA_UAU.1 для определе­
ния аутентификации, в краткой спецификации ОО указывается, как выполняется эта
аутентификация: пароль, маркер, сканирование радужной оболочки глаза и т.д. Может
быть представлена дополнительная информация, например, применимые стандарты,
которые ОО использует для соответствия требованиям ФТБ.
В краткой спецификации ОО могут быть ссылки на технические стандарты.
Примечание - ЗБ является входными данными в ADV, что означает, что ADV позволяет
указывать на несоответствия между TSS и другими спецификациями. Однако здесь не указана
специальная оценочная деятельность, что отражает тот факт, что TSS предоставляет обзор реализации
ФТБ ОО, но не спецификацию реализации.
D.4 ЗБ с прямым обоснованием
D.4.1 Общие положения
В некоторых ситуациях целесообразно опустить определение целей безопасно­
сти ОО. В этом случае обоснование требований безопасности напрямую отображает
ФТБ и, где это целесообразно, цели безопасности для среды функционирования, в
ОПБ.
Цель ЗБ с прямым обоснованием - минимизировать уровень косвенности между
ОПБ, любыми целями безопасности для среды функционирования и ФТБ на основе
описания расширенных ФТБ.
Различия, обнаруженные в ЗБ с прямым обоснованием, содержатся в заявлени­
ях о соответствии, целях безопасности и в разделах ОПБ. Они описаны в D.4.2 и D.4.3
ниже.
Содержание ЗБ с прямым обоснованием показано на рисунке D.2.
182
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Задание по
безопасности
(Прямое обоснование)
Введение ЗБ
Ссылка на ЗБ
Ссылка на ОО
Обзор ОО
Организация (структура) под-ФБО
(только с многоуровневым доверием)
Описание ОО
Соответствие
Утверждения о соответствии:
Требование стандарта (Ссылка на
применяемые ИСО/МЭК 15408 и И СО/
МЭК 18045 стандарты, ИСО/МЭК 15408­
2, ИСО/МЭК 15408-3
(соответствующий/расширенный))
Тип соответствия (точный, строго
демонстрируемый)
Прямое обоснование ПЗконфигурации(й)
Прямое обоснование ПЗ
Пакет(ы) прямого обоснования
Обоснование соответствия
Изложение соответствия:
Ссылка(и) на методы/действия по
оценке
Угрозы
Политики безопасности организации
Допущения
Определение проблемы
безопасности
—
Цели безопасности для среды
функционирования
Обоснование целей безопасности
Цели безопасности
—
Определение расширенных
компонентов
Определение расширенных
компонентов
—
Функциональные требования
безопасности
Требования доверия к безопасности
Обоснование требований безопасности
Требования безопасности
—
Краткая спецификация ОО
■
Краткая спецификация ОО
Рисунок D.2 - Содержание прямого обоснования ЗБ
D.5 Заявления о соответствии (ASE_CCL) в ЗБ с прямым соответствием
ЗБ с прямым обоснованием должно заявлять только о соответствии другим ПЗ с
прямым обоснованием (см. 12.2 и Приложение В).
183
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
ЗБ с прямым обоснованием должен утверждать только соответствие ПЗ-
конфигурации, в которой используется прямое обоснование (см. 12.2).
D.5.1 Определение проблемы безопасности (ASE_SPD) для ЗБ с прямым
обоснованием
ЗБ с прямым обоснованием имеет следующие отличия в отношении целей без­
опасности по сравнению с ЗБ, содержащим цели безопасности для ОО:
- не включены цели безопасности для ОО. Цели безопасности для среды функ­
ционирования все еще нуждаются в описании.
- обоснование целей безопасности, включенное только в цели безопасности для
среды функционирования, поскольку в ЗБ нет целей безопасности ОО.
D .5.2 Требования к проблемам безопасности (ASE_REQ) для ЗБ с прямым
обоснованием
Включено обоснование требований безопасности, которое напрямую сопостав­
ляет ФТБ и любые цели безопасности для среды функционирования с элементами
ОПБ. Рекомендуется, чтобы эта часть обоснования требований безопасности распола­
галась непосредственно под каждой из угроз, ПБО и предположений в разделе ОПБ.
Как и в ЗБ, которые содержат цели безопасности для ОО, обоснование требований
безопасности также должно обосновывать отсутствие лишних ФТБ и любых невыпол­
ненных зависимостей ФТБ; эта часть обоснования обычно располагается после опре­
деления ФТБ.
D
.6 Ссылки на другие стандарты в ЗБ
Ссылка на стандарты в ЗБ аналогична разделу о стандартах для ПЗ, как изложе­
но в В.4. Примеры приведены в D.3.7.1.2 и D.3.7.2.
184
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Приложение Е
(обязательное)
Соответствие ПЗ/ПЗ-конфигурации
Е.1 Общие положения
ПЗ предназначен для использования в качестве «шаблона» для ЗБ. То есть
ПЗ/ПЗ-конфигурация описывают набор потребностей пользователя, а ЗБ, которое со­
ответствует этой ПЗ / ПЗ-конфигурации, описывает ОО, который удовлетворяет эти по­
требности.
Серия стандартов ИСО/МЭК 15408 не допускает частичное соответствие в какой-
либо форме, поэтому, если заявлено соответствие ПЗ/ПЗ-конфигурации, ЗБ должно
соответствовать указанному ПЗ (ям) или ПЗ-конфигурации.
Примечание - В случае основанных на выборе или необязательных ФТБ включение или
исключение этих типов ФТБ, как указано в п. 7.3.2.6, не считается частичным соответствием и поэтому
допускается.
Серия стандартов ИСО/МЭК 15408 определяет три типа соответствия: «доказу­
емое», «строгое» и «точное», где тип допустимого соответствия определяется ПЗ/ПЗ-
конфигурацией (и косвенно ее ПЗ и ПЗ-модулями). То есть ПЗ/ПЗ-конфигурация в сво­
ем заявлении о соответствии указывают допустимые типы соответствия для производ­
ных ЗБ.
Как указано в подразделе 10.5, если ПЗ / ПЗ-конфигурация определяет точное
соответствие, то ЗБ должно заявлять только о точном соответствии этим ПЗ/ПЗ-
конфигурации, а любые другие ПЗ, соответствие которым заявлено ЗБ, также должны
требовать точного соответствия. Если ПЗ включен в ПЗ-конфигурацию (либо сам ПЗ,
либо как базовый ПЗ для ПЗ-модуля в этой ПЗ-конфигурации), то сама ПЗконфигурация и все другие компоненты ПЗ-конфигурации также требуют точного соот­
ветствия.
Различие между доказуемым и строгим соответствием, когда такие утверждения
о соответствии содержатся во многих ПЗ, соответствие которым заявлено ЗБ, приме­
нимо к каждому ПЗ, о соответствии которому ЗБ может заявлять на индивидуальной
основе. Это может означать, что ЗБ строго соответствует некоторым другим ПЗ и дока­
зуемо другим ПЗ.
ЗБ с точным типом соответствия должен заявлять о соответствии ПЗ/ПЗ-
конфигурации только в том случае, если ПЗ/ПЗ-конфигурация имеет точный тип соот­
ветствия и явно допускает это.
185
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
ЗБ должен заявлять о доказуемом соответствии ПЗ/ПЗ-конфигурации только в
том случае, если ПЗ/ПЗ-конфигурация явно допускает это.
Примечание - Доказуемое соответствие означает, что ЗБ, заявляющие о соответствии ПЗ
или ПЗ-конфигурации, должны предлагать решение общей проблемы безопасности, описанной в ПЗ/ПЗконфигурации, но могут делать это любым способом, который эквивалентен или является более
ограничительным в отношении способа, изложенному в ПЗ/ПЗ-конфигурации. В принципе это означает,
что ЗБ может содержать утверждения, которые отличаются от ПЗ/ПЗ-конфигурации, при условии, что в
целом ЗБ налагает те же или большие ограничения на ОО и такие же или меньшие ограничения на
среду функционирования ОО.
Также возможно использование ПЗ в качестве шаблона для другого ПЗ, который
определяет строгий или доказуемый тип соответствия. То есть ПЗ, определяющие
строгое или доказуемое соответствие, могут претендовать на соответствие другим ПЗ.
Этот случай полностью аналогичен случаю ЗБ в сопоставлении с ПЗ.
Если ЗБ соответствует ПЗ-конфигурации, а эта ПЗ-конфигурация не имеет точ­
ного соответствия, то может потребоваться соответствие ЗБ строгим и доказуемым об­
разом в зависимости от типов соответствия компонентов ПЗ-конфигурации.
Соответствие ПЗ ПЗ-конфигурации не допускается независимо от типов соответ­
ствия.
Е.2 Доказуемое соответствие
Доказуемое соответствие ориентировано на спонсора ПЗ/ПЗ-конфигурации, ко­
торому требуются доказательства того, что ЗБ является подходящим решением общей
проблемы безопасности, описанной в ПЗ/ПЗ-конфигурации.
Там, где в случае строгого соответствия существует четкая связь типа подмно­
жество-надмножество между ПЗ/ПЗ-конфигурацией и ЗБ, в случае доказуемого соот­
ветствия связь менее четкая. ЗБ, заявляющие о соответствии ПЗ/ПЗ-конфигурации,
должны предлагать решение общей проблемы безопасности, описанной в ПЗ/ПЗ-
конфигурации.
Однако заявление о соответствии допускается только в том случае, если ЗБ
налагает такие же или больше ограничений на ОО и такие же или меньше ограничений
на среду функционирования ОО.
Е.З Строгое соответствие
Строгое соответствие ориентировано на спонсора ПЗ/ПЗ-конфигурации, который
требует доказательств того, что требования в ПЗ/ПЗ-конфигурации выполнены, что ЗБ
является конкретизацией ПЗ/ПЗ-конфигурации, хотя ЗБ может быть шире, чем ПЗ/ПЗ-
конфигурация. По сути, ЗБ указывает, что ОО выполняет по меньшей мере то же са186
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
мое, что и в ПЗ/ПЗ-конфигурации, в то время как среда функционирования делает по
большей мере то же, что и в ПЗ/ПЗ-конфигурации.
Типичным примером использования строгого соответствия является закупка на
основе выбора, когда ожидается, что требования безопасности ИТ-продукта будут со­
ответствовать требованиям, указанным в ПЗ/ПЗ-конфигурации.
ЗБ, демонстрирующий строгое соответствие ПЗ/ПЗ-конфигурации, может по-
прежнему вводить дополнительные ограничения по сравнению с теми, которые указа­
ны в ПЗ/ПЗ-конфигурации.
Е.4 Точное соответствие
Е.4.1 Общие положения
Точное соответствие ориентировано на спонсора ПЗ/ПЗ-модуля, которому тре­
буются доказательства того, что требования в ПЗ/ПЗ-модуле выполнены, и что ЗБ яв­
ляется конкретизацией именно этих требований безопасности (ФТБ) без включения
дополнительных функций. По сути, ЗБ указывает, что ОО выполняет то, что требуется
ПЗ или ПЗ-конфигурацией, содержащей ПЗ-модуль, без дополнительных заявлений.
При выборе «точного» соответствия, разработчик ПЗ/ПЗ-модуля также имеет
возможность указать следующую информацию:
а) другие ПЗ, о соответствии которым ЗБ может заявлять в сочетании с рассмат­
риваемым ПЗ/ПЗ-модулем, и при этом сохранять точное соответствие;
Ь) ПЗ-модули, которые могут быть указаны с ПЗ/ПЗ-модулем, но при этом сохра­
няют точное соответствие.
Серия стандартов ИСО/МЭК 15408 допускает заявление ЗБ о точном соответ­
ствии нескольким ПЗ до тех пор, пока все ПЗ требуют точного соответствия в их раз­
решенном с заявлением и разрешают претензию с другими указанными ПЗ. Серия
стандартов ИСО/МЭК 15408 допускает заявление ЗБ о точном соответствии ПЗконфигурации при условии, что ПЗ-конфигурация требует точного соответствия, а ЗБ
не заявляют о соответствии какому-либо другому ПЗ или ПЗ-конфигурации.
Серия стандартов ИСО/МЭК 15408 также допускает заявление ПЗ о соответ­
ствии одному или нескольким ПЗ. Однако в случае, когда указанный в заявлении ПЗ
требует точного соответствия, возможность обойти намерение точного соответствия
становится ПЗ очевидной. Это связано с тем, что могут быть добавлены требования,
которые разработчики ПЗ с точным соответствием сочтут неподходящим для исполь­
зования с заявленным ПЗ.
187
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Следовательно, если ПЗ требует точного соответствия, другой ПЗ не должен
требовать какого-либо соответствия этому ПЗ. Это ограничение дает разработчику ПЗ
с точным соответствием больший контроль над функциональностью и доверием,
предоставляемыми для соответствующих ЗБ, чем ПЗ со строгим или доказуемым соот­
ветствием.
Если ЗБ может заявить одновременно о соответствии ПЗ А (который требует
точного соответствия) и ПЗ В (который требует доказуемого соответствия), это приве­
дет к появлению ФТБ, которые разработчик ПЗ А не утверждал явно для использова­
ния в комбинации с функциональностью ПЗ А, когда ЗБ заявляет о соответствии ПЗ А.
Как указано выше, для ЗБ допустимо заявление о точном соответствии многим
ПЗ с точным соответствием. Кроме того, ПЗ-конфигурация может включать несколько
компонентов (ПЗ, базовые ПЗ, ПЗ-модули и базовые ПЗ-модули), которые требуют
точного соответствия. Чтобы позволить разработчикам ПЗ контролировать, какие ком­
поненты ПЗ-конфигурации могут быть заявлены вместе с их ПЗ, в ПЗ, описанном в
В.2.3, может быть включено утверждение «разрешено», которое указывает, о соответ­
ствии каким ПЗ разработчик ЗБ может заявлять одновременно с предметным ПЗ. Все
идентифицированные ПЗ должны требовать точного соответствия в их разрешенном
утверждении, а также должны указывать предметные ПЗ и все другие ПЗ, заявленные
в их разрешенном утверждении. Такая же конфигурация используется для ПЗ-модулей
и базовых ПЗ, а также для любых базовых ПЗ-модулей, которые могут быть указаны.
Для примера ЗБ предположим, что разработчики ПЗ В хотели разрешить ЗБ за­
являть о соответствии ПЗ «В», а также разрешать заявления о соответствии ему в со­
четании с ПЗ «С». Эта ситуация приведена на рисунке Е.1.
188
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Задание по безопасности
Утверждение о соответствии
точное соответствие ПЗ «В»
точное соответствие ПЗ «С»
ПЗ «в»
ПЗ «С»
Утверждение о соответствии:
отсутствует
Утверждение о соответствии:
отсутствует
Изложение соответствия:
точное соответствие
Изложение соответствия:
точное соответствие
Утверждение «разрешено
совместно применять»:
ПЗ «С»
Утверждение «разрешено
совместно применять»:
ПЗ «В»
Рисунок Е.1 - Точное соответствие ЗБ нескольким ПЗ
Тогда должно быть верно следующее:
а) как ПЗ В, так и ПЗ С должны указывать точное соответствие в своем заявле­
нии о соответствии;
Ь)
ПЗ В указывает ПЗ С как разрешенный ПЗ В в его разрешенном заявлении;
с)
ПЗ С указывает ПЗ В как разрешенный ПЗ С в его разрешенном заявлении.
Если какое-либо из этих утверждений не выполняется, ЗБ не может претендо­
вать на точное соответствие ПЗ В и С.
Эта концепция также распространяется на ПЗ-модули и ПЗ-конфигурации. ПЗмодуль должен идентифицировать набор баз ПЗ-модуля; если одна из идентифициро­
ванных баз ПЗ-модулей имеет утверждение о точном соответствии, то все базы ПЗ-
модулей, указанные этим ПЗ-модулем, также должны иметь утверждения о соответ­
ствии с указанием точного соответствия. Кроме того, чтобы обеспечить, что ПЗ-модули
разрешены для использования с базой ПЗ-модуля, каждая база ПЗ-модулей указывает
в своем разрешенном утверждении ПЗ-модули, которым разрешено указывать ее как
базу ПЗ-модуля для использования в ПЗ-конфигурации.
Примечание - Обратное неверно; ПЗ-модулю не нужно указывать какую-либо свою базу
ПЗ-модуля в разрешенном утверждении, потому что он неявно сделал это, определив ПЗ/ПЗ-модуль как
базу ПЗ-модуля.
189
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
ПЗ-модуль также указывает, какие другие ПЗ-модули или ПЗ, которые еще не
включены как одна из баз ПЗ-модулей ПЗ-модуля, могут использоваться в комбинации
с ним в ПЗ-конфигурации.
На рисунке Е.2 показан случай точного соответствия, включающий как ПЗ, так и
ПЗ-модули.
ПЗ-конфигурация: «М»
Изложение соответствия: точное
о
$
ch
ПЗ-модуль: «X»
ПЗ-модуль: «У»
Утверждение о
соответствии: <...>
Утверждение о
соответствии: <...>
Изложение соответствия:
наследовать: точное
соответствие
Изложение соответствия:
наследовать: точное
соответствие
Утверждение «разрешено
совместно применять»:
ПЗ-модуль «У»
ПЗ «С»
Утверждение «разрешено
совместно применять»:
ПЗ-модуль «X»
ПЗ «В»
ПЗ: «В»
ПЗ: «С»
Утверждение о соответствии:
Утверждение о COOTE етствии:
Изложение соответствия:
точное соответствие
Изложение соответс вия:
точное соответствие
Утверждение «разреше/о
совместно применять)
ПЗ-модуль «X»
ПЗ-модуль «Y»
ПЗ «С» <
Утверждение «разре шено
совместно применят >»:
ПЗ-модуль «X»
ПЗ «В»
ПЗ-модуль «У»
от
си
W
0)
W
2
о
Рисунок Е.2 - Точное соответствие ПЗ-конфигурации, включающей многие ПЗ и ПЗ-
модули
190
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Е.4.2 Вопросы и ответы по точному соответствию
В таблице Е.1 приводится краткий перечень часто задаваемых вопросов о слу­
чае точного соответствия.
Таблица Е.1 - Заключение точного соответствия
ПЗ-конфигурации
Может использоваться в модульной ПЗ-конфигурации с много­
уровневым доверием?
Может использоваться в модульной ПЗ-конфигурации с един­
ственным доверием?
Можно объединять ТС с типами строгого/доказуемого соответ­
ствия?
Другие ПЗ сточным соответствием, допустимые в ПЗ- конфигу­
рации сточным соответствием
ПЗсТС
Необязательные/основанные на выборе ФТБ в ПЗ сТС
Дополнительные элементы ОПБ, связанные с необязательными
ФТБ
ПЗ с ТС заявляет о соответствии другому ПЗ с ТС ЕС?
Другие ПЗ с ТС, разрешенные в ПЗ- конфигурации с ТС
ПЗ, основанные на ПЗ со строгим или доказуемым соответстви­
ем?
Может использоваться в ПЗ со строгим или доказуемым соот­
ветствием?
Указывает, какие другие ПЗ с ТС “разрешены с”
Указывает, какие другие ПЗ-модули “разрешены с”
ПЗ-модуль с ТС
Необязательные/основанные на выборе ФТБ в ПЗ-модуле с ТС
ПЗ-модуль с ТС ЕС не включает компонентов его базы в раз­
решенное.
Указывает, какие другие ПЗ с ТС и ПЗ-модули с ТС “разрешены
с”
Все разрешенные элементы также с ТС
Функциональные пакеты с ТС ЕС
Необязательные/основанные на выборе ФТБ, разрешенные в
функциональных пакетах с ТС?
Функциональные пакеты могут увеличиваться в ЗБ?
Заявляются в заявлении ЗБ о соответствии?
ЗБ с ТС
Содержит ОПБ всех ПЗ с ТС и/или компоненты ПЗконфигурации?
Дополнительные или иерархически более высокие требования
безопасности?
Включает только те основанные на выборе требования, кото­
рые уже были выбраны?
Может использоваться с методом прямого обоснования?
Ссылка
Рисунок 5
Разрешено/требуется?
Да
Рисунок 5
Да
10.8.1
Нет
Да
12.4.1
Да
Да
10.8.1
10.4.6
10.10.3
В.3.2.2
Нет
Да
Нет
Нет
11.2.3.3 d)
Да
Да
11.2.3.3
11.2.3.3 d)
Да
Да
11.2.3.3 d)
Да
11.2.3.3 d)
Да
Да
12.2.1 d)
Нет
Нет
12.4.3
Да
12.4.4
Нет
12.4.4
Да
Да
191
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
Библиография
[1]
ISO/IEC 15408-4
Информационная безопасность, кибербезопас­
ность и защита конфиденциальности - Критерии
оценки безопасности ИТ. Часть 4. Руководство
для определения методов и мероприятий оцен­
ки
[\И1
[2]
ISO/IEC 15443
Информационные технологии. Методы и сред­
ства обеспечения безопасности. Структура до­
верия к безопасности
[3]
ISO/IEC 15446
Информационные технологии. Методы и сред­
ства обеспечения безопасности. Руководство
по разработке профилей защиты и ЗБ
[4]
ISO/IEC 18018
Информационные технологии.
Системная
и
программная инженерия. Руководство по воз­
можностям инструментов управления конфигу­
рацией
[5]
ISO/IEC 18031
Информационные технологии. Методы и сред­
ства
обеспечения
безопасности.
Генерация
случайных битов
[6]
ISO/IEC 19608
Информационные технологии. Методы и сред­
ства обеспечения безопасности. Руководство
по
разработке
функциональных требований
конфиденциальности, основанных на ИСО/МЭК
15408
[7]
ISO/IEC 19249
Информационные технологии. Методы и сред­
ства обеспечения безопасности. Каталог архи­
тектурных и проектных принципов для безопас­
ных продуктов, систем и приложений
[8]
ISO/IEC 19791
Информационные технологии. Методы и сред­
ства обеспечения безопасности. Оценка без­
опасности автоматизированных систем
192
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
[9]
ISO/IEC 19896-1
Технологии
ИТ-безопасности.
Требования
к
компетентности тестировщиков и оценщиков
информационной безопасности. Часть 1. Вве­
дение, концепции и общие требования
[Ю]
ISO/IEC 19896-3
Технологии
ИТ-безопасности.
к
Требования
компетентности тестировщиков и оценщиков
информационной безопасности. Часть 3. Тре­
бования к знаниям, навыкам и эффективности
оценщиков по ИСО/МЭК 15408
[11]
ISO/IEC 20004
Информационные технологии. Методы и сред­
ства
обеспечения
безопасности.
Уточнение
анализа уязвимостей программного обеспече­
ния по ИСО/МЭК 15408 и ИСО/МЭК 18045
[12]
ISO/IEC 22216
Информационные технологии. Методы и сред­
ства обеспечения безопасности. Вводное руко­
водство по оценке ИТ-безопасности
[13]
ISO/IEC 27001
Информационные технологии. Методы и сред­
ства обеспечения безопасности. Системы ме­
неджмента
информационной
безопасности.
Требования
[14]
ISO/IEC 27002
Информационные технологии. Методы и сред­
ства обеспечения безопасности. Свод правил
для средств и мер безопасности информации
[15]
ISO/IEC 27034
Информационные технологии. Защита прило­
жений
193
ГОСТ Р ИСО/МЭК 15408-1-20ХХ
(проект, первая редакция)
УДК 004.622:006.354
ОКС 35.020
Ключевые слова: информационная технология, критерии оценки безопасности, зада­
ние по безопасности, профиль защиты, объект оценки, функциональные возможно­
сти безопасности, доверие к безопасности
194