Рабочий пример: профиль защиты третьей доверенной стороны
F.1 Введение
В настоящем приложении поясняется применение руководства, содержащегося в разделах 7-13, посредством рабочего примера применительно к третьей доверенной стороне (ТДС). Рассматриваемый пример учитывает гибкость набора ФТБ, который зависит от типов сервисов, предоставляемых ТДС, например:
a) ТДС может обеспечивать или не обеспечивать сервисы конфиденциальности;
b) ТДС может предоставлять сервисы генерации ключей или предполагать, что подписчики ТДС выполняют действия по генерации ключей самостоятельно.
Исходя из вышеперечисленного, необходимо определить набор основных и дополнительных сервисов, предоставляемых ТДС.
Основные сервисы представляют собой минимум сервисов, обеспечиваемых ТДС, и относятся к регистрации подписчика, а также к выпуску, распределению, аннулированию и хранению в архиве сертификатов открытых ключей аутентификации.
Дополнительные сервисы ТДС включают в себя генерацию ключей, верификацию (проверку подлинности) сертификатов, управление сертификатами, восстановление ключей и создание резервных копий.
При делении сервисов на основные и дополнительные исходят из того, что подписчики ТДС могут иметь собственные прикладные программы для выполнения таких функций, как генерация ключей, генерация и верификация цифровой подписи и т.д.
Разработка ПЗ ТДС с учетом основных и дополнительных сервисов создает проблему совместимости со стандартами серии ИСО/МЭК 15408, так как последние не позволяют задавать спецификацию необязательных требований безопасности в ПЗ.
Альтернативный подход разработки ПЗ для каждой возможной комбинации услуг ТДС, учитывая множество возможных перестановок, представляется непрактичным.
Разрешение данной проблемы заключается в том, чтобы определить основной набор ФТБ в ПЗ, соответствующий основным сервисам ТДС.
Кроме того, для каждого дополнительного сервиса может быть определен функциональный пакет для идентификации дополнительных ФТБ, необходимых для поддержки этого сервиса.
Сформированный таким образом ПЗ ТДС может быть использован:
a) при разработке задания по безопасности, совместно с одним или более определенным функциональным пакетом в зависимости от услуг, предоставляемых ТДС;
b) как основа для подготовки других ПЗ, с учетом конкретного набора услуг ТДС; такой ПЗ следует формировать на основе комбинации основного набора ФТБ соответственно с одним или более определенным функциональным пакетом. Данный подход приводит к созданию "семейства" ПЗ ТДС.
F.2 Среда безопасности объекта оценки
F.2.1 Предположения безопасности
Для ТДС важно, чтобы формулировка предположений относительно безопасности ясно устанавливала возможности и границы ОО.
Желательно, чтобы прикладные программы подписчика ТДС, используемые для генерации цифровой подписи или для зашифровывания/расшифровывания информации, рассматривались как находящиеся вне рамок ОО.
Исходя из вышеизложенного, целесообразно выделить следующие два предположения.
Предположение A1. ТДС не будет сертифицировать (предоставлять поручительство за) открытый ключ, если не удовлетворяется требование к целостности алгоритма, по которому генерируется пара ключей.
Предположение A2. Подписчики имеют доступные технические средства, посредством которых они могут (при необходимости) генерировать собственные открытые/секретные ключи, генерировать и верифицировать цифровые подписи и верифицировать сертификаты открытых ключей.
Предположение А1 необходимо, так как сертификат, выпущенный ТДС, был бы девальвирован, если отсутствует доверие к выполнению подписчиком соответствующего алгоритма.
Предположение А2 необходимо для полноты предположений безопасности (хотя ТДС может поддерживать это предположение, предоставляя соответствующие дополнительные услуги). Таким образом, предположение А2 заключается в том, что описанные функциональные возможности обеспечиваются прикладными программами подписчика, не включенными в возможности ОО "ТДС".
F.2.2 Угрозы
Для ТДС защищаемые активы ИТ - это сертификаты открытых ключей, сгенерированные или сохраненные (например, архивированные) ТДС вместе с ключами, используемыми или сгенерированными ТДС.
Открытые ключи и сертификаты по своей природе не требуют защиты их конфиденциальности, однако требуют обеспечения их целостности и доступности. С другой стороны, секретные ключи требуют защиты от раскрытия. Такими ключами могут быть ключи, используемые ТДС для подписи сертификатов, или ключи подписчика, сгенерированные и сохраненные (для восстановления или создания резервных копий). Эти активы в конечном счете формируются на основе информации, которой обмениваются подписчики, чьи ключи и сертификаты используются для защиты. Сама информация находится вне управления ТДС, но ключи и сертификаты находятся в его пределах.