Главная | Обратная связь | Поможем написать вашу работу!
МегаЛекции

FMT_MSA.3 – Инициализация статических атрибутов




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

Зависимости: FMT_MSA.1 Управление атрибутами безопасности

FMT_SMR.1 Роли безопасности

FMT_SMR.1 – Роли безопасности

FMT_SMR.1.2

ФБО должны быть способны ассоциировать пользователей с ролями.

Зависимости: IA_UID.1 Выбор момента времени идентификации

 

5.2 Требования доверия к безопасности

Комбинация выбранных компонентов доверия к безопасности соответствует 3-му оценочному уровню доверия к безопасности (ОУД3), предусматривающему методическое тестирование и проверку.

 

5.2.1 Управление конфигурацией (ACM)

5.2.1.1 Средства контроля авторизации (ACM_CAP.3)

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

ACM_CAP.3.2D – Разработчик должен использовать систему УК.

ACM_CAP.3.3D – Разработчик должен представить документацию УК.

ACM_CAP.3.1C – Маркировка ОО должна быть уникальна для каждой версии ОО.

ACM_CAP.3.2C – ОО должен быть помечен маркировкой.

ACM_CAP.3.3C – Документация УК должна включать список конфигурации и план УК.

ACM_CAP.3.4C – Список конфигурации должен содержать описание элементов конфигурации, входящих в ОО.

ACM_CAP.3.5C –Документация УК должна содержать описание метода, используемого для уникальной идентификации элементов конфигурации.

ACM_CAP.3.6C – Система УК должна уникально идентифицировать все элементы конфигурации.

ACM_CAP.3.7C – План УК должен содержать описание, как используется система УК.

ACM_CAP.3.8C – Свидетельство должно демонстрировать, что система УК действует в соответствии с планом УК.

ACM_CAP.3.9C –Документация УК должна содержать свидетельство, что система УК действительно сопровождала и продолжает эффективно сопровождать все элементы конфигурации.

ACM_CAP.3.10C – Система УК должна предусмотреть такие меры, при которых в элементах конфигурации могут быть сделаны только санкционированные изменения.

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

 

5.2.1.2 Охват УК объекта оценки (ACM_SCP.1)

ACM_SCP.1.1D – Разработчик должен представить документацию УК.

ACM_SCP.1.1C – Документация УК должна показать, что система УК, как минимум, отслеживает: представление реализации ОО, проектную документацию, тестовую документацию, документацию пользователя, документацию администратора и документацию УК.

ACM_SCP.1.2C –Документация УК должна содержать описание, как элементы конфигурации отслеживаются системой УК.

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

 

5.2.2 Поставка и эксплуатация (ADO)

5.2.2.1 Процедуры поставки (ADO_DEL.1)

ADO_DEL.1.1D – Разработчик должен задокументировать процедуры поставки ОО или его частей пользователю.

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

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

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

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

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

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

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

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

 

5.2.3 Разработка (ADV)

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

ADV_FSP.1.1D – Разработчик должен представить функциональную спецификацию.

ADV_FSP.1.1C –Функциональная спецификация должна содержать неформальное описание ФБО и их внешних интерфейсов.

ADV_FSP.1.2C – Функциональная спецификация должна быть внутренне непротиворечивой.

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

ADV_FSP.1.4C –Функциональная спецификация должна полностью представить ФБО.

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

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

 

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

ADV_HLD.2.1D – Разработчик должен представить проект верхнего уровня ФБО.

ADV_HLD.2.1C – Представление проекта верхнего уровня должно быть неформальным.

ADV_HLD.2.2C – Проект верхнего уровня должен быть внутренне непротиворечивым.

ADV_HLD.2.3C –Проект верхнего уровня должен содержать описание структуры ФБО в терминах подсистем.

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

ADV_HLD.2.5C – Проект верхнего уровня должен идентифицировать все базовые аппаратные, программно-аппаратные и/или программные средства, требуемые для реализации ФБО, с представлением функций, обеспечиваемых поддержкой механизмов защиты, реализуемых этими средствами.

ADV_HLD.2.6C – Проект верхнего уровня должен идентифицировать все интерфейсы для подсистем ФБО.

ADV_HLD.2.7C – Проект верхнего уровня должен идентифицировать, какие из интерфейсов подсистем ФБО являются видимыми извне.

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

ADV_HLD.2.9C – Проект верхнего уровня должен содержать описание разделения ОО на подсистемы, осуществляющие ПБО, и прочие.

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

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

 

5.2.3.3 Неформальная демонстрация соответствия (ADV_RCR.1)

ADV_RCR.1.1D – Разработчик должен представить анализ соответствия между всеми смежными парами имеющихся представлений ФБО.

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

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

