LINEBURG


<< Пред. стр.

страница 6
(всего 26)

ОГЛАВЛЕНИЕ

След. стр. >>

Руководство по посещению объектов см. в подразделе 10.5.
220

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

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


36
подобные продукты, то для приобретения доверия может быть полезно исследование
процедур при их применении.
4.3.2 Подвид деятельности ADO_DEL.2
4.3.2.1 Цели
Цель данного подвида деятельности – сделать заключение, описаны ли в документации
222

поставки все процедуры, применяемые для поддержания целостности и обнаружения
модификации или подмены ОО при распространении ОО по объектам использования.
4.3.2.2 Исходные данные
Свидетельством оценки для этого подвида деятельности является документация поставки.
223

4.3.2.3 Действия оценщика
Этот подвид деятельности включает два элемента действий оценщика из части 3 ОК:
224

а) ADO_DEL.2.1E;
б) Подразумеваемое действие оценщика, основанное на ADO_DEL.2.2D.
4.3.2.3.1 Действие ADO_DEL.2.1E
ADO_DEL.2.1C
Оценщик должен исследовать документацию поставки, чтобы сделать
ADO_DEL.2-1
заключение, описаны ли в ней все процедуры, необходимые для поддержания
безопасности при распространении версий ОО или его составляющих по объектам
использования.
При интерпретации термина необходимые требуется учитывать природу ОО и
225

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

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

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

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

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



37
Выбор процедур поставки зависит от ОО (например, является ли он программным или
230

аппаратным) и целей безопасности. Если процедуры поставки отличаются для различных
частей ОО, то для удовлетворения всех целей безопасности потребуется вся совокупность
процедур.
ADO_DEL.2.2C
Оценщик должен исследовать документацию поставки, чтобы сделать
ADO_DEL.2-2
заключение, что она содержит описание, каким образом различные процедуры и
технические меры обеспечивают обнаружение модификаций или любого
расхождения между оригиналом разработчика и версией, полученной на объекте
использования.
Для обнаружения вмешательства разработчик может использовать процедуры
231

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

и версией, полученной на объекте использования, следует описать в процедурах поставки.
ADO_DEL.2.3C
Оценщик должен исследовать документацию поставки, чтобы сделать
ADO_DEL.2-3
заключение, что она содержит описание, каким образом различные механизмы и
процедуры позволяют обнаружить попытку подмены отправителя, даже в тех
случаях, когда разработчик ничего не отсылал на объект использования.
Это требование может быть выполнено при поставке ОО или его частей (например,
233

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

безопасности могут применяться цифровая подпись, контрольные суммы целостности или
шифрование.
4.3.2.3.2 Подразумеваемое действие оценщика
ADO_DEL.2.2D
Оценщик должен исследовать аспекты процесса поставки, чтобы сделать
ADO_DEL.2-4
заключение о применении процедур поставки.
Подход, предпринятый оценщиком для проверки применения процедур поставки, будет
235

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



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

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

4.4 Оценка установки, генерации и запуска
4.4.1 Подвид деятельности ADO_IGS.1
4.4.1.1 Цели
Цель данного подвида деятельности – сделать заключение, были ли задокументированы
238

процедуры и шаги для безопасной установки, генерации и запуска ОО и приводят ли они к
безопасной конфигурации.
4.4.1.2 Исходные данные
Свидетельства оценки для этого подвида деятельности:
239

а) руководство администратора;
б) процедуры безопасной установки, генерации и запуска;
в) ОО, пригодный для тестирования.
4.4.1.3 Замечания по применению
К рассматриваемым процедурам установки, генерации и запуска относятся все процедуры
240

установки, генерации и запуска, которые необходимы для получения безопасной
конфигурации ОО, описанной в ЗБ, независимо от того, выполняются ли они на объекте
использования или на объекте разработки.
4.4.1.4 Действия оценщика
Этот подвид деятельности включает два элемента действий оценщика из части 3 ОК:
241

а) ADO_IGS.1.1E;
б) ADO_IGS.1.2E.
4.4.1.4.1 Действие ADO_IGS.1.1E
ADO_IGS.1.1C
Оценщик должен проверить, чтобы были предоставлены процедуры,
ADO_IGS.1-1
необходимые для безопасной установки, генерации и запуска ОО.
Если не ожидается, что процедуры установки, генерации и запуска будут или могут быть
242

