Приложение A (справочное). Разработка (ADV)

Приложение A
(справочное)

Разработка (ADV)

Данное приложение содержит вспомогательный материал для дальнейшего объяснения и предоставления дополнительных примеров по вопросам, поднимающимся в семействах класса ADV: "Разработка".

A.1. ADV_ARC: Вспомогательный материал по архитектуре безопасности

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

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

A.1.1. Свойства архитектуры безопасности

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

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

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

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

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

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

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

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

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

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

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

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

A.1.2.1. Разделение доменов

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

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

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

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

A.1.2.2. Собственная защита ФБО

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

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

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

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

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

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

A.1.2.3. Невозможность обхода ФБО

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

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

Ко второй области, касающейся невозможности обхода, относятся те интерфейсы, чьи взаимодействия не связаны с осуществлением ФТБ. В зависимости от заявленных компонентов ADV_FSP и ADV_TDS часть информации об этих интерфейсах может содержаться или не содержаться в функциональной спецификации и проектной документации ОО. Информации, представленной для таких интерфейсов (или для группы интерфейсов), следует быть достаточной для того, чтобы читатель мог сделать заключение (на уровне детализации, соизмеримом с остальными свидетельствами, предоставленными в классе ADV: "Разработка"), что эти осуществляющие ФТБ механизмы нельзя обойти.

Свойство невозможности обхода ФБО распространяется на все функциональные возможности безопасности в равной степени. Это значит, что в описании проекта следует охватывать объекты, которые защищаются по ФТБ (например, компоненты FDP_*) и функциональные возможности (например, аудит), предоставляемые ФБО. В описании следует также идентифицировать интерфейсы, которые связаны с функциональными возможностями безопасности; для этого может быть использована информация из функциональной спецификации. В этом описании следует также рассмотреть любые структуры проекта, такие как механизмы управления объектами, и способ их использования. Например, если процедуры должны использовать стандартный макрос для создания записи аудита, эта установка является частью проекта, который способствует невозможности обхода механизма аудита. Важно отметить, что невозможность обхода в этом контексте не является попыткой ответить на вопрос "может ли часть реализации ФБО, если она вредоносна, обойти функциональные возможности безопасности", а скорее рассматривается для документирования того, как реализация не обходит функциональные возможности безопасности.

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

A.2. ADV_FSP: Дополнительный материал по ИФБО

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

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

A.2.1. Определение ИФБО

Чтобы идентифицировать интерфейсы ФБО, прежде всего должны быть идентифицированы части ОО, составляющие ФБО. Идентификация на самом деле является частью анализа семейства "Проект ОО" (ADV_TDS), но также осуществляется разработчиком и неявно (через идентификацию и описание ИФБО) в случаях, когда семейство "Проект ОО" (ADV_TDS) не включается в пакет доверия. В этом анализе часть ОО должна считаться входящей в ФБО, если это требуется для удовлетворения ФТБ из ЗБ (в целом или частично). Это включает, например, все в ОО, что способствует инициализации во время выполнения ФБО, к примеру, программное обеспечение, которое запускается до момента, когда ФБО способны обеспечить собственную защиту, так как выполнение ФТБ еще не началось (например, в процессе запуска). Также включаются в ФБО все части ОО, которые вносят вклад в архитектурные принципы собственной защиты ФБО, разделения доменов и невозможности обхода (см. семейство ADV_ARC "Архитектура безопасности").

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

A.2.1.1. Электрические интерфейсы

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

A.2.1.2. Стек сетевых протоколов

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

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

