"РУКОВОДЯЩИЙ ДОКУМЕНТ. БЕЗОПАСНОСТЬ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ. КРИТЕРИИ ОЦЕНКИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ " (Утв. Приказом Гостехкомиссии РФ от 19.06.2002 N 187)

14. Класс AVA. Оценка уязвимостей

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

На рисунке 14.1 показаны семейства этого класса и иерархия компонентов в семействах.

Класс AVA. Оценка уязвимостей
Класс AVA. Оценка уязвимостей

	AVA_CCA Анализ скрытых каналов	1	2	3
	AVA_CCA Анализ скрытых каналов	1	2	3

	AVA_MSU Неправильное применение	1	2	3
	AVA_MSU Неправильное применение	1	2	3

	AVA_SOF Стойкость функций безопасности ОО	1
	AVA_SOF Стойкость функций безопасности ОО	1

	AVA_VLA Анализ уязвимостей	1	2	3	4
	AVA_VLA Анализ уязвимостей	1	2	3	4

Рисунок 14.1 - Декомпозиция класса "Оценка уязвимостей"

14.1 Анализ скрытых каналов (AVA_CCA)

Цели

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

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

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

Компоненты ранжированы по повышению строгости анализа скрытых каналов.

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

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

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

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

Если в ЗБ не содержатся никакие ПФБ управления информационными потоками, это семейство требований доверия не применяют, поскольку оно относится только к ПФБ управления информационными потоками.

AVA_CCA.1 Анализ скрытых каналов

Цели

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

Зависимости

ADV_FSP.2 Полностью определенные внешние интерфейсы

ADV_IMP.2 Реализация ФБО

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

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

Элементы действий разработчика

AVA_CCA.1.1D Разработчик должен провести поиск скрытых каналов для каждой политики управления информационными потоками.

AVA_CCA.1.2D Разработчик должен представить документацию анализа скрытых каналов.

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

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

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

AVA_CCA.1.3C Документация анализа должна содержать описание всех предположений, сделанных в процессе анализа скрытых каналов.

AVA_CCA.1.4C Документация анализа должна содержать описание метода, используемого для оценки пропускной способности канала для случая наиболее опасного варианта сценария.

AVA_CCA.1.5C Документация анализа должна содержать описание наиболее опасного варианта сценария использования каждого идентифицированного скрытого канала.

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

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

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

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

AVA_CCA.2 Систематический анализ скрытых каналов

Цели

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

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

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

Зависимости

ADV_FSP.2 Полностью определенные внешние интерфейсы

ADV_IMP.2 Реализация ФБО

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

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

Элементы действий разработчика

AVA_CCA.2.1D Разработчик должен провести поиск скрытых каналов для каждой политики управления информационными потоками.

AVA_CCA.2.2D Разработчик должен представить документацию анализа скрытых каналов.

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

AVA_CCA.2.1C Документация анализа должна идентифицировать скрытые каналы и содержать оценку их пропускной способности.

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

AVA_CCA.2.3C Документация анализа должна содержать описание всех предположений, сделанных в процессе анализа скрытых каналов.

AVA_CCA.2.4C Документация анализа должна содержать описание метода, используемого для оценки пропускной способности канала для случая наиболее опасного варианта сценария.

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

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

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

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

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

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

AVA_CCA.3 Исчерпывающий анализ скрытых каналов

Цели

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

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

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

Зависимости

ADV_FSP.2 Полностью определенные внешние интерфейсы

ADV_IMP.2 Реализация ФБО

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

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

Элементы действий разработчика

AVA_CCA.3.1D Разработчик должен провести поиск скрытых каналов для каждой политики управления информационными потоками.

AVA_CCA.3.2D Разработчик должен представить документацию анализа скрытых каналов.

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

AVA_CCA.3.1C Документация анализа должна идентифицировать скрытые каналы и содержать оценку их пропускной способности.

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

AVA_CCA.3.3C Документация анализа должна содержать описание всех предположений, сделанных в процессе анализа скрытых каналов.

