Приложение С (обязательное). Требования доверия к безопасности автоматизированной системы

Приложение С
(обязательное)

Требования
доверия к безопасности автоматизированной системы

С.1 Введение

В настоящем приложении определены дополнительные требования доверия к безопасности автоматизированных систем, кроме требований ИСО/МЭК 15408-3. ИСО/МЭК 15408-3 использован в качестве основы для структуры компонентов этих систем.

Доверие к безопасности можно рассматривать в двух аспектах - корректность и эффективность. Корректность означает правильность внедрения механизмов безопасности, их функционирования в соответствии со спецификациями безопасности и поддержания доступности услуг по обеспечению безопасности. Эффективность означает, что механизмы безопасности противодействуют угрозам и уязвимостям, направленным против безопасности, и предотвращают такие несанкционированные процессы, как обход механизмов безопасности или несанкционированное вмешательство в работу этих механизмов. Доверие к безопасности можно достигать посредством действий на всех стадиях жизненного цикла системы. Доверие к безопасности автоматизированных систем приведено в таблице С.1.

Как корректность, так и эффективность можно оценить путем оценивания безопасности. Кроме того, может потребоваться принятие во внимание других форм доверия, таких как доверие, связанное с репутацией разработчика системы, и доверие, достигнутое в результате завершения использованных процессов разработки системы. Дополнительную информацию по этой теме см. в ИСО/МЭК ТО 15443 [7].

Таблица С.1 - Доверие к безопасности автоматизированных систем

Фактор	Этап жизненного цикла	Цель доверия	Класс доверия/семейство	Действие по оценке
Эффективность	Разработка/ интеграция	Противодействие рискам. Требования безопасности, указанные в задании по безопасности системы, эффективны при снижении неприемлемых рисков до допустимого уровня	Оценка ЗБС/ПЗС (AST/ASP)	В целях безопасности все идентифицированные риски должны рассматриваться как неприемлемые. Требования безопасности должны соответствовать целям безопасности. Защитные меры противодействия должны соответствовать спецификации СОО
Эффективность	Разработка/ интеграция	Архитектура автоматизированной системы Защитные меры противодействия подсистем, компонентов и т.д. работают вместе для реализации необходимых характеристик безопасности общей системы	Описание архитектуры автоматизированной системы (ASD_SAD). Конструкция подсистемы (ASD_SSD). Конструкция компонента (ASD_CMP). Представления реализации (ASDJMP) Интерфейсы безопасности (ASD_IFS) Концепция безопасности функционирования (ASD_CON)	Защитные меры противодействия должны работать эффективно совместно с другими мерами противодействия
Эффективность	Разработка/ интеграция	Безопасная среда разработки	Меры обеспечения безопасности и их проверка в среде разработки (AOL_DVS)	Меры обеспечения безопасности для среды разработки должны быть подтверждены
	Установка	Надежность механизмов безопасности. Надежность механизмов безопасности эффективна для системы	Анализ уязвимостей (AOV_VLA)	Необходимо проводить анализ уязвимостей, а уязвимости не должны использоваться предполагаемой потенциальной атакой. Необходимо проводить испытание на проникновение, и проблем с безопасностью быть не должно
	Установка	Обучение в области коммуникации и осведомленности. Эффективное обучение соответствующего персонала ролям и процедурам и передача ему этих ролей	Подтверждение коммуникации и осведомленности (ASI_СММ, ASI_AWA)	Коммуникация и осведомленность должны быть подтверждены записями и опросами
	Функционирование	Мониторинг защитных мер противодействия. Для демонстрации должного функционирования защитных мер противодействия собираются контрольные журналы и записи мониторинга	Обнаружение незащищенного состояния (AOV_MSU). Проверка работы ФБС (AOD_ADM, AOD_USR, AOD_OCD, ASI_AWA, ASI_CMM, ASO_RCD, ASO_VER)	Необходимо подтвердить должное функционирование защитных мер противодействия
	Функционирование	Проверка Подтверждено что риски, которым надо оказать противодействие, не обнаружены, и меры обеспечения безопасности функционируют должным образом		Необходимо подтвердить с помощью контрольных журналов и опросов, что неприемлемые риски не обнаружены
	Модификация	Регрессионное тестирование. Меры обеспечения безопасности продолжают работать должным образом	Регрессионное тестирование (AOT_REG)	Обнаруженные проблемы безопасности должны исследоваться, и результаты возвращаться
	Модификация	Испытание на проникновение. Изменения в системе не нарушают область действия мер обеспечения безопасности	Испытание на проникновение (AOV_VLA). Испытание на наличие незащищенных состояний (AOV_MSU)	Обнаруженные проблемы безопасности должны исследоваться, и результаты возвращаться
Правильность	Разработка/ интеграция	Соответствие между рисками безопасности и требованиями безопасности, а также требованиями безопасности и защитными мерами противодействия. Требования безопасности относятся ко всем неприемлемым рискам. Защитные меры противодействия соответствуют всем требованиям безопасности	Оценка ЗБС/ПЗС (AST/ASP)	Цели безопасности должны учитывать все риски, определенные как неприемлемые. Требования безопасности должны соответствовать целям безопасности. Защитные меры противодействия должны соответствовать спецификации СОО
		Управление конфигурацией. Управление элементами конфигурации защитных мер противодействия осуществляется правильно	Конфигурация (AOD_OCD)	Элементами конфигурации необходимо управлять и применять их в системе
		Соответствие проектно-исследовательским разработкам. Защитные меры противодействия реализуются правильно. Защитные меры противодействия -> назначение -> внедрение	Описание архитектуры автоматизированной системы (ASD_SAD). Конструкция подсистем (ASD_SSD). Конструкция компонентов (FSD_CMP). Представления внедрения (ASD_IMP). Интерфейсы безопасности (ASD_IFS). Концепция безопасности операций (ASD_CON). Испытание (АОТ)	Защитные меры противодействия должны реализовываться без несанкционированных модификаций, дополнений или исключений
		Описание руководств. Безопасные операции описаны в руководстве правильно	Описание (AOD_ADM, AOD_USR)	Функционирование защитных мер противодействия должны быть описаны достаточно подробно
	Установка	Соответствие. Организационные меры безопасности соответствуют требованиям безопасности	Изучение руководств (AOV_MSU)	Руководства должны быть понятными и полными
	Установка	Авторизация. Установка организационных мер обеспечения безопасности разрешена санкционированным лицом	(Отсутствует)	(Отсутствует)
Правильность	Установка	Конфигурация. Компоненты и подсистемы сконфигурированы правильно	Конфигурация (АОС). Испытание (АОТ)	Необходимо проверить конфигурацию компонентов и подсистем и функционирование мер обеспечения безопасности
	Установка	Пуск. Пуск СОО выполняется правильно	Установка и пуск (ASI_SIC)	Необходимо подтвердить правильность установки и пуска
	Функционирование	Мониторинг защитных мер противодействия. Защитные меры противодействия выполняются правильно	Мониторинг (ASO_MON)	Необходимо проверить следы аудита и записи мониторинга доступа к активам и их использования
	Функционирование	Проверка. Подтверждено, что риски, которым надо оказать противодействие, не обнаружены, а меры обеспечения безопасности функционируют должным образом	Проверка конфигурации (АОС_ОВМ). Проверка среды эксплуатации (АОС_ЕСР, АОС_РРС, AOC_NCP). Проверка безопасной установки (AOC_SIC). Проверка записей (ASO_RCD). Независимая проверка (ASO_VER)	Необходимо проверить меры обеспечения безопасности
	Модификация	Проверка проекта. Подтверждено, что модификации не сделали недействительными другие части проекта. Регрессионное тестирование. Подтверждено должное функционирование измененных мер обеспечения безопасности	Проверка проекта (AOD_GVR, FSD_GVR). Регрессионное тестирование (AOT_REG)	Необходимо проанализировать изменения в проекте. Необходимо исследовать обнаруженные проблемы безопасности и возвратить результаты

Критерии оценки по ИСО/МЭК 15408-3 содержат многие аспекты доверия к безопасности автоматизированных систем. Однако для некоторых других аспектов доверия к безопасности автоматизированных систем требуются дополнительные критерии.

В настоящем приложении определены новые классы требований доверия. Ими являются:

a) оценка ПЗС (ASP); специфицирует требования к оценке профилей защиты для АС;

b) оценка ЗБС (ASS); специфицирует требования к оценке заданий по безопасности для АС;

c) руководства для автоматизированных систем (AOD); специфицирует требования к оценке руководств для автоматизированных систем;

d) документация по проектированию архитектуры автоматизированных систем и конфигурационная документация (ASD); специфицирует требования к оценке документации по конфигурированию и проектированию автоматизированных систем;

e) управление конфигурацией автоматизированных систем (АОС); специфицирует требования к оценке управления конфигурацией автоматизированных систем;

f) тестирование автоматизированных систем (АОТ); специфицирует требования к оценке тестирования автоматизированных систем;

g) анализ уязвимостей автоматизированных систем (AOV); специфицирует требования к оценке анализа уязвимостей автоматизированных систем;

h) поддержка жизненного цикла автоматизированных систем (AOL); специфицирует требования к оценке поддержки жизненного цикла автоматизированных систем;

i) безопасная установка системы (ASL); специфицирует требования к оценке безопасной установки системы;

j) регистрация и запись в автоматизированных системах (ASO); специфицирует требования к оценке регистрации и мониторинга организационных мер безопасности.

Имеются новые классы доверия для оценки профилей защиты системы (ПЗС) и заданий по безопасности системы (ЗБС), поскольку содержимое ПЗС или ЗБС расширено из содержимого ПЗ или ЗБ. Другие новые классы относятся к дополнительным требованиям доверия к оценке автоматизированных систем.

Взаимосвязь между дополнительными требованиями доверия, определенными в данном приложении, и этапами жизненного цикла автоматизированных систем приведены в таблице С.2

Таблица С.2 - Требования доверия и жизненный цикл автоматизированных систем

Жизненный цикл	Требование доверия
Разработка/интеграция	FOD_OCD.1	Описание конфигурации в руководстве по конфигурации
	AOD_ADM.1	Описание связанных с администраторами ФБС в руководстве для администраторов
	AOD_USR.1	Описание связанных с пользователями ФБС в Руководстве для пользователей
	ASD_SAD.1	Описание архитектуры
	ASD_IFS.1	Описание внешних интерфейсов
	ASD_SSD.1	Описание структуры подсистем
	ASD_CMP.1	Описание структуры базисного элемента (примитива)
	ASD_IMP.1	Получение конкретного представления внедрения
	ASD_CON.1	Концепция безопасности функционирования
	AOL_DVS.1	Меры обеспечения безопасности для среды разработки
	AOT_FUN.1	Функциональная проверка ФБС
	AOT_COV.1	Покрытие тестами для ФБС
	AOT_COV.2	Завершенность покрытия тестами для ФБС
	AOT_DPT.1	Глубина испытания для спецификации интерфейса
	AOT_DPT.2	Глубина испытания для проекта подсистем
	AOT_DPT.3	Глубина испытания для проекта компонентов
	AOT_DPT.4	Глубина испытания для представления реализации
	AOL_DVS.2	Проверка мер обеспечения безопасности для среды разработки
Установка	AOC_OBM.1	Управление конфигурацией
	AOC_ECP.1	Идентификация оцененных продуктов
	AOC_PPC.1	Идентификация соответствия ПЗ
	AOC_NPC.1	Новая оценка новых продуктов
	AOT_FUN.1	Функциональное испытание ФБС
	AOT_COV.1	Покрытие тестами для ФБС
	AOT_COV.2	Завершенность покрытия тестами для ФБС
	AOT_DPT.1	Глубина испытания для спецификации интерфейса
	AOT_DPT.2	Глубина испытания для проекта подсистем
	AOT_DPT.3	Глубина испытания для проекта компонентов
	AOT_DPT.4	Глубина испытания для представления реализации
	AOT_IND.1-3	Независимое тестирование
	AOV_MSU.1	Проверка руководств автоматизированной системы
	AOV_VLA.1-4	Испытание на проникновение
	ASI_AWA.1	Повышение осведомленности
	ASI_CMM.1	Передача информации о ФБС соответствующему персоналу
	ASI_SIC.1	Безопасная установка и пуск СОО
Функционирование	AOD_OCD.2	Проверка спецификаций в руководстве по конфигурациям
	AOD_ADM.2	Проверка проводимости ФБС в руководстве для администраторов
	AOD_USR.2	Проверка проводимости ФБС в руководстве для пользователей
	AOC_OBM.2	Проверка управления конфигурациями
	AOC_ECR.2	Проверка среды эксплуатации для оцененных продуктов
	AOC_PPC.2	Проверка среды эксплуатации для заявленного соответствия ПЗ
	AOC_NCP.2	Проверка среды эксплуатации для новых оцененных продуктов
	AOV_MSU.2	Обнаружение незащищенных рабочих состояний и восстановлений
	ASI_AWA.2	Проверка повышения уровня осведомленности
	ASI_CMM.2	Проверка передачи информации о ФБС персоналу
	ASL_SIC.2	Проверка безопасной установки и пуска
	ASO_RCD.1-2	Проверка рабочих записей
	ASO_VER.1-2	Проверка организационных мер безопасности
	ASO_MON.1	Мониторинг управления для ФБС
	ASO_MON.2	Независимая проверка мониторинга управления
Модификация	AOD_GVR/1	Проверка руководств
	ASD_GVR.1	Проверка проекта
	AOT_REG.1	Регрессивное испытание
	AOV_MSU.2	Анализ и испытание незащищенных состояний
	AOV_VLA.1-4	Испытание на проникновение

Настоящее приложение содержит два существенных отличия от ИСО/МЭК 15408-3 "элементы действий разработчика" были переименованы в "элементы действий разработчика/интегратора", чтобы показать, что автоматизированная система может быть составлена системным интегратором, который отличается от разработчика компонентов и продуктов, используемых в системе, и оба они могут сотрудничать в получении и доставке необходимых свидетельств. В некоторых случаях менеджеры автоматизированной системы отвечают за получение свидетельств, поэтому в этих семействах элементы действий определены как действия управления.

Зависимости между компонентами доверия представлены в таблицах С.3 - С.5. По причине независимого проведения оценок ПЗС, ЗБС и СОО были использованы три таблицы, и поэтому между каждым набором не может быть взаимозависимостей. Каждый из компонентов, являющийся зависимостью какого-либо компонента доверия, находится в соответствующем столбце таблицы. Каждый компонент доверия с зависимостями находится в соответствующей строке. Значение в таблице указывает на прямую потребность маркировочного компонента строки в маркировочном компоненте колонки (знак "X") или косвенную потребность (знак "-").

Таблица С.3 - Зависимости доверия к ПЗС

	ASP_INT.1	ASP_ECD.1	ASP_SPD.1	ASP_OBJ.1	ASP_REQ.1	ASP_DMP.1	ASP_DMO.1	ASP_DMR.1
ASP_CCL.1	X	X	X	X	X
ASP_OBJ.1			X
FSP_REQ.1		X
ASP_REQ.2		X	-	X
ASP_DMI.1	X
ASP_DMC.1	-	-				X	X	X
ASP_DMO.1	X					X
ASP_DMR.1		X
ASP_DMR.2	-	X					X

Таблица С.4 - Зависимости доверия к ЗБС

	ASS_INT.1	ASS_ECD.1	ASS_SPD.1	ASS_OBJ.1	ASS_REQ.1	ASS_DMI.1	ASS_DMP.1	ASS_DMO.1	ASS_DMR.1
ASS_CCL.1	X	X	X	X	X
ASS_OBJ.1			X
ASS_REQ.1		X
ASS_REQ.2		X	-	X
ASS_TSS.1	X	-			X
ASS_DMI.1	X
ASS_DMC.1	-	-					X	X	X
ASS_DMО.1	X						X
ASS_DMR.1		X
ASS_DMR.2	-	X					-	X
ASS_DMS.1	-	-				X			X

Таблица С.5 - Зависимости доверия к СОО

	AOD_OCD.1	AOD_ADM.1	AOD_USR.1	ASD_SAD.1	ASD_IFS.1	ASD_SSD.1	ASD_CMP.1	ASD_IMP.1	ASD_CON.1	AOS_OBM.1	AOT_FUN.1
AOD_OCD.1/2				-	-	-	X		X
AOD_ADM.1/2				X
AOD_USR.1/2X				X
AOD_GVR.1	X	X	X		-	-	-		-
ASD_ТFS.1				X
ASD_SSD.1				X	X
ASD_CMP.1				-	X	X
ASD_IMP.1				-	-	-	X
ASD_CON.1				X
ASD_GVR.1				X	X	X	X		X
AOC_ECP.1/2										X
AOC_PPC.1/2										X
AOC_NCP.1/2										X
AOT_COV.1/2				-	X						X
AOT_DPT.1				-	X						X
AOT_DPT.2				-	X	X					X
AOT_DPT.3				-	X	X	X				X
AOT_DPT.4				-	X	X	X	X			X
AOT_IND.1		X	X	-	X
AOT_IND.2/3		X	X	-							X
AOV_MSU.1/2		X	X	-
AOV_VLA.1		X	X	-	X	X			X
AOV_VLA.1		X	X	-	X	X			X

C.2 Класс ASP: оценка профиля защиты системы

С.2.1 Введение

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

Ниже перечислены семейства в этом классе:

a) ASP_JNT: введение ПЗС;

b) ASP_CCL: утверждения о соответствии;

c) ASP_SPD: определение проблемы безопасности;

d) ASP_OBJ: цели безопасности;

e) ASP_ECD: определение компонентов расширения;

f) ASP_REQ: требования безопасности;

g) ASPP_DMI: введение для домена безопасности;

h) ASP_DMC: утверждения о соответствии домена безопасности;

i) ASP_DMP: определение проблемы безопасности домена безопасности;

j) ASP_DMO: цели безопасности домена безопасности;

k) ASP_DMR: требования безопасности домена безопасности.

С.2.2 Общая часть ПЗС

Следующие спецификации применимы к целому ПЗС. Спецификации для конкретных доменов должны описываться с помощью семейств доменов (см. С.2.9).

С.2.3 Введение ПЗС (ASP_INT)

С.2.3.1 Цели

Целью данного семейства является описание СОО в повествовательном виде.

Оценка введения ПЗС требуется для демонстрации правильной идентификации ПЗС и согласованности между собой краткого анализа СОО и спецификации доменной организации. Введения конкретных доменов безопасности определены в подразделе С.2.10 "Введение доменов безопасности".

С.2.3.2 ASP_INT. 1 Введение ПЗС

Зависимости: зависимости отсутствуют.

С.2.3.2.1 Элементы действий разработчика/интегратора

ASP_INT.1.1D Разработчик/интегратор должен обеспечит введение ПЗС.

С.2.3.2.2 Элементы содержания и представления свидетельств

ASP INT.1.1C Введение ПЗС должно содержать ссылку ПЗС, краткий анализ СОО и спецификацию доменной организации.

ASP_INT.1.2C Ссылка ПЗС должна однозначно идентифицировать ПЗС.

ASP_INT.1.3С В кратком обзоре СОО должны резюмироваться использование и основные характеристики безопасности СОО.

ASP_INT.1.4C Краткий обзор СОО должен идентифицировать тип СОО.

ASP_INT.1.5С Краткий обзор СОО должен идентифицировать взаимосвязь и интерфейсы, необходимые для СОО, с любыми внешними автоматизированными системами.

ASP_INT.1.6C В спецификации доменной организации должна описываться организация мандатных доменов безопасности и их идентификация, физическая сфера применения и границы каждого домена безопасности.

ASP_INT.1.7C Для каждого домена безопасности в спецификации должны описываться все услуги по обеспечению безопасности, предоставляемые этим доменом и доступные другим доменам, и все характеристики безопасности домена, задаваемые другим доменам.

С.2.3.2.3 Элементы действий оценщика

ASP_INT.1.1E Оценщик должен подтверждать соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

ASP_INT.1.2E Оценщик должен подтверждать совместимость краткого обзора СОО и спецификации доменной организации.

С.2.4 Утверждение соответствия (ASP_CCL)

С.2.4.1 Цели

Целью данного семейства является определение достоверности различных утверждений соответствия: утверждение соответствия стандартам серии ИСО/МЭК 15408, утверждение соответствия ПЗС, утверждение соответствия ПЗ и утверждение соответствия пакета требований. В утверждении соответствия стандартов серии ИСО/МЭК 15408 описывается версия ИСО/МЭК 15408, соответствие которой утверждается ПЗС и СОО, в утверждении ПЗ (если имеются) описывается, как ПЗС утверждает соответствие идентифицированным ПЗ, в утверждении пакета (если он имеется) описывается, как ПЗС утверждает соответствие с установленным пакетом, тогда как ПЗС идентифицирует ПЗС (если имеются), о соответствии которым утверждает ПЗС. Определяют достоверность утверждения ПЗС, утверждение ПЗ и пакета влекут за собой определение, четко ли идентифицированы все заявленные ПЗС, ПЗ и пакеты, полностью ли ПЗС содержит эти ПЗС, ПЗ и пакеты, и правильно ли выполнены все требования безопасности, выведенные из этих ПЗС, ПЗ и пакетов. Утверждения соответствия для конкретного домена безопасности определены в С.2.11 "Утверждение о соответствия домена безопасности".