Однако если бы ОО был межсетевым экраном, который защищает внутреннюю сеть от сети Интернет, потенциальный нарушитель не имел бы возможности непосредственных манипуляций с напряжениями, которые входят в ОО; любые чрезмерные напряжения просто не будут переданы через межсетевой уровень. Т.е. нарушитель будет иметь доступ только к протоколам межсетевого уровня или выше. Границы ФБО существуют на каждом уровне стека протоколов. Таким образом, в функциональной спецификации следовало бы обращаться только к протоколам межсетевого уровня или выше его: в ней следовало бы описать каждый из различных уровней взаимодействия, на которых межсетевой экран уязвим в плане того, что составляет правильно сформированные исходные данные на линии; это может привести к тому, что могут существовать одновременно и правильно и неправильно сформированные исходные данные. Например, в описании протокола на межсетевом уровне описывается, что представляет собой правильно сформированный IP-пакет и что происходит при получении правильно сформированного и неправильно сформированного пакетов. А в описании на уровне протокола TCP (транспортный уровень) будет описываться успешное соединение по протоколу TCP, а также что происходит как в случае успешного установления соединения, так и в случае, когда соединение не может быть установлено или было случайно прервано. Если, как предполагается, задачей межсетевого экрана является фильтрация команд на прикладном уровне (например, по протоколу FTP или Telnet), описание на прикладном уровне будет описывать команды прикладного уровня, распознаваемые и фильтруемые межсетевым экраном, а также результаты обнаружения неизвестных команд.

Описания этих уровней, скорее всего, будут содержать ссылки на используемые изданные стандарты связи (Telnet, FTP, TCP и т.д.) с указанием того, какие определяемые пользователем опции были выбраны.

A.2.1.3. Адаптеры интерфейса

"Рис. A.1. Адаптеры интерфейса"

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

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

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

A.2.1.4. Недоступные интерфейсы

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

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

b) Если с целью безопасности для среды функционирования программного межсетевого экрана (приложения) указывается, что "ОС и аппаратные средства предоставят домен безопасности для приложения, свободный от воздействия других программ", то интерфейсы, через которые межсетевой экран может быть доступен для других приложений ОС (например, удаление или изменение исполняемого файла межсетевого экрана, чтение или запись напрямую в области памяти межсетевого экрана), не будут доступны, поскольку ОС/аппаратная часть среды функционирования не позволяют получить доступ к интерфейсу.

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

Во всех этих примерах недоступные интерфейсы не будут являться ИФБО.

A.2.2. Пример: сложная СУБД

На рисунке A.2 представлен сложный ОО: система управления базами данных, полагающаяся на аппаратные и программные средства, находящиеся за пределами границы ОО (в дальнейшем - среда ИТ). Для упрощения в этом примере ОО идентичен ФБО. Закрашенные прямоугольники представляют ФБО, в то время как незакрашенные представляют ИТ-сущности в среде функционирования. ФБО состоит из процессора базы данных и управления ГИП (на рисунке представлен прямоугольником "БД") и модуля ядра, который функционирует как часть ОС, выполняющая некоторые функциональные возможности безопасности (на рисунке представлен прямоугольником "ПЛГ"). Модуль ядра ФБО имеет точки входа, определенные в спецификации ОС, которые определяют, что ОС будет вызывать некоторые функциональные возможности (это может быть драйвер устройства или модуль аутентификации и т.д.). Суть в том, что подключаемый модуль ядра предоставляет сервисы безопасности, специфицированные функциональными требованиями из ЗБ.

"Рис. A.2. Взаимодействия в СУБД"

Среда ИТ состоит из самой операционной системы (прямоугольник "ОС"), а также внешнего сервера (на рисунке представлен прямоугольником "СРВ"). Этот внешний сервер, как и ОС, предоставляет сервисы, от которых зависит ФБО, и, следовательно, должен находиться в среде ИТ. Интерфейсы ИФБО обозначены на рисунке как Ax, прочие интерфейсы, которые были бы документированы в классе ACO "Композиция", - как Bx. Ниже приводится рассмотрение каждой из этих групп интерфейсов.

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

Группа интерфейсов A2 представляет ИФБО, которые вызываются ОС с целью получения функциональных возможностей, предоставляемых подключаемым модулем. Это контрастирует с группой интерфейсов B3, которая представляет вызовы, посылаемые подключаемым модулем с целью получения сервисов от среды ИТ.

