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

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

Приложение A
(обязательное)

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

A.1. Структура замечаний

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

A.1.1. Структура класса

Структура функционального класса в Приложениях C - M приведена на рисунке A.1.

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

A.1.1.1. Имя класса

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

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

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

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

Структура функционального семейства в замечаниях по применению приведена на рисунке A.2.

Рисунок A.2. Структура функционального семейства в замечаниях по применению

A.1.2.1. Имя семейства

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

A.1.2.2. Замечания для пользователя

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

A.1.2.3. Замечания для оценщика

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

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

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

Структура функциональных компонентов в замечаниях по применению показана на рисунке A.3.

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

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

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

A.1.3.2. Обоснование компонента и замечания по применению

В данном подпункте может содержаться любая относящаяся к компоненту "информация".

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

Замечания по применению содержат дополнительное уточнение в виде описания, относящегося к определенному компоненту. Уточнение может касаться замечаний для пользователя и/или оценщика, как указано в A.1.2. Данное уточнение может использоваться при объяснении природы зависимостей (например, совместно применяемая информация или действие).

Данный подпункт не является обязательным и приводится только при необходимости.

A.1.3.3. Разрешенные операции

В данном подпункте для каждого компонента содержатся рекомендации по выполнению разрешенных в данном компоненте операций.

Этот подпункт не является обязательным и приводится только при необходимости.

A.2. Таблицы зависимостей

В следующих таблицах зависимостей для функциональных компонентов представлены прямые, косвенные и выбираемые зависимости функциональных компонентов. Для каждого компонента, от которого зависят какие-либо функциональные компоненты, отведен столбец таблицы. Для каждого функционального компонента отведена строка таблицы. Знаки на пересечении строк и столбцов таблицы указывают характер зависимости соответствующих компонентов: "X" - прямая зависимость; "-" - косвенная, а "O" - выбираемая.

Выбираемую зависимость рассмотрим на примере компонента FDP_ETC.1 "Экспорт данных пользователя без атрибутов безопасности", требующего присутствия компонента FDP_ACC.1 "Ограниченное управление доступом" либо компонента FDP_IFC.1 "Ограниченное управление информационными потоками". Так, если выбран компонент FDP_ACC.1 "Ограниченное управление доступом", то присутствие FDP_IFC.1 "Ограниченное управление информационными потоками" необязательно и наоборот. Если пересечение строки и столбца таблицы пусто, компонент из строки не зависит от компонента из столбца.

Таблица A.1

ТАБЛИЦА ЗАВИСИМОСТЕЙ ДЛЯ КЛАССА FAU "АУДИТ БЕЗОПАСНОСТИ"

Таблица A.2

ТАБЛИЦА ЗАВИСИМОСТЕЙ ДЛЯ КЛАССА FCO "СВЯЗЬ"

Таблица A.3

ТАБЛИЦА ЗАВИСИМОСТЕЙ ДЛЯ КЛАССА FCS "КРИПТОГРАФИЧЕСКАЯ ПОДДЕРЖКА"

Таблица A.4

ТАБЛИЦА ЗАВИСИМОСТЕЙ ДЛЯ КЛАССА FDP "ЗАЩИТА ДАННЫХ ПОЛЬЗОВАТЕЛЯ"

Таблица A.5

ТАБЛИЦА ЗАВИСИМОСТЕЙ ДЛЯ КЛАССА FIA "ИДЕНТИФИКАЦИЯ И АУТЕНТИФИКАЦИЯ"

Таблица A.6

ТАБЛИЦА ЗАВИСИМОСТЕЙ ДЛЯ КЛАССА FMT "УПРАВЛЕНИЕ БЕЗОПАСНОСТЬЮ"

Таблица A.7

ТАБЛИЦА ЗАВИСИМОСТЕЙ ДЛЯ КЛАССА FPR "ПРИВАТНОСТЬ"

Таблица A.8

ТАБЛИЦА ЗАВИСИМОСТЕЙ ДЛЯ КЛАССА FPT "ЗАЩИТА ФБО"

Таблица A.9

ТАБЛИЦА ЗАВИСИМОСТЕЙ ДЛЯ КЛАССА FRU "ИСПОЛЬЗОВАНИЕ РЕСУРСОВ"

Таблица A.10

ТАБЛИЦА ЗАВИСИМОСТЕЙ ДЛЯ КЛАССА FTA "ДОСТУП К ОО"

Приложение B
(обязательное)

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

Приложение C
(обязательное)

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

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

C.1. Требования аудита в распределенной среде

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

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

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

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

Декомпозиция класса FAU "Аудит безопасности" на составляющие его компоненты показана на рисунке C.1.

Рисунок C.1. Декомпозиция класса FAU "Аудит безопасности"

C.2. Автоматическая реакция аудита безопасности (FAU_ARP)

C.2.1. Замечания по применению

Семейство FAU_ARP "Автоматическая реакция аудита безопасности" содержит требования по обработке событий аудита. Конкретное требование может включать в себя требования сигнала тревоги или действий ФБО (автоматическая реакция). Например, ФБО могут обеспечивать подачу сигнала тревоги в реальном времени, прерывание процесса с выявленным нарушением, прекращение обслуживания, блокирование или закрытие учетных данных пользователя.

Событие аудита определяется как "возможное нарушение безопасности", если так указано в компонентах семейства FAU_SAA "Анализ аудита безопасности".

C.2.2. FAU_ARP.1 Сигналы нарушения безопасности

C.2.2.1. Замечания по применению для пользователя

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

C.2.2.2. Операции

C.2.2.2.1. Назначение

В элементе FAU_ARP.1.1 автору ПЗ/ЗБ следует определить действия, предпринимаемые в случае возможного нарушения безопасности. Примером списка таких действий является: "информировать уполномоченного пользователя, блокировать субъекта, действия которого могут привести к нарушению безопасности". Можно также указать, что предпринимаемые действия могут определяться уполномоченным пользователем.

C.3. Генерация данных аудита безопасности (FAU_GEN)

C.3.1. Замечания по применению

Семейство FAU_GEN "Генерация данных аудита безопасности" содержит требования по спецификации событий аудита, которые следует генерировать с использованием ФБО для событий, относящихся к безопасности.

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

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

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

a) минимальный: успешное использование функций административного управления атрибутами безопасности пользователя;

b) базовый: все попытки использования функций административного управления атрибутами безопасности пользователя;

c) базовый: идентификация модифицированных атрибутов безопасности пользователя;

d) детализированный: новые значения атрибутов, за исключением чувствительных атрибутов (например, паролей, ключей шифрования)".

Для каждого выбранного функционального компонента в общую совокупность событий, потенциально подвергаемых аудиту, следует включить те указанные в нем события, которые соответствуют уровню, установленному в FAU_GEN "Генерация данных аудита безопасности". Если в приведенном выше примере в FAU_GEN "Генерация данных аудита безопасности" выбран уровень "базовый", события, указанные в перечислениях "a" - "c", следует отнести к потенциально подвергаемым аудиту.

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

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

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

Ниже приведены примеры типов событий, которые следует определить как потенциально подвергаемые аудиту в каждом функциональном компоненте ПЗ/ЗБ:

a) введение объектов из ОДФ в адресное пространство субъекта;

b) удаление объектов;

c) предоставление или отмена прав или возможностей доступа;

d) изменение атрибутов безопасности субъекта или объекта;

e) проверки политики, выполняемые ФБО как результат запроса субъекта;

f) использование прав доступа для обхода проверок политики;

g) использование функций идентификации и аутентификации;

h) действия, предпринимаемые оператором и/или уполномоченным пользователем (например, подавление такого механизма защиты ФБО, как доступные человеку метки);

i) ввод/вывод данных с/на заменяемые носители (например, печатные материалы, ленты, дискеты).

C.3.2. FAU_GEN.1. Генерация данных аудита

C.3.2.1. Замечания по применению для пользователя

Компонент FAU_GEN.1 "Генерация данных аудита" определяет требования по идентификации событий, потенциально подвергаемых аудиту, для которых следует генерировать записи аудита, и состав информации в этих записях.

Если ПБО не предусматривает ассоциации событий аудита с идентификатором пользователя, то достаточно применения только компонента FAU_GEN.1 "Генерация данных аудита". То же приемлемо и в случае, когда ПЗ/ЗБ содержит требования приватности. Если необходимо подключение идентификатора пользователя, допускается дополнительно использовать компонент FAU_GEN.2 "Ассоциация идентификатора пользователя".

C.3.2.2. Замечания по применению для оценщика

Имеется зависимость от FPT_STM "Метки времени". Если точное значение времени событий для данного ОО несущественно, то допускается логически обоснованный отказ от этой зависимости.

C.3.2.3. Операции

C.3.2.3.1. Выбор

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

C.3.2.3.2. Назначение

В FAU_GEN.1.1 автору ПЗ/ЗБ следует составить список и других событий, потенциально подвергаемых аудиту, для включения в список событий, потенциально подвергаемых аудиту. Назначение в перечислении "c" может не включать в себя ни одного события ("нет") или включать события из функциональных требований, потенциально подвергаемые аудиту более высокого уровня, чем требуется в перечислении "b", а также события, генерируемые при использовании специфицированного интерфейса прикладного программирования (API).

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

C.3.3. FAU_GEN.2 Ассоциация идентификатора пользователя

C.3.3.1. Замечания по применению для пользователя

Компонент FAU_GEN.2 связан с требованием использования идентификаторов пользователей при учете событий, потенциально подвергаемых аудиту. Этот компонент следует использовать в дополнение к FAU_GEN.1 "Генерация данных аудита".

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

C.4. Анализ аудита безопасности (FAU_SAA)

C.4.1. Замечания по применению

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

Действия для выполнения ФБО при обнаружении ожидаемого или потенциального нарушения определяются в компонентах семейства FAU_ARP "Автоматическая реакция аудита безопасности".

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

C.4.2. FAU_SAA.1 Анализ потенциального нарушения

C.4.2.1. Замечания по применению для пользователя

Компонент FAU_SAA.1 используется для определения совокупности событий, потенциально подвергаемых аудиту, появление которых (каждого отдельно или в совокупности) указывает на потенциальные нарушения ПБО, и правил, применяемых для анализа этих нарушений.

C.4.2.2. Операции

C.4.2.2.1. Назначение

В FAU_SAA.1.2 автору ПЗ/ЗБ следует определить совокупность событий, потенциально подвергаемых аудиту, проявление которых (каждого в отдельности или совместно) будет указывать на возможные нарушения ПБО.

В FAU_SAA.1.2 автору ПЗ/ЗБ следует определить любые другие правила, которые ФБО следует использовать для анализа журнала аудита. Эти правила могут включать в себя конкретные требования, согласно которым необходимо, чтобы в течение указанного периода времени (например, установленного времени суток, заданного интервала времени) произошли определенные события. Если нет никаких дополнительных правил, которые должны использовать ФБО при анализе журнала аудита, то данное назначение может быть выполнено как "нет".

C.4.3. FAU_SAA.2 Выявление аномалии, основанное на профиле

C.4.3.1. Замечания по применению для пользователя

Профиль является структурой, характеризующей поведение пользователей и/или субъектов; он описывает различные способы взаимодействия пользователей/субъектов с ФБО. Шаблоны использования для пользователей/субъектов устанавливают по отношению к различным видам результатов их деятельности, включая, например, шаблоны возникновения исключительных ситуаций, шаблоны использования ресурсов (когда, каких, как), шаблоны выполняемых действий. Метрики профиля ссылаются на способы, которыми различные виды деятельности отражаются в профиле (например, измерение использованных ресурсов, счетчики событий, таймеры).

Каждый профиль представляет собой ожидаемые шаблоны использования, выполняемые членами группы, на которую он ориентирован (целевая группа профиля). Данный шаблон может основываться на предшествующем использовании (шаблон предыстории) или на обычном использовании пользователями подобных целевых групп (ожидаемое поведение). Целевая группа профиля включает в себя одного или нескольких пользователей, взаимодействующих с ФБО. Деятельность каждого члена группы данного профиля анализируется инструментальными средствами, чтобы сравнить ее с шаблоном, представленным в профиле. Примерами целевых групп профиля являются:

a) учетная запись отдельного пользователя - один профиль для каждого пользователя;

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

c) операционная роль - один профиль на всех пользователей, выполняющих данную операционную роль;

d) система в целом - один профиль на всех пользователей системы.

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

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

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

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

FAU_SAA.2 "Выявление аномалии, основанное на профиле" содержит требование, чтобы ФБО сопровождали профили использования системы. Под сопровождением понимается активное участие детектора отклонений в обновлении профиля использования системы в соответствии с новыми действиями, выполняемыми членами целевой группы этого профиля. Важно, чтобы автором ПЗ/ЗБ была определена метрика представления деятельности пользователя. Индивид может выполнять тысячи различных действий, но детектор отклонений способен отобрать для контроля только некоторые из них. Результаты аномальной деятельности интегрируются в профиль так же, как и результаты нормальной деятельности (при условии выполнения мониторинга этих действий). То, что считалось отклонением четыре месяца назад, сегодня может стать нормой (и наоборот) из-за изменения условий работы пользователей. ФБО не будут способны учесть изменение ситуации, если в алгоритмах обновления профиля не отражена какая-либо аномальная деятельность пользователей.

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

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

C.4.3.2. Операции

C.4.3.2.1. Выбор

В FAU_SAA.2.1 автору ПЗ/ЗБ следует определить целевую группу профиля. Один ПЗ/ЗБ может включать в себя несколько целевых групп профиля.

В FAU_SAA.2.3 автору ПЗ/ЗБ следует определить условия, при которых ФБО сообщают об аномальном поведении. Условия могут включать в себя достижение рейтингом подозрительной активности некоторого значения или основываться на определенном виде аномального поведения.

C.4.4. FAU_SAA.3 Простая эвристика атаки

C.4.4.1. Замечания по применению для пользователя

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

Сложность средств анализа в значительной степени будет зависеть от назначений, сделанных автором ПЗ/ЗБ при определении базового множества "характерных" событий.

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

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

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

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

C.4.4.2. Операции

C.4.4.2.1. Назначение

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

В FAU_SAA.3.2 автору ПЗ/ЗБ следует специфицировать информацию, используемую при определении показателей функционирования системы. Данная информация является исходной для инструментальных средств анализа показателей функционирования системы, применяемых в ОО. Эта информация может включать в себя данные аудита, комбинации данных аудита с другими системными данными и данные, отличные от данных аудита. При составлении ПЗ/ЗБ следует точно определить, какие системные события и атрибуты событий используются в качестве исходной информации.

C.4.5. FAU_SAA.4 Сложная эвристика атаки

C.4.5.1. Замечания по применению для пользователя

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

Сложность средств анализа в значительной степени будет зависеть от назначений, сделанных автором ПЗ/ЗБ при определении базового множества "характерных" событий и последовательностей событий.

Автору ПЗ/ЗБ следует определить базовое множество "характерных" событий и последовательностей событий, которые будут представлены в ФБО. Дополнительные "характерные" события и последовательности событий могут быть определены разработчиком системы.

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

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

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

Элементы FAU_SAA.4 "Сложная эвристика атаки" не требуют, чтобы реализация эвристик распознавания прямой атаки осуществлялась теми же ФБО, выполнение которых подлежит мониторингу. Поэтому компоненты, применяемые для обнаружения вторжения, можно разрабатывать независимо от системы, показатели функционирования которой подлежат анализу.

C.4.5.2. Операции

C.4.5.2.1. Назначение

В FAU_SAA.4.1 автору ПЗ/ЗБ следует идентифицировать базовое множество перечня последовательностей системных событий, совпадение которых типично для известных сценариев проникновения. Эти последовательности событий представляют известные сценарии проникновения. Каждое событие в последовательности следует сопоставлять с контролируемыми системными событиями, и если в итоге все системные события произошли в действительности, это подтверждает (отображает) попытку проникновения.

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

В FAU_SAA.4.2 автору ПЗ/ЗБ следует специфицировать информацию, используемую при определении показателей функционирования системы. Информация является исходной для инструментальных средств анализа показателей функционирования системы, применяемых в ОО. В эту информацию могут входить данные аудита, комбинации данных аудита с другими системными данными и данные, отличные от данных аудита. При составлении ПЗ/ЗБ следует точно определить, какие системные события и атрибуты событий используются в качестве исходной информации.

C.5. Просмотр аудита безопасности (FAU_SAR)

C.5.1. Замечания по применению

Семейство FAU_SAR определяет требования, относящиеся к просмотру информации аудита.

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

- действия одного или нескольких пользователей (например, идентификация, аутентификация, вход в ОО и действия по управлению доступом);

- действия, выполненные над определенным объектом или ресурсом ОО;

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

- действия, связанные с определенным атрибутом ПБО.

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

C.5.2. FAU_SAR.1 Просмотр аудита

C.5.2.1. Обоснование

Данный компонент обеспечит уполномоченным пользователям возможность получения и интерпретации информации. В случае пользователя-человека данная информация должна представляться в понятном для человека виде. В случае внешних сущностей ИТ информация должна быть однозначно представлена в электронном виде.

C.5.2.2. Замечания по применению для пользователя

Компонент FAU_SAR.1 используется для определения возможности читать записи аудита для пользователей и/или уполномоченных пользователей. Эти записи аудита будут представляться в удобном для пользователя виде. У пользователей различных типов могут быть разные требования к представлению данных аудита.

Содержание записей аудита, предназначенных для просмотра, может быть установлено заранее.

C.5.2.3. Операции

C.5.2.3.1. Назначение

В FAU_SAR.1.1 автору ПЗ/ЗБ следует указать уполномоченных пользователей, которые могут просматривать данные аудита. Если это необходимо, автор ПЗ/ЗБ может указать роли безопасности (см. FMT_SMR.1 "Роли безопасности").

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

C.5.3. FAU_SAR.2 Ограниченный просмотр аудита