повторно применены (например, потому что ОО поставлен в рабочем состоянии), то этот
шаг оценивания (или отдельные его части) не применяется.
4.4.1.4.2 Действие ADO_IGS.1.2E
Оценщик должен исследовать предоставленные процедуры установки,
ADO_IGS.1-2
генерации и запуска, чтобы сделать заключение, что они описывают шаги,
необходимые для безопасной установки, генерации и запуска ОО.
Если не ожидается, что процедуры установки, генерации и запуска будут или могут быть
243

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

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

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




40
5 Вид деятельности ADV
5.1 Введение
Вид деятельности «Разработка» предназначен для того, чтобы оценить проектную
246

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

5.2 Цели
Вид деятельности «Разработка» предназначен для того, чтобы оценить проектную
247

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

5.3 Замечания по применению
Требования ОК к проектной документации ранжированы по уровню формализации. В
248

отношении вида деятельности «Разработка» в ОК рассматриваются следующие
иерархические степени формализации документа: неформальный, полуформальный,
формальный. Неформальный документ – это документ, который составлен на естественном
языке. Методология не предписывает использовать какой-либо конкретный язык; этот
вопрос остается за системой оценки.

5.4 Оценка функциональной спецификации
5.4.1 Подвид деятельности ADV_FSP.1
5.4.1.1 Цели
Цель данного подвида деятельности – сделать заключение, предоставил ли разработчик
249

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

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

41
аудита, связанные с обнаружением и регистрацией таких событий, то описание таких
функций аудита также обычно включается в состав функциональной спецификации; и хотя
пользователь формально не обращается к этим функциям непосредственно через внешний
интерфейс, на них определенно влияет все то, что происходит на уровне внешнего
пользовательского интерфейса.
5.4.1.3 Исходные данные
Безусловными свидетельствами оценки для этого подвида деятельности являются:
251

а) ЗБ;
б) функциональная спецификация.
Свидетельствами оценки для этого подвида деятельности, которые требуются для
252

выполнения шагов оценивания, являются:
а) руководство пользователя;
б) руководство администратора.
5.4.1.4 Действия оценщика
Этот подвид деятельности включает два элемента действий оценщика из части 3 ОК:
253

а) ADV_FSP.1.1E;
б) ADV_FSP.1.2E.
5.4.1.4.1 Действие ADV_FSP.1.1E
ADV_FSP.1.1C
ADV_FSP.1-1 Оценщик должен исследовать функциональную спецификацию, чтобы сделать
заключение, содержит ли она весь необходимый неформальный пояснительный
текст.
Если вся функциональная спецификация является неформальной, то рассматриваемый шаг
254

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

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

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

ADV_FSP.1.3C
ADV_FSP.1-3 Оценщик должен исследовать функциональную спецификацию, чтобы сделать
заключение, определены ли в ней все внешние интерфейсы функций безопасности
ОО.
Термин «внешний» относится к тому интерфейсу, который является видимым для
258

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

42
На рисунке 5.1 показан ОО, включающий ФБО-части (заштрихованы) и не-ФБО-части
(незаштрихованы). Данный ОО имеет три внешних интерфейса: интерфейс в –
непосредственный интерфейс ФБО; интерфейс б – косвенный интерфейс ФБО; интерфейс а
– интерфейс не-ФБО-частей ОО. Таким образом, интерфейсы б и в составляют ИФБО.




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

Следует отметить, что все функции безопасности, отраженные в функциональных
259

требованиях из части 2 ОК (или в компонентах расширения части 2 ОК), будут иметь
некоторым образом внешне видимые проявления. И хотя не обязательно все из них
являются интерфейсами, через которые могут тестироваться функции безопасности, все
они в некотором смысле являются внешне видимыми, а поэтому должны быть включены в
функциональную спецификацию.
ADV_FSP.1-4 Оценщик должен исследовать функциональную спецификацию, чтобы сделать
заключение, описаны ли в ней все внешние интерфейсы функций безопасности
ОО.
Для ОО, по отношению к которому не имеется угроз, связанных с действиями
260

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

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

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

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

<< Пред. стр.

страница 6
(всего 26)

ОГЛАВЛЕНИЕ

След. стр. >>

Copyright © Design by: Sunlight webdesign