ГОСТЕХКОМИССИЯ РОССИИ

РУКОВОДЯЩИЙ ДОКУМЕНТ

БЕЗОПАСНОСТЬ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

Критерии оценки безопасности информационных технологий

Часть 3. Требования доверия к безопасности

2002

2.1.3 Структура компонента доверия

Рисунок 2.2 иллюстрирует структуру компонента доверия.

Рисунок 2.2 - Структура компонента доверия

Связь между компонентами внутри семейства показана с использованием соглашения о шрифтовом выделении. Для частей требований, которые являются новыми, расширенными или модифицированными по сравнению с требованиями предыдущего по иерархии компонента, применен полужирный шрифт. Такое же соглашение о шрифтовом выделении использовано и для зависимостей.

2.1.3.1    Идентификация компонента

Подраздел идентификации компонента содержит описательную информацию, необходимую для идентификации, категорирования, регистрации и ссылок на компонент.

Каждому компоненту доверия присвоено уникальное имя. Имя содержит информацию о тематических разделах, на которые распространяется компонент доверия. Каждый компонент входит в состав конкретного семейства доверия, с которым имеет общую цель безопасности.

Представлена также уникальная краткая форма имени компонента доверия как основной способ ссылки на компонент. Принято, что за краткой формой имени семейства ставится точка, а затем цифра. Цифры для компонентов внутри каждого семейства назначены последовательно, начиная с единицы.

2.1.3.2    Цели

Необязательный подраздел целей компонента доверия содержит конкретные цели этого компонента. Для компонентов доверия, которые имеют этот подраздел, он включает в себя конкретное назначение данного компонента и подробное разъяснение целей.

2.1.3.3    Замечания по применению

Необязательный подраздел замечаний по применению компонента доверия содержит дополнительную информацию для облегчения использования компонента.

7

2.1.3.4    Зависимости

Зависимости среди компонентов доверия возникают, когда компонент не самодостаточен, а предполагает присутствие другого компонента.

Для каждого компонента доверия приведен полный список зависимостей от других компонентов доверия. При отсутствии у компонента идентифицированных зависимостей вместо списка указано: "Зависимости отсутствуют". Компоненты из списка могут, в свою очередь, иметь зависимости от других компонентов.

Список зависимостей определяет минимальный набор компонентов доверия, на которые следует полагаться. Компоненты, которые иерархичны по отношению к компоненту из списка зависимостей, также могут использоваться для удовлетворения зависимости.

В отдельных ситуациях обозначенные зависимости могут быть неприменимы. Разработчик ПЗ/ЗБ может отказаться от удовлетворения зависимости, представив обоснование, почему данная зависимость неприменима.

2.1.3.5    Элементы доверия

Каждый компонент доверия содержит набор элементов доверия. Элемент доверия -требование безопасности, при дальнейшем разделении которого не изменяется значимый результат оценки. Он является наименьшим требованием безопасности, распознаваемым в ОК.

Каждый элемент доверия принадлежит к одному из трех типов.

а)    Элементы действий разработчика, определяющие действия, которые должны выполняться разработчиком. Этот набор действий далее уточняется доказательным материалом, упоминаемым в следующем наборе элементов. Требования к действиям разработчика обозначены буквой "D" после номера элемента.

б)    Элементы содержания и представления свидетельств, определяющие требуемые свидетельства и отражаемую в них информацию. Требования к содержанию и представлению свидетельств обозначены буквой "С" после номера элемента.

в)    Элементы действий оценщика, определяющие действия, которые должны выполняться оценщиком. Этот набор действий непосредственно включает в себя подтверждение того, что требования, предписанные элементами содержания и представления свидетельств, выполнены, а также конкретные действия и анализ, выполняемые в дополнение к уже проведенным разработчиком. Должны также выполняться не указанные явно действия оценщика, необходимые вследствие элементов действий разработчика, но не охваченные в требованиях к содержанию и представлению свидетельств. Требования к действиям оценщика обозначены буквой "Е" после номера элемента.

Действия разработчика, содержание и представление свидетельств определяют требования, предъявляемые к разработчику по демонстрации доверия к ФБО. Выполняя эти требования, разработчик может повысить уверенность в том, что 00 удовлетворяет функциональным требованиям и требованиям доверия из ПЗ или ЗБ.

Действия оценщика определяют его ответственность по двум аспектам. Первый аспект - проверка правильности ПЗ/ЗБ в соответствии с требованиями классов APE/ASE из