С.2.4.2 ASP_CCL.1 Утверждения соответствия

Зависимости:

ASP_INT.1 Введение ПЗС;

ASP_SPD.1 Определение проблем безопасности;

ASP_OBJ.1. Цели безопасности;

ASP_ECD.1 Определение расширенных компонентов;

ASP_REQ.1 Установленные требования безопасности.

С.2.4.2.1 Элементы действий разработчика/интегратора

ASP_CCL.1.1D Разработчик/интегратор должен предоставить утверждение соответствия.

ASP_CCL.1.2D Разработчик/интегратор должен предоставить обоснование утверждения соответствия.

С.2.4.2.2 Элементы содержания и представления свидетельств

ASP_CCL.1.1С Утверждение соответствия должно содержать утверждение соответствия критериям, идентифицирующее версию ИСО/МЭК ТО 19791, соответствие которому утверждается в ПЗС.

ASP_CCL.1.2C В утверждении соответствия критериям должно быть описано функциональное соответствие ПЗС ИСО/МЭК ТО 19791 как функционально соответствующий ИСО/МЭК ТО 19791 или функционально расширенный по отношению к ИСО/МЭК ТО 19791.

ASP_CCL.1.3C В утверждении соответствия критериям должно быть описано соответствие доверия ПЗС ИСО/МЭК ТО 19791 в виде матрицы отображения доверия соответствующего ИСО/МЭК ТО 19791 или как доверие стандартов серии ИСО/МЭК 15408 с расширением по стандарту ИСО/МЭК ТО 19791.

ASP_CCL.1.4C Утверждение соответствия должно согласовываться с определением расширенных компонентов.

ASP_CCL.1.5C Утверждение соответствия должно идентифицировать все ПЗС, ПЗ и пакеты требований безопасности, соответствие которым утверждает ПЗС.

ASP_CCL.1.6C В утверждении соответствия должно быть описано любое соответствие ПЗС пакету или как полностью соответствующее, или как дополненное к пакету.

ASP_CCL.1.7C Обоснование утверждений соответствия должно демонстрировать согласование типа СОО с типом СОО в ПЗС.ПЗ и пакетах, о соответствии которым делается утверждение.

ASP_CCL.1.8C Обоснование утверждений соответствия должно демонстрировать согласование формулировки определения проблемы безопасности с формулировкой определения проблемы безопасности в ПЗС, ПЗ и пакетах, о соответствии которым делается утверждение.

ASP_CCL.1.9C Обоснование утверждений соответствия должно демонстрировать согласование формулировки целей с формулировкой целей в ПЗС, ПЗ и пакетах, о соответствии которым делается утверждение.

ASP_CCL.1.10C Обоснование утверждений соответствия должно демонстрировать согласование формулировки требований безопасности с формулировкой требований безопасности в ПЗС, ПЗ и пакетах, о соответствии которым делается утверждение.

ASP_CCL.1.11C Обоснование утверждений соответствия должно демонстрировать, что все операции, связанные с требованиями безопасности, которые были взяты из ПЗС, ПЗ или пакета, завершены в согласовании с соответствующими ПЗС, ПЗ или пакетом.

С.2.4.2.3 Элементы действий оценщика

ASP_CCL.1.1E Оценщик должен подтвердить, что предоставленная информация отвечает всем требованиям к содержанию и представлению свидетельств.

ASP_CCL.1.2E Оценщик должен подтвердить, что ПЗС удовлетворяет утверждению соответствия стандартам серии ИСО/МЭК 15408.

С.2.5 Определение проблем безопасности (ASP_SPD)

С.2.5.1 Цели

В данном подразделе ПЗС определяются проблемы безопасности, относящиеся к СОО, включая среду его разработки. Эти проблемы безопасности применимы к СОО в целом. Проблемы безопасности конкретного домена безопасности определены в подразделе С.2.12 "Определение проблем доменов безопасности". Оценка определения проблем безопасности нужна для демонстрации, что проблемы безопасности, предназначенные для рассмотрения СОО, включая его среду разработки, четко определены.

С.2.5.2 ASP_SPD.1 Определение проблем безопасности

Зависимости: зависимости отсутствуют.

С.2.5.2.1 Элементы действий разработчика/интегратора

ASP_SPD.1.1D Разработчик/интегратор должен обеспечивать определение проблем безопасности.

С.2.5.2.2 Элементы содержания и представления свидетельств

ASP_SPD.1.1C. В определении проблем безопасности должны быть указаны все риски, применимые к СОО. Каждый риск должен категорироваться как "приемлемый" или "неприемлемый".

ASP_SPD.1.2C Все неприемлемые риски должны быть описаны на основе угроз и уязвимостей. Каждая угроза должна описываться с точки зрения источника угрозы, актива и враждебного действия.

ASP_SPD.1.3C В определении проблем безопасности должны быть описаны ПБОр.

С.2.5.2.3 Элементы действий оценщика

ASP_SPD.1.1E Оценщик должен подтверждать соответствие поставленной информации всем требованиям к содержанию и представлению свидетельств.

ASP_SPD.1.2E Оценщик должен подтверждать внутреннюю непротиворечивость определения проблемы безопасности.

С.2.6 Цели безопасности (ASP_OBJ)

С.2.6.1 Цели

Целями безопасности является краткая формулировка намеченной реакции на проблему безопасности, определенную при помощи семейства ASP_SPD. Определенные цели безопасности в этой части применимы к СОО в целом. Цели безопасности для конкретного домена безопасности определены в подразделе С.2.13 "Цели безопасности домена безопасности". Оценка целей безопасности требуется для демонстрации того, что цели безопасности адекватно и полностью учитывают определение проблем безопасности, и распределение этой проблемы между СОО, средой ее разработки и внешними автоматизированными системами четко определено, и что цели безопасности внутренне согласованы.

С.2.6.2 ASP_OBJ.1 Цели безопасности

Зависимости: ASP_SPD.1 Определение проблемы безопасности.

С.2.6.2.1 Элементы действий разрботчика/интегратора

ASP_OBJ.1.1D Разработчик/интегратор должен предоставить формулировку целей безопасности.

ASP_OBJ.1.2D Разработчик/интегратор должен предоставить обоснование целей безопасности.

С.2.6.2.2 Элементы содержания и представления свидетельств

ASP_OBJ.1.1C В формулировке целей безопасности должны излагаться цели безопасности для СОО.

ASP_OBJ.1.2C В формулировке целей безопасности должны излагаться все цели безопасности, которым соответствуют внешние автоматизированные системы.

ASP_OBJ.1.3C В формулировке целей безопасности должны излагаться цели безопасности для среды разработки.

ASP_OBJ.1.4C В обосновании целей безопасности должна отслеживаться каждая цель безопасности для СОО обратно к рискам, которым противостоит эта цель безопасности, и ПБОр, которым соответствует эта цель безопасности.

ASP_OBJ.1.5C В обосновании целей безопасности должна отслеживаться каждая цель безопасности для внешних автоматизированных систем обратно к рискам, которым противостоит эта цель безопасности, и ПБОр, которым соответствует эта цель безопасности.

ASP_OBJ.1.6C В обосновании целей безопасности должна отслеживаться каждая цель безопасности для среды разработки обратно к рискам, которым противостоит эта цель безопасности, и ПБОр, которым соответствует эта цель безопасности.

ASP_OBJ.1.7C Обоснование целей безопасности должно демонстрировать противостояние целей безопасности всем неприемлемым рискам.

ASP_OBJ.1.8C Обоснование целей безопасности должно демонстрировать, что цели безопасности осуществляют все ПБОр.

С.2.6.2.3 Элементы действий оценщика

ASP_OBJ.1.1E Оценщик должен подтверждать соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

С.2.7 Определение расширенных компонентов (ASP_ECD)

С.2.7.1 Цели

Расширенные требования безопасности основаны не на компонентах стандартов серии ИСО/МЭК 15408 или настоящего стандарта, а на расширенных компонентах, определенных автором ПЗС. Оценка определения расширенных компонентов необходима для определения их ясности, однозначности и необходимости, т.е. для того, чтобы они не могли быть выражены с помощью существующих компонентов стандартов серии ИСО/МЭК 15408 или настоящего стандарта.

С.2.7.2 ASP_ECD.1 определение расширенных компонентов

Зависимости: зависимости отсутствуют.

С.2.7.2.1 Элементы действий разработчика/интегратора

ASP_ECD.1.1D Разработчик/интегратор должен предоставлять формулировку требований безопасности.

ASP_ECD.1.2D Разработчик/интегратор должен предоставлять определение расширенных компонентов.

С.2.7.2.2 Элементы содержания и представления свидетельств

ASP_ECD.1.1C В формулировке требований безопасности должны идентифицироваться все расширенные требования безопасности.

ASP_ECD.1.2C В определении расширенных компонентов должен определяться расширенный компонент для каждого расширенного требования безопасности.

ASP_ECD.1.3C В определении расширенных компонентов должно быть изложено, как каждый расширенный компонент связан с существующими компонентами, семействами и классами по стандартам серии ИСО/МЭК 15408.

ASP_ECD.1.4C В определении расширенных компонентов должны использоваться существующие компоненты, семейства, классы и методология по стандартам серии ИСО/МЭК 15408 в качестве модели для представления.

ASP_ECD.1.5C Расширенные компоненты должны состоять из измеримых и объективных элементов так, чтобы можно было продемонстрировать соответствие или несоответствие этим элементам.

С.2.7.2.3 Элементы действий оценщика

ASP_ECD.1.1E Оценщик должен подтверждать соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

ASP_ECD.1.2E Оценщик должен подтверждать, что ни один расширенный компонент не может быть ясно выражен с помощью существующих компонентов.

С.2.8 Требования безопасности (ASP_REQ)

С.2.8.1 Цели

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

С.2.8.2 Ранжирование компонентов

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

С.2.8.3 ASP_REQ.1 Заданные требования безопасности

Зависимости: ASP_REQ.1 Определение расширенных компонентов.

С.2.8.3.1 Элементы действий разработчика/интегратора

Зависимости: зависимости отсутствуют.

С.2.8.3.2 Элементы содержания и представления свидетельств

ASP_REQ.1.1C В формулировке требований безопасности должны быть описаны ФБС и ДБС.

ASP_REQ.1.2C В формулировке требований безопасности должны идентифицироваться все операции, связанные с требованиями безопасности.

ASP_REQ.1.3C Все операции должны выполняться правильно.

ASP_REQ.1.4C Каждая зависимость между требованиями безопасности должна быть или удовлетворена, или идентифицирована как "неудовлетворенная".

С.2.8.3.3 Элементы действий оценщика

ASP_REQ.1.1E Оценщик должен подтверждать соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

ASP_ REQ.1.2Е Оценщик должен подтверждать внутреннюю согласованность формулировки требований безопасности.

С.2.8.4 ASP_REQ.2 Производные требования безопасности

Являются иерархическими для: ASP_REQ.1 Установленные требования безопасности.

Зависимости:

ASP_OBJ.1 Цели безопасности;

ASP_ECD.1 Определение расширенных компонентов.

С.2.8.4.1 Элементы действий разработчика/интегратора

ASP_REQ.2.1D Разработчик/интегратор должен предоставить обоснование требований безопасности.

С.2.8.4.2 Содержание и представление элементов безопасности

ASP_REQ.2.1C В формулировке должны быть описаны ФБС и ДБС.

ASP_REQ.2.2C В формулировке требований безопасности должны идентифицироваться все операции, связанные с требованиями безопасности.

ASP_REQ.2.3C Все операции должны выполняться правильно.

ASP_REQ.2.4C Каждая зависимость между требованиями безопасности должна быть удовлетворена, или обоснование требований безопасности должно объяснять причину неудовлетворения зависимости.

ASP_REQ.2.5C Обоснование требований безопасности должно сопоставлять каждую ФБС с целями безопасности СОО.

ASP_REQ.2.6C Обоснование требований безопасности должно сопоставлять каждую ФБС с целями целей безопасности СОО или среды его разработки.

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

С.2.8.4.3 Элементы действий оценщика

ASP_REQ.2.1E Оценщик должен подтверждать соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

ASP_ REQ.2.2E Оценщик должен подтверждать внутреннюю согласованность формулировки требований безопасности.

С.2.9 Домены безопасности профиля защиты системы

Каждый домен безопасности ПЗС определяет проблемы безопасности, цели безопасности и требования безопасности, уникальные для этого конкретного домена безопасности.

В последующих разделах определяются семейства, применяющиеся для определения доменов безопасности внутри ПЗС.

С.2.10 Введение доменов безопасности (ASP_DMI)

С.2.10.1 Цели

Целью данного семейства является описание домена безопасности в повествовательной форме на трех уровнях абстракции, ссылка на домен безопасности, краткий обзор домена безопасности и описание домена безопасности.

С.2.10.2 ASP_DMI.1 Введение доменов безопасности

Зависимости: ASP_INT.1 Введение ПЗС.

С.2.10.2.1 Элементы действий разработчика/интегратора

ASP_DMI.1D Разработчик/интегратор должен обеспечить введение доменов безопасности.

С.2.10.2.2 Элементы содержания и представления свидетельств

ASP_DMI.1.1C Введение доменов безопасности должно содержать ссылку на домен безопасности, краткий обзор домена безопасности и описание домена безопасности.

ASP_DMI.1.2C Ссылка на домен безопасности должна однозначно идентифицировать домен безопасности.

ASP_DMI.1.1.3C Домен безопасности должен резюмировать использование и основные характеристики безопасности домена безопасности.

ASP_DMI.1.1.4C В описании домена безопасности должны быть изложены включенные в нее подсистемы и/или компоненты.

ASP_DMI.1.1.5C В описании домена безопасности должны быть изложены взаимосвязи и интерфейсы с другими доменами.

С.2.10.2.3 Элементы действий оценщика

ASP_DMI.1.1.E Оценщик должен подтверждать соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

ASP_DMI.1.2.E Оценщик должен подтверждать согласование ссылки на домен безопасности, краткий обзор домена безопасности и описаний доменов безопасности друг с другом и с введением ПЗС.

С.2.11 Утверждение соответствия для доменов безопасности (ASP_DMC)

С.2.11.1 Цели

Данная часть ПЗС определяет уникальные утверждения соответствия для доменов безопасности.

С.2.11.2 ASP_DMC1 Утверждения о соответствии

Зависимости:

ASP_DMP.1 Определение проблем безопасности доменов безопасности;

ASP_DMO.1 Цели безопасности доменов безопасности;

ASP_DMR.1 Установленные требования безопасности для доменов безопасности.

С.2.11.2.1 Элементы действий разработчика/интегратора

ASP_DMC.1.1D Разработчик/интегратор должен обеспечить утверждения соответствия домена безопасности.

ASP_DMC.1.2D Разработчик/интегратор должен обеспечить обоснование утверждений о соответствии.

С.2.11.2.2 Элементы содержания и представления свидетельств

ASP_DMC.1.1C В утверждении соответствия домена должны идентифицироваться все ПЗС, ПЗ и пакеты требований безопасности, о соответствии которым делается утверждение.

ASP_DMC.1.2C В утверждении соответствия домена должно быть описано любое соответствие домена пакету как соответствующее полностью или как дополнение к пакету.

ASP_DMC.1.3C Обоснование утверждения соответствия домена должно демонстрировать согласование типа СОО с типом СОО в ПЗС, ПЗ и пакетами, о соответствии которых делается утверждение.

ASP_DMC.1.4C Обоснование утверждения соответствия домена должно демонстрировать согласование формулировки определения проблем безопасности домена с формулировкой определения проблем безопасности с ПЗС, ПЗ и пакетами, о соответствии которым делается утверждение.

ASP_DMC.1.5C Обоснование утверждения соответствия домена должно демонстрировать согласование формулировки определения целей безопасности домена с формулировкой целей в ПЗС, ПЗ и пакетами, о соответствии которым делается утверждение.

ASP_DMC.1.6C Обоснование утверждения соответствия домена должно демонстрировать согласование формулировки определения целей безопасности домена с формулировкой целей в ПЗС, ПЗ и пакетами, о соответствии которым делается утверждение.

ASP_DMC.1.7С Обоснование утверждения соответствия домена должно демонстрировать завершение всех операций, связанных с требованиями безопасности, которые были взяты из ПЗС, ПЗ или пакетов, согласно соответствующим ПЗС, ПЗ или пакетам.

С.2.11.2.3 Элементы действий оценщика

ASP_DMC.1.1E Оценщик должен подтверждать соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

С.2.12 Определение проблем безопасности домена безопасности (ASP_DMP)

С.2.12.1 Цели

В данной части ПЗС определяются уникальные проблемы безопасности для домена безопасности.

ASP_DMP.1 Определение проблем безопасности домена безопасности.

Зависимости: зависимости отсутствуют.

С.2.12.2 Элементы действий разработчика/интегратора

ASP_DMP.1.1D Разработчик/интегратор должен обеспечить определение проблем безопасности домена.

С.2.12.3 Элементы содержания и представления свидетельств

ASP_DMP.1.1C В определении проблем безопасности домена должны быть приведены все уникальные риски, применимые к домену. Каждый риск должен категорироваться как "приемлемый" или "неприемлемый".

ASP_DMP.1.2C Все неприемлемые риски должны излагаться с точки зрения угроз и уязвимостей. Каждая угроза должна быть описана исходя из источника угрозы, актива и враждебного действия.

ASP_DMP.1.3C В определении проблем безопасности домена должны быть приведены уникальные ПБОР, применимые к домену.

С.2.12.4 Элементы действий оценщика

ASP_DMP.1.1E Оценщик должен подтверждать соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

ASP_DMP.1.2E Оценщик должен подтверждать внутреннюю согласованность определения проблем безопасности домена.

С.2.13 Цели безопасности домена безопасности (ASPDMO)

С.2.13.1 Цели

В данной части ПЗС приведена краткая формулировка предполагаемой реакции на уникальные проблемы безопасности, определенная посредством семейства ASP_DMP.

С.2.13.2 ASP_DMO.1 Цели безопасности домена безопасности

Зависимости:

ASP_INT.1 Введение ПЗС;

ASP_DMP.1 Определении проблем безопасности домена безопасности.

С.2.13.2.1 Элементы действий разработчика/интегратора

ASP_DMO.1.1D Разработчик/интегратор должен обеспечить формулировку целей безопасности домена.

ASPD_MО.1.2D Разработчик/интегратор должен обеспечить обоснование целей безопасности домена.

С.2.13.2.2 Элементы содержания и представления свидетельств

Каждая зависимость между требованиями безопасности должна быть удовлетворена, или обоснование требований безопасности должно объяснять причину неудовлетворения зависимости.

ASP_DMO.1.1C В формулировке целей безопасности домена должны излагаться уникальные цели безопасности для домена.

ASP_DMO.1.2C В формулировке целей безопасности домена должны излагаться любые цели безопасности для домена, которым соответствуют другие домены или внешние автоматизированные системы.

ASP_DMO.1.3C В формулировке целей безопасности домена должны излагаться любые цели безопасности, которые задаются другим доменам или доступны им.

ASP_DMO.1.4C В формулировке целей безопасности домена должны излагаться любые цели безопасности для среды разработки домена.

ASP_DMO.1.5C В обосновании целей безопасности домена каждая уникальная цель безопасности для домена должна сопоставляться с рисками, которым противостояла эта цель безопасности и ПБОр, которым соответствовала эта цель безопасности.

ASP_DMO.1.6C В обосновании целей безопасности домена каждая уникальная цель безопасности для домена должна сопоставляться с рисками, которым противостояла эта цель безопасности и ПБОр, которым соответствовала эта цель безопасности.

ASP_DMO.1.7C В обосновании целей безопасности домена каждая уникальная цель безопасности для домена должна сопоставляться с рисками, которым противостояла эта цель безопасности и ПБОр, которым соответствовала эта цель безопасности.

ASP_DMO.1.8C Обоснование целей безопасности домена должно демонстрировать противодействие целей безопасности всем уникальным неприемлемым рискам для домена.

ASP_DMO.1.9C Обоснование целей безопасности домена должно демонстрировать выполнение целями безопасности всех уникальных ПБОр для домена.

С.2.13.2.3 Элементы действий оценщика

ASP_DMO.1.1E Оценщик должен подтверждать соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

ASP_DMO.1.2Е Оценщик должен подтверждать внутреннюю согласованность формулировки целей безопасности домена.

ASP_DMO.1.3E Оценщик должен подтверждать согласование формулировки целей безопасности домена со спецификацией доменной организации.

С.2.14 Требования безопасности домена безопасности (ASP_DMR)

С.2.14.1 Цели

