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

"РУКОВОДЯЩИЙ ДОКУМЕНТ. БЕЗОПАСНОСТЬ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ. КРИТЕРИИ ОЦЕНКИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ " (Утв. Приказом Гостехкомиссии РФ от 19.06.2002 N 187)

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

На рисунке 10.1 показаны семейства этого класса и иерархия компонентов в семействах.

Рисунок 10.1 - Декомпозиция класса "Разработка"

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

Рисунок 10.2 - Связи между представлениями ОО и требованиями

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

Требования для всех других соответствий, показанных на рисунке 10.2, определены в классе ADV. Семейство ADV_SPM определяет требования соответствия между ПБО и моделью ПБО, а также между моделью ПБО и функциональной спецификацией. Семейство ADV_RCR определяет требования соответствия между всеми имеющимися представлениями ФБО - от краткой спецификации ОО до представления реализации. Наконец, каждое семейство доверия, относящееся к конкретному представлению ФБО (т.е. ADV_FSP, ADV_HLD, ADV_LLD и ADV_IMP), определяет требования, устанавливающие связь между представлением ФБО и функциональными требованиями, сочетание которых помогает убедиться в том, что функциональные требования безопасности ОО были учтены. Анализ прослеживания будет выполняться всегда, начиная с самого высокого уровня представления ФБО, включая каждое из имеющихся представлений ФБО. ОК реализуют это требование прослеживания, используя зависимости от семейства ADV_RCR. Семейство ADV_INT не представлено на рисунке 10.2, поскольку оно связано с внутренней структурой ФБО и имеет лишь косвенное отношение к процессу уточнения представлений ФБО.

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

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

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

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

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

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

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

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

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

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

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

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

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

Цели

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

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

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

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

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

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

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

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

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

Зависимости

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

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

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

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

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

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

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

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

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

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

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

ADV_FSP.2 Полностью определенные внешние интерфейсы

Зависимости

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

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

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

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

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

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

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

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

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

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

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

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

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

Зависимости

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

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

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

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

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

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

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

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

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

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

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

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

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

Зависимости

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

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

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

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

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

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

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

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

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

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

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

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

Цели

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

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

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

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

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

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

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

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

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

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

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

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

Зависимости

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Зависимости

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Зависимости

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Зависимости

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Зависимости

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цели

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

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

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

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

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

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

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

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

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

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

Зависимости

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

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

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

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

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

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

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

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

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

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

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

ADV_IMP.2 Реализация ФБО

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

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

Зависимости

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Зависимости

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цели

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

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

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

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

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

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

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

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

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

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

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

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

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

Зависимости

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Зависимости

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Зависимости

ADV_IMP.2 Реализация ФБО

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ADV_INT.3.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 - формального проекта нижнего уровня.

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

Зависимости

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Зависимости

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Зависимости

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цели

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

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

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

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

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

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

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

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

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

Зависимости отсутствуют.

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

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

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

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

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

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

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

Зависимости отсутствуют.

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

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

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

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

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

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

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

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

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

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

Зависимости отсутствуют.

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

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

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

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

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

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

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

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

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

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

Цели

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

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

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

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

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

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

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

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

Зависимости

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

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

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

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

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

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

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

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

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

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

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

ADV_SPM.2 Полуформальная модель политики безопасности ОО

Зависимости

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

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

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

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

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

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

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

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

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

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

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

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

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

Зависимости

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

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

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

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

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

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

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

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

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

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

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

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

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