C.5.3.1. Замечания по применению для пользователя

В компоненте FAU_SAR.2 определяется, что ни один пользователь, не указанный в FAU_SAR.1 "Просмотр аудита", не сможет читать записи аудита.

C.5.4. FAU_SAR.3 Выборочный просмотр аудита

C.5.4.1. Замечания по применению для пользователя

Компонент FAU_SAR.3 определяет возможность выборочного просмотра данных аудита. Если просмотр проводится на основе нескольких критериев, то необходимо, чтобы они были логически связаны (например, операциями "и", "или"), а инструментальные средства предоставили возможность обработки данных аудита (например, сортировки, фильтрации).

C.5.4.2. Операции

C.5.4.2.1. Выбор

В FAU_SAR.3.1 автору ПЗ/ЗБ следует выбрать, какие действия (поиск, сортировку и/или упорядочение) могут выполнять ФБО.

C.5.4.2.2. Назначение

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

C.6. Выбор событий аудита безопасности (FAU_SEL)

C.6.1. Замечания по применению

Семейство FAU_SEL "Выбор событий аудита безопасности" содержит требования, связанные с идентификацией того, какие события, потенциально подвергаемые аудиту, действительно подлежат аудиту. События, потенциально подвергаемые аудиту, определяются в семействе FAU_GEN "Генерация данных аудита безопасности", но для выполнения аудита этих событий их следует определить как выбираемые в компоненте FAU_SEL.1.

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

C.6.2. FAU_SEL.1 Избирательный аудит

C.6.2.1. Замечания по применению для пользователя

Компонент FAU_SEL.1 определяет критерии, используемые для отбора событий, которые будут подвергнуты аудиту. Критерии могут допускать включение или исключение событий из совокупности событий, подвергающихся аудиту, на основе атрибутов пользователей, субъектов и объектов или типов событий.

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

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

Права уполномоченных пользователей по просмотру или модификации условий отбора будут регулироваться функциями управления компонента FMT_Mtd.1 "Управление данными ФБО".

C.6.2.2. Операции

C.6.2.2.1. Выбор

В FAU_SEL.1.1 автору ПЗ/ЗБ следует выбрать, на каких атрибутах безопасности основана избирательность аудита: идентификатор объекта, идентификатор пользователя, идентификатор субъекта, идентификатор узла сети или тип события.

C.6.2.2.2. Назначение

В FAU_SEL.1.1 автору ПЗ/ЗБ следует определить дополнительные атрибуты, на которых основана избирательность аудита. Если нет дополнительных правил, на которых основана избирательность аудита, то данное назначение может быть выполнено как "нет".

C.7. Хранение данных аудита безопасности (FAU_STG)

C.7.1. Замечания по применению

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

C.7.2. FAU_STG.1 Защищенное хранение журнала аудита

C.7.2.1. Замечания по применению для пользователя

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

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

C.7.2.2. Операции

C.7.2.2.1. Выбор

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

C.7.3. FAU_STG.2 Гарантии доступности данных аудита

C.7.3.1. Замечания по применению для пользователя

Компонент FAU_STG.2 позволяет автору ПЗ/ЗБ определить метрику для журнала аудита.

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

C.7.3.2. Операции

C.7.3.2.1. Выбор

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

C.7.3.2.2. Назначение

В FAU_STG.2.3 автору ПЗ/ЗБ следует специфицировать метрику, которую ФБО должны обеспечить для журнала аудита. Эта метрика ограничивает потерю данных указанием максимального числа записей, которые необходимо сохранять, или временем, в течение которого обеспечивается хранение записей. Примером метрики может быть число 100000, указывающее, что журнал аудита рассчитан на 100000 записей.

C.7.3.2.3. Выбор

В FAU_STG.2.3 автору ПЗ/ЗБ следует специфицировать условие, при котором ФБО должны быть все еще способны сопровождать определенный объем данных аудита. Это может быть одно из следующих условий: переполнение журнала аудита, сбой, атака.

C.7.4. FAU_STG.3 Действия в случае возможной потери данных аудита

C.7.4.1. Замечания по применению для пользователя

Компонент FAU_STG.3 содержит требование выполнения определенных действий в случае превышения журналом аудита некоторого заранее определяемого предела.

C.7.4.2. Операции

C.7.4.2.1. Назначение

В FAU_STG.3.1 автору ПЗ/ЗБ следует указать значение заранее определяемого предела принятого ограничения. Если функции управления допускают, что уполномоченный пользователь может его изменить, то предел принятого ограничения является значением по умолчанию. Автор ПЗ/ЗБ может позволить уполномоченному пользователю всегда определять это ограничение. В этом случае назначение может быть, например, следующим: "ограничение устанавливает уполномоченный пользователь".

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

C.7.5. FAU_STG.4 Предотвращение потери данных аудита

C.7.5.1 Замечания по применению для пользователя

В компоненте FAU_STG.4 определяется режим функционирования ОО при переполнении журнала аудита: игнорирование записей аудита либо приостановка функционирования ОО для предотвращения возникновения событий, подвергающихся аудиту. Устанавливают, что независимо от принятого решения уполномоченный пользователь, имеющий соответствующие права, может продолжать генерировать события (действия), подвергающиеся аудиту. Это делается потому, что в противном случае уполномоченный администратор не смог бы осуществить даже перезапуск системы. Следует также предусмотреть действия, предпринимаемые ФБО при переполнении журнала аудита, поскольку игнорирование событий, способствующее лучшей доступности ОО, приведет также к возможности совершать действия, не оставляя о них записей и не относя их на счет определенного пользователя.

C.7.5.2. Операции

C.7.5.2.1. Выбор

В FAU_STG.4.1 автору ПЗ/ЗБ следует выбрать, должны ли ФБО в случае переполнения журнала аудита игнорировать проведение аудита, следует ли предотвращать действия, подвергающиеся аудиту, или следует новые записи помещать вместо старых. Может быть выбран только один из вариантов.

C.7.5.2.2. Назначение

В FAU_STG.4.1 автору ПЗ/ЗБ следует определить другие действия, предпринимаемые в случае сбоя хранения данных аудита, такие как информирование уполномоченного пользователя. Если нет никаких других действий, которые нужно предпринять в случае сбоя хранения данных аудита, то данное назначение может быть выполнено как "нет".

Приложение D
(обязательное)

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

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

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

Декомпозиция класса FCO "Связь" на составляющие его компоненты показана на рисунке D.1.

Рисунок D.1. Декомпозиция класса FCO "Связь"

D.1. Неотказуемость отправления (FCO_NRO)

D.1.1. Замечания для пользователя

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

Если информация или ассоциированные с ней атрибуты каким-либо образом изменяются, подтверждение правильности свидетельства отправления может дать отрицательный результат. Поэтому автору ПЗ/ЗБ следует предусмотреть включение в ПЗ/ЗБ требований целостности из компонента FDP_UIT.1 "Целостность передаваемых данных".

Неотказуемость связана с несколькими различными ролями, выполняемыми одним или несколькими субъектами. Во-первых, это субъект, который запрашивает свидетельство отправления (только в FCO_NRO.1 "Избирательное доказательство отправления"). Во-вторых, получатель и/или другие субъекты, которым предоставляется свидетельство (например, нотариус). В-третьих, субъект, который запрашивает верификацию свидетельства отправления, например, получатель или третье лицо, например, арбитр.

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

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

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

D.1.2. FCO_NRO.1 Избирательное доказательство отправления

D.1.2.1. Операции

D.1.2.1.1. Назначение

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

D.1.2.1.2. Выбор

В FCO_NRO.1.1 автору ПЗ/ЗБ следует специфицировать пользователя/субъект, который может запросить свидетельство отправления.

D.1.2.1.3. Назначение

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

В FCO_NRO.1.2 автору ПЗ/ЗБ следует внести в список те атрибуты, которые должны быть связаны с информацией, например, идентификатор отправителя, время и место отправления.

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

D.1.2.1.4. Выбор

В FCO_NRO.1.3 автору ПЗ/ЗБ следует специфицировать пользователя/субъект, который может верифицировать свидетельство отправления.

D.1.2.1.5. Назначение

В FCO_NRO.1.3 автору ПЗ/ЗБ следует сформировать список ограничений, при которых может быть верифицировано свидетельство. Например, свидетельство может быть верифицировано только в течение суток. Допустимо назначение "немедленно" или "неограниченно".

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

D.1.3. FCO_NRO.2 Принудительное доказательство отправления

D.1.3.1. Операции

D.1.3.1.1. Назначение

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

В FCO_NRO.2.2 автору ПЗ/ЗБ следует внести в список те атрибуты, которые должны быть связаны с информацией, например, идентификатор отправителя, время и место отправления.

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

D.1.3.1.2. Выбор

В FCO_NRO.2.3 автору ПЗ/ЗБ следует специфицировать пользователя/субъект, который может верифицировать свидетельство отправления.

D.1.3.1.3. Назначение

В FCO_NRO.2.3 автору ПЗ/ЗБ следует сформировать список ограничений, при которых может быть верифицировано свидетельство. Например, свидетельство может быть верифицировано только в течение суток. Допустимо назначение "немедленно" или "неограниченно".

В FCO_NRO.2.3 автору ПЗ/ЗБ в соответствии с выбором следует специфицировать третью сторону, которая может верифицировать свидетельство отправления. Третьей стороной может быть арбитр, судья или юридический орган.

D.2. Неотказуемость получения (FCO_NRR)

D.2.1. Замечания для пользователя

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

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

Если информация или ассоциированные с ней атрибуты каким-либо образом изменяются, проверка правильности свидетельства получения может дать отрицательный результат. Поэтому автору ПЗ/ЗБ следует предусмотреть включение в ПЗ/ЗБ требований целостности из компонента FDP_UIT.1 "Целостность передаваемых данных".

Неотказуемость связана с несколькими различными ролями, выполняемыми одним или несколькими субъектами. Во-первых, это субъект, который запрашивает свидетельство получения (только в FCO_NRR.1 "Избирательное доказательство получения"). Во-вторых, получатель и/или другие субъекты, которым предоставляется свидетельство (например, нотариус). В-третьих, субъект, который запрашивает верификацию свидетельства получения, например, отправитель или третья сторона, например, арбитр.

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

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

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

D.2.2. FCO_NRR.1 Избирательное доказательство получения

D.2.2.1. Операции

D.2.2.1.1. Назначение

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

D.2.2.1.2. Выбор

В FCO_NRR.1.1 автору ПЗ/ЗБ следует специфицировать пользователя/субъект, который может запросить свидетельство получения.

D.2.2.1.3. Назначение

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

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

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

D.2.2.1.4. Выбор

В FCO_NRR.1.3 автору ПЗ/ЗБ следует специфицировать пользователя/субъект, который может верифицировать свидетельство получения.

D.2.2.1.5 Назначение

В FCO_NRR.1.3 автору ПЗ/ЗБ следует сформировать список ограничений, при которых может быть верифицировано свидетельство. Например, свидетельство может быть верифицировано только в течение суток. Допустимо назначение "немедленно" или "неограниченно".

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

D.2.3. FCO_NRR.2 Принудительное доказательство получения

D.2.3.1. Операции

D.2.3.1.1. Назначение

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

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

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

D.2.3.1.2. Выбор

В FCO_NRR.2.3 автору ПЗ/ЗБ следует специфицировать пользователя/субъект, который может верифицировать свидетельство получения.

D.2.3.1.3. Назначение

В FCO_NRR.2.3 автору ПЗ/ЗБ следует сформировать список ограничений, при которых может быть верифицировано свидетельство. Например, свидетельство может быть верифицировано только в течение суток. Допустимо назначение "немедленно" или "неограниченно".

В FCO_NRR.2.3 автору ПЗ/ЗБ в соответствии с выбором следует специфицировать третьи стороны, которые могут верифицировать свидетельство получения. Третьей стороной может быть арбитр, судья или юридический орган.

Приложение E
(обязательное)

ФБО могут использовать криптографические функциональные возможности для содействия достижению некоторых наиболее важных целей безопасности. К ним относятся (но ими не ограничиваются) следующие цели: идентификация и аутентификация, неотказуемость, доверенный маршрут, доверенный канал, разделение данных. Класс FCS применяют, если ОО имеет криптографические функции, которые могут быть реализованы аппаратными, программно-аппаратными и/или программными средствами.

Класс FCS "Криптографическая поддержка" состоит из двух семейств: FCS_CKM "Управление криптографическими ключами" и FCS_COP "Криптографические операции". В семействе FCS_CKM рассмотрены аспекты управления криптографическими ключами, тогда как в семействе FCS_COP рассмотрено практическое применение этих криптографических ключей.

Для каждого метода генерации криптографических ключей, реализованного в ОО, автору ПЗ/ЗБ следует применить компонент FCS_CKM.1 "Генерация криптографических ключей".

Для каждого метода распределения криптографических ключей, реализованного в ОО, автору ПЗ/ЗБ следует применить компонент FCS_CKM.2 "Распределение криптографических ключей".

Для каждого метода доступа к криптографическим ключам, реализованного в ОО, автору ПЗ/ЗБ следует применить компонент FCS_CKM.3 "Доступ к криптографическим ключам".

Для каждого метода уничтожения криптографических ключей, реализованного в ОО, автору ПЗ/ЗБ следует применить компонент FCS_CKM.4 "Уничтожение криптографических ключей".

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

Криптографические функциональные возможности применимы для достижения целей безопасности, специфицированных в классе FCO "Связь", а также в семействах FDP_DAU "Аутентификация данных", FDP_SDI "Целостность хранимых данных", FDP_UCT "Защита конфиденциальности данных пользователя при передаче между ФБО", FDP_UIT "Защита целостности данных пользователя при передаче между ФБО", FIA_SOS "Спецификация секретов", FIA_UAU "Аутентификация пользователя". В случае, если криптографические функциональные возможности используют для достижения целей безопасности из других классов, цели, требующие применения криптографических средств, специфицируют в отдельных компонентах. Цели класса FSC "Криптографическая поддержка" должны использоваться, если потребители нуждаются в криптографических функциональных возможностях ОО.

Декомпозиция класса FCS "Криптографическая поддержка" на составляющие его компоненты показана на рисунке E.1.

Рисунок E.1. Декомпозиция класса FSC "Криптографическая поддержка"

E.1. Управление криптографическими ключами (FCS_CKM)

E.1.1. Замечания для пользователя

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

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

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

Если в ПЗ/ЗБ включен компонент семейства FAU_GEN "Генерация данных аудита безопасности", то аудиту следует подвергать события, связанные с:

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

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

Для генерации криптографических ключей обычно используют случайные числа. Тогда вместо FIA_SOS.2 "Генерация секретов ФБО" следует использовать компонент FCS_CKM.1. Компонент FIA_SOS.2 следует применять, если генерация случайных чисел требуется для иных целей.

E.1.2. FCS_CKM.1 Генерация криптографических ключей

E.1.2.1. Замечания по применению для пользователя

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

E.1.2.2. Операции

E.1.2.2.1. Назначение

В FCS_CKM.1.1 автору ПЗ/ЗБ следует определить, какой алгоритм генерации криптографических ключей будет использоваться.

В FCS_CKM.1.1 автору ПЗ/ЗБ следует определить, какой длины криптографические ключи будут использоваться. Следует, чтобы длина ключа соответствовала выбранному алгоритму и предполагаемому применению ключа.

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

E.1.3. FCS_CKM.2 Распределение криптографических ключей

E.1.3.1. Замечания по применению для пользователя

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

E.1.3.2. Операции

E.1.3.2.1. Назначение

В FCS_CKM.2.1 автору ПЗ/ЗБ следует определить, какой метод используется для распределения криптографических ключей.

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

E.1.4. FCS_CKM.3 Доступ к криптографическим ключам

E.1.4.1. Замечания по применению для пользователя

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

E.1.4.2. Операции

E.1.4.2.1. Назначение

В FCS_CKM.3.1 автору ПЗ/ЗБ следует определить используемый тип доступа к криптографическим ключам. Примерами операций с криптографическими ключами, к которым предоставляется доступ, являются (но не ограничиваются ими): резервное копирование, архивирование, передача на хранение и восстановление.

В FCS_CKM.3.1 автору ПЗ/ЗБ следует определить, какой метод будет использоваться для доступа к криптографическим ключам.

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

E.1.5. FCS_CKM.4 Уничтожение криптографических ключей

E.1.5.1. Замечания по применению для пользователя

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

E.1.5.2. Операции

E.1.5.2.1. Назначение

В FCS_CKM.4.1 автору ПЗ/ЗБ следует определить, какой метод будет использован для уничтожения криптографических ключей.

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

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

E.2.1. Замечания для пользователя

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

Криптографические операции могут использоваться для поддержки одной или нескольких функций безопасности ОО. Может возникнуть необходимость в итерациях компонента FCS_COP в зависимости от:

a) прикладной программы пользователя, для которой понадобилась данная функция;

b) применения различных криптографических алгоритмов и/или длины криптографических ключей;

c) типа или чувствительности обрабатываемых данных.

Если в ПЗ/ЗБ включен компонент семейства FAU_GEN "Генерация данных аудита безопасности", то аудиту следует подвергать события, связанные с:

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

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

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

E.2.2. FCS_COP.1 Криптографические операции

E.2.2.1. Замечания по применению для пользователя

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

E.2.2.2. Операции

E.2.2.2.1. Назначение

В FCS_COP.1.1 автору ПЗ/ЗБ следует определить выполняемые криптографические операции. Типичными криптографическими операциями являются генерация и/или верификация цифровых подписей, генерация криптографических контрольных сумм для обеспечения целостности и/или верификации контрольных сумм, безопасное хэширование (вычисление хэш-образа сообщения), зашифрование и/или расшифрование данных, зашифрование и/или расшифрование криптографических ключей, согласование криптографических ключей и генерация случайных чисел. Криптографические операции могут выполняться с данными как пользователя, так и ФБО.

