Главная | Обратная связь | Поможем написать вашу работу!
МегаЛекции

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




 

Систематизированный каталог функциональных требований безопасности сосредоточен во второй части ОК. Функциональные требования разбиты на 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 Все авторские права принадлежат авторам лекционных материалов. Обратная связь с нами...