разделов 4 и 5. Второй аспект - верификация соответствия 00 его функциональным требованиям и требованиям доверия. Демонстрируя, что ПЗ/ЗБ правильны, и их требования выполняются 00, оценщик может предоставить основание для уверенности в том, что 00 будет отвечать поставленным целям безопасности.

Элементы действий разработчика, элементы содержания и представления свидетельств и элементы установленных действий оценщика определяют уровень его усилий, которые должны быть приложены при верификации утверждений о безопасности, сформулированных в ЗБ конкретного 00.

2.1.4 Элементы доверия

Каждый элемент представляет собой требование для выполнения. Формулировки этих требований должны быть четкими, краткими и однозначными. Поэтому в требованиях отсутствуют составные предложения. Каждое требование изложено как отдельный элемент.

В тексте элементов использованы, как правило, термины, имеющие обычное словарное значение, которые не могут привести к неоднозначному толкованию требований.

В отличие от функциональных элементов из части 2 ОК к элементам доверия из части 3 ОК не применимы операции назначения и выбора; однако, при необходимости, допустимо применение операции уточнения.

2.1.5 Структура ОУД

Рисунок 2.3 иллюстрирует ОУД и их структуру, определенную в части 3 ОК. Компоненты доверия, содержание которых показано на рисунке, включены в ОУД посредством ссылок на компоненты, приведенные в части 3 ОК.

2.1.5.1    Имя ОУД

Каждому ОУД присвоено уникальное имя. Имя представляет описательную информацию о предназначении ОУД.

Представлена также уникальная краткая форма имени ОУД. Она является основным средством ссылки на ОУД.

2.1.5.2    Цели

В подразделе целей ОУД приведено назначение ОУД.

2.1.5.3    Замечания по применению

Необязательный подраздел замечаний по применению ОУД содержит информацию, представляющую интерес для пользователей ОУД (например, для разработчиков ПЗ и ЗБ, проектировщиков 00, планирующих использование этого ОУД, оценщиков). Представление неформально и включает в себя, например, предупреждения об ограничениях использования или областях, требующих особого внимания.

9

2.1.5.4    Компоненты доверия

Для каждого ОУД выбран набор компонентов доверия.

Более высокий уровень доверия, чем предоставляемый данным ОУД, может быть достигнут:

а)    включением дополнительных компонентов доверия из других семейств доверия;

б)    заменой компонента доверия иерархичным компонентом из этого же семейства доверия.

2.1.6 Связь между требованиями и уровнями доверия

Рисунок 2.4 иллюстрирует связь между требованиями и уровнями доверия, определенными в части 3 ОК. Компоненты доверия состоят из элементов, но последние не могут

2.2 Классификация компонентов

Часть 3 ОК содержит классы семейств и компонентов, которые сгруппированы на основе, связанной с доверием. В начале каждого класса представлена диаграмма, которая указывает семейства в классе и компоненты в каждом семействе.

На рисунке 2.5 показан класс, содержащий одно семейство. Семейство содержит три компонента, которые являются линейно иерархичными (т.е. компонент 2 содержит более высокие требования, чем компонент 1, к конкретным действиям, приводимым свидетельствам или строгости действий и/или свидетельств). Все семейства доверия в части 3 ОК - линейно иерархичные, хотя линейность не обязательна для семейств доверия, которые могут быть добавлены в дальнейшем.

Рисунок 2.5 - Образец декомпозиции класса

2.3    Структура класса критериев оценки профиля защиты и зада

ния по безопасности

Требования для оценки профиля защиты и задания по безопасности трактуют как классы доверия, структура которых подобна структуре других классов доверия, описанных ниже. Отличие заключается в отсутствии подраздела ранжирования компонентов в описаниях семейств и вызвано тем, что каждое семейство имеет только один компонент.

В таблицах 3.1-3.4 приведены названия каждого из классов АРЕ и ASE, составляющих их семейств и их краткие имена. Содержание разделов ПЗ, рассматриваемых в семействах класса АРЕ, представлено в части 1 ОК, приложение Б, подразделы Б.2.2-Б.2.6, а разделов ЗБ, рассматриваемых в семействах класса ASE, - в части 1 ОК, приложение В, подразделы В.2.2-В.2.8.

2.4    Использование терминов в части 3 ОК