В FCS_COP.1.1 автору ПЗ/ЗБ следует определить, какой криптографический алгоритм будет использован.

В FCS_COP.1.1 автору ПЗ/ЗБ следует определить, какой длины криптографические ключи будут использоваться. Необходимо, чтобы длина ключа соответствовала выбранному алгоритму и предполагаемому применению ключа.

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

Приложение F
(обязательное)

Класс FDP "Защита данных пользователя" содержит семейства, определяющие требования к функциям безопасности ОО и политикам функций безопасности ОО, связанным с защитой данных пользователя. Этот класс отличается от классов FIA и FPT тем, что определяет компоненты для защиты данных пользователя, тогда как класс FIA определяет компоненты для защиты атрибутов, ассоциированных с пользователем, а класс FPT - для защиты информации ФБО.

Данный класс не содержит явного требования мандатного управления доступом (Mandatory Access Controls - MAC) или традиционного дискреционного управления доступом (Discretionary Access Controls - DAC); тем не менее, такие требования могут быть выражены с использованием компонентов этого класса.

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

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

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

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

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

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

Политика безопасности ОО может содержать несколько политик функций безопасности (ПФБ), каждая из которых будет идентифицирована компонентами двух ориентированных на политики семейств "Политика управления безопасностью" FDP_ACC и "Политика управления информационными потоками" FDP_IFC. Эти политики будут, как правило, учитывать аспекты конфиденциальности, целостности и доступности так, как это потребуется для удовлетворения требований к ОО. Следует обеспечить, чтобы на каждый объект обязательно распространялась, по меньшей мере, одна ПФБ и при реализации различных ПФБ не возникали конфликты.

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

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

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

Ключом к выбору компонентов этого семейства является наличие полностью определенной политики безопасности ОО, обеспечивающей правильный выбор компонентов из семейств "Политика управления доступом" FDP_ACC и "Политика управления информационными потоками" FDP_IFC. В FDP_ACC "Политика управления доступом" и FDP_IFC "Политика управления информационными потоками" присваивают имя соответственно каждой политике управления доступом или информационными потоками. Кроме того, эти компоненты определяют субъекты, объекты и операции, входящие в область действия соответствующей функции безопасности. Предполагается, что имена этих политик будут использоваться повсеместно в тех функциональных компонентах, которые имеют операцию, запрашивающую назначение или выбор "ПФБ управления доступом" и/или "ПФБ управления информационными потоками". Правила, которые определяют функциональные возможности именованных ПФБ управления доступом или информационными потоками, будут установлены в семействах FDP_ACF "Функции управления доступом" и FDP_IFF "Функции управления информационными потоками" соответственно.

Ниже приведена рекомендуемая последовательность применения этого класса при построении ПЗ/ЗБ, для чего необходимо идентифицировать:

a) осуществляемые политики, применив семейства FDP_ACC "Политика управления доступом" и FDP_IFC "Политика управления информационными потоками". Эти семейства определяют область действия каждой политики, уровень детализации управления и могут идентифицировать некоторые правила следования политике;

b) требуемые компоненты, после чего выполнить все применяемые операции в компонентах, относящихся к политикам. Операции назначения могут выполняться как в обобщенном виде (например, "все файлы"), так и конкретно ("файлы "A", "B" и т.д.) в зависимости от уровня детализации;

c) все потенциально применяемые компоненты, относящиеся к функциям, из семейств FDP_ACF "Функции управления доступом" и FDP_IFF "Функции управления информационными потоками", связанные с именованными политиками из семейств FDP_ACC "Политика управления доступом" и FDP_IFC "Политика управления информационными потоками". Далее выполнить операции, чтобы получить компоненты, определяющие правила этих политик. Это следует сделать так, чтобы компоненты отражали требования выбранной функции, которые уже можно себе представить или которые только подлежат разработке;

d) тех, кому будет предоставлена возможность управления атрибутами функций безопасности и их изменения, например, только администратору безопасности, только владельцу объекта и т.д., после чего выбрать соответствующие компоненты из класса FMT "Управление безопасностью" и выполнить в них операции. При этом могут быть полезны уточнения для идентификации недостающих свойств, например, некоторые или все изменения необходимо выполнять только с использованием доверенного маршрута;

e) все подходящие компоненты класса FMT "Управление безопасностью", необходимые для спецификации начальных значений новых объектов и субъектов;

f) все компоненты семейства FDP_ROL "Откат", применяемые для отката к предшествующему состоянию;

g) все требования из семейства FDP_RIP "Защита остаточной информации", применяемые для защиты остаточной информации;

h) все компоненты из семейств FDP_ITC "Импорт данных из-за пределов действия ФБО" и FDP_ETC "Экспорт данных за пределы действия ФБО", используемые при импорте или экспорте данных, указав, как следует обращаться при этом с атрибутами безопасности;

i) все используемые компоненты, относящиеся к внутренним передачам ОО, из семейства FDP_Itt "Передача в пределах ОО";

j) требования защиты целостности хранимой информации из семейства FDP_SDI "Целостность хранимых данных";

k) все применяемые компоненты, относящиеся к передаче данных между ФБО, из семейств FDP_UCT "Защита конфиденциальности данных пользователя при передаче между ФБО" или FDP_UIT "Защита целостности данных пользователя при передаче между ФБО".

Декомпозиция класса FDP на составляющие его компоненты показана на рисунке F.1.

Рисунок F.1. Декомпозиция класса FDP "Защита данных пользователя"

F.1. Политика управления доступом (FDP_ACC)

F.1.1. Замечания для пользователя

В основу семейства FDP_ACC положена концепция произвольного управления взаимодействием субъектов и объектов. Область и цель управления определяются атрибутами получателя прав доступа (субъекта), атрибутами хранилища данных, к которому предоставляется доступ (объекта), действиями (операциями) и ассоциированными правилами управления доступом.

Компоненты этого семейства дают возможность идентификации (по имени) ПФБ управления доступом, в основе которых лежат традиционные механизмы дискреционного управления доступом (DAC). В семействе определяются субъекты, объекты и операции, которые входят в область действия идентифицированных политик управления доступом. Правила, определяющие функциональные возможности ПФБ управления доступом, будут установлены другими семействами, такими как FDP_ACF "Функции управления доступом" и FDP_RIP "Защита остаточной информации". Предполагается, что имена ПФБ, идентифицированные в семействе FDP_ACC "Политика управления доступом", будут использоваться повсеместно в тех функциональных компонентах, которые имеют операцию, запрашивающую назначение или выбор "ПФБ управления доступом".

В область действия ПФБ управления доступом входит множество триад "субъект, объект, операции". Следовательно, на субъект могут распространяться несколько ПФБ, но только в различных сочетаниях с объектами и операциями. То же относится к объектам и операциям.

Важнейшим аспектом функции управления доступом, осуществляющей ПФБ управления доступом, является предоставление пользователям возможности модифицировать атрибуты управления доступом. Семейство FDP_ACC "Политика управления доступом" для этого не предназначено. Часть относящихся к этой проблеме требований не определена, но их можно ввести как уточнение; часть содержится в других семействах и классах, например, в классе FMT "Управление безопасностью".

В семействе FDP_ACC "Политика управления доступом" нет требований аудита, поскольку оно специфицирует только требования ПФБ управления доступом. Требования аудита присутствуют в семействах, специфицирующих функции для удовлетворения ПФБ управления доступом, идентифицированных в этом семействе.

Это семейство предоставляет автору ПЗ/ЗБ возможность спецификации нескольких политик, например, жесткую ПФБ управления доступом в одной области действия и гибкую в другой. Для спецификации нескольких политик управления доступом компоненты этого семейства могут использоваться в ПЗ/ЗБ несколько раз для различных подмножеств операций и объектов. Это применимо к ОО, в которых предусмотрено несколько политик для различных подмножеств операций и объектов. Другими словами, автору ПЗ/ЗБ следует специфицировать, применяя компонент ACC, необходимую информацию о каждой из ПФБ, которые будут осуществляться ФБО. Например, ПЗ/ЗБ для ОО, включающего в себя три ПФБ, каждая из которых действует для своей части объектов, субъектов и операций в пределах ОО, будет содержать по одному компоненту FDP_ACC.1 "Ограниченное управление доступом" для каждой из трех ПФБ.

F.1.2. FDP_ACC.1 Ограниченное управление доступом

F.1.2.1. Замечания по применению для пользователя

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

Компонент FDP_ACC.1 определяет, что политика распространяется на некоторое полностью определенное множество операций на каком-либо подмножестве объектов. Данный компонент не накладывает никаких ограничений на операции, не входящие в это множество, в том числе операции на объектах, на которых иные операции управляются.

F.1.2.2. Операции

F.1.2.2.1. Назначение

В FDP_ACC.1.1 автору ПЗ/ЗБ следует специфицировать уникально именованную ПФБ управления доступом, осуществляемую ФБО.

В FDP_ACC.1.1 автору ПЗ/ЗБ следует специфицировать список субъектов, объектов и операций субъектов на объектах, на которые распространяется данная ПФБ.

F.1.3. FDP_ACC.2 Полное управление доступом

F.1.3.1. Замечания по применению для пользователя

Компонент FDP_ACC.2 содержит требование, чтобы ПФБ управления доступом распространялась на все возможные операции над объектами, включенными в ПФБ.

Автору ПЗ/ЗБ необходимо продемонстрировать, что на любую комбинацию объектов и субъектов распространяется какая-либо ПФБ управления доступом.

F.1.3.2. Операции

F.1.3.2.1. Назначение

В FDP_ACC.2.1 автору ПЗ/ЗБ следует специфицировать уникально именованную ПФБ управления доступом, осуществляемую ФБО.

В FDP_ACC.2.1 автору ПЗ/ЗБ следует специфицировать список субъектов и объектов, на которые распространяется данная ПФБ. ПФБ будет распространяться на все операции между этими субъектами и объектами.

F.2. Функции управления доступом (FDP_ACF)

F.2.1. Замечания для пользователя

Семейство FDP_ACF описывает правила для конкретных функций, которые могут реализовать политики управления доступом, именованные в FDP_ACC "Политика управления доступом". В FDP_ACC также определяется область действия этих политик.

Данное семейство позволяет автору ПЗ/ЗБ описать правила управления доступом. В результате правила доступа к объектам системы не будут изменяться. Примером такого объекта является рубрика "Новости дня", которую читать могут все, а изменять - только уполномоченный администратор. Данное семейство также позволяет автору ПЗ/ЗБ устанавливать исключения из общих правил управления доступом. Такие исключения будут явно разрешать или запрещать авторизацию доступа к объекту.

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

В этом семействе можно определить ряд ФБ управления доступом, имеющих в основе:

- списки контроля доступа (матрица доступа);

- спецификации управления доступом на основе времени;

- спецификации управления доступом на основе источника;

- атрибуты управления доступом, управляемые их владельцем.

F.2.2. FDP_ACF.1 Управление доступом, основанное на атрибутах безопасности

F.2.2.1. Замечания по применению для пользователя

Компонент FDP_ACF.1 обеспечивает требования к механизму, который поддерживает управление доступом, основанное на атрибутах безопасности, ассоциированных с субъектами и объектами. Каждый объект и субъект имеет совокупность ассоциированных с ним атрибутов, таких как расположение, время создания, права доступа (например, списки контроля доступа). Данный компонент позволяет автору ПЗ/ЗБ специфицировать атрибуты, которые будут использоваться для посредничества при управлении доступом, а также правила управления доступом на основе этих атрибутов.

Примеры атрибутов, которые может назначать автор ПЗ/ЗБ, представлены ниже.

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

Атрибут "время" может использоваться для определения того, что доступ будет предоставляться только в указанные время суток, дни недели или календарный год.

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

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

Компонент FDP_ACF.1 содержит также требования, дающие функциям управления доступом возможность явно предоставлять или запрещать доступ к объектам на основании атрибутов безопасности. Его можно использовать для предоставления полномочий, прав доступа или разрешения доступа в пределах ОО. Такие полномочия, права или разрешения можно применять к пользователям, субъектам (представляющим пользователей или приложения) и объектам.

F.2.2.2. Операции

F.2.2.2.1. Назначение

В FDP_ACF.1.1 автору ПЗ/ЗБ следует специфицировать имя ПФБ управления доступом, осуществляемой ФБО. Имя и область действия ПФБ управления доступом определяются в компонентах семейства FDP_ACC.

В FDP_ACF.1.1 автору ПЗ/ЗБ следует специфицировать атрибуты безопасности и/или именованные группы атрибутов безопасности, которые функция будет использовать при спецификации правил, для каждого управляемого субъекта или объекта. Такими атрибутами безопасности могут быть, например, идентификатор пользователя, идентификатор субъекта, роль, время суток, местоположение, списки контроля доступа, а также любые другие атрибуты, специфицированные автором ПЗ/ЗБ. Для удобства ссылок на атрибуты безопасности неоднократного применения можно ввести именованные группы атрибутов безопасности. Именованные группы могут оказаться полезными при ассоциации "ролей", определенных в семействе FMT_SMR "Роли управления безопасностью", и соответствующих им атрибутов с субъектами. Другими словами, каждую роль можно связать с именованной группой атрибутов.

В FDP_ACF.1.2 автору ПЗ/ЗБ следует специфицировать для данной ПФБ правила управления доступом контролируемых субъектов к контролируемым объектам и контролируемым операциям на контролируемых объектах. Эти правила определяют, когда доступ предоставляется, а когда в нем отказано. В них могут быть специфицированы функции управления доступом общего характера (использующие, например, обычные биты разрешения) или структурированные функции управления доступом (использующие, например, списки контроля доступа).

В FDP_ACF.1.3 автору ПЗ/ЗБ следует специфицировать основанные на атрибутах безопасности правила, которые будут использоваться для явного разрешения доступа субъектов к объектам и дополняют правила, установленные в FDP_ACF.1.1. Они вынесены в отдельный элемент FDP_ACF.1.3, поскольку описывают исключения из правил, установленных в FDP_ACF.1.1. Например, правила явного разрешения доступа могут быть основаны на векторе полномочий, ассоциированном с субъектом и всегда обеспечивающим ему доступ к объектам, на которые распространяется специфицируемая ПФБ управления доступом. Если подобная возможность нежелательна, то автору ПЗ/ЗБ следует указать "Нет" в данной операции.

В FDP_ACF.1.4 автору ПЗ/ЗБ следует специфицировать основанные на атрибутах безопасности правила, которые будут использоваться для явного отказа в доступе субъектов к объектам и дополняют правила, установленные в FDP_ACF.1.1. Они вынесены в отдельный элемент FDP_ACF.1.4, поскольку описывают исключения из правил, установленных в FDP_ACF.1.1. Например, правила явного отказа в доступе могут быть основаны на векторе полномочий, ассоциированном с субъектом и явно отказывающем ему в доступе к объектам, на которые распространяется специфицируемая ПФБ управления доступом. Если подобная возможность нежелательна, то автору ПЗ/ЗБ следует указать "Нет" в данной операции.

F.3. Аутентификация данных (FDP_DAU)

F.3.1. Замечания для пользователя

Семейство FDP_DAU описывает специальные функции, используемые для аутентификации "статических" данных.

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

F.3.2. FDP_DAU.1 Базовая аутентификация данных

F.3.2.1. Замечания по применению для пользователя

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

F.3.2.2. Операции

F.3.2.2.1. Назначение

В FDP_DAU.1.1 автору ПЗ/ЗБ следует специфицировать список объектов или типов информации, для которых ФБО должны быть в состоянии генерировать свидетельство аутентификации данных.

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

F.3.3. FDP_DAU.2 Аутентификация данных с идентификацией гаранта

F.3.3.1. Замечания по применению для пользователя

Компонент FDP_DAU.2 дополнительно содержит требование наличия возможности верифицировать идентификатор пользователя, предоставляющего гарантию аутентификации (например, доверенного третьего лица).

F.3.3.2. Операции

F.3.3.2.1. Назначение

В FDP_DAU.2.1 автору ПЗ/ЗБ следует специфицировать список объектов или типов информации, для которых ФБО должны быть в состоянии генерировать свидетельство аутентификации данных.

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

F.4. Экспорт данных за пределы действия ФБО (FDP_ETC)

F.4.1. Замечания для пользователя

Семейство FDP_ETC определяет функции для экспорта данных пользователя из ОО так, что их атрибуты безопасности могут полностью сохраняться или игнорироваться при экспорте этих данных. Согласованность этих атрибутов безопасности обеспечивается семейством FPT_tdC "Согласованность данных ФБО между ФБО".

В семействе FDP_ETC "Экспорт данных за пределы действия ФБО" также рассматриваются ограничения на экспорт и ассоциация атрибутов безопасности с экспортируемыми данными пользователя.

FDP_ETC и соответствующее семейство для импорта данных FDP_ITC "Импорт данных из-за пределов действия ФБО" определяют, как ОО поступает с данными пользователей, передаваемыми из ОДФ и поступающими в нее. Фактически семейство FDP_ETC обеспечивает экспорт данных пользователей и связанных с ними атрибутов безопасности.

В данном семействе могут рассматриваться следующие действия:

a) экспорт данных пользователей без каких-либо атрибутов безопасности;

b) экспорт данных пользователей с атрибутами безопасности, ассоциированными с этими данными, причем атрибуты безопасности однозначно представляют экспортируемые данные пользователя.

Если применяются несколько ПФБ управления доступом и/или информационными потоками, то может потребоваться повторить этот компонент отдельно для каждой политики (то есть применить к нему операцию итерации).

F.4.2. FDP_ETC.1 Экспорт данных пользователя без атрибутов безопасности

F.4.2.1. Замечания по применению для пользователя

Компонент FDP_ETC.1 используется для спецификации экспорта информации без экспорта атрибутов безопасности.

F.4.2.2. Операции

