13.6 Вид деятельности «Разработка»

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

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

Требования ИСО/МЭК 15408 к проектной документации ранжированы по уровню формализации. В ИСО/МЭК 15408 рассмотрены следующие иерархические степени формализации документа: неформальный, полуформальный, формальный. Неформальный документ — это документ, который составлен на естественном языке. Методология не предписывает использовать какой-либо конкретный язык; этот вопрос остается за системой оценки. Ниже дифференцировано содержание различных неформальных документов.

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

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

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

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

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

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

13.6.2 Оценка функциональной спецификации (ADV_FSP.2)

13.6.2.1 Цели

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

13.6.2.2 Исходные данные

Свидетельствами оценки для этого подвида деятельности являются:

a) ЗБ;

b) функциональная спецификация;

c) руководство пользователя;

d) руководство администратора.

13.6.2.3 Действие ADV_FSP.2.1E

13.6.2.3.1 Шаг оценивания 4:ADV_FSP.2-1

ИСО/МЭК 15408-3 ADV_FSP.2.1C: Функциональная спецификация должна содержать неформальное описание ФБО и их внешних интерфейсов.

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

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

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

13.6.2.3.2 Шаг оценивания 4:ADV_FSP.2-2

ИСО/МЭК 15408-3 ADV_FSP.2.2C: Функциональная спецификация должна быть внутренне непротиворечивой.

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

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

Руководство по анализу непротиворечивости см. в А.3 «Анализ непротиворечивости» (приложение А).

13.6.2.3.3 Шаг оценивания 4:ADV_FSP.2-3

ИСО/МЭК 15408-3 ADV_FSP.2.3C: Функциональная спецификация должна содержать описание назначения и методов использования всех внешних интерфейсов ФБО, обеспечивая полную детализацию всех результатов, нештатных ситуаций и сообщений об ошибках.

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

Термин «внешний» относится к тому интерфейсу, который является видимым для пользователя. Внешние интерфейсы ОО — это либо непосредственно интерфейсы ФБО, либо интерфейсы не-ФБО-частей ОО. Однако и через не-ФБО-интерфейсы возможен доступ к ФБО. Эти внешние интерфейсы, которые прямо или косвенно обращаются к ФБО, совместно составляют интерфейс функций безопасности ОО (ИФБО). На рисунке 12 показан ОО, включающий в себя ФБО-части (заштрихованы) и не-ФБО-части (не заштрихованы). Данный ОО имеет три внешних интерфейса: интерфейс c — непосредственный интерфейс ФБО; интерфейс b — косвенный интерфейс ФБО; интерфейс a — интерфейс не-ФБО-частей ОО. Таким образом, интерфейсы b и c составляют ИФБО.

Рисунок 12- Интерфейсы ФБО

Следует отметить, что все функции безопасности, отраженные в функциональных требованиях ИСО/МЭК 15408-2 (или в компонентах, дополнительных по отношению к ИСО/МЭК 15408-2), будут иметь своего рода внешне видимые проявления. И хотя не обязательно все из них являются интерфейсами, через которые могут быть протестированы функции безопасности, все они до некоторой степени являются внешне видимыми, а поэтому должны быть включены в функциональную спецификацию.

Руководство по определению границ ОО см. в А.6 «Границы ОО» (приложение А).

13.6.2.3.4 Шаг оценивания 4:ADV_FSP.2-4

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

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

С другой стороны, если по отношению к ОО имеются угрозы, связанные с действиями злонамеренных пользователей или обходом (т.е. в его ЗБ включены компоненты требований из семейств FPT_PHP «Физическая защита ФБО», FPT_RVM «Посредничество при обращениях» и FPT_SEP «Разделение домена», то в функциональной спецификации должны быть описаны все внешние интерфейсы, но только в объеме, достаточном для понимания их влияния на ФБО: интерфейсы функций безопасности (т.е. интерфейсы b и c на рисунке 12) должны быть описаны полностью, в то время как другие интерфейсы описывают только в объеме, достаточном для понимания того, что ФБО являются недоступными через рассматриваемый интерфейс (т.е. что интерфейс относится к типу a, а не типу b на рисунке 12). Включение компонентов требований из семейств FPT_PHP, FPT_RVM и FPT_SEP предполагает возможность некоторого влияния всех интерфейсов на ФБО. Поскольку каждый внешний интерфейс — это потенциальный интерфейс ФБО, функциональная спецификация должна содержать описание каждого интерфейса с детализацией, достаточной для того, чтобы оценщик мог сделать заключение, является ли интерфейс значимым с точки зрения безопасности.

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

13.6.2.3.5 Шаг оценивания 4:ADV_FSP.2-5

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

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

a) все ли относящиеся к безопасности, вводимые пользователем параметры (или характеристики этих параметров) определены. Для полноты необходимо, чтобы были определены параметры, которыми пользователь не управляет непосредственно, если они могут быть использованы администраторами;

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

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

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

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

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

