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

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

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

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

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

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

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

10.6.2.1 Цели

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

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

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

a) ЗБ;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10.6.3.1 Цели

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

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

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

a) ЗБ;

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

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

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

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

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

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

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

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

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

Далее >>>