F.4.2.2.1. Назначение

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

F.4.3. FDP_ETC.2 Экспорт данных пользователя с атрибутами безопасности

F.4.3.1. Замечания по применению для пользователя

Данные пользователя экспортируются вместе со своими атрибутами безопасности. Эти атрибуты безопасности однозначно ассоциированы с данными пользователя. Ассоциация может устанавливаться различными способами. К способам установления ассоциации относятся совместное физическое размещение данных пользователя и атрибутов безопасности (например, на одной дискете) или использование криптографических методов, например, цифровых подписей, для ассоциации этих атрибутов и данных пользователя. Для обеспечения получения правильных значений атрибутов другим доверенным продуктом ИТ можно использовать семейство FTP_ITC "Доверенный канал передачи между ФБО", в то время как семейство FPT_tdC "Согласованность данных ФБО между ФБО" может применяться для достижения уверенности в правильной интерпретации этих атрибутов. В свою очередь, семейство FTP_trP "Доверенный маршрут" может применяться для достижения уверенности в инициации экспорта надлежащим пользователем.

F.4.3.2. Операции

F.4.3.2.1. Назначение

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

В FDP_ETC.2.4 автору ПЗ/ЗБ следует специфицировать все дополнительные правила управления экспортом или указать "Нет" при их отсутствии. Эти правила будут реализованы ФБО в дополнение к ПФБ управления доступом и/или информационными потоками, выбранным в FDP_ETC.2.1.

F.5. Политика управления информационными потоками (FDP_IFC)

F.5.1. Замечания для пользователя

В семействе FDP_IFC идентифицируются ПФБ управления информационными потоками и специфицируются области действия каждой такой политики.

Примерами политик безопасности, которые могут быть применены, являются:

- модель безопасности Белла и Ла Падулы [1];

- модель целостности Биба [2];

- невмешательство [5], [6].

Компоненты этого семейства дают возможность идентификации ПФБ управления информационными потоками, осуществляемых традиционными механизмами мандатного управления доступом при их наличии в ОО. Однако их возможности шире традиционных механизмов мандатного управления доступом. Они могут использоваться для определения политик невмешательства и политик, основанных на переходах между состояниями. В этом семействе для каждой из ПФБ управления информационными потоками ОО определяются субъекты, информация и операции перемещения информации к субъектам и от субъектов. Правила, определяющие функциональные возможности ПФБ управления информационными потоками, будут установлены другими семействами, такими как FDP_IFF "Функции управления информационными потоками" и FDP_RIP "Защита остаточной информации". ПФБ управления информационными потоками, определенные в семействе FDP_IFC, в дальнейшем будут использоваться повсеместно в тех функциональных компонентах, которые включают в себя операцию, запрашивающую назначение или выбор "ПФБ управления информационными потоками".

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

Каждая ПФБ распространяется на некоторое множество триад: "субъект, информация, операции перемещения информации к субъектам и от субъектов". Некоторые политики управления информационными потоками могут иметь очень подробную детализацию и описывать субъекты непосредственно в терминах процессов операционной системы. Другие политики могут определяться с меньшими подробностями и описывать субъекты в терминах пользователей или каналов ввода/вывода. Если политика управления информационными потоками задана недостаточно подробно, то четкое определение требуемых функций безопасности ИТ может оказаться невыполнимым. В этом случае целесообразнее описывать политики управления информационными потоками как цели безопасности. Тогда требуемые функции безопасности ИТ можно специфицировать, исходя из этих целей.

Во втором компоненте (FDP_IFC.2 "Полное управление информационными потоками") каждая ПФБ управления информационными потоками будет охватывать все возможные операции перемещения информации к субъектам и от субъектов под управлением этой ПФБ. Более того, требуется, чтобы все информационные потоки были охвачены какой-либо ПФБ, поэтому для каждого действия, вызвавшего перемещение информации, будет существовать совокупность правил, определяющих, является ли данное действие допустимым. Если данный информационный поток подчинен нескольким ПФБ, то необходимо его разрешение всеми этими политиками до его начала.

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

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

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

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

F.5.2. FDP_IFC.1 Ограниченное управление информационными потоками

F.5.2.1. Замечания по применению для пользователя

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

F.5.2.2. Операции

F.5.2.2.1. Назначение

В FDP_IFC.1.1 автору ПЗ/ЗБ следует специфицировать уникально именованную ПФБ управления информационными потоками, осуществляемую ФБО.

В FDP_IFC.1.1 автору ПЗ/ЗБ следует специфицировать список субъектов, информации и операций, вызывающих перемещение управляемой информации к управляемым субъектам и от них, на которые распространяется данная ПФБ. Как указано выше, этот список субъектов может быть задан с различной степенью детализации, определяемой потребностями автора ПЗ/ЗБ. Автор может, например, специфицировать пользователей, устройства или процессы. Информация может относиться к таким данным, как электронная почта, сетевые протоколы или к более конкретным объектам, аналогичным специфицированным в политике управления доступом. Если информация содержится в объекте, который подчинен политике управления доступом, то политики управления доступом и информационными потоками необходимо применять совместно, прежде чем начнется перемещение специфицированной информации в объект или из него.

F.5.3. FDP_IFC.2 Полное управление информационными потоками

F.5.3.1. Замечания по применению для пользователя

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

Автору ПЗ/ЗБ необходимо продемонстрировать, что на любую комбинацию информационных потоков и субъектов распространяется какая-либо ПФБ управления информационным потоком.

F.5.3.2. Операции

F.5.3.2.1. Назначение

В FDP_IFC.2.1 автору ПЗ/ЗБ следует специфицировать уникально именованную ПФБ управления информационными потоками, осуществляемую ФБО.

В FDP_IFC.2.1 автору ПЗ/ЗБ следует специфицировать список субъектов и информации, на которые будет распространяться данная ПФБ. ПФБ будет распространяться на все операции, вызывающие перемещение этой информации к этим субъектам и от них. Как указано выше, этот список субъектов может быть задан с различной степенью детализации, определяемой потребностями автора ПЗ/ЗБ. Автор может, например, специфицировать пользователей, устройства или процессы. Информация может относиться к таким данным, как электронная почта, сетевые протоколы или к более конкретным объектам, аналогичным специфицированным в политике управления доступом. Если информация содержится в объекте, который подчинен политике управления доступом, то политики управления доступом и информационными потоками необходимо применять совместно, прежде чем начнется перемещение специфицированной информации в объект или из него.

F.6. Функции управления информационными потоками (FDP_IFF)

F.6.1. Замечания для пользователя

Семейство FDP_IFF описывает правила для конкретных функций, которые могут реализовать ПФБ управления информационными потоками, именованные в FDP_IFC "Политика управления информационными потоками", где также определена область действия соответствующей политики. Семейство содержит два типа требований: один связан с обычными информационными потоками, второй - с неразрешенными информационными потоками (скрытыми каналами), запрещенными одной или несколькими ПФБ. Это разделение возникает, потому что проблема неразрешенных информационных потоков в некотором смысле противоречит остальным аспектам ПФБ управления информационными потоками. Неразрешенные информационные потоки возникают в нарушение политики, поэтому они не являются результатом применения политики.

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

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

Гибкость этих компонентов позволяет специфицировать в FDP_IFF.1 "Простые атрибуты безопасности" и FDP_IFF.2 "Иерархические атрибуты безопасности" политику полномочий, дающую возможность контролируемого обхода ПФБ в целом или частично. Если необходимо заранее предопределить обход ПФБ, автору ПЗ/ЗБ следует предусмотреть применение политики полномочий.

F.6.2. FDP_IFF.1 Простые атрибуты безопасности

F.6.2.1. Замечания по применению для пользователя

Компонент FDP_IFF.1 содержит требования наличия атрибутов безопасности у информации и субъектов, являющихся отправителями или получателями этой информации. Следует также учитывать атрибуты безопасности мест хранения информации, если требуется их участие в управлении информационными потоками, или если на эти атрибуты распространяется политика управления доступом. Этот компонент специфицирует ключевые осуществляемые правила и описывает, как вводятся атрибуты безопасности. Например, компонент следует применять, если хотя бы одна из ПФБ управления информационными потоками основана на метках, как это определяет модель политики безопасности Белла и Ла Падулы [B&L], но эти атрибуты безопасности не образуют иерархию.

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

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

F.6.2.2. Операции

F.6.2.2.1. Назначение

В FDP_IFF.1.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления информационными потоками, осуществляемые ФБО. Имя и область действия ПФБ управления информационными потоками определяются в компонентах семейства FDP_IFC.

В FDP_IFF.1.1 автору ПЗ/ЗБ для каждого типа управляемых субъектов и информации следует специфицировать атрибуты безопасности, которые необходимы для спецификации правил ПФБ. Такими атрибутами безопасности могут быть, например, идентификатор субъекта, метка чувствительности субъекта, метка допуска субъекта к информации, метка чувствительности информации и т.д. Типы атрибутов безопасности должны быть достаточными для поддержки потребностей среды.

В FDP_IFF.1.2 автору ПЗ/ЗБ следует специфицировать для каждой операции реализуемые ФБО и основанные на атрибутах безопасности отношения, которые необходимо поддерживать между атрибутами безопасности субъектов и информации.

В FDP_IFF.1.3 автору ПЗ/ЗБ следует специфицировать все дополнительные правила ПФБ управления информационными потоками, которые от ФБО требуется реализовать. Если дополнительные правила не используются, то автору ПЗ/ЗБ следует указать "Нет" при выполнении рассматриваемой операции.

В FDP_IFF.1.4 автору ПЗ/ЗБ следует специфицировать все дополнительные возможности ПФБ, которые от ФБО требуется предоставить. Если дополнительные возможности не предоставляются, то автору ПЗ/ЗБ следует указать "Нет" при выполнении рассматриваемой операции.

В FDP_IFF.1.5 автору ПЗ/ЗБ следует специфицировать основанные на атрибутах безопасности правила, явно разрешающие информационные потоки и дополняющие правила, определенные в предыдущих элементах. Они вынесены в отдельный элемент FDP_IFF.1.5, поскольку описывают исключения из правил в предыдущих элементах. Например, правила явного разрешения информационного потока могут быть основаны на векторе полномочий, ассоциированном с субъектом и всегда обеспечивающим ему возможность инициировать перемещение информации, на которую распространяется специфицированная ПФБ. Если подобная возможность нежелательна, то автору ПЗ/ЗБ следует указать "Нет" в данной операции.

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

F.6.3. FDP_IFF.2 Иерархические атрибуты безопасности

F.6.3.1. Замечания по применению для пользователя

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

Например, этот компонент следует применять, когда хотя бы одна из ПФБ управления информационными потоками основана на метках, как это определяет модель политики безопасности Белла и Ла Падулы [1], и эти атрибуты безопасности образуют иерархию.

Важно отметить, что требования иерархических отношений, идентифицируемые в FDP_IFF.2.7, применимы только к атрибутам безопасности управления информационными потоками для ПФБ управления информационными потоками, идентифицированным в FDP_IFF.2.1. Этот компонент не применим к другим ПФБ, например, к ПФБ управления доступом.

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

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

F.6.3.2. Операции

F.6.3.2.1. Назначение

В FDP_IFF.2.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления информационными потоками, осуществляемые ФБО. Имя и область действия ПФБ управления информационными потоками определяются в компонентах семейства FDP_IFC.

В FDP_IFF.2.1 автору ПЗ/ЗБ следует специфицировать для каждого типа управляемых субъектов и информации атрибуты безопасности, необходимые для спецификации правил ПФБ. Такими атрибутами безопасности могут быть, например, идентификатор субъекта, метка чувствительности субъекта, метка допуска субъекта к информации, метка чувствительности информации и т.д. Типы атрибутов безопасности должны быть достаточными для поддержки потребностей среды.

В FDP_IFF.2.2 автору ПЗ/ЗБ следует специфицировать для каждой операции реализуемые ФБО и основанные на атрибутах безопасности отношения, которые необходимо поддерживать между атрибутами безопасности субъектов и информации. Эти отношения следует основывать на упорядоченных связях между атрибутами безопасности.

В FDP_IFF.2.3 автору ПЗ/ЗБ следует специфицировать все дополнительные правила ПФБ управления информационными потоками, которые от ФБО требуется реализовать. Если дополнительные правила не используются, то автору ПЗ/ЗБ следует указать "Нет" при выполнении рассматриваемой операции.

В FDP_IFF.2.4 автору ПЗ/ЗБ следует специфицировать все дополнительные возможности ПФБ, которые от ФБО требуется предоставить. Если дополнительные возможности не предоставляются, то автору ПЗ/ЗБ следует указать "Нет" при выполнении рассматриваемой операции.

В FDP_IFF.2.5 автору ПЗ/ЗБ следует специфицировать основанные на атрибутах безопасности правила, явно разрешающие информационные потоки и дополняющие правила, определенные в предыдущих элементах. Данные правила включены в отдельный элемент FDP_IFF.2.5, поскольку описывают исключения из правил в предыдущих элементах. Например, правила явного разрешения информационного потока могут быть основаны на векторе полномочий, ассоциированном с субъектом и всегда обеспечивающим ему возможность инициировать перемещение информации, на которую распространяется специфицированная ПФБ. Если подобная возможность нежелательна, то автору ПЗ/ЗБ следует указать "Нет" в данной операции.

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

F.6.4. FDP_IFF.3 Ограничение неразрешенных информационных потоков

F.6.4.1. Замечания по применению для пользователя

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

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

F.6.4.2. Операции

F.6.4.2.1. Назначение

В FDP_IFF.3.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления информационными потоками, осуществляемые ФБО. Имя и область действия ПФБ управления информационными потоками определяются в компонентах семейства FDP_IFC.

В FDP_IFF.3.1 автору ПЗ/ЗБ следует специфицировать типы неразрешенных информационных потоков, максимальная интенсивность которых ограничивается.

В FDP_IFF.3.1 автору ПЗ/ЗБ следует специфицировать максимальную интенсивность, допустимую для каждого из идентифицированных неразрешенных информационных потоков.

F.6.5. FDP_IFF.4 Частичное устранение неразрешенных информационных потоков

F.6.5.1. Замечания по применению для пользователя

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

F.6.5.2. Операции

F.6.5.2.1. Назначение

В FDP_IFF.4.1 автору ПЗ/ЗБ следует специфицировать правила ПФБ управления информационными потоками, осуществляемые ФБО. Имя и область действия ПФБ управления информационными потоками определяются в компонентах семейства FDP_IFC "Политика управления информационными потоками".

В FDP_IFF.4.1 автору ПЗ/ЗБ следует специфицировать типы неразрешенных информационных потоков, максимальная интенсивность которых ограничивается.

В FDP_IFF.4.1 автору ПЗ/ЗБ следует специфицировать максимальную интенсивность, допустимую для каждого из идентифицированных неразрешенных информационных потоков.

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

F.6.6. FDP_IFF.5 Отсутствие неразрешенных информационных потоков

F.6.6.1. Замечания по применению для пользователя

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

F.6.6.2. Операции

F.6.6.2.1. Назначение

В FDP_IFF.5.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления информационными потоками, для которой неразрешенные информационные потоки требуется устранить. Имя и область действия ПФБ управления информационными потоками определяют в компонентах семейства FDP_IFC "Политика управления информационными потоками".

F.6.7. FDP_IFF.6 Мониторинг неразрешенных информационных потоков

F.6.7.1. Замечания по применению для пользователя

Компонент FDP_IFF.6 следует использовать, если от ФБО требуется проведение мониторинга неразрешенных информационных потоков, интенсивность которых превышает специфицированное пороговое значение. Если такой поток требуется подвергнуть аудиту, то этот компонент может служить источником событий аудита для компонентов семейства FAU_GEN "Генерация данных аудита безопасности".

F.6.7.2. Операции

F.6.7.2.1. Назначение

В FDP_IFF.6.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления информационными потоками, осуществляемые ФБО. Имя и область действия ПФБ управления информационными потоками определяются в компонентах семейства FDP_IFC "Политика управления информационными потоками".

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

В FDP_IFF.6.1 автору ПЗ/ЗБ следует специфицировать максимальную интенсивность, превышение которой неразрешенным информационным потоком будет отслеживаться ФБО.

F.7. Импорт данных из-за пределов действия ФБО (FDP_ITC)

F.7.1. Замечания для пользователя

Семейство FDP_ITC определяет механизмы для импорта данных пользователя в ОО из-за пределов ОДФ так, чтобы атрибуты безопасности данных пользователя при этом сохранялись. Согласованность этих атрибутов безопасности определяется семейством FPT_tdC "Согласованность данных ФБО между ФБО".

В семействе FDP_ITC "Импорт данных из-за пределов действия ФБО" рассматриваются ограничения на импорт, спецификация атрибутов безопасности пользователем и ассоциация атрибутов безопасности и данных пользователя.

Семейство FDP_ITC и соответствующее семейство для экспорта данных FDP_ETC "Экспорт данных за пределы действия ФБО" определяют, как ОО обращается с данными пользователей, поступающими в ОДФ и передаваемыми из нее. Оно связано с назначением и игнорированием атрибутов безопасности данных пользователя.

В семействе могут рассматриваться следующие действия:

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

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

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

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

Существуют две возможности при импорте данных пользователя: либо они однозначно ассоциируются с достоверными атрибутами безопасности объекта (значения и смысл атрибутов безопасности не меняются), либо никакие достоверные атрибуты безопасности (или вообще какие-либо атрибуты безопасности) не могут быть получены от источника данных. В этом семействе рассмотрены обе возможности.

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

Семейство связано с импортом данных пользователя и сопровождением их ассоциации с атрибутами безопасности в соответствии с требованиями ПФБ. С аспектами импорта, которые находятся вне области действия этого семейства (например, с непротиворечивостью, доверенными каналами, целостностью), связаны другие семейства. Более того, в семействе FDP_ITC "Импорт данных из-за пределов действия ФБО" рассматривается только интерфейс для выполнения импорта. Участие в передаче с другой стороны (как источника) рассматривается в семействе FDP_ETC "Экспорт данных за пределы действия ФБО".