13.6.2.3.6 Шаг оценивания 4:ADV_FSP.2-6

ИСО/МЭК 15408-3 ADV_FSP.2.4C: Функциональная спецификация должна полностью представить ФБО.

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

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

13.6.2.3.7 Шаг оценивания 4:ADV_FSP.2-7

ИСО/МЭК 15408-3 ADV_FSP.2.5C: Функциональная спецификация должна включать в себя обоснование, что ФБО полностью представлены.

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

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

13.6.2.4 Действие ADV_FSP.2.2E

13.6.2.4.1 Шаг оценивания 4:ADV_FSP.1-8

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

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

13.6.2.4.2 Шаг оценивания 4:ADV_FSP.2-9

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

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

Для каждого интерфейса, описанного в функциональной спецификации, который влияет на управляемый ресурс, оценщик делает заключение, возвращает ли интерфейс в соответствии с одним из требований безопасности некоторый код ошибки, указывающий на возможный сбой; если код ошибки не возвращается, то оценщик делает заключение, необходим ли в этом случае возврат кода ошибки. Например, операционная система может представлять интерфейс для ОТКРЫТИЯ управляемого объекта. Описание этого интерфейса может включать в себя код ошибки, который указывает на то, что доступ к объекту не был санкционирован. Если такого кода ошибки не существует, то оценщику следует подтвердить, что это приемлемо (потому что, возможно, посредничество в доступе выполняется при ЧТЕНИИ и ЗАПИСИ, а не при ОТКРЫТИИ).

13.6.3 Оценка проекта верхнего уровня (ADV_HLD.2)

13.6.3.1 Цели

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

13.6.3.2 Исходные данные

Свидетельствами оценки для этого подвида деятельности являются:

a) ЗБ;

b) функциональная спецификация;

c) проект верхнего уровня.

13.6.3.3 Действие ADV_HLD.2.1E

13.6.3.3.1 Шаг оценивания 4:ADV_HLD.2-1

ИСО/МЭК 15408-3 ADV_HLD.2.1C: Представление проекта верхнего уровня должно быть неформальным.

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

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

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

13.6.3.3.2 Шаг оценивания 4:ADV_HLD.2-2

ИСО/МЭК 15408-3 ADV_HLD.2.2C: Проект верхнего уровня должен быть внутренне непротиворечивым.

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

Руководство по анализу непротиворечивости см. в А.3 «Анализ непротиворечивости» (приложение А).

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

13.6.3.3.3 Шаг оценивания 4:ADV_HLD.2-3

ИСО/МЭК 15408-3 ADV_HLD.2.3C: Проект верхнего уровня должен содержать описание структуры ФБО в терминах подсистем.

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

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

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

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

Между вариантом выделения подсистем разработчиком и масштабами проводимого оценщиком анализа могут существовать некоторые взаимозависимости. Эти взаимозависимости рассмотрены ниже при описании шага оценивания ADV_HLD.2-10.

13.6.3.3.4 Шаг оценивания 4:ADV_HLD.2-4

ИСО/МЭК 15408-3 ADV_HLD.2.4C: Проект верхнего уровня должен содержать описание функциональных возможностей безопасности, предоставленных каждой подсистемой ФБО.

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

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

13.6.3.3.5 Шаг оценивания 4:ADV_HLD.2-5

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

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

Если ЗБ не содержит требования безопасности для среды ИТ, то рассматриваемый шаг оценивания не применяют и поэтому считают удовлетворенным.

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

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

13.6.3.3.6 Шаг оценивания 4:ADV_HLD.2-6

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

Если ЗБ не содержит требования безопасности для среды ИТ, то рассматриваемый шаг оценивания не применяют и поэтому считают удовлетворенным.

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

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

13.6.3.3.7 Шаг оценивания 4:ADV_HLD.2-7

ИСО/МЭК 15408-3 ADV_HLD.2.6C: Проект верхнего уровня должен идентифицировать все интерфейсы для подсистем ФБО.

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

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

