LINEBURG


<< Пред. стр.

страница 10
(всего 26)

ОГЛАВЛЕНИЕ

След. стр. >>

соответствующие разделы проекта нижнего уровня. Соответствующее заключение следует
сделать совместно с выполнением подвида деятельности ADV_RCR.1, если этот подвид
деятельности является частью оценки.
Оценщик анализирует проект нижнего уровня, чтобы сделать заключение, полностью ли
385

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

5.8 Оценка соответствия представлений
5.8.1 Подвид деятельности ADV_RCR.1
5.8.1.1 Цели
Цель данного подвида деятельности – сделать заключение, правильно ли и полностью ли
386

разработчик реализовал требования ЗБ на всех уровнях абстракции проекта, включенных в
свидетельство оценки. Выполнение данного подвида деятельности зависит от того, какие
компоненты доверия из класса ADV были включены в пакет доверия. Если в пакет доверия
включены компоненты из всех четырех семейств ADV_FSP, ADV_HLD, ADV_LLD, и
ADV_IMP, то цель данного подвида деятельности – сделать заключение, правильно ли и
полностью ли разработчик реализовал требования ЗБ в функциональной спецификации,
проекте верхнего уровня, проекте нижнего уровня и в представлении реализации.
5.8.1.2 Замечания по применению
Необязательно, чтобы неформальная демонстрация соответствия была в повествовательной
387

форме; достаточным может быть простого двухмерного отображения. Например, матрица с
перечисленными по одной оси модулями и перечисленными по другой оси подсистемами, в
которой ячейки указывают на соответствие модулей и подсистем, была бы полезна для
представления адекватного неформального соответствия между проектом верхнего уровня
и проектом нижнего уровня. Так же простого отображения может быть достаточно для
демонстрации соответствия между другими представлениями ФБО.
5.8.1.3 Исходные данные
Безусловным свидетельством оценки для этого подвида деятельности является ЗБ.
388

Остальные безусловные свидетельства оценки для этого подвида деятельности зависят от
389

того, какие компоненты из класса ADV были включены в пакет доверия.
Если в пакет доверия включен компонент из семейства ADV_FSP, то безусловные
390

свидетельства оценки для этого подвида деятельности также включают:
а) функциональную спецификацию;
б) материалы анализа соответствия между краткой спецификацией ОО и функциональной
спецификацией.
Если кроме этого в пакет доверия включен компонент из семейства ADV_HLD, то
391

безусловные свидетельства оценки для этого подвида деятельности также включают:
а) проект верхнего уровня;



65
б) материалы анализа соответствия между функциональной спецификацией и проектом
верхнего уровня.
Если кроме этого в пакет доверия включен компонент из семейства ADV_LLD, то
392

безусловные свидетельства оценки для этого подвида деятельности также включают:
а) проект нижнего уровня;
б) материалы анализа соответствия между проектом верхнего уровня и проектом нижнего
уровня.
Если кроме этого в пакет доверия включен компонент из семейства ADV_IMP, то
393

безусловные свидетельства оценки для этого подвида деятельности также включают:
a) подмножество представления реализации;
б) материалы анализа соответствия между проектом нижнего уровня и подмножеством
представления реализации.
5.8.1.4 Действия оценщика
Этот подвид деятельности включает один элемент действий оценщика из части 3 ОК:
394

а) ADV_RCR.1.1E.
5.8.1.4.1 Действие ADV_RCR.1.1E
ADV_RCR.1.1C
ADV_RCR.1-1 Оценщик должен исследовать материалы анализа соответствия между краткой
спецификацией ОО и функциональной спецификацией, чтобы сделать
заключение, является ли функциональная спецификация корректным и полным
представлением функций безопасности ОО.
Если функциональная спецификация не включена в состав свидетельств оценки вследствие
395

того, что ни один из компонентов из семейства ADV_FSP не включен в пакет доверия, то
рассматриваемый шаг оценивания не применяется.
Цель оценщика на этом шаге оценивания – сделать заключение, что все функции
396

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