Группа интерфейсов A3 представляет ИФБО, которые проходят через среду ИТ. В этом случае СУБД взаимодействует по сети с помощью собственного протокола прикладного уровня. В то время как среда ИТ отвечает за обеспечение поддержки различных протоколов (например, Ethernet, IP, TCP), протокол прикладного уровня, который используется для получения сервисов СУБД, является ИФБО и должен быть задокументирован как таковой. Пунктирной линией на рисунке указываются возвращаемые значения/сервисы ФБО через сетевое подключение.

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

A.2.3. Пример функциональной спецификации

Рассмотрим как пример межсетевой экран, который используется между внутренней сетью и внешней сетью. Он верифицирует адрес источника полученных данных (с целью удостовериться, что внешние данные не пытаются замаскироваться под внутренние данные); в случае обнаружения любых таких попыток он сохраняет сведения об этом в журнале аудита. Администратор связывается с межсетевым экраном путем установления Telnet-соединения из внутренней сети. Действия администратора включают в себя аутентификацию, изменение паролей, исследование журнала аудита, а также настройку или смену адресов внутренних и внешних сетей.

В приведенном примере межсетевого экрана представлены следующие интерфейсы внутренней сети:

а) IP-дейтаграммы (пакеты данных IP и связанная с ними адресная информация);

б) команды администратора

и следующие интерфейсы для внешней сети:

а) IP-дейтаграммы.

Описание интерфейсов: IP-дейтаграммы

Дейтаграммы находятся в формате, специфицированном в RFC 791.

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

- Метод использования - поставляются протоколом более низкого уровня (например канального).

- Параметры - следующие поля заголовка IP-дейтаграммы: адрес отправителя, адрес получателя, метка нефрагментирования.

- Описание параметров - [В соответствии с определением из RFC 791, подразделом 3.1 ("Формат интернет-заголовка")].

- Действия - передача дейтаграмм, которые не являются подмененными; фрагментирование больших дейтаграмм в случае необходимости; повторная сборка фрагментов в дейтаграммы.

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

Описание интерфейсов: команды администратора

Команды администратора предоставляют администратору средства взаимодействия с межсетевым экраном. Эти команды и реакции на запросы происходят поверх Telnet-соединения (RFC 854), установленного с любого узла внутренней сети. Доступные команды:

Passwd

- Назначение - устанавливает пароль администратора.

- Метод использования - Passwd <password>.

- Параметры - пароль.

- Описание параметров - значение нового пароля.

- Действия - изменение пароля в соответствии с новым предложенным значением. Ограничения отсутствуют.

- Сообщения об ошибках - нет.

Readaudit

- Назначение - предоставляет администратору журнал аудита.

- Метод использования - Readaudit.

- Параметры - отсутствуют.

- Описание параметров - отсутствует.

- Действия - предоставляет текст журнала аудита.

- Сообщения об ошибках - отсутствуют.

Setintaddr

- Назначение - устанавливает адрес для внутреннего адреса.

- Метод использования - Setintaddr <address>.

- Параметры - адрес.

- Описание параметров - первые три поля IP-адреса (как определено в RFC 791). Например: 123.123.123.

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

- Сообщения об ошибках - "адрес занят": указывает, что идентифицированная внутренняя сеть совпадает с внешней сетью.

Setextaddr

- Назначение - устанавливает адрес для внешнего адреса.

- Метод использования - Setextaddr <address>.

- Параметры - адрес.

- Описание параметров - первые три поля IP-адреса (как определено в RFC 791). Например: 123.123.123.

- Действия - изменение значения внутренней переменной, определяющей внешнюю сеть.

- Сообщения об ошибках - "адрес занят": указывает, что идентифицированная внутренняя сеть совпадает с внешней сетью.

A.3. ADV_INT: Дополнительный материал по внутренней структуре ФБО

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

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

A.3.1. Структура процедурного программного обеспечения

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

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

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

A.3.1.1. Связность

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

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

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

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

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

