 |
Функциональные требования безопасности
|
|
|
|
Систематизированный каталог функциональных требований безопасности сосредоточен во второй части ОК. Функциональные требования разбиты на 11 классов, 66 семейств и 135 компонентов.
Структура функционального класса приведена на рис. 3.4.5.1.
Рис. 3.4.5.1. Структура функционального класса
Имя класса содержит информацию, необходимую для идентификации функционального класса и отнесения его к определенной категории. Каждый функциональный класс имеет уникальное имя. Информация о категории предоставлена кратким именем, состоящим из трех букв латинского алфавита. Краткое имя класса используют при задании кратких имен семейств этого класса.
Представление класса содержит рисунок, показывающий все семейства этого класса и иерархию компонентов в каждом семействе.
Структура функционального семейства приведена на рис. 3.4.5.2.
Рис. 3.4.5.2. Структура функционального семейства
Каждое функциональное семейство имеет уникальное имя. Первые три символа идентичны краткому имени класса, далее следуют символ подчеркивания и краткое имя семейства в виде XXX_YYY.
Характеристика семейства – это описание функционального семейства, в котором излагаются его цели безопасности и общее описание функциональных требований. Цели безопасности семейства характеризуют задачу безопасности, которая может быть решена с помощью ОО, включающего компонент из этого семейства. Описание функциональных требований обобщает все требования, которые включены в компоненты.
Цель ранжирования компонентов – предоставить пользователям информацию для выбора подходящего функционального компонента из семейства.
Связи между компонентами в пределах функционального семейства могут быть иерархическими и неиерархическими. Компонент иерархичен (т.е. расположен выше по иерархии) по отношению к другому компоненту, если предлагает большую безопасность.
|
|
|
Требования управления содержат информацию для разработчиков ПЗ/ЗБ, учитываемую при определении действий по управлению для данного компонента. Требования управления детализированы в компонентах класса «Управление безопасностью» (FMT).
Требования аудита содержат события, потенциально подвергаемые аудиту, для их отбора разработчиками ПЗ/ЗБ при условии включения в ПЗ или ЗБ требований из класса FAU «Аудит безопасности». Эти требования включают в себя события, относящиеся к безопасности, применительно к различным уровням детализации, поддерживаемым компонентами семейства FAU_GEN «Генерация данных аудита безопасности». Например, запись аудита какого-либо механизма безопасности может включать на разных уровнях детализации, которые раскрываются в следующих терминах:
· минимальный – успешное использование механизма безопасности;
· базовый – любое использование механизма безопасности, а также информация о текущих значениях атрибутов безопасности.
· детализированный – любые изменения конфигурации механизма безопасности, включая параметры конфигурации до и после изменения.
Структура функционального компонента приведена на рисунке 3.4.5.3.
Рис. 3.4.5.3. Структура функционального компонента
Идентификация компонента включает описательную информацию, необходимую для идентификации, категорирования, записи и реализации перекрестных ссылок компонента. Для каждого функционального компонента представляется следующая информация:
· уникальное имя, отражающее предназначение компонента;
· краткое имя, применяемое как основное имя ссылки для категорирования, записи и реализации перекрестных ссылок компонента и уникально отражающее класс и семейство, к которым компонент принадлежит, а также номер компонента в семействе;
|
|
|
· список иерархических связей, содержащий имена других компонентов, для которых этот компонент иерархичен и вместо которых может использоваться при удовлетворении зависимостей от перечисленных компонентов.
Каждый компонент включает набор элементов. Каждый элемент определяется отдельно и является самодостаточным.
Функциональный элемент – это наименьшее функциональное требование безопасности, идентифицируемое и признаваемое в ОК. При формировании ПЗ или ЗБ не разрешается выбирать только часть элементов компонента – необходимо использовать всю их совокупность.
Вводится уникальная краткая форма имени функционального элемента. Например, имя FDP_IFF.4.2 читается следующим образом: F – функциональное требование, DP – класс «Защита данных пользователя», IFF – семейство «Функции управления информационными потоками», 4 – четвертый компонент «Частичное устранение неразрешенных информационных потоков», 2 – второй элемент компонента.
Зависимости среди функциональных компонентов возникают, когда компонент не самодостаточен и нуждается либо в функциональных возможностях другого компонента, либо во взаимодействии с ним для поддержки собственного выполнения. Список зависимостей идентифицирует минимум функциональных компонентов или компонентов доверия, необходимых для удовлетворения требований безопасности, ассоциированных с данным компонентом. Компоненты, которые иерархичны по отношению к компоненту из списка, также могут быть использованы для удовлетворения зависимости.
Зависимости между компонентами, указанные в части 2 ОК, являются обязательными, и их необходимо удовлетворить при разработке профиля защиты или задания по безопасности. В тех редких случаях, когда эти зависимости удовлетворить невозможно, соответствующее строгое обоснование должно быть приведено в ПЗ или ЗБ.
Классы и семейства представлены во второй части ОК в алфавитном порядке. В начале каждого класса имеется рисунок, показывающий таксономию этого класса, перечисляя семейства в этом классе и компоненты в каждом семействе. Рисунок также иллюстрирует иерархию компонентов внутри каждого семейства.
|
|
|
Пример представления таксономии класса и иерархии компонентов в его семействах приведен на рисунке 3.4.5.4.
Рис. 3.4.5.4. Пример представления класса
Семейство 1 на рис. 3.4.5.4 содержит три иерархических компонента, где компоненты 2 и 3 могут быть применены для выполнения зависимостей вместо компонента 1. Компонент 3 иерархичен к компоненту 2 и может применяться для выполнения зависимостей вместо компонента 2.
В семействе 2 имеются три компонента, не все из которых иерархически связаны. Компоненты 1 и 2 не иерархичны к другим компонентам. Компонент 3 иерархичен к компоненту 2 и может применяться для удовлетворения зависимостей вместо компонента 2, но не вместо компонента 1.
В семействе 3 компоненты 2 – 4 иерархичны к компоненту 1. Компоненты 2 и 3 иерархичны к компоненту 1, но несопоставимы по иерархии между собой. Компонент 4 иерархичен к компонентам 2 и 3.
В таблице 3.4.5 приведена краткая характеристика всех 66 семейств функциональных требований.
Таблица 3.4.5. Семейства функциональных требований
| № п/п | Семейство | Наименование | Характеристика | |
| Класс FAU - аудит безопасности | ||||
| FAU_ARP | Автоматическая реакция аудита безопасности | Определяются действия, которые необходимо предпринять при выявлении возможных нарушений безопасности. | ||
| FAU_GEN | Генерация данных аудита | − Выбираются события, потенциально подвергаемые аудиту и протоколированию. − Определяется минимум регистрируемых данных о событиях безопасности. − Осуществляется привязка событий к идентификаторам вызвавших их пользователей. | ||
| FAU_SAA | Анализ аудита безопасности | Устанавливаются требования к средствам аудита безопасности, функционирующим: − на базе правил; − на базе профилей поведения пользователей; − на базе сигнатур атак. | ||
| FAU_SAR | Просмотр аудита безопасности | − Определяются требования к представлению данных аудита. − Предоставляются права на просмотр записей аудита уполномоченным | ||
| FAU_SEL | Выбор событий аудита безопасности | − Определяются требования по отбору реально протоколируемых событий из числа потенциально подвергаемых протоколированию. − Выделяются атрибуты, по которым производится отбор событий. | ||
| FAU_STG | Хранение данных аудита безопасности | − Определяются требования по защите данных аудита от НСД и повреждения. − Определяется последовательность действий, выполняемых системой при переполнении журнала аудита. | ||
| Класс FCO – связь | ||||
| FCO_NRO | Неотказуемость отправления | Задаются требования по ассоциации атрибутов отправителя информации с элементами передаваемых данных. | ||
| FCO_NRR | Неотказуемость получения | Задаются требования по ассоциации атрибутов получателя информации с элементами передаваемых данных. | ||
| Класс FCS - криптографическая поддержка | ||||
| FCS_CKM | Управление криптографическими ключами | Задаются требования к реализации механизмов генерации, распределения и уничтожения криптографических ключей. | ||
| FCS_COP | Криптографические операции | Декларируется использование тех или иных криптографических средств защиты информации. | ||
| Класс FDP – защита данных пользователя | ||||
| FDP_ACC | Политика управления доступом | Идентифицируются применяемые политики управления доступом. | ||
| FDP_ACF | Функции управления доступом | Описываются правила работы функций, реализующих заявленные политики безопасности. | ||
| FDP_DAU | Аутентификация данных | Определяется порядок генерации и использования данных аутентификации | ||
| FDP_ETC | Экспорт данных за пределы действия ФБО | Определяется порядок экспорта данных за пределы области действия функций безопасности объекта оценки. | ||
| FDP_IFC | Политика управления информационными потоками | − Устанавливаются имена и определяется области действия политик, управляющих информационными потоками. − Задаются требования к покрытию данными политиками всех операций перемещения информации. | ||
| FDP_IFF | Функции управления информационными потоками | − Требуется наличие правил управления информационными потоками. − Определяются правила контроля информационных потоков и управления ими. | ||
| FDP_ITC | Импорт данных из-за пределов действия ФБО | Определяется порядок импорта данных из-за пределов области действия функций безопасности объекта оценки. | ||
| FDP_ITT | Передача в пределах ОО | Определяется порядок защиты данных пользователя при их передаче между различными частями ОО по внутреннему каналу. | ||
| FDP_RIP | Защита остаточной информации | Задаются требования по уничтожению предыдущего содержания ресурсов АС при их освобождении. | ||
| FDP_ROL | Откат | Требуется обеспечение возможности отмены последней выполненной операции (или ряда операций) и возврата к предыдущему состоянию. | ||
| FDP_SDI | Целостность хранимых данных | Задаются требования по контролю целостности данных пользователя. | ||
| FDP_UCT | Защита конфиденциальнос-ти данных пользователя при передаче между ФБО | Определяются требования по обеспечению конфиденциальности данных пользователя при их передаче по внешнему каналу между ОО и доверенными внешними объектами ИТ. | ||
| FDP_UIT | Защита целостности данных пользователя при передаче между ФБО | − Определяются требования по защите целостности данных пользователя при передаче между ФБО. − Задаются требования к механизмам коррекции ошибок. | ||
| Класс FIA – идентификация и аутентификация | ||||
| FIA_AFL | Отказы аутентификации | Задаётся реакция на неудачные запросы аутентификации. | ||
| FIA_ATD | Определение атрибутов пользователя | Определяются атрибуты пользователей, отличные от идентификаторов и используемые для реализации установленных политик. | ||
| FIA_SOS | Спецификация секретов | Задаются требования к механизмам проверки качества и генерации секретов (данных аутентификации). | ||
| FIA_UAU | Аутентификация пользователя | − Задаются требования к реализации механизмов аутентификации. − Определяются механизмы, доступные до осуществления аутентификации пользователя. | ||
| FIA_UID | Идентификация пользователя | − Задаётся порядок идентификации пользователя. − Определяются действия, которые могут быть выполнены до идентификации пользователя. | ||
| FIA_USB | Связывание пользователь-субъект | Определяется связь атрибутов безопасности пользователя с субъектом, действующим от имени пользователя. | ||
| Класс FMT – управление безопасностью | ||||
| FMT_MOF | Управление отдельными функциями ФБО | Определяются пользователи, уполномоченные осуществлять управление режимами выполнения функций безопасности. | ||
| FMT_MSA | Управление атрибутами безопасности | − Определяются пользователи, уполномоченные осуществлять управление атрибутами безопасности. − Регламентируется порядок контроля безопасности параметров данных атрибутов. | ||
| FMT_MTD | Управление данными ФБО | − Определяются пользователи, уполномоченные осуществлять управление ФБО. − Определяются граничные значения данных функций безопасности и действия в случае выхода за допустимые границы. | ||
| FMT_REV | Отмена | Определяется порядок отмены атрибутов безопасности пользователей, субъектов и объектов. | ||
| FMT_SAE | Срок действия атрибута безопасности | Задаются мероприятия, выполняемы по окончании срока действия атрибутов безопасности. | ||
| FMT_SMR | Роли управления безопасностью | Задаются различные роли пользователей системы и создаются правила, управляющие отношениями между ролями. | ||
| Класс FPR – приватность | ||||
| FPR_ANO | Анонимность | Задаётся возможность выполнения определённых действий без запроса идентификатора пользователя | ||
| FPR_PSE | Псевдонимность | Определяется возможность использования ресурсов без раскрытия идентификатора пользователя, но с сохранением подотчётности. | ||
| FPR_UNL | Невозможность ассоциации | Требуется невозможность ассоциирования пользователя с применяемым им сервисом (может потребоваться для защиты от построения поведенческих моделей пользователя). | ||
| FPR_UNO | Скрытность | Требуется предоставление пользователю возможности работы с определёнными сервисами незаметно для кого бы то ни было. | ||
| Класс FPT – защита ФБО | ||||
| FPT_AMT | Тестирование базовой абстрактной машины | Задаются требования, к тестированию, демонстрирующему правильность предположений, обеспечиваемых программно- аппаратной платформой, лежащей в основе функций безопасности. | ||
| FPT_FLS | Безопасность при сбое | Перечисляются типы сбоев, которые не должны приводить к нарушению безопасности системы. | ||
| FPT_ITA | Доступность экспортируемых данных ФБО | Определяются правила предотвращения потери доступности экспортируемых данных функций безопасности. | ||
| FPT_ITC | Конфиденциальность экспортируемых данных ФБО | Определяются правила защиты от несанкционированного раскрытия экспортируемых данных функций безопасности. | ||
| FPT_ITI | Целостность экспортируемых данных ФБО | Определяются правила защиты от несанкционированной модификации экспортируемых данных функций безопасности. | ||
| FPT_ITT | Передача данных ФБО в пределах ОО | Регламентируются требования защиты данных функций безопасности при их передаче между разделенными частями ОО по внутреннему каналу | ||
| FPT_PHP | Физическая защита ФБО | Требуется наличие средств выявления и реагирования на несанкционированный физический доступ к компонентам ОО. | ||
| FPT_RCV | Надежное восстановление | Требуется наличие возможности корректного автоматического или ручного восстановления функций безопасности после сбоев. | ||
| FPT_RPL | Обнаружение повторного использования | Задаются требования по обнаружению повторного использования сущностей различных типов и последующими действиями по его устранению. | ||
| FPT_RVM | Посредничество при обращениях | Задаются требования по реализации концепции монитора безопасности обращений. | ||
| FPT_SEP | Разделение домена | Формулируются требования по организации защищённого домена для каждой функции безопасности. | ||
| FPT_SSP | Протокол синхронизации состояний | Требуется надёжное подтверждение при обмене данными между функциями безопасности в распределённой среде. | ||
| FPT_STM | Метки времени | Требуется предоставление надёжных меток времени в пределах ОО (что необходимо, например, для корректной работы механизмов протоколирования). | ||
| FPT_TDC | Согласованность данных ФБО между ФБО | Задаются требования по согласованности интерпретации данных, совместно используемых различными функциями безопасности и другими доверенными изделиями ИТ. | ||
| FPT_TRC | Согласованность данных ФБО при дублировании в пределах ОО | Определяются требования по синхронизации данных, дублируемых в пределах ОО. | ||
| FPT_TST | Самотестирование ФБО | Задаются требования по самотестированию функций безопасности в части типичных операций с известным результатом. | ||
| Класс FRU – использование ресурсов | ||||
| FRU_FLT | Отказоустойчивость | Требуется корректное выполнение части функциональных возможностей в случае сбоев. | ||
| FRU_PRS | Приоритет обслуживания | Определяется порядок применения высокоприоритетных операций. | ||
| FRU_RSA | Распределение ресурсов | Задаются требования к механизму квотирования, используемому для достижения высокой доступности ресурсов. | ||
| Класс FTA – доступ к ОО | ||||
| FTA_LSA | Ограничение области выбираемых атрибутов | Определяются ограничения на атрибуты безопасности сеанса, которые может выбирать пользователь. | ||
| FTA_MCS | Ограничение на параллельные сеансы | Задаются требования по ограничению числа параллельных сеансов, предоставляемых одному и тому же пользователю. | ||
| FTA_SSL | Блокирование сеанса | Определяется возможность блокирования и разблокирования интерактивного сеанса работы пользователя (по желанию пользователя или по инициативе функций безопасности). | ||
| FTA_TAB | Предупреждения перед предоставлением доступа к ОО | Определяются требования к отображению для пользователей предупреждающего сообщения относительно характера использования ОО. | ||
| FTA_TAH | История доступа к ОО | Задаются требования по отображению для пользователя при успешном открытии сеанса истории успешных и неуспешных попыток получить доступ от имени этого пользователя. | ||
| FTA_TSE | Открытие сеанса с ОО | Задаются параметры функций безопасности, на основании которых пользователю может быть отказано в доступе. | ||
| Класс FTP – доверенный маршрут/канал | ||||
| FTP_ITC | Доверенный канал передачи между ФБО | − Определяются правила организации доверенного канала между функциями безопасности и другими доверенными продуктами ИТ. − Определяется порядок идентификации взаимодействующих сторон. | ||
| FTP_TRP | Доверенный маршрут | Определяется порядок организации канала защищённого взаимодействия между пользователями и функциями безопасности. | ||
|
|
|
|
|
|
Наличие каталога функциональных требований не предполагает их окончательный и всеобъемлющий характер. В случае необходимости, функциональные требования безопасности, которые отсутствуют в каталоге, могут быть сформулированы в явном виде.
Требования доверия
Требования доверия, приведённые в третьей части ОК, сгруппированы в 10 классов, 44 семейства и 93 компонента.
Доверие – основа для уверенности в том, что продукт или система ИТ отвечают целям безопасности. Доверие могло бы быть получено путем обращения к таким источникам, как бездоказательное утверждение, предшествующий аналогичный опыт или специфический опыт. Однако ОК обеспечивают доверие с использованием активного исследования. Активное исследование – это оценка продукта или системы ИТ для определения его свойств безопасности.
Рис. 3.4.6.1. Структура класса доверия
Методы оценки могут включать:
· анализ и проверку процессов и процедур;
· проверку, что процессы и процедуры действительно применяются;
· анализ соответствия между представлениями проекта ОО;
· анализ соответствия каждого представления проекта ОО требованиям;
· верификацию доказательств;
· анализ руководств;
· анализ разработанных функциональных тестов и полученных результатов;
· независимое функциональное тестирование;
· анализ уязвимостей, включающий предположения о недостатках;
· тестирование проникновением.
Наиболее общую совокупность требований доверия называют классом. Каждый класс содержит семейства доверия, которые разделены на компоненты доверия, содержащие, в свою очередь, элементы доверия.
Структура класса доверия приведена на рис. 3.4.6.1.
Каждому классу доверия присвоено уникальное имя. Имя указывает на тематические разделы, на которые распространяется данный класс доверия. Принятое условное обозначение включает в себя букву «A», за которой следуют еще две буквы латинского алфавита, относящиеся к имени класса.
Каждый класс доверия имеет вводный подраздел – представление класса, в котором описаны состав и назначение класса.
Каждый класс доверия содержит по меньшей мере одно семейство доверия (см. рис. 3.4.6.1).
Каждому семейству доверия присвоено уникальное имя. Имя содержит описательную информацию по тематическим разделам, на которые распространяется данное семейство доверия. Каждое семейство доверия размещено в пределах класса доверия, который содержит другие семейства той же направленности.
Представлена также уникальная краткая форма имени семейства доверия. Она является основным средством для ссылки на семейство доверия. Принятое условное обозначение включает в себя краткую форму имени класса и символ подчеркивания, за которым следуют три буквы латинского алфавита, относящиеся к имени семейства.
Структура компонента доверия приведена на рис. 3.4.6.2.
Рис. 3.4.6.2. Структура компонента доверия
Подраздел «Идентификация компонента» содержит описательную информацию, необходимую для идентификации, категорирования, регистрации и ссылок на компонент.
Каждому компоненту доверия присвоено уникальное имя. Имя содержит информацию о тематических разделах, на которые распространяется компонент доверия. Каждый компонент входит в состав конкретного семейства доверия, с которым имеет общую цель безопасности.
Представлена также уникальная краткая форма имени компонента доверия как основной способ ссылки на компонент. Принято, что за краткой формой имени семейства следует точка, а затем цифра. Цифры для компонентов внутри каждого семейства назначены последовательно, начиная с единицы.
Необязательный подраздел «Цели» компонента доверия содержит конкретные цели этого компонента. Для компонентов доверия, которые имеют этот подраздел, он включает в себя конкретное назначение данного компонента и подробное разъяснение целей.
Необязательный подраздел «Замечания по применению» компонента доверия содержит дополнительную информацию для облегчения использования компонента.
Зависимости среди компонентов доверия возникают, когда компонент не самодостаточен, а предполагает присутствие другого компонента. Для каждого компонента доверия приведен полный список зависимостей от других компонентов доверия. При отсутствии у компонента идентифицированных зависимостей вместо списка указано: "Нет зависимостей". Компоненты из списка могут, в свою очередь, иметь зависимости от других компонентов.
Список зависимостей определяет минимальный набор компонентов доверия, на которые следует полагаться. Компоненты, которые являются иерархически более высокими по отношению к компоненту в списке зависимостей, также могут использоваться для удовлетворения зависимости.
В отдельных ситуациях обозначенные зависимости могут быть неприменимы. Разработчик ПЗ или ЗБ может отказаться от удовлетворения зависимости, представив обоснование, почему данная зависимость неприменима.
Каждый компонент доверия содержит набор элементов доверия. Элемент доверия – это требование безопасности, при дальнейшем разделении которого не изменяется значимый результат оценки. Он является наименьшим требованием безопасности, распознаваемым в ОК.
Каждый элемент доверия принадлежит к одному из трех типов.
· Элементы действий разработчика определяют действия, которые должны выполняться разработчиком. Этот набор действий далее уточняется доказательным материалом, упоминаемым в следующем наборе элементов. Требования к действиям разработчика обозначены буквой "D" после номера элемента.
· Элементы содержания и представления свидетельств определяют требуемое свидетельство; что свидетельство должно демонстрировать; какую информацию свидетельство должно отражать. Требования к содержанию и представлению свидетельств обозначены буквой "C" после номера элемента.
· Элементы действий оценщика определяют действия, которые должны выполняться оценщиком. Этот набор действий непосредственно включает подтверждение того, что требования, предписанные элементами содержания и представления свидетельств, выполнены, а также конкретные действия и анализ, выполняемые в дополнение к уже проведенным разработчиком. Должны также выполняться не указанные явно действия оценщика, необходимые вследствие элементов действий разработчика, но не охваченные в требованиях к содержанию и представлению свидетельств. Требования к действиям оценщика обозначены буквой "E" после номера элемента.
К элементам доверия не применяются операции назначения и выбора, однако, при необходимости, допускается уточнение элементов этой части стандарта.
Все семейства доверия в части 3 ОК являются линейно иерархическими, хотя линейность не обязательна для семейств доверия, которые могут быть добавлены в дальнейшем.
В таблице 3.4.6.1. приведена краткая характеристика всех 44 семейств доверия.
Таблица 3.4.6.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 | Анализ уязвимостей | Определяется порядок анализа недостатков, которые могли быть внесены на различных этапах разработки. | |||
| Класс AMA – поддержка доверия | |||||
| AMA_AMP | План поддержки доверия | Идентифицируются планы и процедуры, которые выполняются разработчиком для обеспечения поддержки доверия, установленного к оцененному ОО, после изменений в ОО или его среде. | |||
| AMA_CAT | Отчет о категорировании компонентов ОО | Определяется порядок категорирования компонентов ОО (например, подсистем ФБО) по их отношению к безопасности. | |||
| AMA_EVD | Свидетельство поддержки доверия | Определяется порядок поддержки разработчиком доверия к ОО в соответствии с планом поддержки доверия. | |||
| AMA_SIA | Анализ влияния на безопасность | Задаётся порядок проводимого разработчиком анализа влияния на безопасность всех изменений, воздействующих на ОО после его оценки. | |||
| Класс 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
Воспользуйтесь поиском по сайту:  ©2015 - 2024 megalektsii.ru Все авторские права принадлежат авторам лекционных материалов. Обратная связь с нами...
|