Хорошо известны следующие требования импорта:

a) импорт данных пользователя без каких-либо атрибутов безопасности;

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

Эти требования импорта могут быть реализованы ФБО при участии или без участия человека в соответствии с ограничениями ИТ и политикой безопасности организации. Например, если данные пользователя получены по "конфиденциальному" каналу, атрибуты безопасности объекта будут установлены как "конфиденциальные".

Если применяются несколько ПФБ управления доступом и/или информационными потоками, то может потребоваться повторить этот компонент отдельно для каждой политики (то есть применить к нему операцию итерации).

F.7.2. FDP_ITC.1 Импорт данных пользователя без атрибутов безопасности

F.7.2.1. Замечания по применению для пользователя

Компонент FDP_ITC.1 используется для спецификации импорта данных пользователя, не имеющих достоверных (или вообще никаких) атрибутов безопасности. Эта функция требует, чтобы атрибуты безопасности данных пользователя инициировались ФБО. Правила импорта может специфицировать и автор ПЗ/ЗБ. В некоторых средах может потребоваться использование для передачи этих атрибутов механизма доверенного маршрута или канала.

F.7.2.2. Операции

F.7.2.2.1. Назначение

В FDP_ITC.1.1 автору ПЗ/ЗБ следует специфицировать, какие ПФБ управления доступом и/или информационными потоками будут осуществляться при импорте данных пользователя в ОДФ. Данные пользователя, которые импортируются этой функцией, ограничиваются назначением этих ПФБ.

В FDP_ITC.1.3 автору ПЗ/ЗБ следует специфицировать все дополнительные правила управления импортом или указать "Нет" при отсутствии таковых. Эти правила будут реализованы ФБО в дополнение к ПФБ управления доступом и/или информационными потоками, выбранным в FDP_ITC.1.1.

F.7.3. FDP_ITC.2 Импорт данных пользователя с атрибутами безопасности

F.7.3.1. Замечания по применению для пользователя

Компонент FDP_ITC.2 используется для спецификации импорта данных пользователя, имеющих достоверные атрибуты безопасности, ассоциированные с ними. Эта функция использует атрибуты безопасности, точно и однозначно связанные с объектами на носителе импортируемых данных. После завершения импорта такие объекты будут иметь те же атрибуты безопасности. При этом требуется привлечение семейства FPT_tdC "Согласованность данных ФБО между ФБО" для обеспечения непротиворечивости данных. Правила импорта может специфицировать и автор ПЗ/ЗБ.

F.7.3.2. Операции

F.7.3.2.1. Назначение

В FDP_ITC.2.1 автору ПЗ/ЗБ следует специфицировать, какие ПФБ управления доступом и/или информационными потоками будут осуществляться при импорте данных пользователя в ОДФ. Данные пользователя, которые импортируются этой функцией, ограничиваются назначением ПФБ.

В FDP_ITC.2.5 автору ПЗ/ЗБ следует специфицировать все дополнительные правила управления импортом или указать "Нет" при их отсутствии. Эти правила будут реализованы ФБО в дополнение к ПФБ управления доступом и/или информационными потоками, выбранным в FDP_ITC.2.1.

F.8. Передача в пределах ОО (FDP_Itt)

F.8.1. Замечания для пользователя

Семейство FDP_Itt содержит требования, связанные с защитой данных пользователя при их передаче между различными частями ОО по внутреннему каналу. Этим данное семейство отличается от семейств FDP_UCT "Защита конфиденциальности данных пользователя при передаче между ФБО" и FDP_UIT "Защита целостности данных пользователя при передаче между ФБО", которые обеспечивают защиту данных пользователя при их передаче между различными ФБО по внешнему каналу, а также от семейств FDP_ETC "Экспорт данных за пределы действия ФБО" и FDP_ITC "Импорт данных из-за пределов действия ФБО", которые связаны с передачей данных за пределы или из-за пределов действия ФБО.

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

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

Если применяются несколько ПФБ управления доступом и/или информационными потоками, то может потребоваться повторить этот компонент отдельно для каждой именованной политики (то есть применить к нему операцию итерации).

F.8.2. FDP_Itt.1 Базовая защита внутренней передачи

F.8.2.1. Операции

F.8.2.1.1. Назначение

В FDP_Itt.1.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления доступом и/или информационными потоками, распространяющиеся на передаваемую информацию.

F.8.2.1.2. Выбор

В FDP_Itt.1.1 автору ПЗ/ЗБ следует специфицировать типы ошибок передачи, от которых следует защищать, используя ФБО, данные пользователя при их передаче. Варианты: раскрытие, модификация, недоступность.

F.8.3. FDP_Itt.2 Разделение передачи по атрибутам

F.8.3.1. Замечания по применению для пользователя

Компонент FDP_Itt.2 может быть использован, например, для обеспечения различных видов защиты информации в соответствии с различными уровнями критичности.

Одним из способов разделения данных при передаче является использование разделенных логических или физических каналов.

F.8.3.2. Операции

F.8.3.2.1. Назначение

В FDP_Itt.2.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления доступом и/или информационными потоками, распространяющиеся на передаваемую информацию.

F.8.3.2.2. Выбор

В FDP_Itt.2.1 автору ПЗ/ЗБ следует специфицировать типы ошибок передачи, от которых следует защищать, используя ФБО, данные пользователя при их передаче. Варианты: раскрытие, модификация, недоступность.

F.8.3.2.3. Назначение

В FDP_Itt.2.2 автору ПЗ/ЗБ следует специфицировать атрибуты безопасности, по значениям которых ФБО будут определять, когда данные, пересылаемые между физически разделенными частями ОО, требуют разделения. Например, данные пользователя, ассоциированные с идентификатором одного владельца, передаются отдельно от данных, ассоциированных с идентификаторами других владельцев. Тогда для определения необходимости разделения данных при передаче используется значение идентификатора их владельца.

F.8.4. FDP_Itt.3 Мониторинг целостности

F.8.4.1. Замечания по применению для пользователя

Компонент FDP_Itt.3 используется в сочетании с FDP_Itt.1 "Базовая защита внутренней передачи" или FDP_Itt.2 "Разделение передачи по атрибутам". Он обеспечивает, чтобы ФБО проверяли целостность полученных данных пользователя (и их атрибутов). Компоненты FDP_Itt.1 "Базовая защита внутренней передачи" или FDP_Itt.2 "Разделение передачи по атрибутам" предоставят данные способом, защищающим данные от модификации, а FDP_Itt.3 "Мониторинг целостности" позволит обнаружить некоторые из модификаций.

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

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

F.8.4.2. Операции

F.8.4.2.1. Назначение

В FDP_Itt.3.1 автору ПЗ/ЗБ следует специфицировать, какие ПФБ управления доступом и/или информационными потоками распространяются на передаваемую и проверяемую на ошибки целостности информацию.

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

В FDP_Itt.3.2 автору ПЗ/ЗБ следует специфицировать действия, предпринимаемые ФБО в случае обнаружения ошибки целостности. ФБО, например, могут запросить повторную передачу данных пользователя. ПФБ, специфицированные в FDP_Itt.3.1, будут осуществляться как действия, предпринимаемые ФБО.

F.8.5. FDP_Itt.4 Мониторинг целостности по атрибутам

F.8.5.1. Замечания по применению для пользователя

Компонент FDP_Itt.4 используется в сочетании с FDP_Itt.2 "Разделение передачи по атрибутам". Он обеспечивает, чтобы ФБО проверяли целостность полученных данных пользователя, переданных по разделенным каналам (в соответствии со значениями специфицированных атрибутов безопасности). Компонент позволяет автору ПЗ/ЗБ специфицировать действия, предпринимаемые в случае обнаружения ошибки целостности.

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

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

Автору ПЗ/ЗБ следует специфицировать атрибуты (и ассоциированные с ними каналы передачи), требующие мониторинга ошибок целостности.

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

F.8.5.2. Операции

F.8.5.2.1. Назначение

В FDP_Itt.4.1 автору ПЗ/ЗБ следует специфицировать, какие ПФБ управления доступом и/или информационными потоками распространяются на передаваемую и проверяемую на ошибки целостности информацию.

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

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

В FDP_Itt.4.2 автору ПЗ/ЗБ следует специфицировать действия, предпринимаемые ФБО в случае обнаружения ошибки целостности. ФБО, например, могут запросить повторную передачу данных пользователя. ПФБ, специфицированные в FDP_Itt.4.1, будут осуществляться как действия, предпринимаемые ФБО.

F.9. Защита остаточной информации (FDP_RIP)

F.9.1. Замечания для пользователя

Семейство FDP_RIP связано с необходимостью обеспечения последующей недоступности удаленной информации и отсутствия во вновь созданных объектах информации из объектов, ранее использовавшихся в ОО. Это семейство не применяется к объектам, хранимым автономно.

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

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

Семейство FDP_RIP "Защита остаточной информации" обычно связано с доступом к информации, не являющейся частью объекта, который определен в данный момент, или к которому осуществляется доступ; однако это правило не всегда соблюдается. Пусть, например, объект A является файлом, а объект B - диском, на котором размещается этот файл. Когда объект А удален, доступ к его остаточной информации определяется семейством FDP_RIP "Защита остаточной информации", хотя она все еще остается частью объекта B.

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

Семейства FDP_RIP "Защита остаточной информации" и FDP_ROL "Откат" могут вступать в конфликт, если в первом отображено требование уничтожения остаточной информации во время передачи объекта от приложения к функциям безопасности (то есть при освобождении объекта). Поэтому результат выполнения операции выбора "недоступность при освобождении ресурса" в FDP_RIP "Защита остаточной информации" нельзя совместить с использованием FDP_ROL "Откат" из-за возможного отсутствия информации, необходимой для отката в предыдущее состояние. В этом случае в FDP_RIP "Защита остаточной информации" следует выбрать "недоступность при распределении ресурса", что позволяет использовать FDP_ROL "Откат", хотя существует риск, что ресурс, содержавший информацию, распределен новому объекту до выполнения отката. Если это произойдет, то откат будет невозможен.

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

Это семейство следует применять к объектам, специфицированным в ПФБ управления доступом или информационными потоками автором ПЗ/ЗБ.

F.9.2. FDP_RIP.1 Ограниченная защита остаточной информации

F.9.2.1. Замечания по применению для пользователя

Компонент FDP_RIP.1 содержит требование, что ФБО будут обеспечивать для подмножества объектов ОО отсутствие в распределенном этим объектам или освобожденном ими ресурсе доступной остаточной информации.

F.9.2.2. Операции

F.9.2.2.1. Выбор

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

F.9.2.2.2. Назначение

В FDP_RIP.1.1 автору ПЗ/ЗБ следует привести список объектов, для которых выполняется защита остаточной информации.

F.9.3. FDP_RIP.2 Полная защита остаточной информации

F.9.3.1. Замечания по применению для пользователя

Компонент FDP_RIP.2 содержит требование, что ФБО будут обеспечивать для всех объектов ОО отсутствие в распределенном этим объектам или освобожденном ими ресурсе доступной остаточной информации.

F.9.3.2. Операции

F.9.3.2.1. Выбор

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

F.10. Откат (FDP_ROL)

F.10.1. Замечания для пользователя

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

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

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

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

F.10.2. FDP_ROL.1 Базовый откат

F.10.2.1. Замечания по применению для пользователя

Компонент FDP_ROL.1 позволяет пользователю или субъекту отменять некоторую совокупность операций над предопределенным множеством объектов. Отмена возможна только в некоторых пределах, например, на некоторое число символов или в определенном интервале времени.

F.10.2.2. Операции

F.10.2.2.1. Назначение

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

В FDP_ROL.1.1 автору ПЗ/ЗБ следует специфицировать список операций, допускающих откат.

В FDP_ROL.1.1 автору ПЗ/ЗБ следует специфицировать типы информации и/или список объектов, к которым применима политика отката.

В FDP_ROL.1.2 автору ПЗ/ЗБ следует специфицировать ограничение, в рамках которого могут выполняться операции отката. Это может быть интервал времени, например, могут быть отменены операции, выполненные в течение последних двух минут. Другими возможными ограничениями могут быть максимальное число отменяемых операций или размер буфера.

F.10.3. FDP_ROL.2 Расширенный откат

F.10.3.1. Замечания по применению для пользователя

Компонент FDP_ROL.2 содержит требование, чтобы ФБО предоставляли возможность отката всех операций, однако пользователь может выбрать для отката только часть из них.

F.10.3.2. Операции

F.10.3.2.1. Назначение

В FDP_ROL.2.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления доступом и/или ПФБ управления информационными потоками, которые будут осуществляться при выполнении операций отката. Это необходимо для того, чтобы удостовериться, что откат не используется для обхода специфицированных ПФБ.

В FDP_ROL.2.1 автору ПЗ/ЗБ следует специфицировать список объектов, к которым применима политика отката.

В FDP_ROL.2.2 автору ПЗ/ЗБ следует специфицировать ограничение, в рамках которого могут выполняться операции отката. Это может быть интервал времени, например, могут быть отменены операции, выполненные в течение последних двух минут. Другими возможными ограничениями могут быть максимальное число отменяемых операций или размер буфера.

F.11. Целостность хранимых данных (FDP_SDI)

F.11.1. Замечания для пользователя

Семейство FDP_SDI содержит требования, связанные с защитой данных пользователя во время их хранения в пределах ОДФ.

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

Для предотвращения модификации данных субъектом требуется вместо этого семейства использовать семейства FDP_IFF "Функции управления информационными потоками" или FDP_ACF "Функции управления доступом".

FDP_SDI отличается от семейства FDP_Itt "Передача в пределах ОО", которое защищает данные пользователя от ошибок целостности во время их передачи в пределах ОО.

F.11.2. FDP_SDI.1 Мониторинг целостности хранимых данных

F.11.2.1. Замечания по применению для пользователя

Компонент FDP_SDI.1 контролирует появление ошибок целостности данных, хранимых на носителе. Автор ПЗ/ЗБ может специфицировать различные типы атрибутов данных пользователя, на которых будет основан мониторинг.

F.11.2.2. Операции

F.11.2.2.1. Назначение

В FDP_SDI.1.1 автору ПЗ/ЗБ следует специфицировать ошибки целостности, которые будут выявлять ФБО.

В FDP_SDI.1.1 автору ПЗ/ЗБ следует специфицировать атрибуты данных пользователя, которые будут использоваться как основа для мониторинга.

F.11.3. FDP_SDI.2 Мониторинг целостности хранимых данных и предпринимаемые действия

F.11.3.1. Замечания по применению для пользователя

Компонент FDP_SDI.2 контролирует появление ошибок целостности данных, хранимых на носителе. Автор ПЗ/ЗБ может специфицировать, какие действия следует предпринять при обнаружении ошибок целостности.

F.11.3.2. Операции

F.11.3.2.1. Назначение

В FDP_SDI.2.1 автору ПЗ/ЗБ следует специфицировать ошибки целостности, которые будут выявлять ФБО.

В FDP_SDI.2.1 автору ПЗ/ЗБ следует специфицировать атрибуты данных пользователя, которые будут использоваться как основа для мониторинга.

В FDP_SDI.2.2 автору ПЗ/ЗБ следует специфицировать действия, предпринимаемые при обнаружении ошибки целостности.

F.12. Защита конфиденциальности данных пользователя при передаче между ФБО (FDP_UCT)

F.12.1. Замечания для пользователя

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

Это семейство содержит требование защиты данных пользователя при передаче, тогда как семейство FPT_ITC "Конфиденциальность экспортируемых данных ФБО" имеет дело с данными ФБО.

F.12.2. FDP_UCT.1 Базовая конфиденциальность обмена данными

F.12.2.1. Замечания по применению для пользователя

ФБО имеют возможность защитить от раскрытия некоторые данные пользователя во время обмена.

F.12.2.2. Операции

Е.12.2.2.1. Назначение

В FDP_UCT.1.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления доступом и/или информационными потоками, которые будут осуществляться при обмене данными пользователя. Указанные политики будут осуществляться для принятия решений о том, кто и какими данными может обмениваться.

F.12.2.2.2. Выбор

В FDP_UCT.1.1 автору ПЗ/ЗБ следует определить, применяется этот элемент к механизму отправления или получения данных пользователя.

F.13. Защита целостности данных пользователя при передаче между ФБО (FDP_UIT)

F.13.1. Замечания для пользователя

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

Данное семейство определяет требования по обеспечению целостности данных пользователя при передаче, тогда как семейство FPT_ITI "Целостность экспортируемых данных ФБО" имеет дело с данными ФБО.

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

F.13.2. FDP_UIT.1 Целостность передаваемых данных

Е.13.2.1. Замечания по применению для пользователя

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

F.13.2.2. Операции

F.13.2.2.1. Назначение

В FDP_UIT.1.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления доступом и/или информационными потоками, которые будут осуществляться при обмене данными пользователя. Указанные политики будут осуществляться для принятия решений о том, кто может отправлять или получать данные и какие именно данные могут быть отправлены или получены.

F.13.2.2.2. Выбор

В FDP_UIT.1.1 автору ПЗ/ЗБ следует определить, применять ли этот элемент к ФБО при отправлении или получении объектов.

В FDP_UIT.1.1 автору ПЗ/ЗБ следует определить, защищать ли данные от модификации, удаления, вставки или повторения.

В FDP_UIT.1.2 автору ПЗ/ЗБ следует определить, обнаруживать ли ошибки типа модификации, удаления, вставки или повторения.

F.13.3. FDP_UIT.2 Восстановление переданных данных источником

F.13.3.1. Замечания по применению для пользователя

