Приложение

Таблица I-1. Каталог требований к функциям безопасности

Класс, Семейство, Компонент	Название	Иер. связи	Зависимости
FAU	Аудит безопасности
FAU_ARP	Автоматический ответ аудита безопасности
FAU_ARP.1	Сигналы тревоги	═	FAU_SAA.1^FAU_PAD.1^FAU_PIT.1;FPT_TSA.1.
FAU_ARP.2	Автоматическая реакция	═	FAU_SAA.1^FAU_PAD.1^FAU_PIT.1.
FAU_ARP.3	Возможные варианты автоматической реакции	2	FAU_SAA.1^FAU_PAD.1^FAU_PIT.1;FPT_TSA.1.
FAU_GEN	Генерация данных аудита безопасности
FAU_GEN.1	Генерация данных аудита	═	FIA_UID.1.
FAU_GEN.2	Генерация идентичности пользователя	═	FAU_GEN.1;FIA_UID.1.
FAU_MGT	Управление аудитом безопасности
FAU_MGT.1	Управление трассой контроля	═	FAU_STG.1.
FAU_MGT.2	Контроль заполнения трассы контроля	═	FAU_STG.1.
FAU_MGT.3	Управление заполнением трассы контроля	2
FAU_MGT.4	Управление во время выполнения	1, 3
FAU_PAD	Обнаружение аномалии по базовому образцу
FAU_PAD.1	Профиль-основанное обнаружение аномалии
FAU_PAD.2	Динамическое профиль-основанное наблюдение и ответ	1
FAU_PIT	Средства идентификации проникновения
FAU_PIT.1	Простая эвристика атаки
FAU_PIT.2	Сложная эвристика атаки
FAU_PIT.3	Динамическое управление временем прогона атаки	═	FAU_PIT.1.
FAU_POP	Обработка сохраняемых данных аудита безопасности
FAU_POP.1	Формат, понятный человеку	═	FAU_STG.1.
FAU_POP.2	Формат для автоматизированной обработки	═	FAU_STG.1.
FAU_POP.3	Гибкий формат	═	FAU_STG.1.
FAU_PRO	Защита трассы контроля безопасности
FAU_PRO.1	Ограниченный доступ к трассе контроля	═	FAU_STG.1;FPT_TSA.1.
FAU_PRO.2	Расширенный доступ к трассе контроля	1	FAU_STG.1;FPT_TSA.1.
FAU_PRP	Обработка данных аудита безопасности до хранения
FAU_PRP.1	Формат, понятный человеку	═	FAU_GEN.1.
FAU_PRP.2	Формат для автоматизированной обработки	═	FAU_GEN.1.
FAU_PRP.3	Гибкий формат	═	FPT_TSA.1.
FAU_SAA	Анализ аудита безопасности
FAU_SAA.1	Неизбежный анализ нарушения	═	FAU_GEN.1.
FAU_SAA.2	Конфигурируемый анализ нарушения	═	FAU_SAA.1;FPT_TSA.1.
FAU_SAR	Просмотр аудита безопасности
FAU_SAR.1	Ограниченный просмотр аудита	═	FAU_STG.1;FPT_TSA.1;FAU_PRO.1.
FAU_SAR.2	Расширенный просмотр аудита	1	FAU_STG.1;FPT_TSA.1;FAU_PRO.2.
FAU_SAR.3	Избирательный просмотр аудита	═	FAU_SAR.1.
FAU_SEL	Выбор события аудита безопасности
FAU_SEL.1	Выборочный аудит	═	FAU_GEN.1.
FAU_SEL.2	Режим выбора во время выполнения	1	FPT_TSA.1.
FAU_SEL.3	Режим с ограниченным показом во время выполнения	1	FPT_TSA.1.
FAU_SEL.4	Режим с расширенным показом во время выполнения	3	FPT_TSA.1.
FAU_STG	Хранение событий аудита безопасности
FAU_STG.1	Постоянное хранение трассы контроля	═	FAU_GEN.1.
FAU_STG.2	Перечисление случаев потери контрольных данных	1	FAU_GEN.1.
FAU_STG.3	Предотвращение потери контрольных данных	2	FAU_GEN.1.
FAU_STG.4	Управляемое предотвращение потери контрольных данных	3	FAU_GEN.1.
FCO	Связь
FCO_NRO	Подтверждение отправления
FCO_NRO.1	Предписанное доказательство отправления	═	FIA_UID.1.
FCO_NRO.2	Избирательное доказательство отправления	1	FIA_UID.1.
FCO_NRR	Подтверждение получения
FCO_NRR.1	Предписанное доказательство получения	═	FIA_UID.1.
FCO_NRR.2	Избирательное доказательство получения	1	FIA_UID.1.
FDP	Защита данных пользователя
FDP_ACC	Политика управления доступом
FDP_ACC.1	Дискретный контроль доступа к объекту	═	FDP_ACF.1.
FDP_ACC.2	Полный контроль доступа к объекту	1	FDP_ACF.1.
FDP_ACF	Функции управления доступом
FDP_ACF.1	Контроль доступа по одному признаку безопасности	═	FDP_ACC.1.
FDP_ACF.2	Контроль доступа по многим признакам безопасности	1	FDP_ACC.1.
FDP_ACF.3	Разрешение доступа	═	FDP_ACC.1.
FDP_ACF.4	Разрешение и запрет доступа	3	FDP_ACC.1.
FDP_ACF.5	Фиксированный контроль доступа	═	FDP_ACC.1.
FDP_ACI	Инициализация признаков объекта
FDP_ACI.1	Инициализация статического признака	═	FDP_ACC.1^FDP_IFC.1.
FDP_ACI.2	Инициализация признака, определяемого администратором	1	FDP_ACC.1^FDP_IFC.1; FPT_TSA.1;FPT_TSU.1.
FDP_ACI.3	Инициализация признака, определяемого пользователем	2	FDP_ACC.1^FDP_IFC.1; FPT_TSA.1;FPT_TSU.1.
FDP_ACI.4	Инициализация признака безопасности управления доступом	1	FDP_ACF ^ FDP_IFC; FPT_TSU.1.
FDP_ACI.5	Модификация признака безопасности управления доступом	4	FDP_ACF ^ FDP_IFC; FPT_TSU.1.
FDP_ETC	Контроль вывода
FDP_ETC.1	Вывод данных пользователя без признаков безопасности	═	FDP_ACC.1^FDP_IFC.1.
FDP_ETC.2	Вывод данных пользователя с признаками безопасности	1	FDP_ACC.1^FDP_IFC.1; FTP_ITC.1^FTP_TRP.1; FPT_TDC.1.
FDP_IFC	Политика управления информационным потоком
FDP_IFC.1	Дискретный контроль информационного поток	═	FDP_IFF.1.
FDP_IFC.2	Полный контроль информационного потока	1	FDP_IFF.1.
FDP_IFF	Функции управления информационным потоком
FDP_IFF.1	Простые признаки безопасности	═	FDP_IFC.1.
FDP_IFF.2	Иерархические признаки безопасности	1	FDP_IFC.1.
FDP_IFF.3	Ограничение незаконных информационных потоков	═	AVA_CCA.1;FDP_IFC.1.
FDP_IFF.4	Частичное устранение незаконных информационных потоков	3	AVA_CCA.1^FDP_IFC.1.
FDP_IFF.5	Полное устранение незаконных информационных потоков	4	AVA_CCA.1^FDP_IFC.1.
FDP_IFF.6	Контроль незаконного информационного потока	═	AVA_CCA.1^FDP_IFC.1.
FDP_ITC	Контроль ввода
FDP_ITC.1	Ввод данных пользователя без признаков безопасности	═	FDP_ACC.1^FDP_IFC.1.
FDP_ITC.2	Ввод данных пользователя с признаками безопасности	═	FDP_ACC.1^FDP_IFC.1;FTP_ITC.1^FTP_TRP.1;FPT_TDC.1.
FDP_ITT	Передача внутри ОО
FDP_ITT.1	Базовая защита внутренней передачи	═	FDP_ACC.1^FDP_IFC.1;FPT_TSA.1.
FDP_ITT.2	Разделение передачи признаком	1	FDP_ACC.1^FDP_IFC.1;FPT_TSA.1.
FDP_ITT.3	Контроль целостности	═	FDP_ACC.1^FDP_IFC.1;FDP_ITT.1.
FDP_ITT.4	Контроль целостности по признаку	3	FDP_ACC.1^FDP_IFC.1;FDP_ITT.2.
FDP_RIP	Защита остаточной информации
FDP_RIP.1	Защита поднабора остаточной информации после распределения ресурсов
FDP_RIP.2	Защита поднабора остаточной информации после освобождения ресурсов
FDP_RIP.3	Полная защита остаточной информации после распределения ресурсов	1
FDP_RIP.4	Полная защита остаточной информации после освобождения ресурсов	2,3
FDP_ROL	Рестарт
FDP_ROL.1	Базовый рестарт	═	FIA_UID.1.
FDP_ROL.2	Повышенный рестарт	1	FIA_UID.1.
FDP_ROL.3	Административный рестарт	═	FPT_TSA.1;FDP_ROL.1.
FDP_SAM	Модификация признака безопасности
FDP_SAM.1	Модификация признака администратором	═	FPT_TSA.1;FDP_ACC.1^FDP_IFC.1.
FDP_SAM.2	Модификация признака пользователем	1	FPT_TSA.1;FDP_ACC.1^FDP_IFC.1.
FDP_SAM.3	Надежная модификация признака	═	FDP_SAM.1;FDP_ACC.1^>FDP_IFC.1.
FDP_SAQ	Запрос признака безопасности
FDP_SAQ.1	Запрос признака администратором	═	FPT_TSA.1;FDP_ACC.1^FDP_IFC.1.
FDP_SAQ.2	Запрос признака пользователем	═	FDP_ACC.1^FDP_IFF.1.
FDP_SDI	Целостность хранимых данных
FDP_SDI.1	Контроль целостности хранимых данных
FDP_SDI.2	Контроль целостности хранимых данных по признаку	1
FDP_UCT	Защита конфиденциальности данных пользователя при передаче между ФБ
FDP_UCT.1	Базовая конфиденциальность обмена данными	═	FTP_ITC.1^FTP_TRP.1;FDP_ACC.1.
FDP_UIT	Защита целостности данных пользователя ри передаче между ФБ
FDP_UIT.1	Целостность обмена данными	═	FTP_ITC.1^FTP_TRP.1;FDP_ACC.1^FDP_IFC.1.
FDP_UIT.2	Конечное восстановление обмена данными	═	FTP_ITC.1;FDP_ACC.1^>FDP_IFC.1.
FDP_UIT.3	Исходное восстановление обмена данными	2	FTP_ITC.1;FDP_ACC.1^FDP_IFC.1.
FIA	Идентификация и аутентификация
FIA_ADA	Администрирование данных аутентификации пользователя
FIA_ADA.1	Инициализация данных аутентификации пользователя	═	FPT_TSA.1;FIA_ADP.1;FIA_UAU.1.
FIA_ADA.2	Базовое администрирование данных аутентификации пользователя	1	FPT_TSA.1;FIA_ADP.1;FIA_UAU.1.
FIA_ADA.3	Расширенное администрирование данных аутентификации пользователя	2	FPT_TSA.1;FIA_ADP.1;FIA_UAU.1.
FIA_ADP	Защита данных аутентификации пользователя
FIA_ADP.1	Базовая защита данных аутентификации пользователя	═	FIA_UAU.1.
FIA_ADP.2	Расширенная защита данных аутентификации пользовате	═	FIA_UAU.1.
FIA_AFL	Отказы аутентификации
FIA_AFL.1	Базовая обработка отказа аутентификации	═	FIA_UAU.1.
FIA_AFL.2	Административная обработка отказа аутентификации	1	FIA_UAU.1.
FIA_ATA	Администрирование признака пользователя
FIA_ATA.1	Инициализация признака пользователя	═	FIA_ATD.1;FPT_TSA.1.
FIA_ATA.2	Базовое администрирование признака пользователя	═	FIA_ATD.1;FPT_TSA.1.
FIA_ATA.3	Расширенное администрирование признака пользователя	2	FIA_ATD.1;FPT_TSA.1.
FIA_ATD	Определение признака пользователя
FIA_ATD.1	Определение признака пользователя	═	ADV_FSP.1.
FIA_ATD.2	Определение уникального признака пользователя	1	ADV_FSP.1.
FIA_SOS	Спецификация тайн (паролей)
FIA_SOS.1	Селекция тайн
FIA_SOS.2	ФБ генерации тайн
FIA_UAU	Аутентификация пользователя
FIA_UAU.1	Базовая аутентификация пользователя	═	FIA_UID.1;FIA_ADA.1.
FIA_UAU.2	Опознавательные механизмы с одноразовым использованием	1	FIA_UID.1;FIA_ADA.1.
FIA_UAU.3	Целостность аутентификации	1	FIA_UID.1;FIA_ADA.1.
FIA_UAU.4	Множество опознавательных механизмов	1	FIA_UID.1;FIA_ADA.1.
FIA_UAU.5	Политико-основанные опознавательные механизмы	═	FIA_UAU.1.
FIA_UAU.6	Конфигурируемые опознавательные механизмы	5	FIA_UAU.1.
FIA_UAU.7	Аутентификация по требованию	═	FIA_UAU.1.
FIA_UAU.8	Выбор времени аутентификации	═	FIA_UAU.1.
FIA_UAU.9	Устанавливаемые опознавательные механизмы	═	FIA_UID.1;FPT_TSA.1.
FIA_UID	Идентификация пользователя
FIA_UID.1	Базовая идентификация пользователя	═	FIA_ATD.1.
FIA_UID.2	Уникальная идентификация пользователей	1	FIA_ATD.2.
FIA_UID.3	Выбор времени идентификации
FIA_USB	Закрепление пользователь-субъект
FIA_USB.1	Закрепление пользователь-субъект	═	FIA_ATD.1;ADV_FSP.1;FDP_ACI.1
FPR	Секретность
FPR_ANO	Анонимность
FPR_ANO.1	Анонимность
FPR_ANO.2	Анонимность ФБ	1
FPR_PSE	Псевдонимность
FPR_PSE.1	Псевдонимность
FPR_PSE.2	Обратимая псевдонимность	1	FIA_UID.1.
FPR_PSE.3	Псевдоимя псевдонимности	1
FPR_UNL	Автономность
FPR_UNL.1	Автономность
FPR_UNO	Скрытность
FPR_UNO.1	Ненаблюдаемость
FPR_UNO.2	Наблюдаемость уполномоченным администратором	1
FPT	Защита доверенных функций безопасности
FPT_AMT	Встроенное тестирование абстрактной машины
FPT_AMT.1	Тестирование абстрактной машины
FPT_AMT.2	Тестирование абстрактной машины при запуске
FPT_AMT.3	Тестирование абстрактной машины во время нормальной работы	1,2
FPT_FLS	Безопасность при отказе
FPT_FLS.1	Отказ с сохранением безопасного состояния	═	ADV_FSP.2.
FPT_ITA	Пригодность данных ФБ при обмене между ФБ
FPT_ITA.1	Пригодность в пределах определенного фактора пригодности
FPT_ITC	Конфиденциальность данных ФБ при обмене между ФБ
FPT_ITC.1	Конфиденциальность при передаче между ФБ
FPT_ITI	Целостность данных ФБ при обмене между ФБ
FPT_ITI.1	Обнаружение модификации
FPT_ITI.2	Обнаружение и исправление модификации	1
FPT_ITT	Передача данных ФБ внутри ОО
FPT_ITT.1	Базовая внутренняя защита передачи данных ФБ
FPT_ITT.2	Разделение передаваемых данных признаком	1
FPT_ITT.3	Контроль целостности данных ФБ	1
FPT_PHP	Физическая защита ФБ
FPT_PHP.1	Пассивное обнаружение физического нападения	═	AGD_ADM.1;FPT_TSA.1.
FPT_PHP.2	Уведомление о физическом нападении	1	AGD_ADM.1;FPT_TSA.1.
FPT_PHP.3	Сопротивление физическому нападению	2	AGD_ADM.1;FPT_TSA.1.
FPT_RCV	Восстановление доверия
FPT_RCV.1	Ручное восстановление	═	FPT_TSA.1;FPT_TST.1;>AGD_ADM.1;ADV_FSP.2.
FPT_RCV.2	Автоматизированное восстановление	1	FPT_TSA.1;FPT_TST.1;AGD_ADM.1;ADV_FSP.2.
FPT_RCV.3	Автоматизированное восстановление без чрезмерной потери	2	FPT_TSA.1;FPT_TST.1;AGD_ADM.1;ADV_FSP.2.
FPT_RCV.4	Восстановление функции	═	FPT_TSA.1;FPT_TST.1;AGD_ADM.1;ADV_FSP.2.
FPT_REV	Аннулирование
FPT_REV.1	Основное аннулирование
FPT_REV.2	Немедленное аннулирование	1
FPT_RPL	Обнаружение и предотвращение подмены
FPT_RPL.1	Обнаружение и предотвращение подмены
FPT_RVM	Посредничество ссылки
FPT_RVM.1	Невозможная для обхода ПФБ
FPT_SAE	Истечение признака безопасности
FPT_SAE.1	Ограниченное по времени разрешение
FPT_SEP	Разделение области
FPT_SEP.1	Разделение области ФБ
FPT_SEP.2	Монитор ссылки для некоторых ПФБ	1
FPT_SEP.3	Полный монитор ссылки	2
FPT_SSP	Протокол синхронизации состояний
FPT_SSP.1	Простое доверенное подтверждение	═	FPT_ITI.1;FTP_ITC.1.
FPT_SSP.2	Взаимное доверенное подтверждение	1	FPT_ITI.1;FTP_ITC.1.
FPT_STM	Метки времени
FPT_STM.1	Доверенные метки времени
FPT_SWM	Модификация программного обеспечения ФБ
FPT_SWM.1	Защита выполняемых программ
FPT_TDC	Последовательность данных ФБ при передаче между ФБ
FPT_TDC.1	Базовая последовательность данных ФБ при передаче между ФБ
FPT_TRC	Последовательность данных ФБ при копировании внутри ОО
FPT_TRC.1	Последовательность данных внутри ОО	═	FPT_ITT.1.
FPT_TSA	Администрирование безопасности ОО
FPT_TSA.1	Базовое администрирование безопасности	═	FIA_UID.1;FIA_ATD.1;FIA_ATA.1;AGD_ADM.1.
FPT_TSA.2	Отдельная административная роль безопасности	1	FIA_UID.1;FIA_ATD.1;FIA_ATA.1;AGD_ADM.1.
FPT_TSA.3	Различные административные роли безопасности	2	FIA_UID.1;FIA_ATD.1;FIA_ATA.1;AGD_ADM.1.
FPT_TSA.4	Строго-определенные административные роли	3	FIA_UID.1;FIA_ATD.1;FIA_ATA.1;AGD_ADM.1.
FPT_TSM	Управление безопасностью ОО
FPT_TSM.1	Функции управления	═	FPT_TSA.1.
FPT_TST	Самотестирование ФБ
FPT_TST.1	Тестирование ФБ по требованию	═	FPT_AMT.1.
FPT_TST.2	Тестирование ФБ в процессе запуска	1	FPT_AMT.2.
FPT_TST.3	Тестирование в течение нормального действия	2	FPT_AMT.3.
FPT_TSU	Безопасное административное использование объекта оценки
FPT_TSU.1	Осуществление административного руководства	═	FPT_TSA.1;AGD_ADM.1.
FPT_TSU.2	Безопасные административные стандарты	1	FPT_TSA.1;AGD_ADM.1.
FPT_TSU.3	Определение стандартов администратором	2	FPT_TSA.1;AGD_ADM.1.
FRU	Использование ресурса
FRU_FLT	Устойчивость при отказе
FRU_FLT.1	Пониженная устойчивость при отказе	═	FPT_FLS.1;ADV_FSP.1.
FRU_FLT.2	Предельная устойчивость при отказе	1	FPT_FLS.1;ADV_FSP.1.
FRU_PRS	Приоритет обслуживания
FRU_PRS.1	Ограниченный приоритет обслуживания
FRU_PRS.2	Полный приоритет обслуживания	1
FRU_PRS.3	Управление приоритетами обслуживания	═	FRU_PRS.1;FPT_TSA.1;FIA_UID.1.
FRU_RSA	Распределение ресурса
FRU_RSA.1	Максимальные квоты	═	FIA_UID.1.
FRU_RSA.2	Минимальные и максимальные квоты	1	FIA_UID.1.
FRU_RSA.3	Управление квотами	═	FRU_RSA.1;FRT_TSA.1.
FTA	Доступ к ОО
FTA_LSA	Ограничение на возможности выбираемых признаков
FTA_LSA.1	Ограничение на возможности выбираемых признаков	═	FIA_ATD.1;FTA_TAM.1.
FTA_MCS	Ограничение на параллельные сеансы
FTA_MCS.1	Базовое ограничение на параллельные сеансы	═	FPT_TSA.1.
FTA_MCS.2	Ограничение по признаку пользователя на параллельные сеансы	1	FIA_UID.1;FPT_TSA.1.
FTA_SSL	Блокирование сеанса
FTA_SSL.1	Блокирование сеанса по инициативе ФБ	═	FTA_TAM.1;FIA_UAU.1.
FTA_SSL.2	Блокирование по инициативе пользователя	═	FTA_TAM.1;FIA_UAU.1.
FTA_SSL.3	Завершение по инициативе ФБ	═	FTA_TAM.1.
FTA_TAB	Правила доступа к ОО
FTA_TAB.1	Стандартные правила доступа к ОО
FTA_TAB.2	Конфигурируемые правила доступа к ОО	1	FTA_TAM.1.
FTA_TAH	Хронология доступа к ОО
FTA_TAH.1	Хронология доступа к ОО
FTA_TAM	Управление доступом к ОО
FTA_TAM.1	Базовое управление доступом к ОО	═	FPT_TSA.1.
FTA_TSE	Установление сеанса с ОО
FTA_TSE.1	Установление сеанса с ОО	═	FIA_ATD.1;FTA_TAM.1.
FTP	Надежный маршрут/канал
FTP_ITC	Надежный канал обмена между ФБ
FTP_ITC.1	Надежный канал обмена между ФБ
FTP_TRP	Надежный маршрут
FTP_TRP.1	Надежный маршрут