спецификации ОО и в функциональной спецификации. Оценщик ожидает
непротиворечивого и точного соответствия. Если материалы анализа соответствия
указывают на связь между описанием функции безопасности в краткой спецификации ОО и
описанием интерфейса в функциональной спецификации, оценщик верифицирует, что
функциональные возможности функции и интерфейса одни и те же. Если функции
безопасности в краткой спецификации ОО точно и полно представлены в описании
соответствующего интерфейса, рассматриваемый шаг оценивания считается выполненным.
Данный шаг оценивания может быть выполнен совместно с шагами оценивания
398

ADV_FSP.2-8 и ADV_FSP.2-9.
ADV_RCR.1-2 Оценщик должен исследовать материалы анализа соответствия между
функциональной спецификацией и проектом верхнего уровня, чтобы сделать
заключение, является ли проект верхнего уровня корректным и полным
представлением функциональной спецификации.
Если проект верхнего уровня не включен в состав свидетельств оценки вследствие того, что
399

ни один из компонентов из семейства ADV_HLD не включен в пакет доверия, то
рассматриваемый шаг оценивания не применяется.

66
Оценщик использует материалы анализа соответствия, функциональную спецификацию и
400

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

ни один из компонентов из семейства ADV_LLD не включен в пакет доверия, то
рассматриваемый шаг оценивания не применяется.
Оценщик использует материалы анализа соответствия, проект верхнего уровня и проект
402

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

вследствие того, что ни один из компонентов из семейства ADV_IMP не включен в пакет
доверия, то рассматриваемый шаг оценивания не применяется.
Так как оценщик исследует только подмножество представления реализации, этот шаг
404

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

5.9 Оценка моделирования политики безопасности ОО
5.9.1 Подвид деятельности ADV_SPM.1
5.9.1.1 Цели
Цель данного подвида деятельности – сделать заключение, описывает ли модель политики
405

безопасности ОО четко и непротиворечиво правила и характеристики политик
безопасности ФБ, и соответствует ли это описание описанию функций безопасности в
функциональной спецификации.
5.9.1.2 Замечания по применению

67
Модель описывает политики, осуществляемые теми функциями и услугами безопасности,
406

которые описаны в функциональной спецификации. Неформальная модель – это просто
описание политик безопасности, осуществляемых услугами или функциями безопасности,
доступными через внешний интерфейс. Например, политики управления доступом обычно
описывают защищаемые ресурсы и условия, которые должны быть обеспечены для
предоставления доступа; политики аудита обычно описывают потенциально подвергаемые
аудиту события ОО, идентифицируя, как те, которые выбираются администратором, так и
те, которые всегда подвергаются аудиту; политики идентификации и аутентификации
обычно описывают, как идентифицируются пользователи, как аутентифицируется
заявленная идентификационная информация, а также какие-либо правила, влияющие на то,
каким образом аутентифицируется идентификационная информация (например, для
пользователей корпоративной интранет (внутренней сети) аутентификация не требуется, в
то время как внешние пользователи аутентифицируются на основе одноразовых паролей).
5.9.1.3 Исходные данные
Безусловными свидетельствами оценки для этого подвида деятельности являются:
407

а) ЗБ;
б) модель политики безопасности ОО.
Свидетельством оценки для этого подвида деятельности, обусловленным зависимостями из
408

ОК, является функциональная спецификация.
Свидетельствами оценки для этого подвида деятельности, которые требуются для
409

выполнения шагов оценивания, являются:
а) руководство пользователя;
б) руководство администратора.
5.9.1.4 Действия оценщика
Этот подвид деятельности включает один элемент действий оценщика из части 3 ОК:
410

а) ADV_SPM.1.1E.
5.9.1.4.1 Действие ADV_SPM.1.1E
ADV_SPM.1.1C
ADV_SPM.1-1 Оценщик должен исследовать модель политики безопасности ОО, чтобы
сделать заключение, содержит ли она весь необходимый неформальный
пояснительный текст.
Если вся модель политики безопасности ОО является неформальной, то рассматриваемый
411

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

на основе полуформального или формального описания, требуется вспомогательное
описание в повествовательной форме (например, чтобы сделать понятными значения всех
формальных обозначений).
ADV_SPM.1.2C
ADV_SPM.1-2 Оценщик должен проверить модель политики безопасности ОО, чтобы сделать
заключение, все ли политики ФБ, которые явным образом включены в ЗБ,
смоделированы.
Политика безопасности выражается в ЗБ через совокупность функциональных требований
413