В части 3 ОК определенным образом используются термины, список которых приведен ниже. Они не включены в глоссарий ОК (раздел 2 части 1 ОК), потому что являются общеупотребительными терминами, и их использование, хотя и ограничено приведенными разъяснениями, согласуется со словарными определениями. Однако именно такое толкование терминов применялось при разработке части 3 ОК, и поэтому оно полезно для понимания. В скобках приведены эквиваленты терминов на английском языке.

верифицировать(уепГу): Аналогичен термину "подтверждать" ("confirm"), но имеет более глубокий смысл. При использовании в контексте действий оценщика указывает, что требуются независимые усилия оценщика.

взаимно поддерживающие (mutually supportive): Описывает взаимосвязь в группе сущностей, указывая, что последние обладают некоторыми свойствами, которые не находятся в противоречии со свойствами других сущностей и могут способствовать выполнению другими сущностями их задач. Нет необходимости определять, что каждая из рас-

сматриваемых отдельных сущностей непосредственно поддерживает другие сущности в этой группе; достаточно, если сделано обобщенное заключение.

внутренне непротиворечивый (internally consistent): Отсутствуют очевидные противоречия между любыми аспектами сущности. Применительно к документации это означает, что в ней не может быть изложено что-либо, что может быть воспринято как противоречащее чему-то другому.

делать (независимое) заключение (determine): Требуется независимый анализ для достижения конкретного заключения. Термин отличается от "подтверждать"("сопТ1гш") или "Bepnc[m4HpoBaTb"("verify"), так как последние подразумевают, что требует проверки анализ, проведенный ранее, в то время как "делать (независимое) заключение" подразумевает совершенно независимый анализ, обычно при отсутствии любого предшествующего анализа.