Таблица I-2. Каталог требований гарантии оценки

Класс, Семейство, Компонент	Название	Зависимость
ACM	Управление конфигурацией
ACM_AUT	Автоматизация
ACM_AUT.1	Частичная автоматизация УК	ACM_CAP.2.
ACM_AUT.2	Полная автоматизация	ACM_CAP.2.
ACM_CAP	Способности УК
ACM_CAP.1	Минимальная поддержка
ACM_CAP.2	Контроль полномочий	ACM_SCP.1; ALC_DVS.1.
ACM_CAP.3	Поддержка генерации и процедуры приема	ACM_SCP.1; ALC_DVS.1.
ACM_CAP.4	Повышенная поддержка	ACM_SCP.1; ALC_DVS.2.
ACM_SCP	Возможности УК
ACM_SCP.1	Минимальный охват УК	ACM_CAP.2.
ACM_SCP.2	Охват УК отслеживаемых проблем	ACM_CAP.2.
ACM_SCP.3	Охват УК инструментов разработки	ACM_CAP.2.
ADO	Поставка и действие
ADO_DEL	Поставка
ADO_DEL.1	Процедуры поставки
ADO_DEL.2	Обнаружение модификации	ACM_CAP.2.
ADO_DEL.3	Предотвращение модификации	ACM_CAP.2.
ADO_IGS	Установка, генерация и запуск
ADO_IGS.1	Процедуры установки,генерации и запуска	AGD_ADM.1.
ADO_IGS.2	Журнал генерации	AGD_ADM.1.
ADV	Разработка
ADV_FSP	Функциональная спецификация
ADV_FSP.1	Объект оценки и политика безопасности	ASE_TSS.1; ADV_RCR.1.
ADV_FSP.2	Неформальная модель ПБ	ASE_TSS.1; ADV_RCR.1.
ADV_FSP.3	Полуформальная модель ПБ	ASE_TSS.1; ADV_RCR.1.
ADV_FSP.4	Формальная модель ПБ	ASE_TSS.1; ADV_RCR.1.
ADV_FSP.5	Спецификация свойств интерпретирующей модели	ASE_TSS.1; ADV_RCR.1.
ADV_FSP.6	Формальная спецификация свойств ФБ	ASE_TSS.1; ADV_RCR.1.
ADV_HLD	Проект высокого уровня
ADV_HLD.1	Описательный проект высокого уровня	ADV_FSP.1; ADV_RCR.1.
ADV_HLD.2	Безопасность в проекте высокого уровня	ADV_FSP.1; ADV_RCR.1.
ADV_HLD.3	Полуформальный проект высокого уровня	ADV_FSP.3; ADV_RCR.2.
ADV_HLD.4	Полуформальное объяснение в проекте высокого уровня	ADV_FSP.3; ADV_RCR.2.
ADV_HLD.5	Формальный проект высокого уровня	ADV_FSP.4; ADV_RCR.3.
ADV_IMP	Представление выполнения
ADV_IMP.1	Поднабор выполнения ФБ	ADV_LLD.1; ADV_RCR.1; ALC_TAT.1.
ADV_IMP.2	Выполнение ФБ	ADV_LLD.1; ADV_RCR.1; ALC_TAT.2.
ADV_IMP.3	Структурированное выполнение ФБ	ADV_INT.1; ADV_LLD.1; ADV_RCR.1; ALC_TAT.3.
ADV_INT	Внутренняя структура ФБ
ADV_INT.1	Модульность	ADV_IMP.1; ADV_LLD.1.
ADV_INT.2	Иерархическое представление	ADV_IMP.1; ADV_LLD.1.
ADV_INT.3	Минимизация сложности	ADV_IMP.2; ADV_LLD.1.
ADV_LLD	Проект низкого уровня
ADV_LLD.1	Описательный проект низкого уровня	ADV_HLD.1; ADV_RCR.1.
ADV_LLD.2	Полуформальный проект низкого уровня	ADV_HLD.3; ADV_RCR.2.
ADV_LLD.3	Формальный проект низкого уровня	ADV_HLD.5; ADV_RCR.3.
ADV_RCR	Соответствие представления
ADV_RCR.1	Неформальная демонстрация соответствия
ADV_RCR.2	Полуформальная демонстрация соответствия
ADV_RCR.3	Формальная демонстрация соответствия
AGD	Документы руководства
AGD_ADM	Руководство администратора
AGD_ADM.1	Руководство администратора	ADV_FSP.1.
AGD_USR	Руководство пользователя
AGD_USR.1	Руководство пользователя
ALC	Поддержка жизненного цикла
ALC_DVS	Безопасность разработки
ALC_DVS.1	Идентификация мер безопасности
ALC_DVS.2	Достаточность мер безопасности
ALC_FLR	Устранение недостатков
ALC_FLR.1	Базовое устранение недостатков
ALC_FLR.2	Процедуры сообщений о недостатках	AGD_ADM.1.
ALC_FLR.3	Систематическое устранение недостатков	AGD_ADM.1.
ALC_FLR.4	Своевременное устранение недостатков	AGD_ADM.1.
ALC_LCD	Определение жизненного цикла
ALC_LCD.1	Определение модели жизненного цикла разработчиком
ALC_LCD.2	Стандартизированная модель цикла жизни
ALC_LCD.3	Измеримая модель цикла жизни
ALC_TAT	Инструменты и методы
ALC_TAT.1	Хорошо апробированные инструменты разработки
ALC_TAT.2	Соответствие стандартам выполнения	ADV_IMP.1.
ALC_TAT.3	Соответствие всех частей объекта оценки стандартам выполнения	ADV_IMP.1.
ATE_	Тестирование
ATE_COV	Достаточность
ATE_COV.1	Полный охват - неформальный	ADV_FSP.1; ATE_FUN.1.
ATE_COV.2	Полный охват — строгий	ADV_FSP.1; ATE_FUN.1.
ATE_COV.3	Упорядоченное тестирование	ADV_FSP.1; ATE_FUN.1.
ATE_DPT	Глубина
ATE_DPT.1	Тестирование на уровне функциональной спецификации	ADV_FSP.1; ATE_FUN.1.
ATE_DPT.2	Тестирование на уровне проекта высокого уровня	ADV_FSP.1; ADV_HLD.1; ATE_FUN.1.
ATE_DPT.3	Тестирование на уровне проекта низкого уровня	ADV_FSP.1; ADV_HLD.1; ADV_LLD.1; ATE_FUN.1.
ATE_DPT.4	Тестирование на уровне выполнения	ADV_FSP.1; ADV_HLD.1; ADV_IMP.2; ADV_LLD.1; ATE_FUN.1.
ATE_FUN	Функциональное тестирование
ATE_FUN.1	Функциональное тестирование	ATE_COV.1; ATE_DPT.1.
ATE_IND	Независимое тестирование
ATE_IND.1	Независимое тестирвоание на соответствие	ADV_FSP.1; AGD_USR.1; AGD_ADM.1.
ATE_IND.2	Независимое тестирование по образцу	ADV_FSP.1; AGD_USR.1; AGD_ADM.1; ATE_FUN.1.
ATE_IND.3	Полное независимое тестирование	ADV_FSP.1; AGD_USR.1; AGD_ADM.1; ATE_FUN.1.
AVA	Оценка уязвимостей
AVA_CCA	Анализ тайных каналов
AVA_CCA.1	Анализ тайных каналов	ADV_FSP.1; ADV_IMP.1; AGD_ADM.1; AGD_USR.1.
AVA_CCA.2	Систематический анализ тайных каналов	ADV_FSP.1; ADV_IMP.2; AGD_ADM.1; AGD_USR.1.
AVA_CCA.3	Исчерпывающий анализ тайных каналов	ADV_FSP.1; ADV_IMP.2; AGD_ADM.1; AGD_USR.1.
AVA_MSU	Неправильное применение
AVA_MSU.1	Анализ неправильного применения — очевидные недостатки	ADO_IGS.1; AGD_ADM.1; AGD_USR.1.
AVA_MSU.2	Анализ неправильного применения - независимая верификация	ADO_IGS.1; AGD_ADM.1; AGD_USR.1.
AVA_SOF	Сила функций безопасности ОО
AVA_SOF.1	Оценка силы функции безопасности ОО	ADV_FSP.1; ADV_HLD.1.
AVA_VLA	Анализ уязвимостей
AVA_VLA.1	Анализ уязвимостей разработчиком	ADV_FSP.1; ADV_HLD.1; AGD_ADM.1; AGD_USR.1.
AVA_VLA.2	Независимый анализ уязвимостей	ADV_FSP.1; ADV_HLD.1; ADV_IMP.1; ADV_LLD.1; AGD_ADM.1; AGD_USR.1.
AVA_VLA.3	Относительно стойкий	ADV_FSP.1; ADV_HLD.1; ADV_IMP.1; ADV_LLD.1; AGD_ADM.1; AGD_USR.1.
AVA_VLA.4	Высоко стойкий	ADV_FSP.1; ADV_HLD.1; ADV_IMP.1; ADV_LLD.1; AGD_ADM.1; AGD_USR.1.

