B.3 Взаимодействия между составляющими сущностями ИТ

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

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

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

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

Рисунок B.1 – Обобщенное представление базового компонента

Зависимый по отношению к базовому компонент определяется схожим образом: интерфейсы с внешними сущностями, определенные в ФТБ в составляющего ЗБ, относят к ИФБО и рассматриваются в семействе ADV_FSP.

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

Обобщенное представление зависимого компонента и интерфейсы показаны ниже на Рисунке B.2.

Рисунок B.2 – Обобщенное представление зависимого компонента

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

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

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

Рисунок B.3 – Обобщенное представление составного ОО

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

Возможные интерфейсы описываются подробнее на нижеследующей схеме (Рисунок B.4) и в сопровождающем ее тексте.

Рисунок B.4 – Интерфейсы составляющих компонентов

a) стрелки, входящие в "Зависимый компонент-a" (то есть A и B) = где компонент ожидает ответа от среды функционирования на запрос сервиса (ответ на запросы со стороны зависимого компонента к среде функционирования)

b) стрелки выходящие от "Базового компонента-b" стрелки (C и D) = интерфейсы сервисов, предоставляемых базовым компонентом среде функционирования;

c) пунктирные стрелки между компонентами = типы связи между парами интерфейсов;

d) другие стрелки (серого цвета) = интерфейсы, которые описываются в данных критериях.

Дальнейшее является упрощением, но объясняет, что следует принимать во внимание.

Имеются компонент а ("Зависимый компонент-а") и компонент b ("Базовый компонент-b"): стрелки, выходящие от ФБО-а являются сервисами, предоставляемыми ФБО-а и таким образом, являющиеся ИФБО(а), аналогично, стрелки выходящие от ФБО-b ("С") являются ИФБО(b). Все они детализируются в соответствующих функциональных спецификациях. Компонент-а требует сервисы от своей среды функционирования службы: те, которые необходимы для ФБО(а) помечены буквой "А", остальные (не относящиеся к ФБО-а) помечены буквой "В".

Когда компонент-а и компонент-b объединяются, существуют четыре возможных комбинации { сервисов, требуемых компонентом-а} и { сервисов, предоставляемых компонентом-b}, показанные пунктирными стрелками (типы связи между парами интерфейсов). Любой такой набор может существовать для конкретной композиции:

a) ФБО-а нуждается в сервисах, предоставляемых ФБО-b ("А" соединяется с "С") – тогда все достаточно просто: детализация "С" производится в функциональной спецификации компонента-b. В этом примере все интерфейсы следует определить в функциональных спецификациях компонента-b.

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

c) не-ФБО-а нуждается в сервисах, предоставляемых не-ФБО-b ("В" соединяется с "D") – нет детализации D, но нет и вовлечения безопасности при использовании этих интерфейсов, поэтому их необязательно рассматривать при оценке, хотя они вероятно являются вопросом интеграции для разработчика;

d) ФБО-а нуждается в сервисах, предоставляемых не-ФБО-b ("А" соединяется с "D") – это происходит, когда у компонента-а и компонента-b имеются разные понятия о том, что является «севисом безопасности». Возможно компонент-b не предъявляет требования по идентификации и аутентификации (в его ЗБ нет ФТБ класса FIA), но для компонента-а необходима аутентификация, предоставляемая его средой функционирования. Нет доступной подробной информации о интерфейсах "D" (они не являются ИФБО(b), потому и не включаются в функциональную спецификацию компонента-b).

Замечание: если существует взаимодействие, описанное выше в подпункте d), тогда ФБО составного ОО будет представлять собой ФБО-а + ФБО-b + Не ФБО-b. В иных случаях ФБО составного ОО будет ФБО-а + ФБО-b.

Типы интерфейсов 2 и 4 на рис. B.4 несущественны непосредственно для оценки составного ОО.

Интерфейсы типов 1 и 3 будут рассмотрены в рамках применения трбований различных семейств:

a) в семействе "Функциональная спецификация" (ADV_FSP) (для компонента-b) будут описываться интерфейсы C;

b) в семействе "Доверие к зависимому компоненту" (ACO_REL) будут описываться интерфейсы А;

c) в семействе "Свидетельство разработки" (ACO_DEV) будут описываться интерфейсы С для соединения типа 1 и интерфейсы D для соединения типа 3.

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

Однако оценка СУБД не требует каких-либо свидетельств в отношении зависимости СУБД от ОС. В ЗБ для СУБД наиболее вероятно будут изложены предположения относительно ОС в его в подразделе "Предположения" и изложены цели безопасности ОС в подразделе " Среда функционирования". ЗБ для СУБД может даже приписывать эти цели для среды функционирования в терминах ФТБ для ОС. Однако для ОС не предусмотрена спецификация, которая отражала бы подробности функциональной спецификации, описание архитектуры или другие свидетельства класса ADV «Разработка», аналогичные, что и для СУБД. Необходимость в этом выполнит семейство "Доверие к зависимому компоненту" (ACO_REL).

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

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

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

Приложение C
(справочное)
Перекрестные ссылки между компонентами доверия

Зависимости между компонентами, приведенные в разделах 8-18, являются прямыми зависимостями между компонентами доверия.

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

Таблица C.1 Таблица зависимостей класса ACO: Композиция

Таблица C.2 – Таблица зависимостей класса ADV: Разработка

Таблица C.3 – Таблица зависимостей класса AGD: Руководства

Таблица C.4 Таблица зависимостей класса ALC: Поддержка жизненного цикла

Таблица C.5 Таблица зависимостей класса APE: Оценка профиля защиты

Таблица C.6 - Таблица зависимостей класса ASE: Оценка задания по безопасности

Таблица C.7 - Таблица зависимостей класса ATE: Тестирование

Таблица C.8 - Таблица зависимостей класса AVA: Оценка уязвимостей

Приложение D
(справочное)
Перекрестные ссылки ПЗ и компонентов доверия

В таблице D.1 приводится взаимосвязь между ПЗ и семействами и компонентами класса APE.

Таблица D.1. Краткий Обзор доверия ПЗ

Приложение E
(справочное)
Перекрестные ссылки ОУД и компонентов доверия

Взаимосвязь между оценочными уровнями доверия и классами, семействами и компонентами доверия приведена в таблице E.1.

Таблица E.1. Обзор оценочных уровней доверия

Приложение F

(справочное)

Перекрестные ссылки между СПД и компонентами доверия

Таблица F.1 описывает связи между компонентами уровней доверия и классами, семействами и компонентами доверия.

Таблица F.1 Обзор составных уровней доверия

Приложение ДА
(справочное)
Сведения о соответствии ссылочных международных стандартов ссылочным национальным стандартам Российской Федерации

Таблица ДА.2. Соответствие ссылочных международных стандартов ссылочным национальным стандартам Российской Федерации

Библиография

Данная библиография содержит ссылки на материалы и стандарты, которые могут оказаться полезными для пользователя ИСО/МЭК 18045. При отсутствии в ссылке указания даты пользователю рекомендовано использовать последнюю редакцию документа.

Стандарты и руководства ИСО/МЭК

[1] ISO/IEC 15292, Information technology — Security techniques — Protection Profile registration procedures.

[2] ISO/IEC 15443 (all parts), Information technology — Security techniques — A framework for IT security assurance.

[3] ISO/IEC 15446, Information technology — Security techniques — Guide for the production of Protection Profiles and Security Targets.

[4] ISO/IEC 19790, Information technology — Security techniques — Security requirements for cryptographic modules.

[5] ISO/IEC 19791, Information technology — Security techniques — Security assessment of operational systems.

[6] ISO/IEC 27001, Information technology — Security techniques — Information security management systems — Requirements.

[7] ISO/IEC 27002, Information technology — Security techniques — Code of practice for information security management.