Компонент FDP_UIT.2 предоставляет возможность исправления совокупности идентифицированных ошибок передачи, если требуется, то с помощью другого доверенного продукта ИТ. Поскольку другой доверенный продукт ИТ находится за пределами ОДФ, ФБО не могут управлять режимом его функционирования. Тем не менее, в целях восстановления возможно предоставление функций, обладающих способностью выполняться координировано с другим доверенным продуктом ИТ. ФБО, например, могут включать в себя функции, способные побудить доверенный продукт ИТ, являющийся источником, повторить передачу данных после обнаружения ошибки. Этот компонент связан с возможностью ФБО реализовать такое восстановление при ошибках.

F.13.3.2. Операции

F.13.3.2.1. Назначение

В FDP_UIT.2.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления доступом и/или информационными потоками, которые будут осуществляться при обмене данными пользователя. Указанные политики будут осуществляться для принятия решений о том, какие данные и каким образом могут восстанавливаться.

В FDP_UIT.2.1 автору ПЗ/ЗБ следует привести список ошибок целостности, после которых ФБО с помощью доверенного продукта ИТ, являющегося источником, в состоянии восстановить первоначальное содержание данных пользователя.

F.13.4. FDP_UIT.3 Восстановление переданных данных получателем

F.13.4.1. Замечания по применению для пользователя

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

F.13.4.2. Операции

F.13.4.2.1. Назначение

В FDP_UIT.3.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления доступом и/или информационными потоками, которые будут осуществляться при обмене данными пользователя. Указанные политики будут осуществляться для принятия решений о том, какие данные и каким образом могут восстанавливаться.

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

Приложение G
(обязательное)

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

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

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

Семейство FIA_UID "Идентификация пользователя" предназначено для определения идентификатора пользователя.

Семейство FIA_UAU "Аутентификация пользователя" предназначено для верификации идентификатора пользователя.

Семейство FIA_AFL "Отказы аутентификации" предназначено для определения ограничений на число повторных неуспешных попыток аутентификации.

Семейство FIA_Atd "Определение атрибутов пользователя" предназначено для определения атрибутов пользователей, применяемых при осуществлении ПБО.

Семейство FIA_USB "Связывание пользователь-субъект" предназначено для корректной ассоциации атрибутов безопасности для каждого уполномоченного пользователя.

Семейство FIA_SOS "Спецификация секретов" предназначено для генерации и верификации секретов, соответствующих установленной метрике.

Декомпозиция класса FIA "Идентификация и аутентификация" на составляющие его компоненты показана на рисунке G.1.

Рисунок G.1. Декомпозиция класса FIA "Идентификация и аутентификация"

G.1. Отказы аутентификации (FIA_AFL)

G.1.1. Замечания для пользователя

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

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

G.1.2. FIA_AFL.1 Обработка отказов аутентификации

G.1.2.1. Замечания по применению для пользователя

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

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

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

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

G.1.2.2. Операции

G.1.2.2.1. Выбор

В FIA_AFL.1.1 автор ПЗ/ЗБ должен выбрать или назначение положительного целого числа, или выражение "устанавливаемое администратором положительное целое число", определив диапазон допустимых значений.

G.1.2.2.2. Назначение

В FIA_AFL.1.1 автору ПЗ/ЗБ следует специфицировать события аутентификации. Примерами являются: число неуспешных попыток аутентификации для данного идентификатора пользователя с момента последней успешной попытки; число неуспешных попыток аутентификации для данного терминала с момента последней успешной попытки; число неуспешных попыток аутентификации за последние 10 мин. Необходимо указать, по меньшей мере, одно событие аутентификации.

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

В FIA_AFL.1.1, если выбрано "устанавливаемое администратором положительное целое число", то автору ПЗ/ЗБ следует специфицировать диапазон допустимых значений, из которого администратор ОО может установить число неудачных попыток аутентификации. Число неудачных попыток аутентификации должно быть меньше или равняться значению верхней границы и больше или равняться значению нижней границы диапазона.

    В   FIA_AFL.1.2   автору   ПЗ/ЗБ   следует   специфицировать  действия,\r\nпредпринимаемые  в  случае  достижения  или превышения предельного значения\r\nчисла попыток. Такими действиями могут быть: блокирование учетных данных на\r\n5  мин.,  блокирование терминала на увеличивающийся интервал времени (число\r\n                  n\r\nсекунд,  равное  2 ,  где n - число неуспешных попыток) или блокирование (с\r\nуведомлением   администратора)   учетных   данных   вплоть  до  его  снятия\r\nадминистратором.  В  описании  действий  следует указать принимаемые меры и\r\nсрок их действия (или условия прекращения действия этих мер).

G.2. Определение атрибутов пользователя (FIA_Atd)

G.2.1. Замечания для пользователя

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

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

G.2.2. FIA_Atd.1 Определение атрибутов пользователя

G.2.2.1. Замечания по применению для пользователя

Компонент FIA_Atd.1 специфицирует атрибуты безопасности, которые следует поддерживать на уровне пользователя. Это означает, что назначение и возможное изменение атрибутов безопасности, указанных в списке, осуществляется на уровне пользователя (то есть для каждого пользователя индивидуально). Иными словами, изменение атрибутов из списка, ассоциированного с каким-либо пользователем, не должно влиять на атрибуты безопасности других пользователей.

Если атрибуты безопасности принадлежат группе пользователей (например, список возможностей группы), пользователю потребуется иметь ссылку (как атрибут безопасности) на соответствующую группу.

G.2.2.2. Операции

G.2.2.2.1. Назначение

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

G.3. Спецификация секретов (FIA_SOS)

G.3.1. Замечания для пользователя

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

Секреты могут генерироваться вне ОО, например, выбираться пользователями и вводиться в систему. При этом может быть использован компонент FIA_SOS.1 "Верификация секретов" для обеспечения соответствия секретов, сгенерированных вне системы, конкретным условиям, таким как минимально допустимый размер, отсутствие в словаре и/или неприменение ранее.

Секреты могут также генерироваться самим ОО. В этом случае требование, чтобы сгенерированные ОО секреты соответствовали специфицированной метрике, обеспечивается компонентом FIA_SOS.2 "Генерация секретов ФБО".

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

G.3.2. FIA_SOS.1 Верификация секретов

G.3.2.1. Замечания по применению для пользователя

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

G.3.2.2. Операции

G.3.2.2.1. Назначение

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

G.3.3. FlA_SOS.2 Генерация секретов ФБО

G.3.3.1. Замечания по применению для пользователя

Компонент FIA_SOS.2 позволяет ФБО генерировать секреты для специальных функций, таких как аутентификация по паролю.

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

G.3.3.2. Операции

G.3.3.2.1. Назначение

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

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

G.4. Аутентификация пользователя (FIA_UAU)

G.4.1. Замечания для пользователя

Семейство FIA_UAU определяет типы механизмов аутентификации пользователя, предоставляемые ФБО. Оно также определяет те атрибуты, на которых необходимо базировать механизмы аутентификации пользователя.

G.4.2. FIA_UAU.1 Выбор момента аутентификации

G.4.2.1. Замечания по применению для пользователя

Компонент FIA_UAU.1 содержит требование, чтобы автор ПЗ/ЗБ определил список действий, которые выполняются при посредничестве ФБО и допускаются ФБО от имени пользователя до того, как будет произведена аутентификация пользователя. Эти действия, выполняемые при посредничестве ФБО, с точки зрения безопасности не имеют отношения к пользователям, неверно идентифицировавшим себя до аутентификации. Все прочие действия, выполняемые при посредничестве ФБО и не включенные в этот список, разрешаются пользователю только после завершения аутентификации.

Этот компонент не применим для разрешения каких-либо действий до выполнения идентификации. Для этого необходимо использовать FIA_UID.1 "Выбор момента идентификации" либо FIA_UID.2 "Идентификация до любого действия пользователя" с соответствующими назначениями.

G.4.2.2. Операции

G.4.2.2.1. Назначение

В FIA_UAU.1.1 автору ПЗ/ЗБ следует специфицировать список действий, выполняемых при посредничестве ФБО от имени пользователя прежде, чем завершится аутентификация пользователя. Этот список не может быть пустым. Если таких действий нет, следует вместо этого компонента использовать компонент FIA_UAU.2 "Аутентификация до любых действий пользователя". Примером таких действий может служить запрос о помощи при выполнении процедуры логического входа в систему.

G.4.3. FIA_UAU.2 Аутентификация до любых действий пользователя

G.4.3.1. Замечания по применению для пользователя

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

G.4.4. FIA_UAU.3 Аутентификация, защищенная от подделок

G.4.4.1. Замечания по применению для пользователя

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

Этот компонент применим только для механизмов аутентификации, основанных на уникальных аутентификационных данных (например, биометрических). ФБО не смогут обнаружить и предотвратить тиражирование пароля за пределами ОДФ.

G.4.4.2. Операции

G.4.4.2.1. Выбор

В FIA_UAU.3.1 автору ПЗ/ЗБ следует специфицировать, будут ли ФБО обнаруживать и/или предотвращать подделку данных аутентификации.

В FIA_UAU.3.2 автору ПЗ/ЗБ следует специфицировать, будут ли ФБО обнаруживать и/или предотвращать копирование данных аутентификации.

G.4.5. FIA_UAU.4 Механизмы одноразовой аутентификации

G.4.5.1. Замечания по применению для пользователя

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

Автор ПЗ/ЗБ может определить, к какому механизму(ам) аутентификации применимы эти требования.

G.4.5.2. Операции

G.4.5.2.1. Назначение

В FIA_UAU.4.1 автору ПЗ/ЗБ следует привести список механизмов аутентификации, к которым применяется это требование. Назначением может быть: "все механизмы аутентификации". Примером назначения может быть также следующее: "механизмы аутентификации, используемые для аутентификации пользователей во внешней сети".

G.4.6. FIA_UAU.5 Сочетание механизмов аутентификации

G.4.6.1. Замечания по применению для пользователя

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

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

Для допуска в систему анонимных пользователей можно ввести механизм аутентификации типа "отсутствие аутентификации". Использование доступа такого типа следует четко разъяснить в правилах FIA_UAU.5.2.

G.4.6.2. Операции

G.4.6.2.1. Назначение

В FIA_UAU.5.1 автору ПЗ/ЗБ следует определить предоставляемые механизмы аутентификации. Примером списка механизмов может быть следующий: "отсутствие аутентификации, механизм пароля, биометрия (сканирование сетчатки), механизм ключа шифрования".

В FIA_UAU.5.2 автору ПЗ/ЗБ следует специфицировать правила, описывающие, как механизмы аутентификации обеспечивают аутентификацию и когда используется каждый из них. Это значит, что для любой возможной ситуации необходимо указать совокупность механизмов, которые могли бы использоваться для аутентификации. Пример такого правила: "для аутентификации пользователей, имеющих особые права доступа, должны совместно использоваться механизм пароля и биометрия, причем аутентификация успешна при успешной аутентификации каждым механизмом; для аутентификации остальных пользователей должен использоваться только механизм пароля".

Автор ПЗ/ЗБ может задать ограничения, в пределах которых уполномоченному администратору разрешено специфицировать конкретные правила. Пример правила: "аутентификация пользователя всегда должна производиться посредством аппаратного ключа; администратор может специфицировать дополнительные механизмы аутентификации, которые также необходимо использовать". Автор ПЗ/ЗБ может и не специфицировать ограничения, а оставить выбор механизмов аутентификации и их правил полностью на усмотрение уполномоченного администратора.

G.4.7. FIA_UAU.6 Повторная аутентификация

G.4.7.1. Замечания по применению для пользователя

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

G.4.7.2. Операции

G.4.7.2.1. Назначение

В FIA_UAU.6.1 автору ПЗ/ЗБ следует привести список условий, требующих повторной аутентификации. Этот список может включать в себя завершение периода времени, выделенного пользователю, запрос пользователя с целью изменения действующих атрибутов безопасности или запрос пользователя к ФБО с целью выполнения некоторых критичных функций безопасности.

Автор ПЗ/ЗБ может задать пределы, в которых следует допускать повторную аутентификацию, оставив их детализацию на усмотрение уполномоченного администратора. Пример подобного правила: "пользователь должен проходить повторную аутентификацию не реже одного раза в сутки; администратор может потребовать более частую повторную аутентификацию, но не чаще одного раза в 10 мин.".

G.4.8. FIA_UAU.7 Аутентификация с защищенной обратной связью

G.4.8.1. Замечания по применению для пользователя

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

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

G.4.8.2. Операции

G.4.8.2.1. Назначение

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

G.5. Идентификация пользователя (FIA_UID)

G.5.1. Замечания для пользователя

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

G.5.2. FIA_UID.1 Выбор момента идентификации

G.5.2.1. Замечания по применению для пользователя

Компонент FIA_UID.1 устанавливает требования по идентификации пользователей. Автор ПЗ/ЗБ может указать конкретные действия, которые могут быть выполнены до завершения идентификации.

При использовании компонента упоминаемые в нем действия, которые допускается выполнять при посредничестве ФБО до идентификации, следует также привести и в компоненте FIA_UAU.1 "Выбор момента аутентификации".

G.5.2.2. Операции

G.5.2.2.1. Назначение

В FIA_UID.1.1 автору ПЗ/ЗБ следует специфицировать список действий, выполняемых при посредничестве ФБО от имени пользователя до его собственной идентификации. Этот список не может быть пустым. Если приемлемых действий нет, следует вместо этого компонента использовать компонент FIA_UID.2 "Идентификация до любого действия пользователя". Примером таких действий может служить запрос о помощи при выполнении процедуры логического входа в систему.

G.5.3. FIA_UID.2 Идентификация до любых действий пользователя

G.5.3.1. Замечания по применению для пользователя

Компонент FIA_UID.2 содержит требование идентификации пользователей. До идентификации пользователя ФБО не допускают выполнение им никаких действий.

G.6. Связывание пользователь-субъект (FIA_USB)

G.6.1. Замечания для пользователя

Для работы с ОО аутентифицированный пользователь обычно активизирует какой-либо субъект. Тогда атрибуты безопасности этого пользователя ассоциируются (полностью или частично) с этим субъектом. Семейство FIA_USB определяет требования по созданию и сопровождению ассоциации атрибутов безопасности пользователя с субъектом, действующим от имени пользователя.

G.6.2. FIA_USB.1 Связывание пользователь-субъект

G.6.2.1. Замечания по применению для пользователя

Выражение "действующий от имени", использовавшееся и ранее, требует некоторых пояснений. Установлено, что субъект действует от имени пользователя, создавшего субъект или активизировавшего его для решения некоторой задачи. Поэтому, когда субъект создается, то он действует от имени пользователя, инициировавшего его создание. Если пользователь предпочитает анонимность, субъект также действует от его имени, но идентификатор этого пользователя неизвестен. Особую категорию составляют субъекты, которые обслуживают нескольких пользователей (например, серверный процесс). Тогда "владельцем" этого субъекта считается пользователь, создавший его.

G.6.2.2. Операции

G.6.2.2.1. Назначение

В FIA_USB.1 автору ПЗ/ЗБ следует специфицировать список атрибутов безопасности пользователя, которые должны быть связаны с субъектами.

В FIA_USB.1.2 автору ПЗ/ЗБ следует специфицировать какие-либо правила, которые должны применяться по отношению к исходной ассоциации атрибутов с субъектами, или слово "нет".

В FIA_USB.1.3 автору ПЗ/ЗБ следует специфицировать какие-либо правила, которые должны применяться при внесении изменений в атрибуты безопасности пользователей, связанные с субъектами, действующими от имени пользователей, или слово "нет".

Приложение H
(обязательное)

Класс FMT предназначен для спецификации управления некоторыми аспектами ФБО: атрибутами безопасности, данными и отдельными функциями. Могут быть также установлены различные роли управления и определено их взаимодействие, например, распределение обязанностей.

Если ОО состоит из нескольких физически разделенных частей, образующих распределенную систему, то проблемы синхронизации, относящиеся к распространению атрибутов безопасности, данных ФБО и модификации функций, становятся очень сложными, особенно, если требуется дублирование информации в различных частях ОО. Эти проблемы следует принять во внимание при выборе компонентов FMT_REV.1 "Отмена" и FMT_SAE.1 "Ограниченная по времени авторизация", поскольку при этом возможно нарушение нормального выполнения ФБО. В такой ситуации рекомендуется воспользоваться компонентами семейства FPT_trC "Согласованность данных ФБО при дублировании в пределах ОО".

Декомпозиция класса FMT "Управление безопасностью" на составляющие его компоненты показана на рисунке H.1.

Рисунок H.1. Декомпозиция класса FMT "Управление безопасностью"

H.1. Управление отдельными функциями ФБО (FMT_MOF)

H.1.1. Замечания для пользователя

Функции управления из числа ФБО дают уполномоченным пользователям возможность устанавливать операции безопасности ОО и управлять ими. Эти административные функции обычно подразделяют на несколько категорий:

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

b) функции управления, относящиеся к контролю доступности, например, определение и модификация параметров доступности или квот ресурсов;

c) функции управления, связанные в основном с инсталляцией и конфигурацией, например, конфигурация ОО, ручное восстановление, инсталляция исправлений, относящихся к безопасности ОО (при их наличии), восстановление и реинсталляция аппаратных средств;

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

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

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

H.1.2. FMT_MOF.1 Управление режимом выполнения функций безопасности

H.1.2.1 Замечания по применению для пользователя

Компонент FMT_MOF.1 предоставляет идентифицированным ролям возможность управления функциями из числа ФБО. Может потребоваться выяснить текущее состояние функции безопасности, отключить или подключить функцию безопасности, модифицировать режим ее выполнения. Примером модификации режима выполнения является изменение механизмов аутентификации.

H.1.2.2. Операции

H.1.2.2.1. Выбор

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

H.1.2.2.2. Назначение

