Товары в корзине: 0 шт Оформить заказ
Стр. 1 

166 страниц

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

 Скачать PDF

Данные о замене опубликованы в ИУС 5-2009

Оглавление

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

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

     1.2 Структура

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

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

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

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

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

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

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

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

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

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

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

4 Класс FСО. Связь

     4.1 Неотказуемость отправления (FСО_NRО)

     4.2 Неотказуемость получения (FСО_NRR)

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

     5.1 Управление криптографическими ключами (FCS_СКМ)

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

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

     6.1 Политика управления доступом (FDР_АСС)

     6.2 Функции управления доступом (FDР_АСР)

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

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

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

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

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

     6.8 Передача в пределах ОО (FDР_ITT)

     6.9 Защита остаточной информации (FDР_RIР)

     6.10 Oткат(FDР_ROL)

     6.11 Целостность хранимых данных (FDР_SDD)

     6.12 Защита конфиденциальности данных пользователя при передаче между ФБО (FDP_UСТ)

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

7 Класс FIА. Идентификация и аутентификация

     7.1 Отказы аутентификации (FIA_АFL)

     7.2 Определение атрибутов пользователя (FIA_АТD)

     7.3 Спецификация секретов (FIA_ SOS)

     7.4 Аутентификация пользователя (FIA_UAU)

     7.5 Идентификация пользователя (FIA_UID)

     7.6 Связывание пользователь-cубъект (FIA_USB)

8 Класс РМТ. Управление безопасностью

     8.1 Управление отдельными функциями ФБО (FМТ_МОF)

     8.2 Управление атрибутами безопасности (FМТ_МSА)

     8.3 Управление данными ФБО (FМТ_МТD)

     8.4 Отмена (FМТ_REV)

     8.5 Срок действия атрибута безопасности (FМТ_SАЕ)

     8.6 Роли управления безопасностью (FМТ_SМR)

9 Класс FРR. Приватность

     9.1 Анонимность (FРR_ANO)

     9.2 Псевдонимность (FРR_PSЕ)

     9.3 Невозможность ассоциации (FРR_UNL)

     9.4 Скрытность (FРR_UNО)

10 Класс РРТ. Защита ФБО

     10.1 Тестирование базовой абстрактной машины (FРТ_АМТ)

     10.2 Безопасность при сбое (FРТ_FLS)

     10.3 Доступность экспортируемых данных ФБО (FРТ_IТА)

     10.4 Конфиденциальность экспортируемых данных ФБО (FРТ_IТС)

     10.5 Целостность экспортируемых данных ФБО (FРТ_IТI)

     10.6 Передача данных ФБО в пределах ОО (FРТ_IТТ)

     10.7 Физическая защита ФБО (FРТ_РНР)

     10.8 Надежное восстановление (FРТ_RCV)

     10.9 Обнаружение повторного использования (FРТ_RPL)

     10.10 Посредничество при обращениях (FРТ_RVМ)

     10.11 Разделение домена (FРТ_SЕР)

     10.12 Протокол синхронизации состояний (FРТ_SSР)

     10.13 Метки времени (FРТ_SТМ)

     10.14 Согласованность данных ФБО между ФБО (FРТ_TDС)

     10.15 Согласованность данных ФБО при дублировании в пределах ОО (FРТ_ТRС)

     10.16 Самотестирование ФБО (FРТ_ТSТ)

11 Класс FRU. Использование ресурсов

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

     11.2 Приоритет обслуживания (FRU_РRS)

     11.3 Распределение ресурсов (FRU_RSА)

12 Класс FТА. Доступ к ОО

     12.1 Ограничение области выбираемых атрибутов (FТА_LSА)

     12.2 Ограничение на параллельные сеансы (FТА_МСS)

     12.3 Блокирование сеанса (FТА_SSL)

     12.4 Предупреждения перед предоставлением доступа к ОО (FТА_ТАВ)

     12.5 История доступа к ОО (FТА_TАН)

     12.6 Открытие сеанса с ОО (FТА_TSЕ)