AVA_CCA.3.4C Документация анализа должна содержать описание метода, используемого для оценки пропускной способности канала для случая наиболее опасного варианта сценария.

AVA_CCA.3.5C Документация анализа должна содержать описание наиболее опасного варианта сценария использования каждого идентифицированного скрытого канала.

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

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

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

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

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

14.2 Неправильное применение (AVA_MSU)

Цели

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

Целями являются:

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

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

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

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

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

Противоречивое, вводящее в заблуждение, неполное или необоснованное руководство может убедить пользователя в безопасности ОО при ее отсутствии, что может привести к уязвимостям.

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

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

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

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

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

AVA_MSU.1 Экспертиза руководств

Цели

Зависимости

ADO_IGS.1 Процедуры установки, генерации и запуска

ADV_FSP.1 Неформальная функциональная спецификация

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

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

Элементы действий разработчика

AVA_MSU.1.1D Разработчик должен представить руководства по применению ОО.

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

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

AVA_MSU.1.2C Руководства должны быть полны, понятны, непротиворечивы и обоснованы.

AVA_MSU.1.3C Руководства должны содержать список всех предположений относительно среды эксплуатации.

AVA_MSU.1.4C Руководства должны содержать список всех требований к внешним мерам безопасности (включая внешний контроль над процедурами, физическими мерами и персоналом).

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

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

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

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

AVA_MSU.2 Подтверждение правильности анализа

Цели

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

Зависимости

ADO_IGS.1 Процедуры установки, генерации и запуска

ADV_FSP.1 Неформальная функциональная спецификация

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

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

Элементы действий разработчика

AVA_MSU.2.1D Разработчик должен представить руководства по применению ОО.

AVA_MSU.2.2D Разработчик должен задокументировать анализ руководств.

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

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

AVA_MSU.2.2C Руководства должны быть полны, понятны, непротиворечивы и обоснованы.

AVA_MSU.2.3CРуководства должны содержать список всех предположений относительно среды эксплуатации.

AVA_MSU.2.4C Руководства должны содержать список всех требований к внешним мерам безопасности (включая внешний контроль за процедурами, физическими мерами и персоналом).

AVA_MSU.2.5C Документация анализа должна демонстрировать, что руководства полны.

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

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

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

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

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

AVA_MSU.3 Анализ и тестирование опасных состояний

Цели

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

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

Зависимости

ADO_IGS.1 Процедуры установки, генерации и запуска

ADV_FSP.1 Неформальная функциональная спецификация

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

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

Элементы действий разработчика

AVA_MSU.3.1D Разработчик должен представить руководства по применению ОО.

AVA_MSU.3.2D Разработчик должен задокументировать анализ руководств.

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

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

AVA_MSU.3.2C Руководства должны быть полны, понятны, непротиворечивы и обоснованы.

AVA_MSU.3.3C Руководства должны содержать список всех предположений относительно среды эксплуатации.

AVA_MSU.3.4C Руководства должны содержать список всех требований к внешним мерам безопасности (включая внешний контроль за процедурами, физическими мерами и персоналом).

AVA_MSU.3.5C Документация анализа должна демонстрировать, что руководства полны.

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

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

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

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

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

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

14.3 Стойкость функций безопасности ОО (AVA_SOF)

Цели

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

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

В этом семействе имеется только один компонент.

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

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

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

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

AVA_SOF.1 Оценка стойкости функции безопасности ОО

Зависимости

ADV_FSP.1 Неформальная функциональная спецификация

ADV_HLD.1 Описательный проект верхнего уровня

Элементы действий разработчика

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

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

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

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

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

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

AVA_SOF.1.2E Оценщик должен подтвердить, что утверждения относительно стойкости корректны.

14.4 Анализ уязвимостей (AVA_VLA)

Цели

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

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

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

Ранжирование основано на повышении строгости анализа уязвимостей разработчиком и оценщиком.

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

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

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

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

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