13.6.3.3.8 Шаг оценивания 4:ADV_HLD.2-8

ИСО/МЭК 15408-3 ADV_HLD.2.7C: Проект верхнего уровня должен идентифицировать, какие из интерфейсов подсистем ФБО являются видимыми извне.

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

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

13.6.3.3.9 Шаг оценивания 4:ADV_HLD.2-9

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

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

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

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

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

13.6.3.3.10 Шаг оценивания 4:ADV_HLD.2-10

ИСО/МЭК 15408-3 ADV_HLD.2.9C: Проект верхнего уровня должен содержать описание разделения ОО на подсистемы, осуществляющие ПБО, и прочие.

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

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

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

13.6.3.4 Действие ADV_HLD.2.2E

13.6.3.4.1 Шаг оценивания 4:ADV_HLD.2-11

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

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

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

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

13.6.3.4.2 Шаг оценивания 4:ADV_HLD.1-12

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

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

13.6.4 Оценка представления реализации (ADV_IMP.1)

13.6.4.1 Цели

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

13.6.4.2 Исходные данные

Свидетельствами оценки для этого подвида деятельности являются:

a) ЗБ;

b) проект нижнего уровня;

c) подмножество представления реализации.

13.6.4.3 Действие ADV_IMP.1.1E

13.6.4.3.1 Шаг оценивания 4:ADV_IMP.1-1

ИСО/МЭК 15408-3 ADV_IMP.1.1C: Представление реализации должно однозначно определить ФБО на таком уровне детализации, что ФБО могут быть созданы без дальнейших проектных решений.

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

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

Любые используемые языки программирования должны быть полностью определены, включая однозначное определение всех операторов, а также опций компилятора, используемых для генерации объектного кода. Заключение об этом может уже быть сделано как часть подвида деятельности ALC_TAT.1 «Полностью определенные инструментальные средства разработки».

13.6.4.3.2 Шаг оценивания 4:ADV_IMP.1-2

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

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

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

Руководство по выборке см. в А.2 «Выборка» (приложение А).

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

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

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

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

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

b) требования системы оценки;

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

d) суждение оценщика относительно частей представления реализации, которые могут быть полезными для проводимого оценщиком независимого анализа уязвимостей (подвид деятельности AVA_VLA.2 «Независимый анализ уязвимостей»).

13.6.4.3.3 Шаг оценивания 4:ADV_IMP.1-3

ИСО/МЭК 15408-3 ADV_IMP.1.2C: Представление реализации должно быть внутренне непротиворечивым.

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

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

Руководство по анализу непротиворечивости см. в A.3 «Анализ непротиворечивости» (приложение А).

13.6.4.4 Действие ADV_IMP.1.2E

13.6.4.4.1 Шаг оценивания 4:ADV_IMP.1-4

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

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

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

13.6.5 Оценка проекта нижнего уровня (ADV_LLD.1)

13.6.5.1 Цели

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

13.6.5.2 Исходные данные

Свидетельствами оценки для этого подвида деятельности являются:

a) ЗБ;

b) функциональная спецификация;

c) проект верхнего уровня;

d) проект нижнего уровня.

13.6.5.3 Действие ADV_LLD.1.1E

13.6.5.3.1 Шаг оценивания 4:ADV_LLD.1-1

ИСО/МЭК 15408-3 ADV_LLD.1.1C: Представление проекта нижнего уровня должно быть неформальным.

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

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

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

13.6.5.3.2 Шаг оценивания 4:ADV_LLD.1-2

ИСО/МЭК 15408-3 ADV_LLD.1.2C: Проект нижнего уровня должен 6ыть внутренне непротиворечивым.

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

Руководство по анализу непротиворечивости см. в А.3 «Анализ непротиворечивости» (приложение А).

13.6.5.3.3 Шаг оценивания 4:ADV_LLD.1-3

ИСО/МЭК 15408-3 ADV_LLD.1.3C: Проект нижнего уровня должен содержать описание ФБО в терминах модулей.

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

Применительно к проекту нижнего уровня термин «модуль» использован в соответствующем ИСО/МЭК 15408 для обозначения менее абстрактной сущности, чем подсистема. Это означает, что проект нижнего уровня содержит больше подробностей относительно не только цели каждого модуля, но также и относительно способа достижения модулем своей цели. В идеале в проекте нижнего уровня должна быть представлена вся информация, необходимая для реализации описанных в нем модулей. Последующие шаги оценивания в этом подвиде деятельности требуют проведения конкретного анализа, чтобы сделать заключение, достаточен ли уровень детализации проекта нижнего уровня. На данном шаге оценивания оценщику достаточно верифицировать четкость и однозначность идентификации каждого модуля.

