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

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

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

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

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

ФТБ8 сформулировано на основе элемента FCS_CKM.3.1 компонента FCS_CKM.3 "Доступ к криптографическим ключам" путем выполнения соответствующих операций назначения:

- тип доступа к криптографическим ключам - восстановление ключей;

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

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

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

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

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

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

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

Незначительная модификация ФТБ9 может расширить возможности подписчиков ТДС по проверке сертификатов подобно тому, как это выполняется ТДС.

F.4.2 Требования доверия к безопасности объекта оценки

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

F.4.3 Требования безопасности для ИТ-среды

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

F.5 Обоснование профиля защиты

F.5.1 Обоснование целей безопасности

Демонстрация соответствия целей безопасности угрозам может быть выполнена:

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

b) обоснованием того, что цели безопасности противостоят угрозам.

Ниже приведен пример обоснования целей безопасности.

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

F.5.2 Обоснование функциональных требований безопасности

Демонстрацию соответствия ФТБ целям безопасности для ОО можно представить:

a) в виде таблицы, показывающей, какие ФТБ каким целям безопасности удовлетворяют (например, ФТБ3-4 и ФТБ7 соответствуют цели безопасности O3), при этом необходимо обеспечить соответствие каждого ФТБ, по крайней мере, одной цели безопасности;

b) в виде обоснования соответствия ФТБ целям безопасности.

Ниже приведен пример обоснования ФТБ.

Цель O3 удовлетворяет ФТБ3-4 и ФТБ7, обеспечивающим функциональные возможности генерации цифровой подписи.

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

Анализ зависимостей компонентов ФТБ можно представить в виде таблицы.

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

Ниже приведены примеры демонстрации взаимной поддержки требований безопасности:

a) ФТБ 6 обеспечивает безопасную генерацию ключей ТДС и поэтому поддерживает те ФТБ, которые полагаются на использование этих ключей: ФТБ1, ФТБ2;

b) ФТБ3 - 4, 7 обеспечивают сервис цифровой подписи и поэтому поддерживают те ФТБ, которые полагаются на генерацию цифровых подписей: ФТБ1;

c) ФТБ4 - 5, 7 обеспечивают сервис проверки цифровой подписи и поэтому поддерживают те ФТБ, которые относятся к проверке цифровой подписи: ФТБ2.

F.5.3 Обоснование требований доверия к безопасности

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