демонстрировать (demonstrate): Относится к анализу, который приводит к заключению, но является менее строгим, чем "доказательство" ("proof).

доказывать (prove): Относится к формальному анализу в математическом смысле, полностью строгий во всех отношениях. Обычно используется, когда желательно показать соответствие между двумя представлениями ФБО на высоком уровне строгости.

исчерпывающий (exhaustive): Используется применительно к проведению анализа или другой деятельности. Аналогичен термину "систематический" ("systematic"), но более точен, так как указывает не только на то, что в соответствии с некоторым конкретным планом проведения анализа или другой деятельности был применен методический подход, но также и на то, что этот план достаточен для обеспечения проведения исследования по всем возможным направлениям.

логически упорядоченный (coherent): Сущность логически упорядочена и имеет очевидный смысл. Применительно к документации этот термин относится как к тексту, так и к структуре, указывая, что они понятны потенциальной аудитории.

непротиворечивый (consistent): Описывает связь между двумя или более сущностями, указывая, что между ними нет никаких явных противоречий.

обеспечивать (ensure): Подразумевает сильную причинно-следственную связь между некоторым действием и его последствиями. Часто ему предшествует термин "способствует" ("helps"), указывающий, что одно данное действие не полностью определяет последствия.

объяснять (explain): Отличается от терминов "описывать" ("describe") и "демонстрировать" ("demonstrate"). Предназначен для ответа на вопрос "Почему?" без попытки аргументировать, что ход предпринимаемых действий обязательно оптимален.

описывать (describe): Требует, чтобы некоторые конкретные подробности сущности были представлены.

подтверждать (confirm): Используется для указания необходимости подробного рассмотрения чего-либо; при этом требуется независимое заключение о его достаточности. Требуемый уровень строгости зависит от характера предмета. Применим только к действиям оценщика.

полный (complete): Представлены все необходимые составляющие сущности. Применительно к документации это означает, что приведена вся необходимая информация, причем настолько детально, что на данном уровне абстракции дальнейшие пояснения не требуются.

проверять (check): Аналогичен, но менее строг, чем "подтверждать"("confirm") или "верифицировать"("verify"). Требует, чтобы оценщиком было сделано оперативное заключение, возможно лишь с поверхностным анализом или вообще без него.

прослеживать или сопоставлять (trace): Используется для указания, что между двумя сущностями требуется только минимальный уровень строгости неформального соответствия.

противостоять (counter): Используется в том смысле, что некоторая цель безопасности заключается в противостоянии конкретной угрозе, но не обязательно указывает в итоге на полную ее ликвидацию.

специфицировать или определять (specify): Используется в том же контексте, что и "описывать" ("describe"), но является более строгим и точным. Аналогичен термину "определять" ("define").

строгое обоснование (justification): Относится к анализу, ведущему к заключению, но является более строгим, чем термин "демонстрация" ("demonstration"), в смысле точных и подробных объяснений каждого шага логических суждений.

2.5    Классификация доверия

Классы и семейства доверия, а также их краткие имена приведены в таблице 2.1.

2.6    Краткий обзор классов и семейств доверия

Ниже приведены краткие характеристики классов и семейств доверия из разделов 8-

14.

2.6.1 Класс ACM: Управление конфигурацией

Управление конфигурацией (УК) помогает обеспечить сохранение целостности 00, устанавливая и контролируя определенный порядок процессов уточнения и модификации 00 и предоставления связанной с ними информации. УК предотвращает несанкционированную модификацию, добавление или уничтожение составляющих 00, обеспечивая тем самым доверие, что оцениваются именно те 00 и документация, которые подготовлены к распространению.

14

Класс доверия	Семейство доверия	Краткое имя
ACM-Управление конфигурацией	Автоматизация УК	ACM AUT
	Возможности УК	ACM CAP
	Область УК	ACM SCP
ADO-Поставка и эксплуатация	Поставка	ADO DEL
	Установка, генерация и запуск	ADO IGS
ADV -Разработка	Функциональная спецификация	ADV FSP
	Проект верхнего уровня	ADV HLD
	Представление реализации	ADV IMP
	Внутренняя структура ФБО	ADV INT
	Проект нижнего уровня	ADV LLD
	Соответствие представлений	ADV RCR
	Моделирование политики безопасности	AD VS PM
AGD -Руководства	Руководство администратора	AGD ADM
	Руководство пользователя	AGD USR
ALC -Поддержка жизненного цикла	Безопасность разработки	ALC DVS
	Устранение недостатков	ALC FLR
	Определение жизненного цикла	ALC LCD
	Инструментальные средства и методы	ALC TAT
АТЕ- Тестирование	Покрытие	ATE COV
	Глубина	ATE DPT
	Функциональное тестирование	ATE FUN
	Независимое тестирование	ATE IND
AVA-Оценка уязвимостей	Анализ скрытых каналов	AVA CCA
	Неправильное применение	AVA MSU
	Стойкость функций безопасности 00	AVA SOF
	Анализ уязвимостей	AVA VLA

2.6.1.1    Автоматизация УК (ACM_AUT)

Семейство "Автоматизация управления конфигурацией" устанавливает уровень автоматизации, используемый для управления элементами конфигурации.

2.6.1.2    Возможности УК (АСМ_САР)

Семейство "Возможности управления конфигурацией" определяет характеристики системы управления конфигурацией.

2.6.1.3    Область УК (ACM_SCP)

Семейство "Область управления конфигурацией" указывает на те элементы 00, для которых необходим контроль со стороны системы управления конфигурацией.

15

2.6.2 Класс ADO. Поставка и эксплуатация

Класс доверия ADO определяет требования к мерам, процедурам и стандартам, применяемым для безопасной поставки, установки и эксплуатации 00, обеспечивая, чтобы безопасность 00 не нарушалась во время его распространения, установки и эксплуатации.

2.6.2.1    Поставка (ADO_DEL)

Семейство "Поставка" распространяется на процедуры, используемые для поддержки безопасности во время передачи 00 пользователю при первоначальной поставке и последующих модификациях. Оно включает в себя специальные процедуры или действия, необходимые для демонстрации подлинности поставленного 00. Такие процедуры и меры - основа обеспечения безопасности 00 во время передачи. Несмотря на то, что при оценке 00 не всегда может быть определено его соответствие требованиям поставки, можно оценить процедуры, предусмотренные разработчиком для распространения 00 пользователям.

2.6.2.2    Установка, генерация и запуск (ADOJGS)

Семейство "Установка, генерация и запуск" предусматривает, чтобы копия 00 была конфигурирована и активизирована администратором так, чтобы показать те же самые свойства защиты, что и у оригинала 00. Процедуры установки, генерации и запуска предоставляют уверенность в том, что администратор будет осведомлен о параметрах конфигурации 00 и о том, как они способны повлиять на ФБО.

2.6.3 Класс ADV. Разработка

Класс доверия ADV определяет требования для пошагового уточнения ФБО, начиная с краткой спецификации 00 в ЗБ и вплоть до фактической реализации. Каждое из получаемых представлений ФБО содержит информацию, помогающую оценщику решить, были ли выполнены функциональные требования к 00.

2.6.3.1    Функциональная спецификация (ADV_FSP)

Функциональная спецификация описывает ФБО, и необходимо, чтобы она была полным и точным отображением функциональных требований безопасности 00. Функциональная спецификация также детализирует внешний интерфейс 00. Предполагают, что пользователи 00 взаимодействуют с ФБО через этот интерфейс.

2.6.3.2    Проект верхнего уровня (ADVJHLD)

Проект верхнего уровня - проектная спецификация самого высокого уровня, которая уточняет функциональную спецификацию ФБО в основных составляющих частях ФБО. Проект верхнего уровня идентифицирует базовую структуру ФБО, а также основные элементы аппаратных, программных и программно-аппаратных средств.

2.6.3.3    Представление реализации (ADVJMP)

Представление реализации - наименее абстрактное представление ФБО. Оно фиксирует детализированное внутреннее содержание ФБО на уровне исходного текста, аппаратных схем и т.д.

СОДЕРЖАНИЕ

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    КЛАСС АРЕ. ОЦЕНКА ПРОФИЛЯ ЗАЩИТЫ..........................................................................25

4.1    Описание ОО (APE_DES)......................................................................................................25

4.2    Среда безопасности (APE_ENV)...........................................................................................26

4.3    Введение ПЗ (APEJNT)..........................................................................................................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    Введение ЗБ (ASEJNT)..........................................................................................................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

7    КЛАССЫ, СЕМЕЙСТВА И КОМПОНЕНТЫ ДОВЕРИЯ..........................................................58

8    КЛАСС ACM. УПРАВЛЕНИЕ КОНФИГУРАЦИЕЙ...................................................................59

8.1    Автоматизация УК (ACM_AUT)..............................................................................................59

8.2    Возможности УК (АСМ_САР)................................................................................................62

8.3    Область УК (ACM_SCP)..........................................................................................................68

9    КЛАСС ADO. ПОСТАВКА И ЭКСПЛУАТАЦИЯ........................................................................72

9.1    Поставка (ADO_DEL)..............................................................................................................72

9.2    Установка, генерация и запуск (ADOJGS)..........................................................................74

10    КЛАСС AD V. РАЗ РАБОТКА......................................................................................................77

10.1    Функциональная спецификация (ADV_FSP)........................................................................81

10.2    Проект верхнего уровня (ADVJHLD)....................................................................................84

10.3    Представление реализации (ADVJMP)................................................................................90

10.4    Внутренняя структура ФБО (ADVJNT).................................................................................94

10.5    Проект нижнего уровня (ADV_LLD)......................................................................................98

2.6.3.4    Внутренняя структура ФБО (ADVJNT)

Требования к внутренней структуре ФБО определяют необходимое внутреннее структурирование ФБО.

2.6.3.5    Проект нижнего уровня (ADV_LLD)

Проект нижнего уровня - детализированная проектная спецификация, уточняющая проект верхнего уровня до уровня детализации, который может быть использован как основа для программирования и/или проектирования аппаратуры.

2.6.3.6    Соответствие представлений (ADV_RCR)

Соответствие представлений - демонстрация отображения между всеми смежными парами имеющихся представлений ФБО, от краткой спецификации 00 до наименее абстрактного из имеющихся представлений ФБО.

2.6.3.7    Моделирование политики безопасности (ADV_SPM)

Модели политики безопасности - структурные представления политик безопасности ПБО, используемые для обеспечения повышенного доверия, что функциональная спецификация соответствует политикам безопасности из ПБО и, в конечном счете, функциональным требованиям безопасности 00. Это достигается посредством определения соответствия между функциональной спецификацией, моделью политики безопасности и моделируемыми политиками безопасности.

2.6.4 Класс AGD. Руководства

Класс доверия AGD определяет требования, направленные на обеспечение понятности, достаточности и законченности эксплуатационной документации, представляемой разработчиком. Эта документация, которая содержит две категории информации (для пользователей и администраторов), является важным фактором безопасной эксплуатации 00.

2.6.4.1    Руководство администратора (AGD_ADM)

Требования к руководству администратора способствуют обеспечению, что ограничения среды будут поняты администраторами и операторами 00. Руководство администратора - основное средство, имеющееся в распоряжении разработчика, для предоставления администраторам 00 детальной и точной информации о том, как осуществлять администрирование 00 безопасным способом и эффективно использовать привилегии ФБО и функции защиты.

2.6.4.2    Руководство пользователя (AGD_USR)

Требования к руководству пользователя способствуют обеспечению, что пользователи могут эксплуатировать 00 безопасным способом (например, ограничения использования, предусмотренные ПЗ или ЗБ, необходимо четко объяснить и проиллюстрировать). Руководство - основное средство, имеющееся в распоряжении разработчика, для предоставления пользователям 00 необходимой общей и специфической информации о том, как правильно использовать функции защиты 00. В руководстве необходимо осветить два аспекта. Во-первых, требуется объяснить, что делают доступные пользователю функции безопасности, и как они будут использоваться, чтобы пользователи имели возможность

10.6    Соответствие представлений (ADV_RCR).........................................................................102

10.7    Моделирование политики безопасности (ADV_SPM)......................................................105

11    КЛАСС AGD. РУКОВОДСТВА.................................................................................................108

11.1    Руководство администратора (AGD_ADM).......................................................................108

11.2    Руководство пользователя (AGDJJSR)............................................................................109

12    КЛАСС ALC. ПОДДЕРЖКА ЖИЗНЕННОГО ЦИКЛА.............................................................112

12.1    Безопасность разработки (ALC_DVS)................................................................................112

12.2    Устранение недостатков (ALC_FLR)..................................................................................114

12.3    Определение жизненного цикла (ALC_LCD)......................................................................117

12.4    Инструментальные средства и методы (А1_С_ТАТ)...........................................................120

13    КЛАСС АТЕ. ТЕСТИРОВАНИЕ...............................................................................................123

13.1    Покрытие (ATE_COV)...........................................................................................................124

13.2    Глубина (ATE_DPT)...............................................................................................................127

13.3    Функциональное тестирование (ATE_FUN).......................................................................130

13.4    Независимое тестирование (ATEJND)..............................................................................133

14    КЛАСС AVA. ОЦЕНКА УЯЗВИМОСТЕЙ.................................................................................138

14.1    Анализ скрытых каналов (AVA_CCA)..................................................................................138

14.2    Неправильное применение (AVA_MSU).............................................................................142

14.3    СТОЙКОСТЬ ФУНКЦИЙ БЕЗОПАСНОСТИ ОО (AVA_SOF)...........................................................146

14.4    Анализ уязвимостей (AVA_VLA).........................................................................................147

15    ПАРАДИГМА ПОДДЕРЖКИ ДОВЕРИЯ..................................................................................154

15.1    Введение................................................................................................................................154

15.2    ЦИКЛ ПОДДЕРЖКИ ДОВЕРИЯ.....................................................................................................155

15.3    Класс и семейства поддержки доверия..............................................................................158

16    КЛАСС АМА. ПОДДЕРЖКА ДОВЕРИЯ..................................................................................163

16.1    План поддержки доверия (АМА_АМР)................................................................................163

16.2    Отчет о категорировании компонентов ОО (АМА_САТ)..................................................165

16.3    Свидетельство поддержки доверия (AMA_EVD)...............................................................167

16.4    Анализ влияния на безопасность (AMA_SIA)....................................................................169

ПРИЛОЖЕНИЕ А ПЕРЕКРЕСТНЫЕ ССЫЛКИ МЕЖДУ КОМПОНЕНТАМИ ДОВЕРИЯ...........173

ПРИЛОЖЕНИЕ Б ПЕРЕКРЕСТНЫЕ ССЫЛКИ ОУД И КОМПОНЕНТОВ ДОВЕРИЯ.................175

IV

1 Область применения

Эта часть ОК определяет требования доверия к безопасности и включает в себя оценочные уровни доверия (ОУД), определяющие шкалу для измерения доверия, собственно компоненты доверия, из которых составлены уровни доверия, и критерии для оценки ПЗ и ЗБ.

1.1    Структура

Часть 3 ОК состоит из следующих разделов:

1    - введение и парадигма;

2    - структура представления классов, семейств и компонентов доверия, оценочных уровней доверия и их взаимосвязь, а также краткая характеристика классов и семейств доверия, представленных в разделах 8-14;

3-5 - краткое введение в критерии оценки ПЗ и ЗБ, сопровождаемое детализированными объяснениями семейств и компонентов, которые применяют для этих оценок;

6    - детализированные определения оценочных уровней доверия;

7    - краткое введение в классы доверия;

8-14 - детализированные определения классов доверия;

15-16 - краткое введение в критерии оценки поддержки доверия с детализированными определениями применяемых семейств и компонентов.

Приложение А содержит сводку зависимостей между компонентами доверия.

Приложение Б содержит перекрестные ссылки между ОУД и компонентами доверия.

1.2    Парадигма доверия

Цель данного подраздела состоит в изложении основных принципов и подходов к установлению доверия к безопасности. Данный подраздел позволит читателю понять логику построения требований доверия в ОК.

1.2.1 Основные принципы ОК

Основные принципы ОК состоят в том, что следует четко сформулировать угрозы безопасности и положения политики безопасности организации, а достаточность предложенных мер безопасности должна быть продемонстрирована.

Более того, следует предпринять меры по уменьшению вероятности наличия уязвимостей, возможности их проявления (т.е. преднамеренного использования или непреднамеренной активизации), а также степени ущерба, который может явиться следствием проявления уязвимостей. Дополнительно следует предпринять меры для облегчения последующей идентификации уязвимостей, а также по их устранению, ослаблению и/или оповещению об их использовании или активизации.

1

1.2.2 Подход к доверию

Основная концепция ОК - обеспечение доверия, основанное на оценке (активном исследовании) продукта или системы ИТ, которым предполагается доверять. Оценка была традиционным способом обеспечения доверия и являлась основой предшествующих критериев оценки. Для согласования с существующими подходами в ОК принят тот же самый основной принцип. ОК предполагают, что проверку правильности документации и разработанного продукта или системы ИТ будут проводить опытные оценщики, уделяя особое внимание области, глубине и строгости оценки.

ОК не отрицают и при этом не комментируют относительные достоинства других способов получения доверия. Продолжаются исследования альтернативных путей достижения доверия. Если в результате этих исследований будут выявлены другие отработанные альтернативные подходы, то они могут в дальнейшем быть включены в ОК, которые структурно организованы так, что предусматривают такую возможность.

1.2.2.1    Значимость уязвимостей

Предполагается, что имеются нарушители, которые будут пытаться активно использовать возможности нарушения политики безопасности как для получения незаконной выгоды, так и для незлонамеренных, но, тем не менее, опасных действий. Нарушители могут также случайно активизировать уязвимости безопасности, нанося вред организации. При необходимости обрабатывать чувствительную информацию и отсутствии в достаточной степени доверенных продуктов или систем имеется значительный риск из-за отказов ИТ. Поэтому нарушения безопасности ИТ могут вызвать значительные потери.

Нарушения безопасности ИТ возникают вследствие преднамеренного использования или случайной активизации уязвимостей при применении ИТ по назначению.

Следует предпринять ряд шагов для предотвращения уязвимостей, возникающих в продуктах и системах ИТ. По возможности уязвимости должны быть:

а)    устранены, т.е. следует предпринять активные действия для выявления, а затем удаления или нейтрализации всех уязвимостей, которые могут проявиться;

