Приложение B (справочное). Композиция (ACO)

Приложение B
(справочное)

Композиция (ACO)

Целью данного Приложения является объяснение принципов оценки композиции и критериев класса ACO. В данном Приложении не определяются критерии класса ASE; данное определение приведено в разделе 10.

B.1. Необходимость оценки составных ОО

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

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

Предполагается, что критерии класса ACO применимы в случае, если одна сущность ИТ зависит от другой для предоставления сервисов безопасности. Сущность, предоставляющая такие сервисы, называется "базовым компонентом", получающая сервисы - "зависимым компонентом". Такие взаимоотношения могут существовать в различных условиях. Например, приложение (зависимый компонент) может использовать сервисы, предоставляемые операционной системой (базовый компонент). Взаимоотношения могут быть и пиринговыми (равноправными), когда два связанных приложения могут быть запущены в общей операционной среде или на различных аппаратных платформах. Если один из равноправных пользователей/узлов сети предоставляет сервисы другому узлу/пользователю, то он считается базовым компонентом, тогда как получатель сервисов - зависимым. Если же пользователи/узлы сети взаимно предоставляют друг другу сервисы, они будут считаться базовыми компонентами для предоставляемых сервисов и зависимыми - для получаемых. Это потребует повтора компонентов ACO, причем к каждому из таких компонентов будут предъявляться требования как к базовому и одновременно как к зависимому компоненту.

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

Действия по оценке составного ОО могут проходить вместе с оценкой зависимых компонентов по двум причинам:

a) Экономический/деловой фактор - разработчик независимых компонентов будет или спонсировать действия по оценке составного ОО, или поддерживать эти действия, так как такая оценка комплектуется оценкой зависимых компонентов, требуемой для действий по оценке составного ОО.

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

Свидетельство оценки зависимого компонента, предоставляемое оценщиком, является необходимым для проведения действий по оценке составного ОО. Единственный материал по оценке базового компонента, требуемый для проведения оценки составного ОО, это:

a) остаточные уязвимости базового компонента, выявленные во время его оценки. Это требуется для действий семейства ACO_VUL.

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

Предполагается, что оценка базового и зависимого компонента будет завершена ко времени получения заключительного решения по компонентам ACO.

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

B.2. Выполнение оценки ЗБ для составного ОО

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

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

ЗБ составного ОО может ссылаться на содержание ЗБ компонентов или разработчик ЗБ может повторить материал ЗБ компонентов в ЗБ составного ОО, предоставив обоснование тому, как ЗБ компонентов представлено в ЗБ составного ОО.

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

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

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

Следует, чтобы пакет требований класса ASE: "Оценка ЗБ", применяемый к ЗБ составного ОО, соответствовал пакету требований этого семейства, используемому при оценке ОО-компонентов.

Повторное использование результатов оценки ЗБ компонентов может применяться в случаях, когда ЗБ составного ОО напрямую ссылается на ЗБ компонента. Например, если ЗБ составного ОО ссылается на ЗБ компонента в части изложения ФТБ к нему, оценщик сможет понять, что требования по выполнению всех заданий и операций по выбору (как установлено в ASE_REQ.*.3C) были удовлетворены при оценке компонента.

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

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

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

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

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

"Рис 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) другие стрелки (серого цвета) = взаимодействия, обозначенные в данном критерии.

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

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

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

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

b) не-ФБО-a нуждается в сервисах, предоставляемых ФБО-b ("B" соединяется с "C"). Это тоже довольно простой случай (опять же, детализация "C" приводится в функциональных спецификациях компонента b), но имеющий небольшое значение;

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

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

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

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

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

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

b) "Зависимости зависимых компонентов" (ACO_REL) будет описывать взаимодействия A;

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

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

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

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

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

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