Таблица I-3. Сравнительная характеристика требований пятого класса защищенности РД ГТК РФ для СВТ и типового профиля защиты ПЗ-5

Требования к показателям пятого класса защищенности	Требования профиля защиты ПЗ-5
Дискреционный принцип контроля доступа . Данное требование пятого класса включает в себя аналогичное требование шестого класса, а именно: Дискреционный принцип контроля доступа КСЗ должен контролировать доступ наименованных субъектов (пользователей) к наименованным объектам (файлам, программам, томам и т.д.).	Функциональные требования. Требования управления доступом . FDP_ACC.1.1 — ФБ должна предписать политику дискреционного контроля доступа для: а) пользователей; б) субъектов, действующих от имени пользователей; в) других именованных субъектов; г) именованных объектов, содержащих данные пользователя; д) [назначение: операции между субъектами и объектами, охваченными управлением доступа]. FDP_ACF.1.1 — ФБ должна предписать политику дискреционного контроля доступа к объектам, основанную на следующих признаках субъекта: а) идентичность пользователя: идентичность пользователя по признакам пользователя; б) список группы: нуль или большее количество тождеств из группы признаков пользователя; в) [назначение: тип субъекта: характер(природа) субъекта].
Для каждой пары (субъект — объект) в СВТ должно быть задано явное и недвусмысленное перечисление допустимых типов доступа (читать, писать и т.д.), т.е. тех типов доступа, которые являются санкционированными для данного субъекта (индивида или группы индивидов) к данному ресурсу СВТ (объекту).	ФБ должна предписать политику дискреционного контроля доступа к объектам, основанную на следующих признаках объекта: а) список контроля доступа: список групп и пользователей со списком (для каждой группы или пользователя) специфических операций, разрешенных на объекте каждой группе или пользователю; б) [назначение: тип объекта:характер управляемого объекта].
КСЗ должен содержать механизм, претворяющий в жизнь дискреционные правила разграничения доступа (ПРД). Контроль доступа должен быть применим к каждому объекту и каждому субъекту (индивиду или группе равноправных индивидов).	FDP_ACF.1.2 — ФБ должна предписать следующие правила, чтобы определить, разрешается ли действие между контролируемыми субъектами и объектами: а) если идентичность субъекта пользователя или любой элемент списка группы субъектов упомянуты в списке контроля доступа к объекту, то субъекту будут предоставлены разрешения доступа, упомянутые в списке контроля доступа; б) если ни идентичность субъекта пользователя, ни любой элемент списка группы субъектов не упомянуты в списке контроля доступа к объекту, то доступ будет предоставляться применением [назначение: правила доступа по умолчанию]; в) если ознакомление со списком контроля доступа дает неоднозначный результат, то эта неоднозначность должна быть разрешена применением [назначение: правила для консультации по списку контроля доступа]. Если различные правила относятся к различным субъектам и объектам, то должны быть представлены все эти правила. FDP_ACI.1.1 — ФБ должна предписать политику стандартных (заданных по умолчанию) признаков, чтобы обеспечить разрешающие или стандартные значения для признаков безопасности объекта, которые используются, чтобы предписать ПФБ. FDP_ACI.1.2 — ФБ должна предоставить возможность спецификации альтернативных начальных значений для отмены стандартных значений после создания объекта.
Механизм, реализующий дискреционный принцип контроля доступа, должен предусматривать возможности санкционированного изменения ПРД, в том числе возможность санкционированного изменения списка пользователей СВТ и списка защищаемых объектов. Права изменять ПРД должны предоставляться выделенным субъектам (администрации, службе безопасности и т.д.). Кроме того, должны быть предусмотрены средства управления, ограничивающие распространение прав на доступ.	FDP_SAM.2.1 — ФБ должна предписать следующие правила доступа, чтобы обеспечить уполномоченным пользователям возможность модифицировать признаки объекта: а) Разрешение доступа к объекту пользователям, не обладающим таким разрешением, может быть назначено только уполномоченными пользователями. б) [Назначение: дополнительные правила для изменения признаков объекта].
Очистка памяти . При первоначальном назначении или при перераспределении внешней памяти КСЗ должен предотвращать доступ субъекту к остаточной информации.	FDP_RIP.1.1 — ФБ должна гарантировать, что после распределения ресурсов по объектам, которые содержат данные пользователей, любое предыдущее информационное содержание (включая зашифрованные представления) недоступно.
Идентификация и аутентификация . Данное требование полностью совпадает с требованием для шестого класса, а именно: КСЗ должен требовать от пользователей идентифицировать себя при запросах на доступ. КСЗ должен подвергать проверке подлинность идентификации осуществлять аутентификацию. КСЗ должен располагать необходимыми данными для идентификации и аутентификации. КСЗ должен препятствовать доступу к защищаемым ресурсам неидентифицированных пользователей и пользователей, подлинность идентификации которых при аутентификации не подтвердилась.	Требования идентификации и аутентификации. FIA_UID.1.1 — ФБ должна идентифицировать каждого пользователя перед выполнением любых действий, требуемых пользователем. FIA_UAU.1.1 — ФБ должна подтвердить подлинность требуемой идентичности любого пользователя до выполнения любых функций для пользователя. FIA_ATD.1.1 — ФБ должна обеспечить для каждого пользователя набор признаков безопасности, необходимый, чтобы предписать ПФБ. FIA_ATA.1.1 — ФБ должна обеспечить способность инициализации признаков пользователя с обеспеченными стандартными значениями. FIA_ADP.2.1 — ФБ должна защитить от несанкционированного наблюдения, модификации и разрушения необработанную форму опознавательных данных всегда во время их хранения в ОО.
Регистрация (аудит) . КСЗ должен быть в состоянии осуществлять регистрацию следующих событий: использование идентификационного и аутентификационного механизма; запрос на доступ к защищаемому ресурсу (открытие файла, запуск программы и т.д.); создание и уничтожение объекта; действия по изменению ПРД.	Требования аудита . FAU_GEN.1.1 — ФБ должна быть способна произвести запись аудита следующих контролируемых событий: а) Запуск и завершение контролируемых процессов; б) Все контролируемые события для базового уровня аудита, определенные во всех функциональных компонентах, включенных в ПЗ-5, а именно: [FIA_UID] — Все попытки использовать механизм идентификации пользователя, в том числе, при условии идентичности пользователя. Начало запроса должно быть включено в контрольную запись. [FIA_UAU] — Любое использование опознавательного механизма. Начало запроса должно быть включено в контрольную запись. [FIA_ATA] — Все запросы на использование функции администрирования признака пользователя, включая идентификацию признаков пользователя, которые были изменены. [FIA_ADP] — Все запросы к данным аутентификации пользователя. [FAU_PRO] — Любая попытка читать, модифицировать или уничтожить трассу контроля. [FAU_MGT] — Любая попытка выполнять операции с трассой контроля. [FAU_SEL] — Все модификации конфигурации аудита, которые происходят во время работы набора контрольных функций. [FDP_ACF] — Все запросы для выполнения операции на объекте, охваченном ПФБ, включая введение объектов в адресное пространство пользователя и стирание объектов. [FDP_ACI] — Любые изменения или отмена стандартных признаков объекта, включая идентификацию стандартных признаков объекта, которые были изменены или отменены. [FDP_SAM] — Все попытки модифицировать признаки безопасности, включая идентификацию объекта попытки изменения и новые значения модифицированных признаков безопасности. [FPT_AMT] — Выполнение тестирования основной машины и результаты проверок. [FPT_TSA] — Использование относящейся к безопасности административной функции. в) [назначение: другие контролируемые события].
Для каждого из этих событий должна регистрироваться следующая информация: дата и время; субъект, осуществляющий регистрируемое действие; тип события (если регистрируется запрос на доступ, то следует отмечать объект и тип доступа); успешно ли осуществилось событие (обслужен запрос на доступ или нет).	FAU_GEN.1.2 — ФБ должна в пределах каждой записи аудита фиксировать по крайней мере следующую информацию: а) Дата и время события, тип события, идентичность субъекта и результат (успех, неудача) события. б) Для каждого типа контролируемых событий [назначение: другая, относящаяся к аудиту, информация]. FAU_GEN.2.1 — ФБ должна быть способна связать любое контролируемое событие с идентичностью пользователя, который явился причиной события. FAU_STG.1.1 — ФБ должна обеспечить хранение полученных записей аудита в постоянной трассе контроля. FAU_PRO.1.1 — ФБ должна разрешать доступ к трассе контроля только уполномоченному администратору. FAU_MGT.1.1 - ФБ должна обеспечивать уполномоченному администратору возможность создавать, удалять и освобождать трассу контроля. FAU_SEL.1.1 — ФБ должна быть способна включать или исключать контролируемые события из набора ревизуемых событий на основе следующих признаков: а) идентичность пользователя; б) признаки объекта.
КСЗ должен содержать средства выборочного ознакомления с регистрационной информацией.	FAU_SEL.2.2 — ФБ должна обеспечить уполномоченному администратору возможность выбирать в любое время в течение действия ОО события, которые должны контролироваться. Требования администрирования . FPT_TSA.1.1 — ФБ должна отличать относящиеся к безопасности административные функции от других функций. FPT_TSA.1.2 — Набор относящихся к безопасности административных функций ФБ должен включать все функции, необходимые чтобы инсталлировать, конфигурировать и управлять ФБ; как минимум, этот набор должен включать [назначение: список административных услуг, которые должны быть минимально обеспечены]. FPT_TSA.1.3 — ФБ должна ограничить возможность выполнять относящиеся к безопасности административные функции специально уполномоченными пользователями. FPT_TSA.1.4 — ФБ должна быть способна выделить пользователей, уполномоченных для административных функций, из всех пользователей ОО. FPT_TSU.1.1 — ФБ должна предписать проверки правильности входных значений относящихся к безопасности административных функций как описано в Руководстве администратора.
Целостность КСЗ . В СВТ данного класса защищенности должны быть предусмотрены средства периодического контроля за целостностью программной и информационной части КСЗ.	Защита ФБ и посредничество ссылок . FPT_SEP.1.1 — ФБ должна для собственного выполнения поддерживать область безопасности , которая защищает ее от вмешательства и подделки недоверенными субъектами: а) Передачи между областями ФБ и не-ФБ должны управляться так, чтобы произвольный вход в область ФБ или выход из области ФБ были невозможны. б) Значения ссылок пользовательских или прикладных параметров, относящихся ФБ, должны быть согласованы с адресным пространством и значениями, ожидаемыми ФБ. в) Разрешения ссылок к объектам (и/или к данным не-ФБ) в качестве параметров ФБ должны быть согласованы с разрешениями, требуемыми ФБ. г) Ссылки на объекты ФБ, используемые функциями изоляции ФБ, должны быть установлены ФБ. д) Область ФБ должна иметь все признаки пользователя и объекта. FPT_SEP.1.2 — ФБ должна предписать разделение между областями безопасности субъектов в ВКФБ. FPT_RVM.1.1 — ФБ должна гарантировать, что функции осуществления ПФБ вызываются и действуют прежде, чем произойдет любое, связанное с безопасностью, действие: ФБ должна обеспечить все ссылки на субъекты, объекты, ресурсы и функции ФБ. Посредничество должно гарантировать, что все подчиненные ссылки объекта направлены функциям политики дискреционного контроля доступа. Посредничество должно гарантировать, что все ссылки ресурсов обращаются к функциям защиты остаточной информации. Ссылки, исходящие от привилегированных субъектов, должны быть установлены в соответствии с атрибутами, определенными для этих субъектов. FPT.AMT.1.1 — ФБ должна обеспечить уполномоченному администратору возможность проверить правильность действия относящихся к безопасности функций, поддержанных аппаратными средствами и программируемым оборудованием, на котором функционирует ОО.
Гарантии проектирования . На начальном этапе проектирования СВТ должна быть построена модель защиты. Модель должна включать в себя ПРД к объектам и непротиворечивые правила изменения ПРД.	Требования гарантированности . ОО должен выполнить требования уровня гарантии оценки УГО3, а именно: ADV_FSP.1 (Объект оценки и политика безопасности). ADV_FSP.1.1D — Разработчик должен обеспечить функциональную спецификацию. ADV_FSP.1.2D — Разработчик должен обеспечить ПФБ. ADV_FSP.1.1C — Функциональная спецификация должна описать ФБ с использованием неформального стиля. ADV_FSP.1.2C — Функциональная спецификация должна включать неформальное представление синтаксиса и семантики всех внешних интерфейсов ФБ. ADV_FSP.1.3C — Функциональная спецификация должна включать свидетельство, которое демонстрирует, что ФБ полностью представлена. ADV_FSP.1.1E — Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельства. ADV_FSP.1.2E — Оценщик должен решить, что функциональная спецификация согласуется с ПФБ. ADV_FSP.1.3E — Оценщик должен определить, адресованы ли функциональные требования ЗБ представлениям ФБ.
Конструкторская (проектная) документация . Должна содержать описание принципов работы СВТ, общую схему КСЗ, описание интерфейсов КСЗ с пользователем и интерфейсов модулей КСЗ, модель защиты, описание механизмов контроля целостности КСЗ, очистки памяти, идентификации и аутентификации.	ADV_HLD.2 (Безопасность, предусмотренная проектом высокого уровня) ADV_HLD.2.1D - Разработчик должен обеспечить проект высокого уровня ФБ. ADV_HLD.2.1C — Представление проекта высокого уровня должно быть неформальным. ADV_HLD.2.2C — Проект высокого уровня должен описать структуру ФБ в терминах подсистем. ADV_HLD.2.3C — Проект высокого уровня должен описать функциональные возможности безопасности, обеспеченные каждой подсистемой ФБ. ADV_HLD.2.4C — Проект высокого уровня должен идентифицировать интерфейсы подсистем ФБ. ADV_HLD.2.5C — Проект высокого уровня должен идентифицировать любые основные аппаратные средства ЭВМ, программируемое оборудование и/или программное обеспечение, требуемое ФБ, с представлением функций, обеспеченных поддерживающими механизмами защиты, осуществленными в этих аппаратных средствах ЭВМ, программируемом оборудовании или программном обеспечении. ADV_HLD.2.6C — Проект высокого уровня должен описать разделение ФБ на подсистемы, осуществляющие ПФБ, и другие подсистемы. ADV_HLD.2.1E — Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств. ADV_HLD.2.2E — Оценщик должен определить, адресованы ли функциональные требования ЗБ представлениям ФБ. ADV_RCR. 1 (Неформальная демонстрация соответствия). ADV_RCR.1.1D — Разработчик должен обеспечить свидетельство, что наименее абстрактное представление ФБ есть точное, последовательное и полное преобразование функциональных требований, выраженных в ЦБ. ADV_RCR.1.1C — Для каждой смежной пары представлений ФБ свидетельство должно демонстрировать, что все части более абстрактного представления преобразованы в менее абстрактные представления. ADV_RCR.1.2C — Для каждой смежной пары представлений ФБ демонстрация соответствия между представлениями может быть неформальная. ADV_RCR.1.1E — Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств. ADV_RCR.1.2E — Оценщик должен проанализировать соответствие между функциональными требованиями, выраженными в ЗБ, и наименее абстрактным представлением, чтобы гарантировать точность, последовательность и законченность. ALC_DVS.1 (Идентификация мер безопасности) ALC_DVS.1.1D — Разработчик должен предъявить документацию безопасности разработки. ALC_DVS.1.1C — Документация безопасности разработки должна описать физические, процедурные, персональные и другие меры безопасности, которые используются, чтобы защитить конфиденциальность и целостность ОО в течение разработки. ALC_DVS.1.2C — Документация безопасности разработки должна обеспечить свидетельство того, что эти меры безопасности применяются в течение разработки и обслуживания ОО. ALC_DVS.1.1E — Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств. ALC_DVS.1.2E — Оценщик должен проверить, применяются ли меры безопасности.
Тестирование . В данном классе защищенности должны тестироваться: реализация ПРД (перехват явных и скрытых запросов на доступ, правильное распознавание санкционированных и несанкционированных запросов, средства защиты механизма разграничения доступа, санкционированные изменения ПРД); успешное осуществление идентификации и аутентификации, а также их средства защиты; очистка памяти в соответствии с п. 2.3.2; регистрация событий в соответствии с п. 2.3.5, средства защиты регистрационной информации и возможность санкционированного ознакомления с ней; работа механизма, осуществляющего контроль за целостностью КСЗ.	ATE_FUN.1 (Функциональное тестирование) ATE_FUN.1.1D — Разработчик должен проверить ФБ и задокументировать результаты. ATE_FUN.1.2D — Разработчик должен обеспечить тестовую документацию. ATE_FUN.1.1C - Тестовая документация должна состоять из планов тестирования, процедур тестирования и проверки результатов. ATE_FUN.1.2C — Планы тестирования должны идентифицировать функции безопасности, которые будут проверены, и описать цели тестирования, которые будут выполнены. ATE_FUN.1.3C — Описания процедур тестирования должны идентифицировать тесты, которые будут выполнены, и описать сценарии для тестирования каждой функции безопасности.
Тестовая документация . Должно быть предоставлено описание тестов и испытаний, которым подвергалось СВТ в соответствии с требованиями п. 2.3.7, и результатов тестирования.	ATE_FUN.1.4C — Результаты тестирования в тестовой документации должны показать ожидаемые результаты каждого теста. ATE_FUN.1.5C - Результаты тестирования, выполненного разработчиком, должны демонстрировать, что каждая функция безопасности работает как определено. ATE_FUN.1.1E — Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств. ATE_IND.2 (Независимое тестирование по образцу). ATE_IND.2.1D — Разработчик должен обеспечить ОО для тестирования. ATE_IND.2.1C — ОО должен быть подходящим для тестирования. АTE_IND.2.1E — Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств. ATE_IND.2.2E — Оценщик должен проверить ФБ, чтобы подтвердить, что ФБ работает как определено. ATE_IND.2.3E — Оценщик должен выполнить образец тестирование по тестовой документации, чтобы проверить результаты тестирования разработчиком. ATE_COV.2 (Полный охват - строгий) ATE_COV.2.1D — Разработчик должен обеспечить анализ достаточности тестов. ATE_COV.2.1C — Анализ достаточности тестов должен демонстрировать, что тесты, идентифицированные в тестовой документации, охватывают ФБ. ATE_COV.2.2C — Анализ достаточности тестов должен демонстрировать соответствие между функциями безопасности и результатами тестирования, идентифицированными в тестовой документации. ALC_COV.2.1E — Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств. ATE_DPT.2 (Тестирование на уровне проекта высокого уровня) ATE_DPT.2.1D — Разработчик должен обеспечить анализ глубины тестирования. ATE_DPT.2.1C — Анализ глубины должен демонстрировать, что тесты, идентифицированные в тестовой документации, достаточны, чтобы демонстрировать, что ОО работает в соответствии с функциональной спецификацией и проектом высокого уровня ФБ. ATE_DPT.2.1E — Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств. AVA_VLA.1 (Анализ уязвимостей разработчиком) AVA_VLA.1.1D — Разработчик должен тщательно выполнить и задокументировать анализ представляемого ОО по поиску очевидных путей, которыми пользователь может нарушить ПФБ AVA_VLA.1.2D - Разработчик должен задокументировать расположение идентифицированных уязвимостей. AVA_VLA.1.1C - Свидетельство должно показать для каждой уязвимости, что уязвимость не может эксплуатироваться в предназначенной для ОО окружающей среде. AVA_VLA.1.1E — Оценщик должен подтвердить, что представленная информация выполняет все требования для содержания и представления свидетельств. AVA_VLA.1.2E — Оценщик должен провести испытание проникновения, основанное на анализе уязвимости разработчиком, и гарантировать, что очевидные уязвимости были адресованы (учтены). AVA_MSU.1 (Анализ неправильного применения — очевидные недостатки) AVA_MSU.1.1D - Разработчик должен задокументировать результаты анализа документации руководств в части противоречивости и полноты. AVA_MSU.1.2D - Разработчик должен гарантировать, что документация руководств не содержит никаких вводящих в заблуждение инструкций. AVA_MSU.1.1C — Документация результатов анализа должна демонстрировать, что руководства не имеют противоречий и достаточно полны. AVA_MSU.1.1E — Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств. AVA_MSU.1.2E — Оценщик должен установить, что не имеется никаких вводящих в заблуждение указаний в руководящей документации. AVA_MSU.1.3E — Оценщик должен повторить любые процедуры в документации руководств, чтобы гарантировать, что они дают зарегистрированные результаты. AVA_SOF.1 (Оценка силы функции безопасности ОО) AVA_SOF.1.1D — Разработчик должен идентифицировать все механизмы безопасности ОО, для которых анализ силы функции безопасности ОО является свойственным. AVA_SOF.1.2D — Разработчик должен провести анализ силы функции безопасности для каждого идентифицированного механизма. AVA_SOF.1.1C — Анализ силы функции безопасности ОО должен определить воздействие идентифицированных механизмов безопасности ОО на способности функций безопасности ОО противостоять угрозам. AVA_SOF.1.2C — Анализ силы функции безопасности ОО должен демонстрировать, что идентифицированная сила функций безопасности согласуется с целями безопасности ОО. AVA_SOF.1.3C — Каждое требование силы должно быть или базовое, или среднее, или высокое. AVA_SOF.1.1E — Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств. AVA_SOF.1.2E — Оценщик должен подтвердить, что все механизмы безопасности ОО, требующие анализ силы, были идентифицированы. AVA_SOF.1.3E — Оценщик должен подтвердить, что требования силы правильны. ADO_IGS.1 (Процедуры инсталляции, генерации и запуска) ADO_IGS.1.1D — Разработчик должен задокументировать процедуры, которые нужно использовать для безопасной установки, генерации и запуска ОО. ADO_IGS.1.1C — Документация должна описать шаги, необходимые для безопасной установки, генерации и запуска ОО. ADO_IGS.1.1E — Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств. ACM_CAP.2 (Контроль полномочий) ACM_CAP.2.1D — Разработчик должен использовать систему УК. ACM_CAP.2.2D — Разработчик должен обеспечить документацию УК. ACM_CAP.2.1C - Документация УК должна включать список конфигурации и план УК. ACM_CAP.2.2C — Список конфигурации должен описать изделия конфигурации, которые включает ОО. ACM_CAP.2.3C — Документация УК должна описать метод, используемый, чтобы уникально идентифицировать изделия конфигурации ОО. ACM_CAP.2.4C — План УК должен описать, как используется система УК. ACM_CAP.2.5C — Документация УК должна обеспечить свидетельство того, что система УК работает должным образом. ACM_CAP.2.6C — Документация УК должна обеспечить свидетельство того, что все изделия конфигурации охвачены и эффективно поддерживаются системой УК. ACM_CAP.2.7C — Система УК должна гарантировать, что только санкционированные изменения сделаны в изделиях конфигурации ОО. ACM_CAP.2.1E - Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств. ACM_SCP.1 (Минимальный охват УК) ACM_SCP.1.1C — Как минимум, следующее должно быть прослежено системой УК: представление выполнения ОО, проектная документация, испытательная документация, документация пользователя, документация администратора и документация УК. ACM_SCP.1.2C — Документация УК должна описать, как изделия конфигурации прослеживаются системой УК. ACM_SCP.1.1E — Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств.
Руководство пользователя . Требование совпадает с аналогичным требованием шестого класса, а именно: Документация на СВТ должна включать в себя краткое руководство для пользователя с описанием способов использования КСЗ и его интерфейса с пользователем.	AGD_USR.1 (Руководство пользователя) AGD_USR.1.1D — Разработчик должен обеспечить руководство пользователя. AGD_USR.1.1C - Руководство пользователя должно описать ФБ и интерфейсы, доступные пользователю. AGD_USR.1.2C - Руководство пользователя должно содержать руководящие принципы использования функций безопасности, обеспеченных ОО. AGD_USR.1.3C - Руководство пользователя должно содержать предупреждения относительно функций и привилегий, которые должны управляться в безопасной окружающей среде обработки. AGD_USR.1.4C — Руководство пользователя должно описать взаимодействие между видимыми пользователем функциями безопасности. AGD_USR.1.5C — Руководство пользователя должно быть согласовано со всей другой документацией, имеющейся для оценки. AGD_USR.1.1E - Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств.
Руководство по КСЗ . Данный документ адресован администратору защиты. Должен содержать описание контролируемых функций, руководство по генерации КСЗ, описания старта СВТ, процедур проверки правильности старта, процедур работы со средствами регистрации.	AGD_ADM.1 (Руководство администратора) AGD_ADM.1.1D — Разработчик должен обеспечить руководство администратора, адресованное административному персоналу системы. AGD_ADM.1.1C - Руководство администратора должно описать, как управлять объектом оценки безопасным способом. AGD_ADM.1.2C — Руководство администратора должно содержать предупреждения относительно функций и привилегий, которыми необходимо управлять для обеспечения безопасности окружающей среды обработки. AGD_ADM.1.3C — Руководство администратора должно содержать руководящие принципы последовательного и эффективного использования функций безопасности в пределах ВКФБ. AGD_ADM.1.4C - Руководство администратора должно описать различие между двумя типами функций: теми, которые позволяют администратору управлять параметрами безопасности, и теми, которые позволяют администратору только получать информацию. AGD_ADM.1.5C — Руководство администратора должно описать все параметры безопасности, находящиеся под контролем администратора. AGD_ADM.1. 6C — Руководство администратора должно описать каждый тип относящегося к безопасности события относительно административных функций, которые должны быть выполнены, включая изменение(замену) характеристик безопасности объектов, находящихся под контролем(управлением) ФБ. AGD_ADM.1.7C — Руководство администратора должно содержать руководящие принципы относительно того, как функции безопасности взаимодействуют. AGD_ADM.1.8C — Руководство администратора должно содержать инструкции относительно конфигурирования ОО. AGD_ADM.1.9C - Руководство администратора должно описать все наборы конфигурации, которые могут использоваться в течение безопасной установки ОО. AGD_ADM.1.10C - Руководство администратора должно описать детали, достаточные для использования процедур, относящихся к администрированию безопасности. AGD_ADM.1.11C - Руководство администратора должно быть согласовано со всеми другими документами, имеющимися для оценки. AGD_ADM.1.1E — Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств. AGD_ADM.1.2E — Оценщик должен подтвердить, что процедуры установки заканчиваются безопасной конфигурацией.