б)    минимизированы, т.е. следует предпринять активные действия для уменьшения до допустимого остаточного уровня возможного ущерба от любого проявления уязвимостей;

в)    отслежены, т.е. следует предпринять активные действия для обнаружения любой попытки использовать оставшиеся уязвимости с тем, чтобы ограничить ущерб.

1.2.2.2    Причины уязвимостей

Уязвимости могут возникать из-за недостатков:

а)    требований, т.е. продукт или система ИТ могут обладать требуемыми от них функциями и свойствами, но все же содержать уязвимости, которые делают их непригодными или неэффективными в части безопасности;

б)    проектирования, т.е. продукт или система ИТ не отвечают спецификации, и/или уязвимости являются следствием некачественных стандартов проектирования или неправильных проектных решений;

2

в) эксплуатации, т.е. продукт или система ИТ разработаны в полном соответствии с корректными спецификациями, но уязвимости возникают как результат неадекватного управления при эксплуатации.

1.2.2.3    Доверие в ОК

Доверие - основа для уверенности в том, что продукт или система ИТ отвечают целям безопасности. Доверие могло бы быть получено путем обращения к таким источникам, как бездоказательное утверждение, предшествующий аналогичный опыт или специфический опыт. Однако ОК обеспечивают доверие с использованием активного исследования. Активное исследование - это оценка продукта или системы ИТ для определения его свойств безопасности.

