LINEBURG


<< Пред. стр.

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

ОГЛАВЛЕНИЕ

След. стр. >>

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

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

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

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

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

5.6 Оценка реализации
5.6.1 Подвид деятельности ADV_IMP.1
5.6.1.1 Цели
Цель данного подвида деятельности – сделать заключение, является ли представление
346

реализации достаточным для удовлетворения функциональных требований ЗБ и является
ли оно корректной реализацией проекта нижнего уровня.
5.6.1.2 Исходные данные
Безусловными свидетельствами оценки для этого подвида деятельности являются:
347

а) ЗБ;

58
б) подмножество представления реализации.
Свидетельством оценки для этого подвида деятельности, обусловленным зависимостями из
348

ОК, является проект нижнего уровня.
5.6.1.3 Действия оценщика
Этот подвид деятельности включает два элемента действий оценщика из части 3 ОК:
349

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

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

включая однозначное определение всех операторов, а также опций компилятора,
используемых для генерации объектного кода. Заключение об этом может уже быть
сделано как часть подвида деятельности ALC_TAT.1, если этот подвид деятельности
является частью оценки.
ADV_IMP.1-2 Оценщик должен исследовать представление реализации, предоставленное
разработчиком, чтобы сделать заключение, является ли оно достаточно
репрезентативным.
От разработчика требуется предоставить представление реализации только для
352

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

используя принципы осуществления выборки.
Руководство по выборке см. в подразделе 10.2.
354

Делая заключение о приемлемости подмножества ФБО, оценщик решает, пригодно ли оно
355

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


59
Например, для ОО, который реализован в виде традиционной операционной системы,
356

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

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

репрезентативности подмножества представления реализации:
а) сложность проекта (если сложность проекта в рамках одного ОО варьируется, то в
подмножество представления реализации должно включать какие-либо части высокой
сложности);
б) требования системы сертификации;
в) результаты других подвидов деятельности по анализу проекта (таких, как результаты
шагов оценивания, относящихся к проектам нижнего и верхнего уровней), которые могут
указывать на те части ОО, для которых в проекте возможна неоднозначность;
г) суждение оценщика относительно частей представления реализации, которые могут быть
полезными для проводимого оценщиком независимого анализа уязвимостей (подвид
деятельности AVA_VLA.2, если этот подвид деятельности является частью оценки).
ADV_IMP.1.2C
ADV_IMP.1-3 Оценщик должен исследовать представление реализации, чтобы сделать
заключение о его внутренней непротиворечивости.
Поскольку от разработчика требуется предоставить только подмножество представления
359

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

5.6.1.3.2 Действие ADV_IMP.1.2E
ADV_IMP.1-4 Оценщик должен исследовать подмножество представления реализации, чтобы
сделать заключение, является ли оно точным отображением тех функциональных
требований безопасности ОО, которые имеют отношение к подмножеству.


60
Для тех частей подмножества представления реализации, которые непосредственно
361

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

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

5.7 Оценка проекта нижнего уровня
5.7.1 Подвид деятельности ADV_LLD.1
5.7.1.1 Цели
Цель данного подвида деятельности – сделать заключение, является ли проект нижнего
363

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

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

а) ЗБ;
б) проект нижнего уровня.


61
Свидетельствами оценки для этого подвида деятельности, обусловленными зависимостями
366

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

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

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

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

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

деятельности для обозначения менее абстрактной сущности, чем подсистема. Это означает,
что проект нижнего уровня содержит больше подробностей относительно не только цели
каждого модуля, но также и относительно способа достижения модулем своей цели. В
идеале в проекте нижнего уровня должна быть представлена вся информация, необходимая
для реализации описанных в нем модулей. Последующие шаги оценивания в этом подвиде
деятельности требуют проведения конкретного анализа, чтобы сделать заключение,
достаточен ли уровень детализации проекта нижнего уровня. На данном шаге оценивания
оценщику достаточно верифицировать четкость и однозначность идентификации каждого
модуля.
ADV_LLD.1.4C
ADV_LLD.1-4 Оценщик должен исследовать проект нижнего уровня, чтобы сделать
заключение, содержит ли он описание назначения каждого модуля.
Проект нижнего уровня должен содержать описание назначения каждого модуля. Это
372

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

62
ADV_LLD.1.5C
ADV_LLD.1-5 Оценщик должен исследовать проект нижнего уровня, чтобы сделать
заключение, определены ли в нем взаимосвязи между модулями в терминах
предоставляемых функциональных возможностей безопасности и зависимостей
от других модулей.
В целях проведения такого анализа рассматриваются два способа взаимодействия модулей:
373

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

взаимосвязях. Например, если модуль выполняет вычисления, которые зависят от
результатов вычислений, выполняемых другими модулями, последние должны быть
перечислены. Кроме того, если модуль предоставляет услугу, предназначенную для
использования другими модулями при поддержке функций безопасности, данная услуга
должна быть описана. Возможно, что описание назначения модуля, которое анализируется
на предыдущем шаге оценивания, достаточно для того, чтобы предоставить такую
информацию.
ADV_LLD.1.6C
ADV_LLD.1-6 Оценщик должен исследовать проект нижнего уровня, чтобы сделать
заключение, содержит ли он описание того, каким образом предоставляется
каждая из функций, осуществляющих ПБО.
Функции, осуществляющие ПБО – это те функции из числа ФБО, которые прямо или
375

косвенно осуществляют ПБО.
Рассматриваемое на данном шаге описание, содержащееся в проекте нижнего уровня,
376

является ключевым при оценке того, достаточно ли уточнен проект нижнего уровня, чтобы
дать возможность осуществить реализацию. Оценщику следует проанализировать описание
с точки зрения реализующего. Если для оценщика, поставившего себя на место
реализующего, какой-либо аспект того, каким образом модуль может быть реализован,
остается неясным, то рассматриваемое описание считается неполным. Обратите внимание,
что не предъявляется требование, чтобы модуль был реализован как отдельная единица
(будь это программа, подпрограмма или аппаратный компонент); но проект нижнего
уровня может быть достаточно подробным, чтобы дать возможность осуществить такую
реализацию.
ADV_LLD.1.7C
ADV_LLD.1-7 Оценщик должен проверить, идентифицированы ли в проекте нижнего уровня
все интерфейсы модулей ФБО.
Проект нижнего уровня должен включать для каждого модуля имя каждой из его точек
377

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

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


63
интерфейсы, через которые нельзя получить доступ к ФБО, не обязательно должны быть
включены.
ADV_LLD.1.9C
ADV_LLD.1-9 Оценщик должен исследовать проект нижнего уровня, чтобы сделать
заключение, содержится ли в нем описание назначения и методов использования
всех интерфейсов каждого модуля, и предоставляется ли при необходимости
подробное описание результатов, нештатных ситуаций и сообщений об ошибках.
Описание интерфейсов модулей может быть предоставлено для одних интерфейсов в
379

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

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

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

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

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



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

<< Пред. стр.

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

ОГЛАВЛЕНИЕ

След. стр. >>

Copyright © Design by: Sunlight webdesign