Законодательная база Российской Федерации

"МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ. КРИТЕРИИ ОЦЕНКИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ. Часть 3. ТРЕБОВАНИЯ ДОВЕРИЯ К БЕЗОПАСНОСТИ. ГОСТ Р ИСО/МЭК 15408-3-2008" (утв. Приказом Ростехрегулирования от 18.12.2008 N 521-ст)

Класс ADV "Разработка" содержит четыре семейства требований для представления ФБО на различных уровнях абстракции - от функционального интерфейса до представления реализации. Класс ADV "Разработка" включает в себя также семейство требований для отображения соответствия между различными представлениями ФБО, требуя, в конечном счете, демонстрацию соответствия от наименее абстрактного представления через все промежуточные представления до краткой спецификации ОО, содержащейся в ЗБ. Кроме того, имеется семейство требований для модели ПБО и для отображения соответствия между ПБО, моделью ПБО и функциональной спецификацией. И, наконец, имеется семейство требований к внутренней структуре ФБО, которое распространяется на такие аспекты, как модульность, разбиение на уровни и минимизация сложности.

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

Связи между "различным" представлениями ФБО и требованиями, с которыми они связаны, показаны на рисунке 10. Классы АРЕ и ASE определяют требования соответствия между функциональными требованиями и целями безопасности, а также между целями безопасности и ожидаемой средой ОО. Класс ASE также определяет требован ил к соответствию между целями безопасности, функциональными требованиями и краткой спецификацией ОО.

Требования для всех других соответствий, показанных на рисунке 10, определены в классе ADV "Разработка". Семейство AOV_SPM "Моделирование политики безопасности/' определяет требования соответствия между ПБО и моделью ПБО, а также между моделью ПБО и функциональной спецификацией. Семейство ADV_RCR "Соответствие представлений" определяет требования соответствия между всеми имеющимися представлениями ФБО - от краткой спецификации ОО до представления реализации. Наконец, каждое семейство доверия, относящееся к конкретному представлению ФБО (то есть ACV_FSP "Функциональная спецификация", ADV_HLD "Проект верхнего уровня", ADV_LLD "Проект нижнего уровнял и ADV_IMP "Представление реализации", определяет требования, устанавливающие связь между представлением ФБО и функциональными требованиями, сочетание которых помогает убедиться в том, что функциональные требования безопасности ОО были учтены. Анализ прослеживания будет выполняться всегда, начиная с самого высокого уровня представления ФБО, включая каждое из имеющихся представлений ФБО. ИСО/МЭК 15408 реализует это требование прослеживания, используя зависимости от семейства ADV_RCR "Соответствие представлений". Семейство ADV_JNT "Внутренняя структура ФБО" на рисунке 10 не представлено, поскольку оно связано с внутренней структурой ФБО и имеет лишь косвенное отношение к процессу уточнения представлений ФБО.

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

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

Хотя требования семейства ASE_TSS "Краткая спецификация ОО" и некоторых других семейств класса ASE предусматривают несколько различных представлений ФБО, совсем необязателен отдельный документ для каждого представления ФБО. Действительно, возможен случай, когда один документ выполняет требования по документированию нескольких представлений ФБО, а объединение в нем требуемой информации по каждому из этих представлений ФБО предпочтительнее, несмотря на усложнение структуры данного документа. В случае, если несколько представлений ФБО объединены в одном документе, разработчику следует указать конкретно, е каких документах какие представления содержатся.

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

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

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

Формальную спецификацию налагают с использованием нотации, основанной на известных математических понятиях, и обычно сопровождают вспомогательным пояснительным (неформальным) текстом. Эти математические понятия используют для того, чтобы определить синтаксис и семантику нотации и правила доказательства, поддерживающие логическую аргументацию. Необходимо, чтобы синтаксические и семантические правила, регламентирующие формальную нотацию, определяли, как однозначно распознавать конструкции и определять их значение. Требуется свидетельство невозможности вывода противоречий. а правила, регламентирующие нотацию, необходимо определить или привести ссылку на них.

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

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

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

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

Элементы ADV_RCR.*.1С содержат требование, чтобы разработчик представил свидетельство для каждой смежной пары представлений ФБО, что все относящиеся к безопасности функциональные возможности более абстрактного представления ФБО уточнены в менее абстрактном представлении ФБО. Каждый из элементов ADV_FSP.*.2E, ADV_HLD.*2E, ADV_LLD.*.2E и ADV_IMP.*2E содержит требование, чтобы оценщик сделал заключение о том, что ФБО, представляемые этим семейством требований, - точное и полное отображение функциональных требований безопасности ОО. Предполагается, что оценщик использует свидетельство, предоставленное разработчиком в соответствии ADV_RCR.*1С, как основание для такого заключения. Устанавливая соответствие между функциональными требованиями безопасности ОО и каждым из цепочки последовательных представлений ФБО, этот пошаговый процесс предоставит, в конечном счете, более высокое доверие соответствию наименее абстрактного представления ФБО функциональным требованиям безопасности ОО, что и является конечной целью данного класса.

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

