Приложение С (справочное). Руководство по выполнению операций

Приложение С
(справочное)

Руководство
по выполнению операций

С.1 Введение

Профили защиты и задания по безопасности содержат предопределенные требования безопасности: разработчикам ПЗ и ЗБ при некоторых обстоятельствах также предоставляется возможность расширить список компонентов требований безопасности.

С.2 Примеры операций

В 7.1 приведены четыре типа операций. Примеры выполнения различных операций рассмотрены ниже.

С.2.1 Операция "итерация"

Как описано в 7.1.1, операция "итерация" может быть выполнена по отношению к любому компоненту. Разработчик ПЗ/ЗБ выполняет операцию "итерация" путем включения нескольких требований, основанных на одном и том же компоненте. Каждая итерация компонента должна отличаться от всех других итераций этого компонента, что реализуется завершением по-другому операций "назначение" и "выбор" или применением по-другому операции "уточнение".

Различные итерации следует уникально идентифицировать, чтобы обеспечить четкое обоснование и прослеживаемость от или к этим требованиям.

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

- Криптографическая операция (FCS_COP.1(1));

- Криптографическая операция (FCS_COP.1(2)).

С.2.2 Операция "назначение"

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

Пример элемента требований с операцией "назначение": FIA_AFL1.2 "При достижении или превышении определенного числа неуспешных попыток аутентификации ФБО должны выполнить [назначение: список действий]".

С.2.3 Операция "выбор"

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

Пример элемента требований с операцией "выбор": FPT_TST.1.1 "ФБО должны выполнять пакет программ самотестирования [выбор: при запуске, периодически в процессе нормального функционирования, по запросу уполномоченного пользователя, при условиях [назначение: условия, при которых следует предусмотреть самотестирование]] для демонстрации правильного выполнения ..."

С.2.4 Операция "уточнение"

Как описано в 7.1.4, операция "уточнение" может быть выполнена по отношению к любому требованию. Разработчик ПЗ/ЗБ выполняет уточнение путем изменения требования.

Пример допустимого выполнения операции "уточнение": FIA_UAU.2.1 "ФБО должны требовать, чтобы каждый пользователь был успешно аутентифицирован до разрешения любого действия, выполняемого при посредничестве ФБО от имени этого пользователя" уточнен следующим образом - "ФБО должны требовать, чтобы каждый пользователь был успешно аутентифицирован на основе имени пользователя и пароля до разрешения любого действия, выполняемого при посредничестве ФБО от имени этого пользователя".

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

Единственное исключение из этого правила состоит в том, что допускается, чтобы разработчик ПЗ/ЗБ уточнил ФТБ для его применения по отношению к некоторым, но не ко всем субъектам, объектам, операциям, атрибутам безопасности и/или внешним сущностям.

Пример подобного исключения: FIA_UAU.2.1 "ФБО должны требовать, чтобы каждый пользователь был успешно аутентифицирован до разрешения любого действия, выполняемого при посредничестве ФБО от имени этого пользователя" уточнен следующим образом "ФБО должны требовать, чтобы каждый пользователь из Интернета был успешно аутентифицирован до разрешения любого действия, выполняемого при посредничестве ФБО от имени этого пользователя".

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

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

ФТБ, основанное на компоненте FPT_FLS.1, "ФБО должны сохранить безопасное состояние при следующих типах сбоев: выход из строя одного процессора" могло бы быть уточнено следующим образом - FPT_FLS.1 "ФБО должны сохранить безопасное состояние при следующих типах сбоев: выход одного процессора из строя" или даже - FPT_FLS.1 "ФБО должны сохранить безопасное состояние при следующих типах сбоев: один процессор вышел из строя".

С.3 Организация компонентов

Компоненты в ИСО/МЭК 15408-2 и ИСО/МЭК 15408-3 организованы в иерархические структуры:

классы, состоящие из

семейств, включающих

компоненты, состоящие из

элементов.

Данная организация иерархии "класс - семейство - компонент - элемент" помогает потребителям, разработчикам и оценщикам в поиске конкретных компонентов.

В ИСО/МЭК 15408 функциональные компоненты и компоненты доверия представлены в едином иерархическом стиле, по отношению к ним использована единая организация и терминология.

С.3.1 Класс

Примером класса является класс FIA, который направлен на идентификацию пользователей, аутентификацию пользователей и связывание пользователей и субъектов.

С.3.2 Семейство

Примером семейства является семейство "Аутентификация пользователя" (FIA_UAU), которое является частью класса FIA. Это семейство связано с аутентификацией пользователей.

С.3.3 Компонент

Примером компонента является компонент FIA_UAU.3 "Аутентификация, защищенная от подделок", который связан с аутентификацией, защищенной от подделок.

С.3.4 Элемент

Примером элемента является элемент FIA_UAU.3.2, который связан с предотвращением использования скопированных аутентификационных данных.

С.4 Расширенные компоненты

С.4.1 Определение расширенных компонентов

Всякий раз, когда разработчик ПЗ/ЗБ определяет расширенный компонент, это должно быть сделано способом, подобным существующим компонентам ИСО/МЭК 15408: четким, однозначным и оцениваемым (имеется возможность методично продемонстрировать выполнение требования, основанного на этом компоненте, для ОО). Расширенные компоненты должны использовать обозначение, способ выражения и уровень детализации, подобные существующим компонентам ИСО/МЭК 15408.

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

a) если расширенный компонент относится к аудиту, то, вероятно, придется включить зависимости от компонентов класса FAU;

b) если расширенный компонент связан с модификацией или доступом к данным, то, вероятно, придется включить зависимости от компонентов семейства FDP_ACC;

c) если расширенный компонент использует конкретное описание проекта, то, вероятно, придется включить зависимость от компонентов соответствующего семейства (например, "Функциональная спецификация") класса ADV.

В случае расширенного функционального компонента разработчик ПЗ/ЗБ также должен включить в определение компонента применимую информацию, связанную с аудитом и действиями по управлению, подобно тому, как это сделано для существующих компонентов ИСО/МЭК 15408-2. В случае расширенного компонента доверия разработчик ПЗ/ЗБ также должен предоставить соответствующую методологию оценки для данного компонента, подобную методологии, изложенной в ИСО/МЭК 18045.

Расширенные компоненты могут быть помещены в существующие семейства, в этом случае разработчик ПЗ/ЗБ должен показать, каким образом изменяются данные семейства. Если для новых компонентов не подходят существующие семейства, то они должны быть помещены в новое семейство. Новые семейства должны быть определены также, как определены семейства в ИСО/МЭК 15408.

Новые семейства могут быть помещены в существующие классы, в этом случае разработчик ПЗ/ЗБ должен показать, каким образом изменяются данные классы. Если для новых семейств не подходят существующие классы, то они должны быть помещены в новый класс. Новые классы должны быть определены также, как определены классы в ИСО/МЭК 15408.