LINEBURG


<< Пред. стр.

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

ОГЛАВЛЕНИЕ

След. стр. >>

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

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

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

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

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

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

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

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

45
Для каждого интерфейса, описанного в функциональной спецификации, который оказывает
269

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

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

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

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

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

а) ADV_FSP.2.1E;
б) ADV_FSP.2.2E.
5.4.2.4.1 Действие ADV_FSP.2.1E
ADV_FSP.2.1C

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

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

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

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

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

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




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

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

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


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

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

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

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


48
Оценивая адекватность и правильность представления интерфейсов, оценщик использует
284

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

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

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

49
Для того чтобы оценить полноту представления ФБО, оценщик принимает во внимание
287

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

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

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

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

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

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

5.5 Оценка проекта верхнего уровня
5.5.1 Подвид деятельности ADV_HLD.1
5.5.1.1 Цели
Цель данного подвида деятельности – сделать заключение, дано ли в проекте верхнего
292

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

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

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

ОК, является функциональная спецификация.
5.5.1.4 Действия оценщика
Этот подвид деятельности включает два элемента действий оценщика из части 3 ОК:
296

а) ADV_HLD.1.1E;

<< Пред. стр.

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

ОГЛАВЛЕНИЕ

След. стр. >>

Copyright © Design by: Sunlight webdesign