Information technology. Security techniques. Evaluation criteria for it security Security functional requirements

Вид материала

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

Подобный материал:

1 2 3 4 5 6 7 8 9 ... 78

2.1.2.4 Управление

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

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

2.1.2.5 Аудит

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

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

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

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

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

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

┌─────────────────────────────┐

│ Компонент ├──┐

└─────────────────────────────┘ │

│ ┌─────────────────────────────┐

├─┤ Идентификация компонента │

│ └─────────────────────────────┘

│ ┌─────────────────────────────┐

│ ┌┴────────────────────────────┐│

│ ┌┴────────────────────────────┐├┘

├─┤ Функциональные элементы ├┘

│ └─────────────────────────────┘

│ ┌─────────────────────────────┐

└─┤ Зависимости │

└─────────────────────────────┘

Рисунок 2.3 - Структура функционального компонента

2.1.3 Структура компонента

Структура функционального компонента показана на рисунке 2.3.

2.1.3.1 Идентификация компонента

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

- уникальное имя, отражающее предназначение компонента;

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

- список иерархических связей, содержащий имена других компонентов, для которых этот компонент иерархичен и вместо которых может использоваться при удовлетворении зависимостей от перечисленных компонентов.

2.1.3.2 Функциональные элементы

Каждый компонент включает в себя набор элементов. Каждый элемент определяется отдельно и является самодостаточным.

Функциональный элемент - это функциональное требование безопасности, дальнейшее разделение которого не меняет значимо результат оценки. Является наименьшим функциональным требованием безопасности, идентифицируемым и признаваемым в ГОСТ Р ИСО/МЭК 15408.

При формировании ПЗ, ЗБ и/или пакетов не разрешается выбирать только часть элементов компонента. Для включения в ПЗ, ЗБ или пакет необходимо выбирать всю совокупность элементов компонента.

Вводится уникальная краткая форма имени функционального элемента. Например, имя FDP_IFF.4.2 читается следующим образом: F - функциональное требование, DP - класс "Защита данных пользователя", _IFF - семейство "Функции управления информационными потоками", .4 - четвертый компонент "Частичное устранение неразрешенных информационных потоков", .2 - второй элемент компонента.

2.1.3.3 Зависимости

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

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

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

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