безопасности. Поэтому, чтобы сделать заключение о характере политики безопасности (а,
следовательно, о том, какие политики ФБ должны быть смоделированы), оценщик

68
анализирует функциональные требования из ЗБ для тех политик ФБ, которые затребованы
явным образом (компонентами требований из семейств FDP_ACC и FDP_IFC, если таковые
включены в ЗБ).
В зависимости от ОО, формальное/полуформальное моделирование может быть
414

невозможно даже для управления доступом (например, политика управления доступом для
межсетевого экрана, подключенного к Интернету, не может быть надлежащим образом
формально смоделирована, потому что состояние Интернета не может быть полностью
определено). Любая политика безопасности, для которой создание формальной или
полуформальной модели невозможно, должна быть представлена в неформальном виде.
Если ЗБ не содержит явных политик ФБ (вследствие того, что компоненты требований ни
415

из семейства FDP_ACC, ни из семейства FDP_IFC не включены в ЗБ), то рассматриваемый
шаг оценивания не применяется.
ADV_SPM.1-3 Оценщик должен исследовать модель политики безопасности ОО, чтобы
сделать заключение, все ли политики ФБ, представленные функциональными
требованиями безопасности, заявленными в ЗБ, смоделированы.
Кроме перечисленных в явном виде политик ФБ (см. шаг оценивания ADV_SPM.1-2),
416

оценщик анализирует функциональные требования безопасности из ЗБ для тех политик ФБ,
наличие которых предполагается в связи с другими классами функциональных требований
безопасности. Например, включение компонентов требований класса FDP (за исключением
FDP_ACC и FDP_IFC) обычно требует описания осуществляемой политики защиты
данных; включение компонентов требований класса FIA обычно требует, чтобы в модели
политики безопасности ОО было представлено описание политик ФБ идентификации и
аутентификации; включение компонентов требований безопасности класса FAU требует
описания политик ФБ аудита и т.д. Хотя компоненты функциональных требований
безопасности из других семейств обычно не ассоциируются с тем, что понимается как
политики ФБ, однако они все же обеспечивают выполнение ряда политик ФБ (например,
таких как неотказуемость, посредничество при обращениях, приватность и т.д.), которые
должны быть включены в модель политики безопасности ОО.
В случаях, когда представление модели политики безопасности ОО является
417

неформальным, все политики ФБ могут быть смоделированы (то есть, описаны) и, таким
образом, должны быть включены в модель. Любая политика безопасности, для которой
создание формальной или полуформальной модели невозможно, должна быть представлена
в неформальном виде.
Если ЗБ не содержит таких подразумеваемых правил, то рассматриваемый шаг оценивания
418

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

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

69
значения этих атрибутов. Например, если в политике безопасности предпринята попытка
учесть вопросы целостности данных, то, как правило, в модели политики безопасности ОО:
а) определяется понятие целостности для рассматриваемого ОО;
б) идентифицируются типы данных, для которых ОО поддерживает целостность;
в) идентифицируются сущности, которые могут модифицировать данные указанных типов;
г) идентифицируются правила, которые должны выполняться при модификации данных.
ADV_SPM.1.3C
ADV_SPM.1-5 Оценщик должен исследовать обоснование модели политики безопасности ОО,
чтобы сделать заключение, согласован ли смоделированный режим
функционирования ОО с правилами, описанными в политиках ФБ (т.е.,
сформулированными в соответствии с функциональными требованиями из ЗБ).
Делая заключение о непротиворечивости, оценщик верифицирует, что обоснование
420

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

лежащих в основе функциональных требований безопасности ОО. Доверие складывается из
двух составляющих. Сведение описаний каждой политики ФБ в краткое единое целое
помогает в понимании деталей осуществляемых политик. Кроме того, такое сводное
описание намного упрощает поиск каких бы то ни было огрехов или противоречий (чего и
требуется добиться как части элемента требования ADV_SPM.*.3C) и обеспечивает четкую
характеристику безопасных состояний (чего и требуется добиться как части требований
элемента ADV_SPM.*.2C).
Рассматриваемое требование к неформальной модели политики безопасности (НМПБ)
422