Декомпозиция класса ADV "Разработка" на составляющие его семейства и иерархия компонентов этих семейств показаны на рисунке 11.

14.1.1 Цели

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

14.1.2 Ранжирование компонентов

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

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

14.1.5.2.2 ADV_FSP.2.2C

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

14.1.5.2.3 ADV_FSP.2.3C

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

14.15.2.4 ADV_FSP2.4C

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

14.1.5.2.5 ADV_FSP.2.5C

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

14.1.5.3 Элементы действий оценщика

14.1.5.5.1 ADV_FSP.2.1E

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

14.1.5.3.2 AD V_FSP 2 .2Е

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

14.1.6 ADV_FSP.3 Полуформальная функциональная спецификация

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

14.1.6.1 Элементы действий разработчика

14.1.6.1.1 ADV_FSP.3.1D

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

14.1.6.2 Элементы содержания и представления свидетельств

14.1.6.2.1 ADV_FSP.3.1C

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

14.1.6.2.2 ADV_FSP.3.2C

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

14.1.6.2.3 ADV_FSP.3.3C

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

14.1.6.2.4 AD V_FSP.3.4С

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

14.1.6.2.5 ADV_FSP.3.5C

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

14.1.6.3 Элементы действий оценщика

14.1.6.3.1 ADV_FSP.3.1Е

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

14.1.6.3.2 ADV_FSP.3.2Е

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

14.1.7 ADV_FSP.4 Формальная функциональная спецификация

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

14.1.7.1 Элементы действий разработчика

14.1.7.1.1 ADV_FSP.4.1D

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

14.1.7.2 Элементы содержания и представления свидетельств

14.1.7.2.1 ADV_FSP.4.1C

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

14.1.7.2.2 ADV_FSP.4.2C

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

14.1.7.2.3 ADV_FSP.4.3C

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

14.1.7.2.4 ADV_FSP.4.4C

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

14.1.7.2.5 ADV_FSP.4.5C

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

14.1.7.3 Элементы действий оценщика

14.1.7.3.1 ADV_FSP.4.1E

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

14.1.7.3.2 ADV_FSP.4.2E

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

14.2.1 Цели

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

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

14.2.2 Ранжирование компонентов

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

14.2.3 Замечания по применению

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

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

Выражение "подсистема, осуществляющая ПВО" относится к подсистеме, которая прямо или косвенно содействует осуществлению ПВО.

Элементы ADV_HLD.*.2E данного семейства определяют требование вынесения оценщиком заключения о том, что проект верхнего уровня является точным и полным отображением функциональных требований безопасности ОО. Это обеспечивает прямое соответствие между функциональными требованиями безопасности ОО и проектом верхнего уровня в дополнение к попарным соответствиям, требуемым семейством ADV_RCR "Соответствие представлений". Ожидается, что оценщик использует свидетельство, включенное в ADV_RCR "Соответствие представлений", как основание для этого заключения, а требование полноты предполагает соотнесение с уровнем абстракции проекта верхнего уровня.

ADV_HLD.3.8C содержит требование полного представления интерфейсов подсистем. Этим будет обеспечена необходимая детализации для поддержки как полного тестирования ОО (с использованием компонентов из ATE_DPT "Глубина"), так и оценки уязвимостей.

Применительно к уровню формализации проекта верхнего уровня неформальный, полуформальный и формальный проекты рассматривают как иерархичные по сути. Так, элементы требований ADV_HLD1.1С и ADV_HLD.2.1C могут быть удовлетворены использованием полуформального или формального проекта верхнего уровня, а элементы требований ADV_HLD.3.1C и ADV_HLD.4.1C - использованием формального проекта верхнего уровня.

В ADV_HLD.*.5C выражение "базовые аппаратные, программно-аппаратные и/или программные средства" относится к виртуальной машине, на базе которой работает ОО (если таковая имеется), а не к механизмам самого ОО (к которым относятся другие части компонента). Как таковые требования ADV_HLD.*.5C являются требованиями к информации о среде ИТ.

14.2.4 ADV_HLD.1 Описательный проект верхнего уровня