e) логическая (или процедурная) связность - модуль с логической связностью производит схожие действия над разными структурами данных. Модуль демонстрирует логическую связность, если его функциональные возможности выполняют взаимосвязанные, но различные операции над разными входными данными;

f) случайная связность - модуль со случайной связностью выполняет не связанные или слабо связанные между собой действия.

A.3.1.2. Связанность

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

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

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

2) метка: два модуля являются связанными по метке, если они взаимодействуют посредством параметров запроса, включающих несколько полей или имеющих значимые внутренние структуры;

3) управление: два модуля являются связанными по управлению, если один передает информацию, которая предназначена для влияния на внутреннюю логическую структуру другого;

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

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

2) Количество модулей, которые ссылаются на глобальные переменные: несмотря на то что, как правило, количество модулей, которые ссылаются на глобальную переменную, неограниченно, в случаях, когда множество модулей представляют такие ссылки, следует проводить проверки на предмет их обоснованности и необходимости;

c) по содержимому: два модуля являются связанными по содержимому, если можно дать прямую ссылку от одного модуля на внутренние компоненты другого (например, изменить код или сослаться на внутреннюю структуру другого модуля). В результате часть или же все содержимое одного модуля эффективно включено в другой. Связанность по содержимому может рассматриваться как использование недекларируемых интерфейсов модулей в отличие от сцепления по запросу, где используются только декларированные интерфейсы модулей.

A.3.2. Сложность процедурного программного обеспечения

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

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

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

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

A.4. ADV_TDS: Подсистемы и модули

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

A.4.1. Подсистемы

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

"Рис. A.3. Подсистемы и модули"

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

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

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

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

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

A.4.2. Модули

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

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

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

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

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

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

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

Интерфейсы, представленные модулем, представляют собой интерфейсы, используемые другими модулями для вызова предусмотренных функциональных возможностей. Интерфейсы включают в себя как явные интерфейсы (например, последовательность запросов, вызываемую другими модулями), так и неявные интерфейсы (например, глобальные данные, на которые воздействует модуль). Интерфейсы описываются в терминах того, каким образом они вызываются, а также любых возвращаемых значений. Это описание включает в себя список параметров и описания этих параметров. Если параметры будут включать множество значений (например, параметр "флажок"), то должен быть указан полный набор значений параметра, который может оказать влияние на модуль. Кроме того, параметры, характеризующие структуры данных, описываются таким образом, чтобы каждое поле структур данных было идентифицировано и описано. Глобальные данные следует описать вне зависимости от того, производит ли модуль их чтение и/или запись.

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

С другой стороны, интерфейсы, используемые модулем, должны быть определены так, чтобы можно было идентифицировать, какой модуль вызывается посредством описанного модуля. Из описания проекта должно быть понятно, в чем алгоритмическая причина вызова модуля. Например, для случая, когда есть описанный модуль A и он использует процедуру сортировки пузырьковым методом модуля B, алгоритмического описания "Модуль A вызывает интерфейс double_bubble () модуля B для выполнения сортировки пузырьковым методом" будет недостаточно. Адекватное алгоритмическое описание должно быть следующим: "Модуль А вызывает процедуру double_bubble со списком записей контроля доступа; double_bubble () в ответ на запрос возвращает вначале отобранные по имени пользователя записи, затем - по полю access_allowed согласно следующим правилам...". Описание модуля в проекте должно быть достаточно детализированным для того, чтобы было понятно, какие результаты модуль A ожидает от интерфейса сортировки пузырьковым методом. Следует отметить, что согласно одному из способов представления эти вызываемые интерфейсы отображаются посредством дерева вызовов, а затем алгоритмическое описание может быть включено в алгоритмическое описание вызываемого модуля.

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

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

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

A.4.3. Подход к ранжированию

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

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

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

Компонент семейства	Подсистема ФБО			Модуль ФБО
	Осуществляющая ФТБ	Поддерживающая ФТБ	Не влияющая на ФТБ	Осуществляющий ФТБ	Поддерживающий ФТБ	Не влияющий на ФТБ