13 Класс РТР. Доверенный маршрут/канал

     13.1 Доверенный канал передачи между ФБО (FТР_IТС)

     13.2 Доверенный маршрут (FTP_TRР)

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

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

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

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

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

     В.1 Автоматическая реакция аудита безопасности (FAU_АRР)

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

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

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

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

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

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

     Г.1 Неотказуемость отправления (FСО_NRО)

     Г.2 Неотказуемость получения (FСО_NRR)

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

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

     Д.2 Криптографические операции (FCS_СОР)

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

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

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

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

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

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

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

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

     Е.8 Передача в пределах ОО (FDР_IТТ)

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

     Е.10 Откат (FDР_ROL)

     Е.11 Целостность хранимых данных (FDР_SDI)

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

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

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

     Ж.1 Отказы аутентификации (FIА_АFL)

     Ж.2 Определение атрибутов пользователя (FIА_АТD)

     Ж.3 Спецификация секретов (FIА_SOS)

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

     Ж.5 Идентификация пользователя (FIА_UID)

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

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

     И.1 Управление отдельными функциями ФБО (FМТ_MOF)

     И.2 Управление атрибутами безопасности (FМТ_MSА)

     И.3 Управление данными ФБО (FМТ_МТD)

     И.4 0тмена(FМТ_REV)

     И.5 Срок действия атрибутов безопасности (FМТ_SАЕ)

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

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

     К.1 Анонимность (FРR_АNО)

     К.2 Псевдонимность (FРR_РSЕ)

     К.3 Невозможность ассоциации (FРR_UNL)

     К.4 Скрытность (FРR_UNО)

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

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

     Л.2 Безопасность при сбое (FРТ_FLS)

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

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

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

     Л.6 Передача данных ФБО в пределах ОО (FРТ_IТТ)

     Л.7 Физическая защита ФБО (FРТ_РНР)

     Л.8 Надежное восстановление (FРТ_RCV)

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

     Л.10 Посредничество при обращениях (FРТ_RVМ)

     Л.11 Разделение домена (FРТ_SЕР)

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

     Л.13 Метки времени (FРТ_SТМ)

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

     Л.15 Согласованность данных ФБО при дублировании в пределах ОО (FРТ_TRС)

     Л.16 Самотестирование ФБО (FРТ_TSТ)

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

     М.1 Отказоустойчивость (FRU_FLТ)

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

     М.3 Распределение ресурсов (FRU_RSА)

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

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

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

     Н.3 Блокирование сеанса (FTA_SSL)

     H.4 Предупреждения перед предоставлением доступа к ОО (FTA_ТАВ)

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

     Н.6 Открытие сеанса с ОО (FTA_TSЕ)

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

     П.1 Доверенный канал передачи между ФБО (FТР_IТС)

     П.2 Доверенный маршрут (FТР_TRР)

 

166 страниц

Дата введения01.01.2004
Добавлен в базу01.09.2013
Завершение срока действия01.10.2009
Актуализация01.01.2021

Этот ГОСТ находится в:

Организации:

04.04.2002УтвержденГосстандарт России133-cт
РазработанЦентр безопасности информации
Разработан4 ЦНИИ Министерства обороны РФ
РазработанЦентр Атомзащитаинформ
РазработанВНИИстандарт
РазработанМеждународная рабочая группа по Общим критериям
ИзданИПК Издательство стандартов2002 г.
РазработанЦНИИАТОМИНФОРМ

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