Зависимости: ADV_FSP.1 Неформальная функциональная спецификация

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

14.2.4.1 Элементы действий разработчика

14.2.4.1.1 ADV_HLD.1.1D

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

14.2.4.2 Элементы содержания и представления свидетельств

14.2.4.2.1 ADV_HLD.1.1С

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

14.2.4.2.2 ADV_HLD.1.2C

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

14.2.4.2.3 ADV_HLD.1.3C

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

14.2.4.2.4 ADV_НLD.1.4C

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

14.2.4.2.5 ADV_HLD.1.5C

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

14.2.4.2.6 ADV_HLD.1.6C

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

14.2.4.2.7 ADV_HLD.1.7C

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

14.2.4.3 Элементы действий оценщика

14.2.4.3.1 ADV_HLD.1.1E

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

14.2.4.3.1 ADV_HLD.1.2E

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

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

Зависимости: ADV_FSP.1 Неформальная функциональная спецификация

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

14.2.5.1 Элементы действий разработчика

14.2.5.1.1 ADV_HLD.2.1D

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

14.2.5.2 Элементы содержания и представления свидетельств

14.2.5.2.1 ADV_HLD.2.1C

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

14.2.5.2.2 ADV_HLD.2.2C

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

14.2.5.2.3 ADV_HLD.2.3C

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

14.2.5.2.4 ADV_HLD.2.4C

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

14.2.5.2.5 ADV_HLD.2.5С

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

14.2.5.2.6 ADV_HLD.2.6C

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

14.2.5.2.7 ADV_HLD.2.7C

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

14.2.5.2.8 ADV_HLD.2.8C

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

14.2.5.2.9 ADV_HLD.2.9C

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

14.2.5.3 Элементы действий оценщика

14.2.5.3.1 ADV_HLD.2.1E

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

14.2.5.3.2 ADV_HLD.2.2E

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

14.2.6 ADV_HLD.3 Полуформальный проект верхнего уровня

Зависимости: ADV_FSP.3 Полуформальная функциональная спецификация

ADV_RCR.2 Полуформальная демонстрация соответствия

14.2.6.1 Элементы действий разработчика

14.2.6.1.1 ADV_HLD.3.1D

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

14.2.6.2 Элементы содержания и представления свидетельств

14.2.6.2.1 ADV_HLD.3.1С

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

14.2.6.2.2 ADV_HLD.3.2C

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

14.2.6.2.3 ADV_HLD.3.3C

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

14.2.6.2.4 ADV_HLD.3.4C

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

14.2.6.2.5 ADV_HLD.3.5C

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

14.2.6.2.6 ADV_HLD.3.6C

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

14.2.6.2.7 ADV_HLD.3.7C

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

14.2.6.2.8 ADV_HLD.3.8C

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

14.2.6.2.9 ADV_HLD.3.9C

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

14.2.6.3 Элементы действий оценщика

14.2.6.3 1ADV_HLD.3.1E

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

14.2.6.3 2 ADV_HLD.3.2E

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

14.2.7 ADV_HLD.4 Пояснения в полуформальном проекте верхнего уровня

Зависимости: ADV_FSP.3 Полуформальная функциональная спецификация

ADV_RCR.2 Полуформальная демонстрация соответствия

14.2.7.1 Элементы действий разработчика

14.2.7.1.1 ADV_HLD.4.1D

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

14.2.7.2 Элементы содержания и представления свидетельств

14.2.7.2.1 ADV_HLD.4.1C

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

14.2.7.2.2 ADV_HLD.4.2C

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

14.2.7.2.3 ADV_HLD.4.3C

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

14.2.7.2.4 ADV_HLD.4.4C

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

14.2.7.2.5 ADV_HLD.4.5C

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

14.2.7.2.6 ADV_HLD.4.6C

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

14.2.7.2.7 ADV_HLD.4.7C

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

14.2.7.2.8 ADV_HLD.4.8C

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

14.2.7.2.9 ADV_HLD.4.9C

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

14.2.7.2.10 ADV_HLD.4.10С

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

14.2.7.2.11 ADV_HLD.4.11С

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

14.2.7.3 Элементы действий оценщика

14.2.7.3.1 ADV_HLD.4.1E

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

14.2.7.3.2 ADV_HLD.4.2E

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

14.2.8 ADV_НLD.5 Формальный проект верхнего уровня

Зависимости: ADV_FSP.4 Формальная функциональная спецификация

ADV_RCR.3 Формальная демонстрация соответствия

14.2.8.1 Элементы действий разработчика

14.2.8.1.1 ADV_HLD.5.1D

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

