Часть 3 ОК содержит классы семейств и компонентов, которые сгруппированы на основе, связанной с доверием. В начале каждого класса представлена диаграмма, которая указывает семейства в классе и компоненты в каждом семействе.
На рисунке 2.5 показан класс, содержащий одно семейство. Семейство содержит три компонента, которые являются линейно иерархичными (т.е. компонент 2 содержит более высокие требования, чем компонент 1, к конкретным действиям, приводимым свидетельствам или строгости действий и/или свидетельств). Все семейства доверия в части 3 ОК – линейно иерархичные, хотя линейность не обязательна для семейств доверия, которые могут быть добавлены в дальнейшем.
Р
исунок 2.5 – Образец декомпозиции класса
2.3Структура класса критериев оценки профиля защиты и задания по безопасности
Требования для оценки профиля защиты и задания по безопасности трактуют как классы доверия, структура которых подобна структуре других классов доверия, описанных ниже. Отличие заключается в отсутствии подраздела ранжирования компонентов в описаниях семейств и вызвано тем, что каждое семейство имеет только один компонент.
В таблицах 3.1–3.4 приведены названия каждого из классов APE и ASE, составляющих их семейств и их краткие имена. Содержание разделов ПЗ, рассматриваемых в семействах класса APE, представлено в части 1 ОК, приложение Б, подразделы Б.2.2–Б.2.6, а разделов ЗБ, рассматриваемых в семействах класса ASE, – в части 1 ОК, приложение В, подразделы В.2.2–В.2.8.
2.4Использование терминов в части 3 ОК
В части 3 ОК определенным образом используются термины, список которых приведен ниже. Они не включены в глоссарий ОК (раздел 2 части 1 ОК), потому что являются общеупотребительными терминами, и их использование, хотя и ограничено приведенными разъяснениями, согласуется со словарными определениями. Однако именно такое толкование терминов применялось при разработке части 3 ОК, и поэтому оно полезно для понимания. В скобках приведены эквиваленты терминов на английском языке.
верифицировать(verify): Аналогичен термину "подтверждать" ("confirm"), но имеет более глубокий смысл. При использовании в контексте действий оценщика указывает, что требуются независимые усилия оценщика.
взаимно поддерживающие (mutually supportive): Описывает взаимосвязь в группе сущностей, указывая, что последние обладают некоторыми свойствами, которые не находятся в противоречии со свойствами других сущностей и могут способствовать выполнению другими сущностями их задач. Нет необходимости определять, что каждая из рассматриваемых отдельных сущностей непосредственно поддерживает другие сущности в этой группе; достаточно, если сделано обобщенное заключение.
внутренне непротиворечивый (internally consistent): Отсутствуют очевидные противоречия между любыми аспектами сущности. Применительно к документации это означает, что в ней не может быть изложено что-либо, что может быть воспринято как противоречащее чему-то другому.
делать (независимое) заключение (determine): Требуется независимый анализ для достижения конкретного заключения. Термин отличается от "подтверждать"("confirm") или "верифицировать"("verify"), так как последние подразумевают, что требует проверки анализ, проведенный ранее, в то время как "делать (независимое) заключение" подразумевает совершенно независимый анализ, обычно при отсутствии любого предшествующего анализа.
демонстрировать (demonstrate): Относится к анализу, который приводит к заключению, но является менее строгим, чем "доказательство" ("proof").
доказывать (prove): Относится к формальному анализу в математическом смысле, полностью строгий во всех отношениях. Обычно используется, когда желательно показать соответствие между двумя представлениями ФБО на высоком уровне строгости.
исчерпывающий (exhaustive): Используется применительно к проведению анализа или другой деятельности. Аналогичен термину "систематический" ("systematic"), но более точен, так как указывает не только на то, что в соответствии с некоторым конкретным планом проведения анализа или другой деятельности был применен методический подход, но также и на то, что этот план достаточен для обеспечения проведения исследования по всем возможным направлениям.
логически упорядоченный (coherent): Сущность логически упорядочена и имеет очевидный смысл. Применительно к документации этот термин относится как к тексту, так и к структуре, указывая, что они понятны потенциальной аудитории.
непротиворечивый (consistent): Описывает связь между двумя или более сущностями, указывая, что между ними нет никаких явных противоречий.
обеспечивать (ensure): Подразумевает сильную причинно-следственную связь между некоторым действием и его последствиями. Часто ему предшествует термин "способствует" ("helps"), указывающий, что одно данное действие не полностью определяет последствия.
объяснять (explain): Отличается от терминов "описывать" ("describe") и "демонстрировать" ("demonstrate"). Предназначен для ответа на вопрос "Почему?" без попытки аргументировать, что ход предпринимаемых действий обязательно оптимален.
описывать (describe): Требует, чтобы некоторые конкретные подробности сущности были представлены.
подтверждать (confirm): Используется для указания необходимости подробного рассмотрения чего-либо; при этом требуется независимое заключение о его достаточности. Требуемый уровень строгости зависит от характера предмета. Применим только к действиям оценщика.
полный (complete): Представлены все необходимые составляющие сущности. Применительно к документации это означает, что приведена вся необходимая информация, причем настолько детально, что на данном уровне абстракции дальнейшие пояснения не требуются.
проверять (check): Аналогичен, но менее строг, чем "подтверждать"("confirm") или "верифицировать"("verify"). Требует, чтобы оценщиком было сделано оперативное заключение, возможно лишь с поверхностным анализом или вообще без него.
прослеживать или сопоставлять (trace): Используется для указания, что между двумя сущностями требуется только минимальный уровень строгости неформального соответствия.
противостоять (counter): Используется в том смысле, что некоторая цель безопасности заключается в противостоянии конкретной угрозе, но не обязательно указывает в итоге на полную ее ликвидацию.
специфицировать или определять (specify): Используется в том же контексте, что и "описывать" ("describe"), но является более строгим и точным. Аналогичен термину "определять" ("define").
строгое обоснование (justification): Относится к анализу, ведущему к заключению, но является более строгим, чем термин "демонстрация" ("demonstration"), в смысле точных и подробных объяснений каждого шага логических суждений.
2.5Классификация доверия
Классы и семейства доверия, а также их краткие имена приведены в таблице 2.1.
2.6Краткий обзор классов и семейств доверия
Ниже приведены краткие характеристики классов и семейств доверия из разделов 8-14.
2.6.1Класс ACM: Управление конфигурацией
Управление конфигурацией (УК) помогает обеспечить сохранение целостности ОО, устанавливая и контролируя определенный порядок процессов уточнения и модификации ОО и предоставления связанной с ними информации. УК предотвращает несанкционированную модификацию, добавление или уничтожение составляющих ОО, обеспечивая тем самым доверие, что оцениваются именно те ОО и документация, которые подготовлены к распространению.
Таблица 2.1 – Семейства доверия
Класс доверия
|
Семейство доверия
|
Краткое имя
|
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
|
Моделирование политики безопасности
|
ADV_SPM
|
AGD –
Руководства
|
Руководство администратора
|
AGD_ADM
|
Руководство пользователя
|
AGD_USR
|
ALC –
Поддержка жизненного цикла
|
Безопасность разработки
|
ALC_DVS
|
Устранение недостатков
|
ALC_FLR
|
Определение жизненного цикла
|
ALC_LCD
|
Инструментальные средства и методы
|
ALC_TAT
|
ATE –
Тестирование
|
Покрытие
|
ATE_COV
|
Глубина
|
ATE_DPT
|
Функциональное тестирование
|
ATE_FUN
|
Независимое тестирование
|
ATE_IND
|
AVA –
Оценка уязвимостей
|
Анализ скрытых каналов
|
AVA_CCA
|
Неправильное применение
|
AVA_MSU
|
Стойкость функций безопасности ОО
|
AVA_SOF
|
Анализ уязвимостей
|
AVA_VLA
|
2.6.1.1Автоматизация УК (ACM_AUT)
Семейство "Автоматизация управления конфигурацией" устанавливает уровень автоматизации, используемый для управления элементами конфигурации.
2.6.1.2Возможности УК (ACM_CAP)
Семейство "Возможности управления конфигурацией" определяет характеристики системы управления конфигурацией.
2.6.1.3Область УК (ACM_SCP)
Семейство "Область управления конфигурацией" указывает на те элементы ОО, для которых необходим контроль со стороны системы управления конфигурацией.
2.6.2Класс ADO. Поставка и эксплуатация
Класс доверия ADO определяет требования к мерам, процедурам и стандартам, применяемым для безопасной поставки, установки и эксплуатации ОО, обеспечивая, чтобы безопасность ОО не нарушалась во время его распространения, установки и эксплуатации.
2.6.2.1Поставка (ADO_DEL)
Семейство "Поставка" распространяется на процедуры, используемые для поддержки безопасности во время передачи ОО пользователю при первоначальной поставке и последующих модификациях. Оно включает в себя специальные процедуры или действия, необходимые для демонстрации подлинности поставленного ОО. Такие процедуры и меры – основа обеспечения безопасности ОО во время передачи. Несмотря на то, что при оценке ОО не всегда может быть определено его соответствие требованиям поставки, можно оценить процедуры, предусмотренные разработчиком для распространения ОО пользователям.
2.6.2.2Установка, генерация и запуск (ADO_IGS)
Семейство "Установка, генерация и запуск" предусматривает, чтобы копия ОО была конфигурирована и активизирована администратором так, чтобы показать те же самые свойства защиты, что и у оригинала ОО. Процедуры установки, генерации и запуска предоставляют уверенность в том, что администратор будет осведомлен о параметрах конфигурации ОО и о том, как они способны повлиять на ФБО.
2.6.3Класс ADV. Разработка
Класс доверия ADV определяет требования для пошагового уточнения ФБО, начиная с краткой спецификации ОО в ЗБ и вплоть до фактической реализации. Каждое из получаемых представлений ФБО содержит информацию, помогающую оценщику решить, были ли выполнены функциональные требования к ОО.
2.6.3.1Функциональная спецификация (ADV_FSP)
Функциональная спецификация описывает ФБО, и необходимо, чтобы она была полным и точным отображением функциональных требований безопасности ОО. Функциональная спецификация также детализирует внешний интерфейс ОО. Предполагают, что пользователи ОО взаимодействуют с ФБО через этот интерфейс.
2.6.3.2Проект верхнего уровня (ADV_HLD)
Проект верхнего уровня – проектная спецификация самого высокого уровня, которая уточняет функциональную спецификацию ФБО в основных составляющих частях ФБО. Проект верхнего уровня идентифицирует базовую структуру ФБО, а также основные элементы аппаратных, программных и программно-аппаратных средств.
2.6.3.3Представление реализации (ADV_IMP)
Представление реализации – наименее абстрактное представление ФБО. Оно фиксирует детализированное внутреннее содержание ФБО на уровне исходного текста, аппаратных схем и т.д.
2.6.3.4Внутренняя структура ФБО (ADV_INT)
Требования к внутренней структуре ФБО определяют необходимое внутреннее структурирование ФБО.
2.6.3.5Проект нижнего уровня (ADV_LLD)
Проект нижнего уровня – детализированная проектная спецификация, уточняющая проект верхнего уровня до уровня детализации, который может быть использован как основа для программирования и/или проектирования аппаратуры.
2.6.3.6Соответствие представлений (ADV_RCR)
Соответствие представлений – демонстрация отображения между всеми смежными парами имеющихся представлений ФБО, от краткой спецификации ОО до наименее абстрактного из имеющихся представлений ФБО.
2.6.3.7Моделирование политики безопасности (ADV_SPM)
Модели политики безопасности – структурные представления политик безопасности ПБО, используемые для обеспечения повышенного доверия, что функциональная спецификация соответствует политикам безопасности из ПБО и, в конечном счете, функциональным требованиям безопасности ОО. Это достигается посредством определения соответствия между функциональной спецификацией, моделью политики безопасности и моделируемыми политиками безопасности.
|