ADV_TDS.1 Базовый проект (неформальное представление)	Структура, аннотация осуществляющего ФТБ режима функционирования, взаимодействия	Поддержка проекта*	Поддержка проекта
ADV_TDS.2 Архитектурный проект (неформальное представление)	Структура, детальное описание осуществляющего ФТБ режима функционирования, аннотация прочих режимов, взаимодействия	Структура, аннотация прочих режимов, взаимодействия	Поддержка проекта, взаимодействия
ADV_TDS.3 Базовый модульный проект (неформальное представление)	Описание, взаимодействия	Описание, взаимодействия	Описание, взаимодействия	Назначение, интерфейсы ФТБ**	Взаимодействие, назначение	Взаимодействие, назначение
ADV_TDS.4 Полуформальный модульный проект (полуформальное представление)	Описание, взаимодействия	Описание, взаимодействия	Описание, взаимодействия	Назначение интерфейсы ФТБ	Назначение, интерфейсы ФТБ	Взаимодействие, назначение
ADV_TDS.5 Полный полуформальный модульный проект (полуформальное представление)	Описание, взаимодействия	Описание, взаимодействия	Описание, взаимодействия	Назначение, все интерфейсы***	Назначение, все интерфейсы	Назначение, все интерфейсы
ADV_TDS.6 Полный полуформальный модульный проект с формальным высокоуровневым представлением (полуформальное представление; дополнительное формальное представление)	Описание, взаимодействия	Описание, взаимодействия	Описание, взаимодействия	Назначение, все интерфейсы	Назначение, все интерфейсы	Назначение, все интерфейсы
_____________________________ * Поддержка проекта означает, что нужна только достаточная документация для поддержания классификации подсистемы/модуля. ** Интерфейсы ФТБ - означает, что описание модуля содержит для каждого осуществляющего выполнение ФТБ модуля возвращаемые значения и вызываемые интерфейсы других модулей. *** Все интерфейсы - означает, что описание модуля содержит для каждого интерфейса возвращаемые значения и вызываемые интерфейсы других модулей.

A.5. Дополнительный материал по формальным методам

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

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

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

- Семантика, синтаксис и правила построения выводов формальной системы определены или определения даются в ссылках.

- Каждая формальная система сопровождается пояснительным текстом, который содержит определенную семантику, а именно:

1) в пояснительном тексте приводится определение терминов, сокращений и аббревиатур, которые используются в ином контексте, нежели общепринятый;

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

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

4) в условных обозначениях предоставляются правила определения значения синтаксически верных конструкций языка.

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

- В каждой формальной системе устанавливаются правила доказательств, которые

5) поддерживают логические обоснования хорошо известных математических понятий,

6) помогают предотвратить возникновение противоречий.

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

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

Примеры формальных систем:

Язык спецификаций Z весьма выразителен и поддерживает множество различных методов и стилей формальной спецификации. Z применяется преимущественно для спецификаций, ориентированных на модели с использованием схем формально специфицированных операций. Для получения дополнительной информации см. ссылку http://vl.zuser.org/.

ALC2 является формальной системой с открытым исходным кодом, состоящей из языка спецификаций, основанного на языке обработки списков Лисп (LISP), и инструмента доказательства теорем. Более подробная информация на сайте: http://www.cs.utexas.edu/users/moore/acl2.

Isabelle - популярная среда доказательства общих теорем, которая позволяет выражать математические формулы на формальном языке и предоставляет средства для доказательства этих формул в рамках логического вычисления (см., например, http://www.cl.cam.ac.uk/Research/HVG/lsabelle/ для получения дополнительной информации).

Метод B является формальной системой, основанной на пропозициональном исчислении (исчислении высказываний), вычислении предикатов первого порядка с правилами построения выводов и установленной теоретической базой (см., например, http://vl.fmnet.info/b/ для получения дополнительной информации).