ГОСТ Р ИСО/МЭК 18045— 2008
оценщикделает заключение, дано ли логическое обоснование каждого такого усиления. Если подраздел
«Требования доверия к безопасности ОО» содержит требования доверия, сформулированные вявном виде,
оценщикделает заключение, приведено ли логическое обоснование использования каждого сформулиро
ванного в явном виде требования доверия.
Оценщикделает заключение, даноли в подразделе «Обоснование требований безопасности» доста
точно логичное обоснование, что требования доверия достаточны для изложенной среды безопасности и
целей безопасности. Например, если требуется защита от хорошо осведомленных нарушителей, то было
бы неприемлемым специфицировать компонентAVA_VLA.1 «Анализ уязвимостей разработчиком», который
является несвойственным для обнаружения недостатков безопасности, не являющихся очевидными.
Логическое обоснование может также включать в себя основания, подобные следующим:
a)специфические требования, установленные конкретной системойоценки, национальным правитель
ством или другими организациями;
b
) требования доверия, которые содержались в зависимостях функциональных требований безопас
ности ОО;
c) требования доверия систем и/или продуктов, предназначенных для совместного использования с
ОО:
d)требования потребителей.
Краткий обзор назначения и целей для каждого ОУД приведен в ИСО/МЭК 15408-3. подраздел 10.2.
Оценщику необходимо иметь в виду, что заключение о том. являются ли требования доверия прием
лемыми. может быть субъективным, а значит, анализ достаточности логического обоснования не следует
проводить слишком строго.
Если подраздел «Требования доверия к безопасности ОО» не содержит какой-либо ОУД. то данный
шаг оценивания может быть выполнен совместно с шагом оценивания APE_REQ.1-7.
8.3.5.3.9 Шаг оценивания APE_REQ.1-9
ИСО/МЭК 15408-3APE_REQ.1.5C: ПЗдолжен. принеобходимости, идентифицировать каждоетре
бование безопасности для среды ИТ.
Оценщикдолжен проверить, что в ПЗ. при необходимости, идентифицированы требования безопас
ности для среды ИТ.
Если ПЗ не содержит требований безопасности для среды ИТ, тоданный шагоценивания не применя
ют и поэтому считают удовлетворенным.
Оценщик делает заключение, все ли зависимости ОО от других ИТ в рамках его среды, направлен
ные на обеспечение каких-либо функциональных возможностей безопасности, чтобы достичь целей безо
пасности для ОО, четко идентифицированы в ПЗ как требования безопасности для среды ИТ.
Пример требований безопасности для среды ИТ— межсетевой экран полагается на базовую опера
ционную систему в части обеспечения аутентификации администраторов и долговременного хранения дан
ных аудита. В этом случае требования безопасности для среды ИТ обычно содержат компоненты из клас
сов FAU «Аудит безопасности» и FIA «Идентификация и аутентификация».
Необходимо отметить, что «Требования безопасности для среды ИТ» могут содержать как функцио
нальные требования, так и требования доверия.
Пример зависимости от среды ИТ — программный криптомодуль, который периодически проверяет
свой код и. вслучае обнаружения несанкционированной модификации, самоотключается. Для обеспече
ния возможности восстановления предусмотрено требование FPT_RCV.2 «Автоматическое восстановле
ние». Поскольку криптомодуль не может самостоятельно восстановить свой код после самоотключения, то
требование по восстановлению становится требованием к среде ИТ. Одной из зависимостей компонента
FPT_RCV.2 «Автоматическое восстановление» является компонент AGD_ADM.1 «Руководство админист
ратора». Следовательно, это требованиедоверия становится требованием доверия для среды ИТ.
Оценщику необходимо иметь в виду, что ссылка требований безопасности для среды ИТ на ФБО
относится к функциям безопасности среды, а не к функциям безопасности ОО.
8.3.5.3.10 Шагоценивания APE_REQ.1-10
ИСО/МЭК 15408-3 APE_REQ.1.6C: Все завершенные операции над требованиями безопасности
ИТ. включенными в ПЗ. должны быть идентифицированы.
Оценщикдолжен проверить,что все завершенные операции надтребованиями безопасности ИТ иден
тифицированы.
Допустимо, чтобы ПЗ содержал элементы с незавершенными операциями, т.е. ПЗ может содержать
формулировки функциональных требований безопасности, которые включают в себя незавершенные опе
рации «назначение» или «выбор». Данные операции должны быть впоследствии завершены в ЗБ. отобра-
21