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

C.1 Введение

В.12 Ссылка в ПЗ на другие стандарты

Этот раздел идентичен разделу А.13, посвященному ссылке на стандарты в ЗБ, за одним исключением: так как в ПЗ не содержится краткая спецификация ОО, то пункт с) раздела А.13 не применим по отношению к ПЗ.

Разработчику ПЗ необходимо учитывать, что ссылка в ФТБ на какой-либо стандарт может существенно добавить нагрузку на разработчика ОО, чтобы удовлетворить ПЗ (в зависимости от объема и сложности стандарта и требуемого уровня доверия); при этом может быть более приемлемым требовать использования альтернативных (не относящихся к ОК) способов оценки соответствия стандарту, на который имеется ссылка в ПЗ.

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

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

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

C.2.1 Операция ”итерация”

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

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

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

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

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

C.2.2 Операция ”назначение”

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

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

C.2.3 Операция ”выбор”

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

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

C.2.4 Операция ”уточнение”

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

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

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

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

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

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

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

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

Дата добавления: 2014-01-15