В данной части ПЗС представлено ясное и однозначное описание предполагаемого уникального поведения домена безопасности.

С.2.14.2 Ранжирование компонентов

С.2.14.3 ASP_DMR.1 Заданные требования безопасности домена

Зависимости: ASP_ECD.1 Определение расширенных компонентов.

С.2.14.3.1 Элементы действий разработчика/интегратора

Зависимости: зависимости отсутствуют.

С.2.14.3.2 Элементы содержания и представления свидетельств

ASP_DMR.1.1C В формулировке требований безопасности домена должны излагаться уникальные ФБС и ДБС, применимые к домену.

ASP_DMR.1.2C В формулировке требований безопасности домена должны идентифицироваться все операции, связанные с требованиями безопасности.

ASP_DMR.1.3C Каждая зависимость между требованиями безопасности домена должна быть удовлетворена или идентифицирована как "неудовлетворенная".

С.2.14.3.3 Элементы действий оценщика

ASP_DMR.1.1E Оценщик должен подтверждать соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

ASP_DMR.1.2E Оценщик должен подтверждать внутреннюю согласованность формулировки требований безопасности домена.

С.2.14.4 ASP_DMR.2 Производные требования безопасности домена

Является иерархической для: ASP_DMR.1 Заданные требования безопасности домена.

Зависимости:

ASP_DMO.1 Цели безопасности домена безопасности;

ASP_ECD.1 Определение расширенных компонентов.

С.2.14.4.1 Элементы действий разработчика/интегратора

ASP_DMR.2.1D Разработчик/интегратор должен обеспечить обоснование требований безопасности домена.

С.2.14.4.2 Элементы содержания и представления свидетельств

ASP_DMR.2.1C В формулировке требований безопасности домена должны излагаться уникальные ФБС и ДБС, применимые к домену.

ASP_DMR.2.2C В формулировке требований безопасности домена должны идентифицироваться все операции, связанные с требованиями безопасности.

ASP_DMR.2.3C Все операции должны выполняться правильно.

ASP_DMR.2.4C Каждая зависимость между требованиями безопасности должна быть удовлетворена, или обоснование требований безопасности должно объяснять причину неудовлетворения зависимости.

ASP_DMR.2.5C В обосновании требований безопасности домена каждая ФБС домена должна сопоставляться с целями безопасности домена.

ASP_DMR.2.6C В обосновании требований безопасности домена каждая ФБС домена должна сопоставляться с целями безопасности домена или среды ее разработки.

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

С.2.14.4.3 Элементы действий оценщика

ASP_DMR.2.1E Оценщик должен подтверждать внутреннюю согласованность формулировки требований безопасности домена.

ASP_DMR.2.2E Оценщик должен подтверждать внутреннюю согласованность формулировки требований безопасности домена.

С.3 Класс ASS: оценка задания по безопасности системы

С.3.1 Введение

В данном разделе представлены критерии доверия к оценке задания по безопасности системы (ЗБС). Оценка ЗБС требуется для демонстрации того, что ЗБС является обоснованным и внутренне непротиворечивым и, если ЗБС основано на одном или нескольких ПЗС или пакетах, что ЗБС является корректным представлением этих ПЗС и пакетов.

Ниже приведены семейства этого класса.

a) ASS_INT: Введение ЗБС;

b) ASS_CCL. Утверждения о соответствии;

c) ASS_SPD: Определение проблемы безопасности;

d) ASS_OBJ: Цели безопасности;

e) ASS_ECD: Определение компонентов расширения;

f) ASS_REQ: Требования безопасности;

g) ASS_TSS: Краткая спецификация СОО;

h) ASS_DMI: Введение домена безопасности;

i) ASS_DMC: Утверждение соответствия домена безопасности;

j) ASS_DMP: Определение проблем безопасности домена безопасности;

k) ASS_DMO: Цели безопасности домена безопасности;

I) ASS_DMR: Требования безопасности домена безопасности.

С.3.2 Общая часть ПЗС

Последующие спецификации применимы ко всему ПЗС. Спецификации для конкретных доменов должны описываться с помощью семейств доменов (см. С.3.10).

С.3.3 Введение ПЗС (ASS_INT)

С.3.3.1 Цели

Назначением данного семейства является изложение СОО в описательной форме на следующих уровнях абстракции: ссылка на ПЗС/СОО, краткий обзор СОО, описание СОО и организация доменов.

Оценка введения ПЗС требуется для демонстрации правильности идентификации СОО, правильности описания СОО на четырех уровнях абстракции и согласованности этих четырех описаний друг с другом. Введения конкретных доменов безопасности определены в С.3.11 "Введение доменов безопасности".

C.3.3.2 ASS_INT.1 Введение ПЗС

Зависимости: зависимости отсутствуют.

С.3.3.2.1 Элементы действий разработчика/интегратора

ASS_INT.1.1D Разработчик/интегратор должен обеспечить введение ПЗС.

С.3.3.2.2 Элементы содержания и представления свидетельств

ASS_INT.1.1 С Введение ПЗС должно содержать ссылку на ПЗС, ссылку на СОО, краткий обзор СОО, описание СОО и спецификацию доменной организации.

ASS_INT.1.2C Ссылка на ПЗС должна однозначно идентифицировать ПЗС.

ASS_INT.1.3C Ссылка на СОО должна идентифицировать СОО.

ASS INT.1.4C Краткий обзор СОО должен резюмировать использование и главные характеристики безопасности.

ASS_INT.1.5С Краткий обзор СОО должен идентифицировать тип СОО.

ASS_INT.1.6C Краткий обзор СОО должен идентифицировать взаимосвязи и интерфейсы с любыми внешними автоматизированными системами, требуемыми для СОО.

ASS_INT.1.7С В описании СОО должны быть описаны физическая область действия и границы СОО.

ASS_INT.1.8С В описании СОО должны быть описаны логическая область действия и границы СОО.

ASS_INT.1.9C В описании СОО должны быть описаны среды разработки для СОО, включая любые однозначные характеристики отдельных сред разработки доменов безопасности.

ASS_INT.10C В спецификации доменной организации должны быть описаны организация конструированных доменов безопасности и идентификация, область действия и границы каждого домена безопасности.

ASS_INT.11C Для каждого домена в спецификации доменной организации должны быть описаны любые услуги по обеспечению безопасности, предоставляемые для этого домена, доступные другим доменам, и любые характеристики безопасности домена, навязываемые другим доменам.

С.3.3.2.3 Элементы действий оценщика

ASS_INT.1.1Е Оценщик должен подтверждать соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

ASS_INT.1.2E Оценщик должен подтверждать согласование ссылки на СОО, краткого обзора СОО, описания СОО и спецификации доменной организации друг с другом.

С.3.4 Утверждения о соответствии (ASS_CCL)

С.3.4.1 Цели

Целью данного семейства является определение достоверности различных утверждений соответствия: утверждение соответствия стандартами серии ИСО/МЭК 15408, утверждение соответствия ПЗС, утверждение соответствия ПЗ, утверждение соответствия ЗБ и утверждение соответствия пакету требований. В утверждении соответствия стандартам серии ИСО/МЭК 15408 описывается версия ИСО/МЭК 15408, соответствие которой утверждают ПЗС и СОО, в утверждении соответствия ПЗ, ЗБ и/или пакету (если имеется) описывается, как ЗБС утверждает соответствие заданным ПЗ, ЗБ и/или пакетами, тогда как в утверждении ЗБС идентифицируются ПЗС (если имеются), соответствие которым утверждает ЗБС. Определение достоверности утверждений соответствия ПЗС, ПЗ, ЗБ и пакету требований влечет за собой определение четкости идентификации всех утвержденных ПЗС, ПЗ, ЗБ и пакетов - полностью ли эти ПЗС, ПЗ, ЗБ и пакеты содержатся в ПЗС и правильно ли выполнены требования безопасности, выведенные из этих ПЗС, ПЗ, ЗБ и пакетов. Утверждения соответствия для конкретного домена безопасности определены в подразделе С.3.12 "Утверждение соответствия домена безопасности".

С.3.4.2 ASS_CCL.1 Утверждения соответствия

Зависимости:

ASS_INT.1 Введение ЗБС;

ASS_SPD.1 Определение проблем безопасности;

ASS_OBJ.1 Цели безопасности;

ASS_ECD.1 Определение расширенных компонентов;

ASS_REQ.1 Заданные требования безопасности.

С.3.4.2.1 Элементы действий разработчика/интегратора

ASS_CCL.1.1D Разработчик/интегратор должен предоставить утверждение соответствия.

ASS_CCL.1.2D Разработчик/интегратор должен предоставить обоснование утверждения соответствия.

С.3.4.2.2 Элементы содержания и представления свидетельств

ASS_CCL.1.1C Утверждение соответствия должно содержать утверждение соответствия критериям, которое идентифицирует версию ИСО/МЭК ТО 19791, соответствие которому утверждают ЗБС и СОО.

ASS_CCL.1.2C В утверждении соответствия критериям должно описываться функциональное соответствие ЗБС ИСО/МЭК ТО 19791 или как полностью соответствующее ИСО/МЭК ТО 19791, или функционально дополненное.

ASS_CCL1.3C В утверждении соответствия критериям должно описываться соответствие доверия ЗБС ИСО/МЭК ТО 19791 как совместимое по доверию или расширенное по доверию в ИСО/МЭК ТО 19791.

ASS_CCL.1.4C Утверждение соответствия критериям должно согласовываться с определением расширенных компонентов.

ASS_CCL.1.5C В заявлении о соответствии должны быть определены ПЗС, ПЗ, ЗБ и пакеты, о соответствии которым заявляется в ЗБС.

ASS_CCL.1.6C В утверждении соответствия должно описываться соответствие ЗБС пакету требований как полностью соответствующее или как дополнение к пакету.

ASS_CCL.1.7C В обосновании утверждений соответствия должно демонстрироваться соответствие типа СОО типу СОО в ПЗС, ПЗ, ЗБ и пакетах требований, соответствие которым утверждается.

ASS_CCL.1.8C Обоснование утверждений соответствия должно демонстрировать согласованность формулировки определения проблем безопасности с формулировкой определения проблем безопасности в ПЗС, ПЗ, ЗБ и пакетах, о соответствии которым делается утверждение.

ASS_CCL.1.9C Обоснование заявления о соответствии должно демонстрировать согласованность формулировки целей с формулировкой целей в ПЗС, ПЗ, ЗБ и пакетах, о соответствии которым делается утверждение.

ASS_CCL.1.10C Обоснование заявлений о соответствии должно демонстрировать согласованность формулировки с формулировкой требований безопасности в ПЗС, ПЗ, ЗБ и пакетах, о соответствии которым делается утверждение.

ASS_CCL.1.11С Обоснование утверждений соответствия должно демонстрировать завершение всех заимствованных из ПЗС, ПЗ, ЗБ или пакетов операций в соответствии с соответствующими ПЗС, ПЗ, ЗБ или пакетами.

С.3.4.2.3 Элементы действий оценщика

ASS_CCL.1.1E Оценщик должен подтверждать соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

ASS_CCL.1.2E Оценщик должен подтверждать соответствие ЗБС утверждению соответствия стандартов серии ИСО/МЭК 15408.

С.3.5 Определение проблем безопасности (ASS_SPD)

С.3.5.1 Цели

В настоящей части ЗБС определяются проблемы безопасности, рассматриваемые СОО, включая среду ее разработки. Эти проблемы безопасности применимы к СОО в целом. Проблемы безопасности для конкретного домена безопасности определены в С.3.13. Оценка определения проблем безопасности требуется для демонстрации четкого определения проблем безопасности, предназначенных для рассмотрения СОО.

С.3.5.2 ASS_SPD.1 Определение проблем безопасности

Зависимости: зависимости отсутствуют.

С.3.5.2.1 Элементы действий разработчика/интегратора

ASS_SPD.1.1D Разработчик/интегратор должен предоставить определение проблем безопасности.

С.3.5.2.2 Элементы содержания и представления свидетельств

ASS_SPD.1.1C В определении проблем безопасности должны быть изложены все применимые к СОО риски. Каждый риск должен идентифицироваться как "приемлемый" или "неприемлемый".

ASS_SPD.1.2C Все неприемлемые риски должны быть описаны на основе угроз и уязвимостей. Каждая угроза должна описываться с точки зрения источника угрозы, актива и враждебности действия.

ASS_SPD.1.3C В определении проблем безопасности должны быть изложены ПБОр.

С.3.5.2.3 Элементы действий оценщика

ASS_SPD.1.1E Оценщик должен подтверждать соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

ASS_SPD.1.2E Оценщик должен подтвердить внутреннюю непротиворечивость определения проблемы безопасности.

С.3.6 Цели безопасности (ASS_OBJ)

С.3.6.1 Цели

Цели безопасности представлены в краткой формулировке предполагаемой реакции на проблему безопасности, определенную посредством семейства ASS_SPD. Определенные цели безопасности в данной части применимы к СОО в целом. Цели безопасности для конкретного домена безопасности определены в С.3.14 "Цели безопасности домена безопасности". Оценка целей безопасности требуется для демонстрации того, что цели безопасности адекватно и полностью учитывают определение проблем безопасности, и распределение этой проблемы между СОО, средой ее разработки и внешними автоматизированными системами четко определено и что цели безопасности внутренне согласованы.

С.3.6.2. ASS_OBJ.1 Цели безопасности

Зависимости: ASS_SPD.1 Определение проблем безопасности.

С.3.6.2.1 Элементы действий разработчика/интегратора

ASS_OBJ.1.1D Разработчик/интегратор должен предоставить формулировку целей безопасности.

ASS_OBJ.1.2D Разработчик/интегратор должен предоставить обоснование целей безопасности.

С.3.6.2.2 Элементы содержания и представления свидетельств

SS_OBJ.1.1C В формулировке целей безопасности должны излагаться цели безопасности для СОО.

ASS_OBJ.1.2C В формулировке целей безопасности должны излагаться любые цели безопасности, которым соответствуют внешние автоматизированные системы.

ASS_OBJ.1.3C В формулировке целей безопасности должны излагаться цели безопасности для среды разработки.

ASS_OBJ.1.4C В обосновании целей безопасности каждая цель безопасности СОО должна сопоставляться с рисками, которым противостоит эта цель безопасности, и ПБОр, которым соответствует эта цель безопасности.

ASS_OBJ.1.1.5C В обосновании целей безопасности каждая цель безопасности для внешних автоматизированных систем должна сопоставляться с рисками, которым противостояла эта цель безопасности, и ПБОр, которым соответствовала эта цель безопасности.

ASS_OBJ.1.1.6С В обосновании целей безопасности каждая цель безопасности для среды разработки должна сопоставляться с рисками, которым противостояла эта цель безопасности, и ПБОр, которым соответствовала эта цель безопасности.

ASS_OBJ.1.1.7C В обосновании целей безопасности должно демонстрироваться противостояние целей безопасности всем неприемлемым рискам.

ASS_OBJ.1.8C Обоснование целей безопасности должно демонстрировать выполнение целями безопасности всех ПБОр.

С.3.6.2.3 Элементы действий оценщика

ASS_OBJ.1.1E Оценщик должен подтверждать соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

ASS_OBJ.1.2E Оценщик должен подтверждать внутреннюю согласованность определения проблем безопасности.

С.3.7 Определение расширенных компонентов (ASS_ECD)

С.3.7.1 Цели

С.3.7.2 ASS_ECD.1 Определение расширенных компонентов

Зависимости: зависимости отсутствуют.

С.3.7.3 Элементы действий разработчика/интегратора

ASS_ECD.1.1D Разработчик/интегратор должен предоставить формулировку требований безопасности.

ASS_ECD.1.2D Определение расширенных компонентов.

С.3.7.3.1 Элементы содержания и представления свидетельств

ASS_ECD.1.1С В формулировке требований безопасности должны быть определены все расширенные требования безопасности.

ASS_ECD.1.2C Определение расширенных компонентов должно определять расширенный компонент для каждого расширенного требования безопасности.

ASS_ECD.1.3C В определении расширенных компонентов должно быть описано, как каждый расширенный компонент связан с существующими компонентами, семействами и классами по стандартам серии ИСО/МЭК 15408.

ASS_ECD.1.4С В определении расширенных компонентов должны использоваться существующие компоненты, семейства и классы по стандартам сериии ИСО/МЭК 15408 и методология в качестве модели для представления.

ASS_ECD.1.5C Расширенные компоненты должны состоять из измеримых и объективных элементов для того, чтобы можно было продемонстрировать соответствие или несоответствие этим элементам.

С.3.7.3.2 Элементы действий оценщика

ASS_ECD.1.1Е Оценщик должен подтверждать соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

ASS_ECD.1.2E Оценщик должен подтверждать, что ни один расширенный компонент не может быть ясно выражен с помощью существующих компонентов.

С.3.8 Требования безопасности (ASS_REQ)

С.3.8.1 Цели

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

С.3.8.2 Ранжирование компонентов

С.3.8.3 ASS_REQ.1 Заданные требования безопасности

Зависимости: ASS_ECD.1 Определение расширенных компонентов

С.3.8.3.1 Элементы действий разработчика/интегратора

Зависимости: зависимости отсутствуют.

С.3.8.3.2 Элементы содержания и представления свидетельств

ASS_REQ.1.1С В формулировке требований безопасности должны быть описаны ФБС и ДБС.

ASS_REQ.1.2С В формулировке требований безопасности должны быть определены все операции, связанные с требованиями безопасности.

ASS_REQ.1.3C Все операции "назначение" и "выбор" должны быть завершены.

ASS_REQ 1.4С Все операции должны быть правильно выполнены.

ASS_REQ 1.5С Каждая зависимость между требованиями безопасности должна быть или удовлетворена, или идентифицирована как "неудовлетворенная".

С.З.8.3.3 Элементы действий оценщика

ASS_REQ.1.1E Оценщик должен подтверждать соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

ASS_REQ.1.2E Оценщик должен подтверждать внутреннюю согласованность формулировки требований безопасности.

С.3.8.4 ASS_REQ.2 Производные требования безопасности

Являются иерархическими для: ASS_REQ.1 Заданные требования безопасности.

Зависимости: ASS_OBJ.1 Цели безопасности;

ASS_ECD.1 Определение расширенных компонентов.

С.3.8.4.1 Элементы действий разработчика/интегратора

ASS_REQ.2.1D Разработчик/интегратор должен предоставить обоснование требований безопасности.

С.3.8.4.2 Элементы содержания и представления свидетельств

ASS_REQ.2.1C В формулировке должны быть описаны ФБС и ДБС.

ASS_REQ.2.2C В формулировке должны быть определены все операции, связанные с требованиями безопасности.

ASS_REQ.2.3C Все операции по распределению и выбору должны быть завершены.

ASS_REQ.2.4C Все операции должны выполняться правильно.

ASS_REQ 2.5С Каждая зависимость между требованиями безопасности должна быть удовлетворена или идентифицирована как "неудовлетворенная".

ASS_REQ 2.6С Обоснование требований безопасности должно сопоставлять каждую ФБС с целями безопасности для СОО.

ASS_REQ 2.7С Обоснование требований безопасности должно сопоставлять каждую ДБС с целями безопасности для СОО или среды его разработки.

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

С.3.8.4.3 Элементы действий оценщика

ASS_REQ 2.1Е Оценщик должен подтверждать соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

ASS_REQ 2.2Е Оценщик должен подтверждать внутреннюю согласованность формулировки требований безопасности.

С.3.9 Краткая спецификация СОО (ASS_TSS)

С.3.9.1 Цели

Целью краткой спецификации СОО является предоставление потенциальным заказчикам СОО описания на высоком уровне того, как разработчик/интегратор намеревается выполнить свои ФБС и ДБС. Краткая спецификация СОО должна оказать помощь оценщикам и потенциальным заказчикам в понимании того, насколько СОО соответствует их ФБС и ДБС. Определенная в данной части краткая спецификация СОО применима к СОО в целом. Краткая спецификация безопасности для конкретного домена безопасности определена в С.3.16 "Краткая спецификация домена безопасности (ASS_DMS)". Оценка краткой спецификации СОО необходима для определения адекватности рассмотрения всех ФБС и согласованности краткой спецификации СОО с другими описаниями СОО.

С.3.9.2 ASS_TSS.1 Краткая спецификация СОО

Зависимости:

ASS_INT.1 Введение ЗБС;

ASS_REQ.1 Заданные требования безопасности.

С.3.9.2.1 Элементы действий разработчика/интегратора

ASS_TSS.1.1D Разработчик/интегратор должен предоставить краткую спецификацию СОО.

С.3.9.2.2 Элементы содержания и представления свидетельств

ASS_TSS.1.1C В краткой спецификации СОО должно быть описано, как СОО соответствует каждой ФБС.

ASS_TSS.1.2C В краткой спецификации СОО должно быть описано, как СОО и среда его разработки соответствует каждой ДБС.

С.3.9.2.3 Элементы действий оценщика

ASS_TSS.1.1E Оценщик должен подтверждать соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