Требования к показателям пятого класса защищенности

Требования профиля защиты ПЗ-5

Дискреционный принцип контроля доступа . Данное требование пятого класса включает в себя аналогичное требование шестого класса, а именно:

Дискреционный принцип контроля доступа КСЗ должен контролировать доступ наименованных субъектов (пользователей) к наименованным объектам (файлам, программам, томам и т.д.).

Функциональные требования.

Требования управления доступом . FDP_ACC.1.1 — ФБ должна предписать политику дискреционного контроля доступа для:

а) пользователей;

б) субъектов, действующих от имени пользователей;

в) других именованных субъектов;

г) именованных объектов, содержащих данные пользователя;

д) [назначение: операции между субъектами и объектами, охваченными управлением доступа].

FDP_ACF.1.1 — ФБ должна предписать политику дискреционного контроля доступа к объектам, основанную на следующих признаках субъекта:

а) идентичность пользователя: идентичность пользователя по признакам пользователя;

б) список группы: нуль или большее количество тождеств из группы признаков пользователя;

в) [назначение: тип субъекта: характер(природа) субъекта].

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

ФБ должна предписать политику дискреционного контроля доступа к объектам, основанную на следующих признаках объекта:

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

б) [назначение: тип объекта:характер управляемого объекта].

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

Контроль доступа должен быть применим к каждому объекту и каждому субъекту (индивиду или группе равноправных индивидов).