14.2.8.2 Элементы содержания и представления свидетельств

14.2.8.2.1 ADV_HLD.5.1С

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

14.2.8.2.2 ADV_HLD.5.2C

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

14.2.8.2.3 ADV_HLD.5.3С

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

14.2.8.2.4 ADV_HLD.5.4C

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

14.2.8.2.5 ADV_HLD.5.5C

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

14.2.8.2.6 ADV_HLD.5.6C

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

14.2.8.2.7 ADV.HLD.5.7C

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

14.2.8.2.8 ADV_HLD.5.8C

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

14.2.8.2.9 ADV_HLD.5.9C

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

14.2.8.2.10 ADV_HLD.5.10С

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

14.2.8.2.11 ADV_HLD.5.11C

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

14.2.3.3 Элементы действий оценщика

14.2.8.31 ADV_HLD.5.1E

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

14.2.8.3.2 ADV_HLD.5.2E

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

14.3.1 Цели

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

14.3.2 Ранжирование компонентов

Компоненты в этом семействе ранжированы на основе полноты и структуры приведенного представления реализации.

14.3.3 Замечания по применению

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

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

14.3.4 ADV_IMP.1 Подмножество реализации ФБО

Зависимости: ADV_LLD.1 Описательный проект нижнего уровня

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

ALC_TAT.1 Полностью определенные инструментальные средства разработки

14.3.4.1 Замечаний по применению

ADV_IМР.1.1D содержит требование, чтобы разработчик обеспечил представление реализации для подмножества ФБО. Целью является доступ, по меньшей мере, к части ФБО, обеспечивающей оценщику возможность провести экспертизу представления реализации тех частей ОО, для которых подобная экспертиза может значительно увеличить понимание применяемых механизмов и доверие к ним. Подготовка выборки представления реализации позволит оценщику выборочно проверить свидетельство прослеживания требований безопасности в представлениям проекта ОО с тем, чтобы получить доверие к подходу, принятому для уточнения, и непосредственно оценить предъявленное представление реализации.

Элемент ADV_IMP.1.2Е определяет требование вынесения оценщиком независимого заключения о том, что наименее абстрактное представление ФБО является точным и полным отображением функциональных требований безопасности ОО. Этим обеспечивается прямое соответствие между функциональными требованиями безопасности ОО и наименее абстрактным представлением ФБО в дополнение к попарным соответствиям, требуемым семейством ADV_RCR "Соответствие представлений". Ожидается, что оценщик использует свидетельство, предоставляемое в ADV_RCR "Соответствие представлений", как основание для заключения об этом. Наименее абстрактное представление ФБО для этого компонента - совокупность имеющегося представления реализации и той части проекта нижнего уровня, для которой не имеется представления реализации.

14.3.4.2 Элементы действий разработчика

14.3.4.2.1 ADV_IMP.1.1D

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

14.3.4.3 Элементы содержания и представления свидетельств

14.3.4.3.1 ADV_IMP.1.1С

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

14.3.4.3.2 ADV_IMP.1.2C

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

14.3.4.4 Элементы действий оценщика

14.3.4.4.1 ADV_IMP.1.1 Е

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

14.3.4.42 ADV_IMP.1.2E

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

14.3.5 ADV_IMP2 Реализаций ФБО

Зависимости: ADV_LLD.1 Описательный проект нижнего уровня

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

АLС_ТАТ.1 Полностью определенные инструментальные средства разработки

14.3.5.1 Замечания по применению

Элемент ADV_IMP.2.2E определяет требование вынесения оценщиком независимого заключения о том, что представление ФБО является точным и полным отображением функциональных требований безопасности ОО. Этим обеспечивается прямое соответствие между функциональными требованиями безопасности ОО и представлением реализации в дополнение к попарным соответствиям, требуемым семейством ADV_RCR "Соответствие представлений". Ожидается, что оценщик использует свидетельство, предоставляемое в ADV_RCR "Соответствие представлений", как основание при вынесении этого заключения.

14.3.5.2 Элементы действий разработчика

14.3.5.2.1 ADV_IMP.2.1D

Разработчик должен обеспечить представление реализации для - всех ФБО.

14.3.5.3 Элементы содержания и представления свидетельств

14.3.53.1 ADV_IMP.2.1С

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

14.3.5.3.2 ADV_IMP.2.2C

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

14.3.5.3.3 ADV_IMP.2.3C

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

14.3.5.4 Элементы действий оценщика

14.3.5.4.1 ADV_IMP.2.1E

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

14.3.5.4.2 ADV_IMP.2.2E

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