13.6.5.3.4 Шаг оценивания 4:ADV_LLD.1-4

ИСО/МЭК 15408-3 ADV_LLD.1.4C: Проект нижнего уровня должен содержать описание назначения каждого модуля.

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

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

13.6.5.3.5 Шаг оценивания 4:ADV_LLD.1-5

ИСО/МЭК 15408-3 ADV_LLD.1.5C: Проект нижнего уровня должен определить взаимосвязи между модулями в терминах предоставляемых функциональных возможностей безопасности и зависимостей от других модулей.

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

В целях проведения такого анализа рассматривают два способа взаимодействия модулей:

a) предоставление услуг друг другу;

b) совместную работу для поддержки функций безопасности.

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

13.6.5.3.6 Шаг оценивания 4:ADV_LLD.1-6

ИСО/МЭК 15408-3 ADV_LLD.1.6C: Проект нижнего уровня должен содержать описание, как предоставляется каждая из функций, осуществляющих ПБО.

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

Функции, осуществляющие ПБО, — это те функции из числа ФБО, которые прямо или косвенно осуществляют ПБО.

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

13.6.5.3.7 Шаг оценивания 4:ADV_LLD.1-7

ИСО/МЭК 15408-3 ADV_LLD.1.7C: Проект нижнего уровня должен идентифицировать все интерфейсы модулей ФБО.

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

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

13.6.5.3.8 Шаг оценивания 4:ADV_LLD.1-8

ИСО/МЭК 15408-3 ADV_LLD.1.8C: Проект нижнего уровня должен идентифицировать, какие из интерфейсов модулей ФБО являются видимыми извне.

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

Как изложено в описании шага оценивания ADV_FSP.2-3, через внешние интерфейсы (т.е. видимые пользователю) можно прямо или косвенно получить доступ к ФБО. Любой внешний интерфейс, через который можно прямо или косвенно получить доступ к ФБО, должен быть идентифицирован для проведения данного шага оценивания. Внешние интерфейсы, через которые нельзя получить доступ к ФБО, не обязательно должны быть включены.

13.6.5.3.9 Шаг оценивания 4:ADV_LLD.1-9

ИСО/МЭК 15408-3 ADV_LLD.1.9C: Проект нижнего уровня должен содержать описание назначения и методов использования всех интерфейсов модулей ФБО, предоставляя, при необходимости, детализацию результатов, нештатных ситуаций и сообщений об ошибках.

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

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

Данный шаг оценивания может быть выполнен совместно с проведением оценщиком независимого анализа уязвимостей (подвид деятельности AVA_VLA.2).

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

13.6.5.3.10 Шаг оценивания 4:ADV_LLD.1-10

ИСО/МЭК 15408-3 ADV_LLD.1.10C: Проект нижнего уровня должен содержать описание разделения ОО на модули, осуществляющие ПВО, и прочие.

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

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

13.6.5.4 Действие ADV_LLD.1.2E

13.6.5.4.1 Шаг оценивания 4:ADV_LLD.1-11

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

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

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

b) спецификации интерфейсов согласованы с их использованием другими модулями;

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

13.6.5.4.2 Шаг оценивания 4:ADV_LLD.1-12

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

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

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

13.6.6 Оценка соответствия представлении (ADV_RCR.1)

13.6.6.1 Цели

Цель данного подвида деятельности — сделать заключение, правильно ли и полностью ли разработчик реализовал требования ЗБ, функциональной спецификации, проекта верхнего уровня и проекта нижнего уровня в представлении реализации.

13.6.6.2 Исходные данные

Свидетельствами оценки для этого подвида деятельности являются:

a) ЗБ;

b) функциональная спецификация;

c) проект верхнего уровня;

d) проект нижнего уровня;

e) подмножество представления реализации;

f) материалы анализа соответствия между краткой спецификацией ОО и функциональной спецификацией;

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

h) материалы анализа соответствия между проектом верхнего уровня и проектом нижнего уровня;

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

13.6.6.3 Действие ADV_RCR.1.1E

13.6.6.3.1 Шаг оценивания 4:ADV_RCR.1-1

