AVA_VAN.5.4E
AVA_VAN.5.3E
AVA_VAN.5.2E
AVA_VAN.5.1E
Элементы действий оценщика
AVA_VAN.5.1C
Элементы содержания и представления
AVA_VAN.5.1D
Элементы действий разработчика
Цели
AVA_VAN.5 Расширенный методический анализ уязвимостей
Зависимости: ADV_ARC.1 "Описание архитектуры безопасности"
ADV_FSP.4 " Полная функциональная спецификация"
ADV_TDS.3 " Базовый модульный проект"
ADV_IMP.1 "Представление реализации ФБО"
AGD_OPE.1 "Руководство пользователя по эксплуатации"
AGD_PRE.1 "Подготовительные процедуры"
ATE_DPT.1 "Тестирование: базовый проект"
Методический анализ уязвимостей проводится оценщиком с целью установить наличие потенциальных уязвимостей.
Оценщик проводит тестирование проникновения, чтобы подтвердить, что потенциальные уязвимости не могут быть использованы в среде функционирования ОО. Тестирование проникновения проводится оценщиком с использованием высокого потенциала нападения.
Разработчик должен представить ОО для тестирования.
ОО должен быть при4годен для тестирования.
Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
Оценщик должен выполнить исследование общедоступных источников с целью определения потенциальных уязвимостей ОО.
Оценщик должен провести независимый методический анализ уязвимостей ОО с использованием руководств, функциональной спецификации, проекта ОО, описания архитектуры безопасности и представления реализации с целью определения потенциальных уязвимостей ОО.
Оценщик должен провести тестирование проникновения, основанное на определенных потенциальных уязвимостях, чтобы сделать заключение о том, что ОО устойчив к атакам злоумышленников с высоким потенциалом нападения.
13 Класс ACO: Композиция
Класс ACO: "Композиция" включает пять семейств. Эти семейства определяют требования доверия, которые разрабатываются для обеспечения уверенности, что составной ОО будет функционировать в безопасном режиме, основываясь на функциональных возможностях по безопасности, предоставляемые ранее оцененными программными, программно-аппаратными и аппаратными компонентами.
Композиция включает два или более объектов ИТ, успешно прошедших оценку в соответствии с требованиями пакетов доверия настоящего стандарта ОК (базовые компоненты и зависимые компоненты, см. Приложение B) и объединяются для применения без дальнейшей разработки какого-либо объекта ИТ. Разработка дополнительных объектов ИТ не предусматривается (сущностей, не подвергавшихся ранее оценке составляющих компонентов). Составной ОО образует новый вид продукта, который может быть установлен и интегрирован в любую конкретную среду, соответствующую целям данной среды.
Подобный подход не предоставляет альтернативную оценку составляющих. Композиция в рамках класса ACO предоставляет интегратору составного ОО метод, который может быть использован как альтернатива другим уровням доверия, определенным настоящим стандартом, с целью получения уверенности в безопасности ОО, составленном из двух или более успешно оцененных компонентов без повторной оценки объединенных ФБО (в рамках класса ACO интегратор составного ОО называется "разработчиком", полностью ссылаясь на разработчика базовых или зависимых компонентов).
Составные пакеты доверия, как определено в разделах 8 и 6.3, являются шкалой доверия для составных ОО. Такая шкала доверия требуется в дополнение к ОУД потому что, чтобы совместить компоненты, прошедшие оценку по ОУД, и получить итоговый уровень доверия ОУД, все ТДБ в ОУД должны быть применены к составному ОО. Хотя повторное использование может быть определено по результатам оценки составляющих ОО, часто имеются дополнительные аспекты компонентов, которые должны быть рассмотрены в составном ОО, как описано в Приложении B.3. Так как в процесс оценки составного ОО вовлечены разные стороны, обычно не представляется возможным получить все необходимые свидетельства, касающиеся всех таких дополнительных аспектов компонентов для применения соответствующего ОУД. Следовательно, СоПД определены для рассмотрения проблемы объединения оцененных компонентов и получения значимого результата. Этот вопрос освещается далее в Приложении B.
 |