14.3.6 ADV_IMP.3 Структурированная реализация ФБО

Зависимости: ADV_INT.1 Модульность

ADV_LLD.1 Описательный проект нижнего уровня

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

ALC_TAT.1 Полностью определенные инструментальные средства разработки

14.3.6.1 Замечания по применению

Элемент ADV_IMP.3.2E определяет требование вынесения оценщиком независимого заключения о том, что представление ФБО является точным и полным отображением функциональных требований безопасности ОО. Этим обеспечивается прямое соответствие между функциональными требованиями безопасности ОО и представлением реализации в дополнение к попарным соответствиям, требуемым семейством ADV_RCR "Соответствие представлений". Ожидается, что оценщик использует свидетельство, предоставляемое в ADV_RCR "Соответствие представлений", как основание при вынесении этого заключения.

14.3.6.2 Элементы действий разработчика

14.3.6.2.1 ADV_IMP.3.1D

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

14.3.6.3 Элементы содержания и представления свидетельств

14.3.6.3.1 ADV_IMP.3.1С

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

14.3.63.2 ADV_IMP.3.2C

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

14.3.6.3.3 ADV_IMP.3.3C

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

14.3.6.3.4 ADV_ IMP.3.4C

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

14.3.6.4 Элементы действий оценщика

14.3.6.4.1 ADV_IMP.3.1E

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

14.3.6.4.2 ADV_IMP.3.2Е

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

14.4.1 Цели

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

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

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

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

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

14.4.2 Ранжирование компонентов

Компоненты в таком семействе ранжированы на основе требуемых структурированности и минимизации.

14.4.3 Замечания по применению

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

Элементы ADV_INT.2.5C и ADV_INT.3.5C связаны с минимизацией взаимодействий между уровнями иерархии. Взаимодействие между уровнями допустимо, но при этом от разработчика требуется показать, что эти взаимодействия необходимы и их невозможно избежать.

ADV_INT.2.6C относится к концепции монитора обращений, требуя минимизации сложности тех частей ФБО, которые осуществляют политики управления доступом и/или управления информационными потоками, идентифицированные в ПБО. ADV_INT.3.6C развивает далее концепцию монитора обращений, требуя минимизации сложности всех ФБО.

Некоторые элементы в компонентах этого семейства ссылаются на описание архитектуры. Описание архитектуры выполняется на том же уровне абстракции, что и проект нижнего уровня в отношении модулей ФБО. Принимая во внимание, что проект нижнего уровня описывает модульную конструкцию ФБО, назначение описания архитектуры - предоставить при необходимости свидетельство модульности, разбиения на уровни и минимизации сложности ФБО. Требуется согласованность как проекта нижнего уровня, так и представления реализации с описанием архитектуры для обеспечения доверия к тому, что эти представления ФБО обладают требуемой модульностью, разбиением на уровни и минимизацией сложности.

14.4.4 ADV_INT.1 Модульность

Зависимости: ADV_IMP.1 Подмножество реализации ФБО

ADV_LLD.1 Описательный проект нижнего уровня

14.4.4.1 Элементы действий разработчика

14.4.4.1.1 ADV_INT.1.1D

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

14.4.4.1.2 ADV_INT.1.2D

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

14.4.4.2 Элементы содержания и представления свидетельств

14.4.4.2.1 ADV_INT.1.1С

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

14.4.4.2.2ADV_INT.1.2C

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

14.4.4.2.3ADV_INT.1.3C

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

14.4.4.3 Элементы действий оценщика

14.4.4.3.1 ADV_INT.1.1E

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

14.4.4.3.2 ADV_INT.1.2E

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

14.4.5 ADV_INT.2 Уменьшение сложности

Зависимости: ADV_IMP.1 Подмножество реализации ФБО

ADV_LLD.1 Описательный проект нижнего уровня

14.4.5.1 Замечания по применению

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

14.4.5.2 Элементы действий разработчика

14.4.5.2.1 ADV_INT.2.1D

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

14.4.5.2.2 ADV_INT.2.2D

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

14.4.5.2.3 ADV_INT.2.3D

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

14.4.5.2.4 ADV_INT2.4D

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

14.4.5.3 Элементы содержания и представления свидетельств

14.4.5.3.1 ADV_INT2.1C

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

14.4.5.3.2 ADV_INT2.2C

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

14.4.5.3.3 ADV_INT.2.3C

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

14.4 5.3.4 ADV_INT.2.4С

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

14.4.5.3.5 ADV_INT.2.5C

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

14.4.5.3.6 ADV_INT.2.6C

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