ASS_TSS.1.2E Оценщик должен подтверждать согласование краткой спецификации СОО с кратким обзором и описанием СОО.

С.3.10 Домены безопасности системы как объекта защиты

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

В последующих семействах определены семейства, используемые для определения доменов безопасности в СОО.

С.3.11 Введение доменов безопасности (ASS_DMI)

С.3.11.1 Цели

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

С.3.11.2 ASS_DMI.1 Введение домена безопасности

Зависимости: ASS_INT.1 Введение ЗБС.

С.3.11.2.1 Элементы действий разработчика/интегратора

ASS_DMI.1.1D Разработчик/интегратор должен обеспечить введение домена безопасности.

С.3.11.2.2 Элементы содержания и представления свидетельств

ASS_DMI.1.1C Введение домена безопасности должно содержать ссылку, краткий обзор и описание домена безопасности.

ASS_DMI.1.2C Ссылка на домен безопасности должна однозначно определять домен безопасности.

ASS_DMI.1.3С Обзор домена безопасности должен резюмировать использование и главные характеристики безопасности домена безопасности.

ASSDMI.1.4С В описании домена безопасности должны излагаться включенные подсистемы и компоненты.

ASS_DMI.1.5C В описании домена безопасности должны излагаться взаимосвязи и интерфейсы с другими системами.

С.3.11.2.3 Элементы действий оценщика

ASS_DMI.1.1E Оценщик должен подтверждать соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

ASS_DMI.1.2E Оценщик должен подтверждать согласованность домена безопасности, краткого обзора домена безопасности и описания домена безопасности друг с другом и с введением СОО.

С.3.12 Утверждение соответствия доменов безопасности (ASS_DMC)

С.3.12.1 Цели

В данной части ЗБС определяется специфическое утверждение соответствия для домена безопасности.

С.3.12.2 ASS_DMC.1 Утверждения соответствия

Зависимости:

ASS_DMP.1 Определение проблем безопасности для доменов безопасности;

ASS_DMO.1 Цели безопасности доменов безопасности;

ASS_DMR.1 Заданные требования безопасности для домена.

С.3.12.2.1 Элементы действий разработчика/интегратора

ASS_DMC.1.1D Утверждение соответствия домена.

ASS_DMC.1.2D Разработчик/интегратор должен предоставить обоснование утверждения соответствия домена.

С.3.12.2.2 Элементы содержания и представления свидетельств

ASS_DMC.1.1C В заявлении о соответствии должны быть определены все ПЗС, ПЗ и пакеты требований безопасности, о соответствии которым утверждает домен.

ASS_DMC.1.2C В заявлении о соответствии домена должно быть изложено любое соответствие домена пакету как соответствующее полностью или приданное пакету.

ASS_DMC.1.3С Обоснование утверждения соответствия домена должно демонстрировать согласованность типа СОО с типом СОО в ПЗС, ПЗ и пакетах, о соответствии которым делается утверждение.

ASS_DMC.1.4С Обоснование утверждения соответствия домена должно демонстрировать согласованность формулировки определения проблемы безопасности домена с формулировкой определения проблемы безопасности в ПЗС, ПЗ и пакетах, о соответствии которым делается утверждение.

ASS_DMC.1.5С Обоснование утверждения соответствия домена должно демонстрировать согласованность формулировки целей безопасности домена с формулировкой целей безопасности в ПЗС, ПЗ и пакетах, о соответствии которым делается утверждение.

ASS_DMC.1.6С Обоснование утверждения соответствия домена должно демонстрировать согласованность формулировки требований безопасности домена с формулировкой требований безопасности в ПЗС, ПЗ и пакетах, о соответствии которым делается утверждение.

ASS_DMC.1.7C Обоснование утверждения соответствия домена должно демонстрировать, что все операции, связанные с требованиями безопасности, заимствованными из ПЗС, ПЗ и пакета, завершены в согласовании с соответствующими ПЗС, ПЗ и пакетом.

С.3.12.2.3 Элементы действий оценщика

ASS_DMC1.1E Оценщик должен подтверждать соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

С.3.13 Проблемы безопасности домена безопасности (ASS_DMP)

С.3.13.1 Цели

В данной части ЗБС определены специфические проблемы безопасности, относящиеся к какому-либо домену безопасности.

С.3.13.2 ASS_DMP.1 Определение проблем безопасности домена безопасности

Зависимости: зависимости отсутствуют.

ASS_DMP.1.1D Разработчик/интегратор должен предоставить определение проблем безопасности домена.

ГАРАНТ:

Нумерация пунктов приводится в соответствии с источником

С.3.13.2.2 Элементы содержания и представления свидетельств

ASS_DMP.1.1C В определении проблем безопасности домена должны быть описаны все уникальные риски, применимые к домену. Каждый риск должен категорироваться как "приемлемый" или "неприемлемый".

ASS_DMP.1.2C Все неприемлемые риски должны быть изложены, исходя из угроз и уязвимостей. Каждая угроза должна быть изложены, исходя из источника угрозы, актива и враждебности действия.

ASS_DMP.1.3C В определении проблем безопасности домена должны быть описаны уникальные ПБОр, применимые к домену.

С.3.13.2.3 Элементы действий оценщика

ASS_DMR1.1Е Оценщик должен подтверждать соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

ASS_DMP.1.2E Оценщик должен подтверждать внутреннюю согласованность определения проблем безопасности домена.

С.3.14 Цели безопасности домена безопасности (ASS_DMO)

С.3.14.1 Цели

В данной части ЗБС представлена краткая формулировка предполагаемого реагирования на уникальные проблемы безопасности домена, определенные с помощью семейства ASS_DMP.

С.3.14.2 ASS_DMO.1 Цели безопасности домена безопасности

Зависимости:

ASS_INT.1 Введение ЗБС;

ASS_DMP.1 Определение проблем безопасности домена безопасности.

С.3.14.2.1 Элементы действий разработчика/интегратора

ASS_DMO.1.1D Разработчик/интегратор должен предоставить формулировку целей безопасности домена.

ASS_DMO.1.2D Разработчик/интегратор должен предоставить обоснование целей безопасности домена.

С.3.14.2.2 Элементы содержания и представления свидетельств

ASS_DMO.1.1C В формулировке целей безопасности домена должны быть описаны уникальные цели безопасности для домена.

ASS_DMO.1.2C В формулировке целей безопасности домена должны быть описаны любые цели безопасности для домена, которым соответствуют другие домены или внешние автоматизированные системы.

ASS_DMO.1.3C В формулировке целей безопасности домена должны быть описаны любые цели безопасности для домена, которые задаются другим доменам или доступны им.

ASS_DMO.1.4C В формулировке целей безопасности домена должны быть описаны уникальные цели безопасности для среды разработки домена.

ASS_DMO.1.5С Обоснование целей безопасности должно сопоставлять каждую уникальную цель безопасности для домена с рисками, которым противостояла эта цель безопасности, и ПБОр, которым соответствовала эта цель безопасности.

ASS_DMO.1.6C Обоснование целей безопасности должно сопоставлять каждую уникальную цель безопасности для среды разработки домена с рисками, которым противостояла эта цель безопасности, и ПБОр, которым соответствовала эта цель безопасности.

ASS_DMO.1.7C Обоснование целей безопасности должно сопоставлять каждую уникальную цель безопасности для других доменов с рисками, которым противостояла эта цель безопасности, и ПБОр, которым соответствовала эта цель безопасности.

ASS_DMO.1.8C Обоснование целей безопасности должно демонстрировать противодействие целей безопасности всем неприемлемым рискам, уникальным для домена.

ASS DMO.1.9C Обоснование целей безопасности должно демонстрировать выполнение всеми целями безопасности всех уникальных ПБОр для домена.

С.3.14.2.3 Элементы действий оценщика

ASS_DMO1.1E Оценщик должен подтверждать соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

ASS_DMO.1.2E Оценщик должен подтверждать внутреннюю согласованность формулировки целей безопасности домена.

ASS_DMO.1.3E Оценщик должен подтверждать согласованность формулировки целей безопасности домена со спецификацией доменной организации.

С.3.15 Требования безопасности домена безопасности (ASS_DMR)

С.3.15.1 Цели

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

С.3.15.2 Ранжирование компонентов

С.3.15.2.1 Элементы действий разработчика/интегратора

Зависимости: зависимости отсутствуют.

С.3.15.3.2 Элементы содержания и представления свидетельств

ASS_DMR.1.1C В формулировке требований безопасности домена должны быть описаны уникальные ФБС и ДБС, применимые к этому домену.

ASS_DMR.1.2C В формулировке требований безопасности домена должны быть определены все операции, связанные с требованиями безопасности.

ASS_DMR.1.3C Все операции по распределению и выбору должны быть завершены.

ASS_DMR.1.4C Все операции должны выполняться правильно.

ASS_DMR.1.5C Каждая зависимость между требованиями безопасности должна быть или удовлетворена, или идентифицирована как "неудовлетворенная".

С.3.15.3.3 Элементы действий оценщика

ASS_DMR.1.1E Оценщик должен подтверждать соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

ASS_DMR.1.2E Оценщик должен подтверждать внутреннюю согласованность формулировки требований безопасности домена.

С.3.15.4 ASS_DMR.2 Производные требования безопасности домена

Является иерархическим для: ASS_DMR.1 Заданные требования безопасности домена.

Зависимости:

ASS_DMO.1 Цели безопасности домена безопасности;

ASS_ECD.1 Определение расширенных компонентов.

С.3.15.4.1 Элементы действий разработчика/интегратора

ASS_DMO.1.1D Разработчик/интегратор должен предоставить обоснование требований безопасности домена.

С.3.15.4.2 Элементы содержания и представления свидетельств

ASS_DMR.2.1C В формулировке требований безопасности домена должны быть описаны уникальные ФБС и ДБС, применимые к этому домену.

ASS_DMR.2.2C В формулировке требований безопасности домена должны быть определены все операции, связанные с требованиями безопасности.

ASS_DMR.2.3C Все операции по распределению и выбору должны быть завершены.

ASS_DMR.2.4C Все операции должны выполняться правильно.

ASS_DMR.2.5C Каждая зависимость между требованиями безопасности домена должна быть удовлетворена или идентифицирована как "неудовлетворенная".

ASS_DMR.2.6C Обоснование требований безопасности домена должно сопоставлять каждую ФБС домена с целями безопасности для домена.

ASS_DMR.2.7C Обоснование требований безопасности домена должно сопоставлять каждую ФБС домена с целями безопасности для домена и среды его разработки.

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

С.3.15.4.3 Элементы действий оценщика

ASS_DMR.2.1E Оценщик должен подтверждать соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

ASS_DMR.2.2E Оценщик должен подтверждать внутреннюю согласованность формулировки требований безопасности домена.

С.3.16 Краткая спецификация домена безопасности (ASS_DMS)

С.3.16.1 Цели

В данной части ЗБС определяется краткая спецификация домена безопасности.

С.3.16.2 ASS_DMS.1 Краткая спецификация домена безопасности

Зависимости:

ASS_DMI.1 Введение домена безопасности:

ASS_DMR.1 Требования безопасности домена безопасности.

С.3.16.2.1 Элементы действий разработчика/интегратора

ASS_DMS.1.1D Разработчик/интегратор должен предоставить краткую спецификацию домена.

С.3.16.2.2 Элементы содержания и представления свидетельств

ASS_DMS.1.1C В краткой спецификации домена должно быть описано, как домен соответствует каждой ФБС домена.

ASS_DMS.1.2C В краткой спецификации домена должно быть описано, как домен и его среда разработки соответствует каждой ДБС домена.

С.3.16.2.3 Элементы действий оценщика

ASS_DMS.1.1Е Оценщик должен подтверждать соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

ASS_MS.1.2Е Оценщик должен подтверждать согласованность краткой спецификации домена с кратким обзором домена и описанием домена.

С.4 Класс AOD: руководства для автоматизированных систем

С.4.1 Введение

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

Следовательно, действия AOD тесно связаны с процессами и процедурами, определенными организационными требованиями безопасности. Руководство для пользователя и администратора включает в себя информацию, относящуюся к технологическим аспектам автоматизированной системы, а также к процессам эксплуатации автоматизированной системы с участием человека.

С.4.2 Замечания по применению

Все требования к ФЭБ, определенные в ЗБС, по мере их применения к требуемому поведению персонала должны быть изложены в соответствующем руководстве по автоматизированной системе.

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

В руководстве для администратора должна быть определена следующая информация:

- функции и привилегии, подлежащие контролю;

- типы необходимых мер контроля;

- причины применения мер обеспечения безопасности.

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

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

С.4.3 Спецификация конфигурации автоматизированной системы (AOD_OCD)

С.4.3.1 Цели

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

С.4.3.2 Ранжирование компонентов

Семейство состоит из двух компонентов. Эти компоненты распределяют по уровням на основе подтверждения изложения в документации и проверок в автоматизированной системе.

С.4.3.3 AOD_OCD.1 Спецификация конфигурации автоматизированной системы

Зависимости:

ASD_CON.1 Концепция безопасности операций;

ASD_CMP.1 Конструкция компонентов.

С.4.3.3.1 Элементы действий разработчика/интегратора

AOD_OCD.1.1D Разработчик/интегратор должен предоставлять спецификацию конфигурации, определяющую параметры конфигурации, требуемые для безопасности, которые поддерживают интеграцию компонентов автоматизированной системы и позволяют функциям безопасности автоматизированной системы внедрять и осуществлять концепцию безопасности функционирования и связанных с ним политик автоматизированной системы.

С.4.3.3.2 Элементы содержания и представления свидетельств

AOD_OCD.1.1C В спецификации конфигурации должны быть изложены все требования к конфигурации, относящиеся к СОО, включая среду ее эксплуатации.

AOD_OCD.1.2C В спецификации конфигурации должны быть изложены параметры конфигурации безопасности, доступные системному интегратору или равнозначным им пользователям/администраторам с такой же ролью и обязанностью.

AOD_OCD.1.3C В спецификации конфигурации должно быть изложено применение параметров безопасности, конфигурированных СОО для внедрения и осуществления политик безопасности системы.

AOD_OCD.1.4C В спецификации конфигурации должны содержаться предупреждения о доступных функциях и привилегиях конфигурации, которые должны контролироваться в защищенной среде обработки.

AOD_OCD.1.5C В спецификации конфигурации должны быть четко представлены связанные с конфигурацией обязанности, необходимые для безопасного функционирования СОО.

AOD_OCD.1.6C Спецификация конфигурации должна быть согласована со всей остальной документацией, представленной для оценки.

AOD_OCD.1.7C В спецификации конфигурации должна быть отражена реализация параметров безопасности компонентов, необходимых по концепции безопасности операций, в конструкции компонентов.

С.4.3.3.3 Элементы действий оценщика

AOD_OCD.1.1E Оценщик должен подтверждать соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

С.4.3.4 AOD_OCD.2 Проверка спецификации конфигурации автоматизированной системы

Является иерархической для: AOD_OCD.1 Спецификация конфигурации автоматизированной системы.

Зависимости:

ASD_CON.1 Понятие безопасности операций;

ASD_CMP.1 Конструкция компонентов.

С.4.3.4.1 Элементы действий разработчика/интегратора

AOD_OCD.2.1D Разработчик/интегратор должен предоставлять спецификацию конфигурации, определяющую параметры конфигурации, релевантные для безопасности, которые поддерживают интеграцию компонентов системы и позволяют функциям безопасности автоматизированной системы внедрять и осуществлять концепцию безопасности функционирования и связанных с ним политик.

С.4.3.4.2 Элементы содержания и представления свидетельств

AOD_OCD.2.1C В спецификации конфигурации должны быть изложены все требования к конфигурации, относящиеся к СОО, включая среду ее эксплуатации.

AOD_OCD.2.2C В спецификации конфигурации должны быть изложены параметры конфигурации безопасности, доступные системному интегратору или равнозначным ему пользователям/администраторам с такой же ролью и обязанностью.

AOD_OCD.2.3C В спецификации конфигурации должно быть изложено применение параметров безопасности, сконфигурированных СОО для внедрения и осуществления политик безопасности системы.

AOD_OCD.2.4C В спецификации конфигурации должны содержаться предупреждения о доступных функциях и привилегиях конфигурации, которые должны контролироваться в защищенной среде обработки.

AOD_OCD.2.5C В спецификации конфигурации должны быть четко представлены связанные с конфигурацией обязанности, необходимые для безопасного функционирования СОО.

AOD_OCD.2.6C Спецификация конфигурации должна быть согласована со всей остальной документацией, представленной для оценки.

AOD_OCD.2.7C В спецификации конфигурации должна быть отражена реализация всех параметров безопасности компонентов, необходимых по концепции безопасности операций, в конструкции компонентов.

С.4.3.4.3 Элементы действий оценщика

AOD_OCD.2.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

AOD_OCD.2.2E Оценщик должен независимо проверять практитическое применение параметров конфигурации, определенное в спецификации конфигурации.

С.4.4 Руководство администратора автоматизированной системы (AOD_ADM)

С.4.4.1 Цели

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

С.4.4.2 Ранжирование компонентов

Семейство состоит из двух компонентов. Эти компоненты распределяются по уровням на основе подтверждения изложения в документации и проверок автоматизированной системы.

С.4.4.3 Замечания по применению

Содержимое руководства администратора непосредственно отражает политики, правила, обязанности, процедуры и организационные меры безопасности, связанные с администратором и определенные в организационных мерах безопасности. Требования AOD_ADM.1.3С и AOD_ADM.1 7С относятся к аспекту соответствующего представления всех предупреждений для пользователей СОО в отношении среды безопасности СОО и целей безопасности, изложенных в ПЗС/ЗБС.

Концепция защищенных значений в том виде, в котором она используется в AOD_ADM.1.6C, уместна в случае, если администратор осуществляет контроль за параметрами безопасности. Требуется руководство по защищенным и незащищенным установкам таких параметров.

С.4.4.4 AOD_ADM.1 Руководство администратора

Зависимости: ASD_SAD.1 Описание архитектуры.

С.4.4.4.1 Элементы действий администрации

AOD_ADM.1.1M Администрация должна обеспечить персонал управления системой руководством администратора автоматизированной системы.

С.4.4.4.2 Элементы содержания и представления свидетельств

AOD_ADM.1.1C В руководстве администратора должны излагаться административные функции и интерфейсы, доступные администратору СОО.

AOD_ADM.1.2C В руководстве администратора должны правильно излагаться требования организационного контроля, относящиеся к администратору.

AOD_ADM.1.3C В руководстве администратора должно излагаться безопасное управление СОО.

AOD_ADM.1.4C В руководстве администратора должны содержаться предупреждения о функциях и привилегиях, которые подлежат контролю в безопасной среде обработки.

AOD_ADM.1.5C В руководстве администратора должны описываться операции, имеющие отношение к поведению пользователя, которые связаны с безопасным функционированием СОО.

AOD_ADM.1.6C В руководстве администратора должны излагаться параметры безопасности, находящиеся под контролем администратора, при необходимости, с указанием безопасных значений.

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

AOD_ADM.1.8С Руководство администратора должно согласовываться со всей другой документацией, представленной для оценки.

AOD_ADM.1.9C В руководстве администратора должны описываться интерфейсы к внешним автоматизированным системам, относящиеся к администратору.

С.4.4.4.3 Элементы действий оценщика

AOD_ADM.1.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

С.4.4.5 AOD_ADM.2 Верификация

Является иерархическим для: AOD_ADM.1 Руководство администратора.

Зависимости: ASD_SAD.1 Описание архитектуры.

С.4.4.5.1 Элементы действий администрации

AOD_ADM.2.1.M Администрация должна обеспечивать персонал управления системой руководством администратора автоматизированной системы.

С.4.4.5.2 Элементы содержания и представления свидетельств

AOD_ADM.2.1C В руководстве администратора должны описываться административные функции и интерфейсы, доступные администратору СОО.

AOD_ADM.2.2C В руководстве администратора должны правильно излагаться требования организационного контроля, относящиеся к администратору.

AOD_ADM.2.3C В руководстве администратора должно излагаться безопасное управление СОО.

AOD_ADM.2.4C В руководстве администратора должны содержаться предупреждения о функциях и привилегиях, которые подлежат контролю в безопасной среде обработки.

AOD_ADM.2.5C В руководстве администратора должны описываться все операции, имеющие отношение к поведению пользователя, которые связаны с безопасным функционированием СОО.

AOD_ADM.2.6C В руководстве администратора должны быть приведены все управляемые администратором параметры безопасности, обозначающие соответствующие безопасные значения.

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

AOD_ADM.2.8C Руководство администратора должно согласовываться со всей другой документацией, представленной для оценки.

AOD_ADM.2.9C В руководстве администратора должны описываться все интерфейсы к внешним автоматизированным системам, относящиеся к администратору.

С.4.4.5.3 Элементы действий оценщика

AOD_ADM.2.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

