Приложение F (рекомендуемое). Рабочий пример: профиль защиты третьей доверенной стороны

Приложение F
(рекомендуемое)

Рабочий пример: профиль защиты третьей доверенной стороны

F.1 Введение

В настоящем приложении поясняется применение руководства, содержащегося в разделах 7 - 13, посредством рабочего примера применительно к третьей доверенной стороне (ТДС). Рассматриваемый пример учитывает гибкость набора ФТБ, который зависит от типов сервисов, предоставляемых ТДС, например:

a) ТДС может обеспечивать или не обеспечивать сервисы конфиденциальности;

b) ТДС может предоставлять сервисы генерации ключей или предполагать, что подписчики ТДС выполняют действия по генерации ключей самостоятельно.

Исходя из вышеперечисленного, необходимо определить набор основных и дополнительных сервисов, предоставляемых ТДС.

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

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

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

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

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

Разрешение данной проблемы заключается в том, чтобы определить основной набор ФТБ в ПЗ, соответствующий основным сервисам ТДС.

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

Сформированный таким образом ПЗ ТДС может быть использован:

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

b) как основа для подготовки других ПЗ, с учетом конкретного набора услуг ТДС; такой ПЗ следует формировать на основе комбинации основного набора ФТБ соответственно с одним или более определенным функциональным пакетом. Данный подход приводит к созданию "семейства" ПЗ ТДС.

F.2 Среда безопасности объекта оценки

F.2.1 Предположения безопасности

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

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

Исходя из вышеизложенного, целесообразно выделить следующие два предположения.

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

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

Предположение А1 необходимо, так как сертификат, выпущенный ТДС, был бы девальвирован, если отсутствует доверие к выполнению подписчиком соответствующего алгоритма.

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

F.2.2 Угрозы

Для ТДС защищаемые активы ИТ - это сертификаты открытых ключей, сгенерированные или сохраненные (например, архивированные) ТДС вместе с ключами, используемыми или сгенерированными ТДС.

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

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

Источниками угроз могут быть как злоумышленники, так и подписчики ТДС, а также уполномоченные пользователи ОО.

В качестве примера можно привести следующие угрозы, имеющие отношение к основным сервисам ТДС:

Угроза Т1. Секретный ключ аутентификации подписчика раскрыт лицу, которое не имеет права его знать.

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

Источник угрозы - лицо, которое не имеет права знать секретный ключ подписчика ТДС.

Актив ИТ, подверженный нападению, - это секретный ключ подписчика ТДС.

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

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

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

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

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

Приведем примеры угроз, имеющих отношение к дополнительным сервисам ТДС.

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

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

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

F.2.3 Политика безопасности организации

В качестве ПБОр для ТДС может быть выбрана следующая политика:

Политика безопасности Р1. Требуется, чтобы ТДС соответствовал действующему законодательству и нормативным документам в области информационной безопасности.

F.3 Цели безопасности

F.3.1 Цели безопасности для объекта оценки

Цели безопасности для ТДС делятся на цели безопасности основных и дополнительных сервисов. Цели безопасности для ТДС могут быть определены следующим образом:

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

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

Цель O3. Объект оценки должен обеспечить сервисы генерации цифровых подписей для подтверждения аутентичности.

Цели безопасности O1 и O2 имеют непосредственное отношение к основным сервисам ТДС, предоставляемым подписчикам ТДС.

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

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

В дополнение к "основному" набору целей безопасности для ОО определяются цели безопасности дополнительных сервисов, например:

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

Цель безопасности O4 относится к дополнительному сервису по восстановлению ключей.

F.3.2 Цели безопасности для среды

Цели безопасности для среды определяют в случае наличия требований для процедур поддержания целостности функционирования ТДС.

Цель OЕ1. Лица, ответственные за эксплуатацию ТДС, должны обеспечить использование следующих сервисов проверки процедур:

a) генерации сертификатов (с тем, чтобы гарантировать то, что неправильные данные не помещены в сертификат);

b) верификации сертификата (если необходимо обеспечить информирование подписчиков ТДС о положительном результате верификации сертификата).

Цель ОЕ2. Лица, ответственные за эксплуатацию ТДС, должны обеспечить наличие надлежащих процедур аутентификации подписчиков ТДС и (при необходимости) третьих лиц.

Цель ОЕ1 необходима для предотвращения компрометации ТДС в результате выпуска ненадлежащих (недостоверных) сертификатов.

Цель ОЕ2 необходима для того, чтобы, например, заархивированные секретные ключи (в целях восстановления ключей или создания резервных копий ключей) не были бы раскрыты лицам, которые не имеют на это права.

F.4 Требования безопасности информационных технологий

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

Первоначально выбирают ФТБ, непосредственно удовлетворяющие целям безопасности для ОО. Например, цель O1 требует, в том числе, возможности генерации сертификатов открытых ключей. Это требование может быть сформулировано на основе элемента FDP_DAU.2.1 компонента FDP_DAU.2 (аутентификация данных с идентификацией гаранта) следующим образом:

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

Примечание - Сертификаты открытых ключей должны быть сгенерированы в соответствии с определенным стандартом (например, Х.509).

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

ФТБ2. ФБО должны предоставить [ТДС] возможность верифицировать сертификаты открытых ключей и идентификатор того ТДС, который сгенерировал сертификат.

Примечание - Верификация сертификата должна включать, как минимум:

a) проверку цифровой подписи;

b) проверку срока действия;

c) проверку параметров аннулирования.

Цель безопасности O3 требует возможности генерации цифровых подписей как доказательство происхождения. Это обстоятельство ведет к использованию следующих ФТБ, определенных при помощи компонента FCO_NRO.1 (избирательное доказательство отправления):

ФТБ3. ФБО должны быть способны генерировать цифровые подписи [для передаваемой информации] при запросе [ТДС].

ФТБ4. ФБО должны быть способны связать [идентификационные признаки] отправителя информации и информации, к которой прилагается цифровая подпись.

ФТБ5. ФБО должны предоставить возможность проверки цифровых подписей ТДС при [назначение: ограничения на цифровую подпись].

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

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

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

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

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

Подходящий уровень выбирают, исходя из