ГОСТ Р ИСО/МЭК 15408-2—2002
мня, за исключением случая, когда событие более высокого уровня имеет более высокий уровень
детализации, чем событие более низкого уровня, и может просто заменить его. Когда желательна
детализированная генерацияданных аудита, все идентифицированные события, потенциально под
вергаемые аудиту (для минимального, базового и детализированного уровней), следует включить в
ГТЗ/ЗБ.
Правила управления аудитом более подробно объяснены в классе FAU.
2.1.3 С т р у к т у р а к о м п о н е н т а
Структура функционального компонента показана на рисунке 2.3.
2.1.3.1 Идентификация компонента
Идентификация компонента включает в себя описательную информацию, необходимую для
идентификации, категорирования, записи и реализации перекрестных ссылок компонента. Для каждо го
функционального компонента представляется следующее:
—уникальное ими. отражающее предназначение компонента:
—краткое имя, применяемое как основное имя ссылки для категорирования, записи и реализа
ции перекрестных ссылок компонента и уникально отражающее класс и семейство, которым компо
нент принадлежит, а также номер компонента в семействе:
—список иерархических связей, содержащий имена других компонентов, для которых этот компо
нент иерархичен и вместо которых может использоваться при удовлетворении зависимостей от пере
численных компонентов.
2.1.3.2 Функциональные элементы
Кажлый компонент включает всебя набор элементов. Кажлый элемент определяется отдельно и
является самодостаточным.
Функциональный элемент —это функциональное требование безопасности,дальнейшее разделе
ние которого не меняет значимо результат оценки. Является наименьшим функциональным требова
нием безопасности, идентифицируемым и признаваемым в ГОСТ I*ИСО/М’ЭК 15408.
При формировании ПЗ, ЗБ и/или пакетов не разрешается выбирать только часть элементов
компонента. Для включения в 113. ЗБ или пакет необходимо выбирать всю совокупность элементов
компонента.
Вводится уникальная краткая форма имени функционального элемента. Например, имя
FDIMFF.4.2 читается следующимобразом: F — функциональное требование, DP — класс
«Зашита данных пользователя*, _IFF —семейство «Функции управленияинформационными
потоками», .4 — четвертый компонент «Частичное устранение неразрешенных информационных пото
ков*, .2 —второй элемент компонента.
2.1.3.3 Зависимости
Зависимости среди функциональных компонентов возникают, когда компонент не самодостато
чен и нуждается либо вфункциональных возможностях другого компонента, либо во взаимодействии
с ним для поддержки собственного выполнения.
Каждый функциональный компонент содержит полный список зависимостей отдругих функци
ональных компонентов и компонентовдоверия. Для некоторых компонентов указано, что зависимости
отсутствуют. Компоненты изсписка могут, всвою очередь, иметь зависимости от других компонентов.
Список, приведенный в компоненте, показывает прямые зависимости, т. е. содержит ссылки только на
функциональные компоненты, заведомо необходимые для обеспечения выполнения рассматриваемого
компонента. Косвенные зависимости, определяемые собственными зависимостями компонентов из
списка, показаны в приложении Л. В некоторых случаях зависимость выбирают из нескольких предла
гаемыхфункциональных компонентов, причем каждый из них достаточен для удовлетворения зависи
мости (см., например. FDP_U1T.I).
Список зависимостей идентифицирует минимум функциональных компонентов или компонен
тов доверия, необходимых для удовлетворения требований безопасности, ассоциированных с данным
компонентом. Компоненты, которые иерархиями по отношению к компоненту из списка, также могут
быть использованы для удовлетворения зависимости.
Зависимости между компонентами, указанные в настоящем стандарте, обязательны. Их необхо
димо удоалетворить в 113/ЗБ. В некоторых, особыхслучаях эти зависимости удоалетворить невозможно.
Разработчик 113/ЗБ, обязательно обоснован, почемуданная зависимостьнеприменима, можетне включать
соответствующий компонент в пакет. ПЗ или ЗБ.
9