14.4.5.4 Элементы действий оценщика

14.4.5.4.1 ADV_INT.2.1E

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

14.4.5.4.2 ADV_INT.2.2E

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

14.4.6 ADV_INT.3 Минимизация сложности

Зависимости: ADV_IMP.2 Реализация ФБО

ADV_LLD.1 Описательный проект нижнего уровня

14.4.6.1 Замечания пo применению

Данный компонент содержит требование, - чтобы свойство монитора обращений "достаточно простой для анализа" полностью обеспечивалось. Если этот компонент сочетается с функциональными требованиями FPT_RVM.1 и FPT_SEP.3, то концепция монитора обращений будет полностью реализована.

14.4.6.2 Элементы действий разработчика

14.4.6.2.1 ADV_INT.3.1D

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

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

14.4.6.2.3 ADV_INT.3.3D

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

14.4.6.2.4 ADV_INT.3.4D

Разработчик должен проектировать и структурировать ФБО способом, минимизирующим сложность ФБО в целом.

14.4.6.2.5 ADV_INT.3.5D

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

14.4.6.2.6 ADV_INT.3.6D

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

14.4.6.3 Элементы содержания и представления свидетельств

14.4.6.3.1 ADV_INT.3.1С

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

14.4.6.3.2 ADV_INT.3.2C

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

14.4.6.3.3 ADV_INT.3.3C

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

14.4.6.3.4 ADV_INT.3.4C

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

14.4.6.3.5 ADV_INT.3.3C

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

14.4.6.3.6 ADV_INT.3.6C

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

14.4.6.3.7 ADV_INT.3.7C

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

14.4.6.4 Элементы действий оценщика

14.4.6.4.1 ADV_INT.3.1E

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

14.4.6.4.2 ADV_INT.3.2E

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

14.4.6.4.3 ADV_INT.3.3E

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

4.5.1 Цели

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

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

14.5.2 Ранжирование компонентов

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

14.5.3 Замечания по применению

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

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

Элементы ADV_LLD.*.6C содержат требование, чтобы проект нижнего уровня содержал описание того, как обеспечивается каждая из функций, осуществляющих ПБО. Смысл этого требования состоит в том, чтобы проект нижнего уровня содержал описание планируемой реализации каждого модуля, исходя из перспективы проекта.

Элементы ADV_LLD.*.2E этого семейства определяют требование вынесения оценщиком независимого заключения о том, что проект нижнего уровня является точным и полным отображением функциональных требований безопасности ОО. Этим обеспечивается прямое соответствие между функциональными требованиями безопасности ОО и проектом нижнего уровня в дополнение к попарным соответствиям, требуемым семейством ADV_RCR "Соответствие представлений". Ожидается, что оценщик использует свидетельство, включенное в ADV_RCR "Соответствие представлений" как основание для этого заключения, а требование полноты предполагает соотнесение с уровнем абстракции проекта нижнего уровня.

ADV_LLD.2.9C содержит требование полного представления интерфейсов модулей. Этим будет обеспечена необходимая детализация для поддержки как полного тестирования ОО (с использованием компонентов из семейства ATE_DPT "Глубина"), так и оценки уязвимостей.

Применительно к уровню формализации проекта нижнего уровня неформальный, полуформальный и формальный проекты рассматривают как иерархичные по сути. Так, элемент ADV_LLD.1.1C может быть удовлетворен использованием полуформального или формального проекта нижнего уровня, а элемент ADV_LLD.2.1C - формального проекта нижнего уровня.

14.5.4 ADV_LLD.1 Описательный проект нижнего уровня

Зависимости. ADV_HLD.2 Детализация вопросов безопасности в проекте верхнего уровня ADV_RCR.1 Неформальная демонстрация соответствия

14.5.4.1 Элементы действий разработчика

14.5.4.1.1 ADV_LLD.1.1D

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

14.5.4.2 Элементы содержания и представления свидетельств

14.5.4.2.1 ADV_LLD.1.1C

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

14.5.4.2.2 ADV_LLD.1.2C

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

14.5.4.2.3 ADV_LLD.1.3C

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

14.5.4.2.4 ADV_LLD.1.4C

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

14.5.4.2.5 ADV_LLD.1.5C

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

14.5.4.2.6 ADV_LLD.1.6C

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

14.5.4.2.7 ADV_LLD.1.7C

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

14.5.4.2.3 ADV_LLD.1.8C

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

14.5.4.2.9 ADV_LLD.1.9C

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

14.5.4.2.10 ADV_LLD.1.10С

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

14.5.4.3 Элементы действий оценщика

