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



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

6.6Тестирование (ATE)

6.6.1Покрытие (ATE_COV)


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

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

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

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


6.6.2Глубина (ATE_DPT)


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

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

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

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


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 оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.


6.6.4Независимое тестирование (ATE_IND)


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

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

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

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

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

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


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

6.7.1Дополнительно: Анализ скрытых каналов криптографического модуля (AVA_CCA_EXP.1)


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

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



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

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

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

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

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

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

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

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

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

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


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


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 оценщик должен подтвердить, что документация анализа показывает обеспечение руководством безопасного функционирования во всех режимах эксплуатации ОО.

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


Замечания по применению: Функции безопасности, для которых определены утверждения стойкости, указаны в п.п. 5.2.1, 5.2.2 и 5.4.3.

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

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

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

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

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


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


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



Каталог: wp-content -> uploads -> 2010
2010 -> Принципы доказательной медицины как основа разработки метода и аппаратуры для
2010 -> Два подземных этажа
2010 -> Методическое пособие по сердечно легочной и церебральной реанимации Утвержденное: Российской академией медицинских наук Учреждением Российской академии медицинских наук
2010 -> Здесь представлена подборка заметок и коротеньких статей Нины Рубштейн, очень интересных и важных, на мой взгляд, для специали
2010 -> Уильям Сирс и Марта Сирс
2010 -> Слабое использование в работе адм
2010 -> Б цилиарное тело
2010 -> Российская федерация федеральный закон


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


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

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