выполняется путем четкого изложения политики безопасности ОО. Необходимость в
оформлении НМПБ в виде отдельного документа не является безусловной, так как для
очень простых (очевидных) политик ФБ или политик ФБ, которые очень четко определены
в ЗБ, необходимости в отдельном оформлении НМПБ может и не быть. В таких случаях
различные разделы ЗБ (например, требования безопасности, краткая спецификация ОО)
могут в сочетании друг с другом обеспечить для описания политики безопасности
достаточный уровень детализации. Однако, зачастую это не так. Например, требования
аудита могут быть разнесены по всем функциональным требованиям безопасности ОО и не
обеспечивать четкую модель политики ФБ в целом. Если только в другом разделе ЗБ
(возможно в краткой спецификации ОО) все требования аудита не будут собраны во
взаимосвязанное целое, то возникает необходимость в отдельном документе НМПБ для
того, чтобы иметь возможность обнаружить противоречия в требованиях ЗБ, которые иначе
могут остаться необнаруженными.

70
Когда разработчик утверждает, что требования к НМПБ для некоторых или для всех
423

политик ФБ удовлетворены через ЗБ, оценщику, используя требования компонента
ADV_SPM.1, необходимо сделать заключение, что это именно так, то есть, сделать
заключение, что политика ясно выражена, и что модель является согласованной с
остальными частями ЗБ. В тех случаях, когда разработчик утверждает, что НМПБ
полностью отражена в ЗБ, в качестве части обоснования НМПБ надлежащим является,
чтобы в обосновании была ссылка на материалы демонстрации пригодности отдельных
частей ЗБ и их соответствия друг другу. При выполнении данного шага оценивания
оценщик может использовать соответствующие результаты оценки ЗБ.
Руководство по анализу непротиворечивости см. в подразделе 10.3.
424

ADV_SPM.1-6 Оценщик должен исследовать обоснование модели политики безопасности ОО,
чтобы сделать заключение о полноте смоделированного режима
функционирования ОО по отношению к правилам, описанным в политиках ФБ
(т.е., сформулированным в соответствии с функциональными требованиями из
ЗБ).
Для заключения о полноте обоснования оценщик рассматривает правила и характеристики
425

модели политики безопасности ОО и сопоставляет их с правилами и характеристиками
политики безопасности, изложенными в явном виде (т.е., функциональными
требованиями). Обоснование должно показать, что для всех политик ФБ, которые должны
быть смоделированы, в модели политики безопасности ОО имеется описание связанных с
ними правил или характеристик.
Когда разработчик утверждает, что требования к НМПБ для некоторых или для всех
426

политик ФБ удовлетворены через ЗБ, оценщику, используя требования компонента
ADV_SPM.1, необходимо сделать заключение, что это именно так, т.е., сделать
заключение, что политика четко выражена, и что модель является полной по отношению к
остальным частям ЗБ. При выполнении данного шага оценивания оценщик может
использовать соответствующие результаты оценки полноты различных частей ЗБ.
ADV_SPM.1.4C
ADV_SPM.1-7 Оценщик должен исследовать материалы демонстрации соответствия между
моделью политики безопасности ОО и функциональной спецификацией, чтобы
сделать заключение, идентифицированы ли в этих материалах все функции
безопасности, описанные в функциональной спецификации, которые реализуют
какую-либо часть политики безопасности.
Для заключения о полноте оценщик просматривает функциональную спецификацию,
427

определяет, какие из функций непосредственно поддерживают модель политики
безопасности ОО, и верифицирует наличие этих функций в материалах демонстрации
соответствия функциональной спецификации и модели политики безопасности ОО.
ADV_SPM.1-8 Оценщик должен исследовать материалы демонстрации соответствия между
моделью политики безопасности ОО и функциональной спецификацией, чтобы
сделать заключение, согласуется ли описание функций безопасности,

<< Пред. стр.

страница 10
(всего 26)

ОГЛАВЛЕНИЕ

След. стр. >>

Copyright © Design by: Sunlight webdesign