LINEBURG


<< Пред. стр.

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

ОГЛАВЛЕНИЕ

След. стр. >>

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

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

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

51
Руководство по анализу непротиворечивости см. в подразделе 10.3.
299

Оценщик подтверждает правильность спецификаций интерфейсов конкретной подсистемы,
300

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

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

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

называться «подсистемами», но они должны представлять подобный уровень
декомпозиции. Например, при декомпозиции проекта могут использоваться понятия «слои»
или «менеджеры».
ADV_HLD.1.4C
ADV_HLD.1-4 Оценщик должен исследовать проект верхнего уровня, чтобы сделать
заключение, содержит ли он описание функциональных возможностей
безопасности каждой подсистемы.
Описание режима безопасного функционирования подсистемы – это описание того, что
304

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

оценивания не применяется.
Если ЗБ содержит необязательное изложение требований безопасности для среды ИТ,
306

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


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

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

оценивания не применяется.
Представление функций, предоставляемых базовой абстрактной машиной, на базе которой
309

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

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

входа.
ADV_HLD.1.7C
ADV_HLD.1-8 Оценщик должен проверить, идентифицировано ли в проекте верхнего уровня,
какие интерфейсы подсистем ФБО являются внешне видимыми.
5.5.1.4.2 Действие ADV_HLD.1.2E
ADV_HLD.1-9 Оценщик должен исследовать проект верхнего уровня, чтобы сделать
заключение, является ли он точным отображением функциональных требований
безопасности ОО.
Оценщик анализирует проект верхнего уровня для каждой функции безопасности ОО,
312

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

53
Оценщик также анализирует требования безопасности для среды ИТ, изложенные в ЗБ и
313

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

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

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

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

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

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

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

оценивания не применяется.


54
Для тех частей проекта верхнего уровня, которые трудны для понимания только на основе
321

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

Оценщик подтверждает правильность спецификаций интерфейсов конкретной подсистемы,
323

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

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

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

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

оценщиком анализа могут существовать некоторые взаимозависимости. Эти
взаимозависимости рассматриваются ниже при описании шага оценивания ADV_HLD.2-10.
ADV_HLD.2.4C
ADV_HLD.2-4 Оценщик должен исследовать проект верхнего уровня, чтобы сделать
заключение, содержит ли он описание функциональных возможностей
безопасности каждой подсистемы.
Описание режима безопасного функционирования подсистемы – это описание того, что
328

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

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

оценивания не применяется.
Если ЗБ содержит необязательное изложение требований безопасности для среды ИТ,
330

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

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

оценивания не применяется.
Представление функций, предоставляемых базовой абстрактной машиной, на базе которой
333

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

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

входа.
ADV_HLD.2.7C


56
ADV_HLD.2-8 Оценщик должен проверить, идентифицировано ли в проекте верхнего уровня,
какие интерфейсы подсистем ФБО являются внешне видимыми.
Как изложено в описании шагов оценивания ADV_FSP.1-3 и ADV_FSP.2-3, через внешние
336

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

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

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

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

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


57
Как объяснялось на шаге оценивания ADV_HLD.2-3, вариант выделения разработчиком
341

подсистем и группирования функций безопасности в рамках каждой подсистемы является
важным аспектом полезности проекта верхнего уровня для понимания предполагаемого
функционирования ОО. Однако вариант группирования ФБО в рамках подсистем также
влияет на область действия ФБО, так как подсистема с какой-либо функцией, которая
прямо или косвенно осуществляет ПБО, является частью ФБО. Хотя цель – обеспечить
понимание предполагаемого функционирования ОО – важна, также полезным является
ограничение объема ФБО в рамках подсистем в целях сокращения масштабов
необходимого анализа. Эти две цели – обеспечение понимания и сокращение масштабов
анализа – могут иногда противоречить друг другу. Оценщику следует учитывать это при
оценке варианта выделения подсистем.
5.5.2.4.2 Действие ADV_HLD.2.2E
ADV_HLD.2-11 Оценщик должен исследовать проект верхнего уровня, чтобы сделать
заключение, является ли он точным отображением функциональных требований

<< Пред. стр.

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

ОГЛАВЛЕНИЕ

След. стр. >>

Copyright © Design by: Sunlight webdesign