В FMT_MOF.1.1 автору ПЗ/ЗБ следует специфицировать функции, которые могут быть модифицированы идентифицированными ролями. Примерами таких функций являются функции аудита или определения времени.

В FMT_MOF.1.1 автору ПЗ/ЗБ следует специфицировать роли, которые допускаются к модификации функций из числа ФБО. Все возможные роли специфицированы в FMT_SMR.1 "Роли безопасности".

H.2. Управление атрибутами безопасности (FMT_MSA)

H.2.1. Замечания для пользователя

Семейство FMT_MSA определяет требования по управлению атрибутами безопасности.

У пользователей, субъектов и объектов есть ассоциированные атрибуты безопасности, которые оказывают влияние на режим выполнения ФБО. Примерами атрибутов безопасности являются группы, в которые входит пользователь, роли, которые он может принимать, приоритет процесса (субъекта), а также права, которыми наделены роль или пользователь. Может возникнуть необходимость в управлении этими атрибутами безопасности со стороны пользователя, субъекта или специально уполномоченного пользователя (пользователя с явно предоставленными правами для такого управления).

Следует отметить, что право на назначение прав пользователям само по себе является атрибутом безопасности и/или потенциальным субъектом управления в компоненте FMT_MSA.1 "Управление атрибутами безопасности".

Компонент FMT_MSA.2 "Безопасные значения атрибутов безопасности" можно использовать для обеспечения того, что выбранное сочетание атрибутов безопасности находится в рамках безопасного состояния. Определение, что понимать как "безопасное", возлагается на руководства ОО и модель ПБО. Если разработчик предоставил четкое определение безопасных значений и доводы, почему их следует считать безопасными, зависимостью FMT_MSA.2 "Безопасные значения атрибутов безопасности" от ADV_SPM.1 "Неформальная модель политики безопасности ОО" можно пренебречь.

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

H.2.2. FMT_MSA.1 Управление атрибутами безопасности

H.2.2.1. Замечания по применению для пользователя

Компонент FMT_MSA.1 допускает пользователей, исполняющих некоторые роли, к управлению идентифицированными атрибутами безопасности. Принятие роли пользователем осуществляется в компоненте FMT_SMR.1 "Роли безопасности".

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

H.2.2.2. Операции

H.2.2.2.1. Назначение

В FMT_MSA.1.1 автору ПЗ/ЗБ следует указать ПФБ управления доступом или информационными потоками, для которой применимы атрибуты безопасности.

H.2.2.2.2. Выбор

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

H.2.2.2.3. Назначение

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

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

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

H.2.3. FMT_MSA.2 Безопасные значения атрибутов безопасности

H.2.3.1. Замечания по применению для пользователя

Компонент FMT_MSA.2 содержит требования к значениям, которые могут присваиваться атрибутам безопасности. Следует присваивать такие значения, чтобы ОО оставался в безопасном состоянии.

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

H.2.4. FMT_MSA.3 Инициализация статических атрибутов

H.2.4.1. Замечания по применению для пользователя

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

H.2.4.2. Операции

H.2.4.2.1. Назначение

В FMT_MSA.3.1 автору ПЗ/ЗБ следует указать ПФБ управления доступом или информационными потоками, для которой применимы атрибуты безопасности.

H.2.4.2.2. Выбор

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

H.2.4.2.3. Назначение

В FMT_MSA.3.1, если автор ПЗ/ЗБ выбирает другое свойство, то ему следует специфицировать требуемые характеристики значений по умолчанию.

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

H.3. Управление данными ФБО (FMT_Mtd)

H.3.1. Замечания для пользователя

Семейство FMT_Mtd устанавливает требования по управлению данными ФБО. Примерами данных ФБО являются текущее время и журнал аудита. Например, данное семейство дает возможность специфицировать, кому разрешено читать, удалять или создавать журнал аудита.

H.3.2. FMT_Mtd.1 Управление данными ФБО

H.3.2.1. Замечания по применению для пользователя

Компонент FMT_Mtd.1 позволяет пользователям, которым присвоены определенные роли, управлять значениями данных ФБО. Назначение пользователей на роль рассмотрено в компоненте FMT_SMR.1 "Роли безопасности".

"Задаваемым по умолчанию" называется значение параметра, которое он принимает, если отображается без специально указанного значения. Начальное же значение предоставляется при отображении (создании) параметра, замещая заданное по умолчанию.

H.3.2.2. Операции

H.3.2.2.1. Выбор

В FMT_Mtd.1.1 автору ПЗ/ЗБ следует специфицировать операции, которые могут быть применены к идентифицированным данным ФБО. Автор ПЗ/ЗБ может специфицировать, что роль может изменять заданные по умолчанию значения, выполнять очистку, чтение, модификацию или полное удаление данных ФБО. По желанию автор ПЗ/ЗБ может специфицировать какой-либо тип операции. "Очистка данных ФБО" означает, что содержание данных удаляется, но категория данных остается в системе.

H.3.2.2.2. Назначение

В FMT_Mtd.1.1 автору ПЗ/ЗБ следует специфицировать, какими данными ФБО могут оперировать идентифицированные роли. Допускается, что автор ПЗ/ЗБ специфицирует возможность управления значениями, задаваемыми по умолчанию.

В FMT_Mtd.1.1 автору ПЗ/ЗБ следует специфицировать роли, допущенные к операциям с данными ФБО. Все возможные роли специфицируют в FMT_SMR.1 "Роли безопасности".

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

H.3.3. FMT_Mtd.2 Управление ограничениями данных ФБО

H.3.3.1. Замечания по применению для пользователя

Компонент FMT_Mtd.2 специфицирует граничные значения для данных ФБО и действия, предпринимаемые в случае их превышения. Могут быть указаны, например, допустимый объем журнала аудита и действия при его переполнении.

H.3.3.2. Операции

H.3.3.2.1. Назначение

В FMT_Mtd.2.1 автору ПЗ/ЗБ следует специфицировать данные ФБО, имеющие ограничения, и значения этих ограничений. Примером таких данных ФБО является число пользователей, осуществивших вход в систему.

В FMT_Mtd.2.1 автору ПЗ/ЗБ следует специфицировать роли, допущенные к модификации как ограничений данных ФБО, так и действий в случае нарушения ограничений. Все возможные роли специфицированы в FMT_SMR.1 "Роли безопасности".

В FMT_Mtd.2.2 автору ПЗ/ЗБ следует специфицировать действия, предпринимаемые в случае превышения предельных значений специфицированных данных ФБО. Примером таких действий, выполняемых ФБО, является информирование уполномоченного администратора и генерация записи аудита.

H.3.4. FMT_Mtd.3 Безопасные данные ФБО

H.3.4.1. Замечания по применению для пользователя

Компонент FMT_Mtd.3 распространяется на требования к значениям, которые могут присваиваться данным ФБО. Следует присваивать такие значения, чтобы ОО оставался в безопасном состоянии.

Определение "безопасных" значений в этом компоненте не раскрывается и оставлено для разработчика ОО (конкретно для компонента ADV_SPM.1 "Неформальная модель политики безопасности ОО") и руководств. Если разработчик предоставил четкое определение безопасных значений и объяснение, почему их следует считать безопасными, зависимостью FMT_Mtd.3 "Безопасные данные ФБО" от ADV_SPM.1 "Неформальная модель политики безопасности ОО" можно пренебречь.

H.4. Отмена (FMT_REV)

H.4.1. Замечания для пользователя

Семейство FMT_REV связано с отменой атрибутов безопасности различных сущностей в пределах ОО.

H.4.2. FMT_REV.1 Отмена

H.4.2.1. Замечания по применению для пользователя

В компоненте FMT_REV.1 специфицируются требования по отмене прав. Он содержит требование спецификации правил отмены, например:

a) отмена произойдет при следующем входе пользователя в систему;

b) отмена произойдет при следующей попытке открыть файл;

c) отмена произойдет по истечении установленного времени, что может означать пересмотр всех открытых соединений через каждые X минут.

H.4.2.2. Операции

H.4.2.2.1. Выбор

В FMT_REV.1.1 автору ПЗ/ЗБ следует специфицировать, должна ли быть предоставлена возможность отменять с использованием ФБО атрибуты безопасности пользователей, субъектов, объектов или каких-либо дополнительных ресурсов.

H.4.2.2.2. Назначение

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

В FMT_REV.1.1 автору ПЗ/ЗБ следует, если выбраны дополнительные ресурсы, специфицировать, должна ли быть предоставлена возможность отменять атрибуты безопасности с использованием ФБО.

В FMT_REV.1.2 автору ПЗ/ЗБ следует специфицировать правила отмены. К правилам, в частности, могут быть отнесены: "перед следующей операцией над ассоциированным ресурсом" или "при создании каждого нового субъекта".

H.5. Срок действия атрибутов безопасности (FMT_SAE)

H.5.1. Замечания для пользователя

Семейство FMT_SAE связано с возможностью установления срока действия атрибутов безопасности. Оно может применяться при спецификации требований к сроку действия атрибутов управления доступом, атрибутов идентификации и аутентификации, сертификатов (например, сертификатов ключей по X509), атрибутов аудита и т.д.

H.5.2. FMT_SAE.1 Ограниченная по времени авторизация

H.5.2.1. Операции

H.5.2.1.1. Назначение

В FMT_SAE.1.1 автору ПЗ/ЗБ следует представить список атрибутов безопасности, для которых поддерживается ограничение срока действия. Примером такого атрибута является уровень допуска пользователя.

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

В FMT_SAE.1.2 автору ПЗ/ЗБ следует представить список действий, предпринимаемых по отношению к каждому атрибуту безопасности по истечении срока его действия. Примером является назначение уровню допуска пользователя, по истечении срока его действия, значения, минимального для данного ОО. Если в ПЗ/ЗБ предусматривается немедленная отмена, то следует специфицировать действие "немедленная отмена".

H.6. Спецификация функций управления (FMT_SMF)

H.6.1. Замечания для пользователя

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

H.6.2. FMT_SMF.1 Спецификация функций управления

H.6.2.1. Замечания по применению для пользователя

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

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

H.6.2.2. Операции

H.6.2.2.1. Назначение

В FMT_SMF.1 автору ПЗ/ЗБ следует специфицировать функции управления, предоставляемые ФБО для управления атрибутами безопасности либо для управления данными ФБО, либо для управления функциями безопасности.

H.7. Роли управления безопасностью (FMT_SMR)

H.7.1. Замечания для пользователя

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

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

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

Все роли данного семейства связаны с безопасностью. Каждая роль может предоставлять широкие возможности (например, доступ ко всей структуре UNIX) или незначительные права (например, право чтения объектов единственного типа, таких как файл помощи). Все роли определяют в этом семействе. Возможности ролей определяют в семействах FMT_MOF "Управление отдельными функциями ФБО", FMT_MSA "Управление атрибутами безопасности" и FMT_Mtd "Управление данными ФБО".

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

H.7.2. FMT_SMR.1 Роли безопасности

H.7.2.1. Замечания по применению для пользователя

Компонент FMT_SMR.1 определяет различные роли, которые ФБО следует распознавать. В системах часто проводится различие между владельцем сущности, администратором и остальными пользователями.

H.7.2.2. Операции

H.7.2.2.1. Назначение

В FMT_SMR.1.1 автору ПЗ/ЗБ следует специфицировать роли, которые распознаются системой. Это роли, которые могут исполнять пользователи относительно безопасности. Примеры ролей: владелец, аудитор, администратор.

H.7.3. FMT_SMR.2 Ограничения на роли безопасности

H.7.3.1. Замечания по применению для пользователя

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

Условия, налагаемые на роли, определяют взаимоотношения различных ролей, а также ограничения на принятие роли пользователем.

H.7.3.2. Операции

H.7.3.2.1. Назначение

В FMT_SMR.2.1 автору ПЗ/ЗБ следует специфицировать роли, которые распознаются системой. Это роли, которые могут исполнять пользователи относительно безопасности. Примеры ролей: владелец, аудитор, администратор.

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

H.7.4. FMT_SMR.3 Принятие ролей

H.7.4.1. Замечания по применению для пользователя

Компонент FMT_SMR.3 определяет, что для принятия некоторых ролей необходим явный запрос.

H.7.4.2. Операции

H.7.4.2.1. Назначение

В FMT_SMR.3.1 автору ПЗ/ЗБ следует специфицировать роли, для принятия которых требуется явный запрос. Примеры: аудитор и администратор.

Приложение I
(обязательное)

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

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

Класс FPR вместе с другими классами (содержащими требования аудита, управления доступом, предоставления доверенного маршрута и неотказуемости) обеспечивает гибкость при спецификации желательного режима приватности. В то же время требования этого класса могут налагать ограничения на использование компонентов других классов, таких как FIA "Идентификация и аутентификация" или FAU "Аудит безопасности". Например, если уполномоченным пользователям не разрешено знать идентификатор пользователя (например, в семействах "Анонимность" или "Псевдонимность"), то, очевидно, невозможно будет оставить отдельных пользователей ответственными за выполняемые ими относящиеся к безопасности действия, на которые распространяются требования приватности. Тем не менее и в этом случае возможно включение в ПЗ/ЗБ требований аудита, если возникновение некоторых событий, связанных с безопасностью, важнее, чем знание о том, кто был их инициатором.

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

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

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

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

Необходимо, чтобы ФБО предоставляли защиту от действий не только отдельных пользователей, но и пользователей, объединившихся для получения определенной информации. Стойкость защиты, предоставляемой этим классом, следует описать как стойкость функции в соответствии с ИСО/МЭК 15408-1, приложения A и B.

Декомпозиция класса FPR "Приватность" на составляющие его компоненты показана на рисунке I.1.

Рисунок I.1. Декомпозиция класса FPR "Приватность"

I.1. Анонимность (FPR_ANO)

I.1.1. Замечания для пользователя

Семейство FPR_ANO обеспечивает возможность использования субъектом ресурсов или услуг без раскрытия идентификатора его пользователя.

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

Следовательно, если субъект, пользуясь анонимностью, выполняет некоторое действие, другой субъект будет не в состоянии определить ни идентификатор, ни даже ссылку на идентификатор пользователя, использовавшего первый субъект. Анонимность сфокусирована на защите идентификатора пользователя, а не на защите идентификатора субъекта. Поэтому идентификатор субъекта не защищен от раскрытия.

Хотя идентификатор пользователя не разглашается другим субъектам или пользователям, ФБО прямо не запрещено узнавать идентификатор пользователя. Если не допускается, чтобы ФБО был известен идентификатор пользователя, то можно прибегнуть к компоненту FPR_ANO.2 "Анонимность". В этом случае ФБО не разрешается запрашивать информацию о пользователе.

Термин "определить" следует понимать в самом широком смысле слова. Для конкретизации требований к строгости автор ПЗ/ЗБ может воспользоваться понятием стойкости функций.

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

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

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

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

I.1.2. FPR_ANO.1 Анонимность

I.1.2.1. Замечания по применению для пользователя

Компонент FPR_ANO.1 обеспечивает, чтобы идентификатор пользователя был защищен от раскрытия. Однако в некоторых случаях уполномоченный пользователь может определять, кто произвел определенные действия. Этот компонент дает возможность гибкого подхода, позволяя выбирать политику как ограниченной, так и полной приватности.

I.1.2.2. Операции

I.1.2.2.1. Назначение

В FPR_ANO.1.1 автору ПЗ/ЗБ следует специфицировать совокупность пользователей и/или субъектов, от которых ФБО необходимо предоставить защиту. Например, даже если автор ПЗ/ЗБ специфицирует единственную роль пользователя или субъекта, ФБО необходимо предоставить защиту не только от отдельного пользователя или субъекта, но и от совместно действующих пользователей и/или субъектов. Например, совокупность пользователей может являться группой пользователей, выступающих в одной и той же роли или использующих одни и те же процессы.

В FPR_ANO.1.1 автору ПЗ/ЗБ следует идентифицировать список субъектов и/или операций, и/или объектов, для которых подлинное имя пользователя данного субъекта следует защитить, например, "голосование".

I.1.3. FPR_ANO.2 Анонимность без запроса информации

I.1.3.1. Замечания по применению для пользователя

Компонент FPR_ANO.2 используется для обеспечения того, что ФБО не будет разрешено знать идентификатор пользователя.

I.1.3.2. Операции

I.1.3.2.1. Назначение

В FPR_ANO.2.1 автору ПЗ/ЗБ следует специфицировать совокупность пользователей и/или субъектов, от которых ФБО необходимо предоставить защиту. Например, даже если автор ПЗ/ЗБ специфицирует единственную роль пользователя или субъекта, ФБО необходимо предоставить защиту не только от отдельного пользователя или субъекта, но и от совместно действующих пользователей и/или субъектов. Совокупность пользователей, например, может являться группой пользователей, выступающих в одной и той же роли или использующих одни и те же процессы.

В FPR_ANO.2.1 автору ПЗ/ЗБ следует идентифицировать список субъектов и/или операций, и/или объектов, для которых подлинное имя пользователя данного субъекта следует защитить, например, "голосование".

В FPR_ANO.2.2 автору ПЗ/ЗБ следует идентифицировать список услуг, на которые распространяется требование анонимности, например, "доступ к описанию работ".

В FPR_ANO.2.2 автору ПЗ/ЗБ следует идентифицировать список субъектов, для которых подлинные имена пользователей необходимо защитить при предоставлении специфицированных услуг.

I.2. Псевдонимность (FPR_PSE)

I.2.1. Замечания для пользователя

Семейство FPR_PSE обеспечивает, чтобы пользователь мог использовать ресурс или услугу без раскрытия своего идентификатора, оставаясь в то же время ответственным за это использование. Пользователь может быть ответственным, будучи прямо связан со ссылкой (псевдонимом), предоставляемой ФБО, или с псевдонимом, таким как номер банковского счета, используемым для целей обслуживания.

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

