1. Функциональные компоненты безопасности

1. Структура класса

Каждый функциональный класс содержит имя класса, представление класса и одно или несколько функциональных семейств.

Имя класса

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

Представление класса

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

2. Структура семейства

Имя семейства

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

Характеристика семейства

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

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

б) описание функциональных требований обобщает все требования, которые включены в компонент (компоненты). Описание ориентировано на разработчиков ПЗ, ЗБ и функциональных пакетов, которые хотели бы определить, соответствует ли семейство их конкретным требованиям.

Ранжирование компонентов

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

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

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

Управление

Требования управления содержат информацию для разработчиков ПЗ/ЗБ, учитываемую при определении действий по управлению для данного компонента. Требования управления детализированы в компонентах класса "Управление безопасностью" (FMT).

Разработчик ПЗ/ЗБ может выбрать какие-либо из имеющихся требований управления или включить новые, не указанные в настоящем стандарте. В последнем случае следует представить необходимую информацию.

Аудит

Требования аудита содержат события, потенциально подвергаемые аудиту, для их отбора разработчиками ПЗ/ЗБ при условии включения требований из класса FAU "Аудит безопасности" в ПЗ/ЗБ. Эти требования включают относящиеся к безопасности события применительно к различным уровням детализации, поддерживаемым компонентами семейства FAU_GEN "Генерация данных аудита безопасности". Например, запись аудита какого-либо механизма безопасности может включать на разных уровнях детализации действия, которые раскрываются в следующих терминах.

- "Минимальный": успешное использование механизма безопасности.

- "Базовый": любое использование механизма безопасности, а также информация о текущих значениях атрибутов безопасности.

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

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

Правила управления аудитом более подробно объяснены в классе FAU.