FDP_ACF.1.2 — ФБ должна предписать следующие правила, чтобы определить, разрешается ли действие между контролируемыми субъектами и объектами:

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

б) если ни идентичность субъекта пользователя, ни любой элемент списка группы субъектов не упомянуты в списке контроля доступа к объекту, то доступ будет предоставляться применением [назначение: правила доступа по умолчанию];

в) если ознакомление со списком контроля доступа дает неоднозначный результат, то эта неоднозначность должна быть разрешена применением [назначение: правила для консультации по списку контроля доступа].

Если различные правила относятся к различным субъектам и объектам, то должны быть представлены все эти правила.

FDP_ACI.1.1 — ФБ должна предписать политику стандартных (заданных по умолчанию) признаков, чтобы обеспечить разрешающие или стандартные значения для признаков безопасности объекта, которые используются, чтобы предписать ПФБ.

FDP_ACI.1.2 — ФБ должна предоставить возможность спецификации альтернативных начальных значений для отмены стандартных значений после создания объекта.

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

Права изменять ПРД должны предоставляться выделенным субъектам (администрации, службе безопасности и т.д.).

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

FDP_SAM.2.1 — ФБ должна предписать следующие правила доступа, чтобы обеспечить уполномоченным пользователям возможность модифицировать признаки объекта:

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