Компонент FPR_PSE.1 "Псевдонимность" не специфицирует требований, относящихся к ссылке на идентификатор пользователя. Эти требования имеются в компонентах FPR_PSE.2 "Обратимая псевдонимность" и FPR_PSE.3 "Альтернативная псевдонимность".

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

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

Применяя упомянутые выше конструкции, с помощью FPR_PSE.2 можно ввести электронные деньги, установив требование защиты идентификатора пользователя от наблюдения при условии, что одна и та же электронная сумма не тратится дважды. В последнем случае идентификатор пользователя будет отслеживаться. Следовательно, если пользователь ведет себя честно, его идентификатор защищен, если же он пытается мошенничать, его идентификатор может быть отслежен.

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

Следует иметь в виду, что наиболее строгие компоненты данного семейства могут потенциально не сочетаться с другими возможными требованиями, такими как идентификация и аутентификация или аудит. Выражение "определить идентификатор" следует понимать в широком смысле, а именно: ФБО не предоставляют информацию при выполнении операции; нельзя определить создателя субъекта или владельца субъекта, вызвавшего операцию; ФБО не будут записывать такую информацию, доступную пользователям или субъектам, по которой в дальнейшем можно бы было узнать идентификатор пользователя.

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

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

Примерами потенциально враждебных пользователей являются провайдеры, системные операторы, абоненты связи и пользователи, скрытно вводящие в систему опасные элементы (например, "троянские кони"). Все эти нарушители могут изучать, какие пользователи какие услуги заказывают, и злоупотреблять этой информацией. В дополнение к семейству "Анонимность" услуги, предоставляемые семейством "Псевдонимность", содержат методы авторизации без идентификации, особенно при анонимной оплате ("электронные деньги"). Это помогает провайдерам получать платежи безопасным способом, поддерживая при этом анонимность клиентов.

I.2.2. FPR_PSE.1 Псевдонимность

I.2.2.1. Замечания по применению для пользователя

Компонент FPR_PSE.1 обеспечивает защиту пользователя от раскрытия его идентификатора другими пользователями. При этом пользователь останется ответственным за свои действия.

I.2.2.2. Операции

I.2.2.2.1. Назначение

В FPR_PSE.1.1 автору ПЗ/ЗБ следует специфицировать совокупность пользователей и/или субъектов, от которых ФБО необходимо предоставить защиту. Например, даже если автор ПЗ/ЗБ специфицирует единственную роль пользователя или субъекта, ФБО необходимо предоставить защиту не только от отдельного пользователя или субъекта, но и от совместно действующих пользователей и/или субъектов. Например, совокупность пользователей может являться группой пользователей, выступающих в одной и той же роли или использующих одни и те же процессы.

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

В FPR_PSE.1.2 автору ПЗ/ЗБ следует идентифицировать число псевдонимов (один или более), которое ФБО способны предоставить.

В FPR_PSE.1.2 автору ПЗ/ЗБ следует идентифицировать список субъектов, которым ФБО способны предоставлять псевдонимы.

I.2.2.2.2. Выбор

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

I.2.2.2.3. Назначение

В FPR_PSE.1.3 автору ПЗ/ЗБ следует идентифицировать метрику, которой удовлетворял бы псевдоним, созданный ФБО или выбранный пользователем.

I.2.3. FPR_PSE.2 Обратимая псевдонимность

I.2.3.1. Замечания по применению для пользователя

В компоненте FPR_PSE.2 ФБО должны обеспечить, чтобы при специфицированных условиях по предоставленной ссылке мог быть определен идентификатор пользователя.

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

I.2.3.2. Операции

I.2.3.2.1. Назначение

В FPR_PSE.2.1 автору ПЗ/ЗБ следует специфицировать совокупность пользователей и/или субъектов, от которых ФБО необходимо предоставить защиту. Например, даже если автор ПЗ/ЗБ специфицирует единственную роль пользователя или субъекта, ФБО необходимо предоставить защиту не только от отдельного пользователя или субъекта, но и от совместно действующих пользователей и/или субъектов. Например, совокупность пользователей может являться группой пользователей, выступающих в одной и той же роли или использующих одни и те же процессы.

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

В FPR_PSE.2.2 автору ПЗ/ЗБ следует идентифицировать число псевдонимов (один или более), которое ФБО способны предоставить.

В FPR_PSE.2.2 автору ПЗ/ЗБ следует идентифицировать список субъектов, которым ФБО способны предоставлять псевдонимы.

I.2.3.2.2. Выбор

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

I.2.3.2.3. Назначение

В FPR_PSE.2.3 автору ПЗ/ЗБ следует идентифицировать метрику, которой удовлетворял бы псевдоним, созданный ФБО или выбранный пользователем.

I.2.3.2.4. Выбор

В FPR_PSE.2.4 автору ПЗ/ЗБ следует идентифицировать, могут ли уполномоченный пользователь и/или доверенные субъекты определить подлинное имя пользователя.

I.2.3.2.5. Назначение

В FPR_PSE.2.4 автору ПЗ/ЗБ следует идентифицировать список условий, при которых доверенные субъекты и уполномоченный пользователь могут определить подлинное имя пользователя на основе предоставленной ссылки. Такими условиями может быть "время суток" или же правовое условие, например, предъявление судебного постановления.

В FPR_PSE.2.4 автору ПЗ/ЗБ следует идентифицировать список доверенных субъектов (например, "нотариус" или "пользователь, имеющий специальное разрешение"), которые могут при определенных условиях узнать подлинное имя пользователя.

I.2.4. FPR_PSE.3 Альтернативная псевдонимность

I.2.4.1. Замечания по применению для пользователя

В компоненте FPR_PSE.3 ФБО должны обеспечить, чтобы предоставленная ссылка отвечала определенным правилам ее создания и вследствие этого могла использоваться потенциально опасными субъектами без нарушения безопасности.

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

I.2.4.2. Операции

I.2.4.2.1. Назначение

В FPR_PSE.3.1 автору ПЗ/ЗБ следует специфицировать совокупность пользователей и/или субъектов, от которых ФБО необходимо предоставить защиту. Например, даже если автор ПЗ/ЗБ специфицирует единственную роль пользователя или субъекта, ФБО необходимо предоставить защиту не только от отдельного пользователя или субъекта, но и от совместно действующих пользователей и/или субъектов. Например, совокупность пользователей может являться группой пользователей, выступающих в одной и той же роли или использующих один и тот же процесс.

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

В FPR_PSE.3.2 автору ПЗ/ЗБ следует идентифицировать число псевдонимов (один или более), которое ФБО способны предоставить.

В FPR_PSE.3.2 автору ПЗ/ЗБ следует идентифицировать список субъектов, которым ФБО способны предоставлять псевдонимы.

I.2.4.2.2. Выбор

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

I.2.4.2.3. Назначение

В FPR_PSE.3.3 автору ПЗ/ЗБ следует идентифицировать метрику, которой удовлетворял бы псевдоним, созданный ФБО или выбранный пользователем.

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

I.3. Невозможность ассоциации (FPR_UNL)

I.3.1. Замечания для пользователя

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

Требования невозможности ассоциации предназначены для защиты идентификатора пользователя от применения профиля операций. Например, телефонная компания может определить поведение пользователя телефонной карты, используемой с единственного номера. Если известны профили использования телефона группой пользователей, то карту можно связать с конкретным пользователем. Сокрытие связи между различными обращениями за услугой или за доступом к ресурсу предотвратит накопление подобной информации.

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

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

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

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

I.3.2. FPR_UNL.1 Невозможность ассоциации

I.3.2.1. Замечания по применению для пользователя

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

I.3.2.2. Операции

I.3.2.2.1. Назначение

В FPR_UNL.1.1 автору ПЗ/ЗБ следует специфицировать совокупность пользователей и/или субъектов, от которых ФБО необходимо предоставить защиту. Например, даже если автор ПЗ/ЗБ специфицирует единственную роль пользователя или субъекта, ФБО необходимо предоставить защиту не только от отдельного пользователя или субъекта, но и от совместно действующих пользователей и/или субъектов. Например, совокупность пользователей может являться группой пользователей, выступающих в одной и той же роли или использующих один и тот же процесс.

В FPR_UNL.1.1 автору ПЗ/ЗБ следует идентифицировать список операций, на которые следует распространить требование невозможности ассоциации, например, "отправка электронной почты".

I.3.2.2.2. Выбор

В FPR_UNL.1.1 автору ПЗ/ЗБ следует выбрать взаимосвязи, которые следует скрыть. Этот выбор позволяет специфицировать идентификатор пользователя либо операцию назначения списка соотношений.

I.3.2.2.3. Назначение

В FPR_UNL.1.1 автору ПЗ/ЗБ следует идентифицировать список соотношений, которые следует защищать, например, "посланные с одного и того же терминала".

I.4. Скрытность (FPR_UNO)

I.4.1. Замечания для пользователя

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

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

Для реализации скрытности могут быть применены различные методы. Примеры некоторых из них:

a) размещение информации, влияющее на скрытность. Информацию, которую необходимо скрыть (например, указывающую на выполнение операции), можно разместить в ОО различными способами. Место ее размещения в ОО можно выбирать случайно, чтобы нарушитель не знал, какую именно часть ОО следует атаковать. Данную информацию можно распределить так, чтобы ни в одной части ОО ее не было достаточно для нарушения приватности пользователя. Этот способ рассматривается в компоненте FPR_UNO.2 "Распределение информации, влияющее на скрытность";

b) массовое распространение информации (по локальной сети, по радио). Пользователи не могут определить, кто конкретно получил и использовал данную информацию. Этот метод особенно полезен в случае, если информацию следует довести до того, кто опасается показывать свою заинтересованность в данной информации (например, чувствительной медицинской информации);

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

Иногда пользователей не следует допускать к наблюдению за использованием ресурсов, а уполномоченным пользователям такое наблюдение необходимо для исполнения своих обязанностей. В этом случае может применяться компонент FPR_UNO.4 "Открытость для уполномоченного пользователя", который предоставляет эту возможность одному или нескольким уполномоченным пользователям.

В данном семействе используется понятие "часть ОО". Под ней подразумевается какая-либо часть ОО, отделенная физически или логически от других частей ОО. В случае логического отделения может быть уместно применение семейства FPT_SEP "Разделение домена".

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

I.4.2. FPR_UNO.1 Скрытность

I.4.2.1. Замечания по применению для пользователя

Компонент FPR_UNO.1 содержит требования недопустимости наблюдения неуполномоченными пользователями за использованием услуги или ресурса. Дополнительно к этому компоненту автору ПЗ/ЗБ может потребоваться "Анализ скрытых каналов".

I.4.2.2. Операции

I.4.2.2.1. Назначение

В FPR_UNO.1.1 автору ПЗ/ЗБ следует специфицировать совокупность пользователей и/или субъектов, от которых ФБО необходимо предоставить защиту. Например, даже если автор ПЗ/ЗБ специфицирует единственную роль пользователя или субъекта, ФБО необходимо предоставить защиту не только от отдельного пользователя или субъекта, но и от совместно действующих пользователей и/или субъектов. Например, совокупность пользователей может являться группой пользователей, выступающих в одной и той же роли или использующих одни и те же процессы.

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

В FPR_UNO.1.1 автору ПЗ/ЗБ следует идентифицировать список объектов, на которые распространяется требование скрытности. Примером может быть конкретный сервер электронной почты или FTP-сайт.

В FPR_UNO.1.1 автору ПЗ/ЗБ следует специфицировать совокупность защищаемых пользователей и/или субъектов, скрытность информации которых будет обеспечиваться. Примером может быть: "пользователи, получившие доступ к системе через Интернет".

I.4.3. FPR_UNO.2 Распределение информации, влияющее на скрытность

I.4.3.1. Замечания по применению для пользователя

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

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

Более сложный пример связан с некоторыми "алгоритмами голосования". В предоставлении услуги принимают участие несколько частей ОО, но никакая отдельная часть ОО не сможет нарушить принятую политику. Какое-либо лицо может принять (или не принять) участие в голосовании; при этом невозможно без использования ОО определить результат голосования и его участие в голосовании (если голосование не было единогласным).

В дополнение к этому компоненту автору ПЗ/ЗБ может потребоваться "Анализ скрытых каналов".

I.4.3.2. Операции

I.4.3.2.1. Назначение

В FPR_UNO.2.1 автору ПЗ/ЗБ следует специфицировать совокупность пользователей и/или субъектов, от которых ФБО необходимо предоставить защиту. Например, даже если автор ПЗ/ЗБ специфицирует единственную роль пользователя или субъекта, ФБО необходимо предоставить защиту не только от отдельного пользователя или субъекта, но и от совместно действующих пользователей и/или субъектов. Например, совокупность пользователей может являться группой пользователей, выступающих в одной и той же роли или использующих одни и те же процессы.

В FPR_UNO.2.1 автору ПЗ/ЗБ следует идентифицировать список операций, на которые распространяется требование скрытности. Тогда другие пользователи/субъекты не смогут наблюдать за операциями над объектом из специфицированного списка (например, за чтением и записью).

В FPR_UNO.2.1 автору ПЗ/ЗБ следует идентифицировать список объектов, на которые распространяется требование скрытности. Примером может быть конкретный сервер электронной почты или FTP-сайт.

В FPR_UNO.2.1 автору ПЗ/ЗБ следует специфицировать совокупность пользователей и/или субъектов, скрытность информации которых будет обеспечиваться, например, "пользователи, получившие доступ к системе через Интернет".

В FPR_UNO.2.2 автору ПЗ/ЗБ следует идентифицировать, распределение какой информации, связанной с приватностью, следует контролировать. Примером такой информации являются IP-адрес субъекта, IP-адрес объекта, время, используемые криптографические ключи.

В FPR_UNO.2.2 автору ПЗ/ЗБ следует специфицировать условия распространения указанной информации. Эти условия следует поддерживать все время существования приватной информации пользователя в каждом случае. Примерами таких условий могут быть следующие: "информация должна быть представлена только в одной из разделенных частей ОО и не должна передаваться за ее пределы"; "информация должна пребывать только в одной из разделенных частей ОО, но должна передаваться в другие его части периодически"; "информация должна распределяться между различными частями ОО так, чтобы нарушение защиты любых пяти отдельных частей ОО не приводило к нарушению политики безопасности в целом".

I.4.4. FPR_UNO.3 Скрытность без запроса информации

I.4.4.1. Замечания по применению для пользователя

Компонент FPR_UNO.3 применяется для требования, чтобы ФБО не стремились получить информацию, которая может нарушить скрытность при предоставлении определенных услуг. Поэтому ФБО не будут запрашивать (то есть стремиться получить из других источников) информацию, которая может быть использована для нарушения скрытности.

I.4.4.2. Операции

I.4.4.2.1. Назначение

В FPR_UNO.3.1 автору ПЗ/ЗБ следует идентифицировать список услуг, на которые распространяется требование скрытности, например, "доступ к описанию работ".

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

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

I.4.5. FPR_UNO.4 Открытость для уполномоченного пользователя

I.4.5.1. Замечания по применению для пользователя

Компонент FPR_UNO.4 применяется для предоставления права наблюдения за использованием ресурсов одному или нескольким уполномоченным пользователям. Без этого компонента возможность наблюдения допускается, но не является обязательной.

I.4.5.2. Операции

I.4.5.2.1. Назначение

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

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

Приложение J
(обязательное)

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

В рамках данного класса выделяются три важные составные части ФБО:

1) абстрактная машина ФБО, то есть виртуальная или физическая машина, на которой выполняется оцениваемая реализация ФБО;

2) реализация ФБО, которая выполняется на абстрактной машине и реализует механизмы, осуществляющие ПБО;

3) данные ФБО, которые являются административными базами данных, управляющими осуществлением ПБО.

Все семейства в классе FPT "Защита ФБО" можно связать с этими тремя частями и сгруппировать следующим образом:

a) FPT_PHP "Физическая защита ФБО" предоставляет уполномоченному пользователю возможность обнаружения внешних атак на те части ОО, которые реализуют ФБО;

b) FPT_AMT "Тестирование базовой абстрактной машины" и FPT_TST "Самотестирование ФБО" предоставляют уполномоченному пользователю возможность верифицировать правильность операций базовой абстрактной машины и ФБО, а также целостность данных и выполняемого кода ФБО;

c) FPT_SEP "Разделение домена" и FPT_RVM "Посредничество при обращениях" защищают ФБО во время их выполнения и обеспечивают невозможность обхода ФБО. Если соответствующие компоненты этих семейств сочетаются с соответствующими компонентами семейства ADV_INT "Внутренняя структура ФБО", можно говорить о наличии в ОО традиционного "монитора обращений";

d) FPT_RCV "Надежное восстановление", FPT_FLS "Безопасность при сбое" и FPT_trC "Согласованность данных ФБО при дублировании в пределах ОО" определяют режим выполнения ФБО при возникновении сбоя и непосредственно после него;

e) FPT_ITA "Доступность экспортируемых данных ФБО", FPT_ITC "Конфиденциальность экспортируемых данных ФБО" и FPT_ITI "Целостность экспортируемых данных ФБО" определяют защиту и доступность данных ФБО при их обмене между ФБО и удаленным доверенным продуктом ИТ;

f) FPT_Itt "Передача данных ФБО в пределах ОО" предназначено для защиты данных ФБО при их передаче между физически разделенными частями ОО;

g) FPT_RPL "Обнаружение повторного использования" содержит требование защиты от повторного использования различных типов информации и/или операций;

h) FPT_SSP "Протокол синхронизации состояний" определяет синхронизацию состояний между различными частями распределенных ФБО на основе данных ФБО;

i) FPT_STM "Метки времени" предоставляет надежные метки времени;

j) FPT_tdC "Согласованность данных ФБО между ФБО" предназначено для согласования данных между ФБО и удаленным доверенным продуктом ИТ.

Декомпозиция класса FPT "Защита ФБО" на составляющие его компоненты показана на рисунке J.1.