Рисунок 16 – Взаимосвязь семейств класса ACO и взаимодействие компонентов
Обычно в составном ОО один компонент основывается на сервисах, предоставляемых другим компонентом. Компонент, запрашивающий некоторые сервисы, называется зависимым компонентом, а компонент, предоставляющий сервисы, называется базовым компонентом. Эти взаимодействия и их отличие рассматриваются далее в Приложении B. Допускается случай, когда разработчик зависимого компонента содействует оценке составного ОО в той или иной степени (как разработчик, спонсор или лицо, оказывающее содействие и предоставляющее необходимые свидетельства оценки зависимых компонентов). Компоненты класса ACO «Композиция», входящие в составные пакеты доверия (СоПД), не следует использовать в качестве дополнений к оценке составляющих ОО, т.к. это не обеспечит значимого доверия к компоненту.
Семейства класса ACO при оценке составляющего ОО взаимодействуют аналогичным образом с классами ADV «Разработка», ATE «Тестирование» и AVA «Оценка уязвимостей» и, следовательно, используют спецификации требований этих классов, где это применимо. Однако существуют несколько пунктов, специфичных при оценке составного ОО. Для установления взаимодействий между компонентами и определения любых отклонений от оценок компонентов, определяются зависимости, которые имеет зависимый компонент в отношении базового компонента (ACO_REL). Такая зависимость от базового компонента определяется в терминах интерфейсов, через которые зависимые компоненты запрашивают сервисы для обеспечения выполнения ФТБ зависимого компонента. Интерфейсы, а на более высоких уровнях обеспечивающие режимы функционирования, предоставляемые базовымкомпонентом в ответ на запросы сервисов, рассматриваются в семействе ACO_DEV «Свидетельство разработки». Семейство ACO_DEV «Свидетельство разработки» основывается на семействе ADV_TDS «Проект ОО», так как на простейшем уровне ФБО каждого компонента можно представить в виде подсистемы составного ОО, где дополнительные для каждого компонента части рассматриваются как дополнительные подсистемы. Поэтому интерфейсы между компонентами представляются как взаимодействия между подсистемами при оценке составляющего ОО.
Возможен случай, когда интерфейсы и описания обеспечивающих режимов функционирования, предоставленные для семейства ACO_DEV, могут быть неполными. Это выявляется в процессе обоснования композиции ACO_COR. Семейство ACO_COR использует выходные данные семейств ACO_REL «Доверие к зависимому компоненту» и ACO_DEV «Свидетельства разработки» и определяет, используются ли компоненты в конфигурации, прошедшей оценку, а также определяет имеются ли неполные спецификации, которые впоследствии рассматриваются как входные данные для действий тестирования (ACO_CTT «Тестирование составного ОО») и анализа уязвимостей (ACO_VUL «Анализ уязвимостей композиции») составного ОО.
Тестирование компонентов составного ОО проводится с целью вынесения заключения о том, демонстрирует ли составной ОО ожидаемый режим функционирования, определенный в ФТБ составного ОО, и демонстрирует ли он на более высоких уровнях представления совместимость интерфейсов между компонентами составного ОО.
При анализе уязвимостей составного ОО используются выходные данные оценки анализа уязвимости компонентов. При анализе уязвимостей составного ОО рассматриваются любые остаточные уязвимости от оценки компонентов, чтобы сделать заключение, что эти остаточные уязвимости не применимы к составному ОО. Исследование общедоступной информации, относящейся к компонентам, также проводится для определения любых проблем, о которых были сообщения в отношении компонентов после завершения соответствующих оценок.
Взаимодействие семейств класса ACO «Композиция» отображено ниже, на рисунке 17. Сплошными стрелками показаны семейства, где свидетельства и понимание, полученные для одного семейства, переходят к следующему действию, пунктирными стрелками показано, где действие явно соотносится с ФТБ составного ОО, как описано выше.
 |
Рисунок 17 – Связь между семействами ACO
Дальнейшее рассмотрение определения и взаимодействий в рамках составного ОО содержится в Приложении B.
На рисунке 18 показаны семейства, входящие в состав данного класса, и иерархия компонентов семейств.
Рисунок 18 – ACO: декомпозиция класса "Композиция"