ГОСТ Р ИСО МЭК 15408-3 2007 (1027766), страница 29
Текст из файла (страница 29)
Повторение всех тестов, выполненных разработчиком, может быть осуществимо и желательно в некоторых случаях, но весьма затруднено и менее продуктивно в других. Поэтому самый высокий по иерархии компонент этого семейства следует использовать осторожно. При формировании выборки рассматривается весьдиапазон применения результатов тестирования, включая обеспечение выполнения требованийсемейств ATE_COV «Покрытие» и ATE_DPT «Глубина».Необходимо также принять во внимание, что при оценке могут использоваться разные конфигурации ОО. Оценщику необходимо будет проанализировать применимость предоставленныхрезультатов и в соответствии с этим планировать свое собственное тестирование.Независимое функциональное тестирование отличается от тестирования проникновения,основанного на целенаправленном и систематическом поиске уязвимостей в проекте и/или реализации.
Тестирование проникновения рассмотрено в семействе AVA_VLA «Анализ уязвимостей».Пригодность ОО для тестирования основана на доступности ОО и поддержке документациейи информацией, необходимой для выполнения тестов (включая любое тестовое программноеобеспечение или инструментальные средства тестирования). Необходимость в такой поддержкеотражена в зависимостях от других семейств доверия.Кроме того, пригодность ОО для тестирования может основываться на других соображениях.Например, версия ОО, представленная разработчиком, может быть не окончательной.Ссылки на подмножество ФБО предназначены для того, чтобы позволить оценщику проектировать приемлемую совокупность тестов, которая согласована с целями проводимой оценки.17.4.4ATE_IND.1Независимое тестирование на соответствиеЗависимости: ADV_FSP.1 Неформальная функциональная спецификацияAGD_ADM.1 Руководство администратора125ГОСТ Р ИСО/МЭК 15408-3—…(проект, окончательная редакция)AGD_USR.1 Руководство пользователя17.4.4.1 ЦелиЦелью является демонстрация выполнения функций безопасности в соответствии со спецификациями.17.4.4.2 Замечания по применениюЭтот компонент не ориентирован на использование результатов тестирования разработчиком.
Он применим, когда такие результаты недоступны, а также в случае, когда тестирование, выполненное разработчиком, принимается без проверки. От оценщика требуется разработать и выполнить тесты с целью подтверждения, что функциональные требования безопасности ОО удовлетворены. При этом подходе уверенность в правильном функционировании приобретается черезрепрезентативное тестирование, а не через выполнение всех возможных тестов. Объем тестирования, планируемый для этой цели, является методологической проблемой, и его необходиморассматривать в контексте конкретного ОО и в сопоставлении с другими действиями оценки.17.4.4.3 Элементы действий разработчика17.4.4.3.1ATE_IND.1.1DРазработчик должен представить ОО для тестирования.17.4.4.4 Элементы содержания и представления свидетельств17.4.4.4.1ATE_IND.1.1CОО должен быть пригоден для тестирования.17.4.4.5 Элементы действий оценщика17.4.4.5.1ATE_IND.1.1EОценщик должен подтвердить, что представленная информация удовлетворяет всемтребованиям к содержанию и представлению свидетельств.17.4.4.5.2ATE_IND.1.2EОценщик должен протестировать подмножество ФБО так, чтобы подтвердить, что ООфункционирует в соответствии со спецификациями.17.4.5ATE_IND.2Выборочное независимое тестированиеЗависимости: ADV_FSP.1 Неформальная функциональная спецификацияAGD_ADM.1 Руководство администратораAGD_USR.1 Руководство пользователяATE_FUN.1 Функциональное тестирование17.4.5.1 ЦелиЦелью является демонстрация выполнения функций безопасности в соответствии со спецификациями.
Тестирование, проводимое оценщиком, включает в себя отбор и повторение тестов,выполненных разработчиком.17.4.5.2 Замечания по применениюРазработчику следует предоставить оценщику материалы, необходимые для эффективноговоспроизведения тестов, выполненных разработчиком. Сюда могут быть включены такие материалы, как машиночитаемая тестовая документация, тест-программы и т.д.Этот компонент содержит требование, чтобы оценщику были доступны результаты тестирования разработчиком для дополнения программы тестирования.
Оценщик повторит выборку изтестов, выполненных разработчиком, чтобы получить уверенность в полученных результатах. Получив такую уверенность, оценщик расширит тестирование, выполненное разработчиком, проводядополнительные испытания ОО способом, отличающимся от примененного разработчиком. Осно-126ГОСТ Р ИСО/МЭК 15408-3—…(проект, окончательная редакция)вываясь на подтверждении достоверности результатов тестов, выполненных разработчиком,оценщик способен убедиться, что ОО функционирует правильно в более широком диапазоне условий, чем это было бы возможно для разработчика, ограниченного уровнем его ресурсов. Убедившись в том, что разработчик протестировал ОО, оценщик будет также иметь больше свободыдля концентрации тестирования в тех направлениях, где экспертиза документации или специальные знания вызвали определенную настороженность.17.4.5.3 Элементы действий разработчика17.4.5.3.1ATE_IND.2.1DРазработчик должен представить ОО для тестирования.17.4.5.4 Элементы содержания и представления свидетельств17.4.5.4.1ATE_IND.2.1CОО должен быть пригоден для тестирования.17.4.5.4.2ATE_IND.2.2CРазработчик должен представить набор ресурсов, эквивалентных использованнымим при функциональном тестировании ФБО.17.4.5.5 Элементы действий оценщика17.4.5.5.1ATE_IND.2.1EОценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.17.4.5.5.2ATE_IND.2.2EОценщик должен протестировать подмножество ФБО так, чтобы подтвердить, что ОО функционирует в соответствии со спецификациями.17.4.5.5.3ATE_IND.2.3EОценщик должен выполнить выборку тестов из тестовой документации, чтобы верифицировать результаты тестирования, полученные разработчиком.17.4.6ATE_IND.3Полное независимое тестированиеЗависимости: ADV_FSP.1 Неформальная функциональная спецификацияAGD_ADM.1 Руководство администратораAGD_USR.1 Руководство пользователяATE_FUN.1 Функциональное тестирование17.4.6.1 ЦелиЦелью является демонстрация выполнения всех функций безопасности в соответствии соспецификациями.
Тестирование, проводимое оценщиком, включает в себя повторное выполнениевсех тестов, выполненных разработчиком.17.4.6.2 Замечания по применениюРазработчику следует предоставить оценщику материалы, необходимые для эффективноговоспроизведения тестов, выполненных разработчиком. Сюда могут быть включены такие материалы, как машиночитаемая тестовая документация, тест-программы и т.д.В этом компоненте требуется, чтобы оценщик повторил все тесты, выполненные разработчиком, как часть программы тестирования. Как и в предыдущем компоненте, оценщик проведетдополнительные испытания, стремясь проверить ОО способом, отличным от использованногоразработчиком.
В случае, когда тестирование разработчиком было исчерпывающим, для этого могут оставаться небольшие возможности.127ГОСТ Р ИСО/МЭК 15408-3—…(проект, окончательная редакция)17.4.6.3 Элементы действий разработчика17.4.6.3.1ATE_IND.3.1DРазработчик должен представить ОО для тестирования.17.4.6.4 Элементы содержания и представления свидетельств17.4.6.4.1ATE_IND.3.1CОО должен быть пригоден для тестирования.17.4.6.4.2ATE_IND.3.2CРазработчик должен представить набор ресурсов, эквивалентных использованным им прифункциональном тестировании ФБО.17.4.6.5 Элементы действий оценщика17.4.6.5.1ATE_IND.3.1EОценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.17.4.6.5.2ATE_IND.3.2EОценщик должен протестировать подмножество ФБО так, чтобы подтвердить, что ОО функционирует в соответствии со спецификациями.17.4.6.5.3ATE_IND.3.3EОценщик должен выполнить все тесты из тестовой документации, чтобы верифицироватьрезультаты тестирования, полученные разработчиком.128ГОСТ Р ИСО/МЭК 15408-3—…(проект, окончательная редакция)18Класс AVA: Оценка уязвимостейКласс AVA связан с наличием пригодных для использования скрытых каналов и с возможностью неправильного применения или конфигурирования ОО, а также с возможностью преодолениявероятностных или перестановочных механизмов безопасности и использованием уязвимостей,вносимых при разработке или эксплуатации ОО.На рисунке 15 показаны семейства этого класса и иерархия компонентов в семействах.AVA_CCA Анализ скрытых каналов123AVA_MSU Неправильноеприменение123AVA_SOF Стойкость функцийбезопасности ОО1AVA_VLA Анализ уязвимостей1234Рисунок 15 –Декомпозиция класса AVA: «Оценка уязвимостей»18.1 Анализ скрытых каналов (AVA_CCA)18.1.1ЦелиАнализ скрытых каналов выполняют с целью сделать заключение о существовании и потенциальной пропускной способности непредусмотренных каналов передачи сигналов (т.е.
неразрешенных информационных потоков), которые могут быть использованы.Требования доверия связаны с угрозой существования непредусмотренных и пригодных дляиспользования путей передачи сигналов, которые могут быть применены для нарушения ПФБ.18.1.2Ранжирование компонентовКомпоненты ранжированы по повышению строгости анализа скрытых каналов.18.1.3Замечания по применениюОценка пропускной способности канала основана на неформальных технических оценках, атакже на фактических результатах выполнения тестов.Примеры предположений, на которых основан анализ скрытых каналов, могут включать всебя быстродействие процессора, системную или сетевую конфигурацию, размер памяти, размеркэш-памяти.Выборочное подтверждение правильности анализа скрытых каналов путем тестированиядает оценщику возможность верифицировать любые аспекты анализа (такие, как идентификация,оценка пропускной способности, удаление, мониторинг, сценарии применения).
Это не требуетдемонстрации всех результатов анализа скрытых каналов.Если в ЗБ не содержатся никакие ПФБ управления информационными потоками, это семейство требований доверия не применяется, поскольку оно относится только к ПФБ управления информационными потоками.129ГОСТ Р ИСО/МЭК 15408-3—…(проект, окончательная редакция)18.1.4AVA_CCA.1 Анализ скрытых каналовЗависимости: ADV_FSP.2 Полностью определенные внешние интерфейсыADV_IMP.2 Реализация ФБОAGD_ADM.1 Руководство администратораAGD_USR.1 Руководство пользователя18.1.4.1 ЦелиЦелью является идентифицировать скрытые каналы, которые можно найти путем неформального поиска скрытых каналов.18.1.4.2 Элементы действий разработчика18.1.4.2.1AVA_CCA.1.1DРазработчик должен провести поиск скрытых каналов для каждой политики управления информационными потоками.18.1.4.2.2AVA_CCA.1.2DРазработчик должен представить документацию анализа скрытых каналов.18.1.4.3 Элементы содержания и представления свидетельств18.1.4.3.1AVA_CCA.1.1CДокументация анализа должна идентифицировать скрытые каналы и содержать оценку их пропускной способности.18.1.4.3.2AVA_CCA.1.2CДокументация анализа должна содержать описание процедур, используемых для вынесения заключения о существовании скрытых каналов, и информацию, необходимую дляанализа скрытых каналов.18.1.4.3.3AVA_CCA.1.3CДокументация анализа должна содержать описание всех предположений, сделанных впроцессе анализа скрытых каналов.18.1.4.3.4AVA_CCA.1.4CДокументация анализа должна содержать описание метода, используемого для оценки пропускной способности канала для случая наиболее опасного варианта сценария.18.1.4.3.5AVA_CCA.1.5CДокументация анализа должна содержать описание наиболее опасного варианта сценария использования каждого идентифицированного скрытого канала.18.1.4.4 Элементы действий оценщика18.1.4.4.1AVA_CCA.1.1EОценщик должен подтвердить, что представленная информация удовлетворяет всемтребованиям к содержанию и представлению свидетельств.18.1.4.4.2AVA_CCA.1.2EОценщик должен подтвердить, что результаты анализа скрытых каналов показывают,что ОО удовлетворяет функциональным требованиям.18.1.4.4.3AVA_CCA.1.3EОценщик должен выборочно подтвердить правильность результатов анализа скрытых каналов, применяя тестирование.130ГОСТ Р ИСО/МЭК 15408-3—…(проект, окончательная редакция)18.1.5AVA_CCA.2 Систематический анализ скрытых каналовЗависимости: ADV_FSP.2 Полностью определенные внешние интерфейсыADV_IMP.2 Реализация ФБОAGD_ADM.1 Руководство администратораAGD_USR.1 Руководство пользователя18.1.5.1 ЦелиЦелью является идентифицировать скрытые каналы, которые можно найти путем систематического поиска скрытых каналов.18.1.5.2 Замечания по применениюДля систематического анализа скрытых каналов требуется, чтобы разработчик идентифицировал скрытые каналы структурированным и повторяемым образом, в противоположность идентификации скрытых каналов частным методом, применимым для конкретной ситуации.18.1.5.3 Элементы действий разработчика18.1.5.3.1AVA_CCA.2.1DРазработчик должен провести поиск скрытых каналов для каждой политики управления информационными потоками.18.1.5.3.2AVA_CCA.2.2DРазработчик должен представить документацию анализа скрытых каналов.18.1.5.4 Элементы содержания и представления свидетельств18.1.5.4.1AVA_CCA.2.1CДокументация анализа должна идентифицировать скрытые каналы и содержать оценку ихпропускной способности.18.1.5.4.2AVA_CCA.2.2CДокументация анализа должна содержать описание процедур, используемых для вынесениязаключения о существовании скрытых каналов, и информацию, необходимую для анализа скрытыхканалов.18.1.5.4.3AVA_CCA.2.3CДокументация анализа должна содержать описание всех предположений, сделанных в процессе анализа скрытых каналов.18.1.5.4.4AVA_CCA.2.4CДокументация анализа должна содержать описание метода, используемого для оценки пропускной способности канала для случая наиболее опасного варианта сценария.18.1.5.4.5AVA_CCA.2.5CДокументация анализа должна содержать описание наиболее опасного варианта сценарияиспользования каждого идентифицированного скрытого канала.18.1.5.4.6AVA_CCA.2.6CДокументация анализа должна содержать свидетельство, что метод, использованныйдля идентификации скрытых каналов, является систематическим.18.1.5.5 Элементы действий оценщика18.1.5.5.1AVA_CCA.2.1EОценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.131ГОСТ Р ИСО/МЭК 15408-3—…(проект, окончательная редакция)18.1.5.5.2AVA_CCA.2.2EОценщик должен подтвердить, что результаты анализа скрытых каналов показывают, чтоОО удовлетворяет функциональным требованиям.18.1.5.5.3AVA_CCA.2.3EОценщик должен выборочно подтвердить правильность результатов анализа скрытых каналов, применяя тестирование.18.1.6AVA_CCA.3 Исчерпывающий анализ скрытых каналовЗависимости: ADV_FSP.2 Полностью определенные внешние интерфейсыADV_IMP.2 Реализация ФБОAGD_ADM.1 Руководство администратораAGD_USR.1 Руководство пользователя18.1.6.1 ЦелиЦелью является идентифицировать скрытые каналы, которые можно найти путем исчерпывающего поиска скрытых каналов.18.1.6.2 Замечания по применениюДля исчерпывающего анализа скрытых каналов требуется представление дополнительногосвидетельства, что план идентификации скрытых каналов достаточен для утверждения, что былииспробованы все возможные пути исследования скрытых каналов.18.1.6.3 Элементы действий разработчика18.1.6.3.1AVA_CCA.3.1DРазработчик должен провести поиск скрытых каналов для каждой политики управления информационными потоками.18.1.6.3.2AVA_CCA.3.2DРазработчик должен представить документацию анализа скрытых каналов.18.1.6.4 Элементы содержания и представления свидетельств18.1.6.4.1AVA_CCA.3.1CДокументация анализа должна идентифицировать скрытые каналы и содержать оценку ихпропускной способности.18.1.6.4.2AVA_CCA.3.2CДокументация анализа должна содержать описание процедур, используемых для вынесениязаключения о существовании скрытых каналов, и информацию, необходимую для анализа скрытыхканалов.18.1.6.4.3AVA_CCA.3.3CДокументация анализа должна содержать описание всех предположений, сделанных в процессе анализа скрытых каналов.18.1.6.4.4AVA_CCA.3.4CДокументация анализа должна содержать описание метода, используемого для оценки пропускной способности канала для случая наиболее опасного варианта сценария.18.1.6.4.5AVA_CCA.3.5CДокументация анализа должна содержать описание наиболее опасного варианта сценарияиспользования каждого идентифицированного скрытого канала.18.1.6.4.6132AVA_CCA.3.6CГОСТ Р ИСО/МЭК 15408-3—…(проект, окончательная редакция)Документация анализа должна содержать свидетельство, что метод, использованный дляидентификации скрытых каналов, является исчерпывающим.18.1.6.5 Элементы действий оценщика18.1.6.5.1AVA_CCA.3.1EОценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.18.1.6.5.2AVA_CCA.3.2EОценщик должен подтвердить, что результаты анализа скрытых каналов показывают, чтоОО удовлетворяет функциональным требованиям.18.1.6.5.3AVA_CCA.3.3EОценщик должен выборочно подтвердить правильность результатов анализа скрытых каналов, применяя тестирование.18.2 Неправильное применение (AVA_MSU)18.2.1ЦелиСемейство AVA_MSU позволяет установить, может ли ОО быть конфигурирован или использован опасным образом так, чтобы администратор или пользователь ОО обоснованно считал быего безопасным.Целями являются:a) минимизация вероятности конфигурирования или установки ОО опасным образом, исключающим возможность обнаружения пользователем или администратором;b) минимизация риска ошибок, обусловленных человеческим фактором или иными причинами, в операциях, которые могут блокировать, отключить или помешать активизировать функциибезопасности, приводя к необнаруженному опасному состоянию.18.2.2Ранжирование компонентовКомпоненты ранжированы по возрастанию числа свидетельств, представляемых разработчиком, и повышению строгости анализа.18.2.3Замечания по применениюПротиворечивое, вводящее в заблуждение, неполное или необоснованное руководство может убедить пользователя в безопасности ОО при ее отсутствии, что может привести к уязвимостям.Примером противоречия является наличие двух инструкций руководства, которые подразумевают различные выходные результаты при одних и тех же входных данных.Примером введения в заблуждение является такая формулировка инструкции руководства,которую можно трактовать неоднозначно, причем одна из трактовок может привести к опасномусостоянию.Примером неполноты является список существенных физических требований безопасности,в котором опущен важный пункт, что приведет к игнорированию соответствующего требования администратором, считающим список полным.Примером необоснованности является рекомендация следовать процедуре, приводящей кчрезмерной нагрузке по администрированию.Требуется наличие документации руководств.