AOD_ADM.2.2E Оценщик должен независимо верифицировать, посредством опроса персонала, выборки из руководства администратора и др., практическое применение руководства администратора.

С.4.5 Руководство пользователя автоматизированной системы (AOD_USR)

С.4.5.1 Цели

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

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

С.4.5.2 Ранжирование компонентов

Данное семейство состоит из двух компонентов. Компоненты распределяют по уровням на основе подтверждения описания в документации и проверок в автоматизированной системе.

С.4.5.3 Замечания по применению

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

С.4.5.4 AOD_USR.1 Руководство пользователя

Зависимости: ASD_SAD.1 Описание архитектуры.

С.4.5.4.1 Элементы действий администрации

AOD_USR.1.1M Администрация должна при необходимости предоставлять руководство пользователя.

С.4.5.4.2 Элементы содержания и представления свидетельств

AOD_USR.1.1C В руководстве пользователя должны описываться функции и интерфейсы, доступные для не связанных с управлением пользователей СОО.

AOD_USR.1.2C В руководстве пользователя должны описываться организационные меры безопасности, связанные с пользователем.

AOD_USR.1.3C В руководстве пользователя должно описываться использование доступных пользователю функций безопасности, обеспечиваемых СОО.

AOD_USR.1.4C В руководстве пользователя должны содержаться предупреждения о доступных пользователю функциях и привилегиях, которые подлежат контролю в безопасной среде обработки.

AOD_USR.1.5C В руководстве пользователя должны быть четко представлены обязанности пользователя, необходимые для обеспечения безопасного функционирования СОО, включая обязанности, связанные с поведением пользователя во время эксплуатации системы.

AOD_USR.1.6C Руководство пользователя должно согласовываться с другой документацией, представленной для оценки.

С.4.5.4.3 Элементы действий оценщика

AOD_USR.1.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

С.4.5.5 Верификация руководства пользователя

Является иерархическим для: AOD_USR.1 Руководство пользователя.

Зависимости: ASD_SAD.1 Описание архитектуры.

С.4.5.5.1 Элементы действий администрации

AOD_USR.2.1M Администрация должна обеспечить наличие в организации руководства пользователя.

С.4.5.5.2 Элементы содержания и представления свидетельств

AOD_USR.2.1C В руководстве пользователя должны описываться функции и интерфейсы, доступные для не связанных с управлением пользователей СОО.

AOD_USR.2.2C В руководстве пользователя должны описываться организационные меры безопасности, связанные с пользователем.

AOD_USR.2.3C В руководстве пользователя должно описываться использование доступных пользователю функций безопасности, обеспечиваемых СОО.

AOD_USR.2.4C В руководстве пользователя должны содержаться предупреждения о доступных пользователю функциях и привилегиях, которые подлежат контролю в безопасной среде обработки.

AOD_USR.2.5C В руководстве пользователя должны быть четко представлены обязанности пользователя, необходимые для обеспечения безопасного функционирования СОО, включая обязанности, связанные с поведением пользователя во время эксплуатации системы.

AOD_USR.2.6C Руководство пользователя должно согласовываться со всей другой документацией, представленной для оценки.

С.4.5.5.3 Элементы действий оценщика

AOD_USR.2.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

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

С.4.6 Верификация руководств (AOD_GVR)

С.4.6.1 Цели

Целью является продемонстрировать, что документация руководства остается адекватной после внесения изменений и модификаций в компоненты системы, конфигурацию системы или среду эксплуатации.

С.4.6.2 Ранжирование компонентов

Имеется один компонент.

С.4.6.3 AOD_GVR.1 Верификация руководства

Зависимости:

AOD_OCD.1 Спецификация конфигурации автоматизированной системы;

AOD_ADM.1 Руководство администратора;

AOD_USR.1 Руководство пользователя.

С.4.6.3.1 Цели

Назначением данного компонента является продемонстрировать, что документация руководства остается адекватной после внесения изменений и модификаций в компоненты системы, конфигурацию системы или среду эксплуатации.

С.4.6.3.2 Замечания по применению

Данный компонент рассматривает не только измененные или модифицированные части автоматизированной системы, но также части, которые могли стать недействительными (неисправными).

С.4.6.3.3 Элементы действий разработчика/интегратора

AOD_GVR.1.1D После внесения изменений и модификаций в компоненты системы, конфигурацию системы или среду эксплуатации разработчик/интегратор должен провести верифицирующий анализ для проверки, остались ли конфигурация автоматизированной системы и документация руководства правильными и согласованными.

С.4.6.3.4 Элементы содержания и представления свидетельств

AOD_GVR.1.1C По каждому документу конфигурации верифицирующий анализ должен показать его неизменность после внесения изменений или модификаций в компоненты или его правильное обновление для отражения изменений или модификаций.

AOD_GVR.1.2C По каждому руководству администратора верифицирующий анализ должен показать его неизменность после внесения изменений или модификаций в компоненты или его правильное обновление для отражения изменений или модификаций.

AOD_GVR.1.3C По каждому руководству пользователя верифицирующий анализ должен показать его неизменность после внесения изменений или модификаций в компоненты или его правильное обновление для отражения изменений или модификаций.

С.4.6.3.5 Элементы действий оценщика

AOD_GVR.1.1C Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

С.5 Класс ASD: документация по проектированию архитектуры автоматизированных систем и конфигурационная документация

С.5.1 Введение

Класс доверия ASD является производным класса по ИСО/МЭК 15408-3. Однако информация по разработке и интеграции, необходимая для автоматизированных систем, настолько отлична от информации в классе ADV, что возникла потребность в определении нового класса.

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

С.5.2 Описание архитектуры (ASD_SAD)

С.5.2.1 Цели

Целью описания архитектуры автоматизированной системы является представление подробного обсуждения характеристик безопасности автоматизированной системы, созданных, исходя из структуры (подсистем, компонентов, интерфейсов с внешними автоматизированными системами), взаимодействия (интерфейсы, межсоединения, данные и потоки управления) и назначения (трактовка концепции безопасности операций и требований безопасности автоматизированной системы), а также присвоение различных степеней (уровней) доверия различным частям автоматизированной системы. Эта информация оказывает содействие в понимании и реализации некоторых аспектов оценки автоматизированной системы: присвоение доверия частям автоматизированной системы, концепция безопасности операций этой системы, процедуры, планы и стратегия испытаний автоматизированной системы. Назначением свидетельства описания архитектуры является предоставление описания следующих аспектов автоматизированной системы:

а) определение подсистем, составляющих автоматизированную систему;

b) внутренние и внешние интерфейсы для подсистем и выполняемые функции, предоставляемые посредством идентифицированных интерфейсов;

c) соединения между подсистемами и поток информации между подсистемами, проходящий через эти соединения;

d) внешние автоматизированные системы, с которыми сопряжена данная автоматизированная система и взаимосвязи между данной автоматизированной системой и этими внешними автоматизированными системами;

e) межсоединения для внешних автоматизированных систем и поток информации, проходящий между данной автоматизированной системой и внешними автоматизированными системами через эти межсоединения;

f) меры защиты и осуществление правильного функционирования мер обеспечения безопасности.

С.5.2.2 Ранжирование компонентов

Семейство состоит из одного компонента.

С.5.2.3 ASD_SAD.1 Описание архитектуры

Зависимости: зависимости отсутствуют.

С.5.2.3.1 Элементы действий разработчика/интегратора

ASD_SAD.1.1D Разработчик/интегратор должен обеспечить описание архитектуры.

С.5.2.3.2 Элементы содержания и представления свидетельств

ASD_SAD.1.1C Описание архитектуры должно определять автоматизированную систему, исходя из ее подсистем, интерфейсов и соединений между подсистемами.

ASD_SAD.1.2C Описание архитектуры должно определять внешние автоматизированные системы, взаимосвязанные с данной автоматизированной системой, и интерфейсы и соединения между данной автоматизированной системой и внешними автоматизированными системами.

ASD_SAD.1.3C В описании архитектуры должны излагаться назначение и функции идентифицированных подсистем, межсоединения и интерфейсы данной автоматизированной системы.

ASD_SAD.1.4C В описании архитектуры должны излагаться назначение идентифицированных межсоединений и интерфейсов от данной автоматизированной системы внешним автоматизированным системам, а также услуги, предоставляемые внешним автоматизированным системам, и услуги, предоставляемые этими системами.

ASD_SAD.1.5C В описании архитектуры должны излагаться все характеристики безопасности автоматизированной системы, которые переносятся одним элементом архитектуры на другие, включая меры защиты мер обеспечения безопасности от несанкционированного раскрытия, модификации, уничтожения или обхода.

ASD_SAD.1.6C В описании архитектуры должны излагаться механизмы самозащиты мер обеспечения безопасности.

ASD_SAD.1.7C Описание архитектуры должно быть внутренне согласованным.

С.5.2.3.3 Элементы действий оценщика

ASD_SAD.1.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

С.5.3 Функциональная спецификация интерфейсов (ASD_IFS)

С.5.3.1 Цели

Назначением функциональной спецификации интерфейсов автоматизированной системы является обеспечение описания функций безопасности автоматизированной системы, доступных на видимых интерфейсах, и их характеристики безопасности.

С.5.3.2 Ранжирование компонентов

Данное семейство состоит из одного компонента.

С.5.3.3 ASD_IFS.1 Функциональная спецификация интерфейсов

Зависимости: ASD_SAD.1 Описание архитектуры.

С.5.3.3.1 Элементы действий разработчика/интегратора

ASD_IFS.1.1D Разработчик/интегратор должен обеспечить функциональную спецификацию интерфейсов.

С.5.3.3.2 Элементы содержания и представления свидетельств

ASD_JFS.1.1С В функциональной спецификации интерфейсов должны идентифицироваться и излагаться все видимые интерфейсы автоматизированной системы, включая функции безопасности, доступные через эти интерфейсы, и характеристики безопасности этих интерфейсов.

ASD_IFS.1.2С Функциональная спецификация интерфейсов должна быть внутренне согласованной.

С.5.3.3.3 Элементы действий оценщика

ASD_IFS.1.1Е Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

ASD_IFS.1.2Е Оценщик должен подтвердить соответствие функциональной спецификации интерфейсов описанию архитектуры.

С.5.4 Проект подсистем (ASD_SSD)

С.5.4.1 Цели

Целью свидетельства проектирования подсистем является обеспечение описания:

а) подсистем;

b) распределения функций безопасности по подсистемам;

c) характеристик безопасности каждой подсистемы;

d) интерфейсов каждой подсистемы и функций, выполняемых через каждый интерфейс;

e) компонентов, из которых состоит каждая подсистема.

С.5.4.2 Ранжирование компонентов

Данное семейство состоит из одного компонента.

С.5.4.3 ASD_SSD.1 Проектирование подсистем

Зависимости:

ASD_SAD.1 Описание архитектуры;

ASD_IFS.1 Функциональная спецификация интерфейсов.

С.5.4.3.1 Элементы действий разработчика/интегратора

ASD_SSD.1.1D Разработчик/интегратор должен обеспечить проектирование подсистемы.

ASD_SSD.1.2D Разработчик/интегратор должен обеспечить отображение проектирования подсистемы в проектирование архитектуры.

С.5.4.3.2 Элементы содержания и представления свидетельств

ASD_SSD.1.1C В проектировании подсистем должны излагаться функциональные возможности безопасности, обеспечиваемые каждой подсистемой.

ASD_SSD.1.2C В проектировании подсистем должны быть определены все аппаратные средства, программно-аппаратные средства и программное обеспечение, требуемые для выполнения функций безопасности, распределенных подсистеме.

ASD_SSD.1.3 С В проектировании подсистем должны быть определены интерфейсы к каждой подсистеме.

ASD_SSD.1.4C В проектировании подсистем должны быть определены характеристики безопасности для каждой подсистемы.

ASD_SSD.1.5C В проектировании подсистем должны быть определены интерфейсы к каждой подсистеме, исходя из их назначения и метода использования воздействий, исключений и сообщений об ошибках.

ASD_SSD.1.6C В проектировании подсистем должны быть определены компоненты, из которых состоит каждая подсистема.

ASD_SSD.1.7C Проектирование подсистемы должен быть внутренне согласовано.

ASD_SSD.1.8C Проектирование подсистем должно быть полной иллюстрацией функциональных возможностей безопасности, включая специфические для доменов функции.

ASD_SSD.1.9C Отражение проектирования подсистемы на проектирование архитектуры должно демонстрировать наличие всех элементов проектирования архитектуры в проектировании подсистемы.

С.5.4.3.3 Элементы действий оценщика

ASD_SSD.1.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

ASD_SSD.1.2E Оценщик должен подтвердить совместимость проектирования подсистемы с описанием архитектуры и функциональной спецификацией интерфейсов.

С.5.5 Проектирование компонентов (ASD_CMP)

С.5.5.1 Цели

Целью свидетельства проектирования компонента является обеспечение описания.

а) назначения и функций каждого компонента автоматизированной системы;

b) распределения функциональных возможностей безопасности каждому компоненту;

c) характеристик безопасности каждой подсистемы;

d) интерфейсов подсистемы, обеспечиваемых каждым компонентом;

e) функциональных возможностей, обеспечиваемых посредством идентифицированных интерфейсов для компонента;

f) способа обеспечения функциональных возможностей безопасности и характеристик безопасности каждого компонента.

С.5.5.2 Ранжирование компонентов

Данное семейство состоит из одного компонента.

С.5.5.3 ASD_CMP.1 Проектирование компонентов

Зависимости:

ASD_IFS.1 Функциональная спецификация интерфейсов;

ASD_SSD.1 Проектирование подсистем.

С.5.5.3.1 Элементы действий разработчика/интегратора

ASD_CMP.1.1D Разработчик/интегратор должен обеспечить проектирование компонента.

ASD_CMP.1.2D Разработчик/интегратор должен обеспечить отображение проектирования компонентов в проектирование подсистемы.

ASD_CMP.1.3D Разработчик/интегратор должен обеспечить анализ согласованности краткой спецификации СОО.

С.5.5.3.2 Элементы содержания и представления свидетельств

ASD_CMP.1.1C В проектировании компонента должны излагаться назначение и функции компонентов каждой подсистемы.

ASD_CMP.1.2C В проектировании компонента должны быть определены взаимосвязи между компонентами в каждой подсистеме.

ASD_CMP.1.3C В проектировании компонента должны идентифицироваться интерфейсы для подсистемы автоматизированной системы, которым соответствует каждый компонент.

ASD_CMP.1.4C В проектировании компонента должны описываться интерфейсы для подсистемы автоматизированной системы, которым соответствует каждый компонент, исходя из их назначения и метода использования.

ASD_CMP.1.5C В проектировании компонента должны излагаться функциональные возможности безопасности, обеспечиваемые каждым компонентом.

ASD_CMP.1.6С В проектировании компонента должны идентифицироваться характеристики безопасности каждого компонента.

ASD_CMP.1.7C В проектировании компонента должно излагаться то, как обеспечиваются функциональные возможности безопасности и характеристики безопасности каждого компонента.

ASD_CMP1.8C Проектирование компонентов каждой подсистемы должно быть внутренне согласованным.

ASD_CMP.1.9C Проектирование компонентов каждой подсистемы должно обеспечить полную иллюстрацию функциональных возможностей безопасности, назначенных этой подсистеме, включая специфические для доменов функции.

ASD_CMP1.10С Отражение проектирования компонентов на проектирование подсистемы должно демонстрировать наличие всех элементов проектирования подсистемы в проектировании компонентов.

ASD_CMP.1.11C Анализ согласованности краткой спецификации СОО должен продемонстрировать согласованность проектирования компонентов с описанием внедрения ФБС и ДБС в краткую спецификацию СОО и все краткие спецификации доменов СОО.

С.5.5.3.3 Элементы действий оценщика

ASD_CMP.1.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

ASD_CMP.1.2E Оценщик должен определить согласованность проектирования компонентов с проектированием подсистемы и функциональной спецификацией интерфейса.

С.5.6 Представление реализации (ASD_IMP)

С.5.6.1 Цели

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

С.5.6.2 Замечания по применению

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

С.5.6.3 Ранжирование компонентов

Данное семейство состоит из одного компонента.

С.5.6.4 ASD_IMP.1 Описание реализации

Зависимости: ASD_CMP.1 Проектирование компонентов.

С.5.6.4.1 Элементы действий разработчика/интегратора

ASD_IMP.1D Разработчик/интегратор должен обеспечить описание реализации проектирования компонентов.

С.5.6.4.2 Элементы содержания и представления свидетельств

ASD_IMP.1.1C В описании реализации должна быть приведена полная реализация проектирования компонентов, включая все выполняемые функции безопасности и характеристики безопасности, назначенные этому компоненту.

ASD_IMP.1.2C В описании реализации должны быть определены выполняемые функции безопасности, обеспечиваемые каждым компонентом, исходя из его конкретных требований к конфигурации.

ASD_IMP.1.3C Описание реализации должно быть внутренне согласованным.

С.5.6.4.3 Элементы действий оценщика

ASD_IMP.1.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

С.5.7 Концепция безопасности функционирования (ASD_CON)

С.5.7.1 Цели

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

С.5.7.2 Замечания по применению

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

С.5.7.3 Ранжирование компонентов

Данное семейство состоит из одного компонента.

С.5.7.4 ASD_CON.1 Концепция безопасности операций

Зависимости: ASD_SAD.1 Описание архитектуры.

С.5.7.4.1 Элементы действий разработчика/интегратора

ASD_CON.1.1D Разработчик/интегратор должен обеспечить документацию концепции безопасности операций, охватывающую все ФБС.

С.5.7.4.2 Элементы содержания и представления свидетельств

ASD_CON.1.1C Концепция безопасности операций должна обладать степенью детализации, сопоставимой со степенью детализации описания интерфейсов, свойств и механизмов безопасности, предусмотренных в архитектурном проектировании.

ASD_CON.1.2C В документацию концепции безопасности операций должны быть включены все режимы работы автоматизированной системы (например, режим архивации или ухудшенный режим работы).

ASD_CON.1.3C Документация концепции безопасности операций должна быть внутренне согласованной.

ASD_CON.1.4C В документации концепции безопасности операций должно быть описано поддержание доменов безопасности автоматизированной системы способом, согласующимся с требованиями безопасности системы.

ASD_CON.1.5C Документация концепции безопасности операций должна демонстрировать предотвращение процессом инициализации ФБС обхода, создания помех или умышленного нанесения ущерба при установлении функций выполнения требований безопасности системы.

ASD CON.1.6C Документация концепции безопасности операций должна демонстрировать самозащиту ФБС от помех и фальсифицирования.

ASD_CON.1.7C Документация концепции безопасности операций должна демонстрировать предотвращение обхода функций выполнения требований безопасности системы.

ASD_CON.1.8C Документация концепции безопасности операций должна демонстрировать то, что потоки информации между доменами безопасности автоматизированной системы и между данной автоматизированной системой и внешними автоматизированными системами не обходят, не создают помехи или не наносят ущерб функций выполнения требований безопасности системы.

С.5.7.4.3 Элементы действий оценщика

ASD_CON.1.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

ASD_CON.1.2E Оценщик должен определить, является ли архитектурное проектирование полной и правильной реализацией концепции безопасности функционирования автоматизированной системы в поддержку выполняемой целевой задачи.

С.5.8 Верификация проектной документации (ASD_GVR)

С.5.8.1 Цели

Целью является демонстрация правильности проектной документации по безопасности после внесения изменений в компоненты системы или их модификации.

С.5.8.2 Ранжирование компонентов

Данное семейство состоит из одного компонента.

С.5.8.3 ASD_GVR.1 Проверка проектной документации

Зависимости:

ASD_SAD.1 Описание архитектуры;

ASD_IFS.1 Функциональная спецификация интерфейсов;

ASD_SSD.1 Проектирование подсистем;

ASD_CMP.1 Проектирование компонентов;

ASD_CON.1 Концепция безопасности компонентов.

С.5.8.3.1 Цели

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

С.5.8.3.2 Замечания по применению

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

С.5.8.3.3 Элементы действий разработчика/интегратора

ASD_GVR.1.1D После внесения изменений или модификаций в компоненты системы, ее конфигурацию или среду эксплуатации разработчик/интегратор должен провести верификационный анализ для проверки того, осталась ли проектная документация автоматизированной системы правильной и согласованной.

С.5.8.3.4 Элементы содержания и представления свидетельств

ASD_GVR.1.1C По каждому проектному документу верификационный анализ должен показать, не подвергался ли документ воздействию изменений или модификаций или был ли должным образом обновлен для отражения изменений или модификаций.

С.5.8.3.5 Элементы действий оценщика

ASD_GVR.1.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

С.6 Класс АОС: управление конфигурацией автоматизированных систем

С.6.1 Введение

Целью управления конфигурацией во время оценки является обеспечение доверия к тому, что у оценщика имеется правильная версия всех компонентов автоматизированной системы для других действий по оценке. Следовательно, это управление применимо к мерам в пределах среды разработки и интеграции, но не среды эксплуатации, где она имеет отличия. После разворачивания и интегрирования автоматизированной системы оцененная система управления конфигурацией остается в среде разработки и интеграции.