б) [Назначение: дополнительные правила для изменения признаков объекта].

Очистка памяти . При первоначальном назначении или при перераспределении внешней памяти КСЗ должен предотвращать доступ субъекту к остаточной информации.

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

Идентификация и аутентификация . Данное требование полностью совпадает с требованием для шестого класса, а именно:

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

Требования идентификации и аутентификации.

FIA_UID.1.1 — ФБ должна идентифицировать каждого пользователя перед выполнением любых действий, требуемых пользователем.
FIA_UAU.1.1 — ФБ должна подтвердить подлинность требуемой идентичности любого пользователя до выполнения любых функций для пользователя.
FIA_ATD.1.1 — ФБ должна обеспечить для каждого пользователя набор признаков безопасности, необходимый, чтобы предписать ПФБ.
FIA_ATA.1.1 — ФБ должна обеспечить способность инициализации признаков пользователя с обеспеченными стандартными значениями.
FIA_ADP.2.1 — ФБ должна защитить от несанкционированного наблюдения, модификации и разрушения необработанную форму опознавательных данных всегда во время их хранения в ОО.

Регистрация (аудит) . КСЗ должен быть в состоянии осуществлять регистрацию следующих событий:

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

Требования аудита . FAU_GEN.1.1 — ФБ должна быть способна произвести запись аудита следующих контролируемых событий:

а) Запуск и завершение контролируемых процессов;

б) Все контролируемые события для базового уровня аудита, определенные во всех функциональных компонентах, включенных в ПЗ-5, а именно:

[FIA_UID] — Все попытки использовать механизм идентификации пользователя, в том числе, при условии идентичности пользователя. Начало запроса должно быть включено в контрольную запись.
[FIA_UAU] — Любое использование опознавательного механизма. Начало запроса должно быть включено в контрольную запись.
[FIA_ATA] — Все запросы на использование функции администрирования признака пользователя, включая идентификацию признаков пользователя, которые были изменены.
[FIA_ADP] — Все запросы к данным аутентификации пользователя.
[FAU_PRO] — Любая попытка читать, модифицировать или уничтожить трассу контроля.
[FAU_MGT] — Любая попытка выполнять операции с трассой контроля.
[FAU_SEL] — Все модификации конфигурации аудита, которые происходят во время работы набора контрольных функций.
[FDP_ACF] — Все запросы для выполнения операции на объекте, охваченном ПФБ, включая введение объектов в адресное пространство пользователя и стирание объектов.
[FDP_ACI] — Любые изменения или отмена стандартных признаков объекта, включая идентификацию стандартных признаков объекта, которые были изменены или отменены.
[FDP_SAM] — Все попытки модифицировать признаки безопасности, включая идентификацию объекта попытки изменения и новые значения модифицированных признаков безопасности.
[FPT_AMT] — Выполнение тестирования основной машины и результаты проверок.
[FPT_TSA] — Использование относящейся к безопасности административной функции.

в) [назначение: другие контролируемые события].

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

FAU_GEN.1.2 — ФБ должна в пределах каждой записи аудита фиксировать по крайней мере следующую информацию:

а) Дата и время события, тип события, идентичность субъекта и результат (успех, неудача) события.

б) Для каждого типа контролируемых событий [назначение: другая, относящаяся к аудиту, информация].

FAU_GEN.2.1 — ФБ должна быть способна связать любое контролируемое событие с идентичностью пользователя, который явился причиной события.

FAU_STG.1.1 — ФБ должна обеспечить хранение полученных записей аудита в постоянной трассе контроля.

FAU_PRO.1.1 — ФБ должна разрешать доступ к трассе контроля только уполномоченному администратору.

FAU_MGT.1.1 - ФБ должна обеспечивать уполномоченному администратору возможность создавать, удалять и освобождать трассу контроля.

FAU_SEL.1.1 — ФБ должна быть способна включать или исключать контролируемые события из набора ревизуемых событий на основе следующих признаков:

а) идентичность пользователя;

б) признаки объекта.

КСЗ должен содержать средства выборочного ознакомления с регистрационной информацией.

FAU_SEL.2.2 — ФБ должна обеспечить уполномоченному администратору возможность выбирать в любое время в течение действия ОО события, которые должны контролироваться.

Требования администрирования . FPT_TSA.1.1 — ФБ должна отличать относящиеся к безопасности административные функции от других функций.

FPT_TSA.1.2 — Набор относящихся к безопасности административных функций ФБ должен включать все функции, необходимые чтобы инсталлировать, конфигурировать и управлять ФБ; как минимум, этот набор должен включать [назначение: список административных услуг, которые должны быть минимально обеспечены].

FPT_TSA.1.3 — ФБ должна ограничить возможность выполнять относящиеся к безопасности административные функции специально уполномоченными пользователями.

FPT_TSA.1.4 — ФБ должна быть способна выделить пользователей, уполномоченных для административных функций, из всех пользователей ОО.

FPT_TSU.1.1 — ФБ должна предписать проверки правильности входных значений относящихся к безопасности административных функций как описано в Руководстве администратора.

Целостность КСЗ . В СВТ данного класса защищенности должны быть предусмотрены средства периодического контроля за целостностью программной и информационной части КСЗ.

Защита ФБ и посредничество ссылок . FPT_SEP.1.1 — ФБ должна для собственного выполнения поддерживать область безопасности , которая защищает ее от вмешательства и подделки недоверенными субъектами:

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

б) Значения ссылок пользовательских или прикладных параметров, относящихся ФБ, должны быть согласованы с адресным пространством и значениями, ожидаемыми ФБ.

в) Разрешения ссылок к объектам (и/или к данным не-ФБ) в качестве параметров ФБ должны быть согласованы с разрешениями, требуемыми ФБ.

г) Ссылки на объекты ФБ, используемые функциями изоляции ФБ, должны быть установлены ФБ.

д) Область ФБ должна иметь все признаки пользователя и объекта.

FPT_SEP.1.2 — ФБ должна предписать разделение между областями безопасности субъектов в ВКФБ.

FPT_RVM.1.1 — ФБ должна гарантировать, что функции осуществления ПФБ вызываются и действуют прежде, чем произойдет любое, связанное с безопасностью, действие:

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

FPT.AMT.1.1 — ФБ должна обеспечить уполномоченному администратору возможность проверить правильность действия относящихся к безопасности функций, поддержанных аппаратными средствами и программируемым оборудованием, на котором функционирует ОО.

Гарантии проектирования . На начальном этапе проектирования СВТ должна быть построена модель защиты. Модель должна включать в себя ПРД к объектам и непротиворечивые правила изменения ПРД.

Требования гарантированности . ОО должен выполнить требования уровня гарантии оценки УГО3, а именно:

ADV_FSP.1 (Объект оценки и политика безопасности).
ADV_FSP.1.1D — Разработчик должен обеспечить функциональную спецификацию.
ADV_FSP.1.2D — Разработчик должен обеспечить ПФБ.
ADV_FSP.1.1C — Функциональная спецификация должна описать ФБ с использованием неформального стиля.
ADV_FSP.1.2C — Функциональная спецификация должна включать неформальное представление синтаксиса и семантики всех внешних интерфейсов ФБ.
ADV_FSP.1.3C — Функциональная спецификация должна включать свидетельство, которое демонстрирует, что ФБ полностью представлена.
ADV_FSP.1.1E — Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельства.
ADV_FSP.1.2E — Оценщик должен решить, что функциональная спецификация согласуется с ПФБ.
ADV_FSP.1.3E — Оценщик должен определить, адресованы ли функциональные требования ЗБ представлениям ФБ.

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

ADV_HLD.2 (Безопасность, предусмотренная проектом высокого уровня)

ADV_HLD.2.1D - Разработчик должен обеспечить проект высокого уровня ФБ.

ADV_HLD.2.1C — Представление проекта высокого уровня должно быть неформальным.

ADV_HLD.2.2C — Проект высокого уровня должен описать структуру ФБ в терминах подсистем.

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

ADV_HLD.2.4C — Проект высокого уровня должен идентифицировать интерфейсы подсистем ФБ.

ADV_HLD.2.5C — Проект высокого уровня должен идентифицировать любые основные аппаратные средства ЭВМ, программируемое оборудование и/или программное обеспечение, требуемое ФБ, с представлением функций, обеспеченных поддерживающими механизмами защиты, осуществленными в этих аппаратных средствах ЭВМ, программируемом оборудовании или программном обеспечении.

ADV_HLD.2.6C — Проект высокого уровня должен описать разделение ФБ на подсистемы, осуществляющие ПФБ, и другие подсистемы.

ADV_HLD.2.1E — Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств.

ADV_HLD.2.2E — Оценщик должен определить, адресованы ли функциональные требования ЗБ представлениям ФБ.

ADV_RCR. 1 (Неформальная демонстрация соответствия).

ADV_RCR.1.1D — Разработчик должен обеспечить свидетельство, что наименее абстрактное представление ФБ есть точное, последовательное и полное преобразование функциональных требований, выраженных в ЦБ.

ADV_RCR.1.1C — Для каждой смежной пары представлений ФБ свидетельство должно демонстрировать, что все части более абстрактного представления преобразованы в менее абстрактные представления.

ADV_RCR.1.2C — Для каждой смежной пары представлений ФБ демонстрация соответствия между представлениями может быть неформальная.

ADV_RCR.1.1E — Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств.

ADV_RCR.1.2E — Оценщик должен проанализировать соответствие между функциональными требованиями, выраженными в ЗБ, и наименее абстрактным представлением, чтобы гарантировать точность, последовательность и законченность.

ALC_DVS.1 (Идентификация мер безопасности)

ALC_DVS.1.1D — Разработчик должен предъявить документацию безопасности разработки.

ALC_DVS.1.1C — Документация безопасности разработки должна описать физические, процедурные, персональные и другие меры безопасности, которые используются, чтобы защитить конфиденциальность и целостность ОО в течение разработки.

ALC_DVS.1.2C — Документация безопасности разработки должна обеспечить свидетельство того, что эти меры безопасности применяются в течение разработки и обслуживания ОО.

ALC_DVS.1.1E — Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств.

ALC_DVS.1.2E — Оценщик должен проверить, применяются ли меры безопасности.

Тестирование . В данном классе защищенности должны тестироваться:

реализация ПРД (перехват явных и скрытых запросов на доступ, правильное распознавание санкционированных и несанкционированных запросов, средства защиты механизма разграничения доступа, санкционированные изменения ПРД);
успешное осуществление идентификации и аутентификации, а также их средства защиты;
очистка памяти в соответствии с п. 2.3.2; регистрация событий в соответствии с п. 2.3.5, средства защиты регистрационной информации и возможность санкционированного ознакомления с ней;
работа механизма, осуществляющего контроль за целостностью КСЗ.

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

ATE_FUN.1.1D — Разработчик должен проверить ФБ и задокументировать результаты.

ATE_FUN.1.2D — Разработчик должен обеспечить тестовую документацию.

ATE_FUN.1.1C - Тестовая документация должна состоять из планов тестирования, процедур тестирования и проверки результатов.

ATE_FUN.1.2C — Планы тестирования должны идентифицировать функции безопасности, которые будут проверены, и описать цели тестирования, которые будут выполнены.

ATE_FUN.1.3C — Описания процедур тестирования должны идентифицировать тесты, которые будут выполнены, и описать сценарии для тестирования каждой функции безопасности.

Тестовая документация . Должно быть предоставлено описание тестов и испытаний, которым подвергалось СВТ в соответствии с требованиями п. 2.3.7, и результатов тестирования.

ATE_FUN.1.4C — Результаты тестирования в тестовой документации должны показать ожидаемые результаты каждого теста.

ATE_FUN.1.5C - Результаты тестирования, выполненного разработчиком, должны демонстрировать, что каждая функция безопасности работает как определено.

ATE_FUN.1.1E — Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств.

ATE_IND.2 (Независимое тестирование по образцу).

ATE_IND.2.1D — Разработчик должен обеспечить ОО для тестирования.

ATE_IND.2.1C — ОО должен быть подходящим для тестирования.

АTE_IND.2.1E — Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств.

ATE_IND.2.2E — Оценщик должен проверить ФБ, чтобы подтвердить, что ФБ работает как определено.

ATE_IND.2.3E — Оценщик должен выполнить образец тестирование по тестовой документации, чтобы проверить результаты тестирования разработчиком.

ATE_COV.2 (Полный охват - строгий)

ATE_COV.2.1D — Разработчик должен обеспечить анализ достаточности тестов.

ATE_COV.2.1C — Анализ достаточности тестов должен демонстрировать, что тесты, идентифицированные в тестовой документации, охватывают ФБ.

ATE_COV.2.2C — Анализ достаточности тестов должен демонстрировать соответствие между функциями безопасности и результатами тестирования, идентифицированными в тестовой документации.

ALC_COV.2.1E — Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств.

ATE_DPT.2 (Тестирование на уровне проекта высокого уровня) ATE_DPT.2.1D — Разработчик должен обеспечить анализ глубины тестирования.

ATE_DPT.2.1C — Анализ глубины должен демонстрировать, что тесты, идентифицированные в тестовой документации, достаточны, чтобы демонстрировать, что ОО работает в соответствии с функциональной спецификацией и проектом высокого уровня ФБ.

ATE_DPT.2.1E — Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств.

AVA_VLA.1 (Анализ уязвимостей разработчиком)

AVA_VLA.1.1D — Разработчик должен тщательно выполнить и задокументировать анализ представляемого ОО по поиску очевидных путей, которыми пользователь может нарушить ПФБ

AVA_VLA.1.2D - Разработчик должен задокументировать расположение идентифицированных уязвимостей.

AVA_VLA.1.1C - Свидетельство должно показать для каждой уязвимости, что уязвимость не может эксплуатироваться в предназначенной для ОО окружающей среде.

AVA_VLA.1.1E — Оценщик должен подтвердить, что представленная информация выполняет все требования для содержания и представления свидетельств.

AVA_VLA.1.2E — Оценщик должен провести испытание проникновения, основанное на анализе уязвимости разработчиком, и гарантировать, что очевидные уязвимости были адресованы (учтены).

AVA_MSU.1 (Анализ неправильного применения — очевидные недостатки)

AVA_MSU.1.1D - Разработчик должен задокументировать результаты анализа документации руководств в части противоречивости и полноты.

AVA_MSU.1.2D - Разработчик должен гарантировать, что документация руководств не содержит никаких вводящих в заблуждение инструкций.

AVA_MSU.1.1C — Документация результатов анализа должна демонстрировать, что руководства не имеют противоречий и достаточно полны.

AVA_MSU.1.1E — Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств.

AVA_MSU.1.2E — Оценщик должен установить, что не имеется никаких вводящих в заблуждение указаний в руководящей документации.

AVA_MSU.1.3E — Оценщик должен повторить любые процедуры в документации руководств, чтобы гарантировать, что они дают зарегистрированные результаты.

AVA_SOF.1 (Оценка силы функции безопасности ОО)

AVA_SOF.1.1D — Разработчик должен идентифицировать все механизмы безопасности ОО, для которых анализ силы функции безопасности ОО является свойственным.

AVA_SOF.1.2D — Разработчик должен провести анализ силы функции безопасности для каждого идентифицированного механизма.

AVA_SOF.1.1C — Анализ силы функции безопасности ОО должен определить воздействие идентифицированных механизмов безопасности ОО на способности функций безопасности ОО противостоять угрозам.

AVA_SOF.1.2C — Анализ силы функции безопасности ОО должен демонстрировать, что идентифицированная сила функций безопасности согласуется с целями безопасности ОО.

AVA_SOF.1.3C — Каждое требование силы должно быть или базовое, или среднее, или высокое.

AVA_SOF.1.1E — Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств.

AVA_SOF.1.2E — Оценщик должен подтвердить, что все механизмы безопасности ОО, требующие анализ силы, были идентифицированы.

AVA_SOF.1.3E — Оценщик должен подтвердить, что требования силы правильны.

ADO_IGS.1 (Процедуры инсталляции, генерации и запуска)

ADO_IGS.1.1D — Разработчик должен задокументировать процедуры, которые нужно использовать для безопасной установки, генерации и запуска ОО.

ADO_IGS.1.1C — Документация должна описать шаги, необходимые для безопасной установки, генерации и запуска ОО.

ADO_IGS.1.1E — Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств.

ACM_CAP.2 (Контроль полномочий)

ACM_CAP.2.1D — Разработчик должен использовать систему УК. ACM_CAP.2.2D — Разработчик должен обеспечить документацию УК.

ACM_CAP.2.1C - Документация УК должна включать список конфигурации и план УК.

ACM_CAP.2.2C — Список конфигурации должен описать изделия конфигурации, которые включает ОО.

ACM_CAP.2.3C — Документация УК должна описать метод, используемый, чтобы уникально идентифицировать изделия конфигурации ОО.

ACM_CAP.2.4C — План УК должен описать, как используется система УК.

ACM_CAP.2.5C — Документация УК должна обеспечить свидетельство того, что система УК работает должным образом.

ACM_CAP.2.6C — Документация УК должна обеспечить свидетельство того, что все изделия конфигурации охвачены и эффективно поддерживаются системой УК.

ACM_CAP.2.7C — Система УК должна гарантировать, что только санкционированные изменения сделаны в изделиях конфигурации ОО.

ACM_CAP.2.1E - Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств.

ACM_SCP.1 (Минимальный охват УК)

ACM_SCP.1.1C — Как минимум, следующее должно быть прослежено системой УК: представление выполнения ОО, проектная документация, испытательная документация, документация пользователя, документация администратора и документация УК.

ACM_SCP.1.2C — Документация УК должна описать, как изделия конфигурации прослеживаются системой УК.

ACM_SCP.1.1E — Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств.

Руководство пользователя . Требование совпадает с аналогичным требованием шестого класса, а именно:

Документация на СВТ должна включать в себя краткое руководство для пользователя с описанием способов использования КСЗ и его интерфейса с пользователем.

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

AGD_USR.1.1D — Разработчик должен обеспечить руководство пользователя.

AGD_USR.1.1C - Руководство пользователя должно описать ФБ и интерфейсы, доступные пользователю.

AGD_USR.1.2C - Руководство пользователя должно содержать руководящие принципы использования функций безопасности, обеспеченных ОО.

AGD_USR.1.3C - Руководство пользователя должно содержать предупреждения относительно функций и привилегий, которые должны управляться в безопасной окружающей среде обработки.

AGD_USR.1.4C — Руководство пользователя должно описать взаимодействие между видимыми пользователем функциями безопасности.

AGD_USR.1.5C — Руководство пользователя должно быть согласовано со всей другой документацией, имеющейся для оценки.

AGD_USR.1.1E - Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств.

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

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

AGD_ADM.1.1D — Разработчик должен обеспечить руководство администратора, адресованное административному персоналу системы.

AGD_ADM.1.1C - Руководство администратора должно описать, как управлять объектом оценки безопасным способом.

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

AGD_ADM.1.3C — Руководство администратора должно содержать руководящие принципы последовательного и эффективного использования функций безопасности в пределах ВКФБ.

AGD_ADM.1.4C - Руководство администратора должно описать различие между двумя типами функций: теми, которые позволяют администратору управлять параметрами безопасности, и теми, которые позволяют администратору только получать информацию.

AGD_ADM.1.5C — Руководство администратора должно описать все параметры безопасности, находящиеся под контролем администратора.

AGD_ADM.1. 6C — Руководство администратора должно описать каждый тип относящегося к безопасности события относительно административных функций, которые должны быть выполнены, включая изменение(замену) характеристик безопасности объектов, находящихся под контролем(управлением) ФБ.

AGD_ADM.1.7C — Руководство администратора должно содержать руководящие принципы относительно того, как функции безопасности взаимодействуют.

AGD_ADM.1.8C — Руководство администратора должно содержать инструкции относительно конфигурирования ОО.

AGD_ADM.1.9C - Руководство администратора должно описать все наборы конфигурации, которые могут использоваться в течение безопасной установки ОО.

AGD_ADM.1.10C - Руководство администратора должно описать детали, достаточные для использования процедур, относящихся к администрированию безопасности.

AGD_ADM.1.11C - Руководство администратора должно быть согласовано со всеми другими документами, имеющимися для оценки.

AGD_ADM.1.1E — Оценщик должен подтвердить, что представленная информация выполняет все требования к содержанию и представлению свидетельств.

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

I. Приложение