14.5.4.3.1 ADV_LLD.1.1E

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

14.5.4.3.2 ADV_LLD.1.2E

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

14.5.5 ADV_LLD.2 Полуформальный проект нижнего уровня

Зависимости: ADV_HLD.3 Полуформальный проект верхнего уровня

ADV_RCR.2 Полуформальная демонстрация соответствия

14.5.5.1 Элементы действий разработчика

14.5.5.1.1 ADV_LLD.2.1D

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

14.5.5.2 Элементы содержания и представления свидетельств

14.5.5.2.1 ADV_LLD.2.1C

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

14.5.5.2.2 ADV_LLD.2.2C

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

14.5.5.2.3 ADV_LLD _2.3C

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

14.5.5.2.4 ADV_LLD.2.4C

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

14.5.5.2.5 ADV_LLD.2.5C

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

14.5.5.2.6 ADV_LLD.2.6C

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

14.5.5.2.7 ADV_LLD.2.7C

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

14.5.5.2.8 ADV_LLD.2.8C

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

14.5.5.2.9 ADV_LLD.2.9C

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

14.5.5.2.10 ADV_LLD.2.10С

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

14.5.5.3 Элементы действий оценщика

14.5.5.3.1 ADV_LLD.2.1Е

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

14.5.5.3.2 ADV_LLD.2.2Е

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

14.5.6 ADV_LLD.3 Формальный проект нижнего уровня

Зависимости: ADV_HLD.5 Формальный проект верхнего уровня

ADV_RCR.3 Формальная демонстрация соответствия

14.5.6.1 Элементы действий разработчика

14.5.6.1.1 ADV_LLD.3.1D

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

14.5.6.2 Элементы содержания и представления свидетельств

14.5.6.2.1 ADV_LLD.3.1С

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

14.5.6.2.2 ADV_LLD.3.2С

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

14.5.6.2.3 ADV_LLD.3.3C

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

14.5.6.2.4 ADV_LLD.3.4C

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

14.5.6.2.5 ADV_LLD.3.5С

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

14.5.6.2.6 ADV_LLD.3.6C

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

14.5.6.2.7 ADV_LLD.3.7C

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

14.5.6.2.8 ADV_LLD.3.8C

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

14.5.6.2.9 ADV_LLD.3.9C

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

14.5.6.2.10 ADV_LLD.3.10C

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

14.5.6.3 Элементы действий оценщика

14.5.6.3.1 ADV_LLD.3.1E

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

14.5.6.3 .2 ADV_LLD.3.2E

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

14.6.1 Цели

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

14.6.2 Ранжирование компонентов

Компоненты в этом семействе ранжированы на основе требуемого уровня формализации соответствия между различными предоставлениями ФБО.

14.6.3 Замечания по применению

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

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

Элементы ADV_RCR.*.1С ссылаются на "все функциональные возможности, относящиеся к безопасности" в определении области уточнения для смежной пары представлений ФБО. При переходе от краткой спецификации ОО к функциональной спецификации этот элемент предусматривает только, чтобы функции безопасности ОО из краткой спецификации ОО были уточнены в функциональной спецификации, и не требует, чтобы функциональная спецификация содержала какие-либо подробности относительно мер доверия (которые представлены с краткой спецификации ОО). Когда представление реализации предоставляется только для некоторого подмножества ФБО (как ADV_IMP.1 "Подмножество реализации ФБО"), требуемые уточнения при переходе от проекта нижнего уровня к представлению реализации ограничены функциональными возможностями безопасности, которые имеются в представлении реализации. Во всех остальных случаях этот элемент предусматривает, чтобы все части более абстрактного представления ФБО были уточнены в менее абстрактном представлении ФБО.

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

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

Зависимости: нет зависимостей.

14.6.4.1 Элементы действий разработчика

14.6.4.1.1 ADV_RCR.1.1D

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

14.6.4.2 Элементы содержания и представления свидетельств

14.6.4.2.1 ADV_RCR.1.1С

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

14.6.4.3 Элементы действий оценщика

14.6.4.3.1 ADV_RCR.1.1E

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

14.6.5 ADV_RCR.2 Полуформальная демонстрация соответствия

Зависимости: нет зависимостей.

14.6.5.1 Элементы действий разработчика

14.6.5.1.1 ADV_RCR.2.1D

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

14.6.5.2 Элементы содержания и представления свидетельств

14.6.5.2.1 ADV_RCR.2.1С

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

14.6.5.2.2 ADV_RCR.2.2C

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

14.6.5.3 Элементы действий оценщика

14.6.5.3.1 ADV_RCR.2.1E

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