1.2.2.4    Доверие через оценку

Оценка является традиционным способом достижения доверия, и она положена в основу ОК. Методы оценки могут, в частности, включать в себя:

а)    анализ и проверку процессов и процедур;

б)    проверку, что процессы и процедуры действительно применяются;

в)    анализ соответствия между представлениями проекта 00;

г)    анализ соответствия каждого представления проекта 00 требованиям;

д)    верификацию доказательств;

е)    анализ руководств;

ж)    анализ разработанных функциональных тестов и полученных результатов;

и)    независимое функциональное тестирование;

к)    анализ уязвимостей, включающий предположения о недостатках;

л)    тестирование проникновения.

1.2.3 Шкала оценки доверия в ОК

Основные принципы ОК содержат утверждение, что большее доверие является результатом приложения больших усилий при оценке, и что цель состоит в применении минимальных усилий, требуемых для обеспечения необходимого уровня доверия. Повышение уровня усилий может быть основано на:

а)    области охвата, т.е. увеличении рассматриваемой части продукта или системы ИТ;

б)    глубине, т.е. детализации рассматриваемых проектных материалов и реализации;

в)    строгости, т.е. применении более структурированного и формального подхода.

3

2 Требования доверия к безопасности

2.1    Структуры

Следующие подразделы описывают конструкции, используемые в представлении классов, семейств и компонентов доверия, оценочных уровней доверия (ОУД), и их взаимосвязь.

