ASE_TSS.2.2E

ASE_TSS.2.1E

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

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

ASE_TSS.2.3C

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

ASE_TSS.2.2C

ASE_TSS.2.1C

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

ASE_TSS.2.1D

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

ASE_TSS.2 Краткая спецификация ОО с кратким изложением архитектурного проекта

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

ASE_TSS.1.2E

ASE_TSS.1.1E

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

Зависимости: ASE_INT.1 Введение в ЗБ

ASE_REQ.1 Изложенные требования безопасности

ADV_ARC.1 Описание архитектуры безопасности

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

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

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

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

8 Класс ADV: Разработка

Требования класса «Разработка» предоставляют информацию об ОО. Сведения, полученные с помощью этой информации, используются в качестве основы для проведения анализа уязвимостей и тестирования ОО в соответствии с описанием, представленном в классах требований доверия AVA «Анализ уязвимостей» и ATE «Тестирование».

Класс требований доверия «Разработка» включает 6 семейств требований доверия для структурирования и представления ФБО на различных уровнях с разной степенью детализации. Эти семейства включают:

· требования к описанию (на различных уровнях детализации) проекта и реализации ФТБ (ADV_FSP «Функциональная спецификация», ADV_TDS «Проект ОО», ADV_IMP «Представление реализации»)

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

· требования к модели политики безопасности и соответствию отображения между моделью политики безопасности и функциональной спецификацией (ADV_SPM «Моделирование политики безопасности»)

· требования к внутренней структуре ФБО, которые охватывают такие аспекты как модульность, расслоение и минимизация сложности (ADV_INT «Внутреннее построение ФБО»)

При документировании функциональных возможностей по безопасности ОО необходимо продемонстрировать два свойства. Первое свойство заключается в правильности выполнения определенной функциональной возможности, т.е. в том, что она выполняется в соответствии с заданными требованиями. Второе условие, которое вероятно сложнее продемонстрировать, заключается в том, что ОО не может быть использован таким образом, что определенная функциональная возможность может быть повреждена или ее можно обойти. Эти два свойства требуют несколько отличные подходы в проведении анализа и поэтому семейства в классе требований доверия ADV «Разработка» структурированы таким образом, чтобы предусмотреть эти разные подходы. Семейства требований доверия «Функциональная спецификация» (ADV_FSP), «Проект ОО» (ADV_TDS), «Представление реализации» (ADV_IMP), «Моделирование политики безопасности» (ADV_SPM) относятся к первому свойству: спецификации функциональных возможностей по безопасности. Семейства требований доверия «Архитектура безопасности» (ADV_ARC) и «Внутреннее устройство ФБО» (ADV_INT) относятся ко второму свойству: спецификации проекта ОО, показывающему, что определенная функциональная возможность не может быть повреждена или ее можно обойти. Следует отметить, что оба эти свойства необходимо реализовывать: чем больше уверенности в том, что свойства выполняются, тем большее доверие заслуживает ОО. Компоненты в этих семействах построены таким образом, чтобы большее доверие достигалось с помощью компонентов, находящихся выше по иерархии.

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

На рисунке 10 показаны взаимосвязи между различными представлениями ФБО в требованиях доверия класса ADV «Разработка», а также их взаимосвязи с другими классами. Как показано на рисунке классы APE «Оценка ПЗ» и ASE «Оценка ЗБ» определяют требования для соответствия между ФТБ и целями безопасности для ОО. Класс требований доверия ASE «Оценка ЗБ» определяет также требования для соответствия, как между целями безопасности, так и ФТБ и требования к краткой спецификации ОО, в которой объясняется как ОО выполняет свои ФТБ. Действия оценщика в элементе ALC_CMC.5.2E включают проверку того, что ФБО, которые тестируются в рамках требований доверия классов ATE «Тестирование» и AVA «Оценка уязвимостей», являются фактически теми, которые описаны всеми уровнями декомпозиции в классе требований доверия ADV «Разработка».

Требования для всех других соответствий, показанных на рисунке 10, определяются в классе ADV «Разработка». Семейство «Моделирование политики безопасности» (ADV_SPM) определяет требования для формального моделирования выбранных ФТБ и обеспечивает соответствие между функциональной спецификацией и формальной моделью. Каждое семейство требований доверия, относящееся к представлению ФБО (т.е. «Функциональная спецификация» (ADV_FSP), «Проект ОО» (ADV_TDS) и «Представление реализации» (ADV_IMP)), определяет требования по соотнесению представления ФБО с ФТБ. Все декомпозиции должны точно отображать все другие декомпозиции (т.е. быть взаимосвязанными); разработчик предоставляет соответствующие прослеживания в последних элементах компонентов с окончанием «.C». Доверие относительно этого фактора получается в процессе проведения анализа каждого из уровней декомпозиции с помощью ссылки на другие уровни декомпозиции (рекурсивным образом), когда анализ отдельного уровня декомпозиции уже выполнен; оценщик проверяет такое соответствие как часть второго элемента действий оценщика с окончанием «E». Сведения, получаемые с помощью этих уровней декомпозиции, закладываются в основу проведения функционального тестирования и тестирования на проникновение.

