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



страница14/19
Дата05.03.2019
Размер1.38 Mb.
ТипРеферат
1   ...   11   12   13   14   15   16   17   18   19

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

6.1.1Автоматизация УК (ACM_AUT)


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

ACM_AUT.1.2D разработчик должен представить план УК.

ACM_AUT.1.1C система УК должна предоставить автоматизированные средства, с использованием которых в представлении реализации ОО производятся только санкционированные изменения.

ACM_AUT.1.2C система УК должна предоставить автоматизированные средства для поддержки генерации ОО.

ACM_AUT.1.3C план УК должен содержать описание автоматизированных инструментальных средств, используемых в системе УК.

ACM_AUT.1.4C план УК должен содержать описание, как автоматизированные инструментальные средства используются в системе УК.

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

6.1.2Возможности УК (ACM_CAP)


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

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

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

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

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

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

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

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

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

ACM_CAP.4.7С план УК должен содержать описание, как используется система УК.

ACM_CAP.4.8С свидетельство должно показать, что система УК действует в соответствии с планом УК.

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

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

ACM_CAP.4.11C система УК должна поддерживать генерацию ОО.

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

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


6.1.3Охват УК (ACM_SCP)


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

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

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

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


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

6.2.1Поставка (ADO_DEL)


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

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

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

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

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

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


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


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

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

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

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


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

6.3.1Функциональная спецификация (ADV_FSP)


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

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

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

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

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

ADV_FSP.2.5C функциональная спецификация должна включать логическое обоснование того, что ФБО полностью представлены.

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

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


6.3.2Проект верхнего уровня (ADV_HLD)


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_EXP.2.9C проект верхнего уровня должен определять криптографические границы.

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

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

6.3.3Представление реализации (ADV_IMP)


ADV_IMP.2.1D разработчик должен обеспечить представление реализации для всего ФБО.

ADV_IMP.2.1C представление реализации должно однозначно определить ФБО на таком уровне детализации, что ФБО могут быть созданы без дальнейших проектных решений.

ADV_IMP.2.2C представление реализации должно быть внутренне непротиворечивым.

ADV_IMP.2.3C представление реализации должно включать описание взаимосвязей между всеми частями реализации.

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

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


6.3.4Внутренняя структура ФБО (ADV_INT)


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

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

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

ADV_INT.1.1C описание архитектуры должно идентифицировать модули ФБО.

Замечания по применению: Криптографический модуль является частью проекта ФБО.

ADV_INT.1.2C описание архитектуры должно содержать описание назначения, интерфейсов, параметров и результатов применения каждого модуля ФБО.

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

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

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

6.3.5Проект нижнего уровня (ADV_LLD)


ADV_LLD.1.1D разработчик должен представить проект нижнего уровня ФБО.

ADV_LLD.1.1C представление проекта нижнего уровня должно быть неформальным.

ADV_LLD.1.2C проект нижнего уровня должен быть внутренне непротиворечивым.

ADV_LLD.1.3C проект нижнего уровня должен содержать описание ФБО в терминах модулей.

ADV_LLD.1.4C проект нижнего уровня должен содержать описание назначения каждого модуля.

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



ADV_LLD_EXP.1.5C проект нижнего уровня должен включать описание или диаграмму изменений состояния криптографического модуля.

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

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

ADV_LLD_EXP.1.7C физические/логические порты криптографического модуля должны быть определены.

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

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

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



ADV_LLD_EXP.1.10C проект нижнего уровня должен определять криптографические границы.

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

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

6.3.6Соответствие представлений (ADV_RCR)


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

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

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

6.3.7Моделирование политики безопасности (ADV_SPM)


ADV_SPM.1.1D разработчик должен представить модель ПБО.

ADV_SPM.1.2D разработчик должен демонстрировать соответствие между функциональной спецификацией и моделью ПБО.

ADV_SPM.1.1C модель ПБО должна быть неформальной.

ADV_SPM.1.2C модель ПБО должна содержать описание правил и характеристик всех политик ПБО, которые могут быть смоделированы.



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

ADV_SPM.1.3C модель ПБО должна включать логическое обоснование, которое демонстрирует, что она согласована и полна относительно всех политик ПБО, которые могут быть смоделированы.

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

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




Поделитесь с Вашими друзьями:
1   ...   11   12   13   14   15   16   17   18   19


База данных защищена авторским правом ©vossta.ru 2017
обратиться к администрации

    Главная страница