ГОСТ Р ИСО МЭК 15408-3 2007 (1027766), страница 30
Текст из файла (страница 30)
Она может быть включена в руководствапользователя и администратора или же представляться отдельно. При отдельном представленииоценщику следует подтвердить, что данная документация поставляется вместе с ОО.133ГОСТ Р ИСО/МЭК 15408-3—…(проект, окончательная редакция)18.2.4AVA_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.1AVA_MSU.1.1DРазработчик должен представить руководства по применению ОО.18.2.4.3 Элементы содержания и представления свидетельств18.2.4.3.1AVA_MSU.1.1CРуководства должны идентифицировать все возможные режимы эксплуатации ОО(включая действия после сбоя или ошибки в работе), их последствия и значение для обеспечения безопасной эксплуатации.18.2.4.3.2AVA_MSU.1.2CРуководства должны быть полны, понятны, непротиворечивы и обоснованы.18.2.4.3.3AVA_MSU.1.3CРуководства должны содержать список всех предположений относительно среды эксплуатации.18.2.4.3.4AVA_MSU.1.4CРуководства должны содержать список всех требований к внешним мерам безопасности (включая внешний контроль над процедурами, физическими мерами и персоналом).18.2.4.4 Элементы действий оценщика18.2.4.4.1AVA_MSU.1.1EОценщик должен подтвердить, что представленная информация удовлетворяет всемтребованиям к содержанию и представлению свидетельств.18.2.4.4.2AVA_MSU.1.2EОценщик должен повторить все процедуры конфигурирования и установки для подтверждения, что ОО можно безопасно конфигурировать и использовать, применяя толькопредставленные руководства.18.2.4.4.3AVA_MSU.1.3EОценщик должен сделать независимое заключение, что использование руководствпозволяет выявить все опасные состояния.18.2.5AVA_MSU.2 Подтверждение правильности анализаЗависимости: ADO_IGS.1 Процедуры установки, генерации и запускаADV_FSP.1 Неформальная функциональная спецификацияAGD_ADM.1 Руководство администратораAGD_USR.1 Руководство пользователя18.2.5.1 Цели134ГОСТ Р ИСО/МЭК 15408-3—…(проект, окончательная редакция)Целью является обеспечить отсутствие в руководствах вводящих в заблуждение, необоснованных и противоречивых указаний и предусмотреть безопасные процедуры для всех режимовфункционирования.
Опасные состояния должны легко выявляться. В этом компоненте требуетсяанализ разработчиком руководств для повышения доверия, что цель достигнута.18.2.5.2 Элементы действий разработчика18.2.5.2.1AVA_MSU.2.1DРазработчик должен представить руководства по применению ОО.18.2.5.2.2AVA_MSU.2.2DРазработчик должен задокументировать анализ руководств.18.2.5.3 Элементы содержания и представления свидетельств18.2.5.3.1AVA_MSU.2.1CРуководства должны идентифицировать все возможные режимы эксплуатации ОО (включаядействия после сбоя или ошибки в работе), их последствия и значение для обеспечения безопасной эксплуатации.18.2.5.3.2AVA_MSU.2.2CРуководства должны быть полны, понятны, непротиворечивы и обоснованы.18.2.5.3.3AVA_MSU.2.3CРуководства должны содержать список всех предположений относительно среды эксплуатации.18.2.5.3.4AVA_MSU.2.4CРуководства должны содержать список всех требований к внешним мерам безопасности(включая внешний контроль за процедурами, физическими мерами и персоналом).18.2.5.3.5AVA_MSU.2.5CДокументация анализа должна демонстрировать, что руководства полны.18.2.5.4 Элементы действий оценщика18.2.5.4.1AVA_MSU.2.1EОценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.18.2.5.4.2AVA_MSU.2.2EОценщик должен повторить все процедуры конфигурирования и установки и выборочно другие процедуры для подтверждения, что ОО можно безопасно конфигурировать и использовать, применяя только представленные руководства.18.2.5.4.3AVA_MSU.2.3EОценщик должен сделать независимое заключение, что использование руководств позволяет выявить все опасные состояния.18.2.5.4.4AVA_MSU.2.4EОценщик должен подтвердить, что документация анализа показывает, что руководства по безопасной эксплуатации предоставлены для всех режимов эксплуатации ОО.18.2.6AVA_MSU.3 Анализ и тестирование опасных состоянийЗависимости: ADO_IGS.1 Процедуры установки, генерации и запускаADV_FSP.1 Неформальная функциональная спецификация135ГОСТ Р ИСО/МЭК 15408-3—…(проект, окончательная редакция)AGD_ADM.1 Руководство администратораAGD_USR.1 Руководство пользователя18.2.6.1 ЦелиЦелью является обеспечить отсутствие в руководствах вводящих в заблуждение, необоснованных и противоречивых указаний и предусмотреть безопасные процедуры для всех режимовфункционирования.
Опасные состояния должны легко выявляться. В этом компоненте требуетсяанализ разработчиком руководств для повышения доверия, что цель достигнута, и этот анализпроверяется и подтверждается оценщиком путем тестирования.18.2.6.2 Замечания по применениюВ этом компоненте от оценщика требуется выполнить тестирование, позволяющее удостовериться в том, что при переходе ОО в опасное состояние оно может быть легко выявлено. Этотестирование может рассматриваться как специфический аспект тестирования проникновения.18.2.6.3 Элементы действий разработчика18.2.6.3.1AVA_MSU.3.1DРазработчик должен представить руководства по применению ОО.18.2.6.3.2AVA_MSU.3.2DРазработчик должен задокументировать анализ руководств.18.2.6.4 Элементы содержания и представления свидетельств18.2.6.4.1AVA_MSU.3.1CРуководства должны идентифицировать все возможные режимы эксплуатации ОО (включаядействия после сбоя или ошибки в работе), их последствия и значение для обеспечения безопасной эксплуатации.18.2.6.4.2AVA_MSU.3.2CРуководства должны быть полны, понятны, непротиворечивы и обоснованы.18.2.6.4.3AVA_MSU.3.3CРуководства должны содержать список всех предположений относительно среды эксплуатации.18.2.6.4.4AVA_MSU.3.4CРуководства должны содержать список всех требований к внешним мерам безопасности(включая внешний контроль за процедурами, физическими мерами и персоналом).18.2.6.4.5AVA_MSU.3.5CДокументация анализа должна демонстрировать, что руководства полны.18.2.6.5 Элементы действий оценщика18.2.6.5.1AVA_MSU.3.1EОценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.18.2.6.5.2AVA_MSU.3.2EОценщик должен повторить все процедуры конфигурирования и установки и выборочно другие процедуры для подтверждения, что ОО можно безопасно конфигурировать и использовать,применяя только представленные руководства.18.2.6.5.3136AVA_MSU.3.3EГОСТ Р ИСО/МЭК 15408-3—…(проект, окончательная редакция)Оценщик должен сделать независимое заключение, что использование руководств позволяет выявить все опасные состояния.18.2.6.5.4AVA_MSU.3.4EОценщик должен подтвердить, что документация анализа показывает, что руководства побезопасной эксплуатации предоставлены для всех режимов эксплуатации ОО.18.2.6.5.5AVA_MSU.3.5EОценщик должен выполнить независимое тестирование, чтобы сделать заключение,будут ли администратор или пользователь способны установить, руководствуясь документацией, что ОО конфигурирован и используется опасным образом.18.3 Стойкость функций безопасности ОО (AVA_SOF)18.3.1ЦелиДаже если функцию безопасности ОО нельзя обойти, отключить или исказить, в некоторыхслучаях все же существует возможность ее преодоления из-за уязвимости в концепции реализующих ее базовых механизмов безопасности.
Для этих функций оценка режима безопасности можетбыть проведена с использованием результатов количественного или статистического анализа режима безопасности указанных механизмов, а также усилий, требуемых для их преодоления. Оценку осуществляют в виде утверждения о стойкости функции безопасности ОО.18.3.2Ранжирование компонентовВ этом семействе имеется только один компонент.18.3.3Замечания по применениюФункции безопасности реализуются механизмами безопасности. Например, механизм пароля может использоваться при реализации функций идентификации и аутентификации.Оценку стойкости функции безопасности ОО выполняют на уровне механизма безопасности,но ее результаты позволяют определить способность соответствующей функции безопасностипротивостоять идентифицированным угрозам.При анализе стойкости функции безопасности ОО следует рассматривать, по меньшей мере,содержание всех поставляемых материалов ОО, включая ЗБ, с учетом намеченного оценочногоуровня доверия.18.3.4AVA_SOF.1 Оценка стойкости функции безопасности ООЗависимости: ADV_FSP.1 Неформальная функциональная спецификацияADV_HLD.1 Описательный проект верхнего уровня18.3.4.1 Элементы действий разработчика18.3.4.1.1AVA_SOF.1.1DРазработчик должен выполнить анализ стойкости функции безопасности ОО для каждого механизма, идентифицированного в ЗБ как имеющего утверждение относительностойкости функции безопасности ОО.18.3.4.2 Элементы содержания и представления свидетельств18.3.4.2.1AVA_SOF.1.1CДля каждого механизма, имеющего утверждение относительно стойкости функциибезопасности ОО, анализ должен показать, что ее стойкость достигает или превышает минимальный уровень стойкости, определенный в ПЗ/ЗБ.18.3.4.2.2AVA_SOF.1.2C137ГОСТ Р ИСО/МЭК 15408-3—…(проект, окончательная редакция)Для каждого механизма, имеющего утверждение относительно конкретной стойкостифункции безопасности ОО, анализ должен показать, что ее стойкость достигает или превышает конкретный показатель, определенный в ПЗ/ЗБ.18.3.4.3 Элементы действий оценщика18.3.4.3.1AVA_SOF.1.1EОценщик должен подтвердить, что представленная информация удовлетворяет всемтребованиям к содержанию и представлению свидетельств.18.3.4.3.2AVA_SOF.1.2EОценщик должен подтвердить, что утверждения относительно стойкости корректны.18.4 Анализ уязвимостей (AVA_VLA)18.4.1ЦелиАнализ уязвимостей позволяет сделать заключение, могут ли уязвимости, идентифицированные в процессе оценки устройства ОО и его ожидаемого функционирования или другими методами (например, из гипотезы о недостатках), быть использованы пользователями для нарушенияПБО.При анализе уязвимостей рассматривают угрозы, что пользователь будет в состоянии обнаружить недостатки, позволяющие получить несанкционированный доступ к ресурсам (например,данным), препятствовать выполнению ФБО и искажать их или же ограничивать санкционированные возможности других пользователей.18.4.2Ранжирование компонентовРанжирование основано на повышении строгости анализа уязвимостей разработчиком иоценщиком.18.4.3Замечания по применениюРазработчик выполняет анализ уязвимостей, чтобы установить присутствие уязвимостейбезопасности; при этом следует рассматривать, по меньшей мере, содержание всех поставляемыхматериалов ОО, включая ЗБ, с учетом намеченного оценочного уровня доверия.
От разработчикатребуется задокументировать решение по идентифицированным уязвимостям, чтобы позволитьоценщику использовать эту информацию, если ее признают полезной, для поддержки независимого анализа уязвимостей оценщиком.Анализ, проводимый разработчиком, предназначен для подтверждения невозможности использования идентифицированных уязвимостей безопасности в предполагаемой среде ОО и стойкости ОО к явным нападениям проникновения.Под явными уязвимостями понимают те, которые открыты для использования, требующегоминимума понимания ОО, умений, технического опыта и ресурсов. Они могут быть подсказаныописанием интерфейса ФБО.
К явным уязвимостям относятся известные из общедоступных источников (и разработчику следует детально знать их) или полученные от органа оценки.Систематический поиск уязвимостей предусматривает, чтобы разработчик идентифицировал эти уязвимости структурированным и повторяемым образом, в противоположность идентификации их частными методами. Следует, чтобы свидетельство того, что поиск уязвимостей был систематическим, включало в себя идентификацию всей документации ОО, на которой был основанпоиск недостатков.Независимый анализ уязвимостей не ограничивается уязвимостями, идентифицированнымиразработчиком.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