На рисунке 2.1 показаны требования доверия, определенные в части 3 ОК. Наиболее общую совокупность требований доверия называют классом. Каждый класс содержит семейства доверия, которые разделены на компоненты доверия, содержащие, в свою очередь, элементы доверия. Классы и семейства используют для обеспечения таксономии классифицируемых требований доверия, в то время как компоненты применяют непосредственно для спецификации требований доверия в ПЗ/ЗБ.

2.1.1    Структура класса

Рисунок 2.1 иллюстрирует структуру класса доверия.

2.1.1.1    Имя класса

Каждому классу доверия присвоено уникальное имя. Имя указывает на тематические разделы, на которые распространяется данный класс доверия.

Представлена также уникальная краткая форма имени класса доверия. Она является основным средством для ссылки на класс доверия. Принятое условное обозначение включает в себя букву "А", за которой следуют еще две буквы латинского алфавита, относящиеся к имени класса.

2.1.1.2    Представление класса

Каждый класс доверия имеет вводный подраздел, в котором описаны состав и назначение класса.

2.1.1.3    Семейства доверия

Каждый класс доверия содержит, по меньшей мере, одно семейство доверия. Структура семейств доверия описана в следующем пункте.

4

2.1.2 Структура семейства доверия

Рисунок 2.1 иллюстрирует структуру семейства доверия.

