Законодательная база Российской Федерации

"ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ. КРИТЕРИИ ОЦЕНКИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ. ЧАСТЬ 2. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ БЕЗОПАСНОСТИ. ГОСТ Р ИСО/МЭК 15408-2-2008" (утв. Приказом Ростехрегулирования от 18.12.2008 N 520-ст)

6.1. Краткий обзор

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

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

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

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

6.1.1.1. Имя класса

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Описания семейств содержат графическое представление иерархии компонентов, рассмотренное в 6.2.

6.1.2.4. Управление

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

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

6.1.2.5. Аудит

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

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

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

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

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

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

6.1.3. Структура компонента

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

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

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

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

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

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

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

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

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

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

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

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

6.1.3.3. Зависимости

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

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

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

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

6.2. Каталог компонентов

Расположение компонентов в настоящем стандарте не отражает какую-либо формальную таксономию.

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

В описании каждого функционального компонента приведены его зависимости от других компонентов.

Пример представления таксономии класса и иерархии компонентов в его семействах приведен на рисунке 8.

Рисунок 8. Пример декомпозиции класса

В примере первое семейство содержит три иерархических компонента, где компоненты 2 и 3 могут быть применены для выполнения зависимостей вместо компонента 1. Компонент 3 иерархичен компоненту 2 и может применяться для выполнения зависимостей вместо компонента 2.

В семействе 2 имеются три компонента, не все из них иерархически связаны. Компоненты 1 и 2 не иерархичны другим компонентам. Компонент 3 иерархичен компоненту 2 и может применяться для удовлетворения зависимостей вместо компонента 2, но не вместо компонента 1.

В семействе 3 компоненты 2, 3 и 4 иерархичны компоненту 1. Компоненты 2 и 3 иерархичны компоненту 1, но несопоставимы по иерархии между собой. Компонент 4 иерархичен компонентам 2 и 3.

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

6.2.1. Выделение изменений в компоненте

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