ГОСТЕХКОМИССИЯ РОССИИ
РУКОВОДЯЩИЙ ДОКУМЕНТ
БЕЗОПАСНОСТЬ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ
Критерии оценки безопасности информационных технологий
Часть 3. Требования доверия к безопасности
2002
СОДЕРЖАНИЕ
1 Область применения 1
1.1 Структура 1
1.2 Парадигма доверия 1
2 Требования доверия к безопасности 4
2.1 Структуры 4
2.2 Классификация компонентов 12
2.3 Структура класса критериев оценки профиля защиты и задания по безопасности 12
2.4 Использование терминов в части 3 ОК 12
2.5 Классификация доверия 14
2.6 Краткий обзор классов и семейств доверия 14
2.7 Классификация поддержки 20
2.8 Краткий обзор класса и семейств поддержки доверия 20
3 Критерии оценки профиля защиты и задания по безопасности 22
3.1 Краткий обзор 22
3.2 Краткий обзор критериев профиля защиты 22
3.3 Краткий обзор критериев задания по безопасности 23
4 Класс APE. Оценка профиля защиты 25
4.1 Описание ОО (APE_DES) 25
4.2 Среда безопасности (APE_ENV) 26
4.3 Введение ПЗ (APE_INT) 27
4.4 Цели безопасности (APE_OBJ) 27
4.5 Требования безопасности ИТ (APE_REQ) 29
4.6 Требования безопасности ИТ, сформулированные в явном виде (APE_SRE) 31
5 Класс ASE. Оценка задания по безопасности 33
5.1 Описание ОО (ASE_DES) 34
5.2 Среда безопасности (ASE_ENV) 34
5.3 Введение ЗБ (ASE_INT) 35
5.4 Цели безопасности (ASE_OBJ) 36
5.5 Утверждения о соответствии ПЗ (ASE_PPC) 37
5.6 Требования безопасности ИТ (ASE_REQ) 38
5.7 Требования безопасности ИТ, сформулированные в явном виде (ASE_SRE) 40
5.8 Краткая спецификация ОО (ASE_TSS) 42
6 Оценочные уровни доверия 45
6.1 Краткий обзор оценочных уровней доверия (ОУД) 45
6.2 Детализация оценочных уровней доверия 46
8 Классы, семейства и компоненты доверия 59
9 Класс ACM. Управление конфигурацией 60
9.1 Автоматизация УК (ACM_AUT) 60
9.2 Возможности УК (ACM_CAP) 63
9.3 Область УК (ACM_SCP) 70
10 Класс ADO. Поставка и эксплуатация 74
10.1 Поставка (ADO_DEL) 74
10.2 Установка, генерация и запуск (ADO_IGS) 76
11 Класс ADV. Разработка 79
11.1 Функциональная спецификация (ADV_FSP) 83
11.2 Проект верхнего уровня (ADV_HLD) 87
11.3 Представление реализации (ADV_IMP) 93
11.4 Внутренняя структура ФБО (ADV_INT) 96
11.5 Проект нижнего уровня (ADV_LLD) 100
11.6 Соответствие представлений (ADV_RCR) 104
11.7 Моделирование политики безопасности (ADV_SPM) 107
12 Класс AGD. Руководства 111
12.1 Руководство администратора (AGD_ADM) 111
12.2 Руководство пользователя (AGD_USR) 112
13 Класс ALC. Поддержка жизненного цикла 115
13.1 Безопасность разработки (ALC_DVS) 115
13.2 Устранение недостатков (ALC_FLR) 117
13.3 Определение жизненного цикла (ALC_LCD) 120
13.4 Инструментальные средства и методы (ALC_TAT) 123
14 Класс ATE. Тестирование 126
14.1 Покрытие (ATE_COV) 127
14.2 Глубина (ATE_DPT) 130
14.3 Функциональное тестирование (ATE_FUN) 133
14.4 Независимое тестирование (ATE_IND) 136
15 Класс AVA. Оценка уязвимостей 141
15.1 Анализ скрытых каналов (AVA_CCA) 141
15.2 Неправильное применение (AVA_MSU) 145
15.3 Стойкость функций безопасности ОО (AVA_SOF) 149
15.4 Анализ уязвимостей (AVA_VLA) 150
16 Парадигма поддержки доверия 157
16.1 Введение 157
16.2 Цикл поддержки доверия 158
16.3 Класс и семейства поддержки доверия 161
17 Класс AMA. Поддержка доверия 166
17.1 План поддержки доверия (AMA_AMP) 166
17.2 Отчет о категорировании компонентов ОО (AMA_CAT) 168
17.3 Свидетельство поддержки доверия (AMA_EVD) 170
17.4 Анализ влияния на безопасность (AMA_SIA) 172
Приложение А
(справочное)
Перекрестные ссылки между компонентами доверия 176
Приложение Б
(справочное)
Перекрестные ссылки ОУД и компонентов доверия 178
1Область применения
Эта часть ОК определяет требования доверия к безопасности и включает в себя оценочные уровни доверия (ОУД), определяющие шкалу для измерения доверия, собственно компоненты доверия, из которых составлены уровни доверия, и критерии для оценки ПЗ и ЗБ.
1.1Структура
Часть 3 ОК состоит из следующих разделов:
1 – введение и парадигма;
2 – структура представления классов, семейств и компонентов доверия, оценочных уровней доверия и их взаимосвязь, а также краткая характеристика классов и семейств доверия, представленных в разделах 8–14;
3–5 – краткое введение в критерии оценки ПЗ и ЗБ, сопровождаемое детализированными объяснениями семейств и компонентов, которые применяют для этих оценок;
6 – детализированные определения оценочных уровней доверия;
7 – краткое введение в классы доверия;
8–14 – детализированные определения классов доверия;
15–16 – краткое введение в критерии оценки поддержки доверия с детализированными определениями применяемых семейств и компонентов.
Приложение A содержит сводку зависимостей между компонентами доверия.
Приложение Б содержит перекрестные ссылки между ОУД и компонентами доверия.
1.2Парадигма доверия
Цель данного подраздела состоит в изложении основных принципов и подходов к установлению доверия к безопасности. Данный подраздел позволит читателю понять логику построения требований доверия в ОК.
1.2.1Основные принципы ОК
Основные принципы ОК состоят в том, что следует четко сформулировать угрозы безопасности и положения политики безопасности организации, а достаточность предложенных мер безопасности должна быть продемонстрирована.
Более того, следует предпринять меры по уменьшению вероятности наличия уязвимостей, возможности их проявления (т.е. преднамеренного использования или непреднамеренной активизации), а также степени ущерба, который может явиться следствием проявления уязвимостей. Дополнительно следует предпринять меры для облегчения последующей идентификации уязвимостей, а также по их устранению, ослаблению и/или оповещению об их использовании или активизации.
1.2.2Подход к доверию
Основная концепция ОК – обеспечение доверия, основанное на оценке (активном исследовании) продукта или системы ИТ, которым предполагается доверять. Оценка была традиционным способом обеспечения доверия и являлась основой предшествующих критериев оценки. Для согласования с существующими подходами в ОК принят тот же самый основной принцип. ОК предполагают, что проверку правильности документации и разработанного продукта или системы ИТ будут проводить опытные оценщики, уделяя особое внимание области, глубине и строгости оценки.
ОК не отрицают и при этом не комментируют относительные достоинства других способов получения доверия. Продолжаются исследования альтернативных путей достижения доверия. Если в результате этих исследований будут выявлены другие отработанные альтернативные подходы, то они могут в дальнейшем быть включены в ОК, которые структурно организованы так, что предусматривают такую возможность.
1.2.2.1Значимость уязвимостей
Предполагается, что имеются нарушители, которые будут пытаться активно использовать возможности нарушения политики безопасности как для получения незаконной выгоды, так и для незлонамеренных, но, тем не менее, опасных действий. Нарушители могут также случайно активизировать уязвимости безопасности, нанося вред организации. При необходимости обрабатывать чувствительную информацию и отсутствии в достаточной степени доверенных продуктов или систем имеется значительный риск из-за отказов ИТ. Поэтому нарушения безопасности ИТ могут вызвать значительные потери.
Нарушения безопасности ИТ возникают вследствие преднамеренного использования или случайной активизации уязвимостей при применении ИТ по назначению.
Следует предпринять ряд шагов для предотвращения уязвимостей, возникающих в продуктах и системах ИТ. По возможности уязвимости должны быть:
а) устранены, т.е. следует предпринять активные действия для выявления, а затем удаления или нейтрализации всех уязвимостей, которые могут проявиться;
б) минимизированы, т.е. следует предпринять активные действия для уменьшения до допустимого остаточного уровня возможного ущерба от любого проявления уязвимостей;
в) отслежены, т.е. следует предпринять активные действия для обнаружения любой попытки использовать оставшиеся уязвимости с тем, чтобы ограничить ущерб.
1.2.2.2Причины уязвимостей
Уязвимости могут возникать из-за недостатков:
а) требований, т.е. продукт или система ИТ могут обладать требуемыми от них функциями и свойствами, но все же содержать уязвимости, которые делают их непригодными или неэффективными в части безопасности;
б) проектирования, т.е. продукт или система ИТ не отвечают спецификации, и/или уязвимости являются следствием некачественных стандартов проектирования или неправильных проектных решений;
в) эксплуатации, т.е. продукт или система ИТ разработаны в полном соответствии с корректными спецификациями, но уязвимости возникают как результат неадекватного управления при эксплуатации.
1.2.2.3Доверие в ОК
Доверие – основа для уверенности в том, что продукт или система ИТ отвечают целям безопасности. Доверие могло бы быть получено путем обращения к таким источникам, как бездоказательное утверждение, предшествующий аналогичный опыт или специфический опыт. Однако ОК обеспечивают доверие с использованием активного исследования. Активное исследование – это оценка продукта или системы ИТ для определения его свойств безопасности.
1.2.2.4Доверие через оценку
Оценка является традиционным способом достижения доверия, и она положена в основу ОК. Методы оценки могут, в частности, включать в себя:
а) анализ и проверку процессов и процедур;
б) проверку, что процессы и процедуры действительно применяются;
в) анализ соответствия между представлениями проекта ОО;
г) анализ соответствия каждого представления проекта ОО требованиям;
д) верификацию доказательств;
е) анализ руководств;
ж) анализ разработанных функциональных тестов и полученных результатов;
и) независимое функциональное тестирование;
к) анализ уязвимостей, включающий предположения о недостатках;
л) тестирование проникновения.
1.2.3Шкала оценки доверия в ОК
Основные принципы ОК содержат утверждение, что большее доверие является результатом приложения больших усилий при оценке, и что цель состоит в применении минимальных усилий, требуемых для обеспечения необходимого уровня доверия. Повышение уровня усилий может быть основано на:
а) области охвата, т.е. увеличении рассматриваемой части продукта или системы ИТ;
б) глубине, т.е. детализации рассматриваемых проектных материалов и реализации;
в) строгости, т.е. применении более структурированного и формального подхода.
2Требования доверия к безопасности
2.1Структуры
Следующие подразделы описывают конструкции, используемые в представлении классов, семейств и компонентов доверия, оценочных уровней доверия (ОУД), и их взаимосвязь.
На рисунке 2.1 показаны требования доверия, определенные в части 3 ОК. Наиболее общую совокупность требований доверия называют классом. Каждый класс содержит семейства доверия, которые разделены на компоненты доверия, содержащие, в свою очередь, элементы доверия. Классы и семейства используют для обеспечения таксономии классифицируемых требований доверия, в то время как компоненты применяют непосредственно для спецификации требований доверия в ПЗ/ЗБ.
2.1.1Структура класса
Рисунок 2.1 иллюстрирует структуру класса доверия.
2.1.1.1Имя класса
Каждому классу доверия присвоено уникальное имя. Имя указывает на тематические разделы, на которые распространяется данный класс доверия.
Представлена также уникальная краткая форма имени класса доверия. Она является основным средством для ссылки на класс доверия. Принятое условное обозначение включает в себя букву "A", за которой следуют еще две буквы латинского алфавита, относящиеся к имени класса.
2.1.1.2Представление класса
Каждый класс доверия имеет вводный подраздел, в котором описаны состав и назначение класса.
2.1.1.3Семейства доверия
Каждый класс доверия содержит, по меньшей мере, одно семейство доверия. Структура семейств доверия описана в следующем пункте.
Рисунок 2.1 – Иерархическая структура представления требований доверия: класс-семейство-компонент-элемент
2.1.2Структура семейства доверия
Рисунок 2.1 иллюстрирует структуру семейства доверия.
2.1.2.1Имя семейства
Каждому семейству доверия присвоено уникальное имя. Имя содержит описательную информацию по тематическим разделам, на которые распространяется данное семейство доверия. Каждое семейство доверия размещено в пределах класса доверия, который содержит другие семейства той же направленности.
Представлена также уникальная краткая форма имени семейства доверия. Она является основным средством для ссылки на семейство доверия. Принятое условное обозначение включает в себя краткую форму имени класса и символ подчеркивания, за которым следуют три буквы латинского алфавита, относящиеся к имени семейства.
2.1.2.2Цели
Подраздел целей семейства доверия представляет назначение семейства доверия.
В нем описаны цели, для достижения которых предназначено семейство, особенно связанные с парадигмой доверия ОК. Описание целей для семейства доверия представлено в общем виде. Любые конкретные подробности, требуемые для достижения целей, включены в конкретный компонент доверия.
2.1.2.3Ранжирование компонентов
Каждое семейство доверия содержит один или несколько компонентов доверия. Этот подраздел семейства доверия содержит описание имеющихся компонентов и объяснение их разграничения. Его основная цель состоит в указании различий между компонентами при принятии решения о том, что семейство является необходимой или полезной частью требований доверия для ПЗ/ЗБ.
В семействах доверия, содержащих более одного компонента, выполнено ранжирование компонентов и приведено его обоснование. Это обоснование сформулировано в терминах области применения, глубины и/или строгости.
2.1.2.4Замечания по применению
Необязательный подраздел замечаний по применению семейства доверия содержит дополнительную информацию о семействе. Эта информация предназначена непосредственно для пользователей семейства доверия (например, разработчиков ПЗ и ЗБ, проектировщиков ОО, оценщиков). Представление неформально и включает в себя, например, предупреждения об ограничениях использования или областях, требующих особого внимания.
2.1.2.5Компоненты доверия
Каждое семейство содержит хотя бы один компонент доверия. Структура компонентов доверия представлена в следующем пункте.
2.1.3Структура компонента доверия
Р
исунок 2.2 иллюстрирует структуру компонента доверия.
Рисунок 2.2 – Структура компонента доверия
Связь между компонентами внутри семейства показана с использованием соглашения о шрифтовом выделении. Для частей требований, которые являются новыми, расширенными или модифицированными по сравнению с требованиями предыдущего по иерархии компонента, применен полужирный шрифт. Такое же соглашение о шрифтовом выделении использовано и для зависимостей.
2.1.3.1Идентификация компонента
Подраздел идентификации компонента содержит описательную информацию, необходимую для идентификации, категорирования, регистрации и ссылок на компонент.
Каждому компоненту доверия присвоено уникальное имя. Имя содержит информацию о тематических разделах, на которые распространяется компонент доверия. Каждый компонент входит в состав конкретного семейства доверия, с которым имеет общую цель безопасности.
Представлена также уникальная краткая форма имени компонента доверия как основной способ ссылки на компонент. Принято, что за краткой формой имени семейства ставится точка, а затем цифра. Цифры для компонентов внутри каждого семейства назначены последовательно, начиная с единицы.
2.1.3.2Цели
Необязательный подраздел целей компонента доверия содержит конкретные цели этого компонента. Для компонентов доверия, которые имеют этот подраздел, он включает в себя конкретное назначение данного компонента и подробное разъяснение целей.
2.1.3.3Замечания по применению
Необязательный подраздел замечаний по применению компонента доверия содержит дополнительную информацию для облегчения использования компонента.
2.1.3.4Зависимости
Зависимости среди компонентов доверия возникают, когда компонент не самодостаточен, а предполагает присутствие другого компонента.
Для каждого компонента доверия приведен полный список зависимостей от других компонентов доверия. При отсутствии у компонента идентифицированных зависимостей вместо списка указано: "Зависимости отсутствуют". Компоненты из списка могут, в свою очередь, иметь зависимости от других компонентов.
Список зависимостей определяет минимальный набор компонентов доверия, на которые следует полагаться. Компоненты, которые иерархичны по отношению к компоненту из списка зависимостей, также могут использоваться для удовлетворения зависимости.
В отдельных ситуациях обозначенные зависимости могут быть неприменимы. Разработчик ПЗ/ЗБ может отказаться от удовлетворения зависимости, представив обоснование, почему данная зависимость неприменима.
2.1.3.5Элементы доверия
Каждый компонент доверия содержит набор элементов доверия. Элемент доверия – требование безопасности, при дальнейшем разделении которого не изменяется значимый результат оценки. Он является наименьшим требованием безопасности, распознаваемым в ОК.
Каждый элемент доверия принадлежит к одному из трех типов.
а) Элементы действий разработчика, определяющие действия, которые должны выполняться разработчиком. Этот набор действий далее уточняется доказательным материалом, упоминаемым в следующем наборе элементов. Требования к действиям разработчика обозначены буквой "D" после номера элемента.
б) Элементы содержания и представления свидетельств, определяющие требуемые свидетельства и отражаемую в них информацию. Требования к содержанию и представлению свидетельств обозначены буквой "C" после номера элемента.
в) Элементы действий оценщика, определяющие действия, которые должны выполняться оценщиком. Этот набор действий непосредственно включает в себя подтверждение того, что требования, предписанные элементами содержания и представления свидетельств, выполнены, а также конкретные действия и анализ, выполняемые в дополнение к уже проведенным разработчиком. Должны также выполняться не указанные явно действия оценщика, необходимые вследствие элементов действий разработчика, но не охваченные в требованиях к содержанию и представлению свидетельств. Требования к действиям оценщика обозначены буквой "E" после номера элемента.
Действия разработчика, содержание и представление свидетельств определяют требования, предъявляемые к разработчику по демонстрации доверия к ФБО. Выполняя эти требования, разработчик может повысить уверенность в том, что ОО удовлетворяет функциональным требованиям и требованиям доверия из ПЗ или ЗБ.
Действия оценщика определяют его ответственность по двум аспектам. Первый аспект – проверка правильности ПЗ/ЗБ в соответствии с требованиями классов APE/ASE из разделов 4 и 5. Второй аспект – верификация соответствия ОО его функциональным требованиям и требованиям доверия. Демонстрируя, что ПЗ/ЗБ правильны, и их требования выполняются ОО, оценщик может предоставить основание для уверенности в том, что ОО будет отвечать поставленным целям безопасности.
Элементы действий разработчика, элементы содержания и представления свидетельств и элементы установленных действий оценщика определяют уровень его усилий, которые должны быть приложены при верификации утверждений о безопасности, сформулированных в ЗБ конкретного ОО.
2.1.4Элементы доверия
Каждый элемент представляет собой требование для выполнения. Формулировки этих требований должны быть четкими, краткими и однозначными. Поэтому в требованиях отсутствуют составные предложения. Каждое требование изложено как отдельный элемент.
В тексте элементов использованы, как правило, термины, имеющие обычное словарное значение, которые не могут привести к неоднозначному толкованию требований.
В отличие от функциональных элементов из части 2 ОК к элементам доверия из части 3 ОК не применимы операции назначения и выбора; однако, при необходимости, допустимо применение операции уточнения.
2.1.5Структура ОУД
Рисунок 2.3 иллюстрирует ОУД и их структуру, определенную в части 3 ОК. Компоненты доверия, содержание которых показано на рисунке, включены в ОУД посредством ссылок на компоненты, приведенные в части 3 ОК.
2.1.5.1Имя ОУД
Каждому ОУД присвоено уникальное имя. Имя представляет описательную информацию о предназначении ОУД.
Представлена также уникальная краткая форма имени ОУД. Она является основным средством ссылки на ОУД.
2.1.5.2Цели
В подразделе целей ОУД приведено назначение ОУД.
2.1.5.3Замечания по применению
Необязательный подраздел замечаний по применению ОУД содержит информацию, представляющую интерес для пользователей ОУД (например, для разработчиков ПЗ и ЗБ, проектировщиков ОО, планирующих использование этого ОУД, оценщиков). Представление неформально и включает в себя, например, предупреждения об ограничениях использования или областях, требующих особого внимания.
Р
исунок 2.3 – Структура ОУД
2.1.5.4Компоненты доверия
Для каждого ОУД выбран набор компонентов доверия.
Более высокий уровень доверия, чем предоставляемый данным ОУД, может быть достигнут:
а) включением дополнительных компонентов доверия из других семейств доверия;
б) заменой компонента доверия иерархичным компонентом из этого же семейства доверия.
2.1.6Связь между требованиями и уровнями доверия
Рисунок 2.4 иллюстрирует связь между требованиями и уровнями доверия, определенными в части 3 ОК. Компоненты доверия состоят из элементов, но последние не могут по отдельности быть включены в уровни доверия. Стрелка на рисунке отображает ссылку в ОУД на компонент доверия внутри класса, где он определен.
Рисунок 2.4 – Связь требований и уровня доверия
2.2Классификация компонентов
|