2.1.2.1    Имя семейства

Каждому семейству доверия присвоено уникальное имя. Имя содержит описательную информацию по тематическим разделам, на которые распространяется данное семейство доверия. Каждое семейство доверия размещено в пределах класса доверия, который содержит другие семейства той же направленности.

Представлена также уникальная краткая форма имени семейства доверия. Она является основным средством для ссылки на семейство доверия. Принятое условное обозначение включает в себя краткую форму имени класса и символ подчеркивания, за которым следуют три буквы латинского алфавита, относящиеся к имени семейства.

2.1.2.2    Цели

Подраздел целей семейства доверия представляет назначение семейства доверия.

В нем описаны цели, для достижения которых предназначено семейство, особенно связанные с парадигмой доверия ОК. Описание целей для семейства доверия представлено в общем виде. Любые конкретные подробности, требуемые для достижения целей, включены в конкретный компонент доверия.

2.1.2.3    Ранжирование компонентов

Каждое семейство доверия содержит один или несколько компонентов доверия. Этот подраздел семейства доверия содержит описание имеющихся компонентов и объяснение их разграничения. Его основная цель состоит в указании различий между компонентами при принятии решения о том, что семейство является необходимой или полезной частью требований доверия для ПЗ/ЗБ.

В семействах доверия, содержащих более одного компонента, выполнено ранжирование компонентов и приведено его обоснование. Это обоснование сформулировано в терминах области применения, глубины и/или строгости.

2.1.2.4    Замечания по применению

Необязательный подраздел замечаний по применению семейства доверия содержит дополнительную информацию о семействе. Эта информация предназначена непосредственно для пользователей семейства доверия (например, разработчиков ПЗ и ЗБ, проектировщиков 00, оценщиков). Представление неформально и включает в себя, например, предупреждения об ограничениях использования или областях, требующих особого внимания.

2.1.2.5    Компоненты доверия

Каждое семейство содержит хотя бы один компонент доверия. Структура компонентов доверия представлена в следующем пункте.

6