- •Часть 3. Требования доверия к безопасности
- •Область применения
- •Структура
- •Часть 3 ок состоит из следующих разделов:
- •Парадигма доверия
- •Основные принципы ок
- •Подход к доверию
- •Шкала оценки доверия в ок
- •Требования доверия к безопасности
- •Структуры
- •Структура класса
- •Структура семейства доверия
- •Структура компонента доверия
- •Элементы доверия
- •Структура оуд
- •Р исунок 2.3 – Структура оуд
- •Связь между требованиями и уровнями доверия
- •Классификация компонентов
- •Р исунок 2.5 – Образец декомпозиции класса
- •Структура класса критериев оценки профиля защиты и задания по безопасности
- •Использование терминов в части 3 ок
- •Классификация доверия
- •Краткий обзор классов и семейств доверия
- •Класс acm: Управление конфигурацией
- •Класс agd. Руководства
- •Руководство администратора (agd_adm)
- •Руководство пользователя (agd_usr)
- •Класс alc. Поддержка жизненного цикла
- •Безопасность разработки (alc_dvs)
- •Устранение недостатков (alc_flr)
- •Определение жизненного цикла (alc_lcd)
- •Анализ уязвимостей (ava_vla)
- •Классификация поддержки
- •Краткий обзор критериев профиля защиты
- •Оценка профиля защиты
- •Соотношение с критериями оценки задания по безопасности
- •Задачи оценщика
- •Краткий обзор критериев задания по безопасности
- •Оценка задания по безопасности
- •Соотношение с другими критериями оценки из ок
- •Задачи оценщика
- •Класс ape. Оценка профиля защиты
- •Описание оо (ape_des)
- •Среда безопасности (ape_env)
- •Введение пз (ape_int)
- •Цели безопасности (ape_obj)
- •Требования безопасности ит (ape_req)
- •Требования безопасности ит, сформулированные в явном виде (ape_sre)
- •Класс ase. Оценка задания по безопасности
- •Описание оо (ase_des)
- •Среда безопасности (ase_env)
- •Введение зб (ase_int)
- •Цели безопасности (ase_obj)
- •Утверждения о соответствии пз (ase_ppc)
- •Требования безопасности ит (ase_req)
- •Требования безопасности ит, сформулированные в явном виде (ase_sre)
- •Краткая спецификация оо (ase_tss)
- •Оценочные уровни доверия
- •Краткий обзор оценочных уровней доверия (оуд)
- •Детализация оценочных уровней доверия
- •Оценочный уровень доверия 1 (оуд1) – предусматривающий функциональное тестирование
- •Оценочный уровень доверия 2 (оуд2) – предусматривающий структурное тестирование
- •Оценочный уровень доверия 3 (оуд3) – предусматривающий методическое тестирование и проверку
- •Оценочный уровень доверия 4 (оуд4) – предусматривающий методическое проектирование, тестирование и углубленную проверку
- •Оценочный уровень доверия 5 (оуд5) – предусматривающий полуформальное проектирование и тестирование
- •Оценочный уровень доверия 6 (оуд6) – предусматривающий полуформальную верификацию проекта и тестирование
- •Оценочный уровень доверия 7 (оуд7) – предусматривающий формальную верификацию проекта и тестирование
- •Классы, семейства и компоненты доверия
- •Класс 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)
- •Парадигма поддержки доверия
- •Введение
- •Цикл поддержки доверия
- •Р исунок 15.1 – Пример цикла поддержки доверия
- •Приемка оо
- •Р исунок 15.2 – Пример подхода к приемке оо
- •Мониторинг оо
- •Переоценка
- •Класс и семейства поддержки доверия
- •План поддержки доверия
- •Отчет о категорировании компонентов оо
- •Свидетельство поддержки доверия
- •Анализ влияния на безопасность
- •Класс ama. Поддержка доверия
- •План поддержки доверия (ama_amp)
- •Отчет о категорировании компонентов оо (ama_cat)
- •Свидетельство поддержки доверия (ama_evd)
- •Анализ влияния на безопасность (ama_sia)
- •Приложение а (справочное) Перекрестные ссылки между компонентами доверия
- •Приложение б (справочное) Перекрестные ссылки оуд и компонентов доверия
Цикл поддержки доверия
Этот подраздел описывает один из возможных подходов к использованию семейств и компонентов поддержки доверия с целью проиллюстрировать использование рассматриваемых понятий. В качестве примера приведен "цикл поддержки доверия", разделенный на три следующие фазы:
а) приемка ОО для поддержки – начало цикла, когда планы и процедуры разработчика по поддержке доверия в течение цикла устанавливает разработчик, и затем их правильность независимо подтверждает оценщик;
б) мониторинг – разработчик предоставляет в одной или нескольких контрольных точках цикла свидетельство, что доверие к ОО поддерживается в соответствии с установленными планами и процедурами; это свидетельство поддержки доверия затем независимо проверяет оценщик;
в) переоценка – окончание цикла, когда обновленная версия ОО представляется на рассмотрение для переоценки, основанной на изменениях, которым подверглась сертифицированная версия ОО.
Семейства класса AMA связаны, прежде всего, с двумя первыми фазами, обеспечивая поддержку для третьей. Эти фазы введены здесь только для того, чтобы понятнее описать применение требований поддержки доверия. Не ставится цель сделать строго обязательной схему поддержки доверия, которая формально включает в себя эти три фазы.
Цикл поддержки доверия проиллюстрирован на рисунке 15.1.
В рассматриваемом примере можно переходить к фазе мониторинга ОО только после успешного завершения фазы приемки (т.е. когда планы и процедуры разработчика по поддержке доверия уже приняты). Если разработчик вносит изменения в эти планы или процедуры в фазе мониторинга, необходимо вернуться к фазе приемки ОО, чтобы учесть произведенные изменения.
В фазе мониторинга разработчик выполняет планы и процедуры поддержки доверия, проводя анализ влияния на безопасность изменений, которым подвергается ОО (анализ влияния на безопасность). В определенных контрольных точках этой фазы оценщик независимо проверяет (посредством аудита) деятельность разработчика. От разработчика требуется четкое выполнение планов и процедур поддержки и анализа влияния на безопасность.
Р исунок 15.1 – Пример цикла поддержки доверия
Поэтому при нахождении ОО в фазе мониторинга появляется возможность убедиться, что доверие к ОО поддерживается для новых версий ОО, выпущенных разработчиком.
ОО, который подвергается изменениям, не может пребывать в фазе мониторинга постоянно: в какой-то момент времени переоценка ОО становится необходимой. Время принятия решения о необходимости переоценки зависит от накопления изменений в ОО, а также от особо значительных изменений. Например, большое количество малых изменений может повлиять на доверие к ОО как одно значительное изменение. План разработчика по поддержке доверия определяет предел для изменений в ОО, которые могут быть внесены в фазе мониторинга (см. 15.3.1).
Подобным образом невозможно "повысить рейтинг" ОО (т.е. повысить его уровень доверия) в фазе мониторинга. Это может быть достигнуто только посредством новой оценки ОО (использующей, по возможности, результаты предыдущего оценивания).
Статус поддержки доверия к ОО должен быть пересмотрен, если будет обнаружено, что процедуры поддержки доверия не выполняются, в результате чего утрачивается доверие к ОО. В некоторых случаях от разработчика может потребоваться представление ОО для переоценки, после которой начнется новый цикл поддержки доверия.