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

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

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

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

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

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

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

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

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

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

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

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

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

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