Управление конфигурацией может осуществлять контроль за оцененными и неоцененными продуктами в автоматизированных системах.

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

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

С.6.2 (АОС_ОВМ) Базовая конфигурация автоматизированной системы

С.6.2.1 Цели

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

С.6.2.2 Ранжирование компонентов

Данное семейство состоит из двух компонентов. Компоненты семейства распределяются на основе подтверждения описания документации и проверок в автоматизированной системе.

С.6.2.3 АОС_ОВМ.1 Базовая конфигурация автоматизированной системы

Зависимости: зависимости отсутствуют.

С.6.2.3.1 Элементы действий разработчика/интегратора

AOC_OBM.1.1D Для исходной/самой последней оцененной системы разработчик/интегратор должен использовать систему управления конфигурацией (УК), которая называется "База".

AOC_OBM.1.2D Система УК должна отслеживать и контролировать каждое изменение, предлагаемое для Базы и внесенное в нее, и состояние ее оценки.

AOC_OBM.1.3D Система УК должна сообщать о текущей конфигурации Базы автоматизированной системы.

AOC_OBM.1.4D Разработчик/интегратор/владелец системы должен предоставлять документацию по УК Базы системы.

С.6.2.3.2 Элементы содержания и представления свидетельств

АОС_ОВМ.1.1С Система УК должна однозначно определять Базу СОО, каждое связанное с ней изменение и состояние ее оценки.

АОС_ОВМ.1.2С В плане УК должно излагаться то, как поддерживается База системы и как отслеживаются и управляются изменения в Базе.

С.6.2.3.3 Элементы действий оценщика

ASD_OBM.1.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

С.6.2.4 ASD_OBM.2 Проверка базовой конфигурации автоматизированной системы

Является иерархической для: АОС_ОВМ.1 Базовая конфигурация автоматизированной системы.

Зависимости: зависимости отсутствуют.

С.6.2.4.1 Элементы действий разработчика/интегратора

AOC_OBM.2.1D Для исходной/самой последней оцененной системы разработчик/интегратор должен использовать систему УК, которая называется "База".

AOC_OBM.2.2D Система УК должна отслеживать и контролировать каждое изменение, предлагаемое для Базы и внесенное в нее, и состояние ее оценки.

AOC_OBM.2.3D Система УК должна сообщать о текущей конфигурации Базы автоматизированной системы.

AOC_OBM.2.4D Разработчик/интегратор/владелец системы должен предоставлять документацию по УК Базы системы.

С.6.2.4.2 Элементы содержания и представления свидетельств

АОС_ОВМ.2.1С Система УК должна однозначно определять Базу СОО, каждое связанное с ней изменение и состояние ее оценки.

АОС_ОВМ.2.2С В плане УК должно излагаться то, как поддерживается База системы и как отслеживаются и управляются изменения в Базе.

С.6.2.4.3 Элементы действий оценщика

ASD_OBM.2.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

ASD_OBM.2.1E Оценщик должен независимо проверять посредством опросов персонала, выборки изменений, других методов достоверности системы УК.

С.6.3 Оцененные продукты компонентов (АОС_ЕСР)

С.6.3.1 Цели

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

С.6.3.2 Ранжирование компонентов

С.6.3.3 AOC_ECP.1 Оцененные продукты компонентов

Зависимости: АОС_ОВМ.1 Конфигурация базы автоматизированной системы

С.6.3.3.1 Элементы действий разработчика/интегратора

AOC_ECP1.1D Разработчик/интегратор должен определять оцененные пакеты доверия для продуктов компонентов или доменов безопасности, содержащих такие продукты.

AOC_ECP.1.2D Разработчик/интегратор должен устанавливать эксплуатационные параметры для каждого продукта компонентов.

С.6.3.3.2 Элементы содержания и представления свидетельств

АОС_ЕСР.1.1С В плане УК должны описываться оцененные пакеты доверия для продуктов компонентов или доменов безопасности, содержащих такие продукты.

АОС_ЕСР.1.2С Должны быть определены отчет о результатах оценки или уведомление о независимой сертификации и ЗБ для оцененных продуктов.

АОС_ЕСР.1.3С В плане УК должны быть указаны эксплуатационные параметры для каждого продукта компонента.

С.6.3.3.3 Элементы действий оценщика

ASD_ECP1.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

С.6.3.4 АОС_ЕСР.2 Проверка оцененных продуктов компонентов

Является иерархическим для: АОС_ЕСР.1 Оцененные продукты компонентов.

Зависимости: АОС_ОВМ.1 Конфигурация базы автоматизированной системы.

С.6.3.4.1 Элементы действий разработчика/интегратора

ASD_ECP.2.1D Разработчик/интегратор должен определять оцененные пакеты доверия для продуктов компонентов или доменов безопасности, содержащих такие продукты.

AOC_ECP.2.2D Разработчик/интегратор должен устанавливать эксплуатационные параметры для каждого продукта компонентов.

C.6.3.4.2 Элементы содержания и представления свидетельств

AOC_ECR2.1C В плане УК должны быть указаны оцененные пакеты доверия для продуктов компонентов или доменов безопасности, содержащих такие продукты.

АОС_ЕСР.2.2С. Должны быть определены отчет о результатах оценки или уведомление о независимой сертификации и ЗБ для оцененных продуктов.

АОС_ЕСР.2.3С В плане УК должны быть указаны эксплуатационные параметры для каждого продукта компонента.

С.6.3.4.3 Элементы действий оценщика

ASD_ECP.2.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

ASD_ECP.2.2E Оценщик должен подтвердить соответствие условий эксплуатации, изложенных в отчете о результатах оценки или отчете о независимой сертификации, требованиям среды эксплуатации автоматизированной системы.

С.6.4 Соответствие ПЗ (АОС_РРС)

С.6.4.1 Цели

Данное семейство определяет требования доверия к согласованию с конкретным ПЗ. Предъявляемым свидетельством является уведомление о сертификации, включая приемлемое ЗБ. В среде эксплуатации продукты компонентов могут иметь специфические параметры. Такие параметры должны быть четко определены.

С.6.4.2 Ранжирование компонентов

Данное семейство состоит из двух компонентов. Компоненты семейства распределяются на основе подтверждения описания документации и проверок автоматизированной системы.

С.6.4.3 АОС_РРС1 Согласование с ПЗ

Зависимости: АОС_ОВМ.1 Конфигурация базы автоматизированной системы.

С.6.4.3.1 Элементы действий разработчика/интегратора

AOC_PPC.1.1D Разработчик/интегратор должен обозначить ПЗ для продуктов компонентов, с которыми они должны быть согласованы.

AOC_PPC.1.2D Разработчик/интегратор должен устанавливать эксплуатационные параметры для каждого продукта компонента.

С.6.4.3.2 Элементы содержания и представления свидетельств

АОС_РРС.1.1С В плане УК должны быть определены ПЗ для продуктов компонентов, с которыми они должны быть согласованы.

АОС_РРС.1.2С Должны быть определены отчет о результатах оценки или уведомление о независимой сертификации и ЗБ для оцененных продуктов.

АОС_РРС.1.3С В плане УК должны быть определены эксплуатационные параметры для каждого продукта компонентов.

С.6.4.3.3 Элементы действий оценщика

ASD_PPC.1.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

С.6.4.4 АОС_РРС Согласование с проверкой ПЗ Является иерархическим для:АОС_РРС. согласование с ПЗ.

Зависимости: АОС_ОВМ.1 Конфигурация базы автоматизированной системы.

С.6.4.4.1 Элементы действий разработчика/интегратора

AOC_PPC.2.1D Разработчик/интегратор должен обозначить ПЗ для продуктов компонентов, с которыми они должны быть согласованы.

AOC_PPC.2.2D Разработчик/интегратор должен устанавливать эксплуатационные параметры для каждого продукта компонента.

С.6.4.4.2 Элементы содержания и представления свидетельств

АОС_РРС.2.1С В плане УК должны быть определены ПЗ для продуктов компонентов, с которыми они должны быть согласованы.

АОС_РРС.2.2С Должны быть определены отчет о результатах оценки или уведомление о независимой сертификации и ЗБ для оцененных продуктов.

АОС_РРС.2.3С В плане УК должны быть определены эксплуатационные параметры для каждого продукта компонентов.

С.6.4.4.3 Элементы действий оценщика

ASD_PPC.2.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

ASD_PPC.2.2E Оценщик должен подтвердить соответствие условий эксплуатации, изложенных в отчете о результатах оценки или отчете о независимой сертификации, требованиям среды эксплуатации автоматизированной системы.

С.6.5 Неоцененные продукты компонентов (AOC_NCP)

С.6.5.1 Цели

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

В среде эксплуатации компоненты, состоящие из продуктов, могут иметь специфические параметры. Подобные параметры должны быть четко определены.

С.6.5.2 Ранжирование компонентов

Данное семейство состоит из двух компонентов. Компоненты семейства распределяются на основе подтверждения описания документации и проверки автоматизированной системы.

С.6.5.3 AOC_NCP.1 Неоцененные продукты компонентов

Зависимости: АОС_ОВМ.1 Конфигурация базы автоматизированной системы.

С.6.5.3.1 Элементы действий разработчика/интегратора

AOC_NCP.1.1D Разработчик/интегратор/владелец системы должен определять необходимые пакеты доверия для продуктов компонентов или доменов безопасности, содержащих подобные продукты.

AOC_NCP.1.2D Разработчик/интегратор/оператор системы должен устанавливать эксплуатационные параметры для каждого продукта компонента.

С.6.5.3.2 Элементы содержания и представления свидетельств

AOC_NCP.1.1C В плане УК должны описываться оцененные пакеты доверия для продуктов компонентов или доменов безопасности, содержащих такие продукты.

AOC_NCP.1.2C В плане УК должны быть определены эксплуатационные параметры для каждого продукта компонентов.

С.6.5.3.3 Элементы действий оценщика

AOC_NCP.1.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

С.6.5.4 AOC_NCP.2 Проверка неоцененных продуктов компонентов

Является иерархическим для: AOC_NCP.1 Неоцененные продукты компонентов.

Зависимости: АОС_ОВМ.1 Конфигурация базы автоматизированной системы.

С.6.5.4.1 Элементы действий разработчика/интегратора

AOC_NCP.2.1D Разработчик/интегратор/владелец системы должен определять необходимые пакеты доверия для продуктов компонентов или доменов безопасности, содержащих подобные продукты.

AOC_NCP.2.2D Разработчик/интегратор/оператор системы должен устанавливать эксплуатационные параметры для каждого продукта компонента.

С.6.5.4.2 Элементы содержания и представления свидетельств

АОС_NCP.2.1С В плане УК должны описываться оцененные пакеты доверия для продуктов компонентов или доменов безопасности, содержащих такие продукты.

AOC_NCP.2.2C В плане УК должны быть определены эксплуатационные параметры для каждого продукта компонентов.

С.6.5.4.3 Элементы действий оценщика

AOC_NCP.2.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

AOC_NCP.2.2E Оценщик должен провести оценку и подтвердить, что продукты соответствуют требуемым пакетам доверия в среде эксплуатации автоматизированной системы.

С.7 Класс АОТ: тестирование автоматизированных систем

С.7.1 Введение

Назначением данного класса является проверка соответствия компонентов автоматизированной системы, установленных, интегрированных и конфигурированных в соответствии с архитектурой и свидетельством конфигурации автоматизированной системы, функциональным требованиям безопасности, определенным в ЗБС, и эффективности выполнения концепции безопасности функционирования автоматизированной системы. Архитектура, интеграция и проектная документация автоматизированной системы содействуют в планировании и проведении испытаний. Это содействие определяется тем, что ФБС были сконфигурированы в соответствии со спецификацией конфигурации, испытаны в отношении к соответствующей архитектуре и свидетельству проекта при помощи выборки испытаний разработчика/интегратора и независимого испытания подгруппы (подмножества) ФБС.

С.7.2 Функциональное тестирование автоматизированной системы (AOT_FUN)

С.7.2.1 Цели

Назначением данного компонента является демонстрация разработчиком должного выполнения всех функций безопасности. Разработчик требуется также для проведения тестирования и обеспечения тестовой документации.

При функциональном тестировании, проводимом разработчиком и/или интегратором, устанавливается наличие у ФБС свойств, необходимых для удовлетворения функциональных требований ее ПЗ/ЗБ. Подобное функциональное тестирование обеспечивает доверие к тому, что ФБС соответствует, по крайней мере, функциональным требованиям безопасности, хотя ФБС не может установить, что ФБС не делает более того, что было установлено для нее. Семейство "Функциональные тесты" сфокусировано на типе или объеме документации или на необходимых инструментальных средствах поддержки, а также на том, что должно быть выявлено посредством тестирования разработчика. Функциональное тестирование не ограничивается положительным заключением о предоставлении требуемых функций безопасности, а может также включать в себя негативное тестирование для проверки отсутствия определенного нежелательного поведения (часто основанное на инверсии функциональных требований).

Семейство способствует обеспечению доверия к тому, что вероятность необнаруженных дефектов относительно мала.

Семейства AOT_COV, AOT_DPT и AOT_FUN используются в комбинации для определения свидетельства тестирования, представляемого разработчиком и/или интегратором. Независимое функциональное тестирование, проводимое оценщиком, определяется семейством AOT_IND.

С.7.2.2 Ранжирование компонентов

Данное семейство состоит из одного компонента.

С.7.2.3 Замечания по применению

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

Данное семейство устанавливает требования к представлению всех планов, процедур и результатов тестов. Количество информации, предназначенной для проведения тестирования, изменяется в соответствии с использованием семейств AOT_COV и AOT_DPT.

Зависимости упорядочения являются значимыми, когда успешное выполнение определенного теста зависит от наличия определенного состояния другого теста. Например, может потребоваться выполнение теста А непосредственно перед тестом В, поскольку состояние успешного выполнения теста А является предпосылкой успешного выполнения теста В, следовательно, сбой во время теста В может быть связан с проблемой, касающейся зависимостей упорядочения. В вышеприведенном примере отказ теста В мог быть результатом выполнения теста С (а не теста А) непосредственно перед ним, или сбой в тесте В мог быть связан со сбоем в тесте А.

С.7.2.4 AOT_FUN Функциональное тестирование

Зависимости: зависимости отсутствуют.

С.7.2.4.1 Элементы действий разработчика/интегратора

AOT_FUN.1.1D Разработчик/интегратор должен тестировать ФБС и документировать результаты.

AOT_FUN.1.2D Разработчик/интегратор должен обеспечивать тестовую документацию.

AOT_FUN.1.3D Разработчик/интегратор должен обеспечивать анализ уровня детализации и комплексного тестирования мер обеспечения безопасности.

С.7.2.4.2 Элементы содержания и представления свидетельств

AOT_FUN.1.1C Тестовая документация должна состоять из планов тестов, описания тестовых процедур, предполагаемых и фактических результатов тестов.

AOT_FUN.1.2C Анализ проверки мер обеспечения безопасности должен демонстрировать абсолютное соответствие между мерами обеспечения безопасности, определенными в ЗБ, и тестами, изложенными в тестовой документации.

AOT_FUN.1.3C В планах тестов должны быть определены функции безопасности, предназначенные для тестирования, и изложена цель тестов, предназначенных для выполнения.

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

AOT_FUN.1.5C В предполагаемых результатах тестов должны быть отражены ожидаемые выходные данные после успешного выполнения тестов.

AOT_FUN.1.6C Результаты тестов, выполненных разработчиком/интегратором, должны демонстрировать заданное поведение каждой тестируемой функции безопасности.

AOT_FUN.1.7C Тестовая документация должна включать в себя анализ зависимостей упорядочения тестовых процедур.

С.7.2.4.3 Элементы действий оценщика

AOC_FUN1.1Е Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

С.7.3 Покрытие тестами автоматизированной системы (AOT_COV)

С.7.3.1 Цели

Данное семейство рассматривает аспекты тестирования, связанные с полнотой покрытия тестами. То есть, оно рассматривает степень тестирования ФБС и достаточность этой степени для демонстрации работы ФБС заданным образом.

С.7.3.2 Ранжирование компонентов

Данное семейство состоит из двух компонентов. Эти компоненты распределяются на основе возрастающей строгости испытания интерфейсов и возрастающей строгости анализа достаточности тестов для демонстрации действия ФБС в соответствии с функциональной спецификацией ее интерфейса.

С.7.3.3 AOT_COV.1 Свидетельство покрытия тестами

Зависимости:

ASD_IFS.1 Функциональная спецификация интерфейса;

AOT_FUN.1 Функциональное тестирование.

С.7.3.3.1 Цели

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

С.7.3.3.2 Замечания по применению

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

Для данного компонента требуется разработчик/интегратор для демонстрации того, что идентифицированные тесты включают в себя тестирование всех видимых функций безопасности, как описано в функциональной спецификации интерфейса. Анализ должен не только показывать соответствие между тестами и функциями безопасности, но также обеспечивать оценщика информацией, достаточной для определения способа выполнения функций. Данная информация может применяться в планировании дополнительных тестов оценщика. Хотя на этом уровне разработчику/интегратору приходится демонстрировать, что каждая из функций в функциональной спецификации интерфейса была тестирована, объем тестирования не обязательно должен быть исчерпывающим.

С.7.3.3.3 Элементы действий разработчика/интегратора

AOT_COV.1.1D Разработчик/интегратор должен обеспечивать анализ покрытия тестами.

С.7.3.3.4 Элементы содержания и представления свидетельств

АОT_COV.1.1 С Анализ покрытия тестами должен демонстрировать соответствие между тестами, идентифицированными в тестовой документации, и ФБС, доступными посредством видимых интерфейсов автоматизированной системы, описанных в функциональной спецификации интерфейсов.

AOT_COV.1.2C Анализ покрытия тестами должен демонстрировать полноту соответствия между ФБС, доступными посредством видимых интерфейсов автоматизированной системы, описанных в функциональной спецификации интерфейсов, и тестами, идентифицированными в тестовой документации.

С.7.3.3.5 Элементы действий оценщика

AOC_COV1.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

С.7.3.4 AOC_COV.2 Строгий анализ покрытия тестами

Является иерархическим для: AOC_COV.1 Свидетельство покрытия тестами.

Зависимости:

ASD_IFS.1 Функциональная спецификация интерфейсов;

AOT_FUN.1 Функциональное тестирование.

С.7.3.4.1 Цели

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

С.7.3.4.2 Замечания по применению

Разработчик/интегратор требуется для предоставления убедительного аргумента - идентифицированные тесты охватывают все видимые функции безопасности, и тестирование каждой функции является полным. Для оценщика остается малое поле деятельности для разработки дополнительных функциональных тестов интерфейсов ФБС, основанных на функциональной спецификации интерфейса, иначе они были бы тестированы исчерпывающим образом. Тем не менее оценщик должен стремиться к созданию таких тестов.

С.7.3.4.3 Элементы действий разработчика/интегратора

AOC_COV.2.1D Разработчик/интегратор должен обеспечивать анализ покрытия тестами.

С.7.3.4.4 Элементы содержания и представления свидетельств

AOT_COV.2.1С Анализ покрытия тестами должен демонстрировать соответствие между тестами, идентифицированными в тестовой документации, и ФБС, доступными посредством видимых интерфейсов автоматизированной системы, описанных в функциональной спецификации интерфейсов.

AOT_COV.2.2C Анализ покрытия тестами должен демонстрировать полноту соответствия между ФБС, доступными посредством видимых интерфейсов автоматизированной системы, описанных в функциональной спецификации интерфейсов, и тестами, идентифицированными в тестовой документации.

AOT_COV.2.3C Анализ покрытия тестами должен строго демонстрировать, что все видимые интерфейсы для ФБС, указанные в функциональной спецификации интерфейсов, были полностью тестированы.

С.7.3.4.5 Элементы действий оценщика

AOC_COV2.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

С.7.4 Глубина тестирования автоматизированной системы (AOT_DPT)

С.7.4.1 Цели

Назначением компонентов данного семейства является установление степени детализации тестирования ФБС. Тестирование функций безопасности основано на растущей глубине информации, полученной из анализа представлений.

Целью тестирования является противодействие риску пропуска ошибки при разработке и интеграции СОО. Кроме того, вероятность обнаружения вредоносного кода компонентами этого семейства больше, особенно если тестирование связано с внутренней структурой ФБС.

Тестирование специфических внутренних интерфейсов может обеспечить доверие не только к тому, что ФБС демонстрирует нужное внешнее поведение в области безопасности, но также к тому, что это поведение основано на правильно функционирующих внутренних механизмах.

С.7.4.2 Ранжирование компонентов

Данное семейство состоит из трех компонентов. Компоненты распределяются на основе повышения детализации, установленной в представлениях ФБС, от проекта архитектуры до представления реализации. Это распределение отражает представления ФБС, установленные в классе ASD.