Стр. 1
стр. 1
Стр. 2
стр. 2
Стр. 3
стр. 3
Стр. 4
стр. 4
Стр. 5
стр. 5
Стр. 6
стр. 6
Стр. 7
стр. 7
Стр. 8
стр. 8
Стр. 9
стр. 9
Стр. 10
стр. 10
Стр. 11
стр. 11
Стр. 12
стр. 12
Стр. 13
стр. 13
Стр. 14
стр. 14
Стр. 15
стр. 15
Стр. 16
стр. 16
Стр. 17
стр. 17
Стр. 18
стр. 18
Стр. 19
стр. 19
Стр. 20
стр. 20
Стр. 21
стр. 21
Стр. 22
стр. 22
Стр. 23
стр. 23
Стр. 24
стр. 24
Стр. 25
стр. 25
Стр. 26
стр. 26
Стр. 27
стр. 27
Стр. 28
стр. 28
Стр. 29
стр. 29
Стр. 30
стр. 30

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

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

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

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

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

Часть 2

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

БЗ 6-2001/139


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

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

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

Предисловие

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

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

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

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

4    ВВЕДЕН ВПЕРВЫЕ

© ИПК Издательство стандартов, 2002

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

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


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

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

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

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

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

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

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

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

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

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

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


ДАННЫЕ ОО


ДАННЫЕ ФБО


ДАННЫЕ

ПОЛЬЗОВАТЕЛЕЙ


Аудентифика-

ционные

данные


'    n\

Атрибуты безопасности \ f    Атрибуты пользователей    )

^    Атрибуты объектов    )

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

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


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


5


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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

2.1.1.1    Имя класса

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

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

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

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

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

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

Рисунок 2.2

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

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

ляет основное имя ссылки для компонентов.

7

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

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

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

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

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

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

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

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

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

в 2.2.

2.1.2.4    Управление

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

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

2.1.2.5    Аудит

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9

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

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

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

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

—    итерация — позволяет несколько раз использовать компонент с различным выполнением операций;

—    назначение — позволяет специфицировать заданный параметр;

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

—    уточнение — позволяет добавить детали.

2.1.4.1    Итерация

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

2.1.4.2    Назначение

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

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

2.1.4.3    Выбор

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

2.1.4.4    Уточнение

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

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

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

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

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

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

10

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Аудит: FAU ARP. 1

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

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

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

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

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

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

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

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

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


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

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

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

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

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

Аудит: FAUGEN.l, FAU GEN.2

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

FAU_GEN.l Генерация данных аудита

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

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

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

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

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

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

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

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

13

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

2-1-1523

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

FIA UID.1 Выбор момента идентификации

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

системы.

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

Содержание

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

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

1.2    Структура....................................... 2

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

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

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

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

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

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

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

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

3.4    Просмотр аудита безопасности (FAU SAR)....................... 16

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

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

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

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

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

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

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

5.2    Криптографические операции (FCS COP)....................... 24

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

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

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

6.3    Аутентификация данных (FDP DAU).........................28

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

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

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

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

6.8    Передача в пределах ОО (FDP ITT)..........................35

6.9    Защита остаточной информации (FDP RIP)...................... 37

6.10    Откат (FDP ROL).................................. 38

6.11    Целостность хранимых данных (FDP SDI)....................... 38

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

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

7    Класс FIA. Идентификация и аутентификация.......................42

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

7.2    Определение атрибутов пользователя (FIAATD)....................43

7.3    Спецификация секретов (FIA SOS)..........................44

7.4    Аутентификация пользователя (FIA_UAU)........................45

7.5    Идентификация пользователя (FIA^UID)........................47

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

8    Класс FMT. Управление безопасностью..........................49

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

8.2    Управление атрибутами безопасности (FMTMSA).................... 50

8.3    Управление данными ФБО (FMT MTD)........................ 51

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

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

8.6    Роли управления безопасностью (FMT SMR)....................... 54

9    Класс FPR. Приватность.................................. 55

9.1    Анонимность (FPR ANO)............................... 56

9.2    Псевдонимность (FPR PSE).............................. 56

9.3    Невозможность ассоциации (FPR UNL)......................... 57

9.4    Скрытность (FPR UNO)............................... 58

III

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

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

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

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

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

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

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

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 ФБО должны быть способны указать на ожидаемое нарушение ПБО, когда рейтинг подозрительной активности пользователя превышает следующие пороговые условия [назначение: условия, при которых ФБО сообщает об аномальных действиях].

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

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

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

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

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

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

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

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

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