Семейство ADV_INT «Внутренне устройство ФБО» не представлено на этом рисунке, поскольку оно относится к внутренней структуре ФБО и только косвенно связано с процессом уточнения представлений ФБО. Аналогично, семейство ADV_ARC «Архитектура безопасности» также не представлено на рисунке, поскольку оно относится скорее к правильности архитектуры, а не к представлению ФБО. Оба семейства ADV_INT «Внутренне устройство ФБО» и ADV_ARC «Архитектура безопасности» относятся к анализу свойства того, что ОО не может быть создан таким образом, что его функциональные возможности можно обойти или разрушить.

Рисунок 10 – Взаимосвязи семейств класса ADV «Разработка» между собой и другими семействами

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

При разработке компонентов семейств класса требований доверия ADV «Разработка» были использованы несколько важных принципов. Эти принципы, которые здесь кратко рассматриваются, объясняются более подробно в замечаниях по применению для семейств.

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

В общем случае ФБО являются достаточно сложными, хотя это не всегда верно для всех ОО, и некоторые части ФБО требуют проведения более тщательной проверки по сравнению с другими частями ФБО. Определение этих частей, к сожалению, является отчасти субъективным, поэтому терминология и компоненты требований доверия определены таким образом, что при увеличении уровня доверия ответственность за определение того, какие части ФБО необходимо подробно исследовать переходит от разработчика к оценщику. В целях изложения такого подхода вводится следующая терминология. Следует отметить, что в семействах класса требований доверия эта терминология используется для изложения частей ОО, относящихся к ФТБ (т.е. элементы требований доверия и элементы действий представляются в семействах «Функциональная спецификация» (ADV_FSP), «Проект ОО» (ADV_TDS) и «Представление реализации» (ADV_IMP)). Хотя общий подход (что некоторые части ОО заслуживают большего внимания, чем остальные) применяется и к другим семействам, критерии излагается по разному, чтобы получить требуемое доверие.

Все части ФБО относятся к безопасности, при этом подразумевается, что они должны сохранять безопасность ОО в соответствии с ФТБ и требованиями по разделению доменов и невозможности обхода ФБО. Одним из аспектов, важным с точки зрения безопасности, является то, насколько точно некоторая часть ФБО выполняет некоторое требование безопасности. Поскольку разные части ОО выполняют различные роли (или вообще не имеют явной роли) в выполнении требований безопасности, это приводит к важности совокупности взаимосвязанных ФТБ: на одном конце этой совокупности размещаются части ОО, которые называются обеспечивающие выполнение ФТБ. Эти части выполняют непосредственную роль в реализации каких-либо ФТБ в ОО. Такие ФТБ относятся к любой функциональной возможности, предусмотренной одним из ФТБ, включенным в ЗБ. Следует отметить, что выражение играет роль в для функциональных возможностей, обеспечивающих выполнение ФТБ, невозможно выразить количественно. Например, при реализации механизма Дискреционного управления доступом очень узким представлением части, обеспечивающей выполнение ФТБ, может быть несколько строк кода, которые фактически выполняют проверку атрибутов безопасности субъекта доступа по отношению к атрибутам безопасности объекта. Более широкое представление может включать объект программного обеспечения (например, функция на языке программирования Си), содержащий несколько строк кода. Более широкое представление будет включать еще фрагменты кода, которые вызывают Си-функцию, поскольку они отвечают за принятие решения о доступе на основании значения, возвращенного функцией проверки атрибутов. Еще более широкое представление будет включать любой фрагмент кода в дереве вызовов (или его эквивалентом в зависимости от используемого языка программирования) Си-функции (например, функции сортировки, которая сортирует записи списка управления доступом с помощью реализации алгоритма сортировки по первому совпадению First-Match). Иногда компонент не столько осуществляет политику безопасности, а скорее играет вспомогательную роль; такие компоненты называются способствующие выполнение ФТБ.

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

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

Отличия в проведения анализа реализации ФТБ (обеспечивающих выполнение ФТБ, способствующих выполнение ФТБ функциональных возможностей) и реализации каких-то основных свойств безопасности ОО, которые включают инициализацию, самозащиту и невозможность обхода ФБО, состоит в том, что функциональные возможности, относящиеся к ФТБ, более или менее явно видимы и их относительно легко тестировать, в то время как ранее упомянутые свойства требуют проведения анализа различной глубины на намного большей совокупности функциональных возможностей. Более того, глубина анализа для таких свойств будет меняться в зависимости от проекта ОО. Семейства класса ADV «Разработка» построены таким образом, чтобы учесть это с помощью отдельного семейства (ADV_ARC «Архитектура безопасности»), в котором рассматриваются требования по инициализации, самозащите и невозможности обхода ФБО, в то время как в других семействах рассматривается анализ функциональных возможностей, способствующих выполнению ФТБ.

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

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

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

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

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

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

Рисунок 11 – Декомпозиция класса ADV «Разработка»