С.7.4.3 Замечания по применению

Конкретный объем, тип документации и свидетельство в общем определяются выбранным компонентом из AOT_FUN.

Тестирование на уровне функциональной спецификации интерфейсов осуществляется с помощью AOT_COV.

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

С.7.4.4 AOT_DPT.1 Тестирование: функциональная спецификация интерфейсов

Зависимости:

ASD_IFS.1 Функциональная спецификация интерфейсов;

AOT_FUN. 1 Функциональное тестирование.

С.7.4.4.1 Цели

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

С.7.4.4.2 Элементы действий разработчика/интегратора

AOT_DPT.1.1D Разработчик/интегратор должен обеспечивать анализ глубины тестирования.

С.7.4.4.3 Элементы содержания и представления свидетельств

AOT_DPT.1.1C Анализ глубины тестирования должен демонстрировать, что тестов, указанных в тестовой документации, достаточно для демонстрации функционирования ФБС в соответствии с ее функциональной спецификацией интерфейсов.

С.7.4.4.4 Элементы действий оценщика

AOT_DPT.1.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

С.7.4.5 AOT_DPT.2 Тестирование: проект подсистем

Является иерархическим для: AOT_DPT.1 Тестирование: функциональная спецификация интерфейсов.

Зависимости:

ASD_IFS.1 Функциональная спецификация интерфейсов;

ASD_SSD.1 Проект подсистем;

AOT_FUN.1 Функциональное тестирование.

С.7.4.5.1 Цели

Проект подсистем обеспечивает высокоуровневое описание внутренних действий ФБС. Тестирование на уровне подсистем обеспечивает доверие к правильности реализации подсистем ФБС.

С.7.4.5.2 Элементы действий разработчика/интегратора

AOT_DPT.2.1D Разработчик/интегратор должен обеспечивать анализ глубины тестирования.

С.7.4.5.3 Элементы содержания и представления свидетельств

AOT_DPT.2.1C Анализ глубины тестирования должен демонстрировать, что тестов, указанных в тестовой документации, достаточно для демонстрации функционирования ФБС в соответствии с ее функциональной спецификацией интерфейсов и проектом подсистем.

С.7.4.5.4 Элементы действий оценщика

AOT_DPT.2.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

С.7.4.6 AOT_DPT.3 Тестирование: проект компонентов

Является иерархическим для: AOT_DPT.2 Тестирование: проект подсистем.

Зависимости:

ASD_IFS.1 Функциональная спецификация интерфейсов;

ASD_SSD.1 Проект подсистем;

ASD_CMP.1 Проект компонентов;

AOT_FUN.1 Функциональное тестирование.

С.7.4.6.1 Цели

Проект компонентов обеспечивает подробное описание внутренних действий ФБС. Тестирование на уровне компонентов обеспечивает доверие к правильности реализации рабочего проекта ФБС.

С.7.4.6.2 Элементы действий разработчика/интегратора

AOT_DPT.3.1D Разработчик/интегратор должен обеспечивать анализ глубины тестирования.

С.7.4.6.3 Элементы содержания и представления свидетельств

AOT_DPT.3.1C Анализ глубины тестирования должен демонстрировать, что тестов, указанных в тестовой документации, достаточно для демонстрации функционирования ФБС в соответствии с ее функциональной спецификацией интерфейсов, с проектом подсистем и проектом компонентов.

С.7.4.6.4 Элементы действий оценщика

AOT_DPT.3.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

С.7.4.7 АОТ_ DPT.4 Тестирование: представление реализации

Является иерархическим для: AOT_DPT.3 Тестирование: проект компонентов.

Зависимости:

ASD_IFS.1 Функциональная спецификация интерфейсов;

ASD_SSD.1 Проект подсистем;

ASD_CMP.1 Проект компонентов;

ASD_IMP.1 Представление реализации;

AOT_FUN.1 Функциональное тестирование.

С.7.4.7.1 Цели

Представление реализации ФБС обеспечивает ее фактическое поведение. Тестирование на уровне представления реализации обеспечивает доверие к правильности всесторонней реализации релевантных ФБС.

С.7.4.7.2 Замечания по применению

Представление реализации используется для создания самой ФБС (например, исходный код, который затем компилируется).

С.7.4.7.3 Элементы действий разработчика/интегратора

AOT_DPT.4.1D Разработчик/интегратор должен обеспечивать анализ глубины тестирования.

С.7.4.7.4 Элементы содержания и представления свидетельств

AOT_DPT.4.1C Анализ глубины тестирования должен демонстрировать, что тестов, указанных в тестовой документации, достаточно для демонстрации функционирования ФБС в соответствии с ее функциональной спецификацией интерфейсов, с проектом подсистем, проектом компонентов и представлением реализации.

С.7.4.7.5 Элементы действий оценщика

AOT_DPT.4.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

С.7.5 Независимое тестирование (AOT_IND)

С.7.5.1 Цели

Целью независисмого тестирования является демонстрация должного выполнения функций безопасности.

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

С.7.5.2 Ранжирование компонентов

Данное семейство состоит из трех компонентов. Распределение основано на объеме тестовой документации, тестового обеспечения и объема тестирования оценщиком.

С.7.5.3 Замечания по применению

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

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

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

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

Независимое функциональное тестирование отличается от испытания на проникновение, если оно основывается на информированном и систематическом поиске уязвимостей в проекте и/или реализации. Испытание на проникновение осуществляется с помощью семейства AOV_VLA.

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

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

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

C.7.5.4 AOT_IND.1 Независимое тестирование-соответствие

Зависимости:

ASD_IFS.1 Функциональная спецификация интерфейсов;

AOD_ADM.1 Руководство администратора;

AOD_USR.1 Руководство пользователя.

С.7.5.4.1 Цели

В данном компоненте целью является демонстрация должного выполнения функций безопасности.

С.7.5.4.2 Замечания по применению

Данный компонент не занимается использованием результатов тестов разработчика. Компонент применим в случае отсутствия таких результатов, а также в случаях, если тестирование разработчика принимается без проверки достоверности. Оценщик требуется для разработки и проведения тестов с целью подтверждения соответствия функциональным требованиям безопасности СОО. Метод проведения тестов заключается в приобретении уверенности в правильности функционирования посредством репрезентативного тестирования вместо проведения каждого возможного теста. Число тестов, планирующихся для подтверждения соответствия фунцкио-нальным требованиям безопасности СОО, является методологической проблемой, и потребности в тестах должны рассматриваться в контексте конкретного СОО и равновесия и других действий по оценке.

С.7.5.4.3 Элементы действий разработчика/интегратора

AOT_IND.1.1D Разработчик/интегратор должен предоставлять СОО для тестирования.

С.7.5.4.4 Элементы содержания и представления свидетельств

AOT_IND.1.1C СОО должен быть пригодным для тестирования.

С.7.5.4.5 Элементы действий оценщика

AOT_IND.1.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

AOT_IND.2.1E Оценщик должен протестировать подгруппу ФБС на правильность для подтверждения должного функционирования СОО.

C.7.5.5 AOT_IND.2 Независимое тестирование-выборка

Является иерархическим для: AOT_IND.1 Независимое тестирование-соответствие.

Зависимости:

ASD_IFS.1 Функциональная спецификация интерфейсов;

AOD_ADM.1 Руководство администратора;

AOD_USR.1 Руководство пользователя;

AOT_FUN.1 Функциональное тестирование.

С.7.5.5.1 Цели

Целью является демонстрация должного выполнения функций безопасности.

Тестирование оценщиком включает в себя отбор и повторение выборки из тестов разработчика.

С.7.5.5.2 Замечания по применению

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

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

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

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

С.7.5.5.3 Элементы действий разработчика/интегратора

AOT_IND.2.1D Разработчик/интегратор должен предоставлять СОО для тестирования.

С.7.5.5.4 Элементы содержания и представления свидетельств

AOT_IND.2.1C СОО должен быть пригодным для тестирования.

AOT_IND.2.2C Разработчик/интегратор должен предоставлять набор ресурсов, эквивалентный тем, которые были использованы в функциональном тестировании ФБС разработчиком.

С.7.5.5.5 Элементы действий оценщика

AOT_IND.2.1E Оценщик должен подтверждать соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

AOT_IND.2.2E Оценщик должен протестировать подгруппу ФБС на правильность для подтверждения должного функционирования СОО.

AOT_IND.2.3E Оценщик должен провести выборку тестов в тестовой документации для проверки достоверности результатов тестов разработчика.

С.7.5.6 AOT_IND.3 Независимое тестирование-полнота

Является иерархическим для: AOT_IND.2 Независимое тестирование-выборка.

Зависимости:

ASD_IFS.1 Функциональная спецификация интерфейсов;

AOD_ADM.1 Руководство администратора;

AOD_USR.1 Руководство пользователя;

AOT_FUN.1 Функциональное тестирование.

С.7.5.6.1 Цели

Целью является демонстрация должного выполнения функций безопасности.

Тестирование оценщиком включает повторение всех тестов разработчика.

С.7.5.6.2 Замечания по применению

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

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

С.7.5.6.3 Элементы действий разработчика/интегратора

AOT_IND.3.1D Разработчик/интегратор должен предоставлять СОО для тестирования.

С.7.5.6.4 Элементы содержания и представления свидетельств

AOT_IND.3.1C СОО должен быть пригодным для тестирования.

AOT_IND.3.2C Разработчик/интегратор должен предоставлять набор ресурсов, эквивалентный тем, которые были использованы в функциональном тестировании ФБС разработчиком.

С.7.5.6.5 Элементы действий оценщика

AOT_IND.3.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

AOT_IND.3.2E Оценщик должен протестировать подгруппу ФБС на правильность для подтверждения должного функционирования СОО.

AOT_IND.3.3E Для проверки достоверности результатов тестов разработчика оценщик должен выполнить все тесты из тестовой документации.

С.7.6 Регрессионное тестирование (AOT_REG)

С.7.6.1 Цели

Целью является демонстрация должного выполнения функций безопасности после внесения изменений и модификаций в компоненты или конфигурацию системы или среду эксплуатации.

С.7.6.2 Ранжирование компонентов

Состоит из одного компонента.

С.7.6.3 AOT_REG.1 Регрессионное тестирование

Зависимости: зависимости отсутствуют.

С.7.6.3.1 Цели

Целью данного компонента является демонстрация должного выполнения функций безопасности после внесения изменений или модификаций в компоненты и конфигурацию системы или среду эксплуатации.

С.7.6.3.2 Замечания по применению

Этот компонент относится не только к проверке измененных или модифицированных частей автоматизированной системы.

С.7.6.3.3 Элементы действий разработчика/интегратора

AOT_REG.1.1D Разработчик/интегратор должен протестировать выборку тестов разработчика для ФБС и документировать результаты.

AOT_REG.1.2D Разработчик/интегратор должен предоставлять тестовую документацию.

AOT_REG.1.3D Разработчик/интегратор должен обеспечивать анализ степени детализации регрессионного тестирования.

С.7.6.3.4 Элементы содержания и представления свидетельств

AOT_REG.1.1C Тестовая документация должна состоять из планов тестов, описаний тестовых процедур, предполагаемых результатов тестов и фактических результатов.

AOT_REG.1.2C В планах тестов должны быть определены воздействия, вызванные изменениями или модификациями, функции безопасности, предназначенные для тестирования, и изложена цель предполагаемых тестов.

AOT_REG.1.3C В описаниях тестовых процедур должны определяться тесты для измененных или модифицированных частей и излагаться сценарии тестирования каждой функции безопасности. Сценарии тестирования должны включать в себя любые зависимости упорядочения от измененных частей и результаты других тестов.

AOT_REG.1.4C Результаты тестов, выполненных разработчиком/интегратором, должны демонстрировать должное функционирование каждой тестированной функции безопасности и отсутствие воздействия изменений или модификаций на ФБС.

AOT_REG.1.5C Тестовая документация должна включать в себя анализ зависимостей упорядочения тестовых процедур.

С.7.6.3.5 Элементы действий оценщика

AOT_REG.1.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

С.8 Класс AOV: анализ уязвимостей автоматизированных систем

С.8.1 Введение

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

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

С.8.2 Неправильное применение автоматизированной системы (AOV_MSU)

С.8.2.1 Цели

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

С.8.2.2 Замечания по применению

Противоречивое, дезориентирующее, неполное, неудобное для пользователя или необоснованное руководство может привести к формированию у пользователя СОО или любой из его подсистем или компонентов мнения о достаточной защищенности СОО или любой из его подсистем или компонентов, которая фактически отсутствует, и появлению вследствие этого уязвимостей.

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

Примером дезориентирующего руководства является описание одной инструкции, которая может толковаться по-разному, и одно из толкований может привести к состоянию незащищенности.

Примером неполного руководства является перечень значимых требований физической безопасности, в котором опущен критически важный пункт, что приводит к невыполнению этого пункта администратором, пользователем или обслуживающим персоналом, которые считают этот перечень полным.

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

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

Руководство является необходимым и может содержаться в существующей документации по СОО либо предоставляться отдельно. В последнем случае оценщик должен подтвердить поставку документации с СОО.

С.8.2.3 Ранжирование компонентов

Данное семейство состоит из двух компонентов. Эти компоненты ранжированы на основе подтверждения описания документации и проверке автоматизированной системы.

С.8.2.4 AOV_MSU.1 Проверка руководств автоматизированной системы

Зависимости:

AOD_ADM.1 Руководство администратора;

AOD_USR.1 Руководство пользователя.

С.8.2.4.1 Цели

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

С.8.2.4.2 Элементы действий разработчика/интегратора

AOV_MSU.1.1.D Разработчик/интегратор должен предоставлять документацию руководств.

AOV_MSU.1.2.D Разработчик/интегратор должен документировать анализ документации руководств.

С.8.2.4.3 Элементы содержания и представления свидетельств

AOV_MSU.1.1.C В документации руководств должны быть определены все возможные режимы функционирования СОО (включая операцию, следующую за отказом или эксплуатационной ошибкой), их последствия и воздействия для поддержания безопасного функционирования.

AOV_MSU.1.2.С Документация руководств должна быть полной, ясной, последовательной и обоснованной.

AOV_MSU.1.3.C В документации руководств должны быть указаны все организационные меры обеспечения безопасности.

AOV_MSU.1.4.С В документации руководств должны быть указаны все зависимости от безопасного функционирования внешних автоматизированных систем.

AOV_MSU.1.5.C В документации по анализу должна быть отражена степень полноты документации.

С.8.2.4.4 Элементы действий оценщика

AOT_MSU.1.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

AOT_MSU.1.2E Оценщик должен повторить все процедуры конфигурирования и установки для подтверждения, что СОО можно конфигурировать и использовать безопасно, только пользуясь поставленной документацией руководств.

AOT_MSU.1.3E Оценщик должен определить, что использование документации руководств позволяет выявлять все состояния незащищенности и восстанавливать их до состояния защищенности.

AOT_MSU.1.4E Оценщик должен подтвердить, что в документации анализа отражено предназначение руководств для безопасной работы во всех режимах функционирования СОО.

С.8.2.5 AOT_MSU.2 Анализ и тестирование незащищенных состояний

Является иерархическим для: AOV_MSU.1 Проверка руководства по автоматизированной системе.

Зависимости:

AOD_ADM.1 Руководство администраторов;

AOD_USR.1 Руководство пользователя.

С.8.2.5.1 Цели

Цель анализа и тестирования незащищенных состояний заключается в обеспечении отсутствия дезориентирующего, необоснованного и противоречивого руководства в документации по руководству и указания процедур защиты для всех режимов функционирования. Состояния незащищенности должны легко обнаруживаться. В данном компоненте анализ документации руководств оценщиком требуется для обеспечения дополнительного доверия к соответствию цели; этот анализ проверяется и его достоверность подтверждается посредством тестирования со стороны оценщика.

С.8.2.5.2 Замечания по применению

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

С.8.2.5.3 Элементы действий разработчика/интегратора

AOV_MSU.2.1.D Разработчик/интегратор должен предоставлять документацию руководства.

AOV_MSU.2.2.D Разработчик/интегратор должен документировать анализ документации руководства.

С.8.2.5.4 Элементы содержания и представления свидетельств

AOV_MSU.1.1.C В документации руководства должны быть определены все возможные режимы функционирования СОО (включая операцию, следующую за отказом или эксплуатационной ошибкой), их последствия и воздействия для поддержания безопасного функционирования.

AOV_MSU.1.2.C Документация руководств должна быть полной, ясной, последовательной и обоснованной.

AOV_MSU.1.3.С В документации руководств должны быть указаны все организационные меры безопасности.

AOV_MSU.1.5.C В документации по анализу должна быть отражена степень полноты документации.

С.8.2.5.5 Элементы действий оценщика

AOT_MSU.2.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

AOT_MSU.2.2E Оценщик должен повторить все процедуры конфигурирования и установки для подтверждения, что СОО можно конфигурировать и использовать безопасно, только пользуясь поставленной документацией руководств.

AOT_MSU.2.3E Оценщик должен определить, что использование документации руководств позволяет выявлять все состояния незащищенности и восстанавливать их до состояния защищенности.

AOT_MSU.2.4E Оценщик должен подтвердить, что в документации анализа отражено предназначение руководств для обеспечения безопасной работы во всех режимах функционирования СОО.

AOT_MSU.2.5E Оценщик должен проводить независимое тестирование для определения обоснованной способности администратора или пользователя, ознакомленного с документацией руководств, определять, конфигурирован ли и функционирует ли СОО безопасным образом.

С.8.3 Анализ уязвимостей (AOV_VLA)

С.8.3.1 Цели

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

С.8.3.2 Замечания по применению

Анализ уязвимостей проводится разработчиком/интегратором с целью определения наличия уязвимостей безопасности, и при анализе должно учитываться содержимое комплектующих узлов СОО. Расположение идентифицированных уязвимостей должно документироваться с тем, чтобы оценщик мог воспользоваться этой информацией при независимом тестировании на проникновение и/или проведении анализа уязвимостей.

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

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

Для систематического поиска уязвимостей требуется структурированная и повторяемая работа разработчика/интегратора в противоположность выявлению уязвимостей безструктурным (произвольным) методом.

Основным назначением независимого анализа уязвимостей оценщиком и связанного с ним тестирования на проникновение является сопротивляемость СОО атакам на проникновение, осуществляемым нарушителем, имеющим низкий (AOV_VLA.2), средний (AOV_VLA.3) или высокий (AOV_VLA.4) потенциал атаки. Оценщик должен предположить роль нарушителя с низким, средним или высоким (соответственно AOV_VLA2, AOV_VLA.3 или AOV_VLA.4) потенциалами атаки. Использование уязвимостей автоматизированной системы таким нарушителем должно рассматриваться оценщиком как "очевидные атаки проникновения" (по отношению к элементам AOV_VLA.*.2C) в контексте компонентов от AOV_VLA.2 до AOV_VLA.4.

С.8.3.3 Ранжирование компонентов

Данное семейство состоит из четырех компонентов. Эти компоненты распределяются на основе подтверждения анализа разработчиком/интегратором и глубины независимого анализа.

С.8.3.4 Анализ уязвимостей разработчиком_интегратором

Зависимости:

ASD_IFS.1 Функциональная спецификация интерфейсов;

ASD_SSD.1 Проект подсистем;

ASD_CON 1 Концепция безопасности функционирования;

AOD_ADM.1 Руководство администратора;

AOD_USR.1 Руководство пользователя.

С.8.3.4.1 Цели

Анализ уязвимостей проводится разработчиком/интегратором для выявления наличия очевидных уязвимостей и подтверждения невозможности их использования в предполагаемой среде СОО.

С.8.3.4.2 Замечания по применению

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

С.8.3.4.3 Элементы действий разработчика/интегратора

AOV_VLA.1.1D Разработчик/интегратор должен проводить и документировать анализ комплектующих узлов СОО для поиска очевидных путей, которыми пользователь может нарушить функции обеспечения безопасности.

AOV_VLA.1.2D Разработчик/интегратор должен документировать расположение очевидных уязвимостей.

С.8.3.4.4 Элементы содержания и представления свидетельств

AOV_VLA.1.1C В документации по всем выявленным уязвимостям должно быть указано о невозможности использования уязвимости в предполагаемой среде СОО.

С.8.3.4.5 Элементы действий оценщика

AOV_VLA.1.1E Оценщик должен подтверждать соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

AOV_VLA.1.2E Оценщик должен проводить тестирование на проникновение, построенное на анализе уязвимостей, проведенном разработчиком/интегратором, для обеспечения выявления очевидных уязвимостей.

С.8.3.5 AOV_VLA.2 Независимый анализ уязвимостей

Является иерархическим для: AOV_VLA.1 Анализ уязвимостей, проведенный разработчиком/интегратором.

Зависимости:

ASD_IFS.1 Функциональная спецификация интерфейсов;

ASD_SSD.1 Проект подсистем;

ASD_IMP.1 Представление реализации;

ASD_CON.1 Концепция безопасности функционирования;

