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

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

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

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

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

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

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

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

12.6.2.1 Цели

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

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

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

a) ЗБ;

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

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

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

12.6.2.3 Действие ADV_FSP.1.1E

12.6.2.3.1 Шаг оценивания 3:ADV_FSP.1-1

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

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

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

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

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

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

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

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

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

12.6.2.3.3 Шаг оценивания 3:ADV_FSP.1-3

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

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

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

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

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

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

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

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

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

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

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

12.6.2.3.5 Шаг оценивания 3:ADV_FSP.1-5

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

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

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

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

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

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

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

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

12.6.2.3.6 Шаг оценивания 3:ADV_FSP.1-6

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

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

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

12.6.2.4 Действие ADV_FSP.1.2E

12.6.2.4.1 Шаг оценивания 3:ADV_FSP.1-7

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

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

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

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

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

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

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

12.6.3.1 Цели

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

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

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

a) ЗБ;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

12.6.4.1 Цели

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

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

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

a) ЗБ;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Далее >>>