15

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

2-1*

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

10    Класс FPT. Защита ФБО.................................. 59

10.1    Тестирование базовой абстрактной машины (FPT_AMT)................ 61

10.2    Безопасность при сбое (FPT FLS).......................... 62

10.3    Доступность экспортируемых данных ФБО (FPT ITA)................. 62

10.4    Конфиденциальность экспортируемых данных ФБО (FPT ITC)............63

10.5    Целостность экспортируемых данных ФБО (FPT ITI)................. 63

10.6    Передача данных ФБО в пределах ОО (FPT ITT)...................64

10.7    Физическая защита ФБО (FPT PHP)......................... 65

10.8    Надежное восстановление (FPT RCV)......................... 67

10.9    Обнаружение повторного использования (FPT RPL).................. 69

10.10    Посредничество при обращениях (FPT RVM)..................... 69

10.11    Разделение домена (FPT_SEP)............................ 70

10.12    Протокол синхронизации состояний (FPT SSP).................... 71

10.13    Метки времени (FPT STM)............................. 72

10.14    Согласованность данных ФБО между ФБО (FPTJTDC)................72

10.15 Согласованность данных ФБО при дублировании в пределах ОО (FPTTRC)......73

10.16    Самотестирование ФБО (FPT TST).......................... 74

11    Класс FRU. Использование ресурсов............................ 74

11.1    Отказоустойчивость (FRU    FLT)...........................75

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

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

12    Класс FTA. Доступ к ОО.................................. 77

12.1    Ограничение области выбираемых атрибутов (FTALSA)................78

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

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

12.4    Предупреждения перед предоставлением доступа к ОО (FTA_TAB)...........80

12.5 История доступа к ОО (FTA TAH)..........................81

12.6 Открытие сеанса с ОО (FTAJTSE)..........................81

13    Класс FTP. Доверенный маршрут/канал.......................... 82

13.1    Доверенный канал передачи между ФБО (FTPITC)..................82

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Д.2 Криптографические операции (FCS^COP)........................103

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

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

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

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

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

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

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

IV

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

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

Е.8 Передача в пределах ОО (FDP ITT).........................116

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

ЕЛО Откат (FDP ROL) .................................119

ЕЛ 1 Целостность хранимых данных (FDP SDI) ......................119

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

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

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

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

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

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

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

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

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

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

И. 1 Управление отдельными функциями ФБО (FMT MOF)................127

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

И.3 Управление данными ФБО (FMT MTD)........................129

И.4 Отмена (FMT REY) .................................130

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

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

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

КЛ Анонимность (FPR ANO) ..............................132

К.2 Псевдонимность (FPR PSE) .............................133

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

К.4 Скрытность (FPRJJNO)...............................137

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

ЛЛ Тестирование базовой абстрактной машины (FPT_AMT)................140

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

Л.З Доступность экспортируемых данных ФБО (FPT ITA).................142

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

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

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

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

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

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

ЛЛ 0 Посредничество при обращениях (FPT RVM) ....................147

ЛЛ 1 Разделение домена (FPT_SEP) ............................148

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

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

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

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

Л Л 6 Самотестирование ФБО (FPTTST).........................150

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

МЛ Отказоустойчивость (FRU FLT) ...........................151

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

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

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

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

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

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

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

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

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

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

П. 1 Доверенный канал передачи между ФБО (FTP ITC) ..................158

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

V

Введение

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

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

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

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

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

VI

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

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

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

Часть 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 и соответствующие функциональные требования безопасности, описанные ниже, не предназначены для окончательного решения всех задач безопасности ИТ. Скорее, настоящий стандарт предлагает совокупность хорошо продуманных функциональных требований безопасности, которые могут применяться при создании доверенных продуктов или систем ИТ, отвечаю-

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

1-2-1523

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

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

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

2

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

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

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


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

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

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

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

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

3

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

1-2*

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

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

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

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

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

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

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

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

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

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

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

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

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