14.6.6 ADV_RCR.3 Формальная демонстрация соответствия

Зависимости: нет зависимостей.

14.6.6.1 Замечания по применению

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

14.6.6.2 Элементы действий разработчика

14.6.6.2.1 ADV_RCR.3.1D

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

14.6.6.2.2 ADV_RCR.3.2D

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

14.6.6.3 Элементы содержания и представления свидетельств

14.6.6.3.1 ADV_RCR.3.1С

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

14.6.6.3.2 ADV_RCR.3.2C

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

14.6.6.3.3 ADV_RCR.3.3C

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

14.6.6.4 Элементы действий оценщика

14.6.6.4.1 ADV_RCR.3.1E

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

14.6.6.4.2 ADV_RCR.3.2E

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

14.7.1 Цели

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

14.7.2 Ранжирование компонентов

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

14.7.3 Замечания по применению

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

В каждом из компонентов этого семейства присутствует требование описания в модели ПБО правил и характеристик применяемых политик ПБО и обеспечения адекватности модели ПБО соответствующим политикам ПБО, "Правила" и "характеристики" модели ПБО предназначены для обеспечения гибкости в выборе типа модели (например переход из одного состояния в другое, невмешательство), которая может быть разработана. Например, правила могут быть представлены как "свойства" (например отдельное свойство безопасности), а характеристики могут быть представлены такими определениями, как "начальное состояние", "безопасное состояние", "субъекты" и "объекты".

Применительно к уровню формализации модели ПБО и соответствия между моделью ПБО и функциональной спецификацией неформальный, полуформальный и формальный уровни рассматривают как иерархичные по сути. Так, ADV_SPM.1.1С может быть удовлетворен полуформальной или формальной моделью ПБО, a ADV_SPM.2.1C - также формальной моделью ПБО. Помимо этого, ADV_SPM.2.5C и ADV_SPM.3.5C могут быть удовлетворены формальным доказательством соответствия. И, наконец, при отсутствии каких-либо требований к уровню формализации демонстрация соответствия может быть неформальной, полуформальной или формальной.

14.7.4 ADV_SPM.1 Неформальная модель политики безопасности ОО

Зависимости: ADV_FSP.1 Неформальная функциональная спецификация

14.7.4.1 Элементы действий разработчика

14.7.4.1.1 ADV_SPM.1.1D

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

14.7.4.1.2 ADV_SPM.1.2D

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

14.7.4.2 Элементы содержания и представления свидетельств

14.7.4.2.1 ADV_SPM.1.1C

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

14.7.4.2.2 ADV_SPM.1.2C

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

14.7.4.2.3 ADV_SPM.1.3C

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

14.7.4.2.4 ADV_SPM.1.4C

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

14.7.4.3 Элементы действий оценщика.

14.7.4.3.1 ADV_SPM.1.1E

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

14.7.5 ADV_SPM.2 Полуформальная модель политики безопасности ОО Зависимости: ADV_FSP.1 Неформальная функциональная спецификация

14.7.5.1 Элементы действий разработчика

14.7.5.1.1 ADV_SPM.2.1D

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

14.7.5.1.2 ADV_SPM.2.2D

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

14.7.5.2 Элементы содержания и представления свидетельств

14.7.5.2.1 ADV_SPM.2.1C

Модель ПБО должна быть полуформальной.

14.7.5.2.2 ADV_SPM.2.2С

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

14.7.5.2.3 ADV_SPM.2.3C

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

14.7.5.2.4 ADV_SPM.2.4C

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

14.7.5.2.5 ADV_SPM.2.5С

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

14.7.5.3 Элементы действий оценщика

14.7.5.3.1 ADV_SPM.2.1E

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

14.7.6 ADV_SPM.3 Формальная модель политики безопасности ОО

Зависимости: ADV_FSP.1 Неформальная функциональная спецификация

14.7.6.1 Элементы действий разработчика

14.7.6.1.1 ADV_SPM.3.1D

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

14.7.6.1.2 ADV_SPM.3.2D

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

14.7.6.2 Элементы содержания и представления свидетельств

14.7.6.2.1 ADV_SPM.3.1C

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

14.7.6.2.2 ADV_SPM.3.2C

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

14.7.6.2.3 ADV_SPM.3.3C

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

14.7.6.2.4 ADV_SPM.3.4C

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

14.7.6.2.5 ADV_SPM.3.5C

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

14.7.6.2.6 ADV_SPM.3.6C

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

14.7.6.3 Элементы действий оценщика

14.7.6.3.1 ADV_SPM.3.1E

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