Последнее обновление: 24.04.2024
Законодательная база Российской Федерации
8 (800) 350-23-61
Бесплатная горячая линия юридической помощи
- Главная
- "МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ. КРИТЕРИИ ОЦЕНКИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ. Часть 3. ТРЕБОВАНИЯ ДОВЕРИЯ К БЕЗОПАСНОСТИ. ГОСТ Р ИСО/МЭК 15408-3-2008" (утв. Приказом Ростехрегулирования от 18.12.2008 N 521-ст)
18 Класс AVA. Оценка уязвимостей
Класс AVA "Оценка уязвимостей" связан с наличием при годных для использования скрытых каналов и возможностью неправильного применения или конфигурирования ОО, а также возможностью преодоления вероятностных или перестановочных механизмов безопасности и использованием уязвимостей, вносимых при разработке или эксплуатации ОО.
Декомпозиция класса AVA "Оценка уязвимостей" на составляющие его семейства и иерархия компонентов этих семейств показаны на рисунке 15.
18.1 Анализ, скрытых каналов (AVA_CCA)
18.1.1 Цели
Анализ скрытых каналов выполняют с целью сделать заключение о существовании и потенциальной пропускной способности непредусмотренных каналов передачи сигналов (то есть неразрешенных информационным потоков), которые могут быть использованы.
Требования доверия связаны с угрозой существования непредусмотренных и пригодных для использования путей передачи сигналов, которые могут быть применены для нарушения ПФБ.
18.1.2 Ранжирование компонентов
Компоненты ранжированы по повышению строгости анализа скрытых каналов.
18.1.3 Замечания по применению
Оценка пропускной способности канала основана на неформальных технических оценках, а также на фактических результатах выполнения тестов.
Примеры предположений, на которых основан анализ скрытых каналов, могут включать в себя быстродействие процессора, системную или сетевую конфигураций, размер памяти, размер кэш-памяти.
Выборочное подтверждение правильности анализа скрытых каналов путем тестирования дает оценщику возможность верифицировать любые аспекты анализа (такие как идентификация, оценка пропускной способности, удаление, мониторинг, сценарии применения). Это не требует демонстрации всех, результатов анализа скрытых каналов.
Если в ЗБ не содержатся ПФБ управления информационными потоками, данное семейство требований доверия не применяется, поскольку оно относится только к ПФБ управления информационными потоками.
18.1.4 AVA_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.1 AVA_CCA.1.1D
Разработчик должен провести поиск скрытых каналов для каждой политики управления информационными потоками.
18.1.4.2.2 AVA_CCA.1.2D
Разработчик должен представить документацию анализа скрытых каналов.
18.1.4.3 Элементы содержания и представления свидетельств
18.1.4.3.1 AVA_CCA.1.1С
Документация анализа должна идентифицировать скрытые каналы и содержать оценку их пропускной способности.
18.1.4.3.2 AVA_CСA.1.2C
Документация анализа должна содержать описание процедур, используемых для вынесения заключения о существовании скрытых каналов, и информацию, необходимую для анализа скрытых каналов.
18.1.4.3.3 AVA_CCA.1.3C
Документация анализа должна содержать описание всех предположений, сделанных в процессе анализа скрытых каналов.
18.1.4.3.4 AVA_CCA.1.4C
Документация анализа должна содержать описание метода, используемого для оценки пропускной способности канала для случая наиболее опасного варианта сценария.
Документация анализа должна содержать описание наиболее опасного варианта сценария использования каждого идентифицированного скрытого канала.
13.1.4.4 Элементы действий оценщика
18.1.4.4.1 AVA_CCA.1.1Е
Оценщик должен подтвердить, что представленная информация соответствует всем требованиям к содержанию и представлению свидетельств.
18.1.4.4.2 AVA_CCA.1.2E
Оценщик должен подтвердить, что результаты анализа скрытых каналов показывают, что ОО соответствует функциональным требованиям.
18.1.4.4.3 AVA_CCA.1.3E
Оценщик должен выборочно подтвердить правильность результатов анализа скрытых каналов, применяя тестирование.
13.1.5 AVA_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.1 AVA_CCA.2.1D
Разработчик должен провести поиск скрытых каналов для каждой политики управления информационными потоками.
18.1.5.3.2 AVA_CCA.2.2D
Разработчик должен представить документацию анализа скрытых каналов.
18.1.5.4 Элементы содержания и представления свидетельств
18.1.5.4.1 A VA_CCA.2.1С
Документация анализа должна идентифицировать скрытые каналы и содержать оценку их пропускной способности.
18.1.5.4.2 AVA_CCA.2.2C
Документация анализа должна содержать описание процедур, используемых для вынесения заключения о существовании скрытых каналов, и информацию, необходимую для анализа скрытых каналов.
18.1.5.4.3 AVA_CCA.2.3C
Документация анализа должна содержать описание всех предположений, сделанных в процессе анализа скрытых каналов.
18.1.5.4.4 AVA_CCA.2.4C
Документация анализа должна содержать описание метода, используемого для оценки пропускной способности канала для случая наиболее опасного варианта сценария.
Документация анализа должна содержать описание наиболее опасного варианта сценария использования каждого идентифицированного скрытого канала.
18.1.5.4.6AVA_CCA.2.6C
Документация анализа должна содержать свидетельство, что метод, использованный для идентификации скрытых каналов, является систематическим.
18.1.5.5 Элементы действий оценщика
18.1.5.5.1 AVA_CCA.2.1E
Оценщик должен подтвердить, что представленная информация соответствует всем требованиям к содержанию и представлению свидетельств.
Оценщик должен подтвердить, что результаты анализа скрытых каналов показывают, что ОО соответствует функциональным требованиям.
18.1.5.5.3 AVA_CCA.2.3E
Оценщик должен выборочно подтвердить правильность результатов анализа скрытых каналов, применяя тестирование.
18.1 6 AVA_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.1 AVA_CCA.3.1D
Разработчик должен провести поиск скрытых каналов для каждой политики управления информационными потоками.
18.1.6.3.2 AVA_CCA.3.2D
Разработчик должен представить документацию анализа скрытых каналов.
18.1.6.4 Элементы содержания и представления свидетельств
18.1.6.4.1 AVA_CCA.3.1С
Документация анализа должна идентифицировать скрытые каналы и содержать оценку их пропускной способности.
18.1.6.4.2 AVA_CCA.3.2C
Документация анализа должна содержать описание процедур, используемых для вынесения заключения о существовании скрытым каналов, и информацию, необходимую для анализа скрытым каналов.
18.1.6.4.3 AVA_CCA.3.3C
Документация анализа должна содержать описание всех предположений, сделанных в процессе анализа скрытых каналов.
18.1.6.4.4 AVA_CCA.3.4C
Документация анализа должна содержать описание метода, используемого для оценки пропускной способности канала для случая наиболее опасного варианта сценария.
18.1.6.4.5 AVA_CCA.3.5C
Документация анализа должна содержать описание наиболее опасного варианта сценария использования каждого идентифицированного скрытого канала.
18.1.6.4.6 AVA_CCA.3.6C
Документация анализа должна содержать свидетельство того, что метод, использованный для идентификации скрытым каналов, является исчерпывающим.
18.1.6.5 Элементы действий оценщика
18.1.6.5.1 AVA_CCA.3.1E
Оценщик должен подтвердить, что представленная информация соответствует всем требованиям к содержанию и представлению свидетельств.
18.1.6.5.2 AVA_CCA.3.2E
Оценщик должен подтвердить, что результаты анализа скрытых каналов показывают, что ОО соответствует функциональным требованиям.
18.1.6.5.3 AVA_CCA.3.3Е
Оценщик должен выборочно подтвердить правильность результатов анализа скрытых каналов, применяя тестирование.
18.2 Неправильное применение (AVA_MSU)18.2.1 Цели
Семейство AVA_MSU позволяет установить, может ли ОО быть сконфигурирован или использован опасным образом так, чтобы администратор или пользователь ОО обоснованно считал бы его безопасным. Целями являются:
а) минимизация вероятности конфигурирования или установки ОО опасным образом, исключающим возможность обнаружения пользователем или администратором;
b) минимизация риска ошибок, обусловленных человеческим фактором или иными причинами, в операциях, которые могут блокировать, отключить или помешать активизировать функции безопасности, приводя к необнаруженному опасному состоянию.
13.2.2 Ранжирование компонентов
Компоненты ранжированы по возрастанию числа свидетельств, представляемых разработчиком, и повышению строгости анализа.
18.2.3 Замечания по применению
Противоречивое, вводящее в заблуждение, неполное или необоснованное руководство может убедить пользователя в безопасности ОО при ее отсутствии, что может привести к уязвимостям.
Примером противоречия является наличие двух инструкций руководства, которые подразумевают различные выходные результаты при одних и тех же входных данный.
Примером введения в заблуждение является такая формулировка инструкции руководства, которую можно трактовать неоднозначно, причем одна из трактовок может привести к опасному состоянию.
Примером неполноты является список существенных физических требований безопасности, в котором опущен важный пункт, что приведет к игнорированию соответствующего требования администратором, считающим список полным.
Примером необоснованности является рекомендация следовать процедуре, приводящей к чрезмерной нагрузке по администрированию.
Требуется наличие документации руководств. Она может быть включена в руководства пользователя и администратора или представляться отдельно. При отдельном представлении оценщику следует подтвердить, что данная документация поставляется вместе с ОО.
18.2.4 AVA_MSU.1 Экспертиза руководств
Зависимости: ADO_IGS.1 Процедуры установки, генерации и запуска
ADV_FSP.1 Неформальная функциональная спецификация
AGD_ADM.1 Руководство администратора
AGD_USR.1 Руководство пользователя
18.2.4.1 Цели
Цель состоит в том, чтобы обеспечить отсутствие в руководствах вводящий в заблуждение, необоснованных и противоречивых указаний и предусмотреть безопасные процедуры для всех режимов функционирования. Опасные состояния должны легко выявляться.
18.2.4.2 Элементы действий разработчика
18.2.4.2.1 AVA_MSU.1.1D
Разработчик должен представить руководства по применению ОО.
18.2.4.3 Элементы содержания и представления свидетельств
18.2.4.3.1 AVA_MSU.1.1C
Руководства должны идентифицировать все возможные режимы эксплуатации ОО (включая действия после сбоя или ошибки в работе), их последствия и значение для обеспечения безопасной эксплуатации.
18.2.4.3.2 AVA_MSU.1.2C
Руководства должны быть полными, понятными, непротиворечивыми и обоснованными.
Руководства должны содержать список всех предположений относительно среды эксплуатации.
18.2.4.3.4 AVA_MSU1.4C
Руководства должны содержать список всех требований к внешним мерам безопасности (включая внешний контроль над процедурами, физическими мерами и персоналом).
18.2.4.4 Элементы действий оценщика
18.2.4.4.1 AVA_MSU.1.1Е
Оценщик должен подтвердить, что представленная информация соответствует всем требованиям к содержанию и представлению свидетельств.
18.2.4.4.2 AVA_MSU.1.2E
Оценщик должен повторить все процедуры конфигурирования и установки для подтверждения того, что ОО можно безопасно конфигурировать и использовать, применяя только представленные руководства.
18.2.4.4.3 AVA_MSU.1.3E
Оценщик должен сделать независимое заключение, что использование руководств позволяет выявить все опасные состояния.
18.2.5 AVA_MSU.2 Подтверждение правильности анализа
Зависимости: ADO_IGS.1 Процедуры установки, генерации и запуска
ADV_FSP.1 Неформальная функциональная спецификация
AGD_ADM.1 Руководство администратора
AGD_USR.1 Руководство пользователя
18.2.5.1 Цели
Цель состоит в том, чтобы обеспечить отсутствие в руководствах вводящих в заблуждение, необоснованных и противоречивых указаний и предусмотреть безопасные процедуры для всех режимов функционирования. Опасные состояния должны легко выявляться. В данном компоненте требуется анализ разработчиком руководств для повышения доверия к тому, что цель достигнута.
18.2.5.2 Элементы действий разработчика
18.2.5.2.1 AVA_MSU.2.1D
Разработчик должен представить руководства по применению ОO.
18.2.5.2.2 AVA_MSU.2.2D
Разработчик должен задокументировать анализ руководств.
18.2.5.3 Элементы содержания и представления свидетельств
18.2.5.3.1 AVA_MSU.2.1C
Руководства должны идентифицировать все возможные режимы эксплуатации ОО (включая действия после сбоя или ошибки в работе), их последствия и значение для обеспечения безопасной эксплуатации.
18.2.5.3.2 AVA_MSU.2.2C
Руководства должны быть полны, понятны, непротиворечивы и обоснованы.
18.2.5.3.3 AVA_MSU.2.3С
Руководства должны содержать список всех предположений относительно среды эксплуатации.
18.2.5.3.4 AVA_MSU.2.4C
Руководства должны содержать список всех требований к внешним мерам безопасности (включая внешний контроль за процедурами, физическими мерами и персоналом).
18.2.5.3.5 AVA_MSU.2.5С
Документация анализа должна демонстрировать, что руководства полны.
18.2.5.4 Элементы действий оценщика
18.2.5.4.1 AVA_MSU.2.1E
Оценщик должен подтвердить, что представленная информация соответствует всем требованиям к содержанию и представлению свидетельств.
18.2.5.4.2 AVA_MSU.2.2Е
Оценщик должен повторить все процедуры конфигурирования и установки и, выборочно, другие процедуры для подтверждения, что ОО можно безопасно конфигурировать и использовать, применяя только представленные руководства.
Оценщик должен сделать независимое заключение о том, что использование руководств позволяет выявить все опасные состояния.
18.2.5.4.4 AVA_MSU.2.4E
Оценщик должен подтвердить, что документация анализа показывает, что руководства по безопасной эксплуатации предоставлены для всех режимов эксплуатации ОО.
18.2.6 AVA_MSU.3 Анализ и тестирование опасный состояний
Зависимости. ADO_IGS.1 Процедуры установки, генерации и запуска
ADV_FSP.1 Неформальная функциональная спецификация
AGD_ADM.1 Руководство администратора
AGO_USR.1 Руководство пользователя
18.2.6.1 Цели
Цель состоит в том, чтобы обеспечить отсутствие в руководствах вводящих в заблуждение, необоснованных и противоречивых указаний и предусмотреть безопасные процедуры для всех режимов функционирования. Опасные состояния должны легко выявляться. В данном компоненте требуется анализ разработчиком руководств для повышения доверия к тому, что цель достигнута, и этот анализ проверяется и подтверждается оценщиком путем тестирования.
18.2.6.2 Замечания по применению
В данном компоненте от оценщика требуется выполнить тестирование, позволяющее удостовериться в том, что при переходе ОО в опасное состояние последнее может быть легко выявлено. Указа иное тестирование может рассматриваться как специфический аспект тестирования проникновения.
13.2.6.3 Элементы действий разработчика
18.2.6.3.1 AVA_MSU.3.1D
Разработчик должен представить руководства по применению ОО.
18.2.6.3.2 AVA_MSU.3.2D
Разработчик должен задокументировать анализ руководств.
18.2.6.4 Элементы содержания и представления свидетельств
18.2.6.4.1 AVA_MSU.3.1C
Руководства должны идентифицировать все возможные режимы эксплуатации ОО (включая действия после сбоя или ошибки в работе), их последствия и значение для обеспечения безопасной эксплуатации.
Руководства должны быть полными, понятными, непротиворечивыми и обоснованными.
18.2.6.4.3 AVA_MSU.3.3C
Руководства должны содержать список всех предположений относительно среды эксплуатации.
18.2.6.4.4 AVA_MSU.3.4C
Руководства должны содержать список всех требований к внешним мерам безопасности (включая внешний контроль за процедурами, физическими мерами и персоналом).
18.2.6.4.5 AVA_M5U.3.5C
Документация анализа должна демонстрировать, что руководства полны.
18.2.6.5 Элементы действий оценщика
Оценщик должен подтвердить, что представленная информация соответствует всем требованиям к содержанию и представлению свидетельств.
18.2.6.5.2 AVA_MSU.3.2E
Оценщик должен повторить все процедуры конфигурирования и установки и выборочно другие процедуры для подтверждения, что ОО можно безопасно конфигурировать и использовать, применяя только представленные руководства.
18.2.6.5.3 AVA_MSU.3.3E
Оценщик должен сделать независимое заключение, что использование руководств позволяет выявить все опасные состояния.
Оценщик должен подтвердить, что документация анализа показывает, что руководства по безопасной эксплуатации предоставлены для всех режимов эксплуатации ОО.
18.2.6.5.5 AVA_MSU.3.5E
Оценщик должен выполнить независимое тестирование, чтобы сделать заключение, будет ли администратор или пользователь способен установить, руководствуясь документацией что ОО конфигурирован и используется опасным образом.
18.3 Стойкость функций безопасности ОО (AVA_SOF)18.3.1 Цели
Даже если функцию безопасности ОО нельзя обойти, отключить или исказить, в некоторых случаях существует возможность ее преодоления из-за уязвимости е концепции реализующих ее базовых механизмов безопасности. Для этих функций квалификация режима безопасности может быть проверена с использованием результатов количественного или статистического анализа режима безопасности указанных механизмов, а также усилий, требуемых для их преодоления. Квалификацию осуществляют в виде утверждения о стойкости функции безопасности ОО.
18.3.2 Ранжирование компонентов
В данном семействе имеется только один компонент.
18.3.3 Замечания по применению
Функции безопасности реализуются механизмами безопасности. Например, механизм пароля может использоваться при реализации функций идентификации и аутентификации.
Оценку стойкости функции безопасности ОО выполняют на уровне механизма безопасности, но ее результаты позволяют определить способность соответствующей функции безопасности противостоять идентифицированным угрозам.
При анализе стойкости функции Безопасности ОО следует рассматривать, по меньшей мере, содержание всех поставляемых материалов ОО, включая ЗБ, с учетом намеченного оценочного уровня доверия.
13.3.4 AVA_SOF.1 Оценка стойкости функции безопасности ОО
Зависимости: ADV_FSP.1 Неформальная функциональная спецификация
ADV_HLD.1 Описательный проект верхнего уровня
18.3.4.1 Элементы действий разработчика
18.3.41.1 AVA_SOF.1.1D
Разработчик должен выполнить анализ стойкости функции безопасности ОО для каждого механизма, идентифицированного в ЗБ как имеющего утверждение относительно стойкости функции безопасности ОО.
18.3.4.2 Элементы содержания и представления свидетельств
18.3.4 2.1 AVA_SOF.1.1С
Для каждого механизма, имеющего утверждение относительно стойкости функции безопасности ОО, анализ должен показать, что ее стойкость, достигает или превышает минимальный уровень стойкости, определенных в ПЗ/ЗБ.
18.3.4.2.2 AVA_SOF1.2С
Для каждого механизма, имеющего утверждение относительно конкретной стойкости функции безопасности ОО, анализ должен показать, что ее стойкость достигает или превышает конкретный показатель, определенный в ПЗ/ЗБ.
13.3.4.3 Элементы действий оценщика
18.3.4.3.1 AVA_SOF.1.1Е
Оценщик должен подтвердить, что представленная информация соответствует всем требованиям к содержанию и представлению свидетельств.
Оценщик должен подтвердить, что утверждения относительно стойкости корректны.
18.4 Анализ уязвимостей (AVA_VLA)
18.4.1 Цели
Анализ уязвимостей позволяет сделать заключение, могут ли уязвимости, идентифицированные в процессе оценки устройства ОО и его ожидаемого функционирования или другими методами (например, из гипотезы о недостатках), быть использованы пользователями для нарушения ПБО.
При анализе уязвимостей рассматривают угрозы того, что пользователь будет в состоянии обнаружить недостатки, позволяющие получить несанкционированный доступ к ресурсам (например, данным), препятствовать выполнению ФБО и искажать им или же ограничивать санкционированные возможности других пользователей.
18.4.2 Ранжирование компонентов
Ранжирование основано на повышении строгости анализа уязвимостей разработчиком и оценщиком.
18.4.3 Замечания по применению
Разработчик выполняет анализ уязвимостей с тем, чтобы установить присутствие уязвимостей безопасности при этом следует рассматривать, по меньшей мере, содержание всех поставляемых материалов ОО, включая ЗБ, с учетом намеченного оценочного уровня доверия. От разработчика требуется задокументировать решение по идентифицированным уязвимостям, чтобы позволить оценщику использовать эту информацию (если ее признают полезной) для поддержки независимого анализа уязвимостей оценщиком.
Анализ, проводимый разработчиком, предназначен для подтверждения невозможности использования идентифицированных уязвимостей безопасности в предполагаемой среде ОО и стойкости ОО к явным нападениям проникновения.
Под явными уязвимостями понимают те уязвимости, которые открыты для использования, требующего минимума понимания ОО, умений, технического опыта и ресурсов. Такие уязвимости могут быть подсказаны описанием интерфейса ФБО. К явным уязвимостям относятся известные из общедоступных источников (разработчику следует детально знать их) или полученные от органа оценки.
Систематический поиск уязвимостей требует, чтобы разработчик идентифицировал уязвимости структурированным и повторяемым способом, в противоположность их идентификации частными методами. Необходимо, чтобы свидетельство того, что поиск уязвимостей был систематическим, включало в себя идентификацию всей документации ОО, на которой был основан поиск недостатков.
Независимый анализ уязвимостей не ограничивается уязвимостями, идентифицированными разработчиком. Основная цель анализа, проводимого оценщиком, - сделать заключение, что ОО является стойким к нападениям проникновения со стороны нарушителя, обладающего низким (для AVA_VLA.2 "Независимый анализ уязвимостей"), умеренным (для А/А_VLA.3 "Умеренно стойкий") или высоким (для AVA_VLA.4 "Высоко стойкий") потенциалом нападения. Для достижения этой цели оценщик сначала проверяет возможности использования всех идентифицированных уязвимостей. Это осуществляется посредством тестирования проникновения. Оценщику следует принять на себя роль нарушителя с одним из указанных выше потенциалов нападения при попытке проникновения в ОО. Любое использование уязвимостей таким нарушителем оценщику следует рассматривать как "явное нападение проникновения" (в отношении элементов AVA_VLA.*.2C в контексте компонентов AVA_VLA.2 "Независимый анализ уязвимостей", AVA__VLA.3 "Умеренно стойкими", AVA_VLA.4 "Высоко стойкий").
18.4.4 AVA_VLA.1 Анализ уязвимостей разработчиком
Зависимости: ADV_FSP.1 Неформальная функциональная спецификация
ADV_HLD.1 Описательный проект верхнего уровня
AOD_ADM.1 Руководство администратора
AGD_USR.1 Руководство пользователя
18.4.4.1 Цели
Разработчик выполняет анализ уязвимостей с тем, чтобы установить присутствие явных уязвимостей безопасности и подтвердить, что они не могут быть использованы В предполагаемой среде ОО.
18.4.4.2 Замечания по применению
Оценщику следует предусмотреть выполнение дополнительных тестов для уязвимостей выявленных при выполнении других частей оценки и потенциально пригодных для использования.
18.4.4.3 Элементы действий разработчика
18.4.4.3.1 AVA_VLA.1.1D
Разработчик должен выполнить анализ уязвимостей.
18.4.4.3.2 AVA_VLA.1.2D
Разработчик должен предоставить документацию анализа уязвимостей.
18.4.4.4 Элементы содержания и представления свидетельств
18.4.4.4.1 AVA_VLA.1.1С
Документация анализа уязвимостей должна содержать описание анализа поставляемых материалов ОО, выполненного для поиска данных способов, которыми пользователь может нарушить ПБО.
Документация анализа уязвимостей должна содержать описание решения в отношении явных уязвимостей.
18.4.4.4.3 AVA_VLA_1.3C
Документация анализа уязвимостей должна показать для всех идентифицированных уязвимостей, что ни одна из них не может быть использована в предполагаемой среде ОО.
18.4.4.5 Элементы действий оценщика
18.4.4.5.1 AVA_VLA.1.1E
Оценщик должен подтвердить, что представленная информация соответствует всем требованиям к содержанию и представлению свидетельств.
Оценщик должен провести тестирование проникновения, основанное на анализа уязвимостей, выполненном разработчиком, для обеспечения учета явных уязвимостей.
18.4.5 AVA_VLA.3 Независимый анализ уязвимостей
Зависимости: ADV_F3P.1 Неформальная функциональная спецификация
ADV_HLD.2 Детализация вопросов безопасности в проекте верхнего уровня
ADV_IMP.1 Подмножество реализации ФБО
ADV_LLD.1 Описательный проект нижнего уровня
AGD_ADM.1 Руководство администратора
AGD_USR.1 Руководство пользователя
18.4.5.1 Цели
Разработчик выполняет анализ уязвимостей с тем, чтобы установить присутствие уязвимостей безопасности и подтвердить, что они не могут быть использованы в предполагаемой среде ОО.
Оценщик выполняет независимое тестирование проникновения, поддержанное собственным независимым анализом уязвимостей для того чтобы сделать независимое заключение, что ОО является стойким к нападениям проникновения, выполняемым нарушителями, обладающими низким потенциалом нападения.
18.4.5.2 Элементы действий разработчика
18.4.5.2.1 AVA_VLA.2.1D
Разработчик должен выполнить анализ уязвимостей.
18.4.5.2.2. AVA_VLA2.2D
Разработчик должен предоставить документацию анализа уязвимостей.
18.4.5.3 Элементы содержания и представления свидетельств
18.4.5.3.1 AVA_VLA.2.1C
Документация анализа уязвимостей должна содержать описание анализа поставляемых материалов ОО, выполненного для поиска способов, которыми пользователь может нарушить ПБО.
18.4.5.3.2 AVA_VLA.2.2С
Документация анализа уязвимостей должна содержать описание решения в отношении идентифицированных уязвимостей.
18.4.5.3.3 AVA_VLA.2.3C
Документация анализа уязвимостей должна показать для всех идентифицированных уязвимостей, что ни одна из них не может быть использована, в предполагаемой среде ОО.
Документация анализа уязвимостей должна содержать логическое обоснование того, что ОО с идентифицированными уязвимостями устойчив по отношению к очевидным атакам проникновения.
18.4.5.4 Элементы действий оценщика
18.4.5.4.1 AVA_VLA.2.1E
Оценщик должен подтвердить, что представленная информация соответствует всем требованиям к содержанию и представлению свидетельств.
18.4.5.4.2 AVA_VLA.2.2Е
Оценщик должен провести тестирование проникновения, основанное на анализе уязвимостей, выполненном разработчиком, для обеспечения учета идентифицированных уязвимостей.
18.4.54.3 AVA_VLA.2.3E
Оценщик, должен выполнить независимый анализ уязвимостей.
18.4.5.4.4 AVA_VLА.2.4Е
Оценщик должен выполнить независимое тестирование проникновения, основанное на независимом анализе уязвимостей, и сделать независимое заключение о возможности использования дополнительно идентифицированных уязвимостей в предполагаемой среде.
18.4.54.5 AVA_VLA.2.5E
Оценщик должен сделать независимое заключение, что ОО является стойким к нападениям проникновения, выполняемым нарушителем, обладающим низким потенциалом нападения.
18.4.6 AVA_VLA.3 Умеренно стойкий
Зависимости: ADV_FSP.1 Неформальная функциональная спецификация
ADV_HLD.2 Детализация вопросов безопасности в проекте верхнего уровня
ADV_IMP.1 Подмножество реализации ФБО
ADV_LLD.1 Описательный проект нижнего уровня
AGD_ADM.1 Руководство администратора
AGD_USR.1 Руководство пользователя
18 4 6.1 Цели
Разработчик выполняет анализ уязвимостей с тем, чтобы установить присутствие уязвимостей безопасности и подтвердить, что они не могут быть использованы в предполагаемой среде ОО.
Оценщик выполняет независимое тестирование проникновения, поддержанное собственным независимым анализом уязвимостей, для того чтобы сделать независимое заключение, что ОО является стойким к нападениям проникновения, выполняемым нарушителями, обладающими умеренным потенциалом нападения.
18.4.6.2 Элементы действий разработчика
18.4.6.2.1 AVA_VLA.3.1D
Разработчик должен выполнить анализ уязвимостей.
18.4.6.2.2 AVA_VLA.3.2D
Разработчик должен предоставить документацию анализа уязвимостей.
18.4.6.3 Элементы содержания и представления свидетельств
18.4.6.3.1 AVA_VLA.3.1C
Документация анализа уязвимостей должна содержать описание анализа поставляемых материалов ОО, выполненного для поиска способов, которыми пользователь может нарушить ПБО.
18.4.6.3.2 AVA_VLA.3.2C
Документация анализа уязвимостей должна содержать описание решения в отношении идентифицированных уязвимостей.
18.4.6.3.3 AVA_VLA.3.3С
Документация анализа уязвимостей должна показать для всех идентифицированных уязвимостей, что ни одна из них не может быть использована в предполагаемой среде ОО.
Документация анализа уязвимостей должна содержать логическое обоснование, что ОО с идентифицированными уязвимости ми устойчив по отношению к очевидным атакам проникновения.
18 4 6 3.5 AVA_VLA.3.5C
Документация анализа уязвимостей должна показывать, что поиск, уязвимостей является систематическим.
18.4.6.4 Элементы действий оценщика
18.4.6.4.1 AVA_VLA.3.1E
Оценщик должен подтвердить, что представленная информация соответствует всем требованиям к содержанию и представлению свидетельств.
Оценщик должен провести тестирование проникновения, основанное на анализе уязвимостей, выполненном разработчиком, для обеспечения учета идентифицированных уязвимостей.
18.4.6.4.3 AVA_VL A.3.3E
Оценщик должен выполнить независимый анализ уязвимостей.
18.4.6.4.4 AVA_VL A.3.4E
Оценщик должен выполнить независимое тестирование проникновения, основанное на независимом анализе уязвимостей, и сделать независимое заключение о возможности использования дополнительно идентифицированных уязвимостей в предполагаемой среде.
Оценщик должен сделать независимое заключение, что ОО является стойким к нападениям проникновения, выполняемым нарушителем, обладающим умеренным потенциалом нападения.
18.4.7 AVA_VLA.4 Высокостойкий
Зависимости: ADV_FSP.1 Неформальная функциональная спецификация
ADV_HLD.2 Детализация вопросов безопасности в проекте верхнего уровня
ADV_IMP.1 Подмножество реализации ФБО
ADV_LLD.1 Описательный проект нижнего уровня
AGD_ADM.1 Руководство администратора
AGD_USR.1 Руководство пользователя
13.4.7.1 Цели
Разработчик выполняет анализ уязвимостей с тем, чтобы установить присутствие уязвимостей безопасности и подтвердить, что они не могут быть использованы в предполагаемой среде ОО.
Оценщик выполняет независимое тестирование проникновения, поддержанное собственным независимым анализом уязвимостей, для того чтобы сделать независимое заключение, что ОО является стойким к нападениям проникновения, выполняемым нарушителями, обладающими высоким потенциалом нападения.
18.4.7.2 Элементы действий разработчика
18.4.7.2.1 AVA_VLA.4.1D
Разработчик должен выполнить анализ уязвимостей.
18.4.7.2.2 AVA_VLA.4.2D
Разработчик должен предоставить документацию анализа уязвимостей.
18.4.7.3 Элементы содержания и представления свидетельств
18.4.7.3.1 AVA_VLA.4.1C
Документация анализа уязвимостей должна содержать описание анализа поставляемых материалов ОО, выполненного для поиска способов, которыми пользователь может нарушить ПБО.
18.4.7.3.2 AVA_VLA.4.2С
Документация анализа уязвимостей должна содержать описание решения в отношении идентифицированных уязвимостей.
18.4.7.3.3 AVA_VLA.4.3C
Документация анализа уязвимостей должна показать для всех идентифицированных уязвимостей, что ни одна из них не может быть использована в предполагаемой среде ОО.
Документация анализа уязвимостей должна содержать логическое обоснование, что ОО с идентифицированными уязвимостями устойчив по отношению к очевидным атакам проникновения.
18.4.7.3.5 AVA_VLA.4.5C
Документация анализа уязвимостей должна показывать, что поиск уязвимостей является систематическими.
18.4.7.3.6 AVA_VLA.4.6C
Документации анализа уязвимостей должна содержать логическое обоснование, что анализ полностью учитывает все поставляемые материалы ОО.
18.4.7.4 Элементы действий оценщика
Оценщик должен подтвердить, что представленная информация соответствует всем требованиям к содержанию и представлению свидетельств.
18.4.7.4.2 AVA_VLA.4.2E
Оценщик должен провести тестирование проникновения, основанное на анализе уязвимостей, выполненном разработчиком, для обеспечения учета идентифицирован них уязвимостей.
18.4.7.4.3 AVA_VLA.4.3E
Оценщик должен выполнить независимый анализ уязвимостей.
18.4.7.4.4 AVA_VLA.4.4E
Оценщик должен выполнить независимое тестирование проникновения, основанное на независимом анализе уязвимостей, и сделать независимое заключение о возможности использования дополнительно идентифицированных, уязвимостей в предполагаемой среде.
18.4.7.4.5 AV A_VLA.4.5Е
Оценщик должен сделать независимое заключение, что ОО является стойким к нападениям проникновения, выполняемым нарушителем, обладающим высоким потенциалом нападения.
- Главная
- "МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ. КРИТЕРИИ ОЦЕНКИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ. Часть 3. ТРЕБОВАНИЯ ДОВЕРИЯ К БЕЗОПАСНОСТИ. ГОСТ Р ИСО/МЭК 15408-3-2008" (утв. Приказом Ростехрегулирования от 18.12.2008 N 521-ст)