AOD_ADM.1 Руководство администратора;

AOD_USR.1 Руководство пользователя.

С.8.3.5.1 Цели

Анализ уязвимостей проводится разработчиком/интегратором для установления наличия очевидных уязвимостей и подтверждения невозможности их использования в предполагаемой среде СОО.

Оценщик проводит независимое тестирование на проникновение, сопровождаемое независимым анализом уязвимостей оценщика, с целью определения сопротивляемости СОО атакам на проникновение, осуществляемым нарушителем с низким потенциалом атаки.

С.8.3.5.2 Элементы действий разработчика/интегратора

AOV_VLA.2.1 D Разработчик/интегратор должен проводить и документировать анализ комплектующих узлов СОО для поиска очевидных путей, которыми пользователь может нарушить функции обеспечения безопасности.

AOV_VLA.2.2D Разработчик/интегратор должен документировать расположение очевидных уязвимостей.

С.8.3.5.3 Элементы содержания и представления свидетельств

AOV_VLA.2.1C В документации по всем выявленным уязвимостям должно быть указано о невозможности использования уязвимости в предполагаемой среде СОО.

AOV_VLA.2.2C. B документации должно быть обоснование сопротивляемости СОО со всеми выявленными уязвимостями очевидным атакам на проникновение.

С.8.3.5.4 Элементы действий оценщика

AOV_VLA.2.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

AOV_VLA.2.2E Оценщик должен провести тестирование на проникновение, построенное на анализе уязвимостей, проведенном разработчиком/интегратором, для обеспечения указания выявленных уязвимостей.

AOV_VLA.2.3E Оценщик должен провести независимый анализ уязвимостей.

AOV_VLA.2.4E Оценщик должен провести независимое тестирование на проникновение, основанное на независимом анализе уязвимостей, для определения возможности использования дополнительно выявленных уязвимостей в предполагаемой среде.

AOV_VLA 2.5Е Оценщик должен определять сопротивляемость СОО атакам на проникновение, осуществляемым нарушителем с низким потенциалом атаки.

С.8.3.6 AOT_VLA.3 Средняя сопротивляемость

Является иерархическим для: AOV_VLA2 Независимый анализ уязвимостей.

Зависимости:

ASD_IFS.1 Функциональная спецификация интерфейсов;

ASD_SSD.1 Проект подсистем;

ASD_IMP.1 Представление реализации;

ASD_CON.1 Концепция безопасности функционирования;

AOD_ADM.1 Руководство администратора;

AOD_USR.1 Руководство пользователя.

С.8.3.6.1 Цели

С.8.3.6.2 Элементы действий разработчика/интегратора

AOV_VLA.3.1 D Разработчик/интегратор должен проводить и документировать анализ комплектующих узлов СОО для поиска очевидных путей, которыми пользователь может нарушить функции обеспечения безопасности.

AOV_VLA.3.2D Разработчик/интегратор должен документировать расположение очевидных уязвимостей.

С.8.3.6.3 Элементы содержания и представления свидетельств

AOV_VLA.3.1C В документации по всем выявленным уязвимостям должно быть указано о невозможности использования уязвимости в предполагаемой среде СОО.

AOV_VLA.3.2C.B документации должно быть обоснование сопротивляемости СОО со всеми выявленными уязвимостями очевидным атакам на проникновение.

AOV_VLA.3.3C В свидетельстве должна быть отражена систематичность поиска уязвимостей.

С.8.3.6.4 Элементы действий оценщика

AOV_VLA.3.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

AOV_VLA.3.2E Оценщик должен провести тестирование на проникновение, построенное на анализе уязвимостей, проведенном разработчиком/интегратором, для обеспечения указания выявленных уязвимостей.

AOV_VLA.3.3E Оценщик должен провести независимый анализ уязвимостей.

AOV_VLA.3.4E Оценщик должен провести независимое тестирование на проникновение, основанное на независимом анализе уязвимостей, для определения возможности использования дополнительно выявленных уязвимостей в предполагаемой среде.

AOV_VLA 3.5Е Оценщик должен определять сопротивляемость СОО атакам на проникновение, осуществляемым нарушителем со средним потенциалом атаки.

С.8.3.7 АОТ_VLA.4 Высокая сопротивляемость

Является иерархическим для: AOV_VLA.3 Средняя сопротивляемость.

Зависимости:

ASD_IFS.1 Функциональная спецификация интерфейсов;

ASD_SSD.1 Проект подсистем;

ASD_IMP.1 Представление реализации;

ASD_CON.1 Концепция безопасности функционирования;

AOD_ADM.1 Руководство администратора;

AOD_USR.1 Руководство пользователя.

С.8.3.7.1 Цели

С.8.3.7.2 Элементы действий разработчика/интегратора

AOV_VLA.4.1D Разработчик/интегратор должен проводить и документировать анализ комплектующих узлов СОО для поиска очевидных путей, которыми пользователь может нарушить функции обеспечения безопасности.

AOV_VLA.4.2D Разработчик/интегратор должен документировать расположение очевидных уязвимостей.

С.8.3.7.3 Элементы содержания и представления свидетельств

AOV_VLA.4.1C В документации по всем выявленным уязвимостям должно быть указано о невозможности использования уязвимости в предполагаемой среде СОО.

AOV_VLA.4.2C. B документации должно быть обоснование сопротивляемости СОО со всеми выявленными уязвимостями очевидным атакам на проникновение.

AOV_VLA.4.3C В свидетельстве должна быть отражена систематичность поиска уязвимостей.

AOV_VLA.4.4C В документации анализа должно содержаться обоснование полного охвата анализом комплектующих узлов СОО.

С.8.3.7.4 Элементы действий оценщика

AOV_VLA.4.1.E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

AOV_VLA.4.2E Оценщик должен провести тестирование на проникновение, построенное на анализе уязвимостей, проведенном разработчиком/интегратором, для обеспечения указания выявленных уязвимостей.

AOV_VLA.4.3E Оценщик должен провести независимый анализ уязвимостей.

AOV_VLA.4.4E Оценщик должен провести независимое тестирование на проникновение, основанное на независимом анализе уязвимостей, для определения возможности использования дополнительно выявленных уязвимостей в предполагаемой среде.

AOV_VLA.4.5E Оценщик должен определять сопротивляемость СОО атакам на проникновение, осуществляемым нарушителем с высоким потенциалом атаки.

С.9 Класс AOL: поддержка жизненного цикла автоматизированных систем

С.9.1 Введение

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

С.9.2 Определение мер обеспечения безопасности автоматизированной системы (AOL_DVS)

С.9.2.1 Цели

Данное семейство обеспечивает меры обеспечения безопасности во время разработки автоматизированной системы. При опытно-конструкторских работах должны соблюдаться конфиденциальность и целостность материалов, задействованных для разработки.

С.9.2.2 Ранжирование компонентов

Данное семейство состоит из двух компонентов. Эти компоненты распределяются на основе подтверждения описания в документации и проверок в автоматизированной системе.

С.9.2.3 AOL_DVS.1 Определение мер обеспечения безопасности

Зависимости: зависимости отсутствуют.

С.9.2.3.1 Элементы действий разработчика/интегратора

AOL_DVS.1.1D Разработчик/интегратор должен создавать документацию по безопасности разработки.

С.9.2.3.2 Элементы содержания и представления свидетельств

AOL_DVS.1.1C В документации по безопасности разработки должны быть изложены все физические, процедурные, относящиеся к персоналу, и другие меры обеспечения безопасности, необходимые для защиты конфиденциальности, аутентичности, надежности и целостности проекта и реализации СОО в его среде разработки и интеграции.

AOL_DVS.1.2C Документация по безопасности разработки должна предоставлять доказательство соблюдения этих мер обеспечения безопасности во время разработки и обслуживания СОО.

С.9.2.3.3 Элементы действий оценщика

AOL_DVS.1.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

С.9.2.4 AOL_DVS.2 Проверка мер обеспечения безопасности

Является иерархическим для: AOL_DVS.1 Определение мер обеспечения безопасности.

Зависимости: зависимости отсутствуют.

С.9.2.4.1 Элементы действий разработчика/интегратора

AOL_DVS.2.1D Разработчик/интегратор должен создавать документацию по безопасности разработки.

С.9.2.4.2 Элементы содержания и представления свидетельств

AOL_DVS.2.1C В документации по безопасности разработки должны быть изложены все физические, процедурные, относящиеся к персоналу и другие меры обеспечения безопасности, необходимые для защиты конфиденциальности, аутентичности, надежности и целостности проекта и реализации СОО в его среде разработки и интеграции.

AOL_DVS.2.2C Документация по безопасности разработки должна предоставлять доказательство соблюдения этих мер обеспечения безопасности во время разработки и обслуживания СОО.

С.9.2.4.3 Элементы действий оценщика

AOL_DVS.2.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

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

С.10 Класс ASI: безопасная установка (внедрение) систем

С.10.1 Введение

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

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

С.10.2 Осведомленность (ASI_AWA)

С.10.2.1 Цели

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

С.10.2.2 Ранжирование компонентов

С.10.2.3 ASI_AWA.1 Обучение с целью повышения осведомленности

Зависимости: зависимости отсутствуют.

С.10.2.3.1 Элементы действий руководства

ASI_AWA.1.1M Руководство должно проводить обучение с целью повышения осведомленности с формальным вводным курсом, предназначенным для ознакомления со всеми организационными мерами безопасности и ожидаемыми от них результатами, предоставляя персоналу доступ к активам автоматизированной системы до периода обучения во время или периодически.

С.10.2.3.2 Элементы содержания и представления свидетельств

ASI_AWA.1.1C Обучение с целью повышения осведомленности должно регистрироваться.

ASl_AWA.1.2C Записи должны содержать дату и время, персонал с правом доступа, обучаемый персонал, содержание и результаты обучения.

С.10.2.3.3 Элементы действий оценщика

ASI_AWA.1.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

С.10.2.4 ASI_AWA.2 Проверка обучения с целью повышения осведомленности

Является иерархическим для: ASI_AWA.1 Обучение с целью повышения осведомленности.

Зависимости: зависимости отсутствуют.

С.10.2.4.1 Элементы действий руководства

С.10.2.4.2 Элементы содержания и представления свидетельств

ASl_AWA.2.1C Обучение с целью повышения осведомленности должно документироваться.

ASI_AWA.2.2C Записи должны содержать дату и время, персонал с правом доступа, обучаемый персонал, содержание и результаты обучения.

С.10.2.4.3 Элементы действий оценщика

ASI_AWA.1.1Е Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

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

С.10.3 Доведение (ASI_CMM)

С.10.3.1 Цели

Данное семейство требует от руководства наличия определенных средств передачи документации руководства по эксплуатации, определяющую и предписывающую ФБС для соответствующего персонала.

С.10.3.2 Ранжирование компонентов

С.10.3.3 ASI_CMM.1 Информация о мерах обеспечения безопасности

Зависимости: зависимости отсутствуют.

С.10.3.3.1 Элементы действий руководства

ASI_CMM.1.1M Руководство должно передавать все ФБС всему персоналу, имеющему отношение к организационным мерам безопасности, перед предоставлением им доступа к активам автоматизированной системы.

С.10.3.3.2 Элементы содержания и представления свидетельств

ASI_CMM.1.1C Обучение осведомленности должно документироваться.

ASI_CMM.1.2C Записи должны содержать дату и время, персонал с правом доступа, обучаемый персонал, содержание и результаты обучения.

С.10.3.3.3 Элементы действий оценщика

ASI_CMM.1.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

С.10.3.4 ASI_CMM.2 Проверка достоверности информации о мерах обеспечения безопасности

Является иерархическим для: ASI_CMM.1 Информация о мерах обеспечения безопасности

Зависимости: зависимости отсутствуют.

С.10.3.4.3 Элементы действий руководства

ASI_CMM.2.1M Руководство должно передавать соответствующие ФБС персоналу, имеющему отношение к организационным мерам безопасности, перед предоставлением им доступа к конкретным активам автоматизированной системы.

ГАРАНТ:

Нумерация пунктов приводится в соответствии с источником

С.10.3.4.2 Элементы содержания и представления свидетельств

ASI_CMM.2.1C Обучение осведомленности должно документироваться.

ASI_CMM.2.2C Записи должны содержать дату и время, персонал с правом доступа, обучаемый персонал, содержание и результаты обучения.

С.10.3.4.3 Элементы действий оценщика

ASI_CMM.2.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

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

С.10.4 Проверка безопасной установки (ASI_SIC)

С.10.4.1 Цели

Данное семейство предоставляет средства проверки установки и пуска СОО. Осуществление установки, пуска СОО и управление ими, должны быть правильными и эффективными в соответствии с политикой безопасности автоматизированной системы.

С.10.4.2 Ранжирование компонентов

С.10.4.3 ASI_SIC.1 Проверка безопасной установки

Зависимости: зависимости отсутствуют.

С.10.4.3.1 Элементы действий руководства

ASI_SIC.1.1M Разработчик/интегратор должен документировать процедуры безопасной установки, необходимые для обеспечения возможности безопасной инсталляции, пуска и взаимодействия компонентов и интерфейсов, составляющих СОО, особенно связанных с унаследованными мерами обеспечения безопасности и интерфейсами.

С.10.4.3.2 Элементы содержания и представления свидетельств

ASI_SIC.1.1C В документации по безопасной установке должны излагаться шаги, необходимые для проверки безопасной установки, пуска и взаимодействия СОО в его среде.

С.10.4.3.3 Элементы действий оценщика

ASI_SIC.1.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

С.10.4.4 ASl_SIC.2 Верификация проверки безопасной установки

Является иерархическим для: ASI_SIC.1 Проверка безопасной установки.

Зависимости: зависимости отсутствуют.

С.10.4.4.1 Элементы действий руководства

ASI_SIC.2.1M Разработчик/интегратор должен документировать процедуры безопасной установки, необходимые для обеспечения возможности безопасной инсталляции, пуска и взаимодействия компонентов и интерфейсов, составляющих СОО, особенно связанных с унаследованными мерами обеспечения безопасности и интерфейсами.

С.10.4.4.2 Элементы содержания и представления свидетельств

ASI_SIC.2.1C В документации по безопасной установке должны излагаться шаги, необходимые для проверки безопасной установки, пуска и взаимодействия СОО в его среде.

С.10.4.4.3 Элементы действий оценщика

ASI_SIC.2.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

ASI_.SIC.2.2E Оценщик должен верифицировать, что результатом процедур безопасной установки является безопасная конфигурация.

С.11 Класс ASO: Регистрация и запись в автоматизированных системах

С.11.1 Введение

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

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

Семейства данного класса определяют для руководства средства мониторинга и проверки организационных мер безопасности.

С.11.2 Записи об организационных мерах безопасности (ASO_RCD)

С.11.2.1 Цели

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

С.11.2.2 Ранжирование компонентов

С.11.2.3 ASO_RCD.1 Запись о функционировании организационных мер безопасности

Зависимости: зависимости отсутствуют.

С.11.2.3.1 Элементы действий руководства

ASO_RCD.1.М Руководство должно регистрировать свидетельства эксплуатации, определенные всеми организационными мерами безопасности.

С.11.2.3.2 Элементы содержания и представления свидетельств

ASO_RCD.1.1C Информация, связанная со свидетельством эксплуатации, должна регистрироваться.

ASO_RCD.12С В записях должны указываться дата и время, ответственное лицо, задействованные организационные меры безопасности и результаты функционирования.

С.11.2.3.3 Элементы действий оценщика

ASO_RCD.1.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

С.11.2.4 ASO_RCD.2 Проверка записей эксплуатации

Является иерархическим для: ASO_RCD.1 Запись о функционировании организационных мер безопасности.

Зависимости: зависимости отсутствуют.

С.11.2.4.1 Элементы действий менеджмента

ASO_RCD.2.1M Руководство должно регистрировать свидетельства эксплуатации, определенные (все или по выбору) организационные меры безопасности.

С.11.2.4.2 Элементы содержания и представления свидетельств

ASO_RCD.2.1C Информация, связанная со свидетельством эксплуатации, должна регистрироваться.

ASO_RCD.2.2C В записях указывают дату и время, ответственное лицо, задействованные организационные меры безопасности и результаты функционирования.

С.11.2.4.3 Элементы действий оценщика

ASI_.RCD.2.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

ASI_RCD.2.2E Оценщик должен осуществлять независимую проверку посредством опросов персонала, выборок из записей эксплуатации и других методов, правильность регистрации информации, относящейся к функционированию организационных мер безопасности.

С.11.3 Верификация организационных мер безопасности (ASO_VER)

С.11.3.1 Цели

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

С.11.3.2 Ранжирование компонентов

С.11.3.3 ASO_VER.1 Проверка организационных мер безопасности

Зависимости: зависимости отсутствуют.

С.11.3.3.1 Элементы действий руководства

ASO_VER.1.1M Руководство должно проверять все организационные меры безопасности на правильность и эффективность установки и функционирования.

С.11.3.3.2 Элементы содержания и представления свидетельств

ASO_VER.1.1C Информация, связанная с проверкой, должна регистрироваться.

ASO_VER.1.2C В записях должны указываться дата и время и ответственное лицо, задействованные организационные меры безопасности и результаты проверки.

С.11.3.3.3 Элементы действий оценщика

ASl_VER.1.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

С.11.3.4 ASO_VER.2 Независимая проверка организационных мер безопасности

Является иерархическим для: ASO_VER. Проверка организационных мер безопасности.

Зависимости: зависимости отсутствуют.

С.11.3.4.1 Элементы действий руководства

ASO_VER.2.1M Руководство должно проверять (все или по выбору) организационные меры безопасности на правильность и эффективность установки и функционирования.

С.11.3.4.2 Элементы содержания и представления свидетельств

ASO_VER.2.1C Информация, связанная с проверкой, должна регистрироваться.

ASO_VER.2.2C В записях должны указываться дата и время и ответственное лицо, а также запланированные организационные меры безопасности и результаты проверки.

С.11.3.4.3 Элементы действий оценщика

ASI_VER.2.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

ASI_VER.2.2E Оценщик должен осуществлять независимую проверку посредством опросов персонала, выборки из организационных мер безопасности и других методов, правильность и эффективность установки и функционирования организационных мер безопасности.

С.11.4 Мониторинг организационных мер безопасности (ASO_MON)

С.11.4.1 Цели

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

С.11.4.2 Ранжирование компонентов

С.11.4.3 ASO_MON.1 Мониторинг организационных мер безопасности руководством

Зависимости: зависимости отсутствуют.

С.11.4.3.1 Элементы действий руководства

ASO_MON.1.1M Руководство должно через одинаковые промежутки времени контролировать средства обеспечения и уровни производительности всех организационных мер безопасности.

ASO_MON.1.2M Руководство должно контролировать внесение изменений в предоставление услуг, включая поддержание и усовершенствование политик, процедур и мер обеспечения безопасности с учетом критичности задействованных бизнес-систем и бизнес-процессов и повторной оценки рисков.

С.11.4.3.2 Элементы содержания и представления свидетельств

ASO_MON.1.1C Информация, связанная с мониторингом, должна регистрироваться.

ASO_MON.1.2C В записях должны указываться дата и время и ответственное лицо, а также запланированные организационные меры безопасности и результаты проверки.

С.11.4.3.3 Элементы действий оценщика

ASO_MON.1.1E Оценщик должен подтвердить соответствие представленной информации всем требованиям к содержанию и представлению свидетельств.

С.11.4.4 ASO_MON.2 Верификация мониторинга организационных мер безопасности

Является иерархическим для: ASO_MON.1 Мониторинг организационных мер безопасности руководством.

Зависимости: зависимости отсутствуют.

С.11.4.4.1 Элементы действий руководства

ASO_MON.2.1M Руководство должно через одинаковые промежутки времени контролировать средства обеспечения и уровни производительности всех организационных мер безопасности.

ASO_MON.2.2M Руководство должно контролировать внесение изменений в предоставление услуг, включая поддержание и усовершенствование политик, процедур и мер обеспечения безопасности с учетом критичности задействованных бизнес-систем, бизнес-процессов и повторной оценки рисков.

С.11.4.4.2 Элементы содержания и представления свидетельств

ASO_MON.1.1C Информация, связанная с мониторингом, должна регистрироваться.

С.11.4.4.3 Элементы действий оценщика

ASI_MON.2.2Е Оценщик должен осуществлять независимую проверку (посредством опросов персонала, выборки изменений и другими методами) соответствия проведения мониторинга политике безопасности.

<< Приложение В (обязательное). Функциональные требования безопасности автоматизированных систем		Приложение >> D (справочное). Взаимосвязь с разработкой Общих критериев
	Содержание Национальный стандарт РФ ГОСТ Р ИСО/МЭК ТО 19791-2008 "Информационная технология. Методы и средства обеспечения безопасности....

Приложение С (обязательное). Требования доверия к безопасности автоматизированной системы

ГАРАНТ:

ГАРАНТ:

Откройте актуальную версию документа прямо сейчас