Независимый анализ уязвимостей не ограничивается уязвимостями, идентифицированными разработчиком. Основная цель анализа, проводимого оценщиком, - сделать заключение, что ОО является стойким к нападениям проникновения со стороны нарушителя, обладающего низким (для AVA_VLA.2), умеренным (для AVA_VLA.3) или высоким (для AVA_VLA.4) потенциалом нападения. Для выполнения этой цели оценщик сначала проверяет возможности использования всех идентифицированных уязвимостей. Это осуществляется посредством тестирования проникновения. Оценщику следует принять на себя роль нарушителя с одним из указанным выше потенциалов нападения при попытке проникновения в ОО. Любое использование уязвимостей таким нарушителем оценщику следует рассматривать как "явное нападение проникновения" (в отношении элементов AVA_VLA.*.2C) в контексте компонентов AVA_VLA.2-4.

AVA_VLA.1 Анализ уязвимостей разработчиком

Цели

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

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

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

Зависимости

ADV_FSP.1 Неформальная функциональная спецификация

ADV_HLD.1 Описательный проект верхнего уровня

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

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

Элементы действий разработчика

AVA_VLA.1.1D Разработчик должен выполнить и задокументировать анализ поставляемых материалов ОО по поиску явных путей, которыми пользователь может нарушить ПБО.

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

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

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

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

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

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

AVA_VLA.2 Независимый анализ уязвимостей

Цели

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

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

Зависимости

ADV_FSP.1 Неформальная функциональная спецификация

ADV_HLD.2 Детализация вопросов безопасности в проекте верхнего уровня

ADV_IMP.1 Подмножество реализации ФБО

ADV_LLD.1 Описательный проект нижнего уровня

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

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

Элементы действий разработчика

AVA_VLA.2.1D Разработчик должен выполнить и задокументировать анализ поставляемых материалов ОО по поиску путей, которыми пользователь может нарушить ПБО.

AVA_VLA.2.2D Разработчик должен задокументировать местоположение идентифицированных уязвимостей.

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

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

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

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

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

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

AVA_VLA.2.3E Оценщик должен выполнить независимый анализ уязвимостей.

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

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

AVA_VLA.3 Умеренно стойкий

Цели

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

Зависимости

ADV_FSP.1 Неформальная функциональная спецификация

ADV_HLD.2 Детализация вопросов безопасности в проекте верхнего уровня

ADV_IMP.1 Подмножество реализации ФБО

ADV_LLD.1 Описательный проект нижнего уровня

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

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

Элементы действий разработчика

AVA_VLA.3.1D Разработчик должен выполнить и задокументировать анализ поставляемых материалов ОО по поиску путей, которыми пользователь может нарушить ПБО.

AVA_VLA.3.2D Разработчик должен задокументировать местоположение идентифицированных уязвимостей.

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

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

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

AVA_VLA.3.3C Свидетельство должно показать, что поиск уязвимостей является систематическим.

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

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

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

AVA_VLA.3.3E Оценщик должен выполнить независимый анализ уязвимостей.

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

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

AVA_VLA.4 Высокостойкий

Цели

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

Зависимости

ADV_FSP.1 Неформальная функциональная спецификация

ADV_HLD.2 Детализация вопросов безопасности в проекте верхнего уровня

ADV_IMP.1 Подмножество реализации ФБО

ADV_LLD.1 Описательный проект нижнего уровня

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

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

Элементы действий разработчика

AVA_VLA.4.1D Разработчик должен выполнить и задокументировать анализ поставляемых материалов ОО по поиску путей, которыми пользователь может нарушить ПБО.

AVA_VLA.4.2D Разработчик должен задокументировать местоположение идентифицированных уязвимостей.

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

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

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

AVA_VLA.4.3C Свидетельство должно показать, что поиск уязвимостей является систематическим.

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

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

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

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

AVA_VLA.4.3E Оценщик должен выполнить независимый анализ уязвимостей.

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

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