17. Структура функционального класса, функционального семейства, функционального компонента.

 

Структура функционального класса

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

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

Структура функционального семейства

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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