ИСО/МЭК 15408-3 ADV_RCR.1.1C: Для каждой смежной пары имеющихся представлении ФБО анализ должен демонстрировать, что все функциональные возможности более абстрактного представления ФБО, относящиеся к безопасности, правильно и полностью уточнены в менее абстрактном представлении ФБО.

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

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

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

Данный шаг оценивания может быть выполнен совместно с шагами оценивания ADV_FSP.2-8 и ADV_FSP.2-9.

13.6.6.3.2 Шаг оценивания 4:ADV_RCR.1-2

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

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

13.6.6.3.3 Шаг оценивания 4:ADV_RCR.1-3

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

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

13.6.6.3.4 Шаг оценивания 4:ADV_RCR.1-4

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

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

13.6.7 Оценка моделирования политики безопасности ОО (ADV_SPM.1)

13.6.7.1 Цели

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

13.6.7.2 Исходные данные

Свидетельствами оценки для этого подвида деятельности являются:

a) ЗБ;

b) функциональная спецификация;

c) модель политики безопасности ОО;
d) руководство пользователя;

e) руководство администратора.

13.6.7.3 Действие ADV_SPM.1.1E

13.6.7.3.1 Шаг оценивания 4:ADV_SPM.1-1

ИСО/МЭК 15408-3 ADV_SPM.1.1C: Модель ПБО должна быть неформальной.

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

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

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

13.6.7.3.2 Шаг оценивания 4:ADV_SPM.1-2

ИСО/МЭК 15408-3 ADV_SPM.1.2C: Модель ПБО должна содержать описание правил и характеристик всех политик ПБО, которые могут быть смоделированы.

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

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

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

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

13.6.7.3.3 Шаг оценивания 4:ADV_SPM.1-3

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

Кроме представленных в явном виде политик ФБ (см. шаг оценивания ADV_SPM.1-2), оценщик анализирует функциональные требования безопасности из ЗБ для тех политик ФБ, наличие которых предполагается в связи с другими классами функциональных требований безопасности. Например, включение компонентов требований класса FDP «Защита данных пользователя» (за исключением FDP_ACC и FDP_IFC) обычно предусматривает описание в модели политики безопасности ОО осуществляемой политики защиты данных; включение компонентов требований класса FIA «Идентификация и аутентификация» — описание политик ФБ идентификации и аутентификации; включение компонентов требований безопасности класса FAU «Аудит безопасности» — описание политик ФБ аудита и т.д. Хотя компоненты функциональных требований безопасности из других семейств обычно не ассоциируются с тем, что понимается как политики ФБ, однако они все же обеспечивают выполнение ряда политик ФБ (например, таких как неотказуемость, посредничество при обращениях, приватность и т.д.), которые должны быть включены в модель политики безопасности ОО.

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

Если ЗБ не содержит таких подразумеваемых правил, то рассматриваемый шаг оценивания не применяют и поэтому считают удовлетворенным.

13.6.7.3.4 Шаг оценивания 4:ADV_SPM.1-4

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

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

a) определено понятие целостности для рассматриваемого ОО;

b) идентифицированы типы данных, для которых ОО поддерживает целостность;

c) идентифицированы сущности, которые могут модифицировать данные указанных типов;

d) идентифицированы правила, которые должны быть выполнены при модификации данных.

13.6.7.3.5 Шаг оценивания 4:ADV_SPM.1-5

ИСО/МЭК 15408-3 ADV_SPM.1.3C: Модель ПБО должна включать в себя обоснование, которое демонстрирует, что она согласована и полна относительно всех политик ПБО? которые могут быть смоделированы.

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

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

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

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

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

Руководство по анализу непротиворечивости см. в А.3 «Анализ непротиворечивости в (приложение А).

13.6.7.3.6 Шаг оценивания 4:ADV_SPM.1-6

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

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

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

13.6.7.3.7 Шаг оценивания 4:ADV_SPM.1-7

ИСО/МЭК 15408-3 ADV_SPM.1.4C: Демонстрация соответствия между моделью ПБО и функциональной спецификацией должна показать, что все функции безопасности в функциональной спецификации являются непротиворечивыми и полными относительно модели ПБО.

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

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

13.6.7.3.8 Шаг оценивания 4:ADV_SPM.1-8

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

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

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

Руководство по анализу непротиворечивости см. в А.3 «Анализ непротиворечивости» (приложение А).

Далее >>>