Технические условия ГОСТ Р ИСО/МЭК 15408-2-2002 Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные требования безопасности

ГОСТ Р ИСО/МЭК 15408-2-2002

ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационная технология

МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ КРИТЕРИИ ОЦЕНКИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

Часть 2

Функциональные требования безопасности

Издание официальное

БЗ 6-2001/139

ГОССТАНДАРТ РОССИ И Москва

Предисловие

1 РАЗРАБОТАН Центром безопасности информации. 4 ЦНИИ Министерства обороны РФ. Центром «Атомзатитаинформ». ЦНИИАТОМИНФОРМ. ВНИИстандартпри участии экспертов Международной рабочей группы по Общим критериям

ВНЕСЕН Гостехкомиссией России. Техническими комитетами по стандарти зации ТК 362Р «Зашита информации» и ТК 22 «Информационные технологии»

2ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от4 апреля 2002 г. № 133-ст

3 Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК 15408-2—99 «Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные требования безопасности»
4 ВВЕДЕН ВПЕРВЫЕ

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

Содержание

1 Область применения………………………………
- 1.1 Расширение и сопровождение функциональных требований……………
- 1.2 Структура…………………………………
- 1.3 Парадигма функциональных требований……………………..
2 Функциональные компоненты безопасности…………………….
- 2.1 Краткий обзор……………………………….
- 2.2 Каталог компонентов……………………………..
3 Класс FAU. Аудит безопасности………………………….
- 3.1 Автоматическая реакция аудита безопасности (FAU_ARP)…………….
- 3.2 Генерация данных аудита безопасности (FAU_GEN)……………….
- 3.3 Анализ аудита безопасности (FAU_SAA)……………………
- 3.4 Просмотр аудита безопасности (FAU_SAR)…………………..
- 3.5 Выбор событий аудита безопасности (FAU_SEL)………………..
- 3.6 Хранение данных аудита безопасности (FAU_STG)……………….
4 Класс FCO. Связь………………………………
- 4.1 Неотказуемость отправления (FCO NRO)…………………..
- 4.2 Неотказуемость получения (FCO_NRR)……………………
5 Класс FCS. Криптографическая поддержка…………………….
- 5.1 Управление крипго1рафичсскими ключами (FCS^CKM)……………..
- 5.2 Криптографические операции (FCS_COP)…………………..
6 Класс FDP. Зашита данных пользователя …………………….
- 6.1 Политика управления доступом (FDP ACC)………………….
- 6.2 Функции управления доступом (FDP_ACF)………………….
- 6.3 Аутентификация данных (FDP DAU)…………………….
- 6.4 Экспорт данных за пределы действия ФБО (FDP_ETC)……………..
- 6.5 Политика управления информационными потоками (FDP IFC)………….
- 6.6 Функции управления информационными потоками (FDPJFF)………….
- 6.7 Импорт данных из-за пределов действия ФБО (FDP_1TC) …………..
- 6.8 Передача в пределах 00 (FDP ITT)……………………..
- 6.9 Зашита остаточной информации (FDP_R1P)………………….
- 6.10 Откат (FDP ROL)…………………………….
- 6.11 Целостностьхранимы.хланных(ЕОР SDI)…………………..
- 6.12 Зашита конфиденциальности данных пользователя при передаче между ФБО (FDP_UCT)
- 6.13 Зашита целостности данных пользователя при передаче между ФБО (FDP_UIT)…..
7 Класс FIA. Идентификация и аутентификация…………………..
- 7.1 Отказы аутентификации (FIA AFL)……………………..
- 7.2 Определение атрибутов пользователя (FIA_ATD)………………..
- 7.3 Спецификация секретов (FIASOS)……………………..
- 7.4 Аутентификация пользователя (FIA_UAU)……………………
- 7.5 Идентификация пользователя (FIA UID)……………………
- 7.6 Связывание пользователь—субъект (FIA_USB)…………………
8 Класс F.V1T. Управление безопасностью……………………..
- 8.1 Управление отдельными функциями ФБО (FMT_MOF)……………..
- 8.2 Управление атрибутами безопасности (FMT MSA)………………..
- 8.3 Управление данными ФБО (FMT_\1TD)……………………

8.4Отмена (FMT REV)…………………………….

8.5 Срок действия атрибута безопасности (FMT_SAE)………………..
8.6 Рази управления бе зопасностью (FMT SMR)…………………..

9 Класс FPR. Приватность…………………………….
- 9.1 Анонимность (FPRANO)………………………….
- 9.2 Псевдонимность(РРК_Р5Е)…………………………
- 9.3 Невозможность ассоциации (FPR_UNL)…………………….
- 9.4 Скрытность (FPR_UNO)………………………….
  
  1
  
  2
  
  2
  
  6
  
  6
  
  10
  12
  - 13
  - 14
  16
  
  17
  
  17
  
  19
  - 19
  - 20
  22
  
  22
  
  24
  
  24
  
  26
  - 27
  - 28
  - 29
  - 30
  - 31
  - 34
  - 35
  - 37
  - 38
  38
  
  40
  
  40
  - 42
  - 43
  - 43
  - 44
  - 45
  - 47
  - 48
  - 49
  - 50
  - 50
  - 51
  53
  - 53
  - 54
  - 55
  - 56
  - 56
  - 57
  - 58
10 Класс FPT. Защита ФБО
- 10.1 Тестирование базовой абстрактной машины (FPT_AMT)
- 10.2 Безопасность при сбое (FH*_FLS)
- 10.3 Доступность экспортируемых данных ФБО (FPT_ITA)
- 10.4 Конфиденциальность экспортируемых данных ФБО (FPT_ITC)
- 10.5 Целостность экспортируемых данных ФБО (FPT_1TI)
- 10.6 Передача данных ФБО в пределах ОО (FPT_ITT)
- 10.7 Физическая зашита ФБО (FPT PHP)
- 10.8 Надежное восстановление (FPT_RCV)
- 10.9 Обнаружение повторного использования (FPT_RPL)
- 10.10 Посредничество при обращениях (FPT_RVM)
- 10.11 Разделение домена (FPT SEP)
- 10.12 Протокол синхронизации состояний (FPT_SSP)
- 10.13 Метки времени (FPT_STM)
- 10.14 Согласованность данных ФБО между ФБО (FPT_TDC)
- 10.15 Согласованность данных ФБО при дублировании в пределах ОО (FPT_TRC)
- 10.16 Самотестирование ФБО (FPT_TST)
11 Класс FRU. Использование ресурсов
- 11.1 Отказоустойчивость (FRUFLT)
- 11.2 Приоритет обслуживания (FRU_PRS)
- 11.3 Распределение ресурсов (FRU_RSA)
12 Класс FTA. Доступ к ОО
- 12.1 Ограничение области выбираемых атрибутов (FTA__LSA)
- 12.2 Ограничение на параллельные сеансы (FTA_.MCS)
- 12.3 Блокирование сеанса (FTA_SSL)
- 12.4 Предупреждения перед предоставлением доступа к ОО (FTA_TAB)
- 12.5 История доступа к ОО (FTA_TAH)

12.6OrKpbiTHeccaHcacOO(FTA_TSE)

13 Класс FTP. Доверенный маршрут/канал
- 13.1 Доверенный канал передачи между ФБО (FTP_ITC)
- 13.2 Доверенный маршрут (FTP.TRP)

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

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

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

Приложение Б Функциональные классы, семейства и компоненты

Приложение В Аудит безопасност (FAU)

B. 1 Автоматическая реакция аудита безопасности (FAU ARP)

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

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

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

В.5 Выбор событий аудита безопасности (FAIJ_SEL)

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

Приложение Г Связь (FCO)

Г.1 Неотказуемость отравления (FCO NRO)

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

Приложение Д Криптографическая поддержка (FCS)

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

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

Приложение Е Защита данных пользователя (FDP)

ЕЛ Политика управления доступом (FDP АСС)

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

Е.З Аутентификация данных (FDP^DAU)

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

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

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

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

Е.8 Передача в пределах OO(FDP_ITT)

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

ЕЛО Откат (FDP_ROL)

ЕЛ1 Ue.iocTHOCTbxpaHnMi>ixaaHHbix(FDP_SDI)

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

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

Приложение Ж Идентификация и аутентификация (FIА)

Ж.1 Отказы аутентификации (FIA AFL)

Ж.2 Определение атрибутов пользователя (FIA.ATD)

Ж.З Спецификация секретов (F1A SOS)

Ж.4 Аутентификация пользователя (FIA UAU)

Ж.5 Идентификация пользователя (FIA-UID)

Ж.6 Связывание пользователь-субъект (FIA USB)

Приложение И Управление безопасностью (FMT)

ИЛ Управление отдельными функциями ФБО (FMT_MOF)

И.2 Управление атрибутами безопасности (FMT_MSA)

И.З Управление данными ФБО (ГМТ_МТП)

И.4 Отмена (FMTREV)

И.5 Срок действия атрибутов безопасности (FMT_SAE)

И.6 Роли управления безопасностью (FMT_SMR)

Приложение К Приватность(FPR)

К.1 Анонимность (FPR_ANO)

К.2 nceajoHHMHocTb(FPR PSE)

К.З Невозможность ассоциации (FPR_UNL)

К.4 Скрытность (FPR UNO)

Приложение Л Защита ФБО (FPT)

Л.1 Тестирование базовой абстрактной машины (FPT АМТ)

Л.2 Безопасность при сбое (FPT_FLS)

Л.З Доступность экспортируемых данных ФБО(БРТ_1ТА)

Л.4 Конфиденциальность экспортируемых данных ФБО (FPT_ITC)

Л.5 Целостность экспортируемых данных ФБО (FPT_1TI)

Л.6 Передача данных ФБО в пределах ОО (FPT ITT?

Л.7 Физическая зашита ФБО (FPT PHP) . . 7

Л.8 Надежное восстановление (FPT_RCV)

Л.9 Обнаружение повторного использования (FPT_RPL)

Л.10 Посредничество при обращениях (FPT_RVM)

Л. 11 Разделение домена (FPT SEP)

Л.12 Протокол синхронизации состояний (FPT_SSP)

Л.13 Метки времени (FPT STM)

Л. 14 Согласованность данных ФБО между ФБО (FPT_TDC)

Л Л 5 Согласованность данных ФБО при дублировании в пределах ОО (FPT.TRC)

Л.16 Самотестирование ФБО (FPT_TST)

Приложение М Использование ресурсов (FRU)

МЛ Отказоустойчивость (FRU_FLT)

М.2 Приоритет обслуживания (FRU..PRS)

М.З Распределение ресурсов (FRU RSA)

Приложение Н Доступ к ОО (FTA)

Н.1 Ограничение области выбираемых атрибутов (FTA_LSA)

Н.2 Ограничение на параллельные сеансы (FTA_MCS)

Н.З Блокирование сеанса (FTA SSL)

Н.4 Предупреждения перед предоставлением доступа к ОО (FTAJTAB)

Н.5 История доступа к ОО (FTA ТАН)

Н.6 Открытие сеанса с ОО (FTA TSE)

Приложение П Доверенный маршрут/канал (FTP)

ПЛ Доверенный канал передачи между ФБО (FTPJTC)

П.2 Доверенный маршрут (FTP TRP)

Введение

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

ГОСТ Р ИСО/МЭК 15408 содержит общие критерии оценки безопасности информационных технологий.

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

ГОСТ Р ИСО/МЭК 15408-2 содержит универсальный систематизированный каталог функциональных требований бе зопасности и предусматривает возможность их детализации и расширения по определенным правилам.

ГОСТ Р ИСО/МЭК 15408-3 включает в себя систематизированный каталог требований доверия, определяющих меры, которые должны быть приняты на всех этапах жизненного никла продукта или системы ИТ для обеспечения уверенности в том, что они удовлетворяют предъявленным к ним функциональным требованиям. Здесь же содержатся оценочные уровни доверия, определяющие шкалу требований, которые позволяют с возрастающей степенью полноты и строгости оценить проектную, тестовую и эксплуатационную документацию, правильность реализации функций безопасности ОО. уязвимости продукта или системы ИТ. стойкость механизмов защиты и сделать заключение об уровне доверия к безопасности объекта опенки.

ГОСТ Р ИСО/МЭК 15408-2-2002

ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационная технология

МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ

КРИТЕРИИ ОЦЕНКИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

Часть 2

Функциональные требования безопасности

Information technology. Security techniques. Evaluation criteria for IT security. Part 2.

Security functional requirements

Дата введения 2004—01—01

1 Област ь применения

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

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

Настоящий стандарт предназначен для потребителей, разработчиков, а также оценщиков безопасных систем и продуктов И’Г. Дополнительная информация о потенциальных пользователях ГОСТ Р ИСО/МЭК 15408. а также о применении критериев указанными группами пользователей представлена в разделе 3 ГОСТ Р ИСО/МЭК 15408-1. Эти группы могут использовать настоящий стандарт следующим образом.

Потребители — при выборе компонентов для выражения функциональных требований, позволяющих удовлетворить цели безопасности, выраженные в ПЗ или ЗБ. Более подробная информация о взаимосвязях требований безопасности и целей безопасности приведена в подразделе 4.3 ГОСТ Р ИСО/МЭК 15408-1.

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

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

1.1 Расширение и сопровождение функциональных требований

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

Излапие официальное

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

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

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

1.2 Структура

Раздел 1 содержит введение.

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

В ра зделах 3—13 приведено описание функциональных классов.

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

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

ГОСТ Р ИСО/МЭК 15408-1 содержит следующую информацию, необходимую разработчикам ПЗ или ЗБ:

— термины, используемые в стандарте, определены в разделе 2 ГОСТ Р ИСО/МЭК 15408-1;
— структура ПЗ приведена в приложении Б к ГОСТ Р ИСО/МЭК 15408-1;
— структура ЗБ приведена в приложении В к ГОСТ Р ИСО/МЭК 15408-1.

1.3 Парадигма функциональных требований

Па рисунках 1.1 и 1.2 показаны некоторые ключевые понятия парадигмы. Описаны и другие, не показанные на рисунках, ключевые понятия. Рассматриваемые ключевые понятия

Рисунок 1.1 — Ключевые понятия функциональных требований безопасности (единый ОО)

Локальный пользователь

Локальный (вну1ренний для 00) доверенный маршрут

Передача в пределах 00

Локальный ОО

Передача вне ОДФ

Передача между ФБО

Недоверенный продукт ИТ	у*	—г————- \ Удаленный доверенный
	Доверенный маршрут между , ФБО		продукт ИТ
		ФБ удаленного продукта
	о

Удаленный пользователь

Рисунок 1.2 — Функции безопасности в распределенном 00

выделены полужирным курсивом. Определения терминов, приведенные в словаре в разделе 2 ГОСТ Р ИСО/МЭК 15408-1. в этом подразделе нс изменяются и нс переопределяются.

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

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

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

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

Монитор обращений — это концепция абстрактной машины, которая осуществляет политику управления доступом 00. Механизм проверки правомочности обращений — реализация концепции монитора обращений, обладающая следующими свойствами: защищенностью от проникновения; постоянной готовностью; простотой, достаточной для проведения исчерпывающего анализа и тестирования. ФБО могут состоять из механизма проверки правомочности обращений и/или других функций безопасности, необходимых для эксплуатации 00.

ОО может быть единым продуктом, включающим аппаратные, программно-аппаратные и программные средства.

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

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

Интерфейсы 00 могут быть локализованы в конкретном 00 или же могут допускать взаимодействие с другими продуктами ИТ по внешним каналам связи. Внешние взаимодействия с другими продуктами ИТ могут принимать две формы:

а) Политика безопасности «удаленного доверенного продукта И Г» и ПБО рассматриваемого 00 скоординированы и оценены в административном порядке. Обмен информацией в этом случае назван передачей между ФБО. поскольку он осуществляется между ФБО различных доверенных продуктов.

б) Удаленный продукт ИТ. обозначенный на рисунке 1.2 как «недоверенный продукт ИТ», не был оценен, поэтому его политика безопасности неизвестна. Обмен информацией в этом случае назван передачей за пределы области действия ФБО. так как этот удаленный продукт ИТ не имеет ФБО (или характеристики его политики безопасности неизвестны).

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

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

Пользователи не включаются в состав 00; поэтому они находятся вне ОДФ. Однако пользователи взаимодействуют с 00 через ИФБО при запросе услуг, которые будут выполняться 00. Существует два типа пользователей, учитываемых в функциональных требованиях безопасности настоящего стандарт: человек-пользователь и внешний объект ИТ. Для человека-пользователя различают локального человека-пользователя. взаимодействующего непосредственное 00 через устройства 00 (такие, как рабочие станции), и удаленного человека-пользователя, взаимодействующего с 00 через другой продукт ИТ.

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

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

Дзя выражения требований разделения административных обязанное гей соответствующие функциональные компоненты безопасности (из семейства FMT SMR), приведенные в настоящем стандарте. явно устанавливают обязательность административных ролей. Роль — это заранее определенная совокупность правил, устанавливающих допустимые взаимодействия между пользователем и 00. 00 может поддерживать определение произвольного числа ролей. Например, роли, связанные с операциями безопасности 00. могут включать в себя роли «Администратор аудита» и «Администратор учета пользователей».

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

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

Активные сущности названы субъектами. В пределах ОО могут существовать несколько типов субъектов:

в) действующие от имени уполномоченного пользователя и подчиненные всем правилам ПВО (например, процессы UNIX);

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

д) действующие как часть собственно 00 (например, доверенные процессы).

В настоящем стандарте рассматривается осуществление ПВО для субъектов всех типов, перечисленных выше.

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

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

Пользователи, субъекты, информация и объекты обладают определенными атрибутами, которые содержат информацию, позволяющую 00 функционировать правильно. Некоторые атрибуты, такие как имена файлов, могут предназначаться только для информирования, в то время как другие, например различные параметры управления доступом. — исключительно для осуществления ПБО. Эти последние обобщенно названы «атрибутами безопасности». В дальнейшем слово «атрибут» используется в настоящем стандарте как сокращение для словосочетания «атрибут безопасности’», если иное не оговорено. Вместе с тем. независимо от предназначения информации атрибута, могут потребоваться средства управления этим атрибутом в соответствии с ПБО.

В 00 содержатся данные пользователей и данные ФБО. На рисунке 1.3 показана их взаимосвязь. Данные пользователей — это информация, содержащаяся в ресурсах ОО. которая может применяться пользователями в соответствии с ПБО и не предназначена специально для ФБО. Например, содержание сообщения электронной почты является данными пользователя. Данные ФБО — это информация.

ДАННЫЕ 00

/ДАННЫЕ ФБО

ДАННЫЕ ПОЛЬЗОВАТЕЛЕЙ

(—————>

Аутентификационные данные

Атрибуты безопасности

( Атрибуты пользователей

£ Афибу1ы обьекюв

( Атрибуты субъсктоо

[ Атрибуты информации

‘–

Рисунок 1.3 — Связь между данными пользователей и данными ФБО

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

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

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

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

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

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

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

—————\

Аутентификационные данные

Биометрия Кредитные карточки

Пароли

Криптографические переменные

Секреты

\____________/

Рисунок 1.4 — Связь между понятиями «аутентификационные данные» и «секреты»

2 Функциональные компоненты безопасности

2.1 Краткий обзор

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

2.1.1 Структура класса

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

Рисунок 2.1 — Структура функнионатьносо класса

2.1.1.1 Имя класса

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

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

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

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

2.1.2 С т р у к т у р а семейства

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

2.1.2.1 Имя семейства

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

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

2.1.2.2 Характеристика семейства

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

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

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

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

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

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

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

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

2.1.2.4 Управление

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

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

2.1.2.5 Аудит

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

Минимальный — успешное использование механизма безопасности.

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

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

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

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

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

2.1.3 С т р у к т у р а компонента

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

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

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

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

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

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

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

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

Вводится уникальная краткая форма имени функционального элемента. Например, имя FDP 1FF.4.2 читается следующим образом: F — функциональное требование. DP — класс «Зашита данных пользователя». _lFF — семейство «Функции управления информационными потоками». .4 — четвертый компонент «Частичное устранение неразрешенных информационных потоков». .2 — второй элемент компонента.

2.1.3.3 Зависимости

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

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

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

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

2.1.4 Р а з решенные опер а п и и с функциональными к о м п о н с н-т а м и

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

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

К разрешенным операциям относятся:

— итерация — позволяет несколько раз использовать компонент с различным выполнением операций;
— назначение — позволяет специфицировать заданный параметр;
— выбор — позволяет специфицировать один или несколько элементов из списка:
— уточнение — позволяет добавить детали.

2.1.4.1 Итерация

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

2.1.4.2 Назначение

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

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

2.1.4.3 Выбор

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

2.1.4.4 Уточнение

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

Например, если для конкретного 00 требуется объяснение смысла терминов «субъект» и «объект» в рамках ЗБ. то эти термины подвергают операции уточнения.

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

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

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

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

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

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

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

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

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

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

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

3 Класс FAU. Аудит безопасности

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

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

Рисунок 3.1 — Декомпозиция класса -Аудит безопасности»

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

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

Семейство FAU ARP определяет реакцию на обнаружение событий, указывающих на возможное нарушение безопасности.

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

В FAU. ARP. 1 «Сигналы нарушения безопасности» ФБО должны предпринимать действия в еду час обнаружения возможного нарушения безопасности.

Управление: FAU_ARP. 1

Для функций управления из класса F.MT может рассматриваться следующее действие.

а) Управление действиями (добавление, удаление или модификация).

Аудит: FAU ARP. I

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

а) Минимальный: действия, предпринимаемые в ответ на ожидаемые нарушения безопасности.

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

Иерархический для: Нет подчиненных компонентов.

FAU_ARP. 1.1 ФБО должны предпринять (назначение: список наименее разрушительных действий] при обнаружении возможного нарушения безопасности.

Зависимости: FAU_SAA.I Анализ потенциального нарушения

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

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

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

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

FAU_GEN.l «Генерация данных аудита» определяет уровень событий, потенциально подвергаемых аудиту, и состав данных, которые должны быть зарегистрированы в каждой записи.

В FAU_GEN.2 «Ассоциация идентификатора пользователя» ФБО должны ассоциировать события. потенциально подвергаемые аудиту. и личные идентификаторы пользователей.

Управление: FAU„GEN.l, FAU.GEN.2

Действия по управлению нс предусмотрены.

Аудит: FALLGEN.1. FAU„GEN.2

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

FAU.GEN. 1 Генерация данных аудита

Иерархический для: Нет подчиненных компонентов.

FAU.GEN.l.l ФБО должны быть способны генерировать запись аудита для следующих событий, потенциально подвергаемых аудиту:

а) запуск и завершение выполнения функций аудита;

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

в) [назначение: другие специально определенные события, потенциально подвергаемые оудшлу]. FAU-GEN. 1.2 ФБО должны регистрировать в каждой записи аудита, по меньшей мере, следующую информацию:

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

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

Зависимости: FPT_STM.I Падежные метки времени FAU_GEN.2 Ассоциация идентификатора пользователя Иерархический для: Нет подчиненных компонентов.

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

Зависимости: FAU_GEN.l Генерация данных аудита FIA_UID.l Выбор момента идентификации

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

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

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

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

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

В FAUSAA.1 «Анализ потенциального нарушения» требуется базовый порог обнаружения на основе усганоазенного набора правил.

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

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

В FAUSAA.4 «Сложная эвристика атаки» ФБО должны быть способны задать и обнаружить многошаговые сценарии проникновения. Здесь ФБО способны сравнить события в системе (возможно, выполняемые несколькими участниками) с последовательностями событий, известными как полные сценарии проникновения. ФБО должны быть способны указать на обнаружение характерного события или последовательности событий, свидетельствующих о возможном нарушении ПБО.

Управление: FAU SAA. 1

Для функций управления из класса F.MT может рассматриваться следующее действие.

а) Сопровождение (добавление, модификация, удаление) правил из набора правил. Управление: FAU SAA.2

Для функций управления из класса FMT может рассматриваться следующее действие.

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

Управление: FAU SAA.3

Для функций управления из класса FMT может рассматриваться следующее действие.

а) Сопровождение (удаление, модификация, добавление) подмножества событий системы. Управление: FAU__SAA.4

Для функций управления из класса FMT могут рассматриваться следующие действия.

а) Сопровождение (удаление, модификация, добавление) подмножества событий системы.

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

Аудит: FAU SAA. 1. FAUSAA.2. FAUSAA.3. FAUSAA.4

а) Минимальный: подключение и отключение любого из механизмов анализа.

б) Минимальный: автоматические реакции, выполняемые инструментальными средствами. FAU_SAA. I Анализ потенциального нарушения

Иерархический для: Нет подчиненных компонентов.

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

FAU_SAA.1.2 ФБО должны реализовать следующие правила при мониторинге событий, подвергающихся аудиту:

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

б) [назначение: другие правила].

Зависимости: FAU_GEN.l Генерация данных аудита FAU_SAA.2 Выявление аномалии, основанное на профиле Иерархический для: FAU SAA.1

FAU_SAA.2.1 ФБО должны быть способны сопровождатьпрофили использования системы, где каждый отдельный профиль представляет известные шаблоны предыстории использования, выполнявшиеся участниками [назначение: спецификация целевой группы профиля].

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

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

Зависимости: F1A_L’1D.1 Выбор момента идентификации

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

Иерархический для: FAU_SAA.l

FAU_SAA.3.1 ФБО должны быть способны сопровождать внутреннее представление следующих характерных событий [назначение: подмножество событий системы], которые могут указывать на нарушение ПБО.

F/\U_SAA.3.2 ФБО должны быть способны сравнить характерные события с записью показателей функционирования системы, полученных при обработке [назначение: информация, используемая для определения показателей функционирования системы].

FAU_SAA.3.3 ФБО должны быть способны указать на ожидаемое нарушение ПБО, когда событие системы соответствует характерному событию, указывающему на возможное нарушение ПБО.

Зависимости: отсутствуют.

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

Иерархический для: FAU_SAA.3

FAU_SAA.4.1 ФБО должны быть способны сопровождать внутреннее представление следующих последовательностей событий известных сценариев проникновения [назначение: список последовательностей событий системы, совпадение которых характерно для известных сценариев проникновения] и следующих характерных событий [назначение: подмножество событий системы], которые могут указывать на возможное нарушение ПБО.

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

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

Зависимости: отсутствуют.

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

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

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

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

FAU SAR. I «Просмотр аудита» предоставляет возможность читать информацию из записей аудита.

FAU SAR.2 «Ограниченный просмотр аудита» содержит требование отсутствия доступа к информации кому-либо, кроме пользователей, указанных в FAU_SAR.l.

FAU_SAR.3 «Выборочный просмотр аудита» содержит требование, чтобы средств;! просмотра аудита отбирали данные аудита на основе кри териев просмотра.

Управление: FAU_SAR. 1

Для функций управления из класса FMT может рассматриваться следующее действие.

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

Управление: FAUSAR.2, FAU SAR.3

Действия по управлению не предусмотрены.

Аудит: FAUSAR.1

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

а) Базовый: чтение информации из записей аудита.

Аудит: FAU SAR.2

а) Базовый: неуспешные попытки читать информацию из записей аудита.

Аудит: FAU SAR.3

а) Детализированный: параметры, используемые при просмотре.

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

Компонент FAUSAR.1 предоставит уполномоченным пользователям возможность получать и интерпретировать ин<|юрмаиию. Для человека-пользователя эту информацию требуется представлять в понятном лля него виде. Для внешнего объекта И’Г информацию требуется представлять только в электронном виде.

Иерархический для: Нет подчиненных компонентов.

FAUJSAR.I.I ФБО должны предоставлять [назначение: уполномоченные пользователи} возможность читать [назначение: список информации аудита} из записей аудита.

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

Зависимости: FAU_GEN.l Генерация данных аудита

FAU_SAR.2 Ограниченный просмотр аудита Иерархический для: Нет подчиненных компонентов.

FAU_SAR.2.1 ФБО должны запретить всем пользователям доступ к чтению записей аудита, за исключением пользователей, которым явно предоставлен доступ для чтения.

Зависимости: FAU_SAR.l Просмотр аудита

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

Иерархический для: Нет подчиненных компонентов.

FAU_SAR.3.I ФБО должны предоставить возможность выполнить [выбор: поиск, сортировка, упорядочение] данных аудита, основанный на [назначение: критерии с логическими отношениями].

Зависимости: FAUjSAR.l Просмотр аудита

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

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

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

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

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

Управление: FAU_SEL.I

Для функций управления из класса FMT может рассматриваться следующее действие.

а) Сопровождение прав просмотра/модификапии событий аудита.

Аудит: FAU SEL.I

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

а) Минимальный: все модификации конфигурации аудита, происходящие во время сбора данных аудита.

FAU-SEL.1 Избирательный аудит

Иерархический для: Нет подчиненных компонентов.

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

а) [выбор: идентификатор объекта, идентификатор пользователя, идентификатор субъекта, идентификатор узла сети, тип события];

б) [назначение: список дополнительных атрибутов, на которых основана избирательность аудита].

Зависимости: FAU_GEN.l Генерация данных аудита FMT_MTD. I Управление данными ФБО

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

Характерце I ика семейства

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

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

В FAU STO. 1 «.Защищенное хранение журнала аудита» содержатся требования зашиты журнала аудита от несанкционированного удаления и/или модификации.

FAU STG.2 «Гарантии доступности данных аудита» определяет гарантии, что ФБО поддерживают имеющиеся данные аудита при возникновении нежелательной си туации.

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

FAU STG.4 «Предотвращение потери данных аудита» определяет действия при переполнении журнала аудита.

Управление: FAUSTG.1

Действия по управлению нс предусмотрены.

Управление: FAU STG.2

Для функций управления из класса FMT может рассматриваться следующее действие.

а) Сопровождение параметров, которые управляют возможностями хранения журнала аудита. Управление: FAU STG.3

Для функций управления из класса FMT могут рассматриваться следующие действия.

а) Отслеживание порога заполнения.

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

Управление: FAU_STG.4

Для функций управления из класса FMT может рассматриваться следующее действие.

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

Аудит: FAUJ5TG.1, FAU_STG.2

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

Аудит: FAU-STG.3

а) Базовый: предпринимаемые действия после превышения порога заполнения.

Аудит: FAU STG.4

а) Базовый: предпринимаемые действия при сбое хранения журнала аудита.

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

Иерархический для: Нет подчиненных компонентов.

FAU_STG.I.l ФБО должны защищать хранимые записи аудита от несанкционированного удаления.

FAU_STG.1.2 ФБО должны быть способны к [выбор: предотвращение, выявление] модификации записей аудита.

Зависимости: FAU_GEN.1 Генерация данных аудита

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

Иерархический для: FAU_STG.I

FAU.STG.2.1 ФБО должны защищать хранимые записи аудита от несанкционированного удаления.

FAU_STG.2.2 ФБО должны быть способны к (выбор: предотвращение, выявление] модификации записей аудита.

FAU.STG.2.3 ФБО должны обеспечить поддержку [назначение: показатель сохранности записей аудита] при наступлении следующих событий: [выбор: переполнение журнала аудита, сбой, атака].

Зависимости: FAUGEN. 1 Генерация данных аудита

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

Иерархический для: Нет подчиненных компонентов.

FAU_STG.3.1 ФБО должны выполнить [назначение: действия, которые нужно предпринять в случае возможного сбоя хранения журнала аудита], если журнал аудита превышает [назначение: принятое ограничение].

Зависимости: FAU_STG.l Защищенное хранение журнала аудита

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

Иерархический для: FAU_STG.3

FAU_STG.4.1 ФБО должны выполнить [выбор: «игнорирование событий, подвергающихся аудиту», «предотвращение событий, подвергающихся аудиту, исключая предпринимаемые уполномоченным пользователем со специальными правами», «запись поверх самых старых хранимых записей аудита»] и [назначение: другие действия, которые нужно предпринять в случае возможного сбоя хранения журнала аудитл] при переполнении журнала аудита.

Зависимости: FAU_STG.l Защищенное хранение журнала аудита

4 Класс FCO. Связь

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

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

Рисунок 4.1 — Декомпозиция класса «Связь»

4.1 Пеотказуемость отправления (FCO_NRO)

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

Семейство FCO_NRO обеспечивает невозможность отрицания отправителем информации (ракта ее отправления. Семейство FCO NRO содержит требование. чтобы ФБО обеспечили метод предоставления субъекту-получателю свидетельства отправления информации. Эго свидетельство может быть затем верифицировано этим субъектом или другими субъектами.

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

FCO NRO.1 * Избирательное доказательство отправления* содержит требование, чтобы ФБО предоставили субъектам возможность запросить свидетельство отправления информации.

FCO N RO.2 «Принудительное доказательство отправления» содержит требование, чтобы ФБО всегда генерировали свидетельство отправления передаваемой информации.

Управление: FCO.NRO.l, FCO.NRO.2

Для функций управления из класса F.MT может рассматриваться следующее действие.

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

Аудит: FCO NRO. 1

а) Минимальный: идентификатор пользователя, который запросил генерацию свидетельства отправления.

б) Минимальный: обращение к функции неотказуемости.

в) Базовый: идентификатор информации, получателя и копии предоставляемого свидетельства.

г) Детализированный: идентификатор пользователя, который запросил верификацию свидетельства.

Аудит: FCO_NRO.2

а) Минимальный: обращение к функции неотказуемости.

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

в) Детализированный: идентификатор пользователя, который запросил верификацию свидетельства.

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

Иерархический для: Нет подчиненных компонентов.

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

FCO-NRO. 1.2 ФБО должны быть способны связать (назначение: список атрибутов] отправителя информации и (назначение: список информационных информации, к кото

рой прилагается свидетельство.

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

Зависимости: FIA_U1D.1 Выбор момента идентификации

FCO-NRO.2 Принудительное доказательство отправления

Иерархический для: FCO NRO.I

FCO_NRO.2.1 ФБО должны всегда осуществлять генерацию свидетельства отправления передаваемой (назначение: список типов информации].

FCO_\’RO.2.2 ФБО должны быть способны связать [назначение: список атрибутов] отправителя информации и [назначение: список информационных полей] информации, к которой прилагается свидетельство.

FCO_NRO.2.3 ФБО должны предоставить возможность верифицировать свидетельство отправления информации [выбор: отправитель. получатель, [назначение: список третьих лиц}\ при установленных [назначение: ограничения на свидетельство отправления].

Зависимости: FIA_UID.1 Выбор момента идентификации

4.2 Неогказуемосгь получения (FCO_NRR)

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

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

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

FCO_NRR. I «Избирательное доказательство получения» содержит требование, чтобы ФБО предоставили субъектам возможность запросить свидетельство получения информации.

FCO NRR.2 «Принудительное доказательство получения» содержит требование, чтобы ФБО всегда генерировали свидетельство получения принятой информации.

Управление: FCOJ4RR.I. FCO„NRR.2

Для функций управления из класса FMT может рассматриваться следующее действие.

Аудит: FCO_NRR.l

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

б) Минимальный: обращение к функции неотказуемости.

в) Базовый: идентификация информации, получателя и копии предоставляемого свидетельства.

г) Детализированный: идентификатор пользователя, который запросил верификацию свидетельства.

Аудит: FCOJ4RR.2

а) Минимальный: обращение к функции неотказуемости.

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

в) Детализированный: идентификатор пользователя, который запросил верификацию свидетельства.

FCO_\RR.l Избирательное доказательство получения

Иерархический для: Нет подчиненных компонентов.

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

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

FCO NRR. 1.3 ФБО должны предоставить возможность верифицировать свидетельство получения информации [выбор: отправитель, получатель, [назначение: список третьих лиц[] при установленных [назначение: ограничения на свидетельство отправления] .

Зависимости: FlA L’ID.l Выбор момента идентификации

FCO_\RR.2 Принудительное доказательство получения

Иерархический для: FCO NRR.1

F€’O_NRR.2.1 ФБО должны осуществлять генерацию свидетельства получения принятой (назначение: список типов информации].

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

FCO_\RR.2.3 ФБО должны предоставить возможность верифицировать свидетельство получения информации [выбор: отправитель, получатель, [назначение: список третьих лиц[\ при установленных (назначение: ограничения на свидетельство отправления].

Зависимости: F1A_U1D.1 Выбор момента идентификации

5 Класс FCS. Криптографическая поддержка

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

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

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

Рисунок 5.1 — Декомпозиция класса «Криптографическая поддержка»

5.1 Управление криптографическими ключами (FCS—CKM)

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

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

Ра» 1жировш I ис ком понентов

FCS CKM.I «Генерация криптографических ключей» содержит требования к их созданию согласно определенному алгоритму и длине ключа, которые могут основываться на соответствующем стандарте.

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

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

FCS СКМ.4 «Уничтожение криптографических ключей» содержит требование их уничтожения согласно определенному метолу, который может основываться на соответствующем стандарте.

Управление: FCSJTKM.l, FCS„CKM.2, FCS_CKM.3, FCSJL’KM.4

Для функций управления из класса FMT может рассматриваться следующее действие.

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

Аудит: FCS CKM.l. FCS СКМ.2. FCS СКМ.З. FCS СКМ.4

Если в ПЗ/ЗБ включено семейство FAU/GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих дей-ствий/событий/параметров.

а) Минимальный: успешный или неуспешный результат действия.

б) Базовый: атрибуты объекта и содержание объекта, за исключением любой чувствительной ин<|юрмаиии (например, секретных или приватных ключей).

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

Иерархический для: Нет подчиненных компонентов.

FCS_CKM.1.1 ФБО должны генерировать криптографические ключи в соответствии с определенным алгоритмом (назначение: алгоритм генерации криптографических ключей] и длиной [назначение: длины криптографических ключей], которые отвечают следующему: [назначение: список стандартов].

Зависимости: [FCS_CKM.2 Распределение криптографических ключей или FCS_COP. 1 Криптографические операции]

FCS_CKM.4 Уничтожение криптографических ключей FMT.MSA.2 Безопасные значения атрибутов безопасности

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

Иерархический для: Нет подчиненных компонентов.

FCS-CKM.2.1 ФБО должны распределять криптографические ключи в соответствии с определенным методом [назначение: метод распределения криптографических ключей], который отвечает следующему: [назначение: список стандартов].

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

или FCS_CKM.l Генерация криптографических ключей] FCS_CKM.4 Уничтожение криптографических ключей FMT-MSA.2 Безопасные значения атрибутов безопасности FCS-CKM.3 Доступ к криптографическим ключам Иерархический для: Нет подчиненных компонентов.

FCS_CKM.3.1 ФБО должны выполнять [назначение: тип доступа к криптографическим ключам] в соответствии с определенным методом доступа | назначение: метод доступах криптографическим ключам], который отвечает следующему: (назначение: список стандартов].

Зависимости: (FDP_ITC.l Импорт данных пользователя без атрибутов безопасности или FCS_CKM.l Генерация криптографических ключей] FCS_CKM.4 Уничтожение криптографических ключей FMT.MSA.2 Безопасные значения атрибутов безопасности

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

Иерархический для: Нет подчиненных компонентов.

FCS_CKM.4.1 ФБО должны уничтожать криптографические ключи в соответствии с определенным методом [назначение: метод уничтожения криптографических ключей], который отвечает следующему: (назначение: список стандартов].

Зависимости: (FDP_1TC.1 Импорт данных пользователя без атрибутов безопасности

или FCS_CKM.l Генерация криптографических ключей] FMT_MSA.2 Безопасные значения а трибутов безопасности

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

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

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

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

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

FCS_COP. 1 «Криптографические операции» содержит требования их выполнения по определенным алгоритмам с применением криптографических ключей определенной длины. Алгоритмы и /шина криптографических ключей могут основываться на соответствующем стандарте.

Управление: FCSCOF³.1

Действия по управлению не предусмотрены.

Аудит: FCS-COP.I

Если в ПЗ/ЗБ включено семейство FAU^GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих дей-ствий/событий/параметров.

а) Минимальный: успешное или неуспешное завершение, а также тип криптографической операции.

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

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

Иерархический для: Нет подчиненных компонентов.

FCS_COP.!.l ФБО должны выполнять [назначение: список криптографических операций] в соответствии с определенными алгоритмами [назначение: криптографические алгоритмы] и длиной [назначение: длины криптографических ключей], которые отвечают следующему: [назначение: список стандартов].

Зависимости: |FDP_1TC.1 Импорт данных пользователя без атрибутов безопасности

или FCS_CKM.l Генерация криптографических ключей FCS_CKM.4 Уничтожение криптографических ключей FMT_MSA.2 Безопасные значения атрибутов безопасности

6 Класс FDP. Защита данных пользователя

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

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

— FDP АСС «Политика управления доступом»;

— FDP_IFC «Политика управления информационными потоками».

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

б) Виды защиты данных пользователя:

— FDP_ACF «Функции управления доступом»:

— FDP_IFF «Функции управления информационными потоками»:

— FDP ITT «Передача в пределах 00»:

— FDP_RIP «Защита остаточной информации»:

— FDP_ROL «Откат»;

— FDP SOI «Целостность хранимых данных».

в) Автономное хранение, импорт и экспорт данных:

— FDP_DAU «Аутентификация данных»:

— FDP.ETC «Экспорт данных за пределы действия ФБО»:

— FDP 1ТС «Импорт данных из-за пределов действия ФБО».

Комионенты этих семейств свя заны с доверенной передачей данных в или из ОДР.

г) Связь между ФБО:

— FDP UCT «Зашита конфиденциальности данных пользователя при передаче между ФБО»:

— FDP UIT «Зашита целостности данных пользователя при передаче между ФБО». Компоненты этих семейств определяют взаимодействие между ФБО собственно ОО и другого доверенного продукта ИТ.

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

Рисунок 6.1 — Декомпозиция класса «Зашита данных пользователя*

Рисунок 6.2 — Декомпозиция класса «Зашита данных пользователя» (продолжение)

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

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

Семейство FDP ACC идентифицирует ПФБ управления доступом, устанавливая им имена, и определяет области действия политик, образующих идентифицированную часть управления доступом ПВО. Области действия можно характеризовать тремя множествами: субъекты под управлением политики, объекты под управлением политики и операции управляемых субъектов на управляемых объектах, на которые распространяется политика. Общие критерии допускают существование нескольких политик, каждая из которых имеет уникальное имя. Эго достигается посредством выполнения итсрапий компонентов рассматриваемого семейства по одному разу для каждой именованной политики управления доступом. Правила, определяющие функциональные возможности ПФБ управления доступом. будут установлены другими семействами. такими как FDP ACF и FDP SDI. Предполагается, что имена ПФБ. идентифицированные в семействе FDP_ACC. будут использоваться повсеместно в функциональных компонентах, которые имеют операцию, запрашивающую назначение или выбор «ПФБ управления доступом».

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

FDP ACC. 1 «-Ограниченное управление доступом» содержит требование, чтобы каждая идентифицированная ПФБ управления доступом существовала для подмножества возможных операций на подмножестве объектов в 00.

FDP АСС.2 «Полное управление доступом» содержит требование, чтобы каждая идентифицированная ПФБ управления доступом охватывала все операции субъектов на объектах, управляемых этой ПФБ. Кроме этого требуется, чтобы все объекты и операции в ОДФ были охвачены по меньшей мере одной идентифицированной ПФБ управления доступом.

Управление: FDP_ACC.l. FDP_ACC.2

Действия по управлению не предусмотрены.

Аудит: FDP_ACC.l. FDP_ACC.2

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

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

Иерархический для: Нет подчиненных компонентов.

FDP_ACC.I.l ФБО должны осуществлять [назначение: ПФБ управления доступом] для [назначение: список субъектов, объектов и операции субъектов на объектах, на которые распространяется ПФБ}.

Зависимости: FDP_ACF.l Управление доступом, основанное на атрибутах безопасности FDP_ACC.2 Полное управление доступом

Иерархический для: FDP ACC. 1

FDP_ACC.2.1 ФБО должны осуществлять [назначение: ПФБуправления доступом] для [назначение: список субъектов и объектов] и всех операций субъектов на объектах, на которые распространяется ПФБ.

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

Зависимости: FDP ACF.I Управление доступом, основанное на атрибутах безопасности

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

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

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

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

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

FDP ACF. 1 «Управление доступом, основанное на атрибутах безопасности» позволяет ФБО осуществить доступ. основанный на атрибутах и именованных группах атрибутов безопасности. Кроме того. ФБО могут иметь возможность явно разрешать или запрещать доступ к объекту, основываясь на атрибутах безопасности.

Управление: FDP ACF.1

Для функций управления из класса FMT можс рассматриваться следующее действие.

а) Управление атрибутами, используемыми для явного разрешения или запрещения доступа.

Если в ПЗ/ЗБ включено семейство FAV GEN «Генерация данных аудита безопасности», то следует предусмотрев возможность (в зависимости от выбранного уровня) аудита следующих лей-ствий/событий/пара метров.

а) Минимальный: успешные запросы на выполнение операций на объекте, на который распространяется ПФБ.

б) Базовый: все запросы на выполнение операций на объекте, на который распространяется ПФБ.

в) Детализированный: специальные атрибуты безопасности, используемые при проверке правомерности доступа.

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

Иерархический для: Нет подчиненных компонентов.

FDP_ACF.l. I ФБО должны осуществлять [назначение: ПФБ управления доступом} к объектам, основываясь на [назначение: атрибуты безопасности, именованные группы атрибутов безопасности].

FDP-ACF.1.2 ФБО должны реализовать следующие правила определения того, разрешена ли операция управляемого субъекта на управляемом объекте: [назначение: правила управления доступом управляемых субъектов к управляемым объектам с использованием управляемых операций на янл ].

FDP_ACF.1.3 ФБО должны явно разрешать доступ субъектов к объектам, основываясь па следующих дополнительных правилах: [назначение: правила, основанные на атрибутах безопасности, которые явно разрешают доступ субъектов к объектам].

FDP_ACF. 1.4 ФБО должны явно отказывать в доступе субъектов к объектам, основываясь на следующих дополнительных правилах: [назначение: правила, основанные на атрибутах безопасности, которые явно запрещают доступ субъектов к объектам].

Зависимости: FDP_ACC.l Ограниченное управление доступом FMT_MSA.3 Инициализация статических атрибутов

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

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

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

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

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

FDP DAU.2 «Аутентификация данных с идентификацией гаранта» содержит дополнительное требование, чтобы ФБО были способны установить идентификатор субъекта, который предоставил гарантию подлинности.

Управление: FDP_DAU. I. FDP DAU.2

Для функций управления из класса F.VIT может рассматриваться следующее действие.

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

Аудит: FDP_DAU.l

а) Минимальный: успешная генерация свидетельства правильности.

б) Базовый: неуспешная генерация свидетельства правильности.

в) Детализированный: идентификатор субъекта, который запросил свидетельство.

Аудит: FDP DAU.2

а) Минимальный: успешная генерация свидетельства правильности.

б) Базовый: неуспешная генерация свидетельства правильности.

в) Детализированный: идентификатор субъекта. который запросил свидетельство.

г) Детализированный: идентификатор субъекта, который генерировал свидетельство.

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

Иерархический для: Нет подчиненных компонентов.

FDP_DAU. 1.1 ФБО должны предоставить возможность генерировать свидетельство, которое может быть использовано как гарантия правильности [назначение: список объектов или типов информации].

FDP_DAU.1.2 ФБО должны предоставить [назначение: список субъектов] возможность верифицировать свидетельство правильности указанной информации.

Зависимости: отсутствуют.

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

Иерархический для: FDP DAU.1

FDP_DAU.2.1 ФБО должны предоставить возможность генерировать свидетельство, которое может быть использовано как гарантия правильности [назначение: список объектов или типов информации].

FDP_DAU.2.2 ФБО должны предоставить [назначение: список субъектов] с возможностью верифицировать свидетельство правильности указанной информации и идентификатор пользователя, который создал свидетельство.

Зависимости: FIA_U1D.1 Выбор момента идентификации

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

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

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

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

FDP ETC. 1 «Экспорт данных пользователя без атрибутов безопасности» содержит требование, чтобы ФБО осуществляли соответствующие ПФБ при экспорте данных пользователя за пределы действия ФБО. Данные пользователя, которые экспортируются этой функцией, не сопровождаются ассоциированными с ними атрибутами безопасности.

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

Управление: FDP_ETC.l

Действия по управлению не предусмотрены.

FDPETC.2

Для функций управления класса FMT может рассматриваться следующее действие.

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

Лудит: FDP_ETC.l. FDP ЕТС.2

Если в ПЗ/ЗБ включено семейство FAU GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих дей-ствий/событий/параметров.

а) Минимальный: успешный экспорт информации.

б) Базовый: все попытки экспортировать информацию.

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

Иерархический для: Нет подчиненных компонентов.

FDP_ETC.l .1 ФБО должны осуществлять [назначение: ПФБ управления доступом и/или ПФБ управления информационными потоками} при экспорте данных пользователя, контролируемом ПФБ, за пределы ОДФ.

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

Зависимости: (FDP_ACC.l Ограниченное управление доступом или

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

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

Иерархический для: Нет подчиненных компонентов.

FDP_ETC.2.1 ФБО должны осуществлять (назначение: ПФБ управления доступом и/или ПФБ управления информационными потоками} при экспорте данных пользователя, контролируемом ПФБ, за пределы ОДФ.

FDP_ETC.2.2 ФБО должны экспортировать данные пользователя с атрибутами безопасности, ассоциированными с данными пользователя.

FDP_ETC.2.3 ФБО должны обеспечить, чтобы при экспорте за пределы ОДФ атрибуты безопасности однозначно ассоциировались с экспортируемыми данными пользователя.

FDP_ETC.2.4 ФБО должны реализовать следующие правила при экспорте данных пользователя из ОДФ: (назначение: дополнительные правила управления экспортом информации}.

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

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

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

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

Семейство FDP IFC идентифицирует ПФБ управления информационными потоками, устанавливая им имена, и определяет области действия политик, образующих идентифицированную часть управления информационными потоками ПБО. Эти области действия можно характеризовать тремя множествами: субъекты пол управлением политики, информация пол управлением политики и операции перемещения управляемой информации к управляемым субъектам и от них. на которые распространяется политика. Общие критерии допускают существование нескольких политик, каждая из которых имеет уникальное имя. Это достигается посредством выполнения итераций компонентов рассматриваемого семейства по одному разу для каждой именованной политики управления информационными потоками. Правила, определяющие функциональные возможности ПФБ управления информационными потоками, будут установлены другими семействами, такими как FDP IFF и FDP SDI. Имена ПФБ управления информационными потоками, идентифицированные в семействе FDP IFC. в дальнейшем будут использоваться повсеместно в тех функциональных компонентах, которые включают в себя операцию, запрашивающую назначение или выбор «ПФБ управления информационными потоками».

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

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

FDP 1FC.1 «Ограниченное управление информационными потоками» содержит требование, чтобы каждая идентифицированная ПФБ управления информационными потоками выполнялась для подмножества возможных операций на подмножестве информационных потоков в 00.

FDPIFC.2 «Полное управление информационными потоками» содержит требование, чтобы каждая идентифицированная ПФБ управления информационными потоками охватывала все операции для субъектов и информацию под управлением этой ПФБ. Также требуется, чтобы все информационные потоки и операции в пределах ОДФ были охвачены хотя бы по одной идентифицированной ПФБ управления информационными потоками. Совместно с компонентом FPT RVM.I это обеспечивает аспект «постоянная готовность» мониторинга обращений.

Управление: FDPJFC.l, FDPJFC.2

Действия по управлению не предусмотрены.

Аудит: FDPJFC.l. FDPJFC.2

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

FDPJFC.l Ограниченное управление информационными потоками

Иерархический для: Нет подчиненных компонентов.

FDPJFC.l.1 ФБО должны осуществлять [назначение: ПФБ управления информационными потоками] для [назначение: список субъектов, информации и операции перемещения управляемой информации к управляемым субъектам и от них, на которое распространяется ПФБ].

Зависимости: FDPJFF.1 Простые атрибуты безопасности

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

Иерархический для: FDPJFC.l

FDPJFC.2.1 ФБО должны осуществлять (назначение: ПФБ управления информационными потоками] для (назначение: список субъектов и информации] и всех операций перемещения управляемой информации к управляемым субъектам и от них. на которые распространяется ПФБ.

FDPJFC.2.2 ФБО должны обеспечить, чтобы в пределах ОДФ на все операции перемещения управляемой информации управляемым субъектам и от них распространялась какая-либо ПФБ управления информационными потоками.

Зависимости: FDPJFF. 1 Простые атрибуты безопасности

6.6 Функции управления информационными потоками (FDPJFF)

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

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

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

FDP IFF. I «Простые атрибуты безопасности» содержит требование наличия атрибутов безопасности информации и субъектов, которые выступают как инициаторы отправления или как получатели этой информации. В нем также определяются правила, которые необходимо реализовать с использованием функции, и описано, как функция получает атрибуты безопасности.

FDP 1FF.2 «Иерархические атрибуты безопасности» расширяет требования предыдущего компонента. требуя, чтобы все ПФБ управления информационными потоками в ПВО использовали иерархические атрибуты безопасности, которые образуют некоторую структуру.

FDP JFF.3 «Ограничение неразрешенных информационных потоков» содержит требование, чтобы ПФБ распространялась на неразрешенные информационные потоки, но нс обязательно устраняла их.

FDP 1FF.4 «Частичное устранение неразрешенных информационных потоков» содержит требование. чтобы ПФБ обеспечила устранение некоторых, но не обязательно всех неразрешенных информационных потоков.

FDP IFF.5 «Полное устранение неразрешенных информационных потоков» содержит требование. чтобы ПФБ обеспечила устранение всех неразрешенных информационных потоков.

FDP I FF.6 «Мониторинг неразрешенных информационных потоков» содержит требование, чтобы ПФБ отслеживала нера зрешенные информационные потоки, максимальная интенсивность которых превышает заданное пороговое значение.

Управление: FDP IFF.I. FDP IFF.2

Для функций управления из класса FMT может рассматриваться следующее действие, а) Управление атрибутами, используемыми для явного разрешения и запрещения доступа. Управление: FDPJFF.3. FDPJFF.4. FDPJFF.5

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

Управление: FDP IFF.6

Для функций управления из класса FMT могут рассматриваться следующие действия.

а) Включение или отключение функции мониторинга.

б) Модификация максимальной интенсивности, которая отслеживается при мониторинге. Аудит: FDPJFF.l. FDPJFF.2. FDPJFF.5

а) Минимальный: разрешения на запрашиваемые информационные потоки.

б) Базовый: все решения по запросам на информационные потоки.

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

г) Детализированный: некоторые специфические подмножества информации, передача которой

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

Аудит: FDPJFF.3. FDPJFF.4, FDPJFF.6

а) Минимальный: разрешения на запрашиваемые информационные потоки.

б) Базовый: все решения по запросам на информационные потоки.

в) Базовый: использование выявленных скрытых каналов.

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

шений по осуществлению информационных потоков.

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

е) Детализированный: использование идентифицированных скрытых каналов, для которых оценка

максимальной интенсивности превышает заданное пороговое значение.

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

Иерархический для: Нет подчиненных компонентов.

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

FDP_1FF.1.2 ФБО должны разрешать информационный ноток между управляемыми субъектом и информацией посредством управляемой операции, если выполняются следующие правила: [назначение: основанные на атрибутах безопасности отношения, которые необходимо поддерживать между атрибутами безопасности субъектов и информации (для каждой операции)].

FDP_IFF.1.3 ФБО должны реализовать [назначение: дополнительные правила ПФБ управления информационными потоками].

FDP_IFF. 1.4 ФБО должны предоставить следующее [назначение: список дополнительных возможностей ПФБ].

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

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

Зависимости: FDP_IFC.l Ограниченное управление информационными потоками FMT_MSA.3 Инициализация статических атрибутов

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

Иерархический для: FDP_IFF. 1

FDP_1FF.2.1 ФБО должны осуществлять (назначение: ПФБ управления информационными потоками]. основанную на следующих типах атрибутов безопасности субъектов и информации: [назначение: минимальное число и тип атрибутов безопасности].

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

FDP_IFF.2.3 ФБО должны реализовать [назначение: дополнительные правила ПФБ управления информационными потоками].

FDP_IFF.2.4 ФБО должны предоставить следующее [назначение: список дополнительных возможностей ПФБ].

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

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

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

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

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

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

Зависимости: FDP IFC.1 Ограниченное управление информационными потоками

FMT_.MSA.3 Инициализация статических атрибутов

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

Иерархический для: Нет подчиненных компонентов.

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

Зависимости: AVA_CCA.l Анализ скрытых каналов

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

FDP_1FF.4 Частичное устранение неразрешенных информационных потоков Иерархический для: FDP_1FF.3

FDP-1FF.4.1 ФБО должны осуществлять [назначение: ПФБ управления информационными потоками]. чтобы ограничить интенсивность (назначение: типы неразрешенных информационных потоков] до (назначение: максимальная интенсивность].

FDP_IFF.4.2 ФБО должны предотвращать (назначение: типы неразрешенных информационных потоков].

Зависимости: AVA ССА.1 Анализ скрытых каналов

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

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

Иерархический для: FDP IFF.4

FDP_IFF.5.1 ФБО должны обеспечить, чтобы не существовало никаких неразрешенных информационных потоков, способных нарушить [назначение: имя ПФБ управления информационными потоками].

Зависимости: AVA_CCA.3 Исчерпывающий анализ скрытых каналов

FDP IFC.I Ограниченное управление информационными потоками

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

Иерархический для: Нет подчиненных компонентов.

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

Зависимости: AVA_CCA.l Анализ скрытых каналов

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

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

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

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

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

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

Компонент FDPJTC.l «Импорт данных пользователя без атрибутов безопасности» содержит требования, чтобы атрибуты безопасности правильно представляли данные пользователя и поставлялись независимо от объекта.

Компонент FDPJTC.2 «Импорт данных пользователя с атрибутами безопасности* содержит требования, чтобы атрибуты безопасности правильно представляли данные пользователя, а также точно и однозначно ассоциировались с данными пользователя, импортируемыми из-за пределов ОДФ.

Управление: FDPJTC.l. FDPJTC.2

Для функций управления из класса FMT может рассматриваться следующее действие.

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

Аудит: FDP JTC.l, FDPJTC.2

Если в ПЗ/ЗБ включено семейство FAU GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих дей-ствий/событий/параметров.

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

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

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

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

Иерархический для: Нет подчиненных компонентов.

FDP_ITC.I.l ФБО должны осуществлять [назначение: ПФБуправления доступом и/или ПФБ управления информационными потоками] при импорте данных пользователя, контролируемом ПФБ, из-за пределов ОДФ.

FDP_1TC. 1.2 ФБО должны игнорировать любые атрибуты безопасности, ассоциированные с данными пользователя, при импорте из-за пределов ОДФ.

FDP_ITC.1.3 ФБО должны реализовать следующие правила при импорте данных пользователя, контролируемом ПФБ, из-за пределов ОДФ: [назначение: дополнительные правила управления импортом].

Зависимости: [FDP_ACC.l Ограниченное управление доступом или FDP_IFC. 1 Ограниченное управление информационными потоками] FMT-MSA.3 Инициализация статических атрибутов

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

Иерархический для: Her подчиненных компонентов.

FDP_ITC.2.1 ФБО должны осуществлять [назначение: ПФБуправления доступом и/или ПФБ управления информационными потоками] при импорте данных пользователя, контролируемом ПФБ, из-за пределов ОДФ.

FDP.ITC.2.2 ФБО должны использовать атрибуты безопасности, ассоциированные с импортируемыми данными пользователя.

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

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

FDP_ITC.2.5 ФБО должны реализовать следующие правила при импорте данных пользователя, контролируемом ПФБ, из-за пределов ОДФ: [назначение: дополнительные правила управления импортом].

Зависимости: [FDP_ACC.l Ограниченное управление доступом или FDP_IFC. 1 Ограниченное управление информационными потоками] FTP_1TC.1 Доверенный канал передачи между ФБО или FTP_TRP. 1 Доверенный маршруг]

FPT_TDC.l Базовая согласованность данных ФБО между ФБО

6.8 Передача в пределах ОО (FDP_ITT)

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

Семейство FDP_1TT содержит требования, связанные с зашитой данных пользователя при их передаче между различными частями ОО по внутреннему каналу. Этим оно отличается от семейств FDP UCT и FDP U1T. которые обеспечивают защиту данных пользователя при их передаче между различными ФБО по внешнему каналу, а также от семейств FDP_ETC и FDP 1ТС. которые связаны с передачей данных за пределы или из-за пределов действия ФБО.

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

FDP ITT. 1 «Базовая защита внутренней передачи» содержит требование, чтобы данные пользователя были защищены при передаче между частями ОО.

FDP ITT.2 «Разделение передачи по атрибутам» содержит в дополнение к первому компоненту требование разделения данных, основанного на значениях присущих ПФБ атрибутов.

FDP 1ТТ.З «Мониторинг целостности» содержит требование, чтобы ФБ контролировала данные пользователя, передаваемые между частями 00, на наличие идентифицированных ошибок целостности.

FDP ITT.4 «Мониторинг целостности по атрибутам» расширяет третий компонент, разрешая дополнительную форму мониторинга целостности с разделением, использующим присущие ПФБ атрибуты.

Управление: FDPJTT.l. FDPJTT.2

Для функций управления из класса FMT может рассматриваться следующее действие.

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

Управление: FDPJTT.3. FDPJTT.4

Для функций управления из класса FMT может рассматриваться следующее действие.

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

Лудит: FDP ITT.l. FDP ITT.2

а) Минимальный: успешные передачи данных пользователя с идентификацией используемого метола зашиты.

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

Аудит: FDP ITT.3. FDPJTT.4

Если в ПЗ/ЗБ включено семейство FAU..GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих дей-ствий/событий/парамегров.

а) Минимальный: успешные передачи данных пользователя с идентификацией используемого метода защиты целостности.

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

в) Базовый: несанкционированные попытки изменить метод защиты целостности.

г) Легализированный: действия, предпринимаемые после обнаружения ошибки целостности. FDPJTT.l Базовая зашита внутренней передачи

Иерархический для: Нет подчиненных компонентов.

FDPJTT.l ФБО должны осуществлять [назначение: ПФБ управления доступом и/или ПФБ управления информационными потоками], чтобы предотвратить [выбор: раскрытие, модификация, недоступность] данных пользователя при их передаче между физически разделенными частями ОО.

Зависимости: [FDP_ACC.l Ограниченное управление доступом или FDPJFC.1 Ограниченное управление информационными потоками] FDPJTT.2 Разделение передачи по атрибутам

Иерархический для: FDP ITT. 1

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

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

Зависимости: [FDP ACC.I Ограниченное управление доступом или

FDPJFC. I Ограниченное управление информационными потоками!

FDP_ITT.3 Мониторинг целостности

Иерархический для: Нет подчиненных компонентов.

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

FDP_1TT.3.2 При обнаружении ошибки целостности данных ФБО должны предпринять назначение: действия при ошибке целостности].

Зависимости: [FDP_ACC.l Ограниченное управление доступом или

FDP_1FC. 1 Ограниченное управление информационными потоками! FDPJHT. 1 Базовая защита внутренней передачи

ГОР_ПТ.4 Мониторинг целостности по атрибутам

Иерархический для: FDP_ITT.3

ГОР_ГГТ.4.1 ФБО должны осуществлять [назначение: ПФБ управления доступом и/или ПФБ управления информационными потоками], чтобы контролировать данные пользователя, передаваемые между физически разделенными частями ОО. на наличие следующих ошибок: (назначение: ошибки целостности], основываясь на следующих атрибутах: [назначение: атрибуты безопасности, которые требуют разделения каналов передачи].

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

Зависимости: [FDP ACC.I Ограниченное управление доступом или FDP_IFC. I Ограниченное управление информационными потоками! FDP_1TT.2 Разделение передачи по атрибутам

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

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

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

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

FDP RIP.1 «Ограниченная зашита остаточной информации» содержит требование, чтобы ФБО обеспечили недоступность содержания всей остаточной информации любых ресурсов для определенного подмножества объектов в ОДФ при распределении или освобождении ресурса.

FDP-RIP.2 «Полная зашита остаточной информации» содержит требование, чтобы ФБО обеспечили недоступность содержания всей остаточной информации любых ресурсов для всех объектов при распределении или освобождении ресурса.

Управление: FDP_RIP.l. FDP_RIP.2

Для функций управления из класса F.V1T может рассматриваться следующее действие.

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

Аудит: FDP RIP. 1. FDP RlР.2

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

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

Иерархический для: Нет подчиненных компонентов.

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

Зависимости: отсутствуют.

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

Иерархический для: FDP R1P.1

FDP_RIP.2.1 ФБО должны обеспечить недоступность любого предыдущего информационного содержания ресурсов при (выбор: распределение ресурса, освобождение ресурса} лля всех объектов.

Зависимости: отсутствуют.

6.10 Откат (FDP_ROL)

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

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

сохранить целостность данных пользователя. Ранжирование компонентов

FDP-ROL. 1 «Базовый откат» связан с необходимостью вернуть обратно или отменить ограниченное число операций в определенных пределах.

FDP ROL.2 «Расширенный откат» связан с необходимостью вернуть обратно или отменить все операции в определенных пределах.

Управление: FDP ROLL FDP ROL.2

Для функций управления из класса FMT могут рассматриваться следующие действия.

а) Возможность настройки предела ограничений, до которого возможен откат в пределах 00.

б) Разрешение выполнять операцию отката только вполне определенным ролям.

Аудит: FDP ROL.l. FDP ROL.2

а) Минимальный: все успешные операции отката.

б) Базовый: все попытки выполнить операции отката.

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

FDP_ROI..l Базовый откат

Иерархический для: Нет подчиненных компонентов.

FDP_ROI,.1.1 ФБО должны осуществлять [назначение: ПФБ управления доступом и/или ПФБ управления информационными потоками], чтобы разрешать откат [назначение: список операций] на [назначение: список объектов].

FDP_ROL. 1.2 ФБО должны разрешать откат в пределах [назначение: ограничение выполнения отката].

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

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

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

Иерархический для: FDP ROL.I

FI)P_ROL.2.1 ФБО должны осуществлять (назначение: ПФБ управления доступом и/или ПФБ управления информационными потоками], чтобы разрешать откат всех операций на [назначение: список объектов].

FDP_ROL.2.2 ФБО должны разрешать откат в пределах (назначение: ограничение выполнения отката].

Зависимости: [FDP ACC.I Ограниченное управление доступом или

FDP^IFC.I Ограниченное управление информационными потоками |

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

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

Семейство FDP SD1 содержит требования, связанные с защитой данных пользователя во время их хранения в пределах ОДФ. Ошибки целостности могуг воздействовать на данные пользователя. хранимые как в оперативной памяти, гак и на запоминающих устройствах. Это семейство отличается от семейства FDP ITT «Передача в пределах 00». которое защищает данные пользователя от ошибок целостности во время их передачи в пределах ОО.

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

FDP SOI. 1 «Мониторинг целостности хранимых данных» содержит требование, чтобы ФБ контролировала данные пользователя, хранимые в пределах ОДФ. на наличие идентифицированных ошибок целостности.

FDP_SDI.2 «Мониторинг целостности хранимых данных и предпринимаемые действия» дополняет предыдущий компонент действиями, предпринимаемыми после обнаружения ошибок.

Управление: FDP SDI.I

Действия по управлению нс предусмотрены.

Упраазение: FDP_SDi.2

Для функций управления из класса FMT может рассматриваться следующее действие.

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

Аудит: FDP SDI.I

а) Минимальный: успешные попытки проверки целостности данных пользователя с индикацией результатов проверки.

б) Базовый: все попытки проверки целостности данных пользователя с индикацией результатов проверки, если она была выполнена.

в) Детализированный: тип обнаруженной ошибки целостности.

Аудит: FDPJ5D1.2

в) Детализированный: тип обнаруженной ошибки целостности.

г) Детализированный: действия, предпринимаемые при обнаружении ошибки целостности.

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

Иерархический для: Нет подчиненных компонентов.

FDP_SDI. 1.1 ФБО должны контролировать данные пользователя, хранимые в пределах ОДФ, на наличие [назначение: ошибки целостности] для всех объектов, основываясь на следующих атрибутах: [назначение: атрибуты данных пользователя].

Зависимости: отсутствуют.

FDP_SDI.2 Мониторинг целостности хранимых данных и предпринимаемые действия Иерархический для: FDI_SDI.1

FDP_SDI.2.1 ФБО должны контролировать данные пользователя. хранимые в пределах ОДФ. на наличие [назначение: ошибки целостности] для всех объектов, основываясь на следующих атрибутах: [назначение: атрибуты данных пользователя].

FDP_SDI.2.2 При обнаружении ошибки целостности данных ФБО должны обеспечить [назначение: предпринимаемые действия].

Зависимости: отсутствуют.

6.12 Зашита конфиденциальности данных пользователя при передаче между ФБО (FDP_UCT) Характеристика семейства

Семейство FDP UCT определяет требования по обеспечению конфиденциальности данных пользователя при их передаче по внешнему каналу между 00 и доверенными внешними объектами ИТ или между пользователями ОО и различных доверенных внешних объектов ИТ.

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

Цель компонента FDP_UCT.I «Базовая конфиденциальность обмена данными» состоит в предоставлении зашиты от раскрытия данных пользователя во время их передачи.

Управление: FOP UCT. 1

Действия по управлению нс предусмотрены.

Аудит: FDP„UCT.I

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

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

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

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

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

Иерархический для: Нет подчиненных компонентов.

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

Зависимости: [FTP_ITC.l Доверенный канал передачи между ФБО

или FTP_TRP. I Доверенный маршрут]

[FDP_ACC.l Ограниченное управление доступом или FDP_1FC.1 Ограниченное управление информационными потоками]

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

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

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

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

FDP_UIT. 1 «Целостность передаваемых данных» связан с обнаружением модификации, удалений. вставок и повторения передаваемых данных пользователя.

FDP UIT.2 «Восстановление переданных данных источником» связан с восстановлением исходных данных пользователя, полученных ФБО. с помощью источника — ловеренного продукта ИТ.

FDP UIT.3 «Восстановление переданных данных получателем» связан с самостоятельным восстановлением исходных данных пользователя, полученных ФБО. без какой-либо помощи источника — доверенного продукта ИТ.

Управление: FDP_U1T.I. FDPJJIT.2. FDP U1T.3

Действия по управлению не предусмотрены.

Аудит: FDPU1T.I

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

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

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

г) Базовый: любые идентифицированные попытки блокировать передачу данных пользователя.

д) Детализированный: типы и/или результаты любых обнаруженных модификаций переданных данных пользователя.

Аудит: FDILU1T.2. FDP_UIT.3

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

б) Минимальный: успешное восстановление после ошибок, включая тип обнаруженной ошибки.

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

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

д) Базовый: любые идентифицированные попытки блокировать передачу данных пользователя.

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

FDP_L’IT.l Целостность передаваемых данных

Иерархический для: Нет подчиненных компонентов.

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

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

Зависимости: [FDP_ACC.l Ограниченное управление доступом млн

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

[FTP_ITC.l Доверенный канал передачи между ФБО или FTP_TRP. 1 Доверенный маршрут]

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

Иерархический для: Нет подчиненных компонентов.

FDP_L’IT.2.1 ФБО должны осуществлять [назначение: ПФБ управления доступом и/или ПФБ управления информационными потоками], предоставляющую возможность восстановления после [назначение: список потенциально исправляемых ошибок] с помощью источника — доверенного продукта ИТ.

Зависимости: [FDP_ACC.l Ограниченное управление доступом или

FDP_1FC.1 Ограниченное управление информационными потоками] FTD_LIT. 1 Целостность передаваемых данных FTP_ITC. 1 Доверенный канал передачи между ФБО

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

Иерархический для: FDP U1T.2

FDP_UIT.3.1 ФБО должны осуществлять (назначение: ПФБ управления доступом и/или ПФБ управления информационными потоками]. предоставляющую возможность восстановления после [назначение: список потенциально исправляемых ошибок] без какой-либо помощи источника — доверенного продукта ИТ.

Зависимости: [FDP ACC.I Ограниченное управление доступом или

FDP_IFC.I Ограниченное управление информационными потоками) FDP U IT. I Целостность передаваемых данных FTP 1ТС. 1 Доверенный каши передачи между ФБО

7 Класс FIA. Идентификация и аутентификация

Семейства класса FIA содержат требования к функциям установления и верификации заявленного идентификатора пользователя.

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

Однозначная идентификация уполномоченных пользователей и правильная ассоциация атрибутов безопасности с пользователями и субъектами критичны для осуществления принятых политик безопасности. Семейства этого класса связаны с определением и верификацией идентификаторов пользователей. определением их полномочий на взаимодействие с 00. а также с правильной ассоциацией атрибутов безопасности с каждым уполномоченным пользователем. Эффективность требований других классов (таких, как «Зашита данных пользователя». «Аудит безопасности») во многом зависит от правильно проведенных идентификации и аутентификации пользователей.

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

7.1 Отказы аутентификации (FIA_AFL)

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

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

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

F1A AFL. I «Обработка отказов аутентификации» содержит требование, чтобы ФБО были способны прервать процесс открытия сеанса после определенного числа неуспешных попыток аутентификации пользователя. Также требуется, чтобы после прерывания процесса открытия сеанса ФБО были бы способны блокировать учетные данные пользователя или место входа (например, рабочую станцию), с которого выполнялись попытки, до наступления определенного администратором условия.

Управление: FIA AFL.I

Для функций управления из класса FMT могут рассматриваться следующие действия.

а) Управление ограничениями для неуспешных попыток аутентификации.

б) Управление действиями, предпринимаемыми при неуспешной аутентификации.

Аудит: FIA AFL.1

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

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

Иерархический для: Нет подчиненных компонентов.

FIA_AFL.1.1 ФБО должны обнаруживать, когда произойдет [назначение: число] неуспешных попыток аутентификации, относящихся к [назначение: список событий аутентификации}.

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

Зависимости: FIA_UAU.l Выбор момента аутентификации

7.2 Определение атрибутов пользователя (F1A_ATD)

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

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

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

FIA ATD. 1 «Определение атрибутов пользователя» позволяет поддерживать атрибуты безопасности пользователя для каждого пользователя индивидуально.

Управление FIA ATD. I

Для функций управления из класса FMT могут рассматриваться следующие действия.

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

Аудит: FIA ATD.1

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

FIA_ATD.l Определение атрибутов пользователя

Иерархический для: Нет подчиненных компонентов.

FIA_ATD.1.1 ФБО должны поддерживать для каждого пользователя следующий список а трибутов безопасности: [назначение: список атрибутов безопасности].

Зависимости: отсутствуют.

7.3 Спецификация секретов (F1A_SOS)

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

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

FIA SOS. 1 «Верификация секретов» содержит требование, чтобы ФБО верифицировали, отвечают ли секреты определенной метрике качества.

FIA_SOS.2 «Генерация секретов ФБО» содержит требование, чтобы ФБО были способны генерировать секреты, отвечающие определенной метрике качества.

Управление: FIA SOS.1

Для функций управления из класса F.MT может рассматриваться следующее действие.

а) Управление метрикой, используемой для верификации секретов.

Управление: FIA SOS.2

Для функций управления из класса FMT может рассматриваться следующее действие.

а) Управление метрикой, используемой при генерации секретов.

Аудит: FIA SOS.l. F1A_SOS.2

а) Минимальный: отклонение ФБО любого проверенного секрета.

б) Базовый: отклонение или принятие ФБО любого проверенного секрета.

в) Детализированный: идентификация любых изменений заданных метрик качества.

FIA_SOS.l Верификация секретов

Иерархический для: Нет подчиненных компонентов.

F1A_SOS. 1.1 ФБО должны предоставить механизм для верификации того, что секреты отвечают [назначение: определенная метрика качества].

Зависимости: отсутствуют.

FIA_SOS.2 Генерация секретов ФБО

Иерархический для: Нет подчиненных компонентов.

FIA SOS.2.1 ФБО должны предоставить механизм генерации секретов, отвечающих [назначение: определенная метрика качества}.

FIA_SOS.2.2 ФБО должны быть способны использовать генерируемые ими секреты для [назначение: список функций

Зависимости: отсутствуют.

7.4 Аутентификация пользователя (FIA_VAU)

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

Семейство FIA UAU определяет типы механизмов аутентификации пользователя, предоставляемые ФБО. Оно также определяет те атрибуты, на которых необходимо базировать механизмы аутенти-ф и ка и и и и ол ьзо вате л я.

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

Fl A UAU. I «Выбор момента аутентификации» позволяет пользователю выполнить некоторые действия до аутентификации пользователя.

FIA_UAU.2 «Аутентификация до любых действий пользователя* содержит требование, чтобы пользователи прошли аутентификацию прежде, чем ФБО даст им возможность предпринимать какие-либо действия.

FIA UAU.3 «Аутентификация, защищенная от подделок» содержит требование, чтобы механизм аутентификации был способен выявить аутентификационные данные, которые были фальсифицированы или скопированы, и предотвратить их использование.

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

FIAUAU.5 «Сочетание механизмов аутентификации» содержит требование предоставления и применения различных механизмов аутентификации пользователей в особых случаях.

FIA UAU.6 «Повторная аутентификация» содержит требование возможности определения событий. при которых необходима повторная аутентификация пользователя.

FIA_UAU.7 «Аутентификация с защищенной обратной связью» содержит требование, чтобы во время аутентификации пользователю предоставлялась строго ограниченная информация о ней.

Управление: F1A_UAU. 1

Для функций управления из класса FMT могут рассматриваться следующие действия.

а) Управление аутентификационными данными администратором.

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

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

Управление: FIA UAU.2

Для функций управления из класса FMT могут рассматриваться следующие действия, а) Управление аутентификационными данными администратором.

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

Управление: FIA UAU.l HA_UAU.4. FIA. UAU.7

Действия по управлению нс предусмотрены.

Упраазение: FIA UAU.5

Для функций управления из класса FMT могут рассматриваться следующие действия.

а) Управление механизмами аутентификации.

б) Управление правилами аутентификации.

Управление: FIA_UAU.6

Для функций управления из класса F.MT может рассматриваться следующее действие.

а) Управление запросом на повторную аутентификацию, если для уполномоченного администратора предусмотрена возможность такого запроса.

Аудит: FIA„UAU.1

а) Минимальный: неуспешное использование механизма аутентификации.

б) Базовый: все случаи использования механизма аутентификации.

в) Детализированный: все действия при посредничестве ФБО до аутентификации пользователя. Аудит: FIAUAU.2

Если в ПЗ/ЗБ включено семейство FAU.GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих дей-ствий/событий/параметров.

а) Минимальный: неуспешное использование механизма аутентификации.

б) Базовый: все случаи использования механизма аутентификации.

Лудит: FIA UAU.3

а) Минимальный: обнаружение фальсифицированных аутентификационных данных.

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

Лудит: FIA_UA(J.4

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

Лудит; FIAJJAU,5

а) Минимальный: итоговое решение аутентификации.

б) Базовый: результат действия каждого активизированного механизма вместе с итоговым решением.

Аудит: FIAUAU.6

а) Минимальный: неуспешная повторная аутентификация.

б) Базовый: все попытки повторной аутентификации.

Аудит: FIAUAU.7

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

FIA_UAU.l Выбор момента аутентификации Иерархический для: Нет подчиненных компонентов.

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

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

Зависимости: FIA_U1D.1 Выбор момента идентификации

F1A_UAU.2 Аутентификация до любых действий пользователя

Иерархический для: FIA_UAU.l

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

Зависимости: FIAJJID.1 Выбор момента идентификации

FIA_UAU.3 Аутентификация, защищенная от подделок Иерархический для: Нет подчиненных компонентов.

FIA_UAU.3.1 ФБО должны [выбор: обнаруживать, предотвращать] применение любым пользователем ФБО аутентифицированных данных, когорые были подделаны.

FIA_UAU.3.2 ФБО должны [выбор: обнаруживать, предотвращать] применение любым пользователем ФБО аутентифицированных данных, которые были скопированы у какого-либо другого пользователя ФБО.

Зависимости: отсутствуют.

FIA_UAU.4 Механизмы одноразовой аутентификации

Иерархический для: Нет подчиненных компонентов.

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

Зависимости: отсутствуют.

F1A_UAU.5 Сочетание механизмов аутентификации

Иерархический для: Нет подчиненных компонентов.

FIA_UAU.5.1 ФБО должны предоставлять [назначение: список сочетаемых механизмов аутентификации] для поддержки аутентификации пользователя.

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

Зависимости: отсутствуют.

FIA_UAU.6 Повторная аутентификация

Иерархический для: Нет подчиненных компонентов.

FIA_UAU.6.1 ФБО должны повторно аутентифицировать пользователя при [назначение: список условий, при которых требуется повторная аутентификация].

Зависимости: отсутствуют.

FIA_UAU.7 Аутентификация с защищенной обратной связью

Иерархический для: Нет подчиненных компонентов.

FIA_UAU.7.1 ФБО должны предоставлять пользователю только [назначение: список допустимой информации обратной саязи] во время выполнения аутентификации.

Зависимости: F1A_UAU.I Выбор момента аутентификации

7.5 Идентификация пользователя (FIA_UID)

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

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

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

FIA U1D.1 «Выбор момента идентификации» позволяет пользователю выполнить некоторые действия перед своей идентификацией с использованием ФБО.

FIAJJ1D.2 «Идентификация до любых действий пользователя» содержит требование, чтобы пользователи идентифицировали себя прежде, чем ФБО позволяет им предпринимать какие-либо действия. Управление: FlA_UID.l

Для функций управления из класса FMT могут рассматриваться следующие действия.

а) Управление идентификаторами пользователей.

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

Управление: FIA UID.2

Для функций управления из класса FMT может рассматриваться следующее действие.

а) Управление идентификаторами пользователей.

Лудит: FJAUID.l, FIA„U1D.2

Если в ПЗ/ЗБ включено семейство FAU GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих дей-ствий/событий/параметров.

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

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

FIA_U1D. 1 Выбор момента идентификации

Иерархический для: Нет подчиненных компонентов.

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

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

Зависимости: отсутствуют.

F1A_U1D.2 Идентификация до любых действий пользователя

Иерархический для: FIA UID. 1

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

Зависимости: отсутствуют.

7.6 Связывание пользователь—субъект (FIA_USB)

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

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

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

FIA_USB. 1 «Связывание пользователь—субъект» содержит требование сопровождения ассоциации между атрибутами безопасности пользователя и субъектом, действующим от имени пользователя. Управление: FIA_USB.l

Для функций управления из класса FMT может рассматриваться следующее действие.

а) Переопределение уполномоченным администратором заданных по умолчанию атрибутов безопасности субъекта.

Лудит: FIA_USB. I

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

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

FIA_USB. I Связывание пользователь—субъект

Иерархический для: Нет подчиненных компонентов.

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

Зависимости: FIA_ATD.l Определение атрибутов пользователя

8 Класс FMT. Управление безопасностью

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

Класс позволяет решать следующие задачи:

а) Управление данными ФБО. которые включают в себя, например, предупреждающие сообщения.

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

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

г) Определение ролей безопасности.

Декомпозиция класса FMT на составляющие его компоненты приведена на рисунке 8.1.

Рисунок 8.1 — Декомпозиция класса •Управление безопасностью»

8.1 Управление отдельными функциями ФБО (FMT_MOF)

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

Семейство FMT.MOF позволяет уполномоченным пользователям управлять функциями из числа ФБО. К ним относятся, например, функции аудита и аутентификации.

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

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

Управление: FMT_MOF.l

Для функций управления из класса ГМТ может рассматриваться следующее действие.

а) Управление группой ролей, которые могут взаимодействовать с функциями из числа ФБО. Аудит: FMT_MOF.l

Если в П’З/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих дей-ствий/событий/парамегров.

а) Базовый: все модификации режима выполнения функций из числа ФБО.

FMT_MOF.I Управление режимом выполнения функций безопасности

Иерархический для: Нет подчиненных компонентов.

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

Зависимости: FMTJ5MR.I Роли безопасности

8.2 Управление атрибутами безопасности (FMT_MSA)

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

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

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

FMT_MSA.I «Управление атрибутами безопасности» позволяет уполномоченным пользователям (ролям) управлять определенными атрибутами бе зопасности.

FMT MSA.2 «Безопасные значения атрибутов безопасности» обеспечивает, чтобы значения, присвоенные атрибутам безопасности, были допустимы по безопасности.

ГМТ MSA.3 «Инициализация статических атрибутов* обеспечивает, чтобы значения атрибутов безопасности по умолчанию являлись ио своей сути либо разрешающими, либо ограничительными.

Управление: ГМТ MSA. 1

Для функций управления из класса FMT может рассматриваться следующее действие.

а) Управление группой ролей, которые могут оперировать атрибутами безопасности.

Управление: FMT_MSA.2

Действия по управлению не предусмотрены.

Упраачснис: FMT MSA.3

Для функций управления из класса FMT могут рассматриваться следующие действия.

а) Управление группой ролей, которые могут определять начальные значения.

б) Управление установкой разрешающих или ограничительных значений по умолчанию для данной ПФБ управления доступом.

Аудит: FMT MSA.I

а) Базовый: все модификации значений атрибутов безопасности.

Аудит: FMT MSA.2

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

б) Легализированный: все предлагаемые и принятые безопасные значения атрибутов безопасности.

Аудит: FMT MSA.3

а) Базовый: модификации настройки по умолчанию разрешающих или ограничительных правил.

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

FMT_MSA. 1 Управление атрибутами безопасности

Иерархический для: Нет подчиненных компонентов.

FMT_MSA.1.1 ФБО должны осуществлять [назначение: ПФБ управления доступом, ПФБуправления информационными потоками}, чтобы ограничить возможность [выбор: изменение значении по умолчанию, запрос, модификация, удаление], [назначение: другие операции] атрибутов безопасности [назначение: список атрибутов безопасности] только [назначение: уполномоченные идентифицированные роли].

Зависимости: [FDP_ACC.l Ограниченное управление доступом или

FDP_IFC. 1 Ограниченное управление информационными потоками] FMT.SMR.1 Роли безопасности

FMT_MSA.2 Безопасные значения атрибутов безопасности

Иерархический для: Нет подчиненных компонентов.

FMT_MSA.2.1 ФБО должны обеспечить присвоение атрибутам безопасности только безопасных значений.

Зависимости: ADV_SPM.1 Неформальная модель политики безопасности ОО

[FDP_ACC.I Ограниченное управление доступом или

FDP_1FC. 1 Ограниченное управление информационными потоками] FMT_MSA. I Управление атрибутами безопасности FMT_SMR.l Роли безопасности

FMT_MSA.3 Инициализация статических атрибутов

Иерархический для: Нет подчиненных компонентов.

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

FMT_MSA.3.2 ФБО должны предоставить возможность [назначение: уполномоченные идентифицированные роли] определять альтернативные начальные значения для отмены значений по умолчанию при создании объекта или информации.

Зависимости: FMT_MSA.l Управление атрибутами безопасности

FMT_SMR.l Роли безопасности

8.3 Управление данными ФБО (FMT_MTD)

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

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

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

FMT MTD. 1 «Управление данными ФБО» позволяет уполномоченным пользователям управлять данными ФБО.

FMT MTD.2 «Управление ограничениями данных ФБО» определяет действия, предпринимаемые при достижении или превышении ограничений данных ФБО.

FMT MTD.3 «Безопасные данные ФБО» обеспечивает, чтобы значения, присвоенные данным ФБО. были допустимы по безопасности.

Управление: FMT MTD.1

Для функций управления из класса FMT может рассматриваться следующее действие.

а) Управление группой ролей, которые могут оперировать данными ФБО.

Управление: FMT_MTD.2

Для функций управления и з класса FMT может рассматриваться следующее действие.

а) Управление группой ролей, которые могут оперировать ограничениями данных ФБО.

Управление: FMT^MTD.3

Действия по управлению не предусмотрены.

Аудит: FMT_MTD. 1

а) Базовый: все модификации значений данных ФБО.

Аудит: FMT_MTD.2

а) Базовый: все модификации ограничений данных ФБО.

б) Базовый: все модификации действий, предпринимаемых при нарушениях ограничений.

Аудит: FMT MTD.3

а) Минимальный: все отклоненные значения данных ФБО.

FMT_MTD. 1 Управление данными ФБО

Иерархический для: Нет подчиненных компонентов.

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

Зависимости: FMT_SMR.I Роли безопасности

FMT-MTD.2 Управление ограничениями данных ФБО

Иерархический для: Нет подчиненных компонентов.

FMT_.MTD.2.1 ФБО должны предоставить возможность опреде.зения ограничений следующих данных [назначение: список данных ФБО] только [назначение: уполномоченные идентифицированные роли].

FMT_MTD.2.2 ФБО должны предпринять следующие действия при достижении или превышении данными ФБО установленных выше ограничений: [назначение: предпринимаемые действия].

Зависимости: FMT.MTD. 1 Управление данными ФБО

FMT_SMR.1 Роли безопасности

FMT.MTD.3 Безопасные данные ФБО

Иерархический для: Нет подчиненных компонентов.

FMT.MTD.3.1 ФБО должны обеспечить присвоение данным ФБО только безопасных значений. Зависимости: ADV.SPM.1 Неформальная модель политики безопасности ОО

FMT.MTD.1 Управление данными ФБО

8.4 Отмена (FMT.REV)

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

Семейство FMT.REV связано с отменой атрибутов безопасности различных сущностей в пределах ОО.

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

FMT.REV. 1 «Отмена» предусматривает отмену атрибутов безопасности, осуществляемую в некоторый момент времени.

Упраачение: FMT.REV. I

Для функций управления из класса FMT могут рассматриваться следующие действия.

а) Управление группой ролей, которые могут вызывать отмену атрибутов безопасности.

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

в) Управление правилами отмены.

Аудит: FMT.REV. I

а) Минимальный: неуспешная отмена атрибутов безопасности.

б) Базовый: все попытки отменить атрибуты безопасности.

FMT.REV. 1 Отмена

Иерархический для: Нет подчиненных компонентов.

FMT.REV. 1.1 ФБО должны ограничить возможность отмены атрибутов безопасности, ассоциированных с (выбор: пользователи, субъекты, объекты, другие дополнительные ресурсы], в пределах ОДФ только [назначение: уполномоченные идентифицированные роли].

FMT.REV. 1.2 ФБО должны реализовать правила [назначение: правила отмены].

Зависимости: FMT.SMR. I Роли безопасности

8.5 Срок действия атрибута безопасности (FMT.SAE)

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

Семейство FMT.SAE связано с возможностью установления срока действия атрибутов безопасности.

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

FMT.SAE.I «Ограниченная повремени авторизация» предоставляет возможность уполномоченному пользователю устанавливать срок действия определенных атрибутов безопасности.

Управление: FMT.SAE.I

Для функций управления и з класса FMT могут рассматриваться следующие действия.

а) Управление списком атрибутов безопасности с назначенным сроком действия.

б) Предпринимаемые по истечении назначенного срока действия.

Аудит: FMT SAE.1

а) Базовый: назначение срока действия для атрибута.

б) Базовый: действия, предпринятые по истечении назначенного срока.

FMT_SAE.l Ограниченная по времени авторизация

Иерархический для: Нет подчиненных компонентов.

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

FMT_S/\E.i.2 Для каждого из этих атрибутов безопасности ФБО должны быть способны к [назначение: список действий, предпринимаемых для каждого атрибута безопасности] по истечении его срока действия.

Зависимости: FMT.SMR.1 Роли безопасности

FPT-STM.1 Надежные метки времени

8.6 Роли управления безопасностью (FMT_SMR)

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

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

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

FMT SMR. 1 «Роли безопасности» определяет роли, относящиеся к безопасности и распознаваемые ФБО.

FMT SMR.2 «Ограничения на роли безопасности» определяет, что в дополнение к определению ролей имеются правила, которые управляют отношениями между ролями.

FMT SMR.3 «Принятие ратей» содержит требование, чтобы принятие роли производилось только через точный запрос к ФБО.

Управление: FMT SMR. 1

Для функций управления из класса FMT может рассматриваться следующее действие.

а) Управление группой пользователей — исполнителей роли.

Управление: FMT SMR.2

Для функций управления из класса FMT могут рассматриваться следующие действия.

а) Управление группой пользователей — исполнителей роли.

б) Управление условиями, которым должны удовлетворять роли.

Управление: FMT_SMR.3

Действия по управлению не предусмотрены.

Аудит: FMT SMR. 1

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

б) Детализированный: каждое использование прав, предоставленных ролью.

Аудит: FMTJiMR.2

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

б) Минимальный: неуспешные попытки использовать роль вследствие ограничений, накладываемых на роли.

в) Легализированный: каждое использование прав, предоставленных ролью.

Аудит: FMT_SMR.3

а) Минимальный: конкретные запросы на принятие роли.

FMT.SMR.1 Роли безопасности

Иерархический для: Нет подчиненных компонентов.

FMT_SMR.1.1 ФБО должны поддерживать следующие роли [назначение: уполномоченные идентифицированные роли].

FMT_SMR. 1.2 ФБО должны быть способны ассоциировать пользователей с ролями.

Зависимости: F1A_U1D.1 Выбор момента идентификации

FMT_SMR.2 Ограничения на роли безопасности

Иерархический для: FMT_SMR.l

FMT_SMR.2.1 ФБО должны поддерживать следующие роли [назначение: уполномоченные идентифицированные роли].

FMT_SMR.2.2 ФБО должны быть способны ассоциировать пользователей с ролями.

FMT_SMR.2.3 ФБО должны обеспечить выполнение [назначение: условия для различных ролей]. Зависимости: F1A_U1 D. 1 Выбор момента идентификации

FMTJSMR.3 Принятие ролей

Иерархический для: Нет подчиненных компонентов.

FMT_SMR.3.1 ФБО должны требовать точный запрос для принятия следующих ролей [назначение: список ролей].

Зависимости: FMT.SMR.1 Роли безопасности

9 Класс FPR. Приватность

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

Декомпозиция класса FPR на составляющие его компоненты приведена на рисунке 9.1.

Рисунок 9.1 — Декомпозиция класса «Приватность»

9.1 Анонимность (FPR_ANO)

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

Семейство FPR ANO обеспечивает, чтобы пользователь мог использовать ресурс или услуг)’ 00 без раскрытия своего идентификатора. Требования семейства предоставляют защиту идентификатора пользователя. Семейство нс предназначено для защиты идентификаторов субъектов.

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

FPR ANO.1 «Анонимность» содержит требование, чтобы другие пользователи или субъекты нс могли определить идентификатор пользователя, связанного с субъектом или операцией.

FPRANO.2 «Анонимность без запроса информации» расширяет требования FPR ANO. 1. обеспечивая. чтобы ФБО не запрашивали идентификатор пользователя.

Управление: FPR. ANO.I. FPR ANO.2

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

Аудит: FPR_ANO.l. FPR_AN0.2

Если в ГГЗ/ЗБ включено семейство FAU_GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих дей-ствий/событий/параметров.

а) Минимальный: обращение к механизму анонимности.

FPR_ANO.I Анонимность

Иерархический для: Нет подчиненных компонентов.

FPR_ANO.1.1 ФБО должны обеспечить, чтобы [назначение: совокупность пользователей и/или субъектов] была не способна определить подлинное имя пользователя, связанного с [назначение: список субъектов и/или операций, и/или объектов].

Зависимости: отсутствуют.

FPR_ANO.2 Анонимность без запроса информации

Иерархический для: FPR_ANO.I

FPR_ANO.2.1 ФБО должны обеспечить, чтобы [назначение: совокупность пользователей и/или субъектов] была не способна определить подлинное имя пользователя, свя энного с [назначение: список субъектов и/или операций, и/или объектов].

FPR_ANO.2.2 ФБО должны предоставить [назначение: список услуг] для [назначение: список субъектов] без запроса какой-либо ссылки на подлинное имя пользователя.

Зависимости: отсутствуют.

9.2 Псевдонимность (FPR_PSE)

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

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

Ранжировав I ис ком i юней гов

FPR PSE. 1 «Псевдонимность» содержит требование, чтобы некоторая совокупность пользователей и/или субъектов была не способна определить идентификатор пользователя. связанного с субъектом или операцией, но в то же время этот пользователь оставался ответственным за свои действия.

FPR PSE.2 «Обратимая псевдонимность» содержит гребование. чтобы ФБО предоставили возможность определить первоначальный идентификатор пользователя, основываясь на представленном псевдониме.

FPR PSE.3 «Альтернативная псевдонимность» содержит требование, чтобы при создании псевдонима для идентификатора пользователя ФБО следовали определенным правилам.

Управление: FPR PSE.l. FPR_PSE.2. FPR PSE.3

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

Аудит: FPR_ PSE.l, FPR PSE.2. FPR PSE.3

а) Минимальный: идентификатор субъекта/пользователя. который потребовал раскрытия идентификатора пользователя.

FPR_PSE.l Псевдоннмность

Иерархический для: Нет подчиненных компонентов.

FPR_PSE.1.1 ФБО должны обеспечить, чтобы [назначение: совокупность пользователей и/или субъектов] была нс способна определить подлинное имя пользователя, связанного с [назначение: список субъектов и/или операций, и/или объектов].

FPR_PSE.1.2 ФБО должны быть способны предоставить [назначение: количество псевдонимов] псевдонимов подлинного имени пользователя для [назначение: список субъектов].

FPR_PSE.1.3 ФБО должны быть способны [выбор: определить псевдоним пользователя, принять псевдоним от пользователя] и верифицировать его соответствие [назначение: метрика псевдонимов].

Зависимости: отсутствуют.

FPR_PSE.2 Обратимая псевдоннмность

Иерархический для: FPR PSE.1

FPR_PSE.2.I ФБО должны обеспечить, чтобы [назначение: совокупность пользователей и/или субъектов] была не способна определить подлинное имя пользователя, связанное с [назначение: список субъектов и/или операций, и/или объектов].

FPR_PSE.2.2 ФБО должны быть способны предоставить [назначение: количество псевдонимов] псевдонимов подлинного имени пользователя для [назначение: список субъектов].

FPR_PSE.2.3 ФБО должны быть способны [выбор: определить псевдоним пользователя, принять псевдоним от пользователя] и верифицировать его соответствие [назначение: метрика псевдонимов].

FPR_PSE.2.4 ФБО должны предоставить [выбор: уполномоченный пользователь, [назначение: список доверенных субъектов] возможность определять идентификатор пользователя по представленному псевдониму только при выполнении [назначение: список условий].

Зависимости: FIA_UID.l Выбор момента идентификации

FPR_PSE.3 Альтернативная псевдоннмность

Иерархический для: FPR PSE.l

FPR_PSE.3.1 ФБО должны обеспечить, чтобы [назначение: совокупность пользователей и/или субъектов] была не способна определить подлинное имя пользователя, связанного с [назначение: список субъектов и/или операций, и/или объектов].

FPR_PSE.3.2 ФБО должны быть способны предоставить [назначение: количество псевдонимов] псевдонимов подлинного имени пользователя для [назначение: список субъектов].

FPR_PSE.3.3 ФБО должны быть способны [выбор: определить псевдоним пользователя, принять псевдоним от пользователя] и верифицировать его соответствие [назначение: метрика псевдонимов].

FPR_PSE.3.4 ФБО должны предоставить псевдоним для подлинного имени пользователя, который должен быть идентичен псевдониму, предоставленному ранее, при следующих условиях [назначение: список условий]’, в противном случае предоставляемый псевдоним должен быть не связан с предоставленными ранее псевдонимами.

Зависимости: отсутствуют.

9.3 Невозможность ассоциации (FPR_UNL)

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

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

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

FPR UNL.1 «Невозможность ассоциации» содержит требование. чтобы пользователи и/или субъекты были нс способны определить, были ли определенные операции в системе инициированы одним и тем же пользователем.

Управление: FPR UNL.1

Для функций управления из класса FMT может рассматриваться следующее действие, а) Управление функцией предотвращения ассоциации.

Аудит: FPRUNL.1

Если в ПЗ/ЗБ включено семейство FAU GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих дей-ствий/событий/параметров.

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

FPR_UNL.l Невозможность ассоциации

Иерархический для: Нет подчиненных компонентов.

FPR_UNL.1.1 ФБО должны обеспечить, чтобы [назначение: совокупность пользователей и/или субъектов] была не способна определить, что [назначение: список операций] [выбор: были инициированы одним и тем же пользователем, связаны следующим образом] [назначение: список соотношений].

Зависимости: отсутствуют.

9.4 Скрытность (FPR.UNO)

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

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

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

FPR..UNO.1 «Скрытность» содержит требование, чтобы пользователи и/или субъекты не могли определить, выполняется ли операция.

FPR UNO.2 «Распределение информации, влияющее на скрытность» содержит требование, чтобы ФБО предоставили специальные механизмы для предотвращения концентрации информации, связанной с приватностью, в пределах ОО. Такая концентрация могла бы повлиять на обеспечение скрытности при нарушениях безопасности.

FPR UNO.3 «Скрытность без запроса информации» содержит требование. чтобы ФБО нс пытались получить информацию, связанную с приватностью, что может использоваться для нарушения скрытности.

FPR_UN0.4 «Открытость для уполномоченного пользователя» содержит требование, чтобы ФБО предоставили одному или нескольким уполномоченным пользователям возможность наблюдать за использованием ресурсов и/или услуг.

Упрааление: FPR_UNO.I. FPR_UNO.2

Для функций упрааления из класса F.MT может рассматриваться следующее действие.

а) Упрааление режимом выполнения функции скрытности.

Упрааление: FPRJJNO.3

Действия по управлению для этого компонента не предусмотрены.

Упрааление: FPR UNO.4

Для функций упрааления из класса F.MT может рассматриваться следующее действие.

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

Аудит: FPR UNO.l. FPR UNO.2

а) Минимальный: обращение к механизму скрытности.

Аудит: FPRUNO.3

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

Аудит: FPRUNO.4

а) Минимальный: наблюдение за использованием ресурса или услуги пользователем или субъектом.

FPR_UNO.l Скрытность

Иерархический для: Нет подчиненных компонентов.

FPR_UNO.1.1 ФБО должны обеспечить, чтобы (назначение: совокупность пользователей и/или субъектов} была не способна наблюдать следующие операции [назначение: список операций} на [назначение: список объектов}, выполняемые [назначение: совокупность защищаемых пользователей и/или субъектов}.

Зависимости: отсутствуют.

FPR_UNO.2 Распределение информации, влияющее на скрытность

Иерархический для: FPR_UNO.l

FPR_UNO.2.1 ФБО должны обеспечить, чтобы (назначение: совокупность пользователей и/или субъектов} была не способна наблюдать следующие операции (назначение: список операций} на [назначение: список объектов}. выполняемые [назначение: совокупность защищаемых пользователей а/ши субъектов}.

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

Зависимости: отсутствуют.

FPR_UNO.3 Скрытность без запроса информации

Иерархический для: Нет подчиненных компонентов.

FPR_UNO.3.1 ФБО должны предоставить [назначение: список услуг] для [назначение: список субъектов} без запроса каких-либо ссылок на [назначение: информация, связанная с приватностью}.

Зависимости: FPR_UNO.l Скрытность

FPR_UNO.4 Открытость для уполномоченного пользователя

Иерархический для: Нет подчиненных компонентов.

FPR_UNO.4.1 ФБО должны предоставить [назначение: совокупность уполномоченных пользователей} возможность наблюдать за использованием [назначение: список ресурсов и/или ус.гуг].

Зависимости: отсутствуют.

10 Класс FPT. Защита ФБО

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

В рамках этого класса выделяются три существенные составные части ФБО.

а) Абстрактная машина ФБО, т. е. виртуальная или физическая машина, на которой выполняется оцениваемая реализация <1>БО.

б) Реализация ФБО. которая выполняется на абстрактной машине и реализует механизмы, осуществляющие ПБО.

в) Данные ФБО. которые являются административными базами данных, управляющими осуществлением ПБО.

Декомпозиция класса ГРТ на составляющие его компоненты приведена на рисунках 10.1 и 10.2.

Рисунок 10.1 — Декомпозиция класса «Защита ФБО»

Рисунок 10.2 — Декомпозиция класса «Зашита ФБО» (продолжение)

10.1 Тестирование базовой абстрактной машины (FPT_AMT)

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

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

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

FPT АМТ. 1 «Тестирование абстрактной машины» предоставляет возможность проверки базовой абстрактной машины.

Управление: FPT.AMT.)

Для функций управления из класса FMT могут рассматриваться следующие действия.

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

б) Управление временном интервалом (если такое управление предусмотрено).

Аудит: FPTAMT. I

а) Базовый: выполнение тестирования базовой машины и результаты тестирования.

5 1-1523

FPT_AMT.l Тестирование абстрактной машины

Иерархический для: Нет подчиненных компонентов.

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

Зависимости: отсутствуют.

10.2 Безопасность при сбое (FPT_FLS) Характеристика семейства

Требования семейства FPT_FLS обеспечивают, чтобы 00 не нарушал свою политику безопасности при сбоях ФБО идентифицированных типов.

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

Это семейство состоит из одного компонента. FPT FLS. 1 «Сбой с сохранением безопасного состояния*, содержащего требование, чтобы ФБО сохранили безопасное состояние при идентифицированных сбоях.

Управление: FPT FLS.1

Действия по управлению не предусмотрены.

Аудит: FPT_FLS.I

а) Базовый: сбой ФБО.

FPT_FLS. I Сбой с сохранением безопасного состояния

Иерархический для: Нет подчиненных компонентов.

FPTJFLS. 1.1 ФБО должны сохранить безопасное состояние при следующих типах сбоев: [назначение: список типов сбоев ФБО].

Зависимости ADV_SPM.l Неформальная модель политики безопасности ОО

10.3 Доступность экспортируемых данных ФБО (FPT_ITA)

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

Семейство ГРТ_1ТА определяет правила предотвращения потери доступности данных ФБО. передаваемых между ФБО и удаленным доверенным продуктом ИТ. Это могут быть, например, критичные данные ФБО типа паролей, ключей, данных аудита или выполняемого кода ФБО.

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

Это семейство состоит из одного компонента FPT_1TA. 1 «Доступность экспортируемых данных ФБО в пределах заданной метрики», содержащего требование, чтобы ФБО обеспечили с заданной вероятностью доступность данных ФБО. прелоетавлясмых удаленному доверенному продукту ИТ.

Управление: FPT ITA.1

Для функций управления из класса F.MT может рассматриваться следующее действие.

а) Управление списком типов данных ФБО. для которых необходимо, чтобы они были доступны удаленному доверенному продукту ИТ.

Аудит: FPTJTA.I

Если в ПЗ/ЗБ включено семейство FAU GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих дей-ствий/событий/параметров.

а) Минимальный: отсутствие данных ФБО. когда они запрошены ОО.

FPT_ITA.l Доступность экспортируемых данных ФБО в пределах заданной метрики Иерархический для: Нет подчиненных компонентов.

FPT_ITA. 1.1 ФБО должны обеспечить доступность [назначение: список типов данных ФБО] для удаленного доверенного продукта ИТ в пределах [назначение: заданная метрика доступности] при выполнении следующих условий [назначение: условия обеспечения доступности].

Зависимости: отсутствуют.

10.4 Конфиденциальность экспортируемых данных ФБО (FPT.1TC)

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

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

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

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

Управление: FPTJTC.I

Действия по управлению нс предусмотрены.

Аудит: FPTJTC.I

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

FPT JTC. 1 Конфиденциальность экспортируемых данных ФБО при передаче

Иерархический для: Нет подчиненных компонентов.

FPTJTC. 1.1 ФБО должны защищать все данные ФБО, передаваемые от ФБО к удаленному доверенному продукту ИТ, от несанкционированного раскрытия при передаче.

Зависимости: отсутствуют.

10.5 Целостность экспортируемых данных ФБО (FPT_1T1)

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

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

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

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

FPT ITI.2 «Обнаружение и исправление модификации экспортируемых данных ФБО» позволяет удаленному доверенному продукт)’ ИТ не только обнаружить модификацию, но и восстановить данные ФБО. модифицированные при передаче от ФБО. при допущении, что последнему известен используемый механизм передачи.

Управление: FPTJTI.I

Действия по управлению не предусмотрены.

Управление: FPTJTI.2

Для функций управления из класса FMT могут рассматриваться следующие действия.

а) Управление типами данных ФБО. которые ФБО следует пытаться исправить, если они модифицированы при передаче.

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

Аудит: FPT_1T1.1

а) .Минимальный: обнаружение модификации передаваемых данных ФБО.

б) Базовый: действия, предпринятые при обнаружении модификации передаваемых данных ФБО. Аудит: FPTJT1.2

а) Минимальный: обнаружение модификации передаваемых данных ФБО.

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

в) Базовый: использование механизма восстановления.

FPT_1T1.1 Обнаружение модификации экспортируемых данных ФБО

Иерархический для: Нет подчиненных компонентов.

ЕРТ_1Т1.1.1 ФБО должны предоставить возможность обнаружить модификацию любых данных ФБО при передаче между ФБО и удаленным доверенным продуктом ИТ в пределах следующей метрики: (назначение: метрика модификации}.

FPT_ITI.1.2 ФБО должны предоставить возможность верифицировать целостность всех данных ФБО при их передаче между ФБО и удаленным доверенным продуктом ИТ и выполнить (назначение: предпринимаемые действия], если модификация обнаружена.

Зависимости: отсутствуют.

FPT_1TI.2 Обнаружение и исправление модификации экспортируемых данных ФБО Иерархический для: FPT 1TI. 1

FPT_1TI.2.1 ФБО должны предоставить возможность обнаружить модификацию любых данных <1>БО при передаче между ФБО и удаленным доверенным продуктом ИТ в пределах следующей метрики: (назначение: метрика модификации].

FPT_ITI.2.2 ФБО должны предоставить возможность верифицировать целостность всех данных ФБО при их передаче между ФБО и удаленным доверенным продуктом ИТ и выполнить (назначение: предпринимаемые действия], если модификация обнаружена.

FPT_1TI.2.3 ФБО должны предоставить возможность исправить [назначение: тип модификации] все данные ФБО, передаваемые между ФБО и удаленным доверенным продуктом ИТ.

Зависимости: отсутствуют.

10.6 Передача данных ФБО в пределах ОО (FPT_ITT)

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

Семейство FPT ITT предоставляет требования защиты данных ФБО при их передаче между разделенными частями ОО по внугреннему каналу.

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

FPT ITT.1 «Базовая защита внутренней передачи данных ФБО» содержит требование, чтобы данные ФБО были защищены при их передаче между разделенными частями ОО.

FPT ГГТ.2 «Разделение данных ФБО при передаче» содержит требование, чтобы при передаче ФБО отделяли данные пользователей отданных ФБО.

FPT 1ТГ.З «Мониторинг целостности данных ФБО» содержит требование, чтобы данные ФБО. передаваемые между разделенными частями ОО, контролировались на идентифицированные ошибки целостности.

Управление: FPT ITT.I

Для функций управления из класса FMT могут рассматриваться следующие действия.

а) Управление типами модификации, от которых ФБО следует защищать передаваемые данные.

б) Управление механизмом, используемым для обеспечения зашиты данных при передаче между различными частями ФБО.

Управление: FPT 1ТТ.2

Для функций управления из класса FMT могут рассматриваться следующие действия.

а) Управление типами модификации, от которых ФБО следует защищать передаваемые данные.

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

в) Управление механизмом разделения данных.

Управление: FPT ITT.3

Для функций управления из класса FMT могут рассматриваться следующие действия.

а) Управление типами модификации, от которых ФБО следует защищать передаваемые данные.

в) Управление типами модификации данных ФБО. которые ФБО следует пытаться обнаружить.

г) Управление действиями, предпринимаемыми после обнаружения модификации.

Аудит: FPTJTT.I. FPTJTT.2

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

Аудит: FPT 1ТТ.З

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

а) Минимальный: обнаружение модификации данных ФБО.

б) Базовый: действия, предпринятые после обнаружения ошибок целостности.

FP1 _1ТТ. 1 Базовая защита внутренней передачи данных ФБО

Иерархический для: Нет подчиненных компонентов.

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

Зависимости: отсутствуют.

FPT_ITT.2 Разделение данных ФБО при передаче

Иерархический для: FPT ITT. 1

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

FPT_ITT.2.2 ФБО должны отделить данные пользователя от данных ФБО при их передаче между разделенными частями ОО.

Зависимости: отсутствуют.

FPT_ITT.3 Мониторинг целостности данных ФБО Иерархический для: Нет подчиненных компонентов.

FPT_ITT.3.1 ФБО должны быть способны обнаружить [выбор: модификация данных, подмена данных, перестановка данных, удаление данных, [назначение: другие ошибки целостности]] в данных ФБО, передаваемых между разделенными частями ОО.

FPT-ITT.3.2 При обнаружении ошибки целостности данных ФБО должны предпринять следующие действия: [назначение: выполняемые действия].

Зависимости: FPT_ITT.l Базовая защита внутренней передачи данных ФБО

10.7 Физическая защита ФБО (FPT_PIIP)

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

Компоненты семейства FPT РНРдают возможность ограничивать физический доступ к ФБО. а также реагировать на несанкционированную физическую модификацию или подмену реализации ФБО и противодействовать им.

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

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

ГРТ_РНР. 1 «Пассивное обнаружение физического нападения» предоставляет возможность известить о нападении на устройства или элементы, реализующие ФБО. Однако оповещение о нападении не действует автоматически; уполномоченному пользователю необходимо вызвать административную функцию безопасности или проверить вручную, произошло ли нападение.

FPT PH Р.2 «Оповещение о фи зическом нападении» обеспечивает автоматическое оповещение о нападении для установленного подмножества физических проникновений.

FPT РНР.З «Противодействие физическому нападению» предоставляет возможность предотвращения или противодействия физическому нападению на устройства и элементы, реализующие ФБО.

Управление: FPT_PHP.l. FPT_PHP.3

Действия по управлению не предусмотрены.

Управление: FPT_PHP.2

Для функций управления из класса FMT могут рассматриваться следующие действия.

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

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

Управление: FPT РНР.З

Для функций управления из класса ГМТ может рассматриваться следующее действие.

а) Управление автоматической реакцией на физическое воздействие.

Аудит: FPT PHP.I

а) Минимальный: обнаружение вторжения средствами ИТ.

Аудит: FPT_PHP.2

а) Минимальный: обнаружение вторжения.

Аудит: FPT-PHP.3

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

FPT_P1 IP. 1 Пассивное обнаружение физического нападения

Иерархический для: Нет подчиненных компонентов.

FPT_P1IP.1.I ФБО должны обеспечить однозначное обнаружение физического воздействия, которое может угрожать выполнению ФБО.

FPT.P1IP. 1.2 ФБО должны предоставить возможность определить, произошло ли физическое воздействие на устройства или элементы, реализующие ФБО.

Зависимости: FMT_MOF.I Управление режимом выполнения функций безопасности

FPT_PIIP.2 Оповещение о физическом нападении

Иерархический для: FPT РНР.1

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

FPT_PIIP.2.2 ФБО должны предоставить возможность определить, произошло ли физическое воздействие на устройства или элементы. реализующие ФБО.

FPT_PIIP.2.3 Для [назначение: список устройств/злементов, реализующих ФБО, для которых требуется активное обнаружение} ФБО должны постоянно контролировать устройства. элементы и оповещать [назначение: назначенный пользователь или роль], что произошло физическое воздействие на устройства или элементы, реализующие ФБО.

Зависимости: FMT_MOF.l Управление режимом выполнения функций безопасности

FPT_P1IP.3 Противодействие физическому нападению Иерархический для: Нет подчиненных компонентов.

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

Зависимости: отсутствуют.

10.8 Падежное восстановление (FPT_RCV)

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

Требования семейства FPT_RCV обеспечивают, чтобы ФБО могли определить, не нарушена ли зашита <1>БО при запуске, и восстанавливаться без нарушения зашиты после прерывания операций. Это семейство важно, потому что начальное состояние ФБО при запуске или восстановлении определяет защищенность 00 в последующем.

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

FPT_RCV.1 «Ручное восстановление» позволяет ОО предоставить только такие механизмы возврата к безопасному состоянию, которые предполагают вмешательство человека.

FPT_RCV.2 «Автоматическое восстановление» предоставляет, хотя бы для одного типа прерывания обслуживания, восстановление безопасного состояния без вмешательства человека: восстановление после прерываний других типов может потребовать вмешательства человека.

FPT RCV.3 «Автоматическое восстановление без недопустимой потери» также предусматривает автоматическое восстановление, но повышает уровень требований, препятствуя недопустимой потере защищенных объектов.

FPT RCV.4 «Восстановление функции» предусматривает восстановление на уровне отдельных ФБ. обеспечивая либо их нормальное завершение после сбоя, либо возврат к безопасному состоянию данных ФБО.

Управление: FPT RCV.I

Для функций управления из класса FMT может рассматриваться следующее действие.

а) Управление списком доступа к средствам восстановления в режиме аварийной поддержки. Управление: FPT.RCV.2, FPT.RCV.3

Для функций управления из класса FMT могут рассматриваться следующие действия.

а) Управление списком доступа к средствам восстановления в режиме аварийной поддержки.

б) Управление списком сбоев/прерываний обслуживания, которые будут обрабатываться автоматически м и процедурам и.

Управление: FPT RCV.4

Действия по управлению нс предусмотрены.

Аудит: FPT RCV.I. FPT RCV.2. FPT_RCV.3

а) Минимальный: факт возникновения сбоя ши прерывания обслуживания.

б) Минимальный: возобновление нормальной работы.

в) Базовый: тип сбоя или прерывания обслуживания.

Аудит: FPT RCV.4

а) Минимальный: невозможность возврата к безопасному состоянию после сбоя функции безопасности, если аудит возможен.

б) Базовый: обнаружение сбоя функции безопасности, если аудит возможен.

FPT_RCV.l Ручное восстановление

Иерархический для: Нет подчиненных компонентов.

FPT_RCV.1.I После сбоя или прерывания обслуживания ФБО должны перейти в режим аварийной поддержки, который предоставляет возможность возврата ОО к безопасному состоянию.

Зависимости: FPT_TST.l Тесгирвание ФБО

AGD_ADM.I Руководство администратора ADVJSPM.1 Неформальная модель политики безопасности ОО FPT_RCV.2 Автоматическое восстановление

Иерархический для: FPT.RCV. I

FPT_RCV.2.1 Когда автоматическое восстановление после сбоя или прерывания обслуживания невозможно, ФБО должны перейти в режим аварийной поддержки, который предоставляет возможность возврата ОО к безопасному состоянию.

FPT_RCV.2.2 Для [назначение: список сбоев/прерываний обслуживания] ФБО должны обеспечить возврат ОО к безопасному состоянию с использованием автоматических процедур.

Зависимости: FPT TST.1 Тестирование ФБО AGD ADM. I Руководство администратора ADV_SPM. I Неформальная модель политики безопасности ОО

FPT_RCV.3 Автоматическое восстановление без недопустимой потери

Иерархический для: FPT_RCV.2

FPT_RCV.3.1 Когда автоматическое восстановление после сбоя или прерывания обслуживания невозможно. ФБО должны перейти в режим аварийной поддержки, который предоставляет возможность возврата ОО к безопасному состоянию.

FPT_RCV.3.2 Для [назначение: список сбоев/прерываний обслуживания] ФБО должны обеспечить возврат ОО к безопасному состоянию с использованием автоматических процедур.

FPT_RCV.3.3 Функции из числа ФБО, предназначенные для преодоления последствий сбоя или прерывания обслуживания, должны обеспечить восстановление безопасного начального состояния без превышения [назначение: количественная мера] потери данных ФБО или объектов в пределах ОДФ.

FPT.RCV.3.4 ФБО должны обеспечить способность определения, какие объекты могут, а какие не могут быть восстановлены.

Зависимости: FPT TST.1 Тестирование ФБО

AG D ADM. I Руководство администратора

ADV SP.M.I Неформальная модель политики безопасности ОО

FPT_RCV.4 Восстановление функции

Иерархический для: Нет подчиненных компонентов.

FPT_RCV.4.1 ФБО должны обеспечить следующее свойство для [назначение: список ФБ и сценариев сбоев]’. ФБ нормально заканчивает работу или, для предусмотренных сценариев сбоев, восстанавливается ее устойчивое и безопасное состояние.

Зависимости: ADV_SPM.l Неформальная модель политики безопасности ОО

10.9 Обнаружение повторного использования (FPT_RPL)

Характерце I ика семейства

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

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

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

Управление: FPT_RPL.I

Для функций управления из класса FMT могут рассматриваться следующие действия.

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

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

Аудит: FPT RPL. I

а) Базовый: обнаружение нападения посредством повторного использования.

б) Детализированный: предпринятые специальные действия.

FPT_RPI,.1 Обнаружение повторного использования

Иерархический для: Нет подчиненных компонентов.

FPT_RPL. 1.1 ФБО должны обнаруживать повторное использование для следующих сущностей: [назначение: список идентифицированных сущностей}.

FPT_RPL.1.2 ФБО должны выполнить [назначение: список специальных действий] при обнаружении повторного использования.

Зависимости: отсутствуют.

10.10 Посредничество при обращениях (FPT_RVM)

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

Требования семейства FPT RVM связаны с аспектом «постоянная готовность» традиционного монитора обращений. Цель этого семейства состоит в обеспечении для заданной ПФБ. чтобы все действия, требующие осуществления политики, проверялись ФБО на соответствие ПФБ. Если помимо этого часть ФБО, осуществляющая ПФБ, выполняет требования соответствующих компонентов из семейств FPT SEP «Разделение домена» и ADV 1NT «Внутренняя структура ФБО». то эта часть ФБО обеспечивает «монитор обращений» для этой ПФБ.

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

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

Это семейство состоит из только компонента. FPT RVM.1 «Невозможность обхода ПВО», который содержит требование предотвращения обхода для всех ПФБ из ПВО.

Управление: FPT_RVM.l

Действия по управлению не предусмотрены.

Аудит: FPT RVM.1

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

FPT_RVM.1 Невозможность обхода ПВО

Иерархический для: Нет подчиненных компонентов.

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

Зависимости: отсутствуют.

10.11 Ра зделение домена (FPT_SEP)

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

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

Это семейство содержит следующие требования.

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

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

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

г) Защищенные домены субъектов разделены, за исключением случаев, когда совместное использование одного домена управляется ФБО.

Ранжиров»! I ие ком i юней гов

FPT SEP. 1 «Отделение домена ФБО» предоставляет отдельный защищенный домен для ФБО и обеспечивает разделение между субъектами в ОДФ.

FPT SEP.2 «Отделение домена ПФБ» содержит требования дальнейшего разбиения защищенного домена ФБО с выделением отдельного(ных) домсна(ов) для идентифицированной совокупности ПФБ. которые действуют как мониторы обращений для них, и домена для остальной части ФБО. а также доменов для частей 00. нс связанных с ФБО.

FPT SEP.3 «Полный монитор обращений» содержит требования, чтобы имелся отдельный(ные) домсн(ны) для осуществления ПБО. домен для остальной части ФБО. а также домены для частей ОО. не связанных с ФБО.

Управление: FPT SEP.l. FPT_SEP.2. FPT_SEP.3

Действия по управлению не предусмотрены.

Аудит: FPT.SEP.I. FPT.SEP.2, FPT_SEP.3

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

FPTJSEP. I Отделение домена ФБО

Иерархический для: Нет подчиненных компонентов.

FPT_SEP. 1.1 ФБО должны поддерживать домен безопасности для собственного выполнения, защищающий их от вмешательства и искажения недоверенными субъектами.

FPT_SEP. 1.2 ФБО должны реализовать разделение между доменами безопасности субъектов в ОДФ.

Зависимости: отсутствуют.

FPT_SEP.2 Отделение домена ПФБ

Иерархический для: FPT_SEP.l

FPT_SEP.2.1 Неизолированная часть ФБО должна поддерживать домен безопасности для собственного выполнения, защищающий их от вмешательства и искажения недо-вере иным и субъе ктам и.

FPT_SEP.2.2 ФБО должны реализовать разделение между доменами безопасности субъектов в ОДФ.

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

Зависимости: отсутствуют.

FPT_SEP.3 Полный монитор обращений

Иерархический для: FPT SEP.2

FPT_SEP.3.I Неизолированная часть ФБО должна поддерживать домен безопасности для собственного выполнения, защищающий их от вмешательства и искажения недо-вере иными субъе ктами.

FPT_SEP.3.2 ФБО должны реализовать разделение между доменами безопасности субъектов в ОДФ.

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

Зависимости: отсутствуют.

10.12 Протокол синхронизации состояний (FPT.SSP)

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

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

Семейство FPT..SSP устанавливает требование использования надежных протоколов некоторыми критичными по безопасности функциями из числа ФБО. Оно обеспечивает, чтобы две распределенные части 00 (например, главные ЭВМ) синхронизировали свои состояния после действий, связанных с безопасностью.

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

FPT SSP. I «Одностороннее надежное подтверждение» содержит требование подтверждения одним лишь получателем данных.

FPT SSP.2 «Взаимное надежное подтверждение» содержит требование взаимного подтверждения обмена данными.

Управление: FPT SSP.I. FPT SSP.2

Действия по управлению не предусмотрены.

Аудит: FPT SSP.l, FPT SSP.2

Если в ПЗ/ЗБ включено семейство FAU.GEN «Генерация данных аудита безопасности», го следует предусмотреть возможность (в ‘зависимости от выбранного уровня) аудита следующих дей-ствий/событий/параметров.

а) Минимальный: неполучение ожидаемого подтверждения

FPT_SSP.l Одностороннее надежное подтверждение

Иерархический для: Нет подчиненных компонентов.

FPT_SSP.1.1 ФБО должны подтвердить после запроса другой части ФБО получение немодифнцн-рованных данных ФБО при передаче.

Зависимости: FPT.ITT.1 Базовая зашита внутренней передачи данных ФБО

FPT_SSP.2 Взаимное надежное подтверждение

Иерархический для: FPT SSP. 1

FPT_SSP.2.1 ФБО должны подтвердить после запроса другой части ФБО получение ^’модифицированных данных ФБО при передаче.

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

Зависимости: FPT ITT. 1 Базовая зашита внутренней передачи данных ФБО

10.13 Метки времени (FPT.STM)

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

Семейство FPT STM содержит требования по предостаазению надежных меток времени в пределах 00.

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

‘Это семейство состоит из одного компонента FPT STM. I «Надежные метки времени», который содержит требование, чтобы ФБО предоставили надежные метки времени для функций из числа ФБО.

Управление: FPT_STM. 1

Для функций управления из класса FMT может рассматриваться следующее действие.

а) Управление внутренним представлением времени.

Аудит: FPT.STM. 1

а) Минимальный: изменения внутреннего представления времени.

б) Детализированный: предоставление меток времени.

FPT.STM. 1 Надежные метки времени

Иерархический для: Нет подчиненных компонентов.

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

Зависимости: отсутствуют.

10.14 Согласованность данных ФБО между ФБО (FPT.TDC)

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

В среде распределенной или сложной системы от ОО может потребоваться произвести обмен данными ФБО (такими, как атрибуты ПФБ, ассоциированные с данными, информация аудита или идентификации) с другим доверенным продуктом ИТ. Семейство FPT_TDC определяет требования для совместного использования и согласованной интерпретации этих атрибутов между ФБО и другим доверенным продуктом ИТ.

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

FPT TDC. I «Базовая согласованность данных <1>БО между ФБО» содержит требование, чтобы ФБО предоставили возможность обеспечить согласованность атрибутов между ФБО.

Управление: FPT TDC.1

Действия по управлению нс предусмотрены.

Аудит: FPT TDC.I

а) Минимальный: успешное использование механизмов согласования данных ФБО.

б) Базовый: использование механизмов согласования данных ФБО.

в) Базовый: идентификация ФБО. данные которых интерпретируются.

г) Базовый: обнаружение модифицированных данных ФБО.

FPT.TDC.1 Базовая согласованность данных ФБО между ФБО

Иерархический для: Нет подчиненных компонентов.

FPT.TDC.1.1 ФБО должны обеспечить способность согласованно интерпретировать (назначение: список типов данных ФБО]_Ч совместно используемые ФБО и другим доверенным продуктом ИТ.

FPT_TDC. 1.2 ФБО должны использовать (назначение: список правил интерпретации, применяемых ФБО\ при интерпретации данных ФБО, полученных от другого доверенного продукта ИТ.

Зависимости: отсутствуют.

10.15 Согласованность данных ФБО при дублировании в пределах ОО (FPT_TRC)

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

Требования семейства FPT TRC необходимы, чтобы обеспечить согласованность данных ФБО. когда они дублируются в пределах ОО. Такие данные могут стать несогласованными при нарушении работоспособности внутреннего канала между частями ОО. Если ОО внутренне структурирован как сеть, то это может произойти из-за отключения отдельных частей сети при разрыве сетевых соединений.

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

Это семейство состоит из одного компонента FPT TRC. 1 «Согласованность дублируемых данных ФБО». содержащего требование, чтобы ФБО обеспечили непротиворечивость данных ФБО. дублируемых в нескольких частях ОО.

Управление: для FPT TRC.I

Действия по управлению не предусмотрены.

Аудит: для FPT TRC. 1

а) Минимальный: восстановление согласованности после восстано&тения соединения.

б) Базовый: выявление несогласованности между данными ФБО.

FPT_TRC.l Согласованность дублируемых данных ФБО

Иерархический для: Пет подчиненных компонентов.

FPT_TRC.1.1 ФБО должны обеспечить согласованность данных ФБО при дублировании их в различных частях ОО.

FPT_TRC. 1.2 Когда части ОО, содержащие дублируемые данные ФБО, разъединены, ФБО должны обеспечить согласованность дублируемых данных ФБО после восстановления соединения перед обработкой любых запросов к [назначение: список ФБ, зависящих от согласованности дублируемых данных ФБО].

Зависимости: FPT_1TT. 1 Базовая зашита внутренней передачи данных ФБО

10.16 Самотестирование ФБО (FPT_TST)

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

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

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

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

FPT TST. I «Тестирование ФБО» позволяет проверить правильность выполнения ФБО. Эти тесты могут выполняться при запуске, периодически, по запросу уполномоченного пользователя или при выполнении других заранее оговоренных условий. Этот компонент также предоставляет возможность верифицировать целостность данных и выполняемого кола ФБО.

Управление: для FPT TST.I

Для функций управления из класса FMT могут рассматриваться следующие действия.

а) Управление условиями, при которых происходит самотестирование ФБО (при запуске, с постоянным интервалом или при определенных условиях).

б) Управление периодичностью выполнения (при необходимости).

Аудит: для FPT TST. I

а) Базовый: выполнение и результаты самотестирования ФБО.

j.’I>T_TST.l Тестирование ФБО

Иерархический для: Нет подчиненных компонентов.

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

FPTJTST. 1.2 ФБО должны предоставить уполномоченным пользователям возможность верифицировать целостность данных ФБО.

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

Зависимости: FPT.AMT.I Тестирование абстрактной машины

11 Класс FRU. Использование ресурсов

Класс FRU содержит три семейства, которые поддерживают доступность требуемых ресурсов, таких как вычислительные возможности и/или объем памяти. Семейство FRU FLT «Отказоустойчивость» предоставляет защиту от недоступности ресурсов, вызванной сбоем 00. Семейство FRU_PRS «Приоритет обслуживания» обеспечивает, чтобы ресурсы выделялись наиболее важным или критичным по времени задачам и не могли быть монополизированы задачами с более низким приоритетом. Семейство FRU_RSA «Распределение ресурсов» устанавливает ограничения использования доступных ресурсов, предотвращая монополизацию ресурсов пользователями.

Декомпозиция класса FRU на составляющие его компоненты приведена на рисунке 11.1.

Рисунок 11.1 — Декомпозиция класса «-Использование ресурсов»

П.1 Отказоустойчивость (FRU_FLT)

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

Требования семейства FRU_FLT обеспечивают, чтобы 00 продолжил поддерживать правильное функционирование даже в случае сбоев.

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

FRU_FLT. I * Пониженная отказоустойчивость» содержит требование, чтобы ОО продолжил правильное выполнение указанных возможностей в случае идентифицированных сбоев.

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

Управление: FRU~FLT. I. FRU FLT.2

Действия по управлению не предусмотрены.

Лудит: FRU_FLT.l

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

а) Минимальный: любой сбой, обнаруженный ФБО.

б) Базовый: все операции 00. прерванные из-за сбоя.

Аудит: FRLLFLT.2

а) Минимальный: любой сбой, обнаруженный ФБО.

FRU.FLT.1 Пониженная отказоустойчивость

Иерархический для: Нет подчиненных компонентов.

FRU_FLT.1.1 ФБО должны обеспечить выполнение [назначение: список возможностей ОО], когда происходят следующие сбои: [назначение: список типов сбоев}.

Зависимости: FPT_FLS.l Сбой с сохранением безопасного состояния

FRU_FLT.2 Ограниченная отказоустойчивость

Иерархический для: FRU FLT. 1

FRU_FLT.2.1 ФБО должны обеспечить выполнение всех возможностей ОО. когда происходят следующие сбои: [назначение: список типов сбоев}.

Зависимости: FPT FLS. 1 Сбой с сохранением безопасного состояния

11.2 Приоритет обслуживания (FRU_PRS)

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

Требования семейств:! FRU_PRS позволяют ФБО управлять использованием ресурсов пользователями и субъектами в пределах своей области действия так. что высокоприоритетные операции в пределах ОДФ всегда будут выполняться без препятствий или задержек со стороны операций с более низким приоритетом.

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

FRU PRS. I «Ограниченный приоритет обслуживания» предоставляет приоритеты для использования субъектами подмножества ресурсов в пределах ОДФ.

FRU PRS.2 «Полный приоритет обслуживания» предоставляет приоритеты для использования субъектами всех ресурсов в пределах ОДФ.

Управление: FRU^PRS.I, FRUJ>RS.2

Для функций управления из класса FMT может рассматриваться следующее действие.

а) Назначение приоритетов каждому субъекту в ФБО.

Аудит: FRUJPRS.l. FRU.PRS.2

а) Минимальный: отклонение операции на основании использования приоритета при распределении ресурса.

б) Базовый: все попытки использования функции распределения ресурсов с учетом приоритетности обслуживания.

FRU_PRS.l Ограниченный приоритет обслуживания

Иерархический для: Нет подчиненных компонентов.

FRUJPRS.I.I ФБО должны установить приоритет каждому субъекту в ФБО.

FRU_PRS.1.2 ФБО должны обеспечить доступ к [назначение: управляемые ресурсы] на основе приоритетов, назначенных субъектам.

Зависимости: отсутствуют.

FRU_PRS.2 Полный приоритет обслуживания

Иерархический для: FRU PRS. I

FRU_PRS.2.1 ФБО должны установить приоритет каждому субъекту в ФБО.

FRU_PRS.2.2 ФБО должны обеспечить доступ ко всем совместно используемым ресурсам на основе приоритетов, назначенных субъектам.

Зависимости: отсутствуют.

11.3 Распределение ресурсов (FRU—RSA)

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

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

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

FRU RSA. I «Максимальные квоты» содержит требования к механизмам квотирования, которые обеспечивают, чтобы пользователи и субъекты нс монополизировали управляемый ресурс.

FRU RSA.2 «Минимальные и максимальные квоты» содержит требования к механизмам квотирования. которые обеспечивают, чтобы пользователи и субъекты всегда имели хотя бы минимум специфицированного ресурса, но при этом не могли бы монополизировать этот ресурс.

Управление: FRU RSA.1

Для функций управления из класса FMT может рассматриваться следующее действие.

а) Определение администратором максимальных квот ресурса для групп и/или отдельных пользователей и/или субъектов.

Управление: FRU_RSA.2

Для функций управления из класса F.MT может рассматриваться следующее действие.

а) Определение администратором минимальных и максимальных квот ресурса для групп и/или отдельных пользователей и/или субъектов.

Аудит: FRU RSA.l. FRU RSA.2

а) Минимальный: отклонение операции распределения ресурса из-за его ограниченности.

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

Иерархический для: Нет подчиненных компонентов.

FRU_RSA. 1.1 ФБО должны реализовать максимальные квоты следующих ресурсов: [назначение: управ.зяемыересурсы], которые [выбор: отдельные пользователи, определенные группы пользователей, субъекты] могут использовать [выбор: одновременно, в течение определенного периода времени].

Зависимости: отсутствуют.

FRU_RSA.2 Минимальные и максимальные квоты

Иерархический для: FRU_RSA.l

FRU_RSA.2.1 ФБО должны реализовать максимальные квоты следующих ресурсов: [назначение: управляемые ресурсы], которые [выбор: отдельные пользователи, определенные группы пользователей, субъекты] могут использовать [выбор: одновременно, в течение определенного периода времени].

FRU_RSA.2.2 ФБО должны обеспечить выделение минимального количества каждого из [назначение: управляемые ресурсы], которые являются доступными для [выбор: отдельный пользователь, определенная группа пользователей, субъекты], чтобы использовать [ выбор: одновременно, в течение определенного периода времени]

Зависимости: отсутствуют.

12 Класс FTA. Доступ к ОО

Класс FTA определяет функциональные требования к управлению открытием сеанса пользователя.

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

Рисунок 12.1 — Дскомполшия класса «Доступ к ОО»

12.1 Ограничение области выбираемых атрибутов (FTA_LSA)

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

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

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

FTA LSA. I «Ограничение области выбираемых атрибутов» предоставляет требование к 00 по ограничению области атрибутов безопасности сеанса во время его открытия.

Управление: FTA LSA.1

Для функций управления из класса FMT может рассматриваться следующее действие.

а) Управление администратором областью атрибутов безопасности сеанса.

Аудит: FTA LSA.1

а) Минимальный: все неуспешные попытки выбора атрибутов безопасности сеанса.

б) Базовый: все попытки выбора атрибутов безопасности сеанса.

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

FTA_LSA.l Ограничение области выбираемых атрибутов

Иерархический для: Нет подчиненных компонентов.

FTA_LSA.l. 1 ФБО должны ограничить область атрибутов безопасности сеанса (назначение: атрибуты безопасности сеанса]., основываясь на [назначение: атрибуты].

Зависимости: отсутствуют.

12.2 Ограничение на параллельные сеансы (FTA_MCS)

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

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

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

FTA MCS.I «Базовое ограничение на паралельные сеансы» предоставляет ограничения, которые применяются ко всем пользователям ФБО.

FTA MCS.2 «Ограничение на параллельные сеансы по атрибутам пользователя» расширяет ГТА MCS. 1 требованием возможности определить ограничения на число параллельных сеансов, основываясь на атрибутах безопасности. связанных с пользователем.

Управление: FTA MCS. 1

Для функций управления из класса FMT может рассматриваться следующее действие.

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

Управление: FTA MCS.2

Для функций управления из класса FMT могут рассматриваться следующие действия.

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

Аудит: FTAJMCS.I. FTA_MCS.2

Если в ПЗ/ЗБ включено семейство FAU GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих дей-ствий/событий/парамсгров.

а) Минимальный: отклонение нового сеанса, основанное на ограничении числа паралельных сеансов.

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

FTA_MCS.l Базовое ограничение на наралельные сеансы Иерархический для: Нет подчиненных компонентов.

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

FTA_MCS.1.2 ФБО должны задать по умолчанию ограничение (назначение: задаваемое по умолчанию число] сеансов пользователя.

Зависимости: FIA_UID.l Выбор момента идентификации

FTAMCS.2 Ограничение на параллельные сеансы по атрибутам пользователя

Иерархический для: FTA MCS.1

FTA_MCS.2.I ФБО должны ограничить максимальное число параллельных сеансов, предоставляемых одному и тому же пользователю, согласно правилам [назначение: правила определения максимального числа параллельных сеансов}.

FTA_MCS.2.2 ФБО должны задать по умолчанию ограничение [назначение: задаваемое по умолчанию число} сеансов пользователя.

Зависимости: F1A_UID. I Выбор момента идентификации

12.3 Блокирование сеанса (FTA_SSL) Характеристика семейства

Семейство FTA SSL определяет требования к ФБО по предоставлению возможности как <1>БО. так и пользователю блокировать и разблокировать интерактивный сеанс.

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

FTA_SSL.l «Блокирование сеанса, инициированное ФБО» включает инициированное системой блокирование интерактивного сеанса после определенного периода бездействия пользователя.

FTA_SSL.2 «Блокирование, инициированное пользователем» предоставляет пользователю возможность блокировать и разблокировать свои собственные интерактивные сеансы.

FTA_SSL.3 «Завершение, инициированное ФБО» предоставляет требования к ФБО по завершению сеанса после определенного периода бехчсйствия пользователя.

Управление: FTA_SSL.I

Для функций управления из класса FMT могут рассматриваться следующие действия.

а) Задание времени бездействия пользователя, после которого происходит блокировка сеанса.

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

в) Управление событиями, которыми предусматриваются до разблокирования сеанса. Управление: FTASSL.2

Для функций управления из класса FMT может рассматриваться следующее действие.

а) Управление событиями, которые предусматриваются до разблокирования сеанса. Управление: FTA_SSL.3

Для функций управления из класса FMT могут рассматриваться следующие действия.

а) Задание времени бездействия пользователя, после которого происходит завершение интерактивного сеанса.

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

Аудит: FTA SSL.l. FTA_SSL.2

а) Минимальный: блокирование интерактивного сеанса механизмом блокирования сеанса.

б) Минимальный: успешное разблокирование интерактивного сеанса.

в) Базовый: все попытки разблокирования интерактивного сеанса.

Аудит: FTA SSL.3

а) Минимальный: завершение интерактивного сеанса механизмом блокирования сеанса. FTA_SSL. I Блокирование сеанса, инициированное ФБО Иерархический для: Нет подчиненных компонентов.

FTA SSL. 1.1 ФБО должны блокировать интерактивный сеанс после (назначение: интервал времени бездействия пользователя], для чего предпринимаются следующие действия:

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

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

FTA_SSL.1.2 ФБО должны гребовагь, чтобы до разблокирования сеанса произошли следующие события: (назначение: события, которые будут происходить].

Зависимости: FIA_UAU.l Выбор момента аутентификации

FTA_SSL.2 Блокирование, инициированное пользователем

Иерархический для: Нет подчиненных компонентов.

FTz\_SSL.2.1 ФБО должны допускать инициированное пользователем блокирование своего собственного интерактивного сеанса, для чего предпринимаются следующие действия:

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

FTA_SSL.2.2 ФБО должны требовать, чтобы до разблокирования сеанса произошли следующие события: (назначение: события, которые будут происходить].

Зависимости: FIA_UAU.I Выбор момента аутентификации

FTA_SSL.3 Завершение, инициированное ФБО Иерархический для: Нет подчиненных компонентов.

FT/\_SSL.3.1 ФБО должны завершить интерактивный сеанс после (назначение: интервал времени бездействия пользователя].

Зависимости: отсутствуют.

12.4 Предупреждения перед предоставлением доступа к ОО (FTA_TAB)

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

Семейство FTA TAB определяет требования к отображению для пользователей предупреждающего сообщения с перестраиваемой конфигурацией относительно характера использования ОО.

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

ГТА TAB. 1 «Предупреждения по умолчанию перед предоставлением доступа к ОО» предоставляет требования к предупреждающим сообщениям, которые отображаются перед началом диалога в сеансе.

Управление: FTA TAB.l

Для функций управления из класса FMT может рассматриваться следующее действие.

а) Сопровождение уполномоченным администратором предупреждающих сообщений.

Аудит: FTA ТАВ.1

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

FTA_TAB.l Предупреждения по умолчанию перед предоставлением доступа к ОО Иерархический для: Нет подчиненных компонентов.

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

Зависимости: отсутствуют.

12.5 История доступа к ОО (РТЛ_ТЛП)

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

Семейство FTA ТАН определяет требования к ФБО по отображению для пользователя, при успешном открытии сеанса, истории успешных и неуспешных попыток получить доступ от имени этого пользователя.

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

FTA_TAH. I «История доступа к ОО» предоставляет требования к ОО по отображению информации. связанной с предыдущими попытками открыть сеанс.

Управление: FTA.TAH.I

Действия по управлению не предусмотрены.

Аудит: FTA TAH.I

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

FTA_TAH.l История доступа к ОО

Иерархический дзя: Нет подчиненных компонентов.

FTA_TAH.1.1 При успешном открытии сеанса ФБО должны отобразить (выбор: дата, время, метод, расположение} последнего успешного открытия сеанса от имени пользователя.

FTА_ТАН. 1.2 При успешном открытии сеанса ФБО должны отобразить [выбор: дата, время, метод, расположение] последней неуспешной попытки открытия сеанса и число неуспешных попыток со времени последнего успешного открытия сеанса.

FTA_TA11.1.3 ФБО не должны удалять информацию об истории доступа из интерфейса пользователя без предоставления пользователю возможности просмотреть ее.

Зависимости: отсутствуют.

12.6 Открытие сеанса с ОО (FTA_TSE)

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

Семейство FTA_TSE определяет требования по запрещению пользователям открытия сеанса с ОО.

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

FTA TSE. I «Открытие сеанса с ОО» предоставляет условия запрещения пользователям доступа к ОО. основанного на атрибутах.

Управление: FTA TSE.I

Для функций управления из класса FMT может рассматриваться следующее действие.

а) Управление уполномоченным администратором условиями открытия сеанса.

Аудит: FTA TSE.I

а) Минимальный: запрещение открытия сеанса механизмом открытия сеанса.

б) Базовый: все попытки открытия сеанса пользователя.

в) Детализированный: фиксация значений выбранных параметров доступа (таких как место доступа или время доступа).

FTA_TSE.1 Открытие сеанса с ОО

Иерархический для: Нет подчиненных компонентов.

FTA_TSE. 1.1 ФБО должны быть способны отказать в открытии сеанса, основываясь на [назначение: атрибуты].

Зависимости: отсутствуют.

13 Класс FTP. Доверенный маршрут/канал

Семейства класса FTP содержат требования как к доверенному маршруту связи между пользователями и ФБО. так и к доверенному каналу связи между ФБО и другими доверенными продуктами ИТ. Доверенные маршруты и каналы имеют следующие обшие свойства:

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

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

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

Декомпозиция класса FTP на составляющие его компоненты приведена на рисунке 13.1.

Рисунок 13.1 — Декомпозиция класса «Доверенный маршрут/канал»

13.1 Доверенный канал передачи между ФБО (FTP_1TC)

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

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

Ранжироши i ие ком i юней тов

FTP 1ТС. 1 «Доверенный канал передачи между ФБО» содержит требование, чтобы ФБО предоставили доверенный канал связи между ними самими и другим доверенным продуктом ИТ.

Управление: FTP ITC.1

Для функций управления из класса FMT может рассматриваться следующее действие.

а) Изменение набора операций, которые требуют доверенного канала (если таковой имеется). Лудит: FTP_ITC.I

а) Минимальный: сбой функций доверенного канала.

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

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

г) Базовый: идентификация инициатора и адресата всех функций доверенного канала.

FTP_ITC.l Доверенный канал передачи между ФБО

Иерархический для: Нет подчиненных компонентов.

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

FTP_ITC.1.2 ФБО должны позволить [выбор: ФБО, удаленный доверенный продукт ИТ\ инициировать связь через доверенный канал.

FTP_ITC. 1.3 ФБО должны инициировать связь через доверенный канал для выполнения [назначение: список функций, для которых требуется доверенный канал}.

Зависимости: отсутствуют.

13.2 Доверенный маршрут (FTPJTRP)

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

Семейство FTP_TRP определяет требования установки и поддержания доверенной связи между пользователями и ФБО. Доверенный маршрут может потребоваться для любого связанного с безопасностью взаимодействия. Обмен по доверенному маршруту’ может быть инициирован пользователем при взаимодействии с ФБО или же сами ФБО могут установить связь с пользователем по доверенному маршруту.

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

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

Управление: FTP_TRP.l

Для функций управления из класса FMT может рассматриваться следующее действие.

а) Изменение набора операций, которые требуют доверенного маршрута, если он имеется. Аудит: FTP_TRP. I

а) Минимальный: сбой функций доверенного маршрута.

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

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

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

FTP_TRP.I Доверенный маршрут

Иерархический для: Нет подчиненных компонентов.

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

FTP_TRP.I.2 ФБО должны позволить [выбор: ФБО, локальные пользователи, удаленные пользователи] инициировать свя зь через доверенный маршрут.

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

Зависимости: отсутствуют.

ПРИЛОЖЕНИЕ А (справочное)

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

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

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

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

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

Структура функционального класса в приложениях В — II приведена на рисунке А.1.

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

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

Уникальное имя класса, определенное в нормативных элементах настоящего стандарта.

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

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

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

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

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

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

Уникальное имя семейства, определенное в нормативных элементах настоящего стандарт;!.

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

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

А. 1.2.3 Замечания для оненшика

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

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

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

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

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

нента

Уникальное имя компонента, определенное в нормативных элементах настоящего стандарта.

А. 1.3.2 Обоснование компонен

та и замечания по применению

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

Обоснование содержит такие детали. которые уточняют общие фор

мулировки применительно к спреде- Рисунок А.З – Структура функционального компонента

ленному уровню: его следует использовать только в том случае, если на этом уровне требуется расширенное описание.

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

Эгог раздел не обязателен и вводится при необходимости.

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

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

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

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

В таблице А. I показаны прямые, косвенные и выбираемые зависимости функциональных компонентов. Каждому компоненту, от которого зависят какие-либо функциональные компоненты, отведена графа. Каждому функциональному компоненту отведена строка. Знаки на пересечении строк и граф таблицы указывают характер зависимости соответствующих компонентов: «X» — прямая зависимость: — косвен

ная. а *о» — выбираемая.

Выбираемую зависимость рассмотрим на примере компонента ГОР ETC.I. требующего присутствия либо компонента FDP ACC.I. либо компонента FDP IFC.I. Так. если выбран компонент FDP АСС.1. то присутствие FDP IFC.I необязательно и наоборот. Если пересечение с троки 31 графы таблицы пусто, компонент из строки не -зависит от компонента из графы.

£ T j 6 i н u a AJ — JjBiKirKKin функинона1ьных компонентов

7 a. z

и л

a w

< w¹4* z z

* w

V h-z

z V

-T

Л *

w w

Z w> u

/■

гч

«4

u. L_

«4

/4 z

& гч z

X a*

Z <

< к

*i z z 7

•—

✓

*—

—

«.

Q 7.

«✓

3£

ГАС ARP 1

—

I M GUN 1

IAI GfcN2

—

1 AC SAA 1

—

FAC SAA 2

IAI SAA.’

1 AC SA X 4

1 AC SAR 1

IAC SAR 2

IAC SAR 3

IAC SLL.I

—

I AC STG.I

IAC MU’

—

FAC SiG 3

FAU SIG.4

1(0 NRO 1

KO NRO 2

KO NRR.I

ICO NRR2

ICS CKM 1

IIS CKM 2

К S CKM *

—

ICS CKM 4

I CS COPJ

1 PP AC С 1

—

FDP AC C 2

J PP AO 1

FOP РАС 1

IDP DAI 2

J OP tici

—

ГРР 1 П 2

—

гоог-г-Korsi nmVo.)mjxx)j

> у* i-и	> w	> > м	> > о*	Ж > •z	> > X	> >	> >	> >	>» <z с и »w	> Е у	> w	>	W V WU	W S	W •t	W А	W V ж- ■■■ W	W -t ж W	W X о ы	W V X ич	W X *5	W X	W X		W	W –	W к	W	<?	W iz	W X	W >	W	W — у	W « к	W А
																																					ДОЧ SPM.I
																																					ЛОО ЛОМ 1
																													ж		ж	ж					АЛА < < Л.1
																														ж							д\ А < С А 1
																																					ГАС <.ГЧ 1

																																					ГЛ1′ SARI
																																					ГАС STG 1
																																					I CS < KM.J
																																					its скм.:
																																					И S < КМ 4
																																					res cop.i
													W	С	с	О			о	о			ич W	о	о	0	С	с	1	1	1	1	1	1	1	\| II ГОР Л( < 1
													1	1	1	1			1	1			i	1	1	1	1	1	1	1	1	1	1	1	1	1	ГОР ЛК 1
													л W	с	с	С			о	о			л W	о	о	о	с	с	ж	ж	ж	ж	ж	ж	1	1	ЮР ITT J
													1	1	1	1			1	1			1	1	1	1	1	1	1	1	1	1	1	1	ж	ж	ГОР ni l
																																					ЮР IK 1
																								X												\|п>Р ITT 1
																							ж													111>Р III 2
													ж	ж																						\|п>Р 1 ГТ Л
																																				Аил ATI) 1
		Ж										Ж																								1 ПЛ 1 Al 1
		1					Ж	Ж				1	1	1	1	1			1	1			1	1	1	1	1	1	1	1	1	1	1	1	1	1 1 ил 1 10 1
																																				\|ГМТ М0Г.1
													1	1	1	1			1	1			1	1	1	1	1	1	1	1	1	1	1	1	1	) 11 М Г МЧА 1
																																				Ягмт мм:
													1	1	1				1	1			i	1	1	1	1	ж	1	1	1	1	ж	ж	1	] \|\| мт МЧА ¹
																																				\|l MI MID 1
													1	1	1	1			1	1			i	1	1	1	1	1	1	1	1	1	1	1	1	] \|ГМТ SMR 1
																																				1IPR 1 40 1
																																					IPI AMI 1
																																					ГРТ П.& 1
																																					ГРТ ПТ 1
																																					ГРТ STM 1
																											>										I PI ПК 1
																																					ГРТ TST.I
													ж	ж	о	с											с										I IP IK 1
															d	А																					ГТР TRP 1

гоог-гио«| мыч/оли а гхм

///iwkUMtvwr той/ииы A. I

z X z

V z z

W¹

w¹

X z z

> A

W¹И-

Z X

e«

V z у

«4

w’

X a

<•

ж ж z

< z 7

*•< z z

и»

7 u

A z

* u

-j

w /А

ta.

ПА l-Nli.l

IM1 MOI 1

—

1 МГ MSA 1

—

ГМГ МЧА 2

—

ГМ Г MSA.5

—

IMI MIDI

—

IM1 Ml 1)2

—

IMI MID)

—

ГМТ REX 1

—

i mt sai: i

—

I’M Г SMKI

ГМ1 SMR2

1 Ml SMK3

—

1 l⁴U лЧд I

iik аЧ<И

I’Pk KLi

ГРК PSE 2

11’k Ы I

1 PR (Al l

1 PR I M> 1

IPR I N0 2

ГРН I N03

Г PR I NO 4

Г PT AMT.I

IPI 1 I.S. 1

1 PI Н А 1

1 PT ITC 1

ГРТ ITI 1

ГРТ IT1.2

1 PI 1 ITI

IPI 1112

ГРТ ITT)

‘iptphp.i

—

ГРТ PH P.2

—

ГРТ PH P.3

гоог-г-xorsi jiuVojnaixu

тш’иицы A. I

•s.

7 л

ъ w z

ай л

Z-4

»♦

✓

U u

V* w <

fi.

Ь. л

/А

£» л «■a

0»

/А,

4*4

k«

7 j\

b-a, u

k-z k-

►-

ГРГ RCV.I

1 P1 КС V.2

—

1 PI KCV3

—

1 PI RCV4

—

ГГГ RPL 1

LPT RVM 1

Г PT SEP 1

FPT SEP 2

ГРТ SEP.3

1 PI SSPl

1 P1 SSP2

1 Pt SIM 1

1 РГ ПК 1

LPT TRC.I

ГР1 1ST!

Г KI IIT.I

—

1 KI 1(12

—

1 KI PRS.I

1 KI PRS.2

ГKI RSAI

I Kl RSA.2

ГТА LSA.J

ГТА MCSI

Г ГА M(SJ

I IA SSI 1

—

IT A SSL 2

–

ГГА SSL 3

ITA TAB.I

ITA JAH 1

FT A TSE..I

1 IP 11(1

I IP IKP 1

ГОСТРИСО/М’Ж 15408-2—2002

ПРИЛОЖЕНИЕ Б

(справочное)

Функциональные классы, семейства и компоненты

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

ПРИЛОЖЕНИЕ В

(справочное)

Аудит безопасности (FAU)

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

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

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

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

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

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

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

Декомпозиция класса FAL на составляющие его компоненты показана на рисунке ВЛ.

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

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

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

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

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

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

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

Операции

Н а з и а ч е н и е

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

В.2 Генерация данных аудита безопасности (FAU.GEN)

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

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

Рисунок B.I — Декомпозиция класса «Аудит безопасности*

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

«Если в ПЗ/ЗБ включено семейство FAU GEN «Генерация данных аудита безопасности», то следует предусмотреть возможность (в зависимости от выбранного уровня) аудита следующих денсгвия/событий/па-рамегров.

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

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

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

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

Для каждого выбранного функционального компонента в общую совокупность событий, потенциально подвергаемых аудиту, следует включить те указанные в нем события, которые соответствуют уровню, установленному в FAU GEN. Если, допустим, в приведенном выше примере в FAU GCN выбран уровень •базовый». события, указанные в подпунктах а), б) и в), следует отнести к потенциально подвергаемым аудиту.

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

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

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

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

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

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

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

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

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

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

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

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

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

к) ввод/вывод данных с/на заменяемых носителей (таких, как печатные материалы, ленты, дискеты). FAU_GEN.l Генерация данных аудита

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

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

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

Замечания по применению для оценшика

Имеется зависимость от FPT STM. Если точное значение времени событий для данного 00 несущественно, го может быть строго обоснован отказав от згой зависимости.

Операции

Выбор

Для FAU_GEN.1.16 в разделе аудита функциональных требований, входящих в 113/ЗБ. следует выбрать уровень событий, потенциально подвергаемых аудиту, указанный в разделе аудита других функциональных компонентов, включенных в ПЗ/ЗБ. Этот уровень может быть «минимальным», «базовым», «детализированным® или «неопределенным». Если выбирается «неопределенный» уровень, то автору ПЗ/ЗБ следует перечислить в FAU.GEN.I.Ib все события, которые он относит к потенциально подвергаемым аудиту, и этот элемент (FAU_GEN.1.16) можно не использовать.

Назначен и е

Для FAU_GEN.I.Ib автору 113/ЗБ следует составить список иных событий, потенциально подвергаемых аудиту, для включения в список событии, потенциально подвергаемых аудиту. Это могут быть события из функциональных требований, потенциально подвергаемые аудиту более высокого уровня, чем требуется в FAN_GEN.1.16, а также события, генерируемые при использовании специфицированного интерфейса прикладного программирования (API).

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

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

Замечания по применению ;ыя пользователя

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

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

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

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

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

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

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

FAU.SAA.1 Анализ потенциального нарушения

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

Компонент FAl.’ S/VX.I используется для определения совокупности событий, потенциально подвергаемых аудиту, появление которых (каждого отдельно или в совокупности) указывает на потенциальные нарушения ИБО. и правил, применяемых для анализа этих нарушений.

Операции

Н а з н а ч с и и е

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

Н а зн а ч ен не

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

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

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

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

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

а) учетные данные единственного пользователя — один профиль на пользователя:

б) единый идентификатор или общие учетные данные группы — один профиль на всех пользователей с единым групповым идентификатором или общими учетными данными группы;

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

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

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

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

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

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

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

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

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

Операции

Выбор

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

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

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

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

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

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

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

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

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

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

<М

Операции

Назначение

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

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

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

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

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

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

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

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

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

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

Операции

Назначение

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

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

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

В.4 Просмотр аудита безопасности (FAU.SAR)

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

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

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

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

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

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

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

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

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

Назначение

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

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

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

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

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

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

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

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

Операции

Выбор

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

Назначение

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

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

Семейство FAU SEI. содержит требования, связанные с отбором, какие события, потенциально подвергаемые аудиту, действительно подлежат аудиту. События, потенциально подвергаемые аудиту, определяются в семействе FAU_GEN «Генерация данных аудита безопасности», но для выполнения аудита этих событий их слсдуег определить как выбираемые в компоненте FAU SEL.L

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

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

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

Замечания по применению для польювагсля

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

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

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

Права уполномоченных пользователей по просмотру или модификации условий отбора будут регулироваться функциями управления компонента ГМТ MTD.I «Управление данными ФБО».

Операции

Выбор

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

II а з н а ч е н и е

Для FAL_SEL.1.I6 автору ПЗ/ЗБ следует определить список дополнительных атрибутов, на которых основана избирательность аудита.

В.6 Хранение данных аудита безопасности (FAU.STG)

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

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

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

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

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

Операции

Выбор

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

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

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

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

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

Операции

Выбор

В l-AU STG.2.2 автору 113/ЗБ следует специфицировать должны ли ФБО предотвращать или только выявлять модификацию журнала аудита.

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

Назначение

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

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

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

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

Операции

Н а з н а ч с и и е

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

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

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

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

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

Операции

Выбор

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

Н а з н а ч с н и с

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

ПРИЛОЖЕНИЕ Г (справочное)

Связь (FCO)

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

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

Рисунок Г. I — Декомпозиция класса «Связь»

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

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

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

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

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

Если информация или ассоциированные с ней атрибуты каким-либо образом изменяются, подтверждение правильности свидетельства отправления может дать отрицательный результат. Поэтому автору ПЗ/ЗБ следует предусмотреть включение в ПЗ/ЗБ требований целостности из компонента FDP.l.’IT.I •Целостность передаваемых данных».

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

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

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

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

F€()_NRO.l Избирательное доказательство отправления

Операции

Н а з н а ч сине

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

Выбор

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

Н а з н а ч с н и с

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

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

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

Выбор

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

Назначен и е

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

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

FCO-NRO.2 Принудительное доказательство отправления

Операции

Назначен и е

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

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

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

Выбор

В FCO NRO.2.3 автору П3/3Б следует специфицировать польювателя/субъект. который может верифицировать свидетельство отправления.

Н а з и а ч е н и е

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

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

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

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

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

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

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

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

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

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

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

F€O_NRR.1 Избирательное доказательство получения

Операции

Назначен и е

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

Выбор

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

Н а з н а ч е и и е

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

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

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

Выбор

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

Н а з н а ч е и и е

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

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

FCO-NRR.2 Принудительное доказательство получения

Операции

Назначение

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

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

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

Выбор

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

Н а з и а ч е и и е

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

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

ПРИЛОЖЕНИЕ Я

(справочное)

Криптографическая поддержка (FCS)

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

Класс FCS состоит из двух семейств: FCS.CKM «Управление криптографическими ключами» и PCS СОР «Криптографические операции». В семействе FCS_CKM рассмотрены аспекты управления криптографическими ключами, тогда как в семействе PCS СОР рассмотрено практическое применение этих криптографических ключей.

Декомпозиция класса FCS на составляющие его компоненты показана на рисунке ЯЛ.

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

Рисунок Я.) — Декомпозиция класса «Криптографическая поддержка»

Для каждого метола распределения криптографических ключей, реализованного в 00, автору 113/ЗБ следует применить компоненты FCS СКМ.2.

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

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

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

Криптографические функциональные возможности применимы для достижения целей безопасности, специфицированных в классе FCO. а также в семействах FOP DAL. FDP SDI. FDP UCT. FOP LIT. FIA SOS. FIA LAL’. В случае, когда криптографические функциональные возможности используют для достижения целей безопасности из других классов, цели, требующие применения криптографических средств, специфицируют в отдельных компонентах. Цели класса FSC следует учитывать, когда потребители нуждаются в криптографических функциональных возможностях 00.

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

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

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

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

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

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

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

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

Для генерации криптографических ключей обычно используют случайные числа. Тогда вместо FIA SOS.2 «Генерация секретов ФБО» следует использовать компонент FCS СКМ. 1. Компонент FIA S0S.2 следует применять. когда генерация случайных чисел требуется для иных целей.

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

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

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

Операции

Назначен и е

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

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

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

FCS_€KM.2 Распределение криптографических ключей

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

Компонент I-CS СКМ.2 содержит требование определения метола распределения ключей, который может соответствовать некоторому принятому стандарту.

Операции

Назначен и е

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

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

F€S_CKM.3 Доступ к криптографическим ключам

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

Компонент FCS СКМ.З содержит требование определения метода доступа к криптографическим ключам. который может соответствовать некоторому принятому стандарту.

Операции

Назначение

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

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

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

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

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

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

Операции

Н аз н а ч е н и е

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

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

Д.2 Криптографические операции (FCS_C()F)

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

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

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

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

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

в) типа или чувствительности обрабатываемых данных.

Если в ПЗ/ЗБ включен компонент семейства FAU/GEN “Генерация данных аудита безопасности», то аудиту следует подвергать события, связанные с:

г) типами криптографических операций, к которым могут относиться генерация и/или верификация цифровых подписей, генерация криптографических контрольных сумм для обеспечения целостности и/или верификации контрольных сумм, хэширование (вычисление хэш-образа сообщения), зашифрование и/или расшифрование данных, -зашифрование и/или расшифрование криптографических ключей; согласование криптографических ключей и генерация случайных чисел:

д) атрибутами субъекта, которые могут включать в себя как роли субъектов, так и пользователей, ассоциированных с этими субъектами;

е) атрибутами объекта, которые могут включать в себя сведения о пользователях криптографического ключа, роли пользователя, криптографической операции, для которой используется данный ключ, идентификаторе криптографического ключа и сроке его действия.

FCS-C’OP.l Криптографические операции

Замечания по применению для пользователя

В этом компоненте содержатся требования указания криптографических алгоритмов и дтины ключей, используемых при выполнении определяемых криптографических операций и основанных на некотором принятом стандарте.

Операции

Н а з и а ч е и и е

В FCSCOP.1.1 актору ПЗ/ЗБ следует определить выполняемые криптографические операции. Типичными криптографическими операциями являются генерация и/или верификация цифровых подписей, генерация криптографических контрольных сумм для обеспечения целостности и/или верификации контрольных сумм, безопасное хэширование (вычисление хэш-образа сообщения), зашифрование и/или расшифрование данных, зашифрование и/или расшифрование криптографических ключей, согласование криптографических ключей и генерация случайных чисел. Криптографические операции могут выполняться с данными как пользователя, так и ФБО.

В FCS-COP.1.1 автору ПЗ/ЗБ следует определить, какой криптографический алгоритм будет использован. Обычно применяют алгоритмы типа DES, RSA. IDEA, но могут использоваться и другие.

В FCS_C()P. 1.1 автору ПЗ/ЗБ следует определить, какой длины криптографические ключи будут использоваться. Необходимо, чтобы длина ключа соответствовала выбранному алгоритму н предполагаемому применению ключа.

В FCS_COP.1.1 автору ПЗ/ЗБ следует специфицировать стандарт, в соответствии с которым выполняются идентифицированные криптографические операции. При этом можно как ссылаться, так и нс ссылаться на один или несколько опубликованных стандартов, например на международные, государственные, отраслевые или стандарты предприятия.

ПРИЛОЖЕНИЕ Е

(справочное)

Защита данных пользователя (FDP)

Класс ГОР содержит семейства, определяющие требования к функциям безопасности 00 и политикам функций безопасности 00. связанным с зашитой данных пользователя. Этот класс отличается от ПА и FPT тем. что определяет компоненты для зашиты данных пользователя, тогда как НА определяет компоненты для зашиты атрибутов, ассоциированных с пользователем, а ГИГ — для зашиты информации ФБО.

Этот класс нс содержит явного требования • мандатного управления доступом» (Mandatory Access Controls — МАС) или традиционного «дискреционного управления доступом» (Discretionary Access Controls — DAC); тем не менее такие требования могут быть выражены с использованием компонентов этого класса.

Класс PDP не касается явно конфиденциальности, целостности или доступности, чаше всего сочетающихся в политике и механизмах. Тем не менее в ПЗ/ЗБ политику безопасности 00 необходимо адекватно распространить на эти три цели.

Заключительным аспектом этого класса является то. что он специфицирует управление доступом в терминах «операций». «Операция» определяется как специфический тип доступа к конкретному объект)’. В зависимости от уровня абстракции описания автором ПЗ/ЗБ этих операций, они могут определяться как «чтение» н/нли «запись» или как более сложные операции, например «обновление базы данных».

Политики управления доступом определяют доступ к хранилищам информации. Атрибуты представлены атрибутами места хранения. Как только информация считана из хранилища, лицо, имеющее доступ к ней. может бесконтрольно использовать эту информацию, включая се запись в различные хранилища с другими атрибутами. Напротив, политики управления информационными потоками контролируют доступ к информации. независимо от места ее хранения. Атрибуты информации, которые могут быть (или не быть, как в случае многоуровневых баз данных) ассоциированы с атрибутами места хранения, остаются с информацией при ее перемещении. Получатель доступа к информации не имеет возможности изменять ее атрибуты без явного разрешения.

Класс ГОР не рассматривается как полная таксономия политик управления доступом ИТ. поскольку могут быть предложены иные. Сюда включены те политики, для которых спецификация требований основана на накопленном опыте применения существующих систем. Возможны и другие формы доступа, которые не учтены в имеющихся формулировках.

Так. можно представить себе задачу иметь способы управления информационным потоком, определяемые пользователем (например, реализующие автомати зированиую обработку информации «Нс для посторонних»). Подобные понятия могли бы быть учтены путем уточнения или расширения компонентов класса ГОР.

Наконец, при рассмотрении компонентов класса ГОР важно помнить, что эти компоненты содержат требования для функций, которые могут быть реализованы механизмами, которые служат или могли бы служить и для других целей. Например, возможно формирование политики управления доступом (ГОР /\СС), которая использует метки (ГОР 1FF.I) как основу для механизма управления доступом.

Политика безопасности 00 может содержать несколько политик функций безопасности (ПФБ). каждая и з которых будет идентифицирована компонентами двух ориентированных на политики семейств FOP АСС и ГОР IГС. Эти политики будут, как правило, учитывать аспекты конфиденциальности, целостности и доступности так. как это потребуется для удовлетворения требований к 00. Следует побеспокоиться, чтобы на каждый объект обя зательно распространялась по меньшей мере одна ПФБ и чтобы при реали зации различных ПФБ не возникали конфликты.

Декомпозиция класса FDP на составляющие его компоненты приведена на рисунках Е. I и Е.2.

Рисунок Е.1 — Декомпозиция класса «Зашита данных пользователя»

Во время разработки ПЗ/ЗБ с использованием компонентов класса ГОР при их просмотре н выборе необходимо руководствоваться следующим.

Требования класса ГОР определены в терминах функций безопасности (ФБ). которые реализуют ПФБ. Поскольку ОО может одновременно следовать нескольким ПФБ. автору ПЗ/ЗБ необходимо дать каждой из ПФ Б название, на которое можно ссылаться в других семействах. ‘Эго название будет затем использоваться в каждом компоненте, выбранном для определения части требований для соответствующей функции. Это позволяет автору легко указать область действия, например охватываемые объекты и операции, уполномоченные пользователи и т. д.

Как правило, каждое отображение компонента может использоваться только для одной ПФБ. Поэтому, если ПФБ специфицирована в компоненте, то она будет применена во всех элементах этого компонента. Эти компоненты могут отображаться в ПЗ/ЗБ несколько раз. если желательно учесть несколько политик.

Ключом к выбору компонентов из этого семейства является наличие полностью определенной политики безопасности 00. обеспечивающей правильный выбор компонентов из семейств ГОР АСС и ГОР 1ГС. В FDP АСС и ГОР IГС присваивают имя соответственно каждой политике управления доступом или информа-

Рисунок Е.2 — Декомпозиция класса •Зашита данных пользователя» (продолжение)

иконными потоками. Кроме того, эти компоненты определяют субъекты, объекты и операции, входящие и область действия соответствующей функции безопасности. Предполагается, что имена этих политик будут использоваться повсеместно в тех функциональных компонентах, которые имеют операцию запрашивающую назначение или выбор »ПФБ управления доступом» и/или «ПФБ управления информационными потоками». Правила. которые определяют функциональные возможности именованных ПФБ управления доступом или информационными потоками, будут установлены в семействах ГОР ACF и ГОР IFF соответственно.

11иже приведена рекомендуемая последовательность применения этого класса при построении ПЗ/ЗБ. для чего необходимо идентифицировать следующее.

а) Осуществляемые политики, применив семейства FOP ACC и ГОР IFC. Эти семейства определяют область действия каждой политики, уровень детализации управления и могут идентифицировать некоторые правила следования политике.

б) Требуемые компоненты, после чего выполнить все применяемые операции в компонентах, относящихся к политикам. Операции назначения могут выполняться как в обобщенном виде (например, «все файлы»), так и конкретно («файлы •А». «В» и т. д.) в зависимости от уровня легализации.

в) Все применяемые компоненты. относящиеся к функциям, из се

мейств ГОР ACF и FOP IFF. связанные с именованными политиками из семейств FOP АСС и FOP IFC. Выполнить операции, чтобы получить компоненты, определяющие правила этих политик. Следует отразить в компонентах требования к выбранным функциям, как полностью сформулированные, так и предполагаемые (которые будут завершены в ЗБ).

г) Тех, кому будет предоставлена возможность управления атрибутами функций безопасности и их изменения. например только администратору безопасности, только владельцу объекта и т. д., после чего выбрать соответствующие компоненты из класса FMT •Управление безопасностью» и выполнить в них операции. Здесь могут быть полезны уточнения для идентификации недостающих свойств, например некоторые или все и зменения необходимо выполнять только с использованием доверенного маршрута.

д) Все подходящие компоненты класса ГМТ. необходимые для спецификации начальных значений новых объектов и субъектов.

е) Все компоненты семейства FOP ROL. применяемые для отката к предшествующему состоянию.

ж) Вес требования из семейства FOP RIP. применяемые для защиты остаточной ип<|юрмации.

и) Все компоненты из семейств FOP ITC и ГОР ЕТС. используемые при импорте или экспорте данных. указав, как следует обращаться при этом с атрибутами безопасности.

к) Все используемые компоненты, относящиеся к внутренним передачам 00. из семейства ГОР ITT.

л) Требования зашиты целостности хранимой информации из ГОР SDI.

м) Все применяемые компоненты, относящиеся к передаче данных между ФБО, из семейств ГОР ОСТ или ГОР LIT.

Е. I Политика управления доступом (ГОР_АСС)

В основу семейства FDP ЛСС положена концепция произвольного управления взаимодействием субъектов и объектов. Область и цель управления определяются атрибутами получателя прав доступа (субъекта), атрибутами хранилища данных, к которому предоставляется доступ (объекта), действиями (операциями) и ассоциированными правилами управления доступом.

Замечания для пользователя

Компоненты этого семейства дают возможность идентификации (по имени) 11ФБ управления доступом. в основе которых лежат традиционные механизмы дискреционного управления доступом (DAC). В семействе определяются субъекты, объекты и операции, которые входят в область действия идентифицированных политик управления доступом. Правила, определяющие функциональные возможности ПФБ управления доступом. будут установлены другими семействами, такими как FDP ACF и FDP RIP. Предполагается, что имена ПФБ. идентифицированные в семействе FDP АСС. будут использоваться повсеместно в тех функциональных компонентах, которые имеют операцию, запрашивающую назначение или выбор «ПФБ управления доступом*.

В область действия ПФБ управления доступом входит множество триад «субъект, объект, операции*. Следовательно, на субъект могут распространяться несколько ПФБ. но только в различных сочетаниях с объектами и операциями. Разумеется, то же относится и к объектам, и к операциям.

Важнейшим аспектом функции управления доступом, осуществляющий ПФБ управления доступом, является предоставление пользователям возможности модифицировать атрибуты управления доступом. Семейство FDP АСС для этого не предназначено. Часть относящихся к этой проблеме требований не определена, но их можно ввести как уточнение; часть содержится в других семействах и классах, например в классе FMT «Управление безопасностью*.

В семействе ГОР АСС нет требований аудита, поскольку он специфицирует только требования ПФБ управления доступом. Требования аудита присутствуют в семействах, специфицирующих функции для удовлетворения ПФБ управления доступом, идентифицированных в этом семействе.

‘Это семейство предоставляет автору ПЗ/ЗЬ возможность спецификации нескольких политик, например жесткую ПФБ управления доступом в одной области действия и гибкую в другой. Для спецификации нескольких политик управления доступом компоненты этого семейства могут использоваться в ПЗ/ЗБ несколько раз для различных подмножеств операций и объектов. Это применимо к 00. в которых предусмотрено несколько политик для различных подмножеств операций и объектов. Другими словами, автору ПЗ/ЗБ следует специфицировать. применяя компонент АСС. необходимую информацию о каждой из ПФБ. которые будут осуществляться ФБО. Например. ПЗ/ЗБ для ОО. включающего в себя три ПФБ. каждая из которых действует для своей части объектов, субъектов и операций в пределах 00. будет содержать по одному компоненту’ FDP АСС.1 «Ограниченное управление доступом» для каждой из трех ПФБ.

FDP_ACC.l Ограниченное управление доступом

Замечания по применению для пользователя

Термины «объект* и «субьект* применяют для обобщенного предоставления элементов ОО. Для каждой реализуемой политики необходимо четко идентифицировать сущности этой политики. КПЗ объекты и операции можно представить с использованием типов, например именованные объекты, хранилища данных, доступ для чтения и т. и. Для конкретной системы необходимо уточнение обобщающих понятий «объект» и «субьект*. например файлы, регистры, порты, присоединенные процедуры, запросы на открытие и т. п.

Компонент FDP ACC.I определяет, что политика распространяется на некоторое полностью определенное множество операций на каком-либо подмножестве объектов. Он не накладывает никаких ограничений на операции, не входящие в эго множество, в том числе it операции на объектах, на которых иные операции управляются.

Операции

Назначение

В FDP_ACC.1.1 автору ПЗ/ЗБ следует специфицировать уникально именованную ПФБ управления доступом, осуществляемую ФБО.

В FDP_ACC.1.1 автору ПЗ/ЗБ следует специфицировать список субъектов, объектов и операций субъектов на объектах, на которые распространяется данная ПФБ.

FDP_ACC.2 Полное управление доступом

Замечания по применению для пользователя

Компонент FDP АСС.2 содержит требование, чтобы ПФБ управления доступом распространялась на все возможные операции над объектами, включенными в ПФБ.

Автору ПЗ/ЗБ необходимо продемонстрировать, что на любую комбинацию объектов и субъектов распространяется какая-либо ПФБ управления доступом.

Операции

Назначение

В FDP /\CC.2.1 автору ПЗ/ЗБ следует специфицировать уникально именованную ПФБ управления доступом. осуществляемую ФБО.

В FDPACC.2.1 автору ПЗ/ЗБ следует специфицировать список субъектов и объектов, на которые распространяется данная ПФБ. ПФБ будет распространяться па все операции между этими субъектами и объектами.

Е.2 Функции управления доступом (FDP_ACF)

Семейство FDP АСГ описывает правила для конкретных функций, которые могут реализовать политики управления доступом, именованные в FOP. ACC. В FDP ACC также определяется область действия этих политик.

Замечания для пользователя

Эго семейство позволяет автору Г13/ЗБ описать правила управления доступом. В результате правила доступа к объектам системы не будут изменяться. Примером такого объекта является рубрика «Новости дня», которую читать могут все. а изменять — только уполномоченный администратор. Это семейство также позволяет автору ПЗ/ЗБ устанавливать исключения из общих правил управления доступом. Такие исключения будут явно разрешать или запрещать авторизацию доступа к объекту.

Спецификация других возможных типов функций управления, таких как двойное управление, правила последовательности операций или управление исключениями, явно не предусмотрена. Однако зги механизмы. как и механизм дискреционного управления доступом, можно представить с помощью имеющихся компонентов при внимательном отношении к формулированию правил управления доступом.

В этом семействе можно определить ряд ФБ управления доступом, имеющих в основе:

– списки контроля доступа (матрица доступа):
– спецификации управления доступом на основе времени;
– спецификации управления доступом на основе источника:
– атрибуты управления доступом, управляемые их владельцем.

FDP.ACF.1 Управление доступом, основанное на атрибутах безопасности

Замечания по применению для пользователя

Компонент FDP ACF.1 предоставляет требования к механизму, посредничающему при управлении доступом, основанному на атрибутах безопасности субъектов и объектов. Каждый объект и субъект имеет совокупность ассоциированных с ним атрибутов, таких как расположение, время создания, прана доступа (например. списки контроля доступа). Этот компонент позволяет автору ПЗ/ЗБ специфицировать атрибуты, которые будут использоваться для посредничества при управлении доступом, а также правила управления доступом на основе этих атрибутов.

Примеры атрибутов, которые может назначать автор ПЗ/ЗБ. представлены ниже.

Атрибут «идентификатор* может быть ассоциирован с пользователями, субъектами или объектами для использования при посредничестве. Примерами этого атрибута могут быть имя загрузочного модуля программы. используемой при создании субъекта, или атрибут безопасности, назначенный загрузочному модулю программы.

Атрибут «время» может использоваться для определения, что доступ будет предоставляться только в указанные время суток, дни недели или календарный год.

Атрибут «местоположение* мог бы определять место как формирования запроса на операцию, так и выполнения операции, либо то и другое. Применение таких атрибутов может основываться на внутренних таблицах для сопоставления логических интерфейсов ФБО с местами расположения терминалов, процессоров и т. д.

Атрибут «группирование» позволяет, в целях управления доступом, ассоциировать единую группу пользователей с некоторой операцией. При необходимости, для спецификации максимального числа групп пользователей. пользователей в группе и групп, в которые может одновременно входить пользователь, следует использовать операцию уточнения.

Компонент ГОР ACF. 1 содержит также требования, лающие функциям управления доступом возможность явно предоставлять или запрещать доступ к объектам на основании атрибутов безопасности. Его можно использовать для предоставления полномочий, прав доступа или разрешения доступа в пределах 00. Такие полномочия, права или разрешения можно применять к пользователям, субъектам (представляющим пользователей или приложения) и объектам.

Операции

Н а з и а ч с н и с

В FDP_ACF. 1.1 автору ПЗ/ЗБ следует специфицировать имя ПФБ управления доступом, осуществляемой ФБО. Имя и область действия ПФБ управления доступом определяются в компонентах семейства FDP_ACC.

В FDP_ACF. 1.1 автору Г13/ЗБ следует специфицировать атрибуты безопасности н/или именованные группы атрибутов безопасности, которые функция будет использовать при спецификации правил. Такими атрибутами безопасности могут быть, например, идентификатор пользователя, идентификатор субъекта, роль, время суток, местоположение, списки контроля доступа, а также любые другие атрибуты, специфицированные автором ПЗ/ЗБ. /1дя удобства ссылок на атрибуты безопасности неоднократного применения можно ввести именованные группы атрибутов безопасности. Именованные группы могут оказаться полезными при ассоциации «ролей», определенных в семействе FMT_SMR «Роли управления безопасностью», н соответствующих им атрибутов с субъектами. Другими словами, каждую роль можно связать с именованной группой атрибутов.

В FDP_ACF.1.2 автору ПЗ/ЗБ следует специфицировать для данной ПФБ правила управления доступом контролируемых субъектов к контролируемым объектам и к контролируемым операциям на контролируемых объектах. Эти правила определяют, когда доступ предоставляется, а когда в нем отказано. В них могут быть специфицированы функции управления доступом общего характера (использующие, например, обычные биты разрешения) или структурированные функции управления доступом (использующие, например, списки контроля доступа).

В FDP^ACF. 1.3 автору ПЗ/ЗБ следует специфицировать основанные на атрибутах безопасности правила, которые будут использоваться для явного разрешения доступа субъектов к объектам и дополняют правила, установленные в FDP_ACF.I.l. Они вынесены в отдельный элемент FDP_ACF.1.3, поскольку описывают исключения из правил, установленных в FDP_ACF.1.I. Например, правила явного разрешения доступа могут быть основаны на векторе полномочий, ассоциированном с субъектом н всегда обеспечивающим ему доступ к объектам, на которые распространяется специфицируемая ПФБ управления доступом. Если подобная возможность нежелательна, то автору ПЗ/ЗБ следует указать «Нет» в данной операции.

В FDP_ACF. 1.4 автору ПЗ/ЗБ следует специфицировать основанные на атрибутах безопасности правила, которые будут использоваться для явного отказа в доступе субъектов к объектам и дополняют правила, установленные в FDP_ACF.1.1. Они вынесены в отдельный элемент FDP_ACF.1.4, поскольку описывают исключения из правил, установленных в FDP_ACF.1.1. Например, правила явного отказа в доступе могут быть основаны на векторе полномочий, ассоциированном с субъектом н явно отказывающем ему в доступе к объектам, на которые распространяется специфицируемая ПФБ управления доступом. Гели подобная возможность нежелательна, то автору ПЗ/ЗБ следует указать «Нет» в данной операции.

Е.З Аутентификация данных (FDP_DAU)

Семейство FOP OAU описывает специальные функции, используемые для аутентификации «статических» данных.

Замечания для пользователя

Компоненты этого семейства используют при наличии требования аутентификации «статических» данных. г. с., когда данные обозначаются, но нс передаются. (Заметим, что при передаче данных для обеспечения неотказуемости отправления информации используют семейство ГСО К КО).

FDPDAU.1 Базовая аутентификация данных

Замечания по применению для пользователя

Компонент ГОР OAU.I может быть реализован с помощью односторонних хэш-функций (криптографической контрольной суммы, отображения отпечатков пальцев, хэш-образа сообщения) для генерации хэш-значения определяемого документа, которое может использоваться при верификации правильности или подлинности содержащейся в нем информации.

Операции

Назначен» е

В FDP_DAU.1.1 автору ПЗ/ЗБ следует специфицировать список объектов или типов информации, для которых ФБО должны быть в состоянии генерировать свидетельство аутентификации данных.

В FDP_DAU.1.2 автору ПЗ/ЗБ следует специфицировать список субъектов, которые будут в состоянии верифицировать свидетельства аутентификации данных для объектов, указанных в предыдущем элементе. Список может просто перечислить субъектов, если все они известны, или же описание субъектов в списке может носить более общий характер и ссылаться на «тип» субъекта, например на идентифицированную роль.

FDP_DAU.2 Аутентификация данных с идентификацией гаранта

Замечания по применению для пользователя

Компонент ГОР DAU.2 дополнительно содержит требование наличия возможности верифицировать идентификатор пользователя, предоставляющего гарантию аутентификации (например, доверенного третьего лниа).

Операции

Н азначе н и е

В ГОР OAU.2.1 автору ПЗ/ЗБ следует специфицировать список объектов или типов информации, для которых ФБО должны быть в состоянии генерировать свидетельство аутентификации данных.

В ГОР OAU.2.2 автору ПЗ/ЗБ следует специфицировать список субъектов, которые будут в состоянии верифицировать свидетельства аутентификации данных для объектов, указанных в предыдущем элементе, а также идентификатор пользователя, который создал свидетельство аутентификации данных.

Е.4 Экспорт данных за пределы действия ФБО (FDP_ETC)

Семейство ГОР ЕТС определяет функции для экспорта данных пользователя из 00 таким образом, что их атрибуты безопасности могут или полностью сохраняться, или игнорироваться при экспорте этих данных. Согласованность этих атрибутов безопасности обеспечивается семейством FPT TDC «Согласованность данных ФБО между ФБО».

В семействе ГОР ЕТС также рассматриваются ограничения на экспорт и ассоциация атрибутов безопасности с экспортируемыми данными пользователя.

Замечания для пользователя

ГОР ЕТС и соответствующее семейство для импорта данных ГОР ITC определяют, как ОО поступает с данными пользователей, передаваемыми из ОДФ и поступающими в нее. Фактически, семейство ГОР ЕТС обеспечивает экспорт данных пользователей и связанных с ними атрибутов безопасности.

В этом семействе могут рассматриваться следующие действия:

а) экспорт данных пользователей без каких-либо атрибутов безопасности:

б) экспорт данных пользователей с атрибутами безопасности, ассоциированными с этими данными, причем атрибуты безопасности однозначно представляют экспортируемые данные пользователя.

Если применяются несколько ПФБ управления доступом и/или информационными потоками, го может потребоваться повторить этот компонент отдельно для каждой политики (т.е. применить к нему операцию итерации).

FDP_ETC’.l Экспорт данных пользователя без атрибутов безопасности

Замечания по применению для пользователя

Компонент FOP ETC.I используется для спецификации экспорта информации без экспорта атрибутов бе (опасности.

Операции

II а з н а ч е н и с

В FDP_ETC.1.1 автору ПЗ/ЗБ следует специфицировать, какие 11ФБ управления доступом н/нлн информационными потоками будут осуществляться при экспорте данных пользователя. Данные пользователя, которые экспортируются этой функцией, ограничиваются назначением этих ПФБ.

FDP_ETC.2 Экспорт данных пользователя с атрибутами безопасности

Замечания по применению для пользователя

Данные пользователя экспортируются вместе со своими атрибутами безопасности. Эти атрибуты безопасности однозначно ассоцнрованы с данными пользователя. Ассоциация может устанавливаться различными способами. К способам установления ассоциации относятся совместное физическое размещение данных пользователя и артибутов безопасности (например, на одной дискете) или использование криптографических приемов. таких как цифровые подписи, для ассоциации этих атрибутов и данных пользователя. Для обеспечения получения правильных значений атрибутов другим доверенным продуктом ИТ можно использовать семейство FTP ITC «Доверенный казны передачи между ФБО». в то время как семейство FPT TDC «Согласованность данных ФБО между ФБО» может применяться для достижения уверенности в правильной интерпретации этих атрибутов. В свою очередь, семейство FTP TRP «Доверенный маршрут» может применяться для достижения уверенности в инициации экспорта надлежащим пользователем.

Операции

В а зпаче н и с

В FDP_ETC.2.1 автору ПЗ/ЗБ следует специфицировать, какие ПФБ управления доступом и/или информационными потоками будут осуществляться при экспорте данных пользователя. Данные пользователя, которые экспортируются этой функцией, ограничиваются назначением этих ПФБ.

В FDP_ETC.2.4 автору ПЗ/ЗБ следует специфицировать все дополнительные правила управления экспортом или указать «Нет» при их отсутствии. Эти правила будут реализованы ФБО в дополнение к ПФБ управления доступом и/или информационными потоками, выбранными в FDP_ETC.2.1.

Е.5 Политика управления информационными потоками (FDP__IFC)

В семействе FOP I ГС идентифицируются ПФБ управления информационными потоками и специфицируются области действия калсюй такой политики.

Примерами политик безопасности, которые могут быть применены, являются:

– модель безопасности Белла и Ла Папулы (Bell and La Paduia [ B& LJ):
– модель целостности Биба (Biha |Biba]);
– невмешательство (Non-Interference) [Gogol. Gogu2|.

Замечания для пользователя

Компоненты этого семейства дают возможность идентификации ПФБ управления информационными потоками, осуществляемых традиционными механизмами мандатного управления доступом при их наличии в 00. Однако их возможности шире традиционных механизмов мандатного управления доступом. Они могут использоваться для определения политик невмешательства и политик, основанных на переходах между состояниями. В этом семействе для каждой из ПФБ управления ип(]юрмационными потоками ОО определяются субьекты. информация и операции перемещения информации к субъектам и от субъектов. Правила, определяющие функциональные возможности ПФБ управления информационными потоками, будут установлены другими семействами, такими как ГОР IFF и ГОР RIP. ПФБ управления информационными потоками, именованные здесь, в дальнейшем будут использоваться повсеместно в тех функциональных компонентах, которые включают в себя операцию, запрашивающую назначение или выбор «ПФБ управления информационными потоками».

Компоненты этого семейства достаточно гибки. Они позволяют специфицировать домен управления потоками. не требуя, чтобы механизм управления был основан на метках. Разные элементы компонентов управления информационными потоками также допускают различную степень исключений из осуществляемой политики.

Каждая ПФБ распространяется на некоторое множество триад: «субъект, информация, операции перемещения информации к субъектам и от субъектов». Некоторые политики управления информационными потоками могут иметь очень подробную легализацию и описывать субьекты непосредственно в терминах процессов операционной системы. Другие политики могут определяться с меньшими подробностями и описывать

ПО

субъекты в терминах пользователей или каналов ввода/вывода. Если политика управления информационными потоками задана недостаточно подробно, то четкое определение требуемых функций безопасности ИТ может оказаться невыполнимым. В таком случае целесообразнее описывать политики управления информационными потоками как цели бе ^опасности. Тогда требуемые функции безопасности ИТ можно специфицировать, исходя из этих целей.

Во втором компоненте (ГОР IEC.2 «Полное управление информационными потоками*) каждая ПФБ управления информационными потоками будет охватывать все возможные операции перемещения информации к субъектам и от субъектов под управлением этой ПФБ. Более того, требуется, чтобы все информационные потоки были охвачены какой-либо ПФБ, поэтому для каждого действия, вызвавшего перемещение ин-<|м)рмапии. будет существовать совокупность правил, определяющих, является ли данное действие допустимым. Если данный информационный ноток подчинен нескольким ПФБ. то необходимо его разрешение всеми этими политиками до его начала.

Политика управления информационными потоками охватывает полностью определенное множество операций. Для некоторых информационных потоков этот охват может быть «полным», а для других потоков он может относиться только к некоторым из предусмотренных для них операций.

Политика управления доступом обеспечивает доступ к объектам, содержащим информацию. Политика управления информационными потоками обеспечивает доступ к информации, независимо от места ее хранения. Атрибуты информации, которые могут быть (или не быть, как для многоуровневых баз данных) ассоциированы с атрибутами места хранения, остаются с информацией при ее перемещении. Получатель доступа к информации не имеет возможности без явного разрешения изменять ее атрибуты.

Возможны различные уровни представления информационных потоков и операций. В ЗБ информационные потоки и операции можно специфицировать на уровне конкретной системы, например в терминах пакетов TCP/IP. проходящих через межсетевой экран по известным IP-адресам. В ИЗ информационные потоки и операции можно представить с использованием следующих типов: электронная почта, хранилища данных, доступ для чтения и т. д.

Компоненты семейства FDP 1FC могут неоднократно применяться в ПЗ/ЗБ к различным подмножествам операций и объектов (т. е. к ним может быть применена операция итерации). Это позволит адаптировать данное семейство к 00, включающим в себя несколько политик, каждая из которых действует на собственное подмножество субъектов. информации и операций.

FDP_IEC.l Ограниченное управление информационными потоками

Замечания по применению для пользователя

Компонент ГОР 1 FC.I содержит требование, чтобы политика управления информационным потоком применялась к подмножеству возможных операций в 00.

Операции

Н а з паче н и с

В FDP__IFC.I.l автору ПЗ/ЗБ следует специфицировать уникально именованную ПФБ управления информационными потоками, осуществляемую ФБО.

В FDP_IFC.1.1 автору ПЗ/ЗБ следует специфицировать список субъектов, информации и операций, вызывающих перемещение управляемой информации к управляемым субъектам и от них, на которые распространяется данная ПФБ. Как указано выше, этот список субъектов может быть задан с различной степенью детализации, определяемой потребностями автора ПЗ/ЗБ. Он может, например, специфицировать пользователей, устройства или процессы. Информация может относиться к таким данным, как электронная почта, сетевые протоколы. или же к более конкретным объектам, аналогичным объектам, специфицированным в политике управления доступом. Если информация содержится в объекте, который подчинен политике управления доступом, то политики управления доступом и информационными потоками необходимо применять совместно, прежде чем начнется перемещение специфицированной информации в объект или из него.

FDPIFC.2 Полное управление информационными потоками

Замечания по применению для польювагеля

Компонент ГОР IFC.2 содержит требование. чтобы ПФБ управления информационными потоками распространялась на все возможные операции, вызывающие информационные потоки к субъектам и от субъектов. включенных в ПФБ.

Автору ПЗ/ЗБ необходимо продемонстрировать, что на любую комбинацию информационных потоков и субъектов распространяется какая-либо ПФБ управления информационным потоком.

Операции

Назначен и с

В ГОР IFC.2.1 автору ПЗ/ЗБ следует специфицировать уникально именованную ПФБ управления информационными потоками, осуществляемую ФБО.

В FDP_IFC.2.1 автору ПЗ/ЗБ следует специфицировать список субъектов н информации, на которые будет распространяться данная ПФБ. ПФБ будет распространяться на все операции, вызывающие перемещение этой информации к этим субъектам и от них. Как указано выше, этот список субъектов может быть задан с различной степенью детализации, определяемой потребностями ангора ПЗ/ЗБ. Он может, например, спсни-фицнровать пользователей. устройства или процессы. Информация может относиться к таким данным, как электронная почта, сетевые протоколы, или же к более конкретным объектам, аналогичным объектам, специфицированным в политике управления доступом. Если информация содержится в объекте, который подчинен политике управления доступом. го политики управления доступом и информационными потоками необходимо применять совместно, прежде чем начнется перемещение специфицированной информации в объект или из него.

Е.6 Функции управления информационными потоками (FDE^IFF)

Семейство 1-1)1’ IFF описывает правила для конкретных функций, которые могут реализовать ПФБ управления информационными потоками, именованные в ГОР IFC. где также определена область действия соответствующей политики. Семейство содержит два типа требований: один связан с обычными информационными потоками, а второй — с неразрешенными информационными потоками (скрытыми каналами), запрещенными одной или несколькими ПФБ. Это разделение возникает, потому что проблема неразрешенных информационных потоков в некотором смысле противоречит остальным аспектам ПФБ управления информационными потоками. Неразрешенные информационные потоки возникают в нарушение политики, поэтому они не являются результатом применения политики.

Замечания для пользователя

Для реализации надежной зашиты от раскрытия или модификации в условиях недовсренного программного обеспечения требуется управлять информационными потоками. Одного управления доступом недостаточно. так как при нем контролируется только доступ к хранилищам, что позволяет информации, содержащейся в них, бесконтрольно распространяться в системе.

В этом семействе употребляется выражение «типы неразрешенных информационных потоков». Это выражение может применяться при ссылке на известные типы классификации потоков такие как «каналы памяти» или «каналы синхронизации временнйе каналы)», или же на иную классификацию, отражающую потребности автора ПЗ/ЗБ.

Гибкость этих компонентов позволяет специфицировать в FDP IFF.I и FDP IFF.2 политику полномочий. дающую возможность контролируемого обхода ПФБ в целом или частично. Если необходимо заранее предопределигь обход ПФБ. автору ПЗ/ЗБ следует предусмотреть применение политики полномочий.

FDP IFF.1 Простые атрибуты безопасности

Замечания по применению для пользователя

Компонент FDP. 1FF.I содержит требования наличия атрибутов безопасности у информации и субъектов. являющихся отправителями или получателями этой информации. Следует также учитывать атрибуты безопасности мест хранения информации, если требуется их участие в управлении информационными потоками или если на эти атрибуты распространяется политика управления доступом. Этот компонент специфицирует ключевые осуществляемые правила и описывает, как вводятся атрибуты безопасности. Например, компонент следует применять, когда хотя бы одна из ПФБ управления информапионнымз1 потоками основана на метках, как это определяет модель политики безопасности Белла и Ла Папулы |В&1.], но эти атрибуты безопасности не образуют иерархию.

Этот компонент не определяет детали присвоения значений атрибутам безопасности (т. е. пользователем или процессом). Гибкость политики предоставляется операциями назначения, которые позволяют, при необходимости. специфицировать дополнительные требования к политике и функциям.

Компонент FDP IFF.I также предоставляет требования к функциям управления информационными потоками, чтобы они могли явно разрешать или запрещать информационный поток на основе атрибутов безопасности. Ок можег применяться /зля ре&тизашш политики полномочий, предусматривающей исключения из основной политики, определенной в этом компоненте.

Операции

Н а з паче и и е

В FDP_IFF. 1.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления информационными потоками, осуществляемые ФБО. Имя и область действия ПФБ управления информационными потоками определяются в компонентах семейства FDP_1FC.

В FDP_I FF. 1.1 автору ПЗ/ЗБ следует специфицировать минимальное число и тип атрибутов безопасности, которые будут использоваться при спецификации правил. Такими атрибутами безопасности могут быть, например, идентификатор субъекта, уровень чувствительности субъекта, уровень допуска субъекта к информации, уровень чувствительности информации н т. л. Следует, чтобы минимальное число атрибутов безопасности каждого типа было достаточным для поддержки потребностей среды.

В FDP_IFF.1.2 автору ПЗ/ЗБ следует специфицировать дзя каждой операции реализуемые ФБО и основанные па атрибутах безопасности отношения, которые необходимо поддерживать между атрибутами безопасности субъектов и информации.

В FDP1FF.1.3 автору 113/ЗБ следует специфицировать все дополнительные правила ПФБ управления информационными потоками, которые от ФБО требуется реализовать. Если дополнительные правила не используются, то автору ПЗ/ЗБ следует указать «Нет» при выполнении рассматриваемой операции.

В FDP_IFF. 1.4 автору ПЗ/ЗБ следует специфицировать все дополнительные возможности ПФБ, которые от ФБО требуется предоставить. Если дополнительные возможности не предоставляются, то автору 113/ЗБ следует указать «Нет» при выполнении рассматриваемой операции.

В FDP1FF.1.5 автору НЗ/ЗБ следует специфицировать основанные на атрибутах безопасности правила, явно разрешающие информационные потоки и дополняющие правила, определенные в предыдущих элементах. Они вынесены в отдельный элемент FDP_IFF.1.5, поскольку описывают исключения нт правил в предыдущих элементах. Например, правила явного разрешения информационной) потока могут быть основаны на векторе полномочий, ассоциированном с субъектом и всегда обеспечивающим ему возможность инициировать перемещение информации, на которую распространяется специфицированная ПФБ. Если подобная возможность нежелательна. то автору ПЗ/ЗБ следует указать «Нет» в данной операции.

В FDP_1FF.1.6 автору ПЗ/ЗБ следует специфицировать основанные на атрибутах безопасности правила, явно запрещающие информационные потоки и дополняющие правила, определенные в предыдущих элементах. Они вынесены в отдельный элемент FDP_IFF.1.6, поскольку описывают исключения из правил в предыдущих элементах. Например, правила явного запрещения информационного потока могут быть основаны на векторе полномочий, ассоциированном с субъектом и всегда отказывающим ему в возможности инициировать перемещение информации, на которую распространяется специфицированная ПФБ. Если подобная возможность нежелательна. то автору ПЗ/ЗБ следует указать «Нет» в данной операции.

FDP_IFF.2 Иерархические атрибуты безопасности

Замечания по применению для пользователя

Компонент FDP IFF.2 содержит требование, чтобы все ПФБ управления информационными потоками в ИБО использовали иерархические атрибуты безопасности, которые образуют некоторую структуру.

Например, этот компонент следует применять, когда хотя бы одна из ПФБ управления информационными потоками основана на метках, как это определяет модель политики бдзопасности Белла и Ла Падулы [B&L|. и эти атрибуты безопасности образуют иерархию.

Важно отметить, что требования иерархических отношений, идентифицируемые в FDP IFF.2.7. применимы только к атрибутам безопасности управления информационными потоками для ПФБ управления ин-<|м)рмапионными потоками, идентифицированным в FDP IFF.2.1. Этот компонент не применим к другим ПФБ. например к ПФБ управления доступом.

Компонент FDP ИТ. 2. как и предыдущий, может использоваться для реализации политики полномочии. содержащей правила, позволяющие явно разрешать или запрещать информационные потоки.

В случае, когда необходимо специфицировать несколько ПФБ управления информационными потоками. каждая из которых будет иметь собственные атрибуты безопасности, не связанные с атрибутами других политик, в ПЗ/ЗБ следует специфицировать этот компонент для каждой из ПФБ (г. с. выполнить для него операцию итерации). Если этого не сделать, го различные части FDP IFF.2.7 могут противоречить друг другу, поскольку не будут связаны необходимыми соотношениями.

Операции

И а з н а ч е н и е

В FDP 1FF.2.I автору ПЗ/ЗБ следует специфицировать ПФБ управления информационными потоками, осуществляемые ФБО. Имя и область действия ПФБ управления информационными потоками определяются в компонентах семейства FDP IFC.

В FDP IFF.2.1 автору ПЗ/ЗБ следует специфицировать минимальное число и тип атрибутов безопасности. которые будут использоваться при спецификации правил. Такими атрибутами безопасности могут быть, например, идентификатор субъекта. уровень чувствительности субъекта, уровень допуска субъекта к информации. уровень чувствительности информации и т. д. Следует, чтобы минимальное число атрибутов безопасности каждого типа было достаточным для поддержки потребностей среды.

В FDP 1 FF.2.1 автору ПЗ/ЗБ следует специфицировать для каждой операции рсали зуемыс ФБО и основанные на атрибутах безопасности отношения, которые необходимо поддерживать между атрибутами безопасности субъектов и информации. Эти отношения следует основывать на упорядоченных связях между атрибутами безопасности.

В FDP 1FF.2.3 автору ПЗ/ЗБ следует специфицировать все дополнительные правила ПФБ управления информационными потоками, которые от ФБО требуется реализовать. Если дополнительные правила не используются. то автору ПЗ/ЗБ следует указать «Пег» при выполнении рассматриваемой операции.

В FDP IFF. 2.4 автору ПЗ/ЗБ следует специфицировать все дополни тельные возможности ПФБ. которые от ФБО требуется предоставить. Если дополнительные возможности не предоставляются, то автору ПЗ/ЗБ следует указать «Нет» при выполнении рассматриваемой операции.

В IDP I IT.2.5 автору ПЗ/ЗБ следует специфицировать основанные на атрибутах безопасности правила, явно разрешающие информационные потоки и дополняющие правила, определенные в предыдущих элементах. Они вынесены в отдельный элемент FDP IFF.2.5, поскольку описывают исключения из правил в предыдущих элементах. Например, правила явного разрешения информационного потока могут быть основаны на векторе полномочий, ассоциированном с субъектом и всегда обеспечивающим ему возможность инициировать перемещение информации, на которую распространяется специфицированная ПФБ. Если подобная возможность нежелательна, то автору ПЗ/ЗБ следует указать «Нет» в данной операции.

В FDP IFF.2.6 автору ПЗ/ЗБ следует специфицировать основанные на атрибутах безопасности правила, явно запрещающие информационные потоки и дополняющие правила, определенные в предыдущих элементах. Они вынесены в отдельный элемент FDP IFF.2.6, поскольку описывают исключения из правил в предыдущих хзементах. Например, правила явного запрещения информационного потока Moiyr быть основаны на векторе полномочий, ассоциированном с субъектом и всегда отказывающим ему в возможности инициировать перемещение информации, на которую распространяется специфицированная ПФБ. Если подобная возможность нежелательна, то автору ПЗ/ЗБ следует указать «Пет» в данной операции.

FDPIFF.3 Ограничение неразрешенных информационных потоков

Замечания по применению для пользователя

Компонент ГОР IFF.3 следует использовать. когда одна или несколько ПФБ содержат требования по управлению неразрешенными информационными потоками, но ни одна из них не включает в себя требования их устранения.

Для специфицированных неразрешенных информационных потоков следует установить максимально допустимые интенсивности. Кроме того, автор ПЗ/ЗБ имеет возможность определить, необходимо ли подвергать аудиту неразрешенные информационные потоки.

Операции

Назначен и е

В FDP_IFF.3.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления информационными потоками, осуществляемые ФБО. Имя и область действия ПФБ управления информационными потоками определяются в компонентах семейства FDP_IFC’.

В FDP_IFF.3.1 автору ПЗ/ЗБ следует специфицировать типы неразрешенных информационных потоков, максимальная интенсивность которых ограничивается.

В FDP_IFF.3.1 автору ПЗ/ЗБ следует специфицировать максимальную интенсивность, допустимую для каждого из идентифицированных неразрешенных информационных потоков.

FDP_1FF.4 Частичное устранение неразрешенных информационных потоков

Замечания по применению для пользователя

Компонент FDP 1FF.4 следует использовать. когда одна или несколько ПФБ содержат требования по управлению неразрешенными информационными потоками и при этом хотя бы одна из них включает в себя требования устранения хотя бы одного неразрешенного информационного потока.

Операции

Назначение

В ГОР 1FF.4.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления информационными потоками, осуществляемые ФБО. Имя и область действия ПФБ управления информационными потоками определяются в компонентах семейства FDP IFC.

В FOP IFF.4.1 автору ПЗ/ЗБ следует специфицировать типы неразрешенных информационных потоков, максимальная интенсивность которых озраничивасгся.

В FOP IFF.4.I автору ПЗ/ЗБ следует специфицировать максимальную интенсивность, допустимую для каждого из идентифицированных неразрешенных информационных потоков.

В FDP_IFF.4.2 автору ПЗ/ЗБ следует специфицировать типы неразрешенных информационных потоков, подлежащих устранению. Список не может быть пустым, поскольку данный компонент содержит требование устранения хотя бы части неразрешенных информационных потоков.

FDP_IFF.5 Отсутствие неразрешенных информационных потоков

Замечания по применению для пользователя

Компонент FDP 1FF.5 следует использовать, когда ПФБ. содержащие требования по управлению неразрешенными информационными потоками, включают в себя требование полного их устранения. Однако автору ПЗ/ЗБ следует внимательно изучить, какое влияние подобное устранение может оказать на нормальное функционирование 00. Практика показывает возможность опосредованного влияния неразрешенных информационных потоков па работу 00. поэтому их полное устранение может привести к нежелательным последствиям.

Операции

Назначение

В FDP_IFF.5.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления информационными потоками, для которой информационные потоки требуется устранить. Имя и область действия ПФБ управления информационными потоками определяются в компонентах семейства FDP_IFC.

FDP_IFF.6 Мониторинг неразрешенных информационных потоков

Замечания по применению для пользователя

Компонент FDP IFF.6 следует использовать, когда от ФБО требуется проведение мониторинга неразрешенных информационных потоков, интенсивность которых превышает специфицированное пороговое значение. Если такой поток требуется подвергнуть аудиту, то этот компонент может служить источником событий аудита для компонентов семейства ЕЛЕ’ GEN «Генерация данных аудита безопасности».

Операции

В а зн а ч енис

В FDP_1FF.6.1 автору 113/ЗБ следует специфицировать ПФБ управления информационными потоками, осуществляемые ФБО. Имя и область действия ПФБ управления информационными потоками определяются в компонентах семейства FDPIFC.

В FDP_1FF.6.1 автору ПЗ/ЗБ следует специфицировать типы неразрешенных информационных потоков, подлежащих мониторингу на превышение максимального значения интенсивности.

В FDP_1FF.6.1 автору ПЗ/ЗБ следует специфицировать максимальную интенсивность, превышение которой неразрешенным информационным потоком будет отслеживаться ФБО.

Е.7 Импорт данных из-за пределов действия ФБО (FDP_ITC)

Семейство FOP ITC определяет мсхани змы для импорта данных пользователя в ОО из-за пределов ОДФ таким образом, чтобы атрибуты безопасности данных пользователя при этом сохранялись. Согласованность этих атрибутов безопасности определяется семейством FI’T TDC «Согласованность данных ФБО между ФБО».

В FI)P ITC также рассматриваются ограничения на импорт, спецификация атрибутов безопасности пользователем и ассоциация атрибутов безопасности и данных пользователя.

Замечания для пользователя

FDP ITC и соответствующее семейство для экспорта данных FDP.ETC определяют, как ОО поступает с данными пользователей, поступающими в ОДФ и передаваемыми из нее. Оно связано с назначением и игнорированием атрибутов безопасности данных пользователя.

В семействе могут рассматриваться следующие действия:

а) импорт данных пользователя с бесформатного (по отношению к безопасности) носителя (такого, как гибкий диск, магнитная лента, сканер, видео- или аулиосигнат) без атрибутов безопасности и физическая маркировка носителя для указания на его содержание:

б) импорт данных пользователя, включая атрибуты безопасности, с носителя и верификация соответствия атрибутов безопасности объекта:

в) импорт данных пользователя, включая атрибуты безопасности, с носителя с использованием криптографических методов для зашиты ассоциации данных пользователя с атрибутами безопасности.

Семейство FDP 1ТС не имеет отношения к определению возможности импорта данных пользователя. Здесь рассматриваются лишь значения атрибутов безопасности для ассоциации с импортируемыми данными пользователя.

Есть две возможности при импорте данных пользователя: либо они однозначно ассоциируются с достоверными атрибутами безопасности объекта (значения и смысл атрибутов безопасности не меняются), либо никакие достоверные атрибуты безопасности (или вообще какие-либо атрибуты безопасности) не могут быть получены от источника данных. В этом семействе рассмотрены обе возможности.

Если имеются достоверные атрибуты безопасности, их можно ассоциировать с данными пользователя физически (атрибуты безопасности находятся на том же самом носителе) или логически (атрибуты безопасности передаются отдельно, но включают в себя уникальную идентификацию объекта, например криптографическую контрольную сумму).

Семейство связано с импортом данных пользователя и сопровождением их ассоциации с атрибутами безопасности в соответствии с требованиями ПФБ. С аспектами импорта, которые находятся вне области действия этого семейства (например, с непротиворечивостью, доверенными каналами, целостностью), связаны другие семейства. Более того, в семействе FDP ГГС рассматривается только интерфейс для выполнения импорта. Участие в передаче с другой стороны (как источника) рассматривается в семействе FDP ЕТС.

Хорошо известны следующие требования импорта:

г) импорт данных пользователя без каких-либо атрибутов безопасности:

д) импорт данных пользователя, включая ассоциированные с ними атрибуты безопасности, причем атрибуты безопасности однозначно представляют импортируемую информацию.

‘Эти требования импорта могут быть реализованы ФЬО при участии или без участия человека в соответствии с ограничениями ИТ и политикой безопасности организации. Например, если данные пользователя получены по «конфиденциальному» каналу, атрибуты безопасности объекта будут установлены как «конфиденциальные».

Если применяются несколько ПФБ управления доступом н/или информационными потоками, то может потребоваться повторить этот компонент отдельно для каждой политики (т. е применить к нему операцию итерации).

FDP_ITC.I Импорт данных пользователя без атрибутов безопасности

Замечания по применению .тля пользователя

Компонент FDP ITC.1 используется для спецификации импорта данных пользователя, не имеющих достоверных (или вообще никаких) атрибутов безопасности. Эта функция требует, чтобы атрибуты безопасности данных пользователя инициировались ФБО. Правила импорта может специфицировать и автор ПЗ/ЗБ. 13 некоторых средах может потребоваться использование ятя передачи этих атрибутов механизма доверенного маршрута или канала.

Операции

Н а з и а ч е н и е

В FDP_ITC’.1.1 автору ПЗ/ЗБ следует специфицировать, какие ПФБ управления доступом н/нлн информационными потоками будут осуществляться при имшзрге данных пользователя в ОДФ. Данные пользователя, которые импортируются этой функцией, ограничиваются назначенном этих ПФБ.

В FDP_1TC.1.3 автору ПЗ/ЗБ следует специфицировать все дополнительные правила управления импортом или указать «Нет» при отсутствии таковых. Эти правила будут реализованы ФБО в дополнение к ПФБ управления доступом и/нли информационными потоками, выбранным в FDPITC. 1.1.

FDP_ITC.2 Импорт данных пользователя с атрибутами безопасности

Замечания по применению для пользователя

Компонент FDP ПС.2 используется для спецификации импорта данных пользователя, имеющих достоверные атрибуты безопасности, ассоциированные с ними. Эта функция использует атрибуты безопасности, точно и однозначно связанные с объектами на носителе импортируемых данных. После завершения импорта такие объекты будут иметь тс же атрибуты безопасности. При этом требуется привлечение семейства FPT TDC для обеспечения непротиворечивости данных. Правила импорта может специфицировать и автор ПЗ/ЗБ.

Операции

В а з паче и и е

В FDP_ITC.2.1 автору ПЗ/ЗБ следует специфицировать, какие ПФБ управления доступом и/илн информационными потоками будут осуществляться при импорте данных пользователя в ОДФ. Данные пользователя, которые импортируются этой функцией, ограничиваются назначением ПФБ.

В FDP_ITC’.2.5 автору ПЗ/ЗБ следует специфицировать все дополнительные правила управления импортом или указать «Нет» при их отсутствии. Эти правила будут реализованы ФБО в дополнение к ПФБ управления доступом н/или информационными потоками, выбранным в FDP_ITC.2.1.

Е.8 Передача в пределах ОО (РОР_ГГГ)

Семейство FDP ITT содержит требования, связанные с зашитой данных пользователя при их передаче между различными частями ОО по внутреннему каналу. Этим оно отличается от семейств FDP LCT и FDP L I T. которые обеспечивают защиту данных пользователя при их передаче между различными ФБО по внешнему каналу, а также от семейств FDP ЕТС и EDP ITC, которые связаны с передачей данных за пределы или из-за пределов действия ФБО.

Замечания для полью вате л я

Требования этого семейства позволяют автору ПЗ/ЗБ специфицировать желательный способ зашиты данных пользователя во время их передачи в пределах ОО. Эго может быть зашита от раскрытия, модификации или нарушения доступности.

Принятие решения о степени физического разделения, в условиях которого следует использовать это семейство, зависит от предполагаемой среды эксплуатации. В неблагоприятной среде могут возникать риски, связанные с передачей между частями ОО. разделенными всего лишь системной шиной. В более благоприятной среде для передачи можно использовать обычные сетевые средства.

Если применяются несколько ПФБ управления доступом и/или информационными потоками, то может потребоваться повторить этот компонент отдельно для каждой именованной политики (т. е. применить к нему операцию итерации).

FDP_ITT.l Базовая зашита внутренней передачи

Операции

В а з н а ч е н и е

В РОР_ГП.1.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления доступом н/нлн информационными потоками, распространяющиеся на передаваемую информацию.

Выбор

В FDP__ITT. 1.1 автору ПЗ/ЗБ следует специфицировать типы ошибок передачи, от которых следует защищать, используя ФБО, данные пользователя при их передаче. Варианты: раскрытие, модификация, недоступность.

FDP_ITT.2 Разделение передачи по атрибутам

Замечания по применению для пользователя

Компонент FDP IТГ.2 может быть использован, например. для обеспечения различных видов зашиты информации в соответствии с различными уровнями критичности.

Одним из способов разделения данных при передаче является использование разделенных логических или физических каналов.

Операции

Назначение

В FDP ITT.2.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления доступом и/или ипс|юрмацион-ными потоками, распространяющиеся на передаваемую информацию.

В ы б о р

В FDP ITT.2.1 автору ПЗ/ЗБ следует специфицировать типы ошибок передачи, от которых следует заши-шать. используя ФБО. данные пользователя при их передаче. Варианты: раскрытие, модификация, недоступность.

Н а з н а ч е н и е

В FDPITI.2.2 автору ПЗ/ЗБ следует специфицировать атрибуты безопасности, по значениям которых ФБО будут определять, когда данные, пересылаемые между физически разделенными частями ОО, требуют разделения. Например, данные пользователя, ассоциированные с идентификатором одного владельца, перелаются отдельно от данных, ассоциированных с идентификаторами других владельцев. Тогда для определения необходимости разделения данных при передаче используется значение идентификатора их владельца.

FDPITT.3 Мониторинг целостности

Замечания по применению для пользователя

Компонент ГОР ITT.3 используется в сочетании с ГОР ITT.1 или ГОР ITT.2. Он обеспечивает, чтобы ФБО проверяли целостность полученных данных пользователя (и их атрибутов). Компоненты ГОР ГГГ.1 или FOP ITT.2 предоставят данные способом, зашншаютим данные от модификации, а ГОР ITT.3 позволит обнаружить некоторые из модификаций.

Автор ПЗ/ЗБ должен специфицировать вилы ошибок, подлежащих обнаружению. Автору ПЗ/ЗБ следует рассмотреть, помимо прочих нарушений целостности, следующие виды ошибок данных: модификация, под* мена, невосстапавливаемое изменение последовательности, повторное использование, неполнота.

Автору ПЗ/ЗБ необходимо специфицировать, какие действия следует предпринять ФБО при обнаружении ошибки, например игнорировать данные пользователя, запросить данные повторно, сообщить уполномоченному администратору, направить трафик по другим каналам.

Операции

Назначение

В FDP__1TT.3.1 автору ПЗ/ЗБ следует специфицировать, какие ПФБ управления доступом и/или информационными потоками распространяются на передаваемую и проверяемую на ошибки целостности информацию.

В FDP_ITT..3.1 автору ПЗ/ЗБ следует специфицировать типы возможных ошибок целостности, отслеживаемых во время передачи данных пользователя.

В FDP_ITT.3.2 автору ПЗ/ЗБ следует специфицировать действия, предпринимаемые ФБО в случае обнаружения ошибки целостности. ФБО. например, могут запросить повторную передачу данных пользователя. ПФБ, специфицированные в К1)Р_ГГГ.3.1, будут осуществляться как действия, предпринимаемые ФБО.

РОР_ГП’.4 Мониторинг целостности по атрибутам

Компонент ГОР I ГТ.4 используется в сочетании с ГОР ГГТ.2. Он обеспечивает, чтобы ФБО проверяли целостность полученных данных пользователя, переданных по разделенным каналам (в соответствии со значениями специфицированных атрибутов безопасности). Компонент позволяет ангору ПЗ/ЗБ специфицировать действия, предпринимаемые п случае обнаружения ошибки целостности.

Компонент, например, может использоваться для обеспечения как обнаружения различных ошибок целостности, так и действий над информацией на различных уровнях целостности.

Автор ПЗ/ЗБ должен специфицировать вилы ошибок, подлежащих обнаружению. Автору ПЗ/ЗБ следует рассмотреть, помимо прочих нарушений целостности, следующие виды ошибок данных: модификация, подмена. невосстанавливаемое изменение последовательности, повторное использование, неполнота.

Автору ПЗ/ЗБ следует специфицировать атрибуты (и ассоциированные с ними каналы передачи), требующие мониторинга ошибок целостности.

Операции

Назначение

В ГОР ГГГ.4.1 автору ПЗ/ЗБ следует специфицировать, какие ПФБ управления доступом и/или информационными потоками распространяются на передаваемую и проверяемую на ошибки целостности информацию.

В ГОР ГГТ.4.1 автору ПЗ/ЗБ следует специфииировать типы возможных ошибок целостности, отслеживаемых во время передачи данных пользователя.

В FDP_ITT.4.1 автору ПЗ/ЗБ следует специфицировать список атрибутов безопасности, требующих разделения каналов передачи. Этот список используется для определения того, какие данные пользователя будут отслеживаться на ошибки целостности на основе атрибутов безопасности данных и каналов передачи данных. Этот элемент прямо зависит от компонента FDP_ITT.2 •Разделение передачи по атрибутам».

В ГОР ГГГ.4.2 автору ПЗ/ЗБ следует специфицировать действия, предпринимаемые ФБО в случае обнаружения ошибки целостности. ФБО. например, могут запросить повторную передачу данных пользователя. ПФБ. специфицированные в ГОР ГГТ.4.1. будут осуществляться как действия, предпринимаемые ФБО.

Е.9 Защита остаточной информации (FDPRIP)

Семейство FDP RIP связано с необходимостью обеспечения последующей недоступности удаленной информации и отсутствия во вновь созданных объектах информации из объектов, ранее использовавшихся в 00. Это семейство не применяется к объектам, хранимым автономно.

Замечания для пользователя

‘Это семейство содержит требования зашиты информации, которая уже логически удалена или освобождена (недоступна для пользователя. но все еше находится в пределах системы и может быть восстановлена). В частности, это относится к информации, которая содержится в объекте как часть ресурсов ФБО многократного использования, когда уничтожение объекта необязательно эквивалентно уничтожению ресурса или какой-либо части ресурса.

Семейство применимо также при попеременном использовании различными субъектами ресурсов в системе. Например, в большинстве операционных систем для поддержки системных процессов обычно используются аппаратные регистры (в качестве ресурсов). Поскольку процессы постоянно переходят из активного состояния в состояние ожидания и обратно, эти регистры попеременно используются различными субъектами. Хотя подобные действия «■подкачки» можно не считать занятием или освобождением ресурса, к таким событиям и ресурсам может быть применено семейство FDP RIP.

Семейство FDP R1P обычно связано с доступом к информации, не являющейся частью объекта, который определен в данный момент или к которому осуществляется доступ: однако это правило не всегда соблюдается. Пусть, например, объект А является файлом, а объект В — диском, на котором размешается этот файл. Когда объект А удален, доступ к его остаточной информации определяется семейством FDP RIP. хотя она все еше остается частью объекта В.

Важно иметь в виду, что FDP RIP применяется только к объектам типа on-line, а не off-line (т. е. не к автономным объектам, таким как резервные копии объектов па магнитных лентах). Например, если в ОО удаляется файл, в I DP RIP может быть отображено требование отсутствия любой остаточной информации при освобождении ресурса: тем не менее ФБО не могут распространить осуществление этого требования на тот же самый файл, существующий в виде автономной резервной копии. Следовательно, этот файл по-прежнему доступен. Если важно обеспечить недоступность, то автору ПЗ/ЗБ следует удостовериться, что соответствующая цель безопасности для среды отражена в руководстве администратора применительно к автономным объектам.

Семейства FDP RIP и FDP ROL могут вступать в конфликт, когда в первом отображено требование уничтожения остаточной информации во время передачи объекта от приложения к функциям безопасности (т. е. при освобождении объекта). Поэтому результат выполнения операции выбора «недоступность при освобождении ресурса» в FDP RIP нельзя совместить с использованием FDP ROL из-за возможного отсутствия информации, необходимой для отката в предыдущее состояние. В этом случае в FDP RIP следует выбрать «недоступность при распределении ресурса», что позволяет использовать FDP ROL. хотя имеется риск, что ресурс, содержавший информацию, распределен новому объекту до выполнения откага. Если эго произойдет, то откат будет невозможен.

В FDP R1P нет требований аудита из-за того, что в нем не отражены функции, вызываемые пользователем. Аудит распределенных или освобожденных ресурсов будет возможен как часть операций ПФБ управления доступом или информационными потоками.

Это семейство следует применять к объектам, специфицированным в ПФБ управления доступом или информационными потоками автором ПЗ/ЗБ.

FDP_RIP.l Ограниченная зашита остаточной информации

Замечания по применению для пользователя

Компонент FDP RIP.1 содержит требование, что ФБО будут обеспечивать для подмножества объектов 00 отсутствие в распределенном этим объектам или освобожденном ими ресурсе доступной остаточной информации.

Операции

Выбор

В FDPRIP.I.I автору ПЗ/ЗБ следует специфицировать, в каком именно случае, при распределении или освобождении ресурсов, вызывается функция зашиты остаточной информации.

Н а з н а ч е н и е

В FDP_RIP.1.1 автору ПЗ/ЗБ следует привести список объектов, для которых выполняется защита остаточной информации.

FDP_R1P.2 Полная зашита остаточной информации

Замечания по применению для пользователя

Компонент FDP RIP.2 содержит требование, что ФБО будут обеспечивать для всех объектов 00 otcjt-ствие в распределенном этим объектам или освобожденном ими ресурсе доступной остаточной информации.

Операции

Выбор

В FDP RIP.2.1 автору ПЗ/ЗБ следует специфицировать, в каком именно случае. при распределении или освобождении ресурсов, вызывается функция защиты остаточной информации.

Е. 10 Откат (FDPROL)

Семейство FDP ROL связано с необходимостью возврата в полностью определенное допустимое состояние. например, когда пользователю требуется отменить модификацию файла или отменить транзакции при незаконченной серии тран закций применительно к базе данных.

Это семейство предназначено для содействия пользователю в возвращении в полностью определенное допустимое состояние после того, как он решил отменить некоторую совокупность последних действий или. для распределенной базы данных, вернуть все распределенные копии базы данных к состоянию перед выполнением отмененной операции.

Семейства ГОР R1P и ГОР ROL вступает в конфликт, когдва ГОР RIP устанавливает, что содержание ресурса становится недоступным при освобождении ресурса объектом. Тогда ГОР RIP нельзя использовать совместно с ГОР ROL из-за отсутствия необходимой для отката информации. ГОР RIP можно использовать совместно с ГОР ROL. если FOP RIP устанавливает, что при распределении ресурса объекту предыдущее содержание ресурса будет недоступно. Эго возможно потому, что для успешного отката механизм ГОР ROL получит доступ к предыдущей информации, которая все еше может находиться в 00.

На требование отката накладываются некоторые ограничения. Например, текстовый редактор обычно позволяет откат только на определенное число команд. Другой пример связан с резервными копиями. Если лента для резервного копирования перематывалась, а затем на нее производилась новая запись, то первоначальная информация не может более быть восстановлена. Эго также ограничивает возможности отката.

FDP_ROL.I Базовый откат

Замечания по применению для пользователя

Компонент FDP ROL.1 позволяет пользователю или субъекту отменять некоторую совокупность операций над предопределенным множеством объектов. Отмена возможна только в некоторых пределах, например на некоторое число символов или в определенном интервале времени.

Операции

Назначение

В FDPROL.I.I автору ПЗ/ЗБ следует специфицировать ПФБ управления доступом и/или информационными потоками, которые будут осуществляться при выполнении операций отката. Необходимо удостовериться, что откат нс используется для обхода специфицированных ПФБ.

В FDP_ROL. 1.1 автору ПЗ/ЗБ следует специфицировать список операций, допускающих откат.

В FDP ROL.I.I автору ПЗ/ЗБ следует специфицировать список объектов, к которым применима политика отката.

В FDPROL.1.2 автору ПЗ/ЗБ следует специфицировать ограничение, в рамках которого могут выполняться операции отката. Это может быть интервал времени; например могут быть отменены операции, выполненные в течение последних 2 мин. Другими возможными ограничениями могут быть максимальное количество отменяемых операций или размер буфера.

FDP_ROL.2 Расширенный откат

Замечания по применению для пользователя

Компонент FDP ROL.2 содержит требование, чтобы ФБО предоставляли возможность отката всех операций. однако пользователь может выбрать для отката только часть из них.

Операции

Назначен и е

В ГОР R0L.2.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления доступом и/или ПФБ управления информационными потоками, которые будут осуществляться при выполнении операций отката. Необходимо удостовериться, что откат не используется для обхода специфицированных ПФБ.

В ГОР R0L.2.1 автору ПЗ/ЗБ следует специфицировать список объектов, к которым применима политика отката.

В FOP ROL.2.2 автору ПЗ/ЗБ следует специфицировать ограничение, в рамках которого могут выполняться операции отката. Это может быть интерват времени: например могут быть отменены операции, выполненные в течение последних 2 мин. Другими возможными ограничениями могут быть максимальное количество отменяемых операций или размер буфера.

Е.11 Целостность хранимых данных (FDP_SDI)

Семейство ГОР SOI содержит требования, связанные с зашитой данных пользователя во время их хранения в пределах ОДФ.

Замечания для пользователя

Аппаратные сбои и ошибки могут воздействовать на данные, хранимые в памяти. Семейство содержит требования по обнаружению таких непреднамеренных ошибок. В этом семействе также рассматривается целостность данных во время их хранения в ‘запоминающих устройствах в пределах ОДФ.

Для предотвращения модификации данных субъектом требуется вместо этого семейства использовать семейства FDP IFFunnFDP ACF.

FOP SOI отличается от семейства FDP ITT «Передача в пределах ОО». которое защищает данные пользователя от ошибок целостности во время их передачи в пределах 00.

FDP_SI)I.l Мониторинг целостности хранимых данных

Замечания по применению для пользователя

Компонент FOP SOI.I контролирует появление ошибок целостности данных, хранимых на носителе. Автор ПЗ/ЗБ можег специфицировать рапичныс типы атрибутов данных пользователя, на которых будет основан мониторинг.

Операции

Н а з н а ч е и и е

В FDP SDI.I.I автору ПЗ/ЗБ следует специфицировать ошибки целостности, которые будут выявлять ФБО.

В FDP_SDI. 1.1 автору ПЗ/ЗБ следует специфицировать атрибуты .данных пользователя, которые будут использоваться как основа для мониторинга.

FDP_SDI.2 Мониторинг целостности хранимых данных и предпринимаемые действия

Замечания по применению для пользователя

Компонент FDP SDI.2 контролирует появление ошибок целостности данных, хранимых на носителе. Авгор ПЗ/ЗБ может специфицировать, какие действия следует предпринять при обнаружении ошибок целостности.

Операции

Назначение

В ГОР SDI.2.1 автору ПЗ/ЗБ следует специфицировать ошибки целостности, которые будут выявлять ФБО.

В ГОР SOI.2.1 автору ПЗ/ЗБ следует специфицировать атрибуты данных пользователя, которые будут использоваться как основа для мониторинга.

В FDPSDI.2.2 автору ПЗ/ЗБ следует специфицировать действия, предпринимаемые при обнаружении ошибки целостности.

Е.12 Зашита конфиденциальности данных пользователя при передаче между ФБО (FDP.UCT)

Семейство FOP UCT определяет требования по обеспечению конфиденциальности данных пользователя при их передаче по внешнему каналу между 00 и другим доверенным продуктом И Г. Конфиденциальность осуществляется путем предотвращения несанкционированного раскрытия данных при их передаче между двумя оконечными точками. Оконечными точками могут быть ФБО или пользователь.

Замечания для пользователя

Это семейство предоставляет требование защиты данных пользователя при передаче. Семейство FPT ITC. напротив, имеет дело с данными ФБО.

FDP_U€T.l Базовая конфиденциальность обмена данными

Замечания по применению для пользователя:

ФБО имеют возможность защитить от раскрытия некоторые данные пользователя во время обмена. Операции

Н а з н а ч е н и е

В FDP_UCT. 1.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления доступом н/или информационными потоками, которые будут осуществляться при обмене данными пользователя. Указанные политики будут осуществляться для принятия решений о том, кто и какими данными может обмениваться.

Выбор

В FDP_UCT.1.I автору ПЗ/ЗБ следует определить, применяется этот элемент к механизму отправления или получения данных пользователя.

Е. 13 Защита целостности данных пользователя при передаче между ФБО (FDP_U1T)

Семейство ГОР LIT определяет требования по обеспечению целостности данных пользователя при их передаче между ФБО и другим доверенным продуктом ИТ. а также для их восстановления при обнаруживаемых ошибках. Как минимум, это семейство контролирует целостность данных пользователя на предмет модификации. Кроме того, это семейство поддерживает различные способы исправления обнаруженных ошибок целостности.

Замечания для пользователя

Это семейство определяет требования по обеспечению целостности данных пользователя при передаче, тогда как семейство FPT ГП имеет дело с данными ФБО.

Семейства FDP LIT и FDP LCT сходны между собой, поскольку FDP UCT связано с конфиденциальностью данных пользователя. Поэтому тот же самый механизм, который реализует FDP LIT. мог бы использоваться и для реали зации других семейств, таких как FDP UCT или FDP ГГС.

FDP_UIT.I Целостность передаваемых данных

Замечания по применению для пользователя

ФБО имеют базовую способность отправлять и получать данные пользователя способом, позволяющим обнаружить модификацию. Ог ФБО нс требуется попыток восстановления модифицированных данных.

Операции

Назначение

В FDP.UIT.I.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления доступом н/нлн информационными потоками, которые будут осуществляться при обмене данными пользователя. Указанные политики будут осуществляться для принятия решений о том, кто может отправлять или получать данные и какие именно данные могут быть отправлены или получены.

В ы б о р

В FDP.UIT.I.I автору ПЗ/ЗБ следует определить, применять ли этот элемент к ФБО при отправлении или получении объектов.

В FDP_UIT. I. I автору ПЗ/ЗБ следует определить, зашишать ли данные от модификации, удаления, вставки или повторения.

В FDP_U1T.1.1 автору ПЗ/ЗБ следует определить, обнаруживать ли ошибки типа модификации, удаления. вставки или повторения.

В FDP_UIT.1.2 автору ПЗ/ЗБ следует определить, обнаруживать ли ошибки типа модификации, удаления. вставки или повторения.

EDP_U1T.2 Восстановление переданных данных источником

Замечания по применению для пользователя

Компонент FDP UIT.2 предоставляет возможность исправления совокупности идентифицированных ошибок передачи, если требуется — то с по.мошью другого доверенного продукта ИТ. Поскольку другой доверенный продукт ИТ находится за пределами ОДФ. ФБО не .могут управлять режимом его функционирования. Тем не менее в целях восстановления возможно предоставление функций, обладающих способностью выполняться координировано с другим доверенным продуктом ИТ. ФБО, например, могут включать в себя функции. способные побудить доверенный продукт ИТ. являющийся источником, повторить передачу данных после обнаружения ошибки. Этот компонент связан с возможностью ФБО реализовать такое восстановление при ошибках.

Операции

Н а з н а ч с н и с

В FDP_UIT.2.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления доступом и/или информационными потоками, которые будут осуществляться при обмене данными пользователя. Указанные политики будут осуществляться для принятия решений о том, какие данные и каким образом могут восстанавливаться

В FDP_UIT.2.1 автору ПЗ/ЗБ следует привести список ошибок целостности, после которых ФБО с помощью доверенного продукта ИТ, являющегося источником, в состоянии восстановить первоначальное содержание данных пользователя.

FDP_UIT.3 Восстановление переданных данных получателем

Замечания по применению для пользователя

Компонент FDP UIT.3 предоставляет возможность исправления совокупности идентифицированных ошибок передачи. Исправление выполняется без помощи доверенного продукта ИТ. являющею источником. Например, если обнаружены определенные ошибки, то необходима достаточная устойчивость протокола передачи, чтобы дать возможность ФБО выполнить восстановление на основании контрольных сумм и другой предусмотренной протоколом информации.

Операции

Н а з н а ч е н и е

В ГОР U IT.3.1 автору ПЗ/ЗБ следует специфицировать ПФБ управления доступом и/или информационными потоками, которые будут осуществляться при обмене данными пользователя. Указанные политики будут осуществляться для принятия решений о том. какие данные и каким образом могут восстанавливаться.

В ГОР UIT.3.1 автору ПЗ/ЗБ следует привести список ошибок целостности, после которых ФБО, получающие данные, в состоянии самостоятельно восстановить первоначальное содержание данных пользователя.

ПРИЛОЖЕНИЕ Ж

(справочное)

Идентификация и аутентификация (FIA)

Общим требованием безопасности является однозначная идентификация лица и/или объекта. выполняющего в 00 определенные функции. Это предполагает не только установление заявленного идентификатора каждого польювагсля. но также и верификацию того, что каждый пользователь действительно гот. за кого он себя выдает. Это достигается тем. что от пользователей требуется предоставлять ФБО некоторую информацию. которая, по сведениям ФБО. действительно ассоциирована с ними.

Семейства класса FIA определяют требования к функциям, устанавливающим и верифицирующим заявленный идентификатор каждого пользователя. Идентификация и аутентификация требуются для обеспечения ассоциации пользователей с соответствующими атрибутами безопасности (такими, как идентификатор, группы. роли, уровни безопасности или целостности).

Однозначная идентификация уполномоченных пользователей и правильная ассоциация атрибутов безопасности с пользователями и субъектами критичны для осуществления определенных политик безопасности.

Семейство FIA III) предназначено для определения идентификатора пользователя.

Семейство НА LALi предназначено для верификации идентификатора пользователя.

Семейство Г1/Х /\FL предназначено для определения ограничений на число повторных неуспешных попыток аутентификации.

Семейство НА ATD предназначено для определения атрибутов пользователей, применяемых при осуществлении ИБО.

Семейство НА USB предназначено для корректной ассоциации атрибутов безопасности для каждого уполномоченного пользователя.

Семейство НА SOS предназначено для генерации и верификации секретов, удовлетворяющих установленной метрике.

Декомпозиция класса ГОР на составляющие его компоненты приведена на рисунке Ж.1.

Ж.1 Отказы аутентификации (F1A_AFL)

Семейство НА AFL содержит требования по определению числа попыток аутентификации и действиям ФБО в случае их неудачи. Параметрами. определяющими возможное число попыток аутентификации. среди прочих, могут быть количество попыток и допустимый интервал времени.

Процесс открытия сеанса пользователя предусматривает взаимодействие с пользователем. позволяющее открыть сеанс и независимое от фактической реализации. Если число неуспешных попыток аутентификации превысило установленное значение, то блокируются учетные данные пользователя и/или терминал, с которого выполнялись -запросы. Если учетные данные пользователя заблокированы, то он не может войти в систему. Если заблокирован терминал, то он (или его адрес) нс может быть использован для входа в систему. Эта ситуация сохранится, пока условия для повторения попыток открытия сеанса нс будут удовлетворены.

F1A_AFL.1 Обработка отказов аутентификации

Замечания но применению для пользователя

Автор ПЗ/ЗБ может либо установить число неуспешных

Рисунок Ж.1 — Декомпозиция класса •Идентификация и аутентификация» попыток аутентификации, либо доверить эго разработчику 00 или уполномоченному пользователю. Неуспешные попытки аутентификации не просто накапливаются, но скорее будут связаны с каким-либо событием аутентификации. Таким событием может быть число неуспешных попыток с момента последнего сеанса, ус

пешно открытого с данного терминала.

Автор ПЗ/ЗБ может определить список действий, которые должны предприниматься ФБО в случае отказа аутентификации. Уполномоченному администратору также может быть разрешено управлять этими событиями. если такую возможность предусмотрел автор ПЗ/ЗБ. Такими действиями, среди прочих, могут быть: отключение терминала, отключение учетных данных пользователя или подача сигнала тревоги администратору. Условия, при которых произойдет возвращение к обычному режиму работы, необходимо специфицировать через действия.

Чтобы предотвратить полную невозможность обслуживания, в 00 обычно обеспечивается невозможность блокирования учетных данных по меньшей мере одного пользователя.

Автор ПЗ/ЗБ может устанавливать иные действия для ФБО. относящиеся в том числе и к правилам деблокирования процесса открытия сеанса пользователя или подаче сигнала тревоги администратору. Примерами таких действий являются: до истечения установленного времени: пока уполномоченный администратор вновь нс деблокирует терминал или учетные данные пользователя; до истечения времени, связанного с предыдущими неуспешными попытками (например, после каждой неуспешной попытки время блокирования удваивается).

Операции

Назначение

В FIA_AFL. 1.1 автору ПЗ/ЗБ следует специфицировать задаваемое по умолчанию число неуспешных попыток аутентификации, при достижении или превышении которого будут инициироваться определенные действия. В ПЗ/ЗБ можно указать, что «это число выбирается уполномоченным администратором».

В FlA_AFL. 1.1 автору ПЗ/ЗБ следует специфицировать события аутентификации. Примерами являются: число неуспешных попыток аутентификации .тля данного идентификатора пользователя с момента последней успешной попытки; число неуспешных попыток аутентификации для данного терминала с момента последней успешной попытки; число неуспешных попыток аутентификации за последние 10 мин. Необходимо указал, по меньшей мерс одно событие аутентификации.

В F1A_AFL.1.2 автору ПЗ/ЗБ следует специфицировать действия, предпринимаемые в случае достижения или превышения предельного значения числа попыток. Такими действиями могут быть: блокирование учетных данных на 5 мин, блокирование терминала на увеличивающийся интервал времени (число секунд, равное 2″, где п — число неуспешных попыток) или блокирование, с уведомлением администратора, учетных данных вплоть до его снятия администратором. В описании действий следует указать принимаемые меры и сроки их действия (или условия прекращения действия этих мер).

Ж.2 Определение атрибутов пользователя (FIA_ATD)

Все уполномоченные пользователи могут, помимо идентификатора пользователя, иметь другие атрибуты безопасности, применяемые при осуществлении ПБО. Семейство ПА ATD определяет требования для ассоциации атрибутов безопасности с пользователями в соответствии с необходимостью поддержки ПБО.

Замечания для пользователя

Существуют зависимости от определений отдельных политик безопасности. Следует, чтобы такие определения содержали списки атрибутов, необходимых для осуществления политики.

FIA_ATD. I Определение атрибутов пользователя

Замечания по применению для пользователя

Компонент FIA ATD.I специфицирует атрибуты безопасности, которые следует поддерживать на уровне пользователя. Это означает, что назначение и возможное изменение атрибутов безопасности, указанных в списке, осуществляется на уровне пользователя (т. е. для каждого пользователя индивидуально). Иными словами. не следует, чтобы изменение атрибутов из списка, ассоциированного с каким-либо пользователем, влияло на атрибуты безопасности других пользователей.

Если атрибуты безопасности принадлежат труппс пользователей (например, список возможностей группы). пользователю потребуется иметь ссылку (как атрибут безопасности) на соответствующую группу.

Операции

Н а з и а ч е и и е

В FIA_ATD.1.1 автору ПЗ/ЗБ следует специфицировать атрибуты безопасности, ассоциируемые с каждым отдельным пользователем. Примером может служить список, включающий в себя атрибуты «уровень допуска», «идентификатор группы», «права».

Ж.З Спецификация секретов (FIA_SOS)

Семейство FIA SOS определяет требования к механизмам, которые реализуют определенную метрику качества для предоставляемых секретов и генерируют секреты, удовлетворяющие определенной метрике. Примерами таких механизмов могут быть автоматическая проверка предоставляемых пользователями паролей или автоматическая генерация паролей.

Секреты могут генерироваться вне 00. например выбираться пользователями и вводиться в систему. При этом может быть использован компонент FIA S0S.1 для обеспечения соответствия секретов, сгенерированных вне системы, конкретным условиям, таким как минимально допустимый размер, отсутствие в словаре н/или неприменение ранее.

Секреты могут генерироваться самим ОО. В этом случае требование, чтобы сгенерированные 00 секреты соответствовали специфицированной метрике, обеспечивается компонентом НА SOS.2.

Замечания для пользователя

Секреты, рассматриваемые в данном семействе, содержат аутентификационные данные, предъявляемые пользователем механизму аутентификации, основанному на сведениях, которыми располагает пользователь. Когда используются криптографические ключи, вместо этого семейства следует использовать семейства класса FCS.

FIA.S0S.1 Верификация секретов

Замечания по применению для пользователя

Секреты могут создаваться пользователем. Компонент ПА SOS.1 обеспечивает, чтобы для созданных пользователем секретов могло быть верифицировано их соответствие определенной метрике качества.

Операции

Назначение

В FIA_SOS.1.1 автору ПЗ/ЗБ следует предоставить определенную метрику качества. Эта метрика может быть специфицирована как собственно описание проверки качества или как ссылка на государственный стандарт, определяющий метрики качества, соответствие которым необходимо для секретов. К примерам метрик качества относятся описание допустимых символьных структур секретов н/или допустимых размеров секретов.

F1A_SOS.2 Генерация секретов ФБО

Компонент ПА SOS.2 позволяет ФБО генерировать секреты для специальных функций, таких как аутентификация по паролю.

Замечания по применению для пользователя

Если в алгоритме генерации секретов используется генератор псевдослучайных чисел, на его вход следует подавать произвольные величины, что предоставляло бы высокую степень непредсказуемости выходных данных. Эти произвольные величины могут быть получены и з таких доступных параметров системы, как системные часы, значения системных регистров, дата, время и т. д. Эти параметры следует выбирать с таким расчетом, чтобы количество произвольных величин, которое можно из них получить, было бы не менее минимального числа секретов, которые необходимо сгенерировать.

Операции

Н а з н а ч с н и с

В FIA_SOS.2.1 автору ПЗ/ЗБ следует предоставить определенную метрику качества. Эта метрика может быть специфицирована как собственно описание проверки качества или как ссылка на государственный стандарт, определяющий метрики качества, соответствие которым необходимо для секретов. К примерам метрик качества относятся описание допустимых символьных структур секретов и/нлн допустимых размеров секретов.

В FIA_S()S.2.2 автору ПЗ/ЗБ следует представить список функций из числа ФБО, для которых необходимо использовать секреты, генерируемые ФБО. Примером такой функции может служить механизм аутентификации по паролю.

Ж.4 Аутентификаиня пользователя (FIA_UAU)

Семейство ПА UAU определяет типы мсхани змов аутентификации пользователя, предоставляемые ФБО. Оно также определяет те атрибуты, на которых необходимо базировать механизмы аутентификации пользователя.

FIA_UAU.l Выбор момента аутентификации

Замечания по применению для пользователя

Компонент F1A UAU.1 содержит требование, чтобы автор ПЗ/ЗБ определил список действий, которые выполняются при посредничестве ФБО и допускаются ФБО от имени пользователя до того, как будет произведена аутентификация пользователя. Эти действия, выполняемые при посредничестве ФБО. не следует относить к безопасности для пользователей, неверно идентифицировавших себя еше до аутентификации. Все прочие действия, выполняемые при посредничестве ФБО и не включенные в этот список, разрешаются пользователю только после завершения аутентификации.

Этот компонент не применим для разрешения каких-либо действий до выполнения идентификации. Для этого необходимо использовать либо J IA LID.I. либо Г1А LID.2 с соответствующими назначениями.

Операции

Н а з н а ч е н и е

В FIA_UAU.1.1 автору ПЗ/ЗБ следует специфицировать список действий, выполняемых при посредничестве ФБО от имени пользователя, прежде чем завершится аутентификация пользователя. Этот список нс может быть пустым. Если таких действий нет, следует вместо этого компонента использовать компонент FIA_UAU.2. Примером таких действий может служить запрос о помощи при выполнении процедуры логического входа в систему.

F1A_UAU.2 .Аутентификация до любых действий пользователя

Замечания по применению для пользователя

Компонент Fl A UAL.2 содержит требование завершения аутентификации пользователя до выполнения любых действий при посредничестве ФБО от имени этого пользователя.

FIA_Uz\U.3 Аутентификация, защищенная от подделок

Замечания по применению для пользователя

Компонент FIA UAL.3 содержит требования к механизмам, предоставляющим защиту аутентификационных данных. Аутентификационные данные, заимствованные у другого пользователя или полученные незаконным способом, следует обнаружить н/или отвергнуть. Эти механизмы предоставляют уверенность, что пользователи, аутентифицированные ФБО. действительно те. кем они представляются.

Этот компонент применим только для механизмов аутентификации, основанных на уникальных аутентификационных данных (например, биометрических). ФБО не смогут обнаружить и предотвратить тиражирование пароля за пределами ОДФ.

Операции

Выбор

В F1A_UAU.3.1 автору ПЗ/ЗБ следует специфицировать, будут ли ФБО обнаруживать и/или предотвращать подделку данных аутентификации.

В FIA UAU.3.2 автору ПЗ/ЗБ следует специфицировать, будут ли ФБО обнаруживать н/нли предотвращать копирование данных аутентификации.

FIA_UAU.4 Механизмы одноразовой аутентификации

Замечания по применению для пользователя

Компонент FIA_IJAU.4 содержит требования к механизмам аутентификации, основанным на аутентификационных данных одноразового использования. В качестве таких данных может использоваться то. что пользователь имеет или знает, но не свойства самого пользователя. Примеры одноразовых данных аутентификации пользователя: одноразовые пароли, зашифрованные метки времени, случайные числа секретной таблицы преобразований.

Автор ПЗ/ЗБ может определить, к какому механизму (ам) аутентификации применимы эти требования. Операции

Н а з н а ч е н и е

В FIA_UAU.4.1 автору ПЗ/ЗБ следует привести список механизмов аутентификации, к которым применяется это требование. Назначением может быть: «все механизмы аутентификации». Примером назначения может быть: «механизмы аутентификации, используемые для аутентификации пользователей во внешней сети».

FIA_UAU.5 Сочетание механизмов аутентификации

Замечания по применению для пользователя

Применение компонентов НА LAU.5 позволяет специфицировать требования к применению нескольких механизмов аутентификации в 00. Требования, применяемые к каждому отдельному механизму, необходимо выбирать из класса НА. Чтобы отразить различающиеся требования к разным механизмам аутентификации. можно многократно использовать один и тот же выбранный компонент.

Для обеспечения возможностей механизмов аутентификации, а также правил, определяющих успешность аутентификации. можно привлекать функции управления из класса FMT.

Для допуска в систему анонимных пользователей можно ввести механизм аутентификации типа «отсутствие аутентификации». Использование доступа такого типа следует четко разъяснить в правилах Fl A I.AU.5.2.

Операции

Н а з н а ч е н и е

В FIA UAU.5.1 автору ПЗ/ЗБ следует определить предоставляемые механизмы аутентификации. Примером списка механизмов может служить: «отсутствие аутентификации, механизм пароля, биометрия (сканирование сетчатки), механизм ключа шифрования».

В FIA_IJAIJ.5.2 автору ПЗ/ЗБ следует специфицировать правила, описывающие, как механизмы обеспечивают аутентификацию и когда используется каждый из них. Это значит, что для любой возможной ситуации необходимо указать совокупность механизмов, которые могли бы использоваться для аутентификации. Пример такого правила: «Для аутентификации пользователей, имеющих особые права доступа, должны использоваться совместно механизм пароля и биометрия, причем аутентификация успешна при успешной аутентификации каждым механизмом; для аутентификации остальных пользователей должен использоваться только механизм пароля».

Автор ПЗ/ЗБ может задать ограничения, в пределах которых уполномоченному администратору разрешено специфицировать конкретные правила. Пример правила: «аутезгтификация пользователя всегда должна производиться посредством аппаратного ключа; администратор может специфицировать дополнительные механизмы аутентификации, которые также необходимо использовать». .Автор ПЗ/ЗБ может и не специфицировать ограничения, а оставить выбор механизмов аутентификации и их правил полностью на усмотрение уполномоченного адм н нистратора.

F1A_UAU.6 Повторная аутентификация

Замечания по примснснзпо для пользователя

В компоненте FIA LAU.6 рассматривается потенциальная потребность повторной аутентификации пользователей в определенные моменты времени. Эго может возникнуть при обращенизз пользователя к ФБО с запросом о выполнении действий, критичных по безопасности, а также при запросах о повторной аутентификации. исходящих ог сущностей, не связанных с ФБО. например от серверного приложения. которое запрашивает от ФБО повторную аутентификацию обслуживаемого клиента.

Операции

Н а з на ч сине

В FIA_UAU.6.1 автору ПЗ/ЗБ следует привести список условий, требующих повторной аутентификации. Этот список может включать в себя завершение периода времени, выделенного пользователю, запрос пользователя с целью изменения действующих атрибутов безопасности или запрос пользователя к ФБО с целью выполнения некоторых критичных функций безопасности.

Автор ПЗ/ЗБ может задать пределы, в которых следует допускать повторную аутентификацию, оставив их детализацию на усмотрение уполномоченного администратора. Пример подобного правила: «пользователь должен проходить повторную аутентификацию не реже одного раза в сутки; администратор может потребовать более частую повторную аутентификацию, но не чаше одного раза в 10 мин».

FIAUALI.7 Аутентификация с защищенной обратной связью

Замечания по применению для пользователя

В компоненте HA_UAU.7 рассматривается обратная связь с пользователем в процессе аутентификации. В некоторых системах обратная связь выражается в гом. что пользователю сообщается количество набранных им символов, но сами символы скрываются; в других системах даже эта информация может считаться неприемлемой.

Этот компонент содержит требование, чтобы аутентификационные данные не возвращались пользователю в первоначальном виде. В рабочих станциях принято представлять набранные символы пароля условными знаками (например, звездочками).

Операции

Назначен и е

В FIA_UAU.7.1 автору ПЗ/ЗБ следует определить вид обратной связи с пользователем при проведении аутентификации. Примером такого назначения может служить: «число набранных символов», другой тип обратной связи — «механизм аутентификации, через который не удалось осуществить аутентификацию».

Ж.5 Идентификация пользователя (FIA_UID)

Семейство ПЛ 1’11) определяет условия, при которых от польювагелей требуется собственная идентификация до выполнения при посредничестве ФБО каких-либо иных действий, требующих идентификации пользователя.

F1A_UID.I Выбор момента идентификации

Замечания по применению для пользователя

Компонент ПА U1D.1 устанавливает требования по идентификации пользователей. Автор ПЗ/ЗБ может указать конкретные действия, которые могут быть выполнены до завершения идентификации.

При использовании компонента упоминаемые в нем действия, которые допускается выполнять при посредничестве ФБО до идентификации, следует также привести и в компоненте ПА UAL.1.

Операции

Н а з н а ч е н и е

В FIA_U1D. 1.1 автору ПЗ/ЗБ следует специфицировать список действий, выполняемых при посредничестве ФБО от имени пользователя до его собственной идентификации. Этот список не может быть пустым. Если приемлемых действии нет, следует вместо этого компонента использовать компонент FIA_UID.2. Примером таких действий может служить запрос о помощи при выполнении процедуры логического входа в систему.

FIA_UID.2 Идентификация до любых действий пользователя

Замечания по применению для пользователя

Компонент ПА UID.2 содержит требование идентификации пользователей. До идентификации пользователя ФБО не допускают выполнение им никаких действий.

Ж.6 Связывание пользователь-субъект (F1A_USB)

Для работы с 00 аутентифицированный пользователь обычно активизирует какой-либо субъект. Тогда атрибуты безопасности этого пользователя ассоциируются (полностью или частично) с этим субъектом. Семейство ПА LSB определяет требования по созданию и сопровождению ассоциации атрибутов безопасности пользователя с субъектом, действующим от имени пользователя.

FIA USB.l Связывание нользовагель-субъекг

Замечания по применению для полью ваге л я

Выражение «действующий от имени», использовавшееся и ранее, требует некоторых пояснений. Установлено. что субъект действует от имени пользователя, создавшего субъект или активизировавшего его для решения некоторой задачи. Поэтому, когда субъект создается, то он действует от имени пользователя. инициировавшего его создание. Если пользователь предпочитает анонимность, субъект также действует от его имени. но идентификатор этого пользователя неизвестен. Особую категорию составляют субъекты, которые обслуживают нескольких пользователей (например, серверный процесс). Тогда «владельцем» этого субъекта считается пользователь, создавший его.

ПРИЛОЖЕНИЕ И (справочное)

Управление безопасностью (FMT)

Рисунок И.1 — Декомпозиция класса «Управление безопасностью»

Класс FMT предназначен для спецификации управления некоторыми аспектами ФБО: атрибутами безопасности, данными и отдельными функциями. Могут быть также установлены различные роли управления и определено их взаимодействие, например распределение обязанностей.

Если 00 состоит из нескольких физически разделенных частей, образующих распределенную систему, то проблемы синхронизации, относящиеся к распространению атрибутов безопасности, данных ФБО и модификации функций становятся очень сложными, особенно когда требуется дублирование информации в различных частях 00. Эти проблемы следует принять во внимание при выборе компонентов I МТ REV.1 «Отмена» и FMT SAE.I «Ограниченная по времени авторизация», поскольку при этом возможно нарушение нор-матьного выполнения ФБО. В такой ситуации рекомендуется воспользоваться компонентами семейства FPT TRC.

Декомпозиция класса FMT на составляющие его компоненты приведена па рисунке И.1.

И. 1 Управление отдельными функциями ФБО (FMT-MOF)

Функции управления из числа ФБО дают уполномоченным пользователям возможность устанавливать операции безопасности ОО и управлял» ими. Эти административные функции обычно подразделяются на несколько категорий.

а) Функции, относящиеся к управлению доступом, учету пользователей и аутентификации, реализованные в 00. Например, определение и обновление характеристик безопасности пользователей (таких, как уникальные идентификаторы, ассоциированные с именами пользователей, учетные данные пользователей, параметры входа в систему), определение и обновление средств управления аудитом системы (выбор событий аудита, управление журналами аудита, анализ журнала аудита и генерация отчетов аудита), определение и обновление атрибутов политики, назначенных пользователю (таких, как уровень допуска), определение системных меток управления доступом. управление группами пользователей.

б) Функции управления, относящиеся к контролю доступности. Например, определение и модификация параметров доступности или квот ресурсов.

в) Функции управления, связанные в основном с инсталляцией и конфигурацией. Например, конфигурация 00. ручное восстановление, инстал

ляция исправлений, относящихся к безопасности 00 (при их наличии). восстановление и реинсталляция аппаратных средств.

г) Функции управления, связанные с текущим управлением и сопровождением ресурсов 00. Например, подключение и отключение периферийных устройств, установка съемных носителей памяти, резервное копирование и восстановление объектов пользователей и системы.

Отметим, что эти функции требуется представить в 00 на основе семейств, включенных в 113 или ЗБ. На автора ПЗ/ЗБ возлагается ответственность за предоставление функций управления сисгемоз) безопасным образом.

Допускается включение в число ФБО функций, которыми может управлять администратор. Например, могут быть предусмотрены отключение функций аудита, переключение синхронизации времени, модификация механизма аутентификации.

FMT_MOF. 1 Управление режимом выполнения функции безопасности

Компонент FMT MOF.I предоставляет идентифицированным ролям возможность управления функциями из числа ФБО. Может потребоваться выяснить текущее состояние функции безопасности, отключить или подключить функцию бе зопасности, модифицировать режим ее выполнения. Примером модификации режима выполнения является изменение механизмов аутентификации.

Операции

Выбор

В FMT^MOF.I.l автору ПЗ/ЗБ следует выбрать для роли возможность следующих действии: определение режима выполнения функции безопасности, отключение функций безопасности, подключение функций безопасности и/илн модификация режима выполнения функций безопасности.

Н а з н а ч с н и с

В FMT MOF.1.1 автору ПЗ/ЗБ следует специфицировать функции, которые могут быть модифицированы идентифицированными ролями. Примерами таких функций являются функции аудита или определения времени.

В FMT_M()F.l.l автору 113/31» следует специфицировать роли, которые допускаются к модификации функций из числа ФБО. Все возможные роли специфицированы в FMT.S.MR.I.

И.2 Управление атрибутами безопасности (FMТ_М8Л)

Семейство FMT MSA определяет требования по управлению атрибутами безопасности.

У пользователей, субъектов и объектов есть ассоциированные атрибуты безопасности, которые оказывают влияние на режим выполнения ФБО. Примерами атрибутов безопасности являются группы, в которые входит пользователь, роли, которые он может принимать, приоритет процесса (субъекта), а также права, которыми наделены роль или пользователь. Может возникнуть необходимость в управлении этими атрибутами безопасности со стороны пользователя, субъекта или специально уполномоченного пользователя (пользователя с явно представленными правами такого управления).

Существенно, что право на назначение прав пользователям само по себе является атрибутом безопасности и/или потенциальным субъектом управления в компоненте FMT MSA.I.

Компонент FMT MSA.2 можно использовать для обеспечения, чтобы выбранное сочетание атрибутов безопасности находилось в рамках безопасного состояния. Определение, что понимать как «безопасное*, возлагается на руководство 00 и модель ПБО. Если разработчик предоставил четкое определение безопасных значений и доводы, почему их следует считать безопасными, зависимостью FMT MSA.2 от ADV SPM.1 можно пренебречь.

В некоторых случаях субъекты, объекты или учетные данные пользователей создаются заново. Если при этом не заданы явно значения атрибутов безопасности, связанные с субъектами, объектами или пользователями. го необходимо использовать значения по умолчанию. Компонент FMT MSA.I можно использовать для определения, что этими значениями, задаваемыми по умолчанию, можно управлять.

FMT_MSA. I Управление атрибутами безопасности

Компонент FMT MSA.1 допускает пользователей, исполняющих некоторые роли, к управлению идентифицированными атрибутами безопасности. Принятие роли пользователем осуществляется в компоненте FMT SMR.1.

Задаваемым по умолчанию называется значение параметра, которое он принимает, когда отображаетсз1 без специально указанного значения. Начальное же значение предоставляется при отображении (создании) параметра, заметая заданное по умолчанию.

Операции

Н а з паче н и с

В F\1T_MSA.1.1 автору ПЗ/ЗБ следует указать ПФБ управления доступом или информационными потоками, .гзя которой применимы атрибуты безопасности.

Выбор

В FMT_MSA.1.1 автору ПЗ/ЗБ следует специфицировать операции, которые можно применять к идентифицированным атрибутам безопасности. .Автор НЗ/ЗБ может специфицировать, что роль допускается к изменению задаваемых по умолчанию значений атрибутов безопасности, запросу и модификации значений атрибутов безопасности, полному удалению атрибутов безопасности, а также определить собственные операции с ними.

Н а з паче и и с

В FMT_MSA.1.1, если сделан соответствующий выбор, автору ПЗ/ЗБ следует специфицировать, какие дополнительные операции может выполнять роль. Примером такой операции может быть «создать».

В FMT_MSA. I. I автору ПЗ/ЗБ следует специфицировать атрибуты безопасности, которыми могут оперировать идентифицированные роли. Допускается, что автор ПЗ/ЗБ специфицирует возможность у правления задаваемыми по умолчанию величинами, такими как задаваемые по умолчанию права доступа. Примерами этих атри-бугов безопасности являются: уровень допуска, приоритет уровня обслуживания, список управления доступом, права доступа по умолчанию.

В FMT.MSA.1.I автору ПЗ/ЗБ следует специфицировать роли, которые допушены к операциям с атрибутами безопасности. Все возможные роли специфицированы в FMT_SMR. 1.

FMT_MSA.2 Безопасные значения атрибутов безопасности

Компонент FMT MSA.2 содержит требования к значениям, которые могут присваиваться атрибутами безопасности. Следует присваивать такие значения, чтобы 00 оставался в безопасном состоянии.

Определение, что является •безопасным», в этом компоненте не раскрывается, но оставлено для класса «Разработка» (конкретно, для компонента ADV SPM.1 «Неформальная модель политики безопасности 00») и руководств. Примером может служить нетривиальный пароль, назначаемый пользователю при регистрации.

FMT.MSA.3 Инициализация статических атрибутов

Замечания по применению для пользователя

Компонент FMT MSA.3 содержит требования, чтобы ФБО предоставлял возможность как присвоения атрибутам безопасности обьекгов значений по умолчанию, гак и их замены начальными значениями. Действительно. для новых объектов возможно иметь при создании различающиеся значения атрибутов безопасности. если существует механизм спецификации полномочий во время создания объекта.

Операции

Н а з н а ч е и и е

В FMTMSA.3.1 автору ПЗ/ЗБ следует указать ПФБ управления доступом или информационными потоками, для которой применимы атрибуты безопасности.

Выбор

В FMT_MSA.3.1 автору ПЗ/ЗБ следует специфицировать, будут ли заданные по умолчанию свойства атрибутов управления доступом ограничивающими, разрешающими или иного характера. В последнем случае автору ПЗ/ЗБ следует уточнить характер этих свойств.

Н а з н а ч е н и е

В F.MT_MSA.3.2 автору ПЗ/ЗБ следует специфицировать роли, которые допущены к модификации значении атрибутов безопасности. Все возможные роли специфицированы в FMT_SMR.l.

И.З Управление данными ФБО (FMT_MTD)

Семейство FMT MTD устанавливает требования по управлению данными ФБО. Примерами данных ФБО являются текущее время и журнал аудита. Например, это семейство дает возможность специфицировать, кому разрешено читать, удалять или создавать журнал аудита.

FMT_MTD.l Управление данными ФБО

Компонент FMT MTD.I позволяет пользователям, которым присвоены определенные роли, управлять значениями данных ФБО. Назначение пользователей на роль рассмотрено в компоненте I МТ SMR.I.

Задаваемым по умолчанию называется значение параметра, которое он принимает, когда отображается без специально указанного значения. Начальное же значение предоставляется при отображении (создании) параметра, замещая заданное по умолчанию.

Операции

Выбор

В FMT_MTD.1.1 автору 113/ЗБ следует специфицировать операции, которые могут быть применены к идентифицированным данным ФБО. Автор 113/ЗБ может специфицировать, что роль может изменять заданные по умолчанию значения, выполнять очистку, чтение, модификацию или полное удаление данных ФБО. По желанию автор ПЗ/ЗБ может специфицировать какой-либо тип операции. «Очистка данных ФБО* означает, что содержание данных удаляется, но сама суншость остается в системе.

Н а з н а ч с н и с

В FMT-MTD.1.1, если сделан соответствующий выбор, автору 113/ЗБ следует специфицировать, какие дополнительные операции может выполнять роль. Примером такой операции может быть «создать».

В FMT_MTD.1.I автору ПЗ/ЗБ следует специфицировать, какими данными ФБО могут оперировать идентифицированные роли. Допускается, что автор ПЗ/ЗБ специфицирует возможность управления значениями, задаваемыми по умолчанию.

В FMT_MTD.1.1 автору ПЗ/ЗБ следует специфицировать роли, которые допущены к операциям с данными ФБО. Все возможные роли специфицированы в FMT_SMR.l.

FMT_MTD.2 Управление ограничениями данных ФБО

Компонент F.MT MTD.2 специфицирует граничные значения для данных ФБО и действия, предпринимаемые в случае их превышения. Могут быть указаны, например, допустимый объем журнала аудита и действия при его переполнении.

Операции

Назначение

В FMT_MTD.2.I автору ПЗ/ЗБ следует специфицировать данные ФБО, имеющие ограничения, и значения этих ограничении. Примером таких данных ФБО является число пользователей, осуществивших вход в систему.

В FMTMTD.2.1 автору ПЗ/ЗБ следует специфицировать роли, которые допущены к модификации как ограничении данных ФБО, гак и действий в случае нарушения ограничений. Все возможные роли специфицированы в FMTJiMR.l.

В FMT_MTD.2.2 автору ПЗ/ЗБ следует специфицировать действия, предпринимаемые в случае превышения предельных значений специфицированных данных ФБО. Примером таких действий, выполняемых ФБО, является информирование уполномоченного администратора и генерация записи аудита.

FMT_MTD.3 Безопасные данные ФБО

Компонент FMT MTD.3 распространяется на требования к значениям, которые могут присваиваться данным ФБО. Следует присваивать такие значения, чтобы 00 оставался в безопасном состоянии.

Определение, что является «безопасным», в этом компоненте не раскрывается, а оставлено для класса • Разработка» (конкретно для компонента ADV SPM.I •Неформальная модель политики безопасности ОО») и руководств. Если разработчик предоставил четкое определение безопасных значений и объяснение, почему их следует считать безопасными, зависимостью 1’МТ MSA.2otADV Sl’M.l можно пренебречь.

И.4 Отмена (FMT.REV)

Характеристика семейства

Семейство F.MT REV связано с отменой атрибутов безопасности различных сущностей в пределах 00. FMT_REV.l Отмена

В компоненте F.MT REV.1 специфицируются требования по отмене прав. Он содержит требование спецификации правил отмены, например:

а) отмена произойдет при следующем входе пользователя в систему;

б) отмена произойдет при следующей попытке открыть файл;

в) отмена произойдет по истечении установленною времени, что может означать пересмотр всех открытых соединений через каждые Л мин.

Операции

Выбор

В FMT_REV.1.1 автору ПЗ/ЗБ следует специфицировать. должна ли быть предоставлена возможность отменять с использованием ФБО атрибуты безопасности пользователей, субъектов, объектов или каких-либо иных ресурсов. Если выбран последний вариант, то следует использовать операцию уточнения для определения ресурсов.

Н а з н а ч е и и е

В FMT_REV. 1.1 автору ПЗ/ЗБ следует указать роли, которые допущены к отмене атрибутов безопасности. Все возможные роли специфицированы в FMT_SMR. 1.

В FMT_REV.1.2 автору ПЗ/ЗБ следует специфицировать правила отмены. К правилам, в частности, могут быть отнесены: «перед следующей операцией над ассоциированным ресурсом» или «при создании каждого нового субъекта».

И.5 Срок действия атрибутов безопасности (FMT_SAE)

Семейство FMT SAE связано с возможностью установления срока действия атрибутов безопасности. Оно может применяться при спецификации требований к сроку действия атрибутов управления доступом, атрибутов идентификации и аутентификации, сертификатов (например, сертификатов ключей типа Х.509). атрибутов аудита и т. л.

FMT_SAE.l Ограниченная по времени авторизация

Операции

II а з н а ч е н и с

В FMT_SAE. 1.1 автору ПЗ/ЗБ следует представить список атрибутов безопасности, для которых поддерживается ограничение срока действия. Примером такого атрибута является уровень допуска пользователя.

В FMT_SAE.I.l автору ПЗ/ЗБ следует указать роли, которые допущены к назначению срока действия атрибутов безопасности. Все возможные роли специфицированы в FMT_SMR.I.

В FMT_SAE.1.2 автору ПЗ/ЗБ следует представить список действий, предпринимаемых по отношению к каждому атрибуту безопасности, когда заканчивается срок его действия. Примером является назначение уровню допуска пользователя, по истечении срока его действия, значения, минимального для данного ОО. Если в ПЗ/ЗБ предусматривается и немедленная отмена, то следует специфицировать действие «немедленная отмена».

И.6 Роли управления безопасностью (FMT_SMR)

Семейство F.MT SMR уменьшает вероятность ущерба, который могут нанести пользователи действиями. выходящими за рамки назначенных им функциональных обязанностей. В семействе также рассматривается противодействие угрозе применения неадекватного механизма, предоставляемого для безопасного управления ФБО.

Это семейство содержит требования к предоставлению ин(]юрмании по поддержке идентификации полномочий пользователя на применение отдельных административных функций, относящихся к безопасности.

Некоторые действия управления могут выполнять пользователи, другие — только специально назначенные лица из данной организации. Семейство позволяет определять различные роли, такие как владелец, аудитор. администратор, дежурный администратор.

Все роли из этого семейства связаны с безопасностью. Каждая роль может предоставлять широкие возможности (например, доступ ко всей структуре UNIX) или незначительные права (например, право чтения объектов единственного типа, таких как файл помощи). Все роли определяются в этом семействе. Возможности ролей определяются в семействах FIA МОГ, FMT MSA и FMT MTD.

Некоторые типы ролей могут быть взаимно исключающими. Например, дежурный администратор может быть способен определять и активизировать пользователей, но не удалять их (эта возможность закреплена за ролью администратора). Это семейство допускает спецификацию политик двойного управления.

FMT.SMR.I Роли безопасности

Компонент FMT SMR.I определяет различные роли, которые ФБО следует распознавать. В системах часто проводится различие между владельцем сущности, администратором и остальными пользователями.

Операции

Назначение

В FMT_SMR.l. автору ПЗ/ЗБ следует специфицировать роли, которые распознаются системой. Это роли, которые могут исполнять пользователи относительно безопасности. Примеры ролей: владелец, аудитор, администратор.

FMT_SMR.2 Ограничения на роли безопасности

Компонент FMT SMR.2 специфицирует различные роли, которые ФБО следует распознавать, и условия. при которых этими ролями можно управлять. В системах часто проводится различие между владельцем сущности, администратором и другими пользователями.

Условия, налагаемые на роли, определяют взаимоотношения различных ролей, а также ограничения на принятие роли пользователем.

Операции

Назначение

В I M Г SMR.2.1 автору 113/3Б следует специфицировать роли, которые распознаются системой. Это роли, которые могут исполнять пользователи относительно безопасности. Примеры ролей: владелец. аудитор, администратор.

В FMT_SMR.2.3 автору ПЗ/ЗБ следует специфицировать условия, которым необходимо следовать при управлении назначением роли. Примерами таких условий являются: «заказчик нс может исполнять роль аудитора или администратора» или «пользователю, исполняющему роль ассистента, необходимо также исполнять роль владельца».

FMT_SMR.3 Принятие ролей

Компонент FMT SMR.3 определяет, что для принятия некоторых ролей необходим точный запрос. Операции

Н а з н а ч е н и е

В FMT_SMR.3.I автору ПЗ/ЗБ следует специфицировать роли, для принятия которых требуется точный запрос. Примеры: аудитор и администратор.

ПРИЛОЖЕНИЕ К

(справочное)

Приватность (FPR)

Класс FPR описывает требования, которые могут накладываться для удовлетворения потребности пользователя и приватности, допуская максимально возможную гибкость системы, но оставляя в то же время возможной поддержку достаточного управления функционированием системы.

Компоненты этого класса достаточно гибки, чтобы учитывать, распространяется ли действие затребованных функций безопасности на уполномоченных пользователей. Например, автор ПЗ/ЗБ мог бы указать, что не потребуется зашита приватности пользователя от пользователей, наделенных специальными полномочиями.

Декомпозиция класса FPR на составляющие его компоненты приведена на рисунке К.1.

Рисунок К.1 — Декомпозиция класса «Приватность» возможно

Класс FPR вместе с другими классами (содержащими требования аудита, управления доступом, предоставления доверенного маршрута и неотка-зуемости) обеспечивает гибкость при спецификации желательного режима приватности. В то же время требования этого класса могут налагать ограничения на использование компонентов других классов, таких как FIA или FAU. Например, если уполномоченным пользователям нс разрешено знать идентификатор пользователя (например, в семействах «Анонимность» или «Псевдонимность»). то. очевидно, невозможно будет оставить отдельных пользователей ответственными за выполняемые ими относящиеся к безопасности действия. на которые распространяются требования приватности. Тем не менее и в этом случае возможно включение в ПЗ/ЗБ требований аудита, когда само возникновение некоторых событий, связанных с безопасностью, важнее, чем знание того, кто был их инициатором.

Дополнительная информация по этому вопросу представлена в замечаниях но применению класса FAU. где разъясняется, чго вместо идентификатора в контексте аудита может применяться псевдоним или другая информация, которая могла бы идентифицировать пользователя.

Этот класс содержит четыре семейства: «Анонимность». «Псевдонимность*. «Невозможность ассоциации» и «Скрытность». Три первых семейства имеют сложные взаимосвязи. При выборе семейства для применения следует учитывать выявленные угрозы. Для некоторых типов угроз приватности «Псевдонимность» подойдет больше, чем «Анонимность» (например, при требовании проведения аудита). Кроме того, некоторым видам угроз приватности наилучшим образом противостоит сочетание компонентов из нескольких семейств.

Во всех семействах предполагается, что пользовагель нс предпринимает прямо никаких действий, раскрывающих его собственный идентификатор. Например, не ожидается, чтобы ФБО скрывали имя пользователя в сообщениях электронной почты или базы данных.

Все семейства этого класса имеют компоненты, область действия которых может быть задана операциями. Эти операции позволяют автору ПЗ/ЗБ указать те действия, общие для пользователей/субъектов. которым необходимо противодействовать с использованием ФБО. Возможный пример отображения анонимности: «ФБО должны обеспечить, чтобы пользователи и/илн субъекты были не способны определить идентификатор пользователя, обратившегося за телеконсультанией».

Следует, чтобы ФБО предоставляли защиту °^т действий не только отдельных пользователей, но и пользователей. объединившихся для получения определенной информации. Стойкость «пииты, предоставляемой этим классом, следует описать как стойкость функции согласно Б и В к ГОСТ Р ИСО/МЭК 15408-1.

К.1 Анонимность (FPR_ANO)

Семейство FPR ANO обеспечивает, чтобы субъект мог использовать ресурсы или услуги без раскрытия идентификатора его пользователя.

Замечания для пользователя

Данное семейство предназначено для определения, что пользователь или субъект сможет предпринимать действия, не раскрывая идентификатора пользователя другим пользователям, субъектам или объектам. Эго семейство предоставляет автору ПЗ/ЗБ способ идентификации совокупности пользователей, которые нс смогут узнать идентификатор исполнителя некоторых действий.

Следовательно, если субъект, пользуясь анонимностью, выполняет некоторое действие, другой субъект будет не в состоянии определить ни идентификатор, ни даже ссылку на идентификатор пользователя, использовавшего первый субъект. Анонимность сфокусирована на «пиите идентификатора пользователя, а нс на защите идентификатора субъекта. Поэтому идентификатор субъекта не защищается от раскрытия.

Хотя идентификатор пользователя ие разглашается другим субъектам или пользователям. ФБО прямо не запрещено узнавать идентификатор пользователя. Если не допускается, чтобы ФБО был известен идентификатор пользователя, то можно прибегнуть к компоненту Г PR ANO.2. В этом случае ФБО не разрешается запрашивать ин(|юрмапию о польют)геле.

Термин «определить» («determine») следует понимать в самом широком смысле слот). .Тля конкретизации требований к строгости автор ПЗ/ЗБ может воспользоваться понятием стойкости функций.

В этом компоненте проводится различие между пользователями и уполномоченными пользователями. Уполномоченный пользователь часто не упоминается в компонентах; тогда ему не запрещается знать идентификатор пользователя. Однако нет и явного требования, чтобы уполномоченный пользователь обязательно имел возможность определить идентификатор пользователя. Для достижения максимальной приватности в компоненте необходимо указать, что ни пользователь, ни уполномоченный пользователь не смогут узнать идентификатор кого-либо при выполнении какого-либо действия.

В то время как некоторые системы обеспечат анонимность всех предоставляемых услуг, в других системах она предоставляется только для некоторых субъектов/операпий. Для необходимой гибкости включена операция, в которой задается область действия требования. Если автор ПЗ/ЗБ захочет охватить все субъекты/операции. можно воспользоваться выражением «Все субъекты и операции».

Возможные применения анонимности включают в себя заросы конфиденциального характера к общедоступным базам данных, ответы на опросы, проводимые через телекоммуникации, или осуществление анонимных выпла или пожертвований.

Примерами потенциально враждебных пользователей или субъектов являются провайдеры, системные операторы, абоненты связи и пользователи, скрытно вводящие в систему опасные элементы (например, •троянских коней»). Все они могут изучать образ действий пользователей (например, какие пользователи какие услуги заказывают) и злоупотреблять этой информацией.

FPR.ANO.I Анонимность

Замечания по применению для пользователя

Компонент FPR ANO.1 обеспечивает, чтобы идентификатор пользователя был защитен от раскрытия. В некоторых случаях, однако, уполномоченный пользователь может определить, кто произвел определенные действия. Этот компонент дает возможность гибкого подхода, позволяя выбирать политику как ограниченной, гак и полной приватности.

Операции

Назначение

В FPRANO.1.1 автору ПЗ/ЗБ следует специфицировать совокупность пользователей и/илн субъектов, от которых ФБО необходимо предоставить защиту. Например, лаже если автор ПЗ/ЗБ специфицирует единственную роль пользователя или субъекта, ФБО необходимо предоставить защиту нс только от отдельного пользователя или субъекта, но и от совместно действующих пользователей н/илн субъектов. Совокупность пользователей, например, может являться группой пользователей, выступающих в одной и гой же роли или использующих один и тот же процесс.

В FPR_AN().1.1 автору ПЗ/ЗБ следует идентифицировать список субъектов и/илн операций, и/или объектов, для которых подлинное имя пользователя данного субъекта следует защитить, например «голосование».

FPRANO.2 Анонимность без запроса информации

Замечания по применению для пользователя

Компонент FPR ANO.2 используется для обеспечения того, что ФБО не будет разрешено знать идентификатор пользователя.

Операции

Назначение

В IPR ANO.2.1 автору ПЗ/ЗБ следует специфицировать совокупность пользователей и/или субъектов, от которых ФБО необходимо предоставить защиту. Например, даже если автор ПЗ/ЗБ специфицирует единственную роль пользователя или субъекта. ФБО необходимо предоставить защиту не только от отдельного пользователя или субъекта, но и от совместно действующих пользователей и/или субъектов. Совокупность пользователей, например, может являться группой пользователей, выступающих в одной и той же рази или использующих один и тот же процесс.

В FPR ANO.2.1 автору ПЗ/ЗБ следует идентифицировать список субъектов и/мли операций, и/или объектов. для которых подлинное имя пользователя данного субъекта следует защитить, например «голосование».

В FPR ANO.2.2 автору ПЗ/ЗБ следует идентифицировать список услуг, на которые распространяется требование анонимности, например «доступ к описанию работ».

Для FPR ANO.2.2 автору ПЗ/ЗБ следует идентифицировать список субъектов, для которых подлинные имена пользователей следует защитить при предоставлении специфицированных услуг.

К.2 Пссвдонимность (FPR_PSE)

Семейство FPR PSE обеспечивает, чтобы пользователь мог использовать ресурс или услугу без раскрытия своего идентификатора, оставаясь в то же время ответственны за это использование. Пользователь может быть ответственным, будучи прямо связан со ссылкой (псевдонимом), предоставляемой ФБО. или с псевдонимом. используемым для целей обслуживания, таким как номер банковского счета.

Замечания для пользователя

В некотором отношении пссвдонимпость походит на анонимность. В обоих случаях защищается идентификатор пользователя. но в псевдоззимности поддерживается ссылка на идентификатор пользователя как для сохранения его ответственности, так и для других целей.

Компонент FPR PSE.1 не специфицирует требований, относящихся к ссылке на идентификатор пользователя. Эти требования имеются в компонентах FPR PSE.2 и FPR PSE.3.

Одним из путей использования этой ссылки является возможность получения первоначального идентификатора пользователя. Например, если компьютеризованная касса несколько раз выдает абсолютно одинаковые чеки (т. е. происходит мошенничество), было бы предпочтительно иметь возможность отследить идентификатор пользователя. В общем случае необходимость восстановления идентификаторов пользователей определяется конкретными условиями. Для описания такой услуги автору ПЗ/ЗБ можно воспользоваться компонентом FPR PSE.2 «Обратимая пссзсюззимносгь».

Ссылка может также использоваться в качестве псевдонима пользователя. Например, пользователь, не желающий быть идентифицированным, может предоставить номер счета, с которого следует оплачивать использование ресурсов. В таком случае ссылка на идентификатор пользователя — это его псевдоним, который другие пользователи или субъекты могут использовать для выполнения своих функций, без получения при особых обстоятельствах идентификатора пользователя (например, при сборе статистических данных использования системы). В этом случае для определения правил, которым ссылкам необходимо удовлетворять, автор ПЗ/ЗБ может воспользоваться компонентом FPR PSE.3 «Альтернативная псевдонимноеть».

Применяя упомянутые выше конструкции, с помощью FPR PSE.2 можно ввести электронные деньги, установив требование защиты идентификатора пользователя от наблюдения при условии, что одна и та же электронная сумма не тратится дважды. В последнем случае идентификатор пользователя будет отслеживаться. Следовательно, когда пользователь ведет себя честно, его идентификатор защищается, когда же он пытается мошенничать, его идентификатор может быть отслежен.

Другим видом системы электронных платежей являются электронные кредитные карточки, когда пользователь предоставляет псевдоним, который указывает на счет, с которого могут быть сняты деньги. В подобном случае можно использовать, например, компонент FPR PSE.3. определив. что идентификатор пользователя будет защищен зз что этот пользователь только тогда получит требуемую сумму, когда на его счете есть деньги (если так оговорено в условиях).

Следует иметь в виду, что наиболее строгие компоненты этого семейства могут потенциально не сочетаться с другими возможными требованиями, такими как идентификация и аутентификация или аудит. Выражение «определить идентификатор» следует понимать в широком смысле: ФБО не предоставляют информацию при выполнении операции: нельзя определить создателя субъекта или владельца субъекта, вызвавшего операцию: ФБО не будут записывать такую информацию, доступную пользователям или субъектам, по которой в дальнейшем можно бы было узнать идентификатор пользователя.

Смысл заключается в том. чтобы ФБО не раскрывали без необходимости любую информацию, с помощью которой можно определить идентификатор пользо1загеля. например идентификаторы субъектов, действующих от имени пользователя. Степень сохранности этой информации зависит от усилий, которые потребуются нарушителю для ее раскрытия. Следовательно, в компонентах семейства FPR PSE необходимо учитывать требования стойкости функций.

Возможные применения включают в себя оплату телефонных услуг по льготному тарифу без раскрытия идентификатора абонента или оплату анонимного использования системы электронных платежей.

Примерами потенциально враждебных пользователей являются провайдеры, системные операторы, абоненты связи и пользователи, скрытно вводящие в систему опасные элементы (например, «троянских коней»). Все они могут изучать. какие пользователи какие услуги заказывают, зз злоупотреблять этой информацией. В дополнение к семейству «Анонимность* услуги предоставляемые семейством «Псевдонимзюсть». содержат методы авторизации без идентификации, особенно при анонимной оплате «(электронные деньги»). Это помогает провайдерам получать платежи безопасным способом, поддерживая при этом анонимность клиентов.

FPR_PSE. 1 Псевдонимность

Замечания по применению для пользователя

Компонент FPR PSE.I обеспечивает защиту пользователя от раскрытия его идентификатора другими пользователями. При этом пользователь останется ответственным за свои действия.

Операнизз

Н а з паче зз зз с

В FPR_PSE.I.l автору ПЗ/ЗБ следует спспифицнроватз» совокупность пользователей и/или субъектов, от которых ФБО необходимо предоставить защиту. Например, лаже если автор ПЗ/ЗБ специфицирует единственную роль пользователя или субъекта. ФБО необходимо предоставить защиту нс только от отдельного пользователя или субъекта, ко и от совместно действующих пользователей и/или субъектов. Совокупность пользователей, например, может являться группой пользователей, выступающих в одной и той же роли или использующих один и тот же процесс.

В FPR_PSE.1.1 автору ПЗ/ЗБ следует идентифицировать список субъектов и/или операций, н/или объектов, для которых подлинное имя пользователя данного субъекта следует защитить, например «доступ к предложениям трудоустройства». Отметим, что к «объектам» относят любые атрибуты, позволяющие другим пользователям или субъектам раскрыть действительный идентификатор данного пользователя.

В FPR_PSE.1.2 автору ПЗ/ЗБ следует идентифицировать число псевдонимов (один или более), которое ФБО способны предоставить.

FPRPSF.1.2 автору ПЗ/ЗБ следует нлентнфниировать список субъектов, которым ФБО способны предоставлять псевдонимы.

Выбор

В FPR PSE.I.3 автору ПЗ/ЗБ следует специфицировать, создаются псевдонимы функциями безопасности ОО или выбираются самими пользователями.

Назначение

В FPR_PSE.1.3 автору ПЗ/ЗБ следует идентифицировать метрику, которой удовлетворял бы псевдоним, созданный ФБО или выбранный пользователем.

FPR.PSE.2 Обратимая пссвдонимность

Замечания по применению для пользователя

В компоненте FPR PSE.2 ФБО должны обеспечить, чтобы при специфицированных условиях по предоставленной ссылке мог быть определен идентификатор пользователя.

В этом компоненте ФБО должны вместо идентификатора пользователя предоставитьего псевдоним. При удовлетворении специфицированных условий идентификатор пользователя, которому принадлежит псевдоним, может быть определен. Для электронных денег примером таких условий может служить: «ФБО должны предоставить нотариусу возможность определить идентификатор пользователя по представленному псевдониму только в том случае, если чек был выдан дважды».

Операции

Н а з н а ч е и и е

В FPR PSE.2.1 автору ПЗ/ЗБ следует специфицировать совокупность пользователей и/или субъектов, от которых ФБО необходимо предоставить защиту. Например, даже если автор ПЗ/ЗБ специфицирует единственную роль пользователя или субъекта. ФБО необходимо предоставить -защиту не только от отдельного пользователя или субъекта, но и от совместно действующих пользователей и/или субъектов. Совокупность пользователей. например, можег являться группой пользователей, выступающих в одной и гой же роли или использующих один и гот же процесс.

В FPR PSE.2.1 автору ПЗ/ЗБ следует идентифицировать список субъектов и/или операций, н/или объектов. для которых подлинное имя пользователя данного субъекта следует защитить, например -доступ к предложениям трудоустройства». Отмстим, что к «объектам» относят любые атрибуты, позволяющие другим пользователям или субъектам раскрыть действительный идентификатор данного пользователя.

В FPR PSE.2.2 автору ПЗ/ЗБ следует идентифицировать число псевдонимов (один или более), которое ФБО способны предоставить.

В FPR PSE.2.2 автору ПЗ/ЗБ следует идентифицировать список субъектов, которым ФБО способны предоставлять псевдонимы.

Выбор

В FPR PSE.2.3 автору ПЗ/ЗБ следует специфицировать, создаются псевдонимы функциями безопасности ОО или выбираются самими пользователями.

Назначение

В FPR PSE.2.3 автору ПЗ/ЗБ следует идентифицировать метрику, которой! удовлетворял бы псевдоним, созданный ФБО или выбранный пользователем.

Выбор

В FPRPSE.2.4 автору ПЗ/ЗБ следует идентифицировать, могут ли уполномоченный пользователь н/илн доверенные субъекты определить подлинное имя пользователя.

Н а з н а ч е и и е

В FPR_PSE.2.4 автору ПЗ/ЗБ следует идентифицировать список доверенных субъектов (например, «нотариус» или «пользователь, имеющий специальное разрешение»), которые могут при определенных условиях узнать подлинное имя пользователя.

В FPR_PSE.2.4 автору ПЗ/ЗБ следует идентифицировать список условий, при которых доверенные субъекты и уполномоченный пользователь могут определить подлинное имя пользователя на основе предоставленной ссылки. Такими условиями может быть «время суток» или же правовое условие, например предъявление судебного постановления.

FPR_PSE.3 Альтернативная исевдонимносгь

Замечания по применению для пользователя

В компоненте FPR PSE.3 ФБО должны обеспечивать, чтобы предоставленная ссылка отвечала определенным правилам се создания и вследствие этого могла использоваться потенциально опасными субъектами без нарушения безопасности.

Если пользователь хочет использовать ресурсы, не раскрывая свой идентификатор, то может применяться псевдонимность. Обычно на всем протяжении доступа к системе пользователь обязан использовать один и тот же псевдоним. Такое условие можно специфицировать в этом компоненте.

Операции

Н а з паче н и с

В FPR PSE.3.1 автору ПЗ/ЗБ следует специфицировать совокупность пользователей и/или субъектов, от которых ФБО необходимо предоставить защиту. Например, даже если автор ПЗ/ЗБ специфицирует единственную роль пользователя или субъекта. ФБО необходимо предоставить защиту не только от отдельного пользователя или субъекта, но и от совместно действующих пользователей и/или субъектов. Совокупность пользователей. например, может являться группой пользователей, выступающих в одной и той же роли или использующих один и тот же процесс.

В FPR PSE.3.1 автору ПЗ/ЗБ следует идентифицировать список субъектов и/или операций, и/или объектов. для которых подлинное имя пользователя данного субъекта следует защитить, например «доступ к предложениям трудоустройства». Отметим, что к «объектам» относят любые атрибуты, позволяющие другим пользователям или субъектам раскрыть действительный идентификатор данного пользователя.

В FPR PRS.3.2 автору ПЗ/ЗБ следует идентифицировать число псевдонимов (один или более), которое ФБО способны предоставить.

В FPR PSE.3.2 автору ПЗ/ЗБ следует идентифицировать список субъектов, которым ФБО способны предоставлять псевдонимы.

Выбор

В FPR PSE.3.3 автору ПЗ/ЗБ следует специфицировать, создаются псевдонимы функциями безопасности 00 или выбираются самими пользователями.

Н а з н а ч е и и е

В FPR PSE.3.3 автору ПЗ/ЗБ следует идентифицировать метрику, которой удовлетворял бы псевдоним, созданный ФБО или выбранный пользователем.

В FPR_PSE.3.4 автору ПЗ/ЗБ следует идентифицировать синеок условий, указывающих, в каких случаях ссылки на подлинное имя пользователя должны быть одинаковы, а в каких должны быть различными, например «когда пользователь осуществляет многократный вход в узел сети, он будет использовать один и то же псевдоним».

К.З Невозможность ассоциации (FPRIJNL)

Семейство FPR UNL обеспечивает, чтобы пользователь мог неоднократно использовать ресурсы или услуги, не давая никому во зможности свя гать вместе их использование. Невозможность ассоциации отличается от псевдоннмности тем. что хотя при псевдонимности сам пользователь также неизвестен, связи между его различными действиями не скрываются.

Замечания для пользователя

Требования невозможности ассоциации предназначены для зашиты идентификатора пользователя от применения профиля операций. Например, телефонная компания может определить поведение пользователя гелс()юнной карты, используемой с единственного номера. Если известны профили использования телефона группой пользователей, то карту можно свя зать с конкретным пользователем. Сокрытие связи между различными обращениями за услугой или за доступом к ресурсу предотвратит накопление подобной информации.

В результате требования невозможности ассоциации могут означать защиту идентификатора субъекта и пользователя для некоторой операции. В противном случае эта информация может быть использована для связывания операций вместе.

Семейство содержит требование исключить установление связи между различными операциями. Эта связь может приобретать различные формы. Например, с пользователем ассоциируется операция или терминал. с которого инициировано действие, или продолжительность выполнения действия. Автор ПЗ/ЗБ может специфицировать. раскрытию какого типа связей необходимо противодействовать.

Возможные приложения включают в себя возможность многократного использования псевдонима, исключающие создание шаблона использования, по которому можно раскрыть идентификатор пользователя.

Примерами потенциально враждебных субъектов или пользователей являются провайдеры, системные операторы, абоненты связи и пользователи, скрытно вводящие в систему опасные элементы (например, «троянских коней»). Сами они не выполняют операции в системе, но стремятся получить информацию об операциях. Все они могут изучать образ действий пользователей (например, какие пользователи какие услуги заказывают) и злоупотреблять этой ип(]юрмацией. Невозможность ассоциации защищает пользователей от сопоставления. которое может быть произведено между различными действиями потребителя. Например, серия гслс(|юппых вызовов, сделанных анонимным потребителем по различным номерам, может дагь ин<|юрмацию для раскрытия его идентификатора по сочетанию номеров.

FPR_UNL.l Невозможность ассоциации

Замечания по применению для пользователя

Компонент FPR UNL.1 обеспечивает, чтобы пользователи не могли связывать между собой различные операции в системе и таким образом получать информацию.

Операции

Назначение

В FPR_UNL. 1.1 автору 113/36 следует специфицировать совокупность пользователей н/нли субъектов, от которых ФБО необходимо предоставить защиту. Например, даже если автор 113/36 специфицирует единственную роль польтователя или субъекта, ФБО необходимо предоставить защиту не только от отдельного пользователя или субъекта, но и от совместно действующих пользователей н/или субъектов. Совокупность пользователей, например, может являться группой пользователей, выступающих в одной и той же роли или использующих один и тот же процесс.

В FPR_UNL.1.1 автору Г13/36 следует идентифицировать список операций, на которые следует распространить требование невозможности ассоциации, например «отправка электронной почты».

Выбор

В FPR_UN1,.1.I автору ПЗ/ЗБ следует выбрать взаимосвя зи, которые следует скрыть. Этот выбор позволяет специфицировать либо идентификатор пользователя, либо операцию назначения списка соотношений.

Н а з н а ч с н и с

В FPR_UNI..1.1 автору ПЗ/ЗБ следует идентифицировать список соотношений, которые следует защищать, например «посланные с одного и того же терминала*.

К.4 Скрытность (FPR_UNO)

Семейство FPR L.NO обеспечивает, чтобы пользователь мог использовать ресурс или услугу без предоставления кому-либо, в особенности третьей стороне, возможности знать об использовании ресурса или услуги.

Замечания для ноль зова геля

Подход к защите идентификатора пользователя в этом семействе отличает его от остальных семейств данного класса. Скрывается факт использования ресурса или услуги, а не идентификатор пользователя.

Для реализации скрытности могут быть применены различные методы. Примеры некоторых из них приведены ниже.

а) Размещение информации, повышающее скрытность. Информацию, которую необходимо скрыть (например. указывающую на выполнение операции), можно разместить в 00 различными способами. Место ее размещения в ОО можно выбирать случайно, так. чтобы нарушитель не знал, какую именно часть 00 следует атаковать. Данную информацию можно распределить таким образом, чтобы ни в одной части 00 ее не было достаточно для нарушения приватности пользователя. Этот способ рассматривается в компоненте FPR IJNO.2.

б) Массовое распространение информации (по локальной сети, по радио). Пользователи не могут определить. кому конкретно послана данная информация и кто в действительности сганег се использовать. Этот метод особенно полезен, когда информацию следует довести до того, кто опасается показывать свою заинтересованность в данной информации (например, чувствительной медицинской информации).

в) Криптографическая зашита и дополнение сообщений незначащей информацией. Путем наблюдения за потоком сообщений можно извлечь информацию из самого факта передачи сообщения сообщения и его атрибутов. Защиту передаваемых сообщений и их атрибутов можно обеспечить посредством дополнения графика и самих сообщений незначащей информацией или шифрования.

Иногда пользователей нс следует допускать к наблюдению за использованием ресурсов, а уполномоченным пользователям такое наблюдение необходимо для исполнения своих обязанностей. В таком случае может применяться компонент FPR UN0.4. который предоставляет эту возможность одному или нескольким упол-но моч е н н ы м пол ь зо вател я м.

В этом семействе используется понятие «часть 00». Под йен подразумевается какая-либо часть 00. отделенная физически или логически от других частей 00. В случае логического отделения может быть уместно применение семейства FPT SEP.

Скрытность связей может быть важным фактором во многих областях, таких как осуществление конституционных прав, политика организации или приложения. связанные с оборонными вопросами.

FPR_UN0.1 Скрытность

Замечания по применению для пользователя

Компонент FPR UNO. 1 содержит требования недопустимости наблюдения неуполномоченными пользователями за использованием услуги или ресурса. Дополнительно к этому компоненту автору ПЗ/ЗБ может потребоваться «Анализ скрытых каналов».

Операции

Назначение

В FPR_UN0.1.1 автору 113/3Б следует специфицировать совокупность пользователей и/или субъектов, от которых ФБО необходимо предоставить защиту. Например, даже если автор ПЗ/ЗБ специфицирует единственную роль пользователя или субъекта, ФБО необходимо предоставить защиту не только от отдельного пользователя или субъекта, но и от совместно действующих пользователей и/или субъектов. Совокупность пользователей, например, может являться группой пользователей, выступающих в одной и той же роли или использующих один и тот же процесс.

Для FPR_UNO.1.1 автору ПЗ/ЗБ следует идентифицировать список операций, на которые распространяется требование скрытности. Тогда другие пользователи/субъекты не смозут наблюдать за указанными в списке операциями над специфицированными ниже объектами (например, за чтением и записью на объекте).

Для FPR_UNO.1.1 автору ПЗ/ЗБ следует идентифицировать список объектов, на которые распространяется требование скрытности. Примером может быть конкретный сервер электронной почты или FTP-сайт.

Для FPR_(JNO. 1.1 автору ПЗ/ЗБ следует идентифицировать совокупность пользователей и/или субъектов, скрытность информации которых будет обеспечиваться.

Примером может быть: «пользователи, получившие доступ к системе через Интернет».

FPR_UNO.2 Распределение информации, влияющее на скрытность

Замечания по применению для пользователя

Компонент FPR.UNO.2 содержит требования недопустимости наблюдения определенными пользователями за использованием услуги или ресурса. Кроме этого, в нем определяется, какая информация, связанная с приватностью пользователя, распределяется в 00 таким образом, чтобы нарушитель не мог установить. в какой именно части 00 она содержится, или был вынужден атаковать несколько частей 00.

Примером использования этого компонента является случайный выбор узла для предоставления услуги. В этом случае в компоненте может быть установлено требование, что информация, связанная с приватностью пользователя, должна быть доступна только в одной идентифицированной части ОО. не распространяясь за ее пределы.

Более сложный пример связан с некоторыми «алгоритмами голосования». В предоставлении услуги принимают участие несколько частей 00. но никакая отдельная часть не сможет нарушить принятую политику. Какое-либо лицо может принять (или не принять) участие в голосовании: при этом невозможно определить результат голосования и его участие в голосовании (если голосование было анонимным).

Дополнительно к этому компоненту автору ПЗ/ЗБ может потребоваться «Анализ скрытых каналов*. Операции

Н а з н а ч е н и е

В FPR UNO.2.1 автору ПЗ/ЗБ следует специфицировать совокупность пользователей и/или субъектов, от которых ФБО необходимо предоставить защиту. Например, даже если автор ПЗ/ЗБ специфицирует единственную роль пользователя или субъекта. ФБО необходимо предоставить защиту не только от отдельного пользователя или субъекта, но и от совместно действующих пользователей и/или субъектов. Совокупность пользователей. например, может являться группой пользователей, выступающих в одной и той же роли или использующих один н тог же процесс.

Для FPR UNO.2.1 автору ПЗ/ЗБ следует идентифицировать список операций, на которые распространяется требование скрытности. Тогда другие по.тьзовагсли/субьскты нс смогут наблюдать за ука заннымн в списке операциями ii;li специфицированными ниже объектами (например, за чтением и записью на объекте).

Для FPR UNO.2.1 автору ПЗ/ЗБ следует идентифицировать список объектов, на которые распространяется требование скрытности. Примером может быть конкретный сервер электронной почты или ГТР-сайт.

3 FPR UNO.2.1 автору ПЗ/ЗБ следует специфицировать совокупность пользователей н/или субъектов, скрытность информации которых будет обеспечиваться, например «пользователи, получившие доступ к системе через Интернет».

В FPR_UNO.2.2 автору ПЗ/ЗБ следует идентифицировать, распределение какой информации, связанной с приватностью, следует контролировать. Примером такой информации являются IP-адрес субъекта, IP-адрес объекта, время, используемые криптографические ключи.

Для FPR_UNO.2.2 автору ПЗ/ЗБ следует специфицировать, каким условиям следует соответствовать распределению указанной информации. Эти условия следует поддерживать все время существования приватной информации пользователя в каждом случае. Примерами таких условий могут быть: «информация должна быть представлена только в одной из разделенных частей ОО и нс должна передаваться за се пределы»; «информация должна пребывать только в одной из разделенных частей ОО. не должна передаваться в другие его части периодически»; «информация должна распределяться между различными частями ОО таким образом, чтобы нарушение защиты любых пяти отдельных частей ОО нс приводило к нарушению политики безопасности в целом».

FPR_UNO.3 Скрытность без запроса информации

Замечания по применению для польюватсля

Компонент FPR UNO.3 применяется для требования, чтобы ФБО не стремились получить информацию. которая может нарушить скрытность при предоставлении определенных услуг. Поэтому ФБО не будут запрашивать (т. е. стремиться получить из других источников) информацию, которая может быть использована для нарушения скрытности.

Операции

Назначение

В FPR_UNO.3.I автору ПЗ/ЗБ следует идентифицировать список услуг, на которые распространяется требование скрытности, например «доступ к описанию работ».

В FPR_UN0.3.1 автору ПЗ/ЗБ следует идентифицировать список субъектов, от которых при получении специфицированных услуг следует защищать информацию, связанную с приватностью.

В FPR_UNO.3.1 автору ПЗ/ЗБ следует специфицировать информацию, связанную с приватностью, которая будет защищена от специфицированных субъектов. Это может быть идентификатор субъекта, получающего услугу, или характеристики полученной услуги, например использованный ресурс памяти.

EPR_UN0.4 Открытость для уполномоченного пользователя

Замечания по применению .для пользователя

Компонент Г PR UNO.4 применяется для предоставления права наблюдения за использованием ресурсов одному или нескольким уполномоченным пользователям. Без этого компонента возможность наблюдения допускается, но не является обязательной.

Операции

Назначение

В FPR_UNO.4.1 автору ПЗ/ЗБ следует специфицировать совокупность уполномоченных пользователей, которым ФБО необходимо предоставить возможность наблюдения за использованием ресурсов. Это может быть, например, группа уполномоченных пользователей, исполняющих одну и ту же роль или использующих один и гот же процесс.

В FPR_UNO.4.1 автору ПЗ/ЗБ следует специфицировать список ресурсов и/или услуг, возможность наблюдения за которыми необходима уполномоченному пользователю.

ПРИЛОЖЕНИЕ Л

(справочное)

Защита ФБО (FPT)

Класс FPT содержит семейства функциональных требований. которые связаны с целостностью и управлением механизмами, реализованными в ФБО. не завися при этом от особенностей ПВО. а также с целостностью данных ФБО. не завися от специфического содержания данных ПВО. В некотором смысле, компоненты семейств этого класса дублируют компоненты из класса I DP и могут даже использовать одни и те же механизмы. Однако класс ГОР специализирован на защите данных пользователя, в то время как класс FPT нацелен на защиту данных ФБО. Фактически, компоненты из класса FPT необходимы для реатизании требований невозможности нарушения и обхода политик ФВ данного 00.

В рамках этого класса выделяются три существенные составные части ФБО.

а) Абстрактная машина ФБО, т. е. виртуальная или физическая машина, на которой выполняется оцениваемая реатизаиия ФБО.

б) Реализация ФБО, которая выполняется на абстрактной машине и реализует механизмы, осуществляющие ИБО.

в) Данные ФБО, которые являются административными базами данных, управляющими осуществлением ИБО.

Все семейства в классе ГРТ можно связать с этими тремя частями и сгруппировать следующим образом.

г) FPT PIIP «Физическая зашита ФБО» предоставляет уполномоченному пользователю возможность обнаружения внешних атак на те части 00. которые реализуют ФБО.

д) FPT АМТ «■Тестирование базовой абстрактной машины* и FPT TST «Самотестирование ФБО» предоставляют уполномоченному пользователю возможность верифицировать правильность операций базовой абстрактной машины и ФБО. а также целостность данных и выполняемого кола ФБО.

е) FPI SEP «Разделение домена» и FPT RVM «Посредничество при обращениях» защищают ФБО во время их выполнения и обеспечивают невозможность обхода ФБО. Когда соответствующие компоненты этих семейств сочетаются с соответствующими компонентами семейства ADV I NT «Внутренняя структура ФБО». можно говорить о наличи в 00 традиционного «монитора обращений».

ж) FPT RCV «Надежное восстановление*. FPT FLS «Безопасность при сбое» и FPT IRC «Согласованность данных ФБО при дублировании в пределах 00- определяют режим выполнения ФБО при возникновении сбоя и непосредственно после него.

и) FPT ITA «Доступность экспортируемых данных ФБО». FPT 1ТС «Конфиденциальность экспортируемых данных ФБО» и FPT IT1 «Целостность экспортируемых данных ФБО» определяют защиту и доступность данных ФБО при их обмене между ФБО и удаленным доверенным продуктом ИТ.

к) FPT ITT «Передача данных ФБО в пределах 00» предназначено для защиты данных ФБО при их передаче между физически разделенными частями 00.

л) FPT RPL «Обнаружение повторного использования» содержит требование защиты от повторного использования различных типов информации и/или операций.

м) FPT SSP «Протокол синхронизации состояний* определяет синхронизацию состояний между различными частями распределенных ФБО на основе данных ФБО.

н) FPT STM «Метки времени» предоставляет надежные метки времени.

п) FPT TDC «Согласованность данных ФБО между ФБО» предназначено для согласования данных между ФБО и удаленным доверенным продуктом ИТ.

Декомпозиция класса FPT на составляющие ею компоненты приведена на рисунках Л. 1. Л.2.

Рисунок Л.1 — Декомпозиция класса «Зашита ФБО»

Л.1 Тестирование базовой абстрактной машины (FPT_AMT)

Семейство FPT /\МТ определяет требования к выполнению тестирования ФБО, демонстрирующего предположения безопасности относительно базовой абстрактной машины, лежащей в основе построения ФБО. «Абстрактная» машина может быть как платформой аппаратных/программно-аппаратных средств. гак и некоторым известным и прошедшим оценку сочетанием аппаратных/программны.х средств, действующим как виртуальная машина. В качестве примеров такого тестирования можно указать проверку аппаратной зашиты. посылку типовых пакетов по сети для проверки получения, верификацию режима функционирования виртуального машинного интерфейса и т. д. Эти тесты могхт выполняться при некотором поддерживаемом состоянии, при запуске, по запросу или постоянно. Действия, предпринимаемые с использованием 00 по результатам тестирования, определены в FPT RCV.

Рисунок Л.2 — Декомпозиция класса «Зашита ФБО» (продолжение)

Замечания для пользователя

Термин «базовая абстрактная машина» относится главным образом к аппаратуре, реализующей ФБО. Однако его можно отнести и к предварительно оцененной базовой комбинации аппаратных средств и программного обеспечения, ведущей себя как виртуальная машина, на которой реализованы ФБО.

Тесты абстрактной машины могут иметь различные формы:

а) тесты при включении, которые проверяют правильность работы платформы. Для аппаратных и программно-аппаратных средств они могут включать в себя тесты таких элементов, как платы памяти, маршруты передачи данных, шины, управляющие элементы, регистры процессора, порты сообщений, интерфейсы консолей, звуковоспроизводящие и периферийные устройства. Для программных элементов (виртуальной машины) они включат в себя верификацию корректности инициализации и режима функционирования:

б) загружаемые тесты, которые могут загружаться и выполняться уполномоченным пользователем или активизироваться при определенных условиях. Они могут включать в себя тесты нагрузки элементов процессора (логических элементов, вычислительных элементов и г. д.) и управляемой памяти.

Замечания для оненшика

Следует, чтобы тесты базовой абстрактной машины были достаточны для проверки всех характеристик базовой абстрактной машины, на которой выполняются ФБО.

FPT_AMT.I Тестирование абстрактной машины

Замечания по применению для пользователя

Компонент FPT /\МТ. 1 поддерживает периодическое тестирование предположений безопасности базовой абстрактной машины, ог которых зависит выполнение ФБО, требуя обеспечения возможности периодического запуска тестирования функций.

При желании автор ПЗ/ЗЬ может уточнить требование, указав, в каком режиме следует проводить тестирование: автономно, при обычном функционировании системы или в режиме аварийной поддержки.

Замечания по применению для оценшика

Допускается, чтобы функции периодического тестирования были доступны только в автономном режиме или режиме аварийной поддержки. Следует иметь средства управления для предоставления доступа в режиме аварийной поддержки только уполномоченным пользователям.

Операции

Выбор

В FPT.AMT, 1.1 автору II3/3Б следует специфицировать, когда ФБО будут выполнить тестирование абстрактной машины: при запуске, периодически во время нормального функционирования, по запросу уполномоченного пользователя, при других условиях. В последнем случае следует уточнить, какие это условия. С помощью этой операции выбора автор ПЗ/ЗБ имеет возможность указать также периодичность выполнения самотестирования. Более частое тестирование ласт пользователю большую уверенность в правильном функционировании ОО. Однако необходимо выбрать правильное соотношение между предоставлением уверенности и потенциальным уменьшением доступности ОО, поскольку слишком частое тестирование может замедлить нормальное функционирование ОО.

Л.2 Безопасность при сбое (FPT_FLS)

Требования семейства FPT I-LS обеспечивает, чтобы ОО не нарушал свою политику безопасности при сбоях ФБО идентифицированных типов.

FPT_FLS.I Сбой с сохранением безопасного состояния

Замечания по применению для пользователя

Термин «безопасное состояние» относится к состоянию, при котором данные ФБО непротиворечивы и ФБО продолжают корректное осуществление ПВО. «Безопасное состояние* определяется в модели ПВО. Бели разработчик предоставил четкое определение безопасного состояния и разъяснение, когда его следует считать гаковым. зависимость FPT FLS.1 от ADV SPM.1 можно не учитывать.

Хотя при сбоях с сохранением безопасного состояния желательно проведение аудита, это возможно не во всех ситуациях. Автору ПЗ/ЗБ следует специфицировать те ситуации, при которых проведение аудита желательно и выполнимо.

Сбои ФБО могут включать в себя аппаратные отказы, которые указывают на нарушение режима работы оборудования и требуют аварийной поддержки или восстановления ФБО. Сбои ФБО могут включать в себя также устранимые программные отказы, после которых требуется только иниииализаиия или повторный запуск ФБО.

Операции

Н а з и а ч е и и е

Для FPT_FLS. 1.1 автору ПЗ/ЗБ следует привести список типов сбоев ФБО. при которых следует, чтобы ФБО «сбились безопасно», т. е. сохранили безопасное состояние и продолжали корректно осуществлять ИБО.

Л.З Доступность экспортируемых данных ФБО (FPTJTA)

Семейство FPT 1ТА определяет правила предотвращения потери доступ пости данных ФБО. передаваемых между ФБО и удаленным доверенным продуктом ИТ. Это могут быть, например, критичные данные ФБО типа паролей, ключей, данных аудита или выполняемого кола ФБО.

Замечания по применению для пользователя

Это семейство используется в распределенных системах, когда ФБО представляют свои данные удаленному доверенному продукту¹ ИТ. ФБО могут предпринимать меры безопасности лишь со своей стороны и не могут вести ответственность за ФБО другого доверенного продукта И Г.

Если имеется несколько различных метрик доступности для разных типов данных ФБО. эго г компонент следует повторить для каждой отдельной пары «метрика — тип данных ФБО*.

FPT_ITA.l Доступность экспортируемых данных ФБО в пределах заданной метрики

Операции

И а з н а ч е и и е

Для FPT_ITA.1.1 автору ПЗ/ЗБ следует специфицировать типы данных ФБО, на которые распространяется метрика доступности.

Для FPT_ITA.1.1 автору 113/ЗБ следует специфицировать метрику доступности для соответствующих данных ФБО.

Для FPT_ITA.1.1 автору ПЗ/ЗБ следует специфицировать условия, при которых необходимо обеспечить доступность. Это, например, может быть наличие связи между ОО и удаленным доверенным продуктом ИТ.

Л.4 Конфиденциальность экспортируемых данных ФБО (FPT_ITC)

Семейство FPT ITC определяет правила зашиты данных ФБО от несанкционированного раскрытия при передаче между ФБО и удаленным доверенным продуктом ИТ. Это могут быть, например, критичные данные ФБО типа паролей, ключей, данных аудита или выполняемого кода ФБО.

Замечания по применению для пользователя

‘Эго семейство используется в распределенных системах, когда ФБО представляют свои данные удаленному доверенному продукту ИТ. ФБО могут предпринять меры безопасности лишь в своей области действия и нс могут нести ответственность за ФБО другого доверенного продукта ИТ.

FPT_ITC.l Конфиденциальность экспортируемых данных ФБО при передаче

Замечания по применению для оценщика

Конфиденциальность данных ФБО во время передачи необходима для их зашиты от раскрытия. Возможные способы обеспечения конфиденциальности включают в себя применение криптографии, а также других методов, выбор которых постоянно расширяется.

Л.5 Целостность экспортируемых данных ФБО (FPT_ITI)

Семейство FPT 1Т1 определяет правила танины данных ФБО от несанкционированной модификации при передаче между ФБО и удаленным доверенным продуктом ИТ. Эго могут быть, например, критичные данные ФБО типа паролей, ключей, данных аудита или выполняемого кода ФБО.

Замечания для пользователя

Это семейство используется в распределенных системах, когда ФБО представляют свои данные удаленному доверенному продукту’ ИТ. Отметим, что требования, связанные с модификацией, обнаружением или восстановлением и относящиеся к удаленному доверенному продукту ИТ. невозможно специфицировать, поскольку заранее не известны механизмы, которые будут использованы в удаленном доверенном продукте ИТ. Поэтому эти требования выражены в терминах •предоставления ФБО возможности», которую может использовать удаленный доверенный продукт ИТ.

FPT_1TI.1 Обнаружение модификации экспортируемых данных ФБО

Замечания по применению для пользователя

Компонент I ИТ 111.1 следует использовать в ситуациях, когда достаточно обнаружить, что данные модифицированы. Примером является ситуация, когда у удаленного доверенного продукта ИТ имеется возможность запросить ФБО о повторении передачи данных при обнаружении их модификации или удовлетворить аналогичный запрос.

Желательная стойкость функции обнаружения модификации основана на определенной метрике модификации. которая зависит от используемого алгоритма и может находиться в диапазоне от простых контрольных сумм и проверки на четность, которые не обнаруживают простые комбинации изменений в нескольких разрядах, до более сложных криптографических контрольных сумм.

Операции

Н а з н а ч с н и е

Для FPT_1T1.F1 автору ПЗ/ЗБ следует специфицировать метрику модификации, удовлетворение которой необходимо для механизма обнаружения. Эта метрика должна определить желательную стойкость функции обнаружения модификации.

Для FPT_ITI.1.2 автору ПЗ/ЗБ следует специфицировать действия, предпринимаемые при обнаружении модификации данных ФБО. Примером таких действий может служить: «игнорировать полученные данные ФБО и запросить у доверенного продукта, являющегося отправителем, повторную передачу данных ФБО*.

FPT_ITI.2 Обнаружение и исправление модификации экспортируемых данных ФБО

Замечания по применению для пользователя

Компонент FPT П‘1.2 следует использовать в ситуациях, когда требуется обнаружить или исправить модификации критичных данных ФБО.

Желательная стойкость функции обнаружения модификации основана на определенной метрике модификаций. которая зависит от используемого алгоритма и может находиться в диапазоне от контрольных сумм и проверки на четность, которые могут не обнаружить простые комбинации изменений в нескольких разрядах. до более сложных криптографических контрольных сумм. Метрику, которую требуется определить, можно связать либо с отражением атак (например, будет пропускаться только одно из тысячи случайных сообщений). либо с приведенным в открытой литературе механизмом (например, необходимо, чтобы требуемая стойкость соответствовала стойкости алгоритма безопасного хэширования).

Подход к исправлению модификаций может быть основан на использовании некоторых видов контрольных сумм, позволяющих корректировать ошибки.

Замечания по применению для оценщика

Возможные способы удовлетворения этих требований состоят в использовании криптографических функций или некоторых видов контрольных сумм.

Операции

Назначение

Для FPT ITI.2.1 автору ПЗ/ЗБ следует специфицировать метрику модификации, удовлетворение которой необходимо для механизма обнаружения. ‘Эта метрика должна определить желательную стойкость функции обнаружения модификации.

Для IPT ITI. 1.2 автору ПЗ/ЗБ следует специфицировать действия, предпринимаемые при обнаружении модификации данных ФБО. Примером таких действий может служить: «игнорировать полученные данные ФБО и запросить у доверенного продукта, являющегося отправителем, повторную передачу данных ФБО*.

Для FPT_1TI.2.3 автору ПЗ/ЗБ следует определить типы модификаций, после которых ФБО следует предоставить возможность восстановления.

Л.6 Передача данных ФБО в пределах ОО (FPT_1TT)

Семейство FPT ITT предоставляет требования защиты данных ФБО при их передаче между разделенными частями ОО по внутреннему каналу.

Замечания для пользователя

Принятие решения о степени физического или логического разделения, в условиях которого могло бы применяться это семейство, зависит от предполагаемой среды эксплуатации. В неблагоприятной среде могут возникать риски, связанные с передачей между частями ОО. разделенными всего лишь системной шиной. В более благоприятной среде для передачи можно использовать обычные сетевые средства.

Замечания для пользователя

Один из механизмов, практически применяемых для реализации функциями безопасности 00 этого вида зашиты, основан на применении криптографических методов.

FPT_ITT.l Базовая зашита внутренней передачи данных ФБО

Операции

Выбор

В FPT ITT.I.1 автору ПЗ/ЗБ следует спеиифицировать требуемый тип зашиты. предоставляя ее от раскрытия или модификации.

FPT_ITT.2 Разделение данных ФБО при передаче

Замечания по применению для польювагсля

Одним из путей выполнения разделения каналов, основанного на атрибутах, относящихся к ПФБ. является использование разделенных логических или физических каналов.

Операции

Выбор

В FPT ITT.2.I автору ПЗ/ЗБ следует специфицировать требуемый тип защиты, предоставляя ее от раскрытия или модификации.

FPTJTT.3 Мониторинг целостности данных ФБО

Операции

Выбор

В FPT_ITT.3.1 автору ПЗ/ЗБ следует спеиифицировать. какой тип модификации должны быть способны обнаруживать ФБО. выбирая из следующих типов: модификации данных, подмена данных, перестановка данных, удаление данных или какие-либо иные ошибки целостности.

Н а з и а ч с н и с

В FPT_ITT.3.1 в случае выбора автором ПЗ/ЗБ последнего варианта из предыдущего абзаца, ему следует также специфицировать, какие иные ошибки целостности ФБО следует обнаруживать.

В FPT_ITT.3.2 автору ПЗ/ЗБ следует специфицировать действия, предпринимаемые при обнаружении ошибки целостности.

Л.7 Физическая зашита ФБО (FPT_PHP)

Компоненты семейства FPT PH Р дают возможность ограничивать фи зичсский доступ к ФБО, а также реагировать на несанкционированную физическую модификацию или подмену рсали зании ФБО и противодействовать им.

Требования компонентов в этом семействе обеспечивают, чтобы ФБО были защищены от физического воздействия и вмешательства. Удовлетворение требований этих компонентов позволяет получить реализацию ФБО. компонуемую и используемую способом, предусматривающим обнаружение физического воздействия или противодействие ему. Без этих компонентов -защита ФБО теряет свою эффективность в среде, где нс может быть предотвращено физическое повреждение. Эго семейство также содержит требования к реакции ФБО на попытки физического воздействия на их реализацию.

Примерами сценариев физического воздействия являются нападения с использованием механических средств, радиоактивного излучения. изменения температуры.

Замечания для пользователя

Допускается, чтобы функции обнаружения физических нападений были доступны уполномоченному пользователю только в автономном режиме или режиме аварийной поддержки. Следует предусмотреть средства ограничения доступа в этих режимах, предоставляя его только уполномоченным пользователям. Поскольку в этих режимах ФБО могут оказаться «невыполнимыми»* это может помешать нормальному осуществлению доступа уполномоченных пользователей. Физически ОО может состоять из устройств различного типа, например из экранирующего корпуса, плат и микросхем. Необходимо, чтобы эта совокупность «элементов» -защищала ФБО от физического вмешательства (а также оповещала о нем и противодействовала ему). Это не означает. что эти качества необходимы всем устройствам но отдельности, но следует, чтобы их имело физическое воплощение 00 в целом.

Хотя с этими компонентами ассоциирован только минимальный аудит, это сделано исключительно потому, что потенциально механизмы обнаружения и оповещения могут быть реализованы полностью аппаратно. на уровне взаимодействий более низком, чем управление подсистемой аудита (например, это может быть система обнаружения на аппаратном уровне, реагирующая на разрыв цепи зз подающая световой сигнал. если цепь разорвана в момент нажатия кнопкзз уполномоченным пользователем). Тем нс менее автор ПЗ/ЗБ может определить, что для некоторых угроз, исходящих ог среды, требуется аудит физических нападений. В этом случае автору ПЗ/ЗБ следует включить в список событий аудита соответствующие требования. Необходимо иметь в виду, что наличие этих требований может повлиять на конструкцию аппаратуры 31 ее взаимодействие с программным обеспечением.

FPT_PHP.l Пассивное обнаружение физического нападения

Замечания по применению для пользователя

Компонент FPT PHP.I следует применять, когда угрозам несанкционированного физического воздействия на части 00 не противопоставлены процедурные методы. В этом компоненте рассматривается угроза. что физическое воздействие на ФБО может и не быть выявлено. Обычно задача верификации того, что нападение имело место, возлагается на уполномоченного пользователя. Как уже сказано. этот компонент всего лишь представляет способность ФБО обнаруживать физическое воздействие, поэтому требуется -зависимость от FMT MOF.I, чтобы специфицировать. кто и каким образом можег воспользоваться этой способностью. Если эта функция реализована с помощью механизма, не связанного с ИТ (например, путем физической проверки), то может быть указано, что зависимость от ГМ Г МОГ.I не удовлетворяется.

FPT_PHP.2 Оповещение о физическом нападении

Замечания по применению для пользователя

Компонент FPT PH Р.2 следует применять, когда угрозам несанкционированного физического воздействия на части 00 нс противопоставлены процедурные методы и при этом требуется оповещение определенных лиц о фи зическом нападении. В этом компоненте рассматривается угроза, что физическое воздействие на элементы ФБО может быть хотя и выявлено, но не замечено (т. е. о нем никто не оповещен).

Операции

Н а з н а ч ен не

Для FPT_PHP.2.3 автору ПЗ/ЗБ следует предоставить список устройств/элементов, реализующих ФБО. для которых требуется активное обнаружение физического воздействия.

Для ЕРТ_РНР.2.3 автору 113/ЗБ следует указать пользователя или роль, уведомляемую об обнаружении физического воздействия. Тип пользователя или роли могут меняться на итерациях компонента управления безопасностью FMT_MOF.l. включенного в 113/ЗБ.

FPT_PHP.3 Противодействие физическому нападению

Для некоторых типов воздействия требуется, чтобы ФБО не только обнаруживали воздействие, но и фактически противодействовали ему или задерживали напавшего.

Замечания по применению для пользователя

Компонент FPT РНР.З следует использовать, когда устройства и элементы, реализующие ФБО. предназначены для эксплуатации в среде, где физическое воздействие (например, с целью наблюдения, анализа или модификации) на составляющие устройств, реализующих ФБО. или же на элементы, реализующие ФБО. само по себе признано угрозой.

Операции

Н а з н а ч с н и с

Для ЕРТ_РНР.3.1 автору ПЗ/ЗБ следует специфицировать хтя списка устройств/элементов, реализующих ФБО. сценарии физического проникновения; ФБО следует противодействовать физическому проникновению, выполняемому по этим сценариям. Этот список может относиться к определенному подмножеству физических устройств и элементов, реализующих ФБО, выделенному на основе учета технологических ограничений и физической незащищенности прибора. Выделение такого подмножества следует четко определить и строго обосновать. Кроме того, ФБО следует реагировать на попытки физического проникновения автоматически. При автоматической реакции на физическое проникновение следует сохранять политику устройства, например, если проводится политика конфиденциальности, го прибор был бы физически отключен для того, чтобы защищаемая информация нс могла быть считана.

Для FPT_PHP.3.1 автору ПЗ/ЗБ следует специфицировать список устройств/элементов. реализующих ФБО. для которых ФБО следует противодействовать физическому проникновению согласно идентифицированным сценариям.

Л.8 Надежное восстановление (FPT_RCV)

Требования семейства FPT RCV обеспечивают, чтобы ФБО могли определить, не нарушена ли зашита ФБО при запуске, и восстанавливаться без нарушения зашиты после прерывания операций. ’Это семейство важно, потому что начальное состояние ФБО при -запуске или восстановлении определяет защищенность 00 в последующем.

Компоненты данного семейства позволяют устанавливать безопасное состояние ФБО или предотвращать их переход в опасное состояние после сбоев, прерывания функционирования или перс запуска. В число возможных сбоев обычно включают:

а) сбои, которые всегда приводят к аварийным отказам системы (например, устойчивая несогласованность критичных системных таблиц: неуправляемые переходы в коле ФБО. вызванные сбоями аппаратных или программно-аппаратных средств: сбои питания, процессора, связи):

б) сбои носителей, приводящие к тому, что часть носителя или весь носитель, представляющий объекты ФБО, становится недоступным или неисправным (например, ошибки четности, неисправность головок дисков, устойчивый сбой чтения/записи, неточная юстировка головок дисков, износ магнитного покрытия, запыленность поверхности диск,]):

в) прерывание функционирования вследствие ошибочных действий администратора или отсутствия его своевременных действий (например, неожиданное прекращение работы из-за неподготовленности к отключению питания, игнорирование перерасхода критичных ресурсов, неадекватная инсталлированная конфигурация).

Важно отметить, что восстановление можег быть предусмотрено для сценария как частичного, гак и полного отказа. Полный отказ можег возникнуть в неразделенной операционной системе, в распределенной среде его вероятность меньше. В такой среде некоторые подсистемы могут отказать. в то время как другие части останутся работающими. Более того, критичные элементы могут иметь избыточность (дублирование дисков, альтернативные маршруты) и точки проверки. Пол восстановлением имеется в виду восстановление бе (опасного состояния.

Семейство FPT RCV идентифицирует режим аварийной поддержки. В этом режиме нормальное функционирование может оказаться невозможным или сильно ограниченным из-за возможности перехода в опасное состояние. В таких случаях обычно доступ разрешается только уполномоченным пользователям, а более конкретно. кто может получить доступ в режиме аварийной поддержки, определяется в классе F.MT «Управление безопасностью». Если в классе FMT нет никаких указаний о том. кто имеет право доступа в этом режиме, теоретически допускается, что восстановить систему может любой пользователь. Однако на практике эго нежелательно. поскольку пользователь, востанавливаюший систему, может установить конфигурацию ОО. нарушающую ИБО.

Механизмы, предназначенные для обнаружения исключительных состояний при эксплуатации, определяются в FPT TST «Самотестирование ФБО». FPT FLS «Безопасность при сбое» и в других разделах, относящихся к проблеме «Сохранность программного обеспечения».

Замечания для пользователя

В этом семействе применяется выражение «безопасное состояние». Оно относится к состоянию, при котором данные ФБО непротиворечивы и продолжают корректное осуществление ИБО. Это состояние может быть состоянием после загрузки системы или состоянием в некоторой контрольной точке. Термин «безопасное состояние» определяется в модели ПФБ. Если разработчик предоставил четкое определение безопасного состояния и разъяснение, когда его следует считать таковым, зависимость FPT RCV.I—FPT RCV.4 от ADV SPX1.I можно не учитывать.

FPT^RCV.I Ручное восстановление

Среди видов надежного восстановления тот из них. который основан только на ручном вмешательстве, наименее желателен, так как при этом исключается восстановление системы без участия человека.

Замечания по применению для пользователя

Компонент FPT RCV.1 предназначен для применения в ОО. которые не требуют автоматического восстановления безопасного состояния. Требования этого компонента направлены против угрозы нарушения зашиты в результате приведения ОО с участием человека в опасное состояние при восстановлении после сбоя или другого прерывания.

Замечания по применению для оценщика

Допускается, чтобы функции уполномоченного администратора по надежному восстановлению были доступны ему только в режиме аварийной поддержки. Следует предусмотреть средства ограничения доступа в режиме аварийной поддержки, предоставляя его только уполномоченным пользователям.

FPT_RCV.2 Автоматическое восстановление

Автоматическое восстановление считается более предпочтительным, чем ручное, так как оно позволяет машине продолжать функционирование без участия человека.

Замечания по применению для пользователя

Компонент FPT RCV.2 расширяет FPT RCV.I. требуя возможность автоматического восстановления хотя бы после одного типа сбоя/прерывания обслуживания. Требования этого компонента направлены против угрозы нарушения -зашиты в результате приведения ОО бе з участия человека в опасное состояние при восстановлении после сбоя или другого прерывания.

Замечания по применению для оиеншика

В соответствии с FPT RCV.2.1 разработчик ФБО отвечает за определение совокупности сбоев и прерываний обслуживания, после которых возможно восстановление.

Предполагается, что робастность механизмов автоматического восстановления будет верифицирована. Операции

Назначение

Для FPT_RCV.2.2 автору ПЗ/ЗБ следует специфицировать список сбоев или других прерываний обслуживания, для которых необходима возможность автоматического восстановления.

FPT_RCV.3 Автоматическое восстановление без недопустимой потери

Автоматическое восстановление считается более предпочтительным, чем ручное, но оно связано с риском потери большого числа объектов. Предотвращение недопустимых потерь объектов обеспечивается дополнительными средствами восстановления.

Замечания по применению для пользователя

Компонент FPT RCV.3 расширяет FPT RCV.2. требуя, чтобы не было чрезмерных потерь данных или объектов ФБО в ОДФ. В соответствии с FPT RCV.2 механизм автоматического восстановления мог бы. в предельном случае, произвести восстановление путем уничтожения всех обьектов и возвращения ФБО в известное безопасное состояние. Такой тип автоматического восстановления в FPT RCV.3 запрещается.

Требования этого компонента направлены против утрозы нарушения защиты в результате непредусмотренного перехода ()() в опасное состояние при восстановлении после сбоя или перерывов в функционировании с большой потерей данных или объектов ФБО в ОДФ.

Замечания по применению для оценщика

Предполагается, что робастность механизмов автоматического восстановления будет верифицирована оиеншнком.

Операции

Назначение

Дтя FPT RCV.3.2 автору ПЗ/ЗБ следует специфицировать список сбоев или других прерываний обслуживания. для которых необходима возможность автоматического восстановления.

Для FPTRCV.3.3 автору ПЗ/ЗБ следует предоставить количественную меру приемлемых потерь данных или объектов ФБО.

FPT_RCV.4 Восстановление функции

Компонент FPT RCV.4 содержит требование, чтобы в случае сбоя ФБО некоторые функции из числа ФБО либо нормально заканчивали работу*, либо возвращались к безопасному состоянию.

Операции

Н а з н а ч с н и с

В FPT_RCV.4.1 автору ПЗ/ЗБ следует специфицировать список функций безопасности и сценариев сбоев, для которых нормально заканчивается работа ФБ, указанных в списке, или восстанавливается их устойчивое и безопасное состояние.

Л.9 Обнаружение повторного использования (FPT_RPL)

FPT_RPL.l Обнаружение повторного использования

Замечания по применению для пользователя

Рассматриваемыми здесь сущностями могут быть, например, сообщения, запросы на обслуживание, ответы на запросы обслуживания или сеансы пользователей.

Операции

Н а з н а ч е и и е

В FPT_RPL.1.I автору ПЗ/ЗБ следует представить список сущностей, для которых следует предусмотреть возможность обнаружения повторного использования. Их примерами могут быть: сообщения, запросы на обслуживание, ответы на запросы обслуживания, сеансы пользователей.

В FPT_RPL.1.2 автору ПЗ/ЗБ следует специфицировать список действий, предпринимаемых ФБО при обнаружении повторного использования. Совокупность предпринимаемых действий может включать в себя игнорирование повторно используемой сущности, запрос подтверждения сущности из идентифицированного источника и отключение субъекта, пытавшегося инициировать повторное использование.

Л.10 Посредничество при обращениях (FPT_RVM)

Требования семейства FPT RVM связаны с аспектом «постоянная готовность» традиционного монитора обращений. Цель этого семейств;! состоит в обеспечении для заданной ПФБ. чтобы в ОДФ все действия, требующие осуществления политики и инициируемые субъектами, недоверенными относительно одной или всех ПФБ. над объектами, управляемыми этой ПФБ. проверялись ФБО на соответствие ПФБ. Если помимо этого часть ФБО. осуществляющая ПФБ. выполняет требования соответствующих компонентов из семейств FPT SEP «Разделение домена* и ADV INT «Внутренняя структура ФБО», то эта часть ФБО обеспечивает «монитор обращений» для этой ПФБ.

Монитор обращений является частью ФБО. ответственной за осуществление ПБО, и обладает следующими тремя свойствами.

а) Недоверенные субъекты не могут вмешиваться в работу монитора, т. е. он устойчив к проникновению. *Эго свойство обеспечивается требованиями компонентов семейства FPT SEP.

б) Недоверенные субъекты не могут обойти проверки монитора, т. е. он постоянно готов к работе. Это свойство обеспечивается требованиями компонентов семейства FPT RVM.

в) Монитор достаточно прост, его устройство поддается анализу, его действия понятны (т. е. его построение концептуально несложно). Это свойство обеспечивается требованиями компонентов семейства ADV INT.

В единственном компоненте семейства FPT RVM содержится требование: «ФБО должны обеспечить, чтобы функции, осуществляющие ПБО, вызывались и успешно выполнялись прежде, чем разрешается выполнение любой другой функции в пределах ОДФ». В любой системе (распределенной или ист) имеется конечное число функций, ответственных за осуществление ПБО. В этом требовании не утверждается, что для управления безопасностью применяется одна функция. Наоборот, утверждается, что роль механизма проверки правомочности обращений выполняют несколько функций, и именно их совокупность, осуществляющая ПБО. объединена пол именем монитора обращений. При этом необходимо принимать во внимание задачу сохранения простоты «монитора обращений».

ФБО при реализации ПФБ предоставляют эффективную защиту от несанкционированных операций тогда и только тогда, когда правомочность всех действий, предполагаемых для осуществления (например, доступ к объектам) и запрошенных субъектами, недоверенными относительно всех или именно этой ПФБ. проверяется ФБО до выполнения действий. Если действия по проверке будут выполнены неправильно или проигнорированы (обойдены), то осуществление ПФБ в целом может быть поставлено пол угрозу (ее можно обойти). Тогда «недоверенные» субъекты смогут обходить ПФБ различными способами (такими, как обход проверки доступа для некоторых субъектов и объектов, обход проверки для объектов, чья -зашита управляется прикладными программами, сохранение права доступа после истечения установленного срока действия, обход аудита событий, подлежащих аудиту, обход аутентификации). Важно отметить, что термин «неловеренный субъект» относится к субъектам, недоверенным относительно какой-либо или всех осуществляемых ПФБ: субъект может быть доверенным относительно одной ПФБ и неловеренным относительно другой.

FPT-RVM.1 Невозможность обхода ПБО

Замечания по применению для пользователя

Для получения эквивалента монитора обращений необходимо применить данный компонент совместно либо с FPT SEP.2 «Отделение домена ПФБ». либо с FPT SEP.3 «Полный монитор обращений», а также с ADV INT.3* «Минимизация сложности». Кроме того, если требуется полное посредничество при обращениях. требования компонентов из класса FDP «Зашита данных пользователя» необходимо распространить на все объекты в составе 00.

Л. II Разделение домена (FPT_SEP)

Компоненты семейства FPT SEP обеспечивают, чтобы по меньшей мерс один домен безопасности был доступен только для собственного выполнения ФБО. и этим они были защищены ог внешнего вмешательства и искажения ( например, модификации кода или структур данных ФБО) со стороны недоверенных субъектов. Выполнение требований этого семейства устанавливает такую самозащиту ФБО. что неловеренный субъект не сможет модифицировать или повредить ФБО.

Это семейство содержит следующие требования.

а) Ресурсы домена безопасности ФБО («защищенного домена») и ресурсы субъектов и активных сущностей. внешних по отношению к этому домену, разделяются так. что сущности, внешние по отношению к защищенному домену, не смогут получить или модифицировать данные или код ФБО в пределах защищенного домена.

б) Обмен между доменами управляется так. что невозможен произвольный вход в защищенный домен или произвольный выход из него.

в) Параметры пользователя или прикладкой программы, переданные в защищенный домен по адресу, проверяются относительно адресного пространства защищенного домена, а переданные по значению — относительно значений, ожидаемых этим доменом.

Замечания для пользователя

Это семейство применяется, когда требуется уверенность в том. что ФБО не подвержены внешнему воздействию.

Для получения эквивалента монитора обращений необходимо применить компонент FPT SEP.2 (Отделение домена ПФБ) или FPT SEP.3 «Полный монитор обращений» совместно с FPT RVM.1 «Невозможность обхода ИБО» и ADV INT.3 «Минимизация сложности*. Кроме того_ь если требуется полное посредничество при обращениях, требования компонентов из класса FDP «Зашита данных пользователя» необходимо распространить на все объекты в составе ОО.

FPT_SEP.l Отделение домена ФБО

Без отдельного защищенного домена для ФБО нс может быть доверия тому, что ФБО не подвергались каким-либо воздействиям со стороны недоверенных субъектов. Такие воздействия могут привести к модификации кола и/или структур данных ФБО.

FPT-SEP.2 Отделение домена ПФБ

Наиболее важной функцией ФБО является поддержка осуществляемых ими ПФБ. Чтобы упростить разработку ПФБ и прибли зить их свойства к свойствам монитора обращений, в частности, к стойкости к воздействиям. функции, проводящие ПФБ. необходимо сосредоточить в домене, отличном от остальной части ФБО.

Замечания по применению для оненшика

Возможно, что монитор обращений в многоуровневом проекте предоставляет больше функций, чем требуется в ПФБ. Это проистекает из практической реализации многоуровневого проекта программного обеспечения. При этом функции, не относящиеся к ПФБ. следует свести к минимуму.

Допустимо, чтобы мониторы обращений для всех осуществляемых ПФБ находились как в одном домене монитора обращений, так и в нескольких доменах (каждый используется для осуществления одной или нс-скольких ПФБ). Если имеется несколько доменов монитора обращений для нескольких ПФБ. они могут или быть равноправными, или образовывать иерархию.

Дтя FPT SEP.2.1 фраза «псизолированная часть ФБО» относится к той части ФБО. которая не охвачена в FPT SEP.2.3.

Операции

Назначение

Для FPTSEP.2.3 автору ПЗ/ЗБ следует специфицировать те ПФБ управления доступом и/или информационными потоками, которым следует занимать отдельный домен.

FPT_SEP.3 Полный монитор обращений

Наиболее важной функцией из числа ФБО является поддержка осуществляемых ими ПФБ. Компонент ГРТ SEP.3 завершает требования предыдущих компонентов семейства, устанавливая, что «се функции безопасности. проводящие ПФБ управления доступом и/или информационными потоками, будут выполняться в домене, отличном от домена выполнения остальных ФБО. Это упрощает разработку ФБО и приближает их свойства к свойствам монитора обращений, в частности, к стойкости к воздействиям.

Замечания по применению для оценшика

Возможно, что монитор обращений в многоуровневом проекте предоставляет больше функции, чем требуется в ПФБ. Эго проистекает из практической реализации многоуровневого проекта программного обеспечения. При этом функции, не относящиеся к ПФБ. следует свести к минимуму.

Допустимо, чтобы мониторы обращений для всех осуществляемых ПФБ находились как в одном домене монитора обращений, так и в нескольких доменах (каждый используется для осуществления одной или нескольких ПФБ). Если имеется несколько доменов монитора обращений ;1ля нескольких ПФБ. они могут или быть равноправными, или образовывать иерархию.

Л. 12 Протокол синхронизации состояний (FPT_SSP)

Распределенные системы могут иметь большую сложность, чем нераспределенные, из-за многообразия состояний частей системы, а также из-за задержек связи. В большинстве случаев синхронизация состояния между распределенными функциями включает в себя, вместо обычных действий, применение протокола обмена. Когда в среде распределенных систем существуют угрозы безопасности, потребуются более сложные защищенные протоколы.

Семейство ГРТ SSP устанавливает требование использования надежных протоколов некоторыми критичными по безопасности функциями и з числа ФБО. Оно обеспечивает, чтобы две распределенные части 00 (например, главные ЭВМ) синхронизировали свои состояния после действий, связанных с безопасностью.

Замечания для пользователя

Некоторые состояния невозможно синхронизировать, или затраты на транзакцию будут слишком велики для практического применения; отмена ключа шифрования является примером, когда после выполнения действия состояние может стать неопределенным. Либо действие предпринято, а подтверждение не может быть отправлено, либо сообщение проигнорировано получателем, и поэтому отмена не произойдет. Неопределенность присуща распределенным системам. Проблема неопределенности связана с необходимостью синхронизации состояний и может решаться соответствующими методами. Планировать неопределенные состояния бесполезно; при них автору ПЗ/ЗБ следует прибегнуть к другим требованиям (например, подача сигнала тревоги, проведение аудита).

FPT_SSP.l Одностороннее надежное подтверждение

Замечания по применению для полью ваге л я

В компоненте ГИГ SSP. I необходимо, чтобы по запросу ФБО предоставляли подтверждение для другой части ФБО. Это подтверждение требуется для указания, что в одной части распределенного ОО успешно получено ^модифицированное сообщение из другой части 00.

FPT_SSP.2 Взаимное надежное подтверждение

Замечания по применению для пользователя

Компонент FPT SSP.2 содержит требование, что в дополнение к предоставлению подтверждения получения передаваемых данных принимающей части ФБО необходимо обратиться к передающей за уведомлением о получении подтверждения.

Например, локальная часть ФБО передает данные удаленной части ФБО. Последняя подтверждает успешный прием сообщения и запрашивает у передавшей сообщение части ФБО уведомление, что она получила подтверждение. Этот механизм дает дополнительную уверенность, что обе части ФБО. участвующие в передаче данных, извещены об успешном завершении передачи.

.1.13 Метки времени (FPT.STM)

Семейство FPT STM содержи! требования по предоставлению надежных меток времени в пределах 00.

Замечания для пользователя

На автора ПЗ/ЗБ возлагается разъяснение смысла выражения «надежные метки времени» и указание, где принимается решение о надежности.

FPT-STM.1 Надежные метки времени

Замечания по применению для пользователя

Применение компонента FPT STM.I возможно для предоставления надежных меток времени при проведении аудита, а также для ограничения срока действия атрибутов безопасности.

Л. 14 Согласованность данных ФБО между ФБО (FPT_TDC)

В среде распределенной или сложной системы от ОО может потребоваться произвести обмен данными ФБО (такими, как атрибуты ПФБ. ассоциированные с данными, информация аудита или идентификации) с другим доверенным продуктом ИТ. Семейство FPT TDC определяет требования для совместного использования и непротиворечивой интерпретации этих атрибутов между ФБО и другим доверенным продуктом ИТ.

Замечания для пользователя

Это семейство предназначено для представления требований к автоматической поддержке согласованности данных ФБО при их передаче между ФБО рассматриваемого ОО и ФБО другого доверенного продукта. Возможна и такая ситуация, когда для согласования атрибутов безопасности применяются только процедурные меры, однако они здесь не рассматриваются.

Семейство FPT TDC отличается от ГОР ЕТС и FDP ГГС. гак как последние направлены лишь на соотнесение атрибутов безопасности между ФБО и носителями импортируемой или экспортируемой ими нн-<|юрмаиии.

В случае, когда важна целостность данных ФБО. следует выбрать требования из семейства ГР Г ГГ1. Его компоненты определяют требования, чтобы ФБО были способны обнаружить и/или исправить модификации данных ФБО во время передачи.

FPT_TDC. I Базовая согласованность данных ФБО между ФБО

Замечания по применению для пользователя

ФБО отвечают за поддержку согласованности данных ФБО. используемых ими или ассоциированных с ними, которые являются общими у двух или более доверенных систем. Например, данные ФБО для ФБО двух различных систем могут толковаться внутри них по-разному. Для правильного применения данных ФБО принимающим доверенным продуктом ИТ (например, для обеспечения такой же защиты данных пользователя, как и в ОО) необходимо, чтобы ОО и другой доверенный продукт ИТ применяли заранее установленный протокол обмена данными ФБО.

Операции

Назначение

В FPT_TDC.1.1 автору ПЗ/ЗБ следует определить список типов данных ФБО. которые должны согласованно интерпретироваться при совместном использовании ФБО и другим доверенным продуктом ИТ.

В FPTTDC.1.2 автору ПЗ/ЗБ следует привести список правил интерпретации, применяемых ФБО.

Л.15 Согласованность данных ФБО при дублировании в пределах ОО (FPT_TRC)

Требования семейства FPT TRC необходимы, чтобы обеспечить согласованность данных ФБО. когда они дублируются в пределах ОО. Такие данные могут стать несогласованными при нарушении работоспособности внутреннего канала между частями ОО. Если ОО внутренне структурирован как сеть, то это может произойти m-за отключения отдельных частей сети при разрыве сетевых соединений.

Замечания для пользователя

Метол обеспечения согласованности в данном семействе не указывается. Согласованность может достигаться с помощью некоторой формы обработки транзакций (где соответствующие транзакции «возвращаются назад» к месту отправления через повторное соединение) или путем обновления дублируемых данных через протокол синхрони зании. Если для ПЗ/ЗБ необходим конкретный протокол, го он может быть специфицирован с использованием операции уточнения.

Можег оказаться, что синхронизировать некоторые состояния невозможно или затраты на такую синхронизацию слишком высоки. Примером подобной ситуации служит отмена каналов связи it ключей шифрования. Могут также возникать неопределенные состояния. Если желателен конкретный режим функционирования. его следует специфицировать с использованием операции уточнения.

fPT TRC.l Согласованность дублируемых данных ФБО

Операции

Н а з н а ч е и и е

В FPT_TRC. 1.2 автору ПЗ/ЗБ следует специфицировать список ФБ, которые зависят от согласованности дублирования данных ФБО.

Л. 16 Самотестирование ФБО (FPT.TST)

Семейство I ИГ 1ST определяет требования для самотестирования ФБО в части некоторых типичных операций с известным результатом. Примерами могут служить обращения к интерфейсам осуществляемых функций, а также некоторые арифметические операции, выполняемые критичными частями ОО. Эти тесты могут выполняться при запуске, периодически, по запросу уполномоченного пользователя или при удовлет