5.2.4 Руководства (AGD)

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

AGD_ADM.1.1D –Разработчик должен представить руководство администратора, предназначенное для персонала системного администрирования.

AGD_ADM.1.1C – Руководство администратора должно содержать описание функций администрирования и интерфейсов, доступных администратору ОО.

AGD_ADM.1.2C – Руководство администратора должно содержать описание, как управлять ОО безопасным способом.

AGD_ADM.1.3C –Руководство администратора должно содержать

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

AGD_ADM.1.4C – Руководство администратора должно содержать описание всех предположений о поведении пользователя, которые связаны с безопасной эксплуатацией ОО.

AGD_ADM.1.5C – Руководство администратора должно содержать описание всех параметров безопасности, контролируемых администратором, указывая, при необходимости, безопасные значения.

AGD_ADM.1.6C – Руководство администратора должно содержать описание каждого типа относящихся к безопасности событий, связанных с выполнением обязательных функций администрирования, включая изменение характеристик безопасности сущностей, контролируемых ФБО.

AGD_ADM.1.7C – Руководство администратора должно быть согласовано со всей другой документацией, представленной для оценки.

AGD_ADM.1.8C – Руководство администратора должно содержать описание всех требований безопасности к среде ИТ, которые относятся к администратору.

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

 

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

AGD_USR.1.1D – Разработчик должен представить руководство пользователя.

AGD_USR.1.1C – Руководство пользователя должно содержать описание функций и интерфейсов, которые доступны пользователям ОО, не связанным с администрированием.

AGD_USR.1.2C – Руководство пользователя должно содержать описание применения доступных пользователям функций безопасности, предоставляемых ОО.

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

AGD_USR.1.4C – Руководство пользователя должно четко представить все обязанности пользователя, необходимые для безопасной эксплуатации ОО, включая обязанности, связанные с предположениями относительно действий пользователя, содержащимися в изложении среды безопасности ОО.

AGD_USR.1.5C – Руководство пользователя должно быть согласовано со всей другой документацией, представленной для оценки.

AGD_USR.1.6C –Руководство пользователя должно содержать описание всех требований безопасности к среде ИТ, которые имеют отношение к пользователю.

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

5.2.5 Поддержка жизненного цикла (ALC)

5.2.5.1 Идентификация мер безопасности (ALC_DVS.1)

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

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

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

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

ALC_DVS.1.2E – Оценщик должен подтвердить применение мер безопасности.

 

5.2.6 Тестирование (АТЕ)

5.2.6.1 Анализ покрытия (ATE_COV.2)

ATE_COV.2.1D –Разработчик должен представить анализ покрытия тестами.

ATE_COV.2.1C – Анализ покрытия тестами должен демонстрировать соответствие между тестами, идентифицированными в тестовой документации, и описанием ФБО в функциональной спецификации.

ATE_COV.2.2C – Анализ покрытия тестами должен демонстрировать полное соответствие между описанием ФБО в функциональной спецификации и тестами, идентифицированными в тестовой документации.

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

 

5.2.6.2 Тестирование: проект верхнего уровня (ATE_DPT.1)

ATE_DPT.1.1D – Разработчик должен представить анализ глубины тестирования.

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

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

 

5.2.6.3 Функциональное тестирование (ATE_FUN.1)

ATE_FUN.1.1D – Разработчик должен протестировать ФБО и задокументировать результаты.

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

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

ATE_FUN.1.2C – Планы тестирования должны идентифицировать проверяемые функции безопасности и содержать изложение целей тестирования.

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

ATE_FUN.1.4C – Ожидаемые результаты тестирования должны показать прогнозируемые выходные данные успешного выполнения тестов.

ATE_FUN.1.5C – Результаты выполнения тестов разработчиком должны демонстрировать, что каждая проверенная функция безопасности выполнялась в соответствии со спецификациями.

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

5.2.6.4 Выборочное независимое тестирование (ATE_IND.2)

ATE_IND.2.1D – Разработчик должен представить ОО для тестирования.

ATE_IND.2.1C – ОО должен быть пригоден для тестирования.

ATE_IND.2.2C –Разработчик должен представить набор ресурсов, эквивалентных использованным им при функциональном тестировании ФБО.

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

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

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

5.2.7 Оценка уязвимостей (AVA)

5.2.7.1 Экспертиза руководств (AVA_MSU.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 –Оценщик должен сделать независимое заключение, что использование руководств позволяет выявить все опасные состояния.

 

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

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

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

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

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

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

 

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

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

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

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

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

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

 

Поделиться:





Воспользуйтесь поиском по сайту:



©2015 - 2024 megalektsii.ru Все авторские права принадлежат авторам лекционных материалов. Обратная связь с нами...