ГОСТ Р ИСО/МЭК 18045-2013 Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий

ГОСТ Р ИСО/МЭК 18045-2013

Группа П85

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационная технология

МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ. МЕТОДОЛОГИЯ ОЦЕНКИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

Information technology - Security techniques - Methodology for IT security evaluation

ОКС 35.040
ОКСТУ 4002

Дата введения 2014-07-01

Предисловие

1 ПОДГОТОВЛЕН Обществом с ограниченной ответственностью "Центр безопасности информации" (ООО "ЦБИ"), Федеральным автономным учреждением "Государственный научно-исследовательский испытательный институт проблем технической защиты информации Федеральной службы по техническому и экспортному контролю" (ФАУ "ГНИИИ ПТЗИ ФСТЭК России")

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 362 "Защита информации"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 28 августа 2013 г. N 624-ст

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 18045:2008* "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий" ("ISO/IEC Information technology - Security techniques - Methodology for IT security evaluation")
________________
* Доступ к международным и зарубежным документам, упомянутым здесь и далее по тексту, можно получить, перейдя по ссылке на сайт . - .

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА

5 ВЗАМЕН ГОСТ Р ИСО/МЭК 18045-2008


Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (gost.ru)

Введение

Введение

Международный стандарт ISO/IEC 18045:2008 был подготовлен Совместным техническим комитетом ISO/IEC JTC 1 "Информационные технологии", Подкомитетом SC 27 "Методы и средства обеспечения безопасности ИТ". Идентичный ISO/IEC 18045:2008 текст опубликован организациями - спонсорами проекта "Общие критерии" как "Общая методология оценки безопасности информационных технологий".

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

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

Вторая редакция стандарта отменяет и заменяет первую редакцию (ГОСТ Р ИСО/МЭК 18045:2007*), которая подверглась технической переработке.

________________
* Вероятно, ошибка оригинала. Следует читать: ГОСТ Р ИСО/МЭК 18045-2008. - .

1 Область применения

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

Настоящий стандарт не определяет действия оценщика для некоторых компонентов высокого доверия ИСО/МЭК 15408, по оценке которых пока нет единых согласованных руководств.

2 Нормативные ссылки

Указанные в данном разделе документы* являются необходимыми для применения настоящего стандарта. Для датированных ссылок используют только указанное издание. Для недатированных ссылок - последнее издание со всеми изменениями и дополнениями.
_______________
* Таблицу соответствия национальных стандартов международным см. по ссылке. - .

ИСО/МЭК 15408 (все части) Информационная технология - Методы и средства обеспечения безопасности - Критерии оценки безопасности ИТ [ISO/IEC 15408 (all parts) Information technology - Security techniques - Evaluation criteria for IT security].

3 Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями:

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

3.1 действие (action): Элемент действий оценщика из ИСО/МЭК 15408-3.

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

3.2 вид деятельности (activity): Применение класса требований доверия из ИСО/МЭК 15408-3.

3.3 проверить (check): Вынести вердикт посредством простого сравнения.

Примечание - Специальные знания и опыт оценщика не требуются. В формулировке, в которой используется этот глагол, описывается то, что сравнивается.

3.4 поставка для оценки (evaluation deliverable): Любой ресурс, который оценщик или орган оценки требует от заявителя или разработчика для выполнения одного или нескольких видов деятельности по проведению оценки или по надзору за оценкой.

3.5 свидетельство оценки (evaluation evidence): Фактическая поставка для оценки.

3.6 технический отчет об оценке (evaluation technical report): Отчет, выпущенный оценщиком и представленный в орган оценки, в котором приводится общий вердикт и его логическое обоснование.

3.7 исследовать (examine): Вынести вердикт на основе анализа с использованием специальных знаний и опыта оценщика.

Примечание - Формулировка, в которой используется этот глагол, указывает на то, что конкретно и какие свойства подвергаются анализу.

3.8 интерпретация (interpretation): Разъяснение или расширение требования ИСО/МЭК 15408, ИСО/МЭК 18045 или системы оценки.

3.9 методология (methodology): Система принципов, процедур и процессов, применяемых для оценки безопасности ИТ.

3.10 сообщение о проблеме (observation report): Сообщение, документально оформленное оценщиком, в котором он просит разъяснений или указывает на возникшую при оценке проблему.

3.11 общий вердикт (overall verdict): Положительный или отрицательный вывод оценщика по результатам оценки.

3.12 вердикт органа оценки (oversight verdict): Вывод органа оценки, подтверждающий или отклоняющий общий вердикт, который основан на результатах деятельности по надзору за оценкой.

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

3.14 привести в отчете (сообщении) (report): Включить результаты оценки и вспомогательные материалы в технический отчет об оценке или в сообщение о проблеме.

3.15 система оценки (scheme): Совокупность правил, установленных органом оценки и определяющих среду оценки, включая критерии и методологию, требуемые для проведения оценки безопасности ИТ.

3.16 подвид деятельности (sub-activity): Применение компонента требований доверия из ИСО/МЭК 15408-3.

Примечание - Семейства требований доверия прямо не рассматриваются в настоящем стандарте, поскольку при проведении оценки всегда используется только один компонент доверия из применяемого семейства.

3.17 прослеживание (tracing): Однонаправленная связь между двумя совокупностями сущностей, которая показывает, какие сущности в первой совокупности каким сущностям из второй соответствуют.

3.18 вердикт (verdict): Вывод оценщика положительный, отрицательный или неокончательный применительно к некоторому элементу действий оценщика, компоненту или классу требований доверия из ИСО/МЭК 15408.

Примечание - См. также общий вердикт.

3.19 шаг оценивания (work unit): Наименьшая структурная единица работ по оценке.

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

4 Обозначения и сокращения

В настоящем стандарте применены следующие сокращения:

ЗБ (ST) - задание по безопасности

ИТ (IT) - информационная технология

ИФБО (TSFI) - интерфейс ФБО

ОО (TOE) - объект оценки

ОУД (EAL) - оценочный уровень доверия

ПБОр (OSP) - политика безопасности организации

ПЗ (РР) - профиль защиты

ТДБ (SAR) - требование доверия к безопасности

УК (CM) - управление конфигурацией

ФБО (TSF) - функциональные возможности безопасности ОО

ФТБ (SFR) - функциональное требование безопасности

ТОО (ETR) - технический отчет об оценке

СП (OR) - сообщение о проблеме

5 Краткий обзор

5.1 Структура стандарта

Раздел 6 определяет соглашения, используемые в настоящем стандарте.

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

Раздел 8 описывает работы, необходимые для получения результата оценки ПЗ.

В разделах 9-15 определяются действия по оценке, сгруппированные по классам доверия.

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

В приложении В приводится пояснение критериев оценки уязвимостей и примеры их применения.

6 Принятые соглашения

6.1 Терминология

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

Любая определенная в методологии работа по оценке, которая не следует непосредственно из требований ИСО/МЭК 15408, называется задачей или подзадачей.

6.2 Употребление глаголов

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

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

Глаголы проверить (check), исследовать (examine), привести в отчете (report) и зафиксировать (record) в тексте настоящего стандарта имеют точный смысл, указанный в определениях раздела 3.

6.3 Общие указания по оценке

Материал, который применим более чем к одному подвиду деятельности, приводится в одном месте. Указания, которые являются широко применимыми (к нескольким видам деятельности или ОУД), приведены в приложении А. Указания, относящиеся к нескольким подвидам одного вида деятельности, содержатся во вводной части описания этого вида деятельности. Если указания относятся только к одному подвиду деятельности, они содержатся только в его описании.

6.4 Взаимосвязь между структурами ИСО/МЭК 15408 и ИСО/МЭК 18045

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

Рисунок 1 - Соотношение структур ИСО/МЭК 15408 и ИСО/МЭК 18045

Рисунок 1 - Соотношение структур ИСО/МЭК 15408 и ИСО/МЭК 18045

7 Процесс оценки и соответствующие задачи оценки

7.1 Введение

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

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

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

Подвиды деятельности по оценке в данном разделе вводятся, а полностью описываются в последующих разделах.

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

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

7.2 Краткое описание процесса оценки

7.2.1 Цели

В данном подразделе представлена общая модель методологии оценки и определяются:

a) роли и обязанности сторон, вовлеченных в процесс оценки;

b) общая модель оценки.

7.2.2 Обязанности ролей

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

Заявитель предъявляет запрос об оценке и отвечает за поддержание процесса оценки. Это означает, что заявитель заключает различные соглашения по поводу проведения оценки (например, относительно начала процесса оценки). Кроме того, заявитель отвечает и за то, чтобы оценщику были доступны свидетельства оценки.

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

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

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

7.2.3 Взаимоотношения между ролями

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

Кроме того, при проведении некоторых видов оценки (например оценки по ОУД1) может не требоваться вовлечение разработчика в процесс оценки. В таком случае ОО оценщику предоставляет заявитель, и он же генерирует свидетельства оценки.

7.2.4 Общая модель оценки

Процесс оценки состоит из выполнения оценщиком задачи получения исходных данных для оценки, задачи оформления результатов оценки и задачи выполнения подвидов деятельности по оценке. На рисунке 2 отражены отношения между этими задачами и подвидами деятельности.

Рисунок 2 - Общая модель оценки

Рисунок 2 - Общая модель оценки

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

7.2.5 Вердикты оценщика

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

В настоящем стандарте различаются три взаимоисключающих вида вердикта:

a) условиями положительного вердикта являются завершение оценщиком элемента действий оценщика из ИСО/МЭК 15408 и определение, что требования к оцениваемому ПЗ, ЗБ или ОО выполнены. Для элемента условиями положительного вердикта являются:

1) успешное завершение всех шагов оценивания, составляющих соответствующее действие из методологии оценки;

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

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

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

c) Все вердикты поначалу неокончательные и остаются такими до вынесения положительного или отрицательного вердикта.

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

Рисунок 3 - Пример правила вынесения вердикта

Рисунок 3 - Пример правила вынесения вердикта

7.3 Задача получения исходных данных для оценки

7.3.1 Цели

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

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

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

Поскольку требования доверия относятся к ОО в целом, то необходимо, чтобы оценщику были доступны свидетельства оценки, относящиеся ко всем частям ОО. Область применения и требуемое содержание такого свидетельства оценки не зависят от уровня контроля разработчиком над каждой частью ОО. Например, если требуется проект, то требования семейства ADV_TDS "Проект ОО" относятся ко всем подсистемам, являющимся частью ФБО. Кроме того, требования доверия, согласно которым требуется выполнение определенных процедур (например, из семейств ALC_CMC "Возможности УК" и ALC_DEL "Поставка"), также относятся к ОО в целом (включая любую часть, разработанную другим разработчиком).

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

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

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

a) тестовая документация, позволяющая оценщику предварительно оценить тесты и процедуры тестирования;

b) проектная документация, предоставляющая оценщику исходную информацию для понимания конструкции ОО;

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

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

7.3.3 Подзадача управления свидетельством оценки

7.3.3.1 Контроль конфигурации

Оценщик должен осуществлять контроль конфигурации свидетельства оценки.

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

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

7.3.3.2 Дальнейшее использование

Системы оценки могут предусматривать контроль за изъятием из использования свидетельств оценки после завершения оценки. Изъятие из использования свидетельств оценки может достигаться посредством следующих действий:

a) возврата свидетельств оценки;

b) архивирования свидетельств оценки;

c) уничтожения свидетельств оценки.

7.3.3.3 Конфиденциальность

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

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

7.4 Подвиды деятельности по оценке

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

7.5 Задача оформления результатов оценки

7.5.1 Цели

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

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

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

a) подготовку СП (если это необходимо при выполнении оценки);

b) подготовку ТОО.

7.5.2 Управление результатами оценки

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

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

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

7.5.4 Подзадача подготовки СП

СП предоставляют оценщику механизм для запроса разъяснений (например, от органа оценки о применении требований) или для определения проблемы по одному из аспектов оценки.

При отрицательном вердикте оценщик должен представить СП для отражения результата оценки. В противном случае оценщик может использовать СП как один из способов выражения потребности в разъяснении.

В любом СП оценщик должен привести следующее:

a) идентификатор оцениваемого ПЗ или ОО;

b) задачу/подвид деятельности по оценке, при выполнении которой/которого проблема была выявлена;

c) суть проблемы;

d) оценку ее серьезности (например, приводит к отрицательному вердикту, задерживает выполнение оценки или требует решения до завершения оценки);

e) наименование организации, ответственной за решение вопроса;

f) рекомендуемые сроки решения;

g) определение влияния на оценку отсутствия решения проблемы.

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

7.5.5 Подзадача подготовки ТОО

7.5.5.1 Цели

Оценщик должен подготовить ТОО, чтобы представить техническое логическое обоснование вердиктов.

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

Предполагается, что читатель ТОО знаком с общими концепциями информационной безопасности, ИСО/МЭК 15408, настоящим стандартом, подходами к оценке и ИТ

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

7.5.5.2 ТОО при оценке ПЗ

В данном подпункте приведено минимально необходимое содержание информации, включаемой в ТОО при оценке ПЗ. Содержание ТОО показано на рисунке 4; этот рисунок может использоваться как образец при построении структурной схемы ТОО.

Рисунок 4 - Содержание ТОО при оценке ПЗ

Рисунок 4 - Содержание ТОО при оценке ПЗ

7.5.5.2.1 Введение

Оценщик должен привести в отчете идентификаторы системы оценки.

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

Оценщик должен привести в отчете идентификаторы контроля конфигурации ТОО.

Идентификаторы контроля конфигурации ТОО содержат информацию, которая идентифицирует ТОО (например, наименование, дату составления и номер версии).

Оценщик должен привести в отчете идентификаторы контроля конфигурации ПЗ.

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

Оценщик должен привести в отчете идентификатор разработчика.

Идентификатор разработчика ПЗ требуется для идентификации стороны, ответственной за создание ПЗ.

Оценщик должен привести в отчете идентификатор заявителя.

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

Оценщик должен привести в отчете идентификатор оценщика.

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

7.5.5.2.2 Оценка

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

Оценщик приводит ссылки на использованные при оценке ПЗ критерии оценки, методологию и интерпретации.

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

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

7.5.5.2.3 Результаты оценки

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

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

7.5.5.2.4 Выводы и рекомендации

Оценщик должен привести в отчете выводы по результатам оценки, в частности, общий вердикт в соответствии с разделом 9 "Результаты оценки" ИСО/МЭК 15408-1 и процедурой вынесения вердикта, описанной в пункте 7.2.5 настоящего стандарта.

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

7.5.5.2.5 Перечень свидетельств оценки

Оценщик должен привести в отчете следующую информацию о каждом свидетельстве оценки:

- о составителе свидетельства (например, разработчик, заявитель);

- о названии свидетельства;

- об уникальной ссылке на свидетельство (например, дата составления и номер версии).

7.5.5.2.6 Перечень сокращений/глоссарий терминов

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

В ТОО нет необходимости повторять определения глоссария, уже приведенные в ИСО/МЭК 15408 или настоящем стандарте.

7.5.5.2.7 Сообщения о проблемах

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

Для каждого СП в перечне следует привести идентификатор СП, а также название или аннотацию.

7.5.5.3 ТОО при оценке ОО

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

Рисунок 5 - Содержание ТОО при оценке ОО

Рисунок 5 - Содержание ТОО при оценке ОО

7.5.5.3.1 Введение

Оценщик должен привести в отчете идентификаторы системы оценки.

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

Оценщик должен привести в отчете идентификаторы контроля конфигурации ТОО.

Идентификаторы контроля конфигурации ТОО содержат информацию, которая идентифицирует ТОО (например, название, дату составления и номер версии).

Оценщик должен привести в отчете идентификаторы контроля конфигурации ЗБ и ОО.

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

Если ЗБ содержит "Утверждения о соответствии" ОО требованиям одного или нескольких ПЗ, ТОО должен содержать ссылку на соответствующие ПЗ.

Ссылка на ПЗ содержит информацию, которая уникально идентифицирует ПЗ (например, название, дату составления и номер версии).

Оценщик должен привести в отчете идентификатор разработчика.

Идентификатор разработчика ОО требуется для идентификации стороны, ответственной за создание ОО.

Оценщик должен привести в отчете идентификатор заявителя.

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

Оценщик должен привести в отчете идентификатор оценщика.

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

7.5.5.3.2 Описание архитектуры ОО

Оценщик должен привести в отчете высокоуровневое "Описание ОО" и его главных компонентов, основанное на свидетельстве оценки, указанном в семействе доверия ИСО/МЭК 15408 "Проект ОО" (ADV_TDS), где оно применимо.

Назначение этого пункта состоит в указании степени архитектурного разделения главных компонентов. Если в ЗБ нет требований из семейства ADV_TDS "Проект ОО", этот пункт не применим и считается удовлетворенным.

7.5.5.3.3 Оценка

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

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

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

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

7.5.5.3.4 Результаты оценки

Для каждого вида деятельности по оценке ОО оценщик должен привести в отчете:

- название рассматриваемого вида деятельности;

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

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

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

Для видов деятельности AVA и ATE указываются шаги оценивания, которые определяют информацию, включаемую в ТОО.

7.5.5.3.5 Выводы и рекомендации

Оценщик должен привести в отчете выводы по результатам оценки об удовлетворении ОО требованиям своего ЗБ, в частности, общий вердикт в соответствии с разделом 9 "Результаты оценки" ИСО/МЭК 15408-1 и процедурой вынесения вердикта, описанной в пункте 7.2.5 настоящего стандарта.

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

7.5.5.3.6 Перечень свидетельств оценки

Оценщик должен привести в отчете следующую информацию о каждом свидетельстве оценки:

- о составителе свидетельства (например, разработчик, заявитель);

- о названии свидетельства;

- об уникальной ссылке на свидетельство (например, дата составления и номер версии).

7.5.5.3.7 Перечень сокращений/глоссарий терминов

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

В ТОО нет необходимости повторять определения глоссария, уже приведенные в ИСО/МЭК 15408 или настоящем стандарте.

7.5.5.3.8 Сообщения о проблемах

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

Для каждого СП в перечне следует привести идентификатор СП, а также название или аннотацию.

8 Класс АРЕ: Оценка профиля защиты

8.1 Введение

Этот раздел описывает оценку ПЗ. Требования и методология оценки ПЗ идентичны для каждой оценки ПЗ, независимо от ОУД (или другой совокупности требований доверия), заявленного в ПЗ. Методология оценки в этом разделе основана на требованиях к ПЗ, определенных в классе АРЕ из ИСО/МЭК 15408-3.

Данный раздел следует использовать вместе с приложениями А, В и С в ИСО/МЭК 15408-1, поскольку в этих приложениях разъясняются приведенные здесь понятия и приводятся многочисленные примеры.

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

8.2.1 Повторное использование результатов оценки сертифицированных ПЗ

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

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

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

a) ряд новых и/или измененных требований внутренне непротиворечив, и

b) все новые и/или измененные требования совместимы с исходными требованиями.

Оценщик отмечает в ТОО каждый случай, где исследования не сделаны или только частично сделаны по этой причине.

8.3 "Введение ПЗ" (APE_INT)

8.3.1 Подвид деятельности по оценке (APE_INT.1)

8.3.1.1 Цели

Цель этого подвида деятельности - сделать заключение о том, что ПЗ правильно идентифицирован и что "Ссылка на ПЗ" и "Аннотация ОО" не противоречат друг другу.

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

Свидетельством оценки для этого подвида деятельности является ПЗ.

8.3.1.3 Действие APE_INT.1.1E

ИСО/МЭК 15408-3 APE_INT.1.1С: "Введение ПЗ" должно содержать "Ссылку на ПЗ" и "Аннотацию ОО".

8.3.1.3.1 Шаг оценивания APE_INT.1-1

Оценщик должен проверить, представлены ли в разделе "Введение ПЗ" "Ссылка на ПЗ" и "Аннотация ОО".

ИСО/МЭК 15408-3 APE_INT.1.2С: "Ссылка на ПЗ" должна уникально идентифицировать ПЗ.

8.3.1.3.2 Шаг оценивания APE_INT.1-2

Оценщик должен исследовать "Ссылку на ПЗ" в целях определения того, что она уникально идентифицирует ПЗ.

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

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

ИСО/МЭК 15408-3 APE_INT.1.3С: В "Аннотации ОО" должна быть предоставлена краткая информация об использовании и основных функциональных возможностях безопасности ОО.

8.3.1.3.3 Шаг оценивания APE_INT.1-3

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

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

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

ИСО/МЭК 15408-3 APE_INT.1.4C: В "Аннотации ОО" должен быть идентифицирован тип ОО.

8.3.1.3.4 Шаг оценивания APE_INT.1-4

Оценщик должен проверить, идентифицирован ли в "Аннотации ОО" тип ОО.

ИСО/МЭК 15408-3 APE_INT.1.5C: В "Аннотации ОО" должны быть идентифицированы любые не входящие в ОО аппаратные, программные, а также программно-аппаратные средства, доступные для ОО.

8.3.1.3.5 Шаг оценивания APE_INT.1-5

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

В то время как некоторые ОО являются автономными, другим ОО (особенно если ОО является программным средством) для работы необходимы дополнительные аппаратные, программные или программно-аппаратные средства. В этом подразделе ПЗ автор ПЗ перечисляет все доступные аппаратные, программные или программно-аппаратные средства, которые могут быть запущены на ОО.

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

8.4 Утверждения о соответствии (APE_CCL)

8.4.1 Подвид деятельности по оценке (APE_CCL.1)

8.4.1.1 Цели

Цель этого подвида деятельности состоит в том, чтобы определить обоснованность различных утверждений о соответствии. Он описывает, каким образом ПЗ соответствует ИСО/МЭК 15408, другим ПЗ и пакетам требований.

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

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

a) ПЗ;

b) другие ПЗ, соответствие которым утверждается в ПЗ;

c) пакеты требований, соответствие которым утверждается в ПЗ.

8.4.1.3 Действие АРЕ_ССL.1.1Е

ИСО/МЭК 15408-3 АРЕ_ССL.1.1С: В "Утверждения о соответствии" должно быть включено "Утверждение о соответствии ИСО/МЭК 15408", которое определяет, для какой редакции ИСО/МЭК 15408 утверждается соответствие ПЗ.

8.4.1.3.1 Шаг оценивания АРЕ_ССL.1-1

Оценщик должен проверить, что в "Утверждения о соответствии" включено "Утверждение о соответствии ИСО/МЭК 15408", которое определяет, для какой редакции ИСО/МЭК 15408 должен соответствовать ПЗ.

Оценщик делает заключение о том, что "Утверждение о соответствии ИСО/МЭК 15408" идентифицирует редакцию ИСО/МЭК 15408, которая использовалась для разработки данного ПЗ. В "Утверждение" следует включать номер редакции ИСО/МЭК 15408 и, если не использовалась международная редакция ИСО/МЭК 15408 на английском языке, то в нем следует указать язык используемой редакции ИСО/МЭК 15408.

ИСО/МЭК 15408-3 APE_CCL.1.2C: В "Утверждении о соответствии ИСО/МЭК 15408" должно приводиться описание соответствия ПЗ ИСО/МЭК 15408-2; ПЗ либо описывается как соответствующий требованиям ИСО/МЭК 15408-2, либо как содержащий расширенные по отношению к ИСО/МЭК 15408-2 требования.

8.4.1.3.2 Шаг оценивания АРЕ_ССL.1-2

Оценщик должен проверить, что "Утверждение о соответствии ИСО/МЭК 15408" описывает соответствие ПЗ ИСО/МЭК 15408-2; ПЗ либо описывается как соответствующий требованиям ИСО/МЭК 15408-2, либо как содержащий расширенные по отношению к ИСО/МЭК 15408-2 требования.

ИСО/МЭК 15408-3 APE_CCL.1.3C: В "Утверждении о соответствии ИСО/МЭК 15408" должно приводиться описание соответствия ПЗ ИСО/МЭК 15408-3; ПЗ либо описывается как соответствующий требованиям ИСО/МЭК 15408-3, либо как содержащий расширенные по отношению к ИСО/МЭК 15408-3 требования.

8.4.1.3.3 Шаг оценивания АРЕ_ССL.1-3

Оценщик должен проверить, что "Утверждение о соответствии ИСО/МЭК 15408" описывает соответствие ПЗ ИСО/МЭК 15408-3; ПЗ либо описывается как соответствующий требованиям ИСО/МЭК 15408-3, либо как содержащий расширенные по отношению к ИСО/МЭК 15408-3 требования.

ИСО/МЭК 15408-3 APE_CCL.1.4C: "Утверждение о соответствии ИСО/МЭК 15408" должно согласовываться с "Определением расширенных компонентов".

8.4.1.3.4 Шаг оценивания АРЕ_ССL.1-4

Оценщик должен исследовать "Утверждение о соответствии ИСО/МЭК 15408-2" в целях вынесения заключения о его согласованности с "Определением расширенных компонентов".

Если "Утверждение о соответствии ИСО/МЭК 15408" в ПЗ содержит "Утверждение о соответствии ИСО/МЭК 15408-2", оценщик делает заключение о том, что "Определение расширенных компонентов" не определяет функциональные компоненты.

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

8.4.1.3.5 Шаг оценивания АРЕ_ССL.1-5

Оценщик должен исследовать "Утверждение о соответствии ИСО/МЭК 15408" в отношении ИСО/МЭК 15408-3 в целях вынесения заключения о его согласованности с "Определением расширенных компонентов".

Если "Утверждение о соответствии ИСО/МЭК 15408" содержит "Утверждение о соответствии ИСО/МЭК 15408-3", оценщик делает заключение о том, что "Определение расширенных компонентов" не определяет компоненты требований доверия.

Если "Утверждение о соответствии ИСО/МЭК 15408" содержит "Утверждение о соответствии расширению ИСО/МЭК 15408-3", оценщик делает заключение о том, что "Определение расширенных компонентов" определяет хотя бы один расширенный компонент доверия.

ИСО/МЭК 15408-3 АРЕ_ССL.1.5С: В "Утверждении о соответствии" должны быть идентифицированы все ПЗ и пакеты требований безопасности, о соответствии которым утверждается в ПЗ.

8.4.1.3.6 Шаг оценивания АРЕ_ССL.1-6

Оценщик должен проверить, что "Утверждения о соответствии" содержит "Утверждение о соответствии ПЗ", идентифицирующее все ПЗ, о соответствии которым утверждается в ПЗ.

Если в ПЗ не утверждается соответствие ПЗ другим ПЗ, то этот шаг оценивания не применим и считается удовлетворенным.

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

Оценщику следует помнить, что утверждения частичного соответствия ПЗ недопустимы.

8.4.1.3.7 Шаг оценивания АРЕ_ССL.1-7

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

Если в ПЗ не утверждается соответствие какому-либо пакету требований, то этот шаг оценивания не применим и считается удовлетворенным.

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

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

ИСО/МЭК 15408-3 APE_CCL.1.6C: В "Утверждении о соответствии ПЗ пакету требований" должно приводиться описание любого соответствия ПЗ некоторому пакету требований; ПЗ либо описывается как соответствующий пакету требований, либо как содержащий расширенные по отношению к пакету требования.

8.4.1.3.8 Шаг оценивания АРЕ_ССL.1-8

Оценщик должен проверить, что для каждого идентифицированного пакета "Утверждения о соответствии" содержит* утверждение либо о соответствии именованному пакету, либо о соответствии пакету, усиленному относительно именованного пакета.
_______________
* Текст документа соответствует оригиналу. - .

Если в ПЗ не утверждается о соответствии какому-либо пакету требований, то этот шаг оценивания не применим и считается удовлетворенным.

Если в "Утверждении о соответствии ПЗ пакету требований" содержится утверждение о соответствии именованному пакету, оценщик делает заключение о том, что:

a) Если пакет является пакетом требований доверия, то ПЗ содержит все ТДБ, включенные в пакет, но не содержит дополнительных ТДБ.

b) Если пакет является функциональным, то ПЗ содержит все ФТБ, включенные в пакет, но не содержит дополнительных ФТБ.

Если в "Утверждении о соответствии ПЗ пакету требований" содержится утверждение о соответствии расширенному пакету требований относительно именованного, оценщик делает заключение о том, что:

a) Если пакет является пакетом доверия, то ПЗ содержит все ТДБ, включенные в пакет, и по крайней мере одно дополнительное ТДБ или одно ТДБ, которое является иерархическим к ТДБ в пакете.

b) Если пакет является функциональным, то ПЗ содержит все ФТБ, включенные в пакет, и по крайней мере одно дополнительное ФТБ или одно ФТБ, которое является иерархическим к ФТБ в пакете.

ИСО/МЭК 15408-3 АРЕ_ССL.1.7С: В "Обосновании утверждений о соответствии" должно быть продемонстрировано, что тип ОО согласуется с типом ОО в тех ПЗ, о соответствии которым утверждается.

8.4.1.3.9 Шаг оценивания АРЕ_ССL.1-9

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

Если в ПЗ не утверждается о соответствии ПЗ другому ПЗ, то этот шаг оценивания не применим и считается удовлетворенным.

Отношение между типами может быть простым: например, в ПЗ межсетевого экрана утверждается о соответствии другому ПЗ межсетевого экрана, или более сложным: например в ПЗ смарт-карты утверждается о соответствии многим другим ПЗ одновременно - ПЗ интегральной схемы, ПЗ для ОС смарт-карты и двум ПЗ двух приложений на смарт-карте.

ИСО/МЭК 15408-3 АРЕ_ССL.1.8С: В "Обосновании утверждений о соответствии" должно быть продемонстрировано, что изложение определения проблемы безопасности согласуется с изложением определения проблемы безопасности тех ПЗ, о соответствии которым утверждается.

8.4.1.3.10 Шаг оценивания АРЕ_ССL.1-10

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

Если в оцениваемом ПЗ не утверждается о соответствии другим ПЗ, то этот шаг оценивания не применим и считается удовлетворенным.

Если в ПЗ, о соответствии которому утверждается, не включено изложение "Определения проблемы безопасности", то этот шаг оценивания не применим и считается удовлетворенным.

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

a) набор угроз в оцениваемом ПЗ расширенным или идентичным по отношению к перечню угроз в ПЗ, о соответствии которому утверждается;

b) набор ПБОр в оцениваемом ПЗ расширенным или идентичным по отношению к ПБОр в ПЗ, о соответствии которому утверждается;

с) набор предположений в оцениваемом ПЗ идентичным по отношению к предположениям в ПЗ, о соответствии которому утверждается.

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

В качестве руководства о том, что считать "эквивалентным или более ограничительным" изложением, см. ИСО/МЭК 15408-1 приложение D "Соответствие ПЗ".

ИСО/МЭК 15408-3 АРЕ_ССL.1.9С: В "Обосновании утверждений о соответствии" должно быть продемонстрировано, что изложение "Целей безопасности" согласуется с изложением "Целей безопасности" в тех ПЗ, о соответствии которым утверждается.

8.4.1.3.11 Шаг оценивания АРЕ_ССL.1-11

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

Если в ПЗ не утверждается о соответствии ПЗ другому ПЗ, то этот шаг оценивания не применим и считается удовлетворенным.

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

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

- оцениваемый ПЗ абсолютно все цели безопасности для среды функционирования (за одним исключением, которое описано в следующем абзаце). Следует отметить, что в оцениваемом ПЗ не допускается наличие дополнительных целей безопасности для среды функционирования;

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

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

В качестве руководства о том, что считать "эквивалентным или более ограничительным" изложением, см. ИСО/МЭК 15408-1 приложение D "Соответствие ПЗ".

ИСО/МЭК 15408-3 АРЕ_ССL.1.10С: В "Обосновании утверждений о соответствии" должно быть продемонстрировано, что изложение "Требований безопасности" согласуется с изложением "Требований безопасности" в тех ПЗ, о соответствии которым утверждается.

8.4.1.3.12 Шаг оценивания АРЕ_ССL.1-12

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

Если в ПЗ не утверждается о соответствии другому ПЗ, то этот шаг оценивания не применим и считается выполненным успешно.

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

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

В качестве руководства о том, что считать "эквивалентным или более ограничительным" изложением, см. ИСО/МЭК 15408-1 приложение D "Соответствие ПЗ".

ИСО/МЭК 15408-3 АРЕ_ССL.1.11С: "Изложение соответствия" должно содержать описание соответствия, требуемого любыми ПЗ/ЗБ данному профилю защиты в виде строгого или демонстрируемого соответствия.

8.4.1.3.13 Шаг оценивания АРЕ_ССL.1-13

Оценщик должен проверить, что изложение соответствия ПЗ содержит утверждение о строгом или демонстрируемом соответствии ПЗ.

8.5 Определение проблемы безопасности (APE_SPD)

8.5.1 Подвид деятельности по оценке (APE_SPD.1)

8.5.1.1 Цели

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

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

Свидетельством оценки для этого подвида деятельности является ПЗ.

8.5.1.3 Действие APE_SPD.1.1E

ИСО/МЭК 15408-3 APE_SPD.1.1С: "Определение проблемы безопасности" должно включать в себя описание угроз.

8.5.1.3.1 Шаг оценивания APE_SPD.1-1

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

Если все цели безопасности получены из предположений и/или только из ПБОр, изложение угроз не обязательно должно присутствовать в ПЗ. В этом случае этот шаг оценивания не применим и считается удовлетворенным.

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

ИСО/МЭК 15408-3 APE_SPD.1.2C: Описание всех угроз должно проводиться в терминах источника угрозы, активов и негативного воздействия.

8.5.1.3.2 Шаг оценивания APE_SPD.1-2

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

Если все цели безопасности получены из предположений и/или только из ПБОр, изложение угроз не обязательно должно присутствовать в ПЗ. В этом случае этот шаг оценивания не применим и считается удовлетворенным.

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

ИСО/МЭК 15408-3 APE_SPD.1.3C: В "Определение проблемы безопасности" должно быть включено описание ПБОр.

8.5.1.3.3 Шаг оценивания APE_SPD.1-3

Оценщик должен проверить, что "Определение проблемы безопасности" описывает ПБОр.

Если все цели безопасности получены из предположений и/или только из ПБОр, изложение угроз не обязательно должно присутствовать в ПЗ. В этом случае этот шаг оценивания не применим и считается удовлетворенным.

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

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

ИСО/МЭК 15408-3 APE_SPD.1.4C: "Определение проблемы безопасности" должно содержать описание предположений относительно среды функционирования ОО.

8.5.1.3.4 Шаг оценивания APE_SPD.1-4

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

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

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

8.6 Цели безопасности (APE_OBJ)

8.6.1 Подвид деятельности по оценке (APE_OBJ.1)

8.6.1.1 Цели

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

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

Свидетельством оценки для этого подвида деятельности является ПЗ.

8.6.1.3 Действие APE_OBJ.1.1E

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

8.6.1.3.1 Шаг оценивания APE_OBJ.1-1

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

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

8.6.2 Подвид деятельности по оценке (APE_OBJ.2)

8.6.2.1 Цели

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

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

Свидетельством оценки для этого подвида деятельности является ПЗ.

8.6.2.3 Действие APE_OBJ.2.1Е

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

8.6.2.3.1 Шаг оценивания APE_OBJ.2-1

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

Оценщик проверяет, что обе категории "Целей безопасности" ясно идентифицированы и отделены друг от друга.

ИСО/МЭК 15408-3 APE_OBJ.2.2C: В "Обосновании целей безопасности" каждая цель безопасности для ОО должна быть прослежена к угрозам, на противостояние которым направлена эта цель безопасности, и к ПБОр, на осуществление которых направлена эта цель безопасности.

8.6.2.3.2 Шаг оценивания APE_OBJ.2-2

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

Каждая цель безопасности для ОО может быть прослежена к угрозам или ПБОр или к комбинации угроз и ПБОр, но должна быть прослежена по крайней мере к одной угрозе или ПБОр.

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

ИСО/МЭК 15408-3 APE_OBJ.2.3C: В "Обосновании целей безопасности" каждая цель безопасности для ОО должна быть прослежена к угрозам, на противостояние которым направлена эта цель безопасности, к ПБОр, на осуществление которых направлена эта цель безопасности, а также к предположениям, поддерживаемым данной целью безопасности.

8.6.2.3.3 Шаг оценивания APE_OBJ.2-3

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

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

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

ИСО/МЭК 15408-3 APE_OBJ.2.4C: В "Обосновании целей безопасности" должно быть продемонстрировано, что цели безопасности направлены на противостояние всем идентифицированным угрозам.

8.6.2.3.4 Шаг оценивания APE_OBJ.2-4

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

Если ни одна цель безопасности не прослежена к конкретной угрозе, то результат данного шага оценивания отрицательный (выносится отрицательный вердикт).

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

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

Следует отметить, что прослеживание целей безопасности к угрозам в "Обосновании целей безопасности" может быть частью логического обоснования, но само по себе оно не является логическим обоснованием. Даже в том случае, когда цель безопасности является просто заявлением, отражающим намерение предотвратить реализацию конкретной угрозы, то все равно требуется логическое обоснование, хотя в этом случае оно может быть минимальным и иметь вид: "Цель безопасности X непосредственно противостоит Угрозе Y".

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

ИСО/МЭК 15408-3 APE_OBJ.2.5C: В "Обосновании целей безопасности" должно быть продемонстрировано, что цели безопасности направлены на осуществление всей ПБОр.

8.6.2.3.5 Шаг оценивания APE_OBJ.2-5

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

Если ни одна цель безопасности не прослежена к определенной ПБОр, то результат данного шага оценивания отрицательный (выносится отрицательный вердикт).

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

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

Следует отметить, что прослеживание целей безопасности к ПБОр в "Обосновании целей безопасности" может быть частью логического обоснования, но само по себе оно не является логическим обоснованием. Даже в том случае, когда цель безопасности является просто заявлением, отражающим намерение реализовать конкретную ПБОр, то все равно требуется логическое обоснование, хотя в этом случае оно может быть минимальным и иметь вид: "Цель безопасности X непосредственно обеспечивает осуществление ПБОр Y".

ИСО/МЭК 15408-3 APE_OBJ.2.6C: В "Обосновании целей безопасности" должно быть продемонстрировано, что цели безопасности для среды функционирования поддерживают все предположения.

8.6.2.3.6 Шаг оценивания APE_OBJ.2-6

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

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

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

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

Следует отметить, что прослеживание целей безопасности для среды функционирования к предположениям в "Обосновании целей безопасности" может быть частью логического обоснования, но само по себе оно не является логическим обоснованием. Даже в том случае, когда цель безопасности для среды функционирования представляет собой просто перефразированное предположение, то все равно требуется логическое обоснование, хотя в этом случае оно может быть минимальным и иметь вид: "Цель безопасности X непосредственно поддерживает выполнение Предположения Y".

8.7 Определение расширенных компонентов (APE_ECD)

8.7.1 Подвид деятельности по оценке (APE_ECD.1)

8.7.1.1 Цели

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

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

Свидетельством оценки для этого подвида деятельности является ПЗ.

8.7.1.3 Действие APE_ECD.1.1E

ИСО/МЭК 15408-3 APE_ECD.1.1С: В изложении "Требований безопасности" должны быть идентифицированы все расширенные требования безопасности.

8.7.1.3.1 Шаг оценивания APE_ECD.1-1

Оценщик должен проверить, что все требования безопасности в изложении "Требований безопасности", которые не идентифицированы как расширенные требования, присутствуют в ИСО/МЭК 15408-2 или в ИСО/МЭК 15408-3.

ИСО/МЭК 15408-3 APE_ECD.1.2C: В "Определении расширенных компонентов" должен определяться расширенный компонент для каждого расширенного требования безопасности.

8.7.1.3.2 Шаг оценивания APE_ECD.1-2

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

Если ПЗ не содержит расширенные требования безопасности, то этот шаг оценивания не применим и считается удовлетворенным.

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

ИСО/МЭК 15408-3 APE_ECD.1.3C: В "Определении расширенных компонентов" должно указываться, как каждый расширенный компонент связан с существующими компонентами, семействами и классами ИСО/МЭК 15408.

8.7.1.3.3 Шаг оценивания APE_ECD.1-3

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

Если ПЗ не содержит расширенные требования безопасности, то этот шаг оценивания не применим и считается удовлетворенным.

Оценщик делает заключение о том, что каждый расширенный компонент является:

a) компонентом семейства ИСО/МЭК 15408-2 или ИСО/МЭК 15408-3, или

b) компонентом нового семейства, определенного в ПЗ.

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

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

Если в ПЗ определяются новые семейства, оценщик делает заключение о том, что каждое новое семейство является либо:

a) семейством существующего класса ИСО/МЭК 15408-2 или ИСО/МЭК 15408-3, или

b) семейством нового класса, определенного в ПЗ.

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

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

8.7.1.3.4 Шаг оценивания APE_ECD.1-4

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

Если ПЗ не содержит расширенные требования безопасности, то этот шаг оценивания не применим и считается удовлетворенным.

Оценщик подтверждает, что никакие применимые зависимости не были пропущены автором ПЗ.

ИСО/МЭК 15408-3 APE_ECD.1.4C: В "Определении расширенных компонентов" в качестве модели представления должны использоваться компоненты, семейства, классы и методология ИСО/МЭК 15408.

8.7.1.3.5 Шаг оценивания APE_ECD.1-5

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

Если ПЗ не содержит расширенные функциональные требования безопасности, то этот шаг оценивания не применим и считается удовлетворенным.

Оценщик делает заключение о том, что расширенный функциональный компонент согласуется с пунктом 6.1.3 "Структура компонента" ИСО/МЭК 15408-2.

Если в расширенном функциональном компоненте используются операции, оценщик делает заключение о том, что расширенный функциональный компонент согласуется с подразделом 7.1 "Операции" ИСО/МЭК 15408-1.

Если расширенный функциональный компонент находится в иерархической зависимости по отношению к существующему функциональному компоненту, оценщик делает заключение о том, что расширенный функциональный компонент согласуется с пунктом 6.2.1 "Выделение изменений в компоненте" ИСО/МЭК 15408-2.

8.7.1.3.6 Шаг оценивания APE_ECD.1-6

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

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

Оценщик делает заключение о том, что все новые функциональные семейства совместимы с пунктом 6.1.2 "Структура семейства" ИСО/МЭК 15408-2.

8.7.1.3.7 Шаг оценивания APE_ECD.1-7

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

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

Оценщик делает заключение о том, что все новые функциональные классы согласуются с пунктом 6.1.1 "Структура класса" ИСО/МЭК 15408-2.

8.7.1.3.8 Шаг оценивания APE_ECD.1-8

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

Если в ПЗ не содержатся расширенные требования доверия к безопасности, то этот шаг оценивания не применим и считается удовлетворенным.

Оценщик делает заключение о том, что "Определение расширенных компонентов" согласуется с пунктом 6.1.3 "Структура компонента" ИСО/МЭК 15408-3.

Если в расширенном компоненте доверия используются операции, оценщик делает заключение о том, что расширенный компонент доверия согласуется с подразделом 7.1 "Операции" ИСО/МЭК 15408-1.

Если расширенный компонент доверия находится в иерархической зависимости по отношению к существующему компоненту доверия, оценщик делает заключение о том, что расширенный компонент доверия согласуется с пунктом 6.1.3 "Структура компонента" ИСО/МЭК 15408-3.

8.7.1.3.9 Шаг оценивания APE_ECD.1-9

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

Если ПЗ не содержит расширенные требования доверия к безопасности, то этот шаг оценивания не применим и считается удовлетворенным.

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

8.7.1.3.10 Шаг оценивания APE_ECD.1-10

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

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

Оценщик делает заключение о том, что все новые семейства доверия совместимы с пунктом 6.1.2 "Структура семейства" ИСО/МЭК 15408-3.

8.7.1.3.11 Шаг оценивания APE_ECD.1-11

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

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

Оценщик делает заключение о том, что все новые классы доверия согласуются с пунктом 6.1.1 "Структура класса" ИСО/МЭК 15408-3.

ИСО/МЭК 15408-3 APE_ECD.1.5C: Расширенные компоненты должны состоять из измеримых объективных элементов, чтобы была возможность продемонстрировать соответствие или несоответствие этим элементам.

8.7.1.3.12 Шаг оценивания APE_ECD.1-12

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

Если ПЗ не содержит расширенные требования безопасности, то этот шаг оценивания не применим и считается удовлетворенным.

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

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

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

8.7.1.4 Действие APE_ECD.1.2E

8.7.1.4.1 Шаг оценивания APE_ECD.1-13

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

Если ПЗ не содержит расширенные требования доверия к безопасности, этот шаг оценивания не применим, и считается удовлетворенным.

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

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

8.8 Требования безопасности (APE_REQ)

8.8.1 Подвид деятельности по оценке (APE_REQ.1)

8.8.1.1 Цели

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

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

Свидетельством оценки для этого подвида деятельности является ПЗ.

8.8.1.3 Действие APE_REQ.1.1E

ИСО/МЭК 15408-3 APE_REQ.1.1C: Изложение "Требований безопасности" должно содержать описание ФТБ и ТДБ.

8.8.1.3.1 Шаг оценивания APE_REQ.1-1

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

Оценщик делает заключение о том, что каждое ФТБ идентифицировано одним из следующих способов:

a) ссылкой на конкретный компонент ИСО/МЭК 15408-2;

b) ссылкой на расширенный компонент в "Определении расширенных компонентов" ПЗ;

c) ссылкой на ПЗ, о соответствии с которым утверждается в ПЗ;

d) ссылкой на пакет требований безопасности, о соответствии с которым утверждается в ПЗ;

e) с помощью воспроизведения в ПЗ.

Не обязательно использовать одинаковые способы идентификации для всех ФТБ.

8.8.1.3.2 Шаг оценивания APE_REQ.1-2

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

Оценщик делает заключение о том, что каждое ТДБ идентифицировано одним из следующих способов:

a) ссылкой на конкретный компонент ИСО/МЭК 15408-3;

b) ссылкой на расширенный компонент в "Определении расширенных компонентов" ПЗ;

c) ссылкой на ПЗ, о соответствии с которым утверждается в ПЗ;

d) ссылкой на пакет требований безопасности, о соответствии с которым утверждается в ПЗ;

e) с помощью воспроизведения отображения в ПЗ.

Не обязательно использовать одинаковые способы идентификации для всех ТДБ.

ИСО/МЭК 15408-3 APE_REQ.1.2C: Все субъекты, объекты, операции, атрибуты безопасности, внешние сущности и другие понятия, используемые в ФТБ и ТДБ, должны быть определены.

8.8.1.3.3 Шаг оценивания APE_REQ.1-3

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

Оценщик делает заключение о том, что ПЗ определяет все:

- субъекты и объекты (их типы), которые используются в ФТБ;

- атрибуты безопасности (их типы) субъектов, пользователей, объектов, информации, сеансов и/или ресурсов, возможные значения, которые могут принимать данные атрибуты и любые отношения между этими значениями (например, "Совершенно секретно" выше, чем "Секретно");

- операции (их типы), которые используются в ФТБ, включая результаты выполнения этих операций;

- типы внешних сущностей в ФТБ;

- прочие элементы, которые введены в ФТБ и/или ТДБ путем выполнения операций, если эти элементы не являются ясными без дополнительного объяснения или используются вне их словарных значений.

Цель этого шага оценивания состоит в том, чтобы удостовериться, что ФТБ и ТДБ были четко определены и что не может произойти их неправильного понимания из-за употребления неопределенных терминов. При выполнении этого шага оценивания не следует доходить до крайностей, вынуждая автора ПЗ определять каждое слово. Предполагается, что у широкой аудитории, на которую рассчитан набор требований безопасности, есть понимание ИТ в целом, основ информационной безопасности и знание "Критериев оценки безопасности информационных технологий".

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

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

ИСО/МЭК 15408-3 APE_REQ.1.3C: В изложении "Требований безопасности" должны быть идентифицированы все выполняемые над требованиями безопасности операции.

8.8.1.3.4 Шаг оценивания APE_REQ.1-4

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

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

ИСО/МЭК 15408-3 APE_REQ.1.4C: Все операции должны выполняться правильно.

8.8.1.3.5 Шаг оценивания APE_REQ.1-5

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

Руководство по правильному выполнению операций представлено в приложении С "Руководство по выполнению операций" ИСО/МЭК 15408-1.

8.8.1.3.6 Шаг оценивания APE_REQ.1-6

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

Руководство по правильному выполнению операций представлено в приложении С "Руководство по выполнению операций" ИСО/МЭК 15408-1.

8.8.1.3.7 Шаг оценивания APE_REQ.1-7

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

Руководство по правильному выполнению операций представлено в приложении С "Руководство по выполнению операций" ИСО/МЭК 15408-1.

8.8.1.3.8 Шаг оценивания APE_REQ.1-8

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

Руководство по правильному выполнению операций представлено в приложении С "Руководство по выполнению операций" ИСО/МЭК 15408-1.

ИСО/МЭК 15408-3 APE_REQ.1.5C: Каждая зависимость от "Требований безопасности" должна быть либо удовлетворена, либо должно приводиться обоснование неудовлетворения данной зависимости.

8.8.1.3.9 Шаг оценивания APE_REQ.1-9

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

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

В логическом обосновании того, что зависимость не удовлетворена, следует указывать либо:

a) почему зависимость не является полезной или необходимой, в этом случае не требуется предоставлять дополнительную информацию; либо

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

ИСО/МЭК 15408-3 APE_REQ.1.6C: Изложение "Требований безопасности" должно быть внутренне непротиворечивым.

8.8.1.3.10 Шаг оценивания APE_REQ.1-10

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

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

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

Некоторые примеры возможных конфликтов:

a) расширенное ТДБ определяет, что проект некоторого криптографического алгоритма должен содержаться в секрете, а другое расширенное ТДБ предписывает свободный доступ к просмотру его исходных кодов;

b) компонент FAU_GEN.1 "Генерация данных аудита безопасности" определяет, что идентификатор субъекта должен регистрироваться в журнале; компонент FDP_ACC.1 "Ограниченное управление доступом" определяет, кто имеет права доступа к этим журналам, а компонент FPR_UNO.1 "Скрытность" определяет, что не рекомендуется, чтобы некоторые действия субъектов были доступны для просмотра другим субъектам. Если субъект, которому не следует иметь возможность видеть действия других субъектов, может получить доступ к журналам регистрации данных действий, эти ФТБ являются конфликтующими;

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

d) многократные итерации компонента FDP_ACC.1 "Ограниченное управление доступом", особенно если некоторые итерации касаются одних и тех же субъектов, объектов или операций. Если одно ФТБ по управлению доступом позволяет субъекту выполнять операцию над объектом, тогда как другое ФТБ по управлению доступом не позволяет это, эти требования являются конфликтующими.

8.8.2 Подвид деятельности по оценке (APE_REQ.2)

8.8.2.1 Цели

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

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

Свидетельством оценки для этого подвида деятельности является ПЗ.

8.8.2.3 Действие APE_REQ.2.1E

ИСО/МЭК 15408-3 APE_REQ.2.1С: Изложение "Требований безопасности" должно содержать описание ФТБ и ТДБ.

8.8.2.3.1 Шаг оценивания APE_REQ.2-1

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

Оценщик делает заключение о том, что каждое ФТБ идентифицировано одним из следующих способов:

a) ссылкой на конкретный компонент ИСО/МЭК 15408-2;

b) ссылкой на расширенный компонент в "Определении расширенных компонентов" ПЗ;

c) ссылкой на конкретный компонент ПЗ, о соответствии с которым утверждается в ПЗ;

d) ссылкой на конкретный компонент в пакете требований безопасности, о соответствии с которым утверждается в ПЗ;

e) с помощью воспроизведения в ПЗ.

Не обязательно использовать одинаковые способы идентификации для всех ФТБ.

8.8.2.3.2 Шаг оценивания APE_REQ.2-2

Оценщик должен проверить, что изложение "Требований безопасности" содержит описание требований доверия к безопасности.

Оценщик делает заключение о том, что каждое ТДБ идентифицировано одним из следующих способов:

a) ссылкой на конкретный компонент ИСО/МЭК 15408-3;

b) ссылкой на расширенный компонент в "Определении расширенных компонентов" ПЗ;

c) ссылкой на конкретный компонент ПЗ, о соответствии с которым утверждается в ПЗ;

d) ссылкой на конкретный компонент в пакете требований безопасности, о соответствии с которым утверждается в ПЗ;

e) с помощью воспроизведения в ПЗ.

Не обязательно использовать одинаковые способы идентификации для всех ТДБ.

ИСО/МЭК 15408-3 APE_REQ.2.2C: Все субъекты, объекты, операции, атрибуты безопасности, внешние сущности и другие понятия, используемые в ФТБ и ТДБ, должны быть определены.

8.8.2.3.3 Шаг оценивания APE_REQ.2-3

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

Оценщик делает заключение о том, что ПЗ определяет все:

- субъекты и объекты (их типы), используемые в ФТБ;

- атрибуты безопасности субъектов (их типы), пользователей, объектов, информации, сеансов и/или ресурсов, возможные значения, которые могут принимать данные атрибуты и любые отношения между этими значениями (например, "Совершенно секретно" выше, чем "Секретно");

- операции (их типы), которые используются в ФТБ, включая результаты выполнения этих операций;

- внешние сущности (их типы) в ФТБ;

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

Цель этого шага оценивания состоит в том, чтобы удостовериться, что ФТБ и ТДБ четко определены и что не может произойти их неправильного понимания из-за употребления неопределенных терминов. При выполнении этого шага оценивания не следует доходить до крайностей, вынуждая автора ПЗ определять каждое слово. Предполагается, что у широкой аудитории, на которую рассчитан набор требований безопасности, есть понимание ИТ в целом, основ информационной безопасности и знание "Критериев оценки безопасности информационных технологий".

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

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

ИСО/МЭК 15408-3 APE_REQ.2.3C: В изложении "Требований безопасности" должны быть идентифицированы все операции над требованиями безопасности.

8.8.2.3.4 Шаг оценивания APE_REQ.2-4

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

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

ИСО/МЭК 15408-3 APE_REQ.2.4C: Все операции должны быть выполнены правильно.

8.8.2.3.5 Шаг оценивания APE_REQ.2-5

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

Руководство по правильному выполнению операций представлено в приложении С "Руководство по выполнению операций" ИСО/МЭК 15408-1.

8.8.2.3.6 Шаг оценивания APE_REQ.2-6

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

Руководство по правильному выполнению операций представлено в приложении С "Руководство по выполнению операций" ИСО/МЭК 15408-1.

8.8.2.3.7 Шаг оценивания APE_REQ.2-7

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

Руководство по правильному выполнению операций представлено в приложении С "Руководство по выполнению операций" ИСО/МЭК 15408-1.

8.8.2.3.8 Шаг оценивания APE_REQ.2-8

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

Руководство по правильному выполнению операций представлено в приложении С "Руководство по выполнению операций" ИСО/МЭК 15408-1.

ИСО/МЭК 15408-3 APE_REQ.2.5C: Каждая зависимость от "Требований безопасности" должна быть либо удовлетворена, либо должно приводиться обоснование неудовлетворения зависимости.

8.8.2.3.9 Шаг оценивания APE_REQ.2-9

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

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

В логическом обосновании того, что зависимость не удовлетворена, следует указать либо:

a) почему зависимость не является полезной или необходимой, в этом случае не требуется предоставлять дополнительную информацию; либо

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

ИСО/МЭК 15408-3 APE_REQ.2.6C: В "Обосновании требований безопасности" должно быть представлено прослеживание соответствия каждого ФТБ к целям безопасности для ОО.

8.8.2.3.10 Шаг оценивания APE_REQ.2-10

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

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

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

ИСО/МЭК 15408-3 APE_REQ.2.7C: В "Обосновании требований безопасности" должно быть продемонстрировано, что ФТБ обеспечивают выполнение всех целей безопасности для ОО.

8.8.2.3.11 Шаг оценивания APE_REQ.2-11

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

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

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

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

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

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

ИСО/МЭК 15408-3 APE_REQ.2.8C: В "Обосновании требований безопасности" должно приводиться пояснение того, почему выбраны определенные ТДБ.

8.8.2.3.12 Шаг оценивания APE_REQ.2-12

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

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

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

ИСО/МЭК 15408-3 APE_REQ.2.9C: Изложение "Требований безопасности" должно быть внутренне непротиворечивым.

8.8.2.3.13 Шаг оценивания APE_REQ.2-13

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

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

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

Некоторые примеры возможных конфликтов:

a) расширенное ТДБ определяет, что проект некоторого криптографического алгоритма должен содержаться в секрете, а другое расширенное ТДБ предписывает свободный доступ к просмотру его исходных кодов;

b) компонент FAU_GEN.1 "Генерация данных аудита безопасности" определяет, что идентификатор субъекта должен регистрироваться в журнале; компонент FDP_ACC.1 "Ограниченное управление доступом" определяет, кто имеет права доступа к этим журналам, а компонент FPR_UNO.1 "Скрытность" определяет, что не рекомендуется, чтобы некоторые действия субъектов были доступны для просмотра другим субъектам. Если субъект, которому не следует иметь возможность видеть действия других субъектов, может получить доступ к журналам регистрации данных действий, эти ФТБ являются конфликтующими;

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

d) многократные итерации компонента FDP_ACC.1 "Ограниченное управление доступом", особенно если некоторые итерации касаются одних и тех же субъектов, объектов или операций. Если одно ФТБ по управлению доступом позволяет субъекту выполнять операцию над объектом, тогда как другое ФТБ по управлению доступом не позволяет это, эти требования являются конфликтующими.

9 Класс ASE: Оценка задания по безопасности

9.1 Введение

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

Методология оценки в этом разделе основана на требованиях к ЗБ, определенных в классе ASE "Оценка ЗБ" из ИСО/МЭК 15408-3.

Данный раздел следует использовать вместе с приложениями А, В и С в ИСО/МЭК 15408-1, поскольку в этих приложениях разъясняются приведенные здесь понятия и приводятся многочисленные примеры.

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

9.2.1 Использование результатов оценки сертифицированных ПЗ

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

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

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

a) набор новых и/или измененных требований внутренне непротиворечив, и

b) набор всех новых и/или измененных требований не противоречит исходным требованиям.

Оценщик отмечает в ТОО каждый случай, где исследования не сделаны или сделаны только частично по этой причине.

9.3 Введение ЗБ (ASE_INT)

9.3.1 Подвид деятельности по оценке (ASE_INT.1)

9.3.1.1 Цели

Цель этого подвида деятельности - сделать заключение о том, правильно ли идентифицированы ЗБ и ОО, правильно ли описан ОО по трем уровням представления ("Ссылка на ОО", "Аннотация ОО" и "Описание ОО") и согласованы ли данные описания друг с другом.

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

Свидетельством оценки для этого подвида деятельности является ЗБ.

9.3.1.3 Действие ASE_INT.1.1E

ИСО/МЭК 15408-3 ASE_INT.1.1С: "Введение ЗБ" должно содержать "Ссылку на ЗБ", "Ссылку на ОО", "Аннотацию ОО" и "Описание ОО".

9.3.1.3.1 Шаг оценивания ASE_INT.1-1

Оценщик должен проверить, содержит ли "Введение ЗБ" "Ссылку на ЗБ", "Ссылку на ОО", "Аннотацию ОО" и "Описание ОО".

ИСО/МЭК 15408-3 ASE_INT.1.2C: "Ссылка на ЗБ" должна однозначно идентифицировать ЗБ.

9.3.1.3.2 Шаг оценивания ASE_INT.1-2

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

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

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

ИСО/МЭК 15408-3 ASE_INT.1.3C: "Ссылка на ОО" должна однозначно идентифицировать ОО.

9.3.1.3.3 Шаг оценивания ASE_INT.1-3

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

Оценщик выносит заключение о том, что "Ссылка на ОО" идентифицирует ОО так, что ясно, к какому ОО относится ЗБ, и что она идентифицирует версию ОО, например благодаря включению номера версии/даты выпуска/создания.

9.3.1.3.4 Шаг оценивания ASE_INT.1-4

Оценщик должен исследовать "Ссылку на ОО", чтобы сделать заключение о том, что она не вводит в заблуждение.

Если ОО связан с одним или более широко известными продуктами, допускается отразить этот факт в "Ссылке на ОО". Однако это не следует использовать для введения пользователей в заблуждение: не позволяется допускать ситуации, когда в "Ссылке на ОО" не отражено, что оценена только небольшая часть продукта.

ИСО/МЭК 15408-3 ASE_INT.1.4C: В "Аннотации ОО" должна быть представлена краткая информация о его использовании и основных функциональных возможностях безопасности ОО.

9.3.1.3.5 Шаг оценивания ASE_INT.1-5

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

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

В "Аннотации ОО" в ЗБ для составных ОО следует представить описание использования и основных характеристик безопасности для составного ОО, а не для отдельных ОО в его составе.

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

ИСО/МЭК 15408-3 ASE_INT.1.5C: В "Аннотации ОО" должен быть идентифицирован тип ОО.

9.3.1.3.6 Шаг оценивания ASE_INT.1-6

Оценщик должен проверить, идентифицирован ли в "Аннотации ОО" тип ОО.

9.3.1.3.7 Шаг оценивания ASE_INT.1-7

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

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

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

ИСО/МЭК 15408-3 ASE_INT.1.6C: В "Аннотации ОО" должны быть идентифицированы любые не входящие в ОО аппаратные, программные, а также программно-аппаратные средства, требуемые ОО.

9.3.1.3.8 Шаг оценивания ASE_INT.1-8

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

В то время как некоторые ОО являются автономными, другим ОО (особенно если ОО является программным средством) для работы необходимы дополнительные аппаратные, программные или программно-аппаратные средства. Если ОО не требуется каких-либо аппаратных, программных, программно-аппаратных средств, этот шаг оценивания не применим и считается удовлетворенным.

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

ИСО/МЭК 15408-3 ASE_INT.1.7С: "Описание ОО" должно включать описание физических границ ОО.

9.3.1.3.9 Шаг оценивания ASE_INT.1-9

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

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

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

ИСО/МЭК 15408-3 ASE_INT.1.8С: "Описание ОО" должно включать описание логических границ ОО.

9.3.1.3.10 Шаг оценивания ASE_INT.1-10

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

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

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

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

9.3.1.4 Действие ASE_INT.1.2E

9.3.1.4.1 Шаг оценивания ASE_INT.1-11

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

9.4 Утверждения о соответствии (ASE_CCL)

9.4.1 Подвид деятельности по оценке (ASE_CCL.1)

9.4.1.1 Цели

Цель этого подвида деятельности состоит в том, чтобы определить правомерность различных утверждений о соответствии. Он описывает, каким образом ЗБ и ОО соответствует ИСО/МЭК 15408, и как ЗБ соответствует ПЗ и пакетам требований.

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

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

a) ЗБ;

b) другие ПЗ, о соответствии которым утверждается в ЗБ;

c) пакеты требований, о соответствии которым утверждается в ЗБ.

9.4.1.3 Действие ASE_CCL.1.1E

ИСО/МЭК 15408-3 ASE_CCL.1.1C: В "Утверждения о соответствии" должно быть включено "Утверждение о соответствии ИСО/МЭК 15408", которое определяет, для какой редакции ИСО/МЭК 15408 утверждается соответствие ЗБ и ОО.

9.4.1.3.1 Шаг оценивания ASE_CCL.1-1

Оценщик должен проверить, что в "Утверждении о соответствии" включено "Утверждение о соответствии ИСО/МЭК 15408", которое определяет, для какой редакции ИСО/МЭК 15408 утверждается о соответствии в ЗБ и ОО.

Оценщик делает заключение о том, что в "Утверждении о соответствии ИСО/МЭК 15408" идентифицируется редакция ИСО/МЭК 15408, которая использовалась для разработки данного ЗБ. В "Утверждение" следует включать номер редакции ИСО/МЭК 15408 и, если не использовалась международная редакция стандарта ИСО/МЭК 15408 на английском языке, то в нем должен быть указан язык используемой редакции ИСО/МЭК 15408.

Для составного ОО оценщик должен рассмотреть любые отличия между редакцией ИСО/МЭК 15408, о соответствии которой утверждается в ОО-компоненте, и редакцией ИСО/МЭК 15408, о соответствии которой утверждается в составном ОО. Если редакции отличаются, оценщик должен определить, приведут ли различия между редакциями к противоречивым утверждениям.

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

ИСО/МЭК 15408-3 ASE_CCL.1.2C: В "Утверждении о соответствии ИСО/МЭК 15408" должно приводиться описание соответствия ЗБ ИСО/МЭК 15408-2; ЗБ либо описывается как соответствующее требованиям ИСО/МЭК 15408-2, либо как содержащее расширенные по отношению к ИСО/МЭК 15408-2 требования.

9.4.1.3.2 Шаг оценивания ASE_CCL.1-2

Оценщик должен проверить, что "Утверждение о соответствии ИСО/МЭК 15408" описывает соответствие ЗБ ИСО/МЭК 15408-2; ЗБ либо описывается как соответствующее требованиям ИСО/МЭК 15408-2, либо как содержащее расширенные по отношению к ИСО/МЭК 15408-2 требования.

Для составного ОО оценщик рассматривает, совместимо ли "Утверждение о соответствии" не только с ИСО/МЭК 15408-2, но и с "Утверждениями о соответствии ИСО/МЭК 15408-2" каждого из ОО-компонентов составного ОО. Т.е. если в одном или более ОО-компонентах утверждается, что ЗБ содержит расширенные по отношению к ИСО/МЭК 15408-2 требования, то и в составном ОО тоже следует приводить утверждение о соответствии расширению относительно ИСО/МЭК 15408-2.

"Утверждение о соответствии ИСО/МЭК 15408" для составного ОО может включать утверждение о соответствии расширению ИСО/МЭК 15408-2, даже если ОО-компоненты соответствуют ИСО/МЭК 15408-2, в случае, если к базовому ОО предъявляются расширенные ФТБ (см. Руководство по составным ОО для ASE_CCL.1.6C).

ИСО/МЭК 15408-3 ASE_CCL.1.3C: В "Утверждении о соответствии ИСО/МЭК 15408" должно приводиться описание соответствия ПЗ ИСО/МЭК 15408-3; ЗБ либо описывается как соответствующее требованиям ИСО/МЭК 15408-3, либо как содержащее расширенные по отношению к ИСО/МЭК 15408-3 требования.

9.4.1.3.3 Шаг оценивания ASE_CCL.1-3

Оценщик должен проверить, что в "Утверждении о соответствии ИСО/МЭК 15408" в ЗБ описывает соответствие ЗБ ИСО/МЭК 15408-3; ЗБ либо описывается как соответствующее требованиям ИСО/МЭК 15408-3, либо как содержащее расширенные по отношению к ИСО/МЭК 15408-3 требования.

ИСО/МЭК 15408-3 ASE_CCL.1.4C: "Утверждение о соответствии ИСО/МЭК 15408" должно согласовываться с "Определением расширенных компонентов".

9.4.1.3.4 Шаг оценивания ASE_CCL.1-4

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

Если в "Утверждении о соответствии ИСО/МЭК 15408" указывается о соответствии ИСО/МЭК 15408-2, оценщик делает заключение о том, что "Определение расширенных компонентов" не определяет функциональные компоненты.

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

9.4.1.3.5 Шаг оценивания ASE_CCL.1-5

Оценщик должен исследовать "Утверждение о соответствии ИСО/МЭК 15408" в отношении ИСО/МЭК 15408-3, чтобы сделать заключение о его согласованности с "Определением расширенных компонентов".

Если в "Утверждении о соответствии ИСО/МЭК 15408" указывается о соответствии ИСО/МЭК 15408-3, оценщик делает заключение о том, что "Определение расширенных компонентов" не определяет компоненты требований доверия.

Если в "Утверждении о соответствии ИСО/МЭК 15408" указывается о соответствии расширению ИСО/МЭК 15408-3, оценщик делает заключение о том, что "Определение расширенных компонентов" определяет хотя бы один расширенный компонент требований доверия.

ИСО/МЭК 15408-3 ASE_CCL.1.5C: В "Утверждении о соответствии" должны быть идентифицированы все ПЗ и пакеты требований безопасности, о соответствии которым утверждается в ЗБ.

9.4.1.3.6 Шаг оценивания ASE_CCL.1-6

Оценщик должен проверить, что в "Утверждении о соответствии" содержится "Утверждение о соответствии ПЗ", идентифицирующее все ПЗ, о соответствии которым утверждается в ЗБ.

Если в ЗБ не утверждается о соответствии ПЗ, то этот шаг оценивания не применим и считается удовлетворенным.

Оценщик делает заключение о том, что все ПЗ, на которые имеется ссылка, однозначно идентифицированы (например, названием и номером версии или идентификацией, включенной во введение этого ПЗ).

Оценщику следует помнить, что утверждения о частичном соответствии ПЗ недопустимы. Поэтому, соответствие ПЗ, требующее составного решения, может быть указано в ЗБ для составного ОО. Соответствие такому ПЗ не было бы возможно в процессе оценки ОО-компонентов, так как такие ОО не удовлетворяют составному решению. Возможность такого соответствия будет иметься только в тех случаях, когда "составной" ПЗ допускает использование подхода к оценке композиции (использование компонентов класса АСО "Композиция").

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

9.4.1.3.7 Шаг оценивания ASE_CCL.1-7

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

Если в ЗБ не утверждается о соответствии ЗБ какому-либо пакету требований, то этот шаг оценивания не применим и считается удовлетворенным.

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

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

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

ИСО/МЭК 15408-3 ASE_CCL.1.6C: В "Утверждении о соответствии ЗБ пакету требований" должно приводиться описание любого соответствия ЗБ некоторому пакету требований; ЗБ либо описывается как соответствующее пакету требований, либо как содержащее расширенные по отношению к пакету требования.

9.4.1.3.8 Шаг оценивания ASE_CCL.1-8

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

Если в ЗБ не утверждается о соответствии ЗБ какому-либо пакету требований, то этот шаг оценивания не применим и считается удовлетворенным.

Если в утверждении о соответствии пакетам содержится утверждение о соответствии именованному пакету, оценщик делает заключение о том, что:

а) если пакет является пакетом требований доверия, то ЗБ содержит все ТДБ, включенные в пакет, но не содержит дополнительных ТДБ.

b) если пакет является функциональным, то ЗБ содержит все ФТБ, включенные в пакет, но не содержит дополнительных ФТБ.

Если в утверждении о соответствии пакетам содержится утверждение о соответствии расширению относительно именованного пакета, оценщик делает заключение о том, что:

a) если пакет является пакетом требований доверия, то ЗБ содержит все ТДБ, включенные в пакет, и по крайней мере одно дополнительное ТДБ или по крайней мере одно ТДБ, которое является иерархическим к ТДБ в пакете.

b) если пакет является функциональным, то ЗБ содержит все включенные в пакет ФТБ, и по крайней мере одно дополнительное ФТБ, или по крайней мере одно ФТБ, которое является иерархическим к ФТБ в пакете.

ИСО/МЭК 15408-3 ASE_CCL.1.7C: В "Обосновании утверждений о соответствии" должно быть продемонстрировано, что тип ОО согласуется с типом ОО в тех ПЗ, о соответствии которым утверждается.

9.4.1.3.9 Шаг оценивания ASE_CCL.1-9

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

Если в ЗБ не утверждается о соответствии ПЗ, то этот шаг оценивания не применим и считается удовлетворенным.

Отношение между типами может быть простым: например, в ЗБ межсетевого экрана утверждается о соответствии некоторому ПЗ межсетевого экрана, или более сложным: например, в ЗБ смарт-карты утверждается о соответствии нескольким ПЗ одновременно - ПЗ интегральной схемы, ПЗ для ОС смарт-карты, и двум ПЗ двух приложений на смарт-карте.

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

ИСО/МЭК 15408-3 ASE_CCL.1.8C: В "Обосновании утверждений о соответствии" должно быть продемонстрировано, что изложение определения проблемы безопасности согласуется с изложением определения проблемы безопасности в тех ПЗ, о соответствии которым утверждается.

9.4.1.3.10 Шаг оценивания ASE_CCL.1-10

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

Если в ЗБ не утверждается о соответствии ПЗ, то этот шаг оценивания не применим и считается удовлетворенным.

Если ПЗ не содержит изложение определения проблемы безопасности, то этот шаг оценивания не применим и считается удовлетворенным.

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

a) набор угроз в ЗБ расширенным или идентичным по отношению к перечню угроз в ПЗ, соответствие которому утверждается;

b) набор ПБОр в ЗБ расширенным или идентичным по отношению к ПБОр в ПЗ, соответствие которому утверждается;

c) набор предположений в ЗБ идентичным по отношению к предположениям в ПЗ, соответствие которому утверждается.

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

В качестве руководства о том, что считать "эквивалентным или более ограничительным" изложением, см. ИСО/МЭК 15408-1, приложение D "Соответствие ПЗ".

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

a) изложение угроз и ПБОр в ЗБ составного ОО не противоречат изложениям в ЗБ ОО-компонентов;

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

ИСО/МЭК 15408-3 ASE_CCL.1.9C: В "Обосновании утверждений о соответствии" должно быть продемонстрировано, что изложение "Целей безопасности" согласуется с изложением "Целей безопасности" в тех ПЗ, о соответствии которым утверждается.

9.4.1.3.11 Шаг оценивания ASE_CCL.1-11

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

Если в ЗБ не утверждается о соответствии ПЗ, то этот шаг оценивания не применим и считается удовлетворенным.

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

- ЗБ все цели безопасности для ОО того ПЗ, о соответствии которому утверждается. Следует отметить, что в оцениваемом ЗБ могут быть дополнительные цели безопасности для ОО;

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

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

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

В качестве руководства о том, что считать "эквивалентным или более ограничительным" изложением, см. ИСО/МЭК 15408-1, приложение D "Соответствие ПЗ".

Для составного ОО оценщик рассматривает, соответствуют ли "Цели безопасности" составного ОО определенным в ЗБ для ОО-компонентов. Заключение делается в виде демонстрируемого соответствия. В частности, оценщик исследует "Обоснование утверждений о соответствии", чтобы сделать заключение о том, что:

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

b) изложение "Целей безопасности" в составном ЗБ согласуется с изложением "Целей безопасности" в ЗБ ОО-компонентов.

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

ИСО/МЭК 15408-3 ASE_CCL.1.10C: В "Обосновании утверждений о соответствии" должно быть продемонстрировано, что изложение "Требований безопасности" согласуется с изложением "Требований безопасности" в тех ПЗ, о соответствии которым утверждается.

9.4.1.3.12 Шаг оценивания ASE_CCL.1-12

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

Если в ЗБ не утверждается о соответствии профилю защиты, то этот шаг оценивания не применим и считается удовлетворенным.

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

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

В качестве руководства о том, что считать "эквивалентным или более ограничительным" изложением, см. ИСО/МЭК 15408-1, приложение D "Соответствие ПЗ".

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

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

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

c) изложение "Требований безопасности" в составном ЗБ согласуется с изложением "Требований безопасности" в ЗБ ОО-компонентов.

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

9.5 "Определение проблемы безопасности" (ASE_SPD)

9.5.1 Подвид деятельности по оценке (ASE_SPD.1)

9.5.1.1 Цели

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

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

Свидетельством оценки для этого подвида деятельности является ЗБ.

9.5.1.3 Действие ASE_SPD.1.1E

ИСО/МЭК 15408-3 ASE_SPD.1.1C: "Определение проблемы безопасности" должно содержать описание угроз.

9.5.1.3.1 Шаг оценивания ASE_SPD.1-1

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

Если все цели безопасности получены из предположений и/или только из ПБОр, изложение угроз не обязательно должно присутствовать в ЗБ. В этом случае этот шаг оценивания не применим и считается удовлетворенным.

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

ИСО/МЭК 15408-3 ASE_SPD.1.2C: Описание всех угроз должно проводиться в терминах источника угрозы, активов и негативного действия.

9.5.1.3.2 Шаг оценивания ASE_SPD.1-2

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

Если все цели безопасности получены из предположений и/или только из ПБОр, изложение угроз не обязательно должно присутствовать в ЗБ. В этом случае этот шаг оценивания не применим и считается удовлетворенным.

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

ИСО/МЭК 15408-3 ASE_SPD.1.3C: В "Определение проблемы безопасности" должно быть включено описание ПБОр.

9.5.1.3.3 Шаг оценивания ASE_SPD.1-3

Оценщик должен проверить, что "Определение проблемы безопасности" включает описание ПБОр.

Если все цели безопасности получены из предположений и/или только из ПБОр, изложение угроз не обязательно должно присутствовать в ЗБ. В этом случае этот шаг оценивания не применим и считается удовлетворенным.

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

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

ИСО/МЭК 15408-3 ASE_SPD.1.4C: "Определение проблемы безопасности" должно содержать описание предположений относительно среды функционирования ОО.

9.5.1.3.4 Шаг оценивания ASE_SPD.1-4

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

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

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

9.6 Цели безопасности (ASE_OBJ)

9.6.1 Подвид деятельности по оценке (ASE_OBJ.1)

9.6.1.1 Цели

Цель данного подвида деятельности - сделать заключение о том, четко ли определены цели безопасности для среды функционирования.

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

Свидетельством оценки для этого подвида деятельности является ЗБ.

9.6.1.3 Действие ASE_OBJ.1.1E

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

9.6.1.3.1 Шаг оценивания ASE_OBJ.1-1

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

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

9.6.2 Подвид деятельности по оценке (ASE_OBJ.2)

9.6.2.1 Цели

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

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

Свидетельством оценки для этого подвида деятельности является ЗБ.

9.6.2.3 Действие ASE_OBJ.2.1Е

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

9.6.2.3.1 Шаг оценивания ASE_OBJ.2-1

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

Оценщик проверяет, что обе категории "Целей безопасности" ясно идентифицированы и отделены друг от друга.

ИСО/МЭК 15408-3 ASE_OBJ.2.2C: В "Обосновании целей безопасности" каждая цель безопасности для ОО должна быть прослежена к угрозам, на противостояние которым направлена эта цель безопасности, и к ПБОр, на осуществление которых направлена эта цель безопасности.

9.6.2.3.2 Шаг оценивания ASE_OBJ.2-2

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

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

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

ИСО/МЭК 15408-3 ASE_OBJ.2.3C: В "Обосновании целей безопасности" каждая цель безопасности для ОО должна быть прослежена к угрозам, на противостояние которым направлена эта цель безопасности, к ПБОр, на осуществление которых направлена эта цель безопасности, а также к предположениям, поддерживаемым данной целью безопасности.

9.6.2.3.3 Шаг оценивания ASE_OBJ.2-3

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

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

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

ИСО/МЭК 15408-3 ASE_OBJ.2.4C: В "Обосновании целей безопасности" должно быть продемонстрировано, что цели безопасности направлены на противостояние всем идентифицированным угрозам.

9.6.2.3.4 Шаг оценивания ASE_OBJ.2-4

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

Если ни одна цель безопасности не прослежена к конкретной угрозе, то результат данного шага оценивания отрицательный (выносится отрицательный вердикт).

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

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

Следует отметить, что прослеживание целей безопасности к угрозам в "Обосновании целей безопасности" может быть частью логического обоснования, но само по себе оно не является логическим обоснованием. Даже в том случае, когда цель безопасности является просто заявлением, отражающим намерение предотвратить реализацию конкретной угрозы, то все равно требуется логическое обоснование, хотя в этом случае оно может быть минимальным и иметь вид: "Цель безопасности X непосредственно противостоит Угрозе Y".

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

ИСО/МЭК 15408-3 ASE_OBJ.2.5C: В "Обосновании целей безопасности" должно быть продемонстрировано, что цели безопасности направлены на осуществление всех ПБОр.

9.6.2.3.5 Шаг оценивания ASE_OBJ.2-5

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

Если ни одна цель безопасности не прослежена к определенной ПБОр, то результат данного шага оценивания отрицательный (выносится отрицательный вердикт).

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

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

Следует отметить, что прослеживание целей безопасности к ПБОр в "Обосновании целей безопасности" может быть частью логического обоснования, но само по себе оно не является логическим обоснованием. Даже в том случае, когда цель безопасности является просто заявлением, отражающим намерение реализовать конкретную ПБОр, то все равно требуется логическое обоснование, хотя в этом случае оно может быть минимальным и иметь вид: "Цель безопасности X непосредственно обеспечивает осуществление ПБОр Y".

ИСО/МЭК 15408-3 ASE_OBJ.2.6C: В "Обосновании целей безопасности" должно быть продемонстрировано, что цели безопасности для среды функционирования поддерживают все предположения.

9.6.2.3.6 Шаг оценивания ASE_OBJ.2-6

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

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

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

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

Следует отметить, что прослеживание целей безопасности для среды функционирования к предположениям в "Обосновании целей безопасности" может быть частью логического обоснования, но само по себе оно не является логическим обоснованием. Даже в том случае, когда цель безопасности для среды функционирования представляет собой просто перефразированное предположение, то все равно требуется логическое обоснование, хотя в этом случае оно может быть минимальным и иметь вид: "Цель безопасности X непосредственно обеспечивает выполнение Предположения Y".

9.7 Определение расширенных компонентов (ASE_ECD)

9.7.1 Подвид деятельности по оценке (ASE_ECD.1)

ГОСТ Р ИСО/МЭК 18045-2013

Группа П85

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационная технология

МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ. МЕТОДОЛОГИЯ ОЦЕНКИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

Information technology - Security techniques - Methodology for IT security evaluation

ОКС 35.040
ОКСТУ 4002

Дата введения 2014-07-01

Предисловие

1 ПОДГОТОВЛЕН Обществом с ограниченной ответственностью "Центр безопасности информации" (ООО "ЦБИ"), Федеральным автономным учреждением "Государственный научно-исследовательский испытательный институт проблем технической защиты информации Федеральной службы по техническому и экспортному контролю" (ФАУ "ГНИИИ ПТЗИ ФСТЭК России")

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 362 "Защита информации"

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 28 августа 2013 г. N 624-ст

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 18045:2008* "Информационная технология. Методы и средства обеспечения безопасности. Методология оценки безопасности информационных технологий" ("ISO/IEC Information technology - Security techniques - Methodology for IT security evaluation")
________________
* Доступ к международным и зарубежным документам, упомянутым здесь и далее по тексту, можно получить, перейдя по ссылке на сайт . - .

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА

5 ВЗАМЕН ГОСТ Р ИСО/МЭК 18045-2008


Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (gost.ru)

Введение

Введение

Международный стандарт ISO/IEC 18045:2008 был подготовлен Совместным техническим комитетом ISO/IEC JTC 1 "Информационные технологии", Подкомитетом SC 27 "Методы и средства обеспечения безопасности ИТ". Идентичный ISO/IEC 18045:2008 текст опубликован организациями - спонсорами проекта "Общие критерии" как "Общая методология оценки безопасности информационных технологий".

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

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

Вторая редакция стандарта отменяет и заменяет первую редакцию (ГОСТ Р ИСО/МЭК 18045:2007*), которая подверглась технической переработке.

________________
* Вероятно, ошибка оригинала. Следует читать: ГОСТ Р ИСО/МЭК 18045-2008. - .

1 Область применения

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

Настоящий стандарт не определяет действия оценщика для некоторых компонентов высокого доверия ИСО/МЭК 15408, по оценке которых пока нет единых согласованных руководств.

2 Нормативные ссылки

Указанные в данном разделе документы* являются необходимыми для применения настоящего стандарта. Для датированных ссылок используют только указанное издание. Для недатированных ссылок - последнее издание со всеми изменениями и дополнениями.
_______________
* Таблицу соответствия национальных стандартов международным см. по ссылке. - .

ИСО/МЭК 15408 (все части) Информационная технология - Методы и средства обеспечения безопасности - Критерии оценки безопасности ИТ [ISO/IEC 15408 (all parts) Information technology - Security techniques - Evaluation criteria for IT security].

3 Термины и определения

В настоящем стандарте применены следующие термины с соответствующими определениями:

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

3.1 действие (action): Элемент действий оценщика из ИСО/МЭК 15408-3.

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

3.2 вид деятельности (activity): Применение класса требований доверия из ИСО/МЭК 15408-3.

3.3 проверить (check): Вынести вердикт посредством простого сравнения.

Примечание - Специальные знания и опыт оценщика не требуются. В формулировке, в которой используется этот глагол, описывается то, что сравнивается.

3.4 поставка для оценки (evaluation deliverable): Любой ресурс, который оценщик или орган оценки требует от заявителя или разработчика для выполнения одного или нескольких видов деятельности по проведению оценки или по надзору за оценкой.

3.5 свидетельство оценки (evaluation evidence): Фактическая поставка для оценки.

3.6 технический отчет об оценке (evaluation technical report): Отчет, выпущенный оценщиком и представленный в орган оценки, в котором приводится общий вердикт и его логическое обоснование.

3.7 исследовать (examine): Вынести вердикт на основе анализа с использованием специальных знаний и опыта оценщика.

Примечание - Формулировка, в которой используется этот глагол, указывает на то, что конкретно и какие свойства подвергаются анализу.

3.8 интерпретация (interpretation): Разъяснение или расширение требования ИСО/МЭК 15408, ИСО/МЭК 18045 или системы оценки.

3.9 методология (methodology): Система принципов, процедур и процессов, применяемых для оценки безопасности ИТ.

3.10 сообщение о проблеме (observation report): Сообщение, документально оформленное оценщиком, в котором он просит разъяснений или указывает на возникшую при оценке проблему.

3.11 общий вердикт (overall verdict): Положительный или отрицательный вывод оценщика по результатам оценки.

3.12 вердикт органа оценки (oversight verdict): Вывод органа оценки, подтверждающий или отклоняющий общий вердикт, который основан на результатах деятельности по надзору за оценкой.

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

3.14 привести в отчете (сообщении) (report): Включить результаты оценки и вспомогательные материалы в технический отчет об оценке или в сообщение о проблеме.

3.15 система оценки (scheme): Совокупность правил, установленных органом оценки и определяющих среду оценки, включая критерии и методологию, требуемые для проведения оценки безопасности ИТ.

3.16 подвид деятельности (sub-activity): Применение компонента требований доверия из ИСО/МЭК 15408-3.

Примечание - Семейства требований доверия прямо не рассматриваются в настоящем стандарте, поскольку при проведении оценки всегда используется только один компонент доверия из применяемого семейства.

3.17 прослеживание (tracing): Однонаправленная связь между двумя совокупностями сущностей, которая показывает, какие сущности в первой совокупности каким сущностям из второй соответствуют.

3.18 вердикт (verdict): Вывод оценщика положительный, отрицательный или неокончательный применительно к некоторому элементу действий оценщика, компоненту или классу требований доверия из ИСО/МЭК 15408.

Примечание - См. также общий вердикт.

3.19 шаг оценивания (work unit): Наименьшая структурная единица работ по оценке.

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

4 Обозначения и сокращения

В настоящем стандарте применены следующие сокращения:

ЗБ (ST) - задание по безопасности

ИТ (IT) - информационная технология

ИФБО (TSFI) - интерфейс ФБО

ОО (TOE) - объект оценки

ОУД (EAL) - оценочный уровень доверия

ПБОр (OSP) - политика безопасности организации

ПЗ (РР) - профиль защиты

ТДБ (SAR) - требование доверия к безопасности

УК (CM) - управление конфигурацией

ФБО (TSF) - функциональные возможности безопасности ОО

ФТБ (SFR) - функциональное требование безопасности

ТОО (ETR) - технический отчет об оценке

СП (OR) - сообщение о проблеме

5 Краткий обзор

5.1 Структура стандарта

Раздел 6 определяет соглашения, используемые в настоящем стандарте.

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

Раздел 8 описывает работы, необходимые для получения результата оценки ПЗ.

В разделах 9-15 определяются действия по оценке, сгруппированные по классам доверия.

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

В приложении В приводится пояснение критериев оценки уязвимостей и примеры их применения.

6 Принятые соглашения

6.1 Терминология

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

Любая определенная в методологии работа по оценке, которая не следует непосредственно из требований ИСО/МЭК 15408, называется задачей или подзадачей.

6.2 Употребление глаголов

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

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

Глаголы проверить (check), исследовать (examine), привести в отчете (report) и зафиксировать (record) в тексте настоящего стандарта имеют точный смысл, указанный в определениях раздела 3.

6.3 Общие указания по оценке

Материал, который применим более чем к одному подвиду деятельности, приводится в одном месте. Указания, которые являются широко применимыми (к нескольким видам деятельности или ОУД), приведены в приложении А. Указания, относящиеся к нескольким подвидам одного вида деятельности, содержатся во вводной части описания этого вида деятельности. Если указания относятся только к одному подвиду деятельности, они содержатся только в его описании.

6.4 Взаимосвязь между структурами ИСО/МЭК 15408 и ИСО/МЭК 18045

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

Рисунок 1 - Соотношение структур ИСО/МЭК 15408 и ИСО/МЭК 18045

Рисунок 1 - Соотношение структур ИСО/МЭК 15408 и ИСО/МЭК 18045

7 Процесс оценки и соответствующие задачи оценки

7.1 Введение

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

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

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

Подвиды деятельности по оценке в данном разделе вводятся, а полностью описываются в последующих разделах.

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

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

7.2 Краткое описание процесса оценки

7.2.1 Цели

В данном подразделе представлена общая модель методологии оценки и определяются:

a) роли и обязанности сторон, вовлеченных в процесс оценки;

b) общая модель оценки.

7.2.2 Обязанности ролей

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

Заявитель предъявляет запрос об оценке и отвечает за поддержание процесса оценки. Это означает, что заявитель заключает различные соглашения по поводу проведения оценки (например, относительно начала процесса оценки). Кроме того, заявитель отвечает и за то, чтобы оценщику были доступны свидетельства оценки.

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

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

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

7.2.3 Взаимоотношения между ролями

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

Кроме того, при проведении некоторых видов оценки (например оценки по ОУД1) может не требоваться вовлечение разработчика в процесс оценки. В таком случае ОО оценщику предоставляет заявитель, и он же генерирует свидетельства оценки.

7.2.4 Общая модель оценки

Процесс оценки состоит из выполнения оценщиком задачи получения исходных данных для оценки, задачи оформления результатов оценки и задачи выполнения подвидов деятельности по оценке. На рисунке 2 отражены отношения между этими задачами и подвидами деятельности.

Рисунок 2 - Общая модель оценки

Рисунок 2 - Общая модель оценки

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

7.2.5 Вердикты оценщика

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

В настоящем стандарте различаются три взаимоисключающих вида вердикта:

a) условиями положительного вердикта являются завершение оценщиком элемента действий оценщика из ИСО/МЭК 15408 и определение, что требования к оцениваемому ПЗ, ЗБ или ОО выполнены. Для элемента условиями положительного вердикта являются:

1) успешное завершение всех шагов оценивания, составляющих соответствующее действие из методологии оценки;

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

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

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

c) Все вердикты поначалу неокончательные и остаются такими до вынесения положительного или отрицательного вердикта.

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

Рисунок 3 - Пример правила вынесения вердикта

Рисунок 3 - Пример правила вынесения вердикта

7.3 Задача получения исходных данных для оценки

7.3.1 Цели

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

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

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

Поскольку требования доверия относятся к ОО в целом, то необходимо, чтобы оценщику были доступны свидетельства оценки, относящиеся ко всем частям ОО. Область применения и требуемое содержание такого свидетельства оценки не зависят от уровня контроля разработчиком над каждой частью ОО. Например, если требуется проект, то требования семейства ADV_TDS "Проект ОО" относятся ко всем подсистемам, являющимся частью ФБО. Кроме того, требования доверия, согласно которым требуется выполнение определенных процедур (например, из семейств ALC_CMC "Возможности УК" и ALC_DEL "Поставка"), также относятся к ОО в целом (включая любую часть, разработанную другим разработчиком).

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

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

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

a) тестовая документация, позволяющая оценщику предварительно оценить тесты и процедуры тестирования;

b) проектная документация, предоставляющая оценщику исходную информацию для понимания конструкции ОО;

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

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

7.3.3 Подзадача управления свидетельством оценки

7.3.3.1 Контроль конфигурации

Оценщик должен осуществлять контроль конфигурации свидетельства оценки.

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

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

7.3.3.2 Дальнейшее использование

Системы оценки могут предусматривать контроль за изъятием из использования свидетельств оценки после завершения оценки. Изъятие из использования свидетельств оценки может достигаться посредством следующих действий:

a) возврата свидетельств оценки;

b) архивирования свидетельств оценки;

c) уничтожения свидетельств оценки.

7.3.3.3 Конфиденциальность

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

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

7.4 Подвиды деятельности по оценке

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

7.5 Задача оформления результатов оценки

7.5.1 Цели

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

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

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

a) подготовку СП (если это необходимо при выполнении оценки);

b) подготовку ТОО.

7.5.2 Управление результатами оценки

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

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

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

7.5.4 Подзадача подготовки СП

СП предоставляют оценщику механизм для запроса разъяснений (например, от органа оценки о применении требований) или для определения проблемы по одному из аспектов оценки.

При отрицательном вердикте оценщик должен представить СП для отражения результата оценки. В противном случае оценщик может использовать СП как один из способов выражения потребности в разъяснении.

В любом СП оценщик должен привести следующее:

a) идентификатор оцениваемого ПЗ или ОО;

b) задачу/подвид деятельности по оценке, при выполнении которой/которого проблема была выявлена;

c) суть проблемы;

d) оценку ее серьезности (например, приводит к отрицательному вердикту, задерживает выполнение оценки или требует решения до завершения оценки);

e) наименование организации, ответственной за решение вопроса;

f) рекомендуемые сроки решения;

g) определение влияния на оценку отсутствия решения проблемы.

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

7.5.5 Подзадача подготовки ТОО

7.5.5.1 Цели

Оценщик должен подготовить ТОО, чтобы представить техническое логическое обоснование вердиктов.

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

Предполагается, что читатель ТОО знаком с общими концепциями информационной безопасности, ИСО/МЭК 15408, настоящим стандартом, подходами к оценке и ИТ

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

7.5.5.2 ТОО при оценке ПЗ

В данном подпункте приведено минимально необходимое содержание информации, включаемой в ТОО при оценке ПЗ. Содержание ТОО показано на рисунке 4; этот рисунок может использоваться как образец при построении структурной схемы ТОО.

Рисунок 4 - Содержание ТОО при оценке ПЗ

Рисунок 4 - Содержание ТОО при оценке ПЗ

7.5.5.2.1 Введение

Оценщик должен привести в отчете идентификаторы системы оценки.

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

Оценщик должен привести в отчете идентификаторы контроля конфигурации ТОО.

Идентификаторы контроля конфигурации ТОО содержат информацию, которая идентифицирует ТОО (например, наименование, дату составления и номер версии).

Оценщик должен привести в отчете идентификаторы контроля конфигурации ПЗ.

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

Оценщик должен привести в отчете идентификатор разработчика.

Идентификатор разработчика ПЗ требуется для идентификации стороны, ответственной за создание ПЗ.

Оценщик должен привести в отчете идентификатор заявителя.

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

Оценщик должен привести в отчете идентификатор оценщика.

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

7.5.5.2.2 Оценка

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

Оценщик приводит ссылки на использованные при оценке ПЗ критерии оценки, методологию и интерпретации.

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

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

7.5.5.2.3 Результаты оценки

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

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

7.5.5.2.4 Выводы и рекомендации

Оценщик должен привести в отчете выводы по результатам оценки, в частности, общий вердикт в соответствии с разделом 9 "Результаты оценки" ИСО/МЭК 15408-1 и процедурой вынесения вердикта, описанной в пункте 7.2.5 настоящего стандарта.

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

7.5.5.2.5 Перечень свидетельств оценки

Оценщик должен привести в отчете следующую информацию о каждом свидетельстве оценки:

- о составителе свидетельства (например, разработчик, заявитель);

- о названии свидетельства;

- об уникальной ссылке на свидетельство (например, дата составления и номер версии).

7.5.5.2.6 Перечень сокращений/глоссарий терминов

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

В ТОО нет необходимости повторять определения глоссария, уже приведенные в ИСО/МЭК 15408 или настоящем стандарте.

7.5.5.2.7 Сообщения о проблемах

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

Для каждого СП в перечне следует привести идентификатор СП, а также название или аннотацию.

7.5.5.3 ТОО при оценке ОО

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

Рисунок 5 - Содержание ТОО при оценке ОО

Рисунок 5 - Содержание ТОО при оценке ОО

7.5.5.3.1 Введение

Оценщик должен привести в отчете идентификаторы системы оценки.

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

Оценщик должен привести в отчете идентификаторы контроля конфигурации ТОО.

Идентификаторы контроля конфигурации ТОО содержат информацию, которая идентифицирует ТОО (например, название, дату составления и номер версии).

Оценщик должен привести в отчете идентификаторы контроля конфигурации ЗБ и ОО.

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

Если ЗБ содержит "Утверждения о соответствии" ОО требованиям одного или нескольких ПЗ, ТОО должен содержать ссылку на соответствующие ПЗ.

Ссылка на ПЗ содержит информацию, которая уникально идентифицирует ПЗ (например, название, дату составления и номер версии).

Оценщик должен привести в отчете идентификатор разработчика.

Идентификатор разработчика ОО требуется для идентификации стороны, ответственной за создание ОО.

Оценщик должен привести в отчете идентификатор заявителя.

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

Оценщик должен привести в отчете идентификатор оценщика.

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

7.5.5.3.2 Описание архитектуры ОО

Оценщик должен привести в отчете высокоуровневое "Описание ОО" и его главных компонентов, основанное на свидетельстве оценки, указанном в семействе доверия ИСО/МЭК 15408 "Проект ОО" (ADV_TDS), где оно применимо.

Назначение этого пункта состоит в указании степени архитектурного разделения главных компонентов. Если в ЗБ нет требований из семейства ADV_TDS "Проект ОО", этот пункт не применим и считается удовлетворенным.

7.5.5.3.3 Оценка

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

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

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

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

7.5.5.3.4 Результаты оценки

Для каждого вида деятельности по оценке ОО оценщик должен привести в отчете:

- название рассматриваемого вида деятельности;

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

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

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

Для видов деятельности AVA и ATE указываются шаги оценивания, которые определяют информацию, включаемую в ТОО.

7.5.5.3.5 Выводы и рекомендации

Оценщик должен привести в отчете выводы по результатам оценки об удовлетворении ОО требованиям своего ЗБ, в частности, общий вердикт в соответствии с разделом 9 "Результаты оценки" ИСО/МЭК 15408-1 и процедурой вынесения вердикта, описанной в пункте 7.2.5 настоящего стандарта.

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

7.5.5.3.6 Перечень свидетельств оценки

Оценщик должен привести в отчете следующую информацию о каждом свидетельстве оценки:

- о составителе свидетельства (например, разработчик, заявитель);

- о названии свидетельства;

- об уникальной ссылке на свидетельство (например, дата составления и номер версии).

7.5.5.3.7 Перечень сокращений/глоссарий терминов

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

В ТОО нет необходимости повторять определения глоссария, уже приведенные в ИСО/МЭК 15408 или настоящем стандарте.

7.5.5.3.8 Сообщения о проблемах

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

Для каждого СП в перечне следует привести идентификатор СП, а также название или аннотацию.

8 Класс АРЕ: Оценка профиля защиты

8.1 Введение

Этот раздел описывает оценку ПЗ. Требования и методология оценки ПЗ идентичны для каждой оценки ПЗ, независимо от ОУД (или другой совокупности требований доверия), заявленного в ПЗ. Методология оценки в этом разделе основана на требованиях к ПЗ, определенных в классе АРЕ из ИСО/МЭК 15408-3.

Данный раздел следует использовать вместе с приложениями А, В и С в ИСО/МЭК 15408-1, поскольку в этих приложениях разъясняются приведенные здесь понятия и приводятся многочисленные примеры.

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

8.2.1 Повторное использование результатов оценки сертифицированных ПЗ

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

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

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

a) ряд новых и/или измененных требований внутренне непротиворечив, и

b) все новые и/или измененные требования совместимы с исходными требованиями.

Оценщик отмечает в ТОО каждый случай, где исследования не сделаны или только частично сделаны по этой причине.

8.3 "Введение ПЗ" (APE_INT)

8.3.1 Подвид деятельности по оценке (APE_INT.1)

8.3.1.1 Цели

Цель этого подвида деятельности - сделать заключение о том, что ПЗ правильно идентифицирован и что "Ссылка на ПЗ" и "Аннотация ОО" не противоречат друг другу.

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

Свидетельством оценки для этого подвида деятельности является ПЗ.

8.3.1.3 Действие APE_INT.1.1E

ИСО/МЭК 15408-3 APE_INT.1.1С: "Введение ПЗ" должно содержать "Ссылку на ПЗ" и "Аннотацию ОО".

8.3.1.3.1 Шаг оценивания APE_INT.1-1

Оценщик должен проверить, представлены ли в разделе "Введение ПЗ" "Ссылка на ПЗ" и "Аннотация ОО".

ИСО/МЭК 15408-3 APE_INT.1.2С: "Ссылка на ПЗ" должна уникально идентифицировать ПЗ.

8.3.1.3.2 Шаг оценивания APE_INT.1-2

Оценщик должен исследовать "Ссылку на ПЗ" в целях определения того, что она уникально идентифицирует ПЗ.

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

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

ИСО/МЭК 15408-3 APE_INT.1.3С: В "Аннотации ОО" должна быть предоставлена краткая информация об использовании и основных функциональных возможностях безопасности ОО.

8.3.1.3.3 Шаг оценивания APE_INT.1-3

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

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

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

ИСО/МЭК 15408-3 APE_INT.1.4C: В "Аннотации ОО" должен быть идентифицирован тип ОО.

8.3.1.3.4 Шаг оценивания APE_INT.1-4

Оценщик должен проверить, идентифицирован ли в "Аннотации ОО" тип ОО.

ИСО/МЭК 15408-3 APE_INT.1.5C: В "Аннотации ОО" должны быть идентифицированы любые не входящие в ОО аппаратные, программные, а также программно-аппаратные средства, доступные для ОО.

8.3.1.3.5 Шаг оценивания APE_INT.1-5

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

В то время как некоторые ОО являются автономными, другим ОО (особенно если ОО является программным средством) для работы необходимы дополнительные аппаратные, программные или программно-аппаратные средства. В этом подразделе ПЗ автор ПЗ перечисляет все доступные аппаратные, программные или программно-аппаратные средства, которые могут быть запущены на ОО.

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

8.4 Утверждения о соответствии (APE_CCL)

8.4.1 Подвид деятельности по оценке (APE_CCL.1)

8.4.1.1 Цели

Цель этого подвида деятельности состоит в том, чтобы определить обоснованность различных утверждений о соответствии. Он описывает, каким образом ПЗ соответствует ИСО/МЭК 15408, другим ПЗ и пакетам требований.

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

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

a) ПЗ;

b) другие ПЗ, соответствие которым утверждается в ПЗ;

c) пакеты требований, соответствие которым утверждается в ПЗ.

8.4.1.3 Действие АРЕ_ССL.1.1Е

ИСО/МЭК 15408-3 АРЕ_ССL.1.1С: В "Утверждения о соответствии" должно быть включено "Утверждение о соответствии ИСО/МЭК 15408", которое определяет, для какой редакции ИСО/МЭК 15408 утверждается соответствие ПЗ.

8.4.1.3.1 Шаг оценивания АРЕ_ССL.1-1

Оценщик должен проверить, что в "Утверждения о соответствии" включено "Утверждение о соответствии ИСО/МЭК 15408", которое определяет, для какой редакции ИСО/МЭК 15408 должен соответствовать ПЗ.

Оценщик делает заключение о том, что "Утверждение о соответствии ИСО/МЭК 15408" идентифицирует редакцию ИСО/МЭК 15408, которая использовалась для разработки данного ПЗ. В "Утверждение" следует включать номер редакции ИСО/МЭК 15408 и, если не использовалась международная редакция ИСО/МЭК 15408 на английском языке, то в нем следует указать язык используемой редакции ИСО/МЭК 15408.

ИСО/МЭК 15408-3 APE_CCL.1.2C: В "Утверждении о соответствии ИСО/МЭК 15408" должно приводиться описание соответствия ПЗ ИСО/МЭК 15408-2; ПЗ либо описывается как соответствующий требованиям ИСО/МЭК 15408-2, либо как содержащий расширенные по отношению к ИСО/МЭК 15408-2 требования.

8.4.1.3.2 Шаг оценивания АРЕ_ССL.1-2

Оценщик должен проверить, что "Утверждение о соответствии ИСО/МЭК 15408" описывает соответствие ПЗ ИСО/МЭК 15408-2; ПЗ либо описывается как соответствующий требованиям ИСО/МЭК 15408-2, либо как содержащий расширенные по отношению к ИСО/МЭК 15408-2 требования.

ИСО/МЭК 15408-3 APE_CCL.1.3C: В "Утверждении о соответствии ИСО/МЭК 15408" должно приводиться описание соответствия ПЗ ИСО/МЭК 15408-3; ПЗ либо описывается как соответствующий требованиям ИСО/МЭК 15408-3, либо как содержащий расширенные по отношению к ИСО/МЭК 15408-3 требования.

8.4.1.3.3 Шаг оценивания АРЕ_ССL.1-3

Оценщик должен проверить, что "Утверждение о соответствии ИСО/МЭК 15408" описывает соответствие ПЗ ИСО/МЭК 15408-3; ПЗ либо описывается как соответствующий требованиям ИСО/МЭК 15408-3, либо как содержащий расширенные по отношению к ИСО/МЭК 15408-3 требования.

ИСО/МЭК 15408-3 APE_CCL.1.4C: "Утверждение о соответствии ИСО/МЭК 15408" должно согласовываться с "Определением расширенных компонентов".

8.4.1.3.4 Шаг оценивания АРЕ_ССL.1-4

Оценщик должен исследовать "Утверждение о соответствии ИСО/МЭК 15408-2" в целях вынесения заключения о его согласованности с "Определением расширенных компонентов".

Если "Утверждение о соответствии ИСО/МЭК 15408" в ПЗ содержит "Утверждение о соответствии ИСО/МЭК 15408-2", оценщик делает заключение о том, что "Определение расширенных компонентов" не определяет функциональные компоненты.

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

8.4.1.3.5 Шаг оценивания АРЕ_ССL.1-5

Оценщик должен исследовать "Утверждение о соответствии ИСО/МЭК 15408" в отношении ИСО/МЭК 15408-3 в целях вынесения заключения о его согласованности с "Определением расширенных компонентов".

Если "Утверждение о соответствии ИСО/МЭК 15408" содержит "Утверждение о соответствии ИСО/МЭК 15408-3", оценщик делает заключение о том, что "Определение расширенных компонентов" не определяет компоненты требований доверия.

Если "Утверждение о соответствии ИСО/МЭК 15408" содержит "Утверждение о соответствии расширению ИСО/МЭК 15408-3", оценщик делает заключение о том, что "Определение расширенных компонентов" определяет хотя бы один расширенный компонент доверия.

ИСО/МЭК 15408-3 АРЕ_ССL.1.5С: В "Утверждении о соответствии" должны быть идентифицированы все ПЗ и пакеты требований безопасности, о соответствии которым утверждается в ПЗ.

8.4.1.3.6 Шаг оценивания АРЕ_ССL.1-6

Оценщик должен проверить, что "Утверждения о соответствии" содержит "Утверждение о соответствии ПЗ", идентифицирующее все ПЗ, о соответствии которым утверждается в ПЗ.

Если в ПЗ не утверждается соответствие ПЗ другим ПЗ, то этот шаг оценивания не применим и считается удовлетворенным.

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

Оценщику следует помнить, что утверждения частичного соответствия ПЗ недопустимы.

8.4.1.3.7 Шаг оценивания АРЕ_ССL.1-7

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

Если в ПЗ не утверждается соответствие какому-либо пакету требований, то этот шаг оценивания не применим и считается удовлетворенным.

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

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

ИСО/МЭК 15408-3 APE_CCL.1.6C: В "Утверждении о соответствии ПЗ пакету требований" должно приводиться описание любого соответствия ПЗ некоторому пакету требований; ПЗ либо описывается как соответствующий пакету требований, либо как содержащий расширенные по отношению к пакету требования.

8.4.1.3.8 Шаг оценивания АРЕ_ССL.1-8

Оценщик должен проверить, что для каждого идентифицированного пакета "Утверждения о соответствии" содержит* утверждение либо о соответствии именованному пакету, либо о соответствии пакету, усиленному относительно именованного пакета.
_______________
* Текст документа соответствует оригиналу. - .

Если в ПЗ не утверждается о соответствии какому-либо пакету требований, то этот шаг оценивания не применим и считается удовлетворенным.

Если в "Утверждении о соответствии ПЗ пакету требований" содержится утверждение о соответствии именованному пакету, оценщик делает заключение о том, что:

a) Если пакет является пакетом требований доверия, то ПЗ содержит все ТДБ, включенные в пакет, но не содержит дополнительных ТДБ.

b) Если пакет является функциональным, то ПЗ содержит все ФТБ, включенные в пакет, но не содержит дополнительных ФТБ.

Если в "Утверждении о соответствии ПЗ пакету требований" содержится утверждение о соответствии расширенному пакету требований относительно именованного, оценщик делает заключение о том, что:

a) Если пакет является пакетом доверия, то ПЗ содержит все ТДБ, включенные в пакет, и по крайней мере одно дополнительное ТДБ или одно ТДБ, которое является иерархическим к ТДБ в пакете.

b) Если пакет является функциональным, то ПЗ содержит все ФТБ, включенные в пакет, и по крайней мере одно дополнительное ФТБ или одно ФТБ, которое является иерархическим к ФТБ в пакете.

ИСО/МЭК 15408-3 АРЕ_ССL.1.7С: В "Обосновании утверждений о соответствии" должно быть продемонстрировано, что тип ОО согласуется с типом ОО в тех ПЗ, о соответствии которым утверждается.

8.4.1.3.9 Шаг оценивания АРЕ_ССL.1-9

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

Если в ПЗ не утверждается о соответствии ПЗ другому ПЗ, то этот шаг оценивания не применим и считается удовлетворенным.

Отношение между типами может быть простым: например, в ПЗ межсетевого экрана утверждается о соответствии другому ПЗ межсетевого экрана, или более сложным: например в ПЗ смарт-карты утверждается о соответствии многим другим ПЗ одновременно - ПЗ интегральной схемы, ПЗ для ОС смарт-карты и двум ПЗ двух приложений на смарт-карте.

ИСО/МЭК 15408-3 АРЕ_ССL.1.8С: В "Обосновании утверждений о соответствии" должно быть продемонстрировано, что изложение определения проблемы безопасности согласуется с изложением определения проблемы безопасности тех ПЗ, о соответствии которым утверждается.

8.4.1.3.10 Шаг оценивания АРЕ_ССL.1-10

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

Если в оцениваемом ПЗ не утверждается о соответствии другим ПЗ, то этот шаг оценивания не применим и считается удовлетворенным.

Если в ПЗ, о соответствии которому утверждается, не включено изложение "Определения проблемы безопасности", то этот шаг оценивания не применим и считается удовлетворенным.

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

a) набор угроз в оцениваемом ПЗ расширенным или идентичным по отношению к перечню угроз в ПЗ, о соответствии которому утверждается;

b) набор ПБОр в оцениваемом ПЗ расширенным или идентичным по отношению к ПБОр в ПЗ, о соответствии которому утверждается;

с) набор предположений в оцениваемом ПЗ идентичным по отношению к предположениям в ПЗ, о соответствии которому утверждается.

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

В качестве руководства о том, что считать "эквивалентным или более ограничительным" изложением, см. ИСО/МЭК 15408-1 приложение D "Соответствие ПЗ".

ИСО/МЭК 15408-3 АРЕ_ССL.1.9С: В "Обосновании утверждений о соответствии" должно быть продемонстрировано, что изложение "Целей безопасности" согласуется с изложением "Целей безопасности" в тех ПЗ, о соответствии которым утверждается.

8.4.1.3.11 Шаг оценивания АРЕ_ССL.1-11

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

Если в ПЗ не утверждается о соответствии ПЗ другому ПЗ, то этот шаг оценивания не применим и считается удовлетворенным.

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

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

- оцениваемый ПЗ абсолютно все цели безопасности для среды функционирования (за одним исключением, которое описано в следующем абзаце). Следует отметить, что в оцениваемом ПЗ не допускается наличие дополнительных целей безопасности для среды функционирования;

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

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

В качестве руководства о том, что считать "эквивалентным или более ограничительным" изложением, см. ИСО/МЭК 15408-1 приложение D "Соответствие ПЗ".

ИСО/МЭК 15408-3 АРЕ_ССL.1.10С: В "Обосновании утверждений о соответствии" должно быть продемонстрировано, что изложение "Требований безопасности" согласуется с изложением "Требований безопасности" в тех ПЗ, о соответствии которым утверждается.

8.4.1.3.12 Шаг оценивания АРЕ_ССL.1-12

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

Если в ПЗ не утверждается о соответствии другому ПЗ, то этот шаг оценивания не применим и считается выполненным успешно.

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

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

В качестве руководства о том, что считать "эквивалентным или более ограничительным" изложением, см. ИСО/МЭК 15408-1 приложение D "Соответствие ПЗ".

ИСО/МЭК 15408-3 АРЕ_ССL.1.11С: "Изложение соответствия" должно содержать описание соответствия, требуемого любыми ПЗ/ЗБ данному профилю защиты в виде строгого или демонстрируемого соответствия.

8.4.1.3.13 Шаг оценивания АРЕ_ССL.1-13

Оценщик должен проверить, что изложение соответствия ПЗ содержит утверждение о строгом или демонстрируемом соответствии ПЗ.

8.5 Определение проблемы безопасности (APE_SPD)

8.5.1 Подвид деятельности по оценке (APE_SPD.1)

8.5.1.1 Цели

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

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

Свидетельством оценки для этого подвида деятельности является ПЗ.

8.5.1.3 Действие APE_SPD.1.1E

ИСО/МЭК 15408-3 APE_SPD.1.1С: "Определение проблемы безопасности" должно включать в себя описание угроз.

8.5.1.3.1 Шаг оценивания APE_SPD.1-1

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

Если все цели безопасности получены из предположений и/или только из ПБОр, изложение угроз не обязательно должно присутствовать в ПЗ. В этом случае этот шаг оценивания не применим и считается удовлетворенным.

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

ИСО/МЭК 15408-3 APE_SPD.1.2C: Описание всех угроз должно проводиться в терминах источника угрозы, активов и негативного воздействия.

8.5.1.3.2 Шаг оценивания APE_SPD.1-2

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

Если все цели безопасности получены из предположений и/или только из ПБОр, изложение угроз не обязательно должно присутствовать в ПЗ. В этом случае этот шаг оценивания не применим и считается удовлетворенным.

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

ИСО/МЭК 15408-3 APE_SPD.1.3C: В "Определение проблемы безопасности" должно быть включено описание ПБОр.

8.5.1.3.3 Шаг оценивания APE_SPD.1-3

Оценщик должен проверить, что "Определение проблемы безопасности" описывает ПБОр.

Если все цели безопасности получены из предположений и/или только из ПБОр, изложение угроз не обязательно должно присутствовать в ПЗ. В этом случае этот шаг оценивания не применим и считается удовлетворенным.

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

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

ИСО/МЭК 15408-3 APE_SPD.1.4C: "Определение проблемы безопасности" должно содержать описание предположений относительно среды функционирования ОО.

8.5.1.3.4 Шаг оценивания APE_SPD.1-4

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

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

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

8.6 Цели безопасности (APE_OBJ)

8.6.1 Подвид деятельности по оценке (APE_OBJ.1)

8.6.1.1 Цели

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

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

Свидетельством оценки для этого подвида деятельности является ПЗ.

8.6.1.3 Действие APE_OBJ.1.1E

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

8.6.1.3.1 Шаг оценивания APE_OBJ.1-1

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

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

8.6.2 Подвид деятельности по оценке (APE_OBJ.2)

8.6.2.1 Цели

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

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

Свидетельством оценки для этого подвида деятельности является ПЗ.

8.6.2.3 Действие APE_OBJ.2.1Е

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

8.6.2.3.1 Шаг оценивания APE_OBJ.2-1

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

Оценщик проверяет, что обе категории "Целей безопасности" ясно идентифицированы и отделены друг от друга.

ИСО/МЭК 15408-3 APE_OBJ.2.2C: В "Обосновании целей безопасности" каждая цель безопасности для ОО должна быть прослежена к угрозам, на противостояние которым направлена эта цель безопасности, и к ПБОр, на осуществление которых направлена эта цель безопасности.

8.6.2.3.2 Шаг оценивания APE_OBJ.2-2

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

Каждая цель безопасности для ОО может быть прослежена к угрозам или ПБОр или к комбинации угроз и ПБОр, но должна быть прослежена по крайней мере к одной угрозе или ПБОр.

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

ИСО/МЭК 15408-3 APE_OBJ.2.3C: В "Обосновании целей безопасности" каждая цель безопасности для ОО должна быть прослежена к угрозам, на противостояние которым направлена эта цель безопасности, к ПБОр, на осуществление которых направлена эта цель безопасности, а также к предположениям, поддерживаемым данной целью безопасности.

8.6.2.3.3 Шаг оценивания APE_OBJ.2-3

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

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

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

ИСО/МЭК 15408-3 APE_OBJ.2.4C: В "Обосновании целей безопасности" должно быть продемонстрировано, что цели безопасности направлены на противостояние всем идентифицированным угрозам.

8.6.2.3.4 Шаг оценивания APE_OBJ.2-4

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

Если ни одна цель безопасности не прослежена к конкретной угрозе, то результат данного шага оценивания отрицательный (выносится отрицательный вердикт).

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

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

Следует отметить, что прослеживание целей безопасности к угрозам в "Обосновании целей безопасности" может быть частью логического обоснования, но само по себе оно не является логическим обоснованием. Даже в том случае, когда цель безопасности является просто заявлением, отражающим намерение предотвратить реализацию конкретной угрозы, то все равно требуется логическое обоснование, хотя в этом случае оно может быть минимальным и иметь вид: "Цель безопасности X непосредственно противостоит Угрозе Y".

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

ИСО/МЭК 15408-3 APE_OBJ.2.5C: В "Обосновании целей безопасности" должно быть продемонстрировано, что цели безопасности направлены на осуществление всей ПБОр.

8.6.2.3.5 Шаг оценивания APE_OBJ.2-5

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

Если ни одна цель безопасности не прослежена к определенной ПБОр, то результат данного шага оценивания отрицательный (выносится отрицательный вердикт).

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

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

Следует отметить, что прослеживание целей безопасности к ПБОр в "Обосновании целей безопасности" может быть частью логического обоснования, но само по себе оно не является логическим обоснованием. Даже в том случае, когда цель безопасности является просто заявлением, отражающим намерение реализовать конкретную ПБОр, то все равно требуется логическое обоснование, хотя в этом случае оно может быть минимальным и иметь вид: "Цель безопасности X непосредственно обеспечивает осуществление ПБОр Y".

ИСО/МЭК 15408-3 APE_OBJ.2.6C: В "Обосновании целей безопасности" должно быть продемонстрировано, что цели безопасности для среды функционирования поддерживают все предположения.

8.6.2.3.6 Шаг оценивания APE_OBJ.2-6

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

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

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

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

Следует отметить, что прослеживание целей безопасности для среды функционирования к предположениям в "Обосновании целей безопасности" может быть частью логического обоснования, но само по себе оно не является логическим обоснованием. Даже в том случае, когда цель безопасности для среды функционирования представляет собой просто перефразированное предположение, то все равно требуется логическое обоснование, хотя в этом случае оно может быть минимальным и иметь вид: "Цель безопасности X непосредственно поддерживает выполнение Предположения Y".

8.7 Определение расширенных компонентов (APE_ECD)

8.7.1 Подвид деятельности по оценке (APE_ECD.1)

8.7.1.1 Цели

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

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

Свидетельством оценки для этого подвида деятельности является ПЗ.

8.7.1.3 Действие APE_ECD.1.1E

ИСО/МЭК 15408-3 APE_ECD.1.1С: В изложении "Требований безопасности" должны быть идентифицированы все расширенные требования безопасности.

8.7.1.3.1 Шаг оценивания APE_ECD.1-1

Оценщик должен проверить, что все требования безопасности в изложении "Требований безопасности", которые не идентифицированы как расширенные требования, присутствуют в ИСО/МЭК 15408-2 или в ИСО/МЭК 15408-3.

ИСО/МЭК 15408-3 APE_ECD.1.2C: В "Определении расширенных компонентов" должен определяться расширенный компонент для каждого расширенного требования безопасности.

8.7.1.3.2 Шаг оценивания APE_ECD.1-2

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

Если ПЗ не содержит расширенные требования безопасности, то этот шаг оценивания не применим и считается удовлетворенным.

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

ИСО/МЭК 15408-3 APE_ECD.1.3C: В "Определении расширенных компонентов" должно указываться, как каждый расширенный компонент связан с существующими компонентами, семействами и классами ИСО/МЭК 15408.

8.7.1.3.3 Шаг оценивания APE_ECD.1-3

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

Если ПЗ не содержит расширенные требования безопасности, то этот шаг оценивания не применим и считается удовлетворенным.

Оценщик делает заключение о том, что каждый расширенный компонент является:

a) компонентом семейства ИСО/МЭК 15408-2 или ИСО/МЭК 15408-3, или

b) компонентом нового семейства, определенного в ПЗ.

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

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

Если в ПЗ определяются новые семейства, оценщик делает заключение о том, что каждое новое семейство является либо:

a) семейством существующего класса ИСО/МЭК 15408-2 или ИСО/МЭК 15408-3, или

b) семейством нового класса, определенного в ПЗ.

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

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

8.7.1.3.4 Шаг оценивания APE_ECD.1-4

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

Если ПЗ не содержит расширенные требования безопасности, то этот шаг оценивания не применим и считается удовлетворенным.

Оценщик подтверждает, что никакие применимые зависимости не были пропущены автором ПЗ.

ИСО/МЭК 15408-3 APE_ECD.1.4C: В "Определении расширенных компонентов" в качестве модели представления должны использоваться компоненты, семейства, классы и методология ИСО/МЭК 15408.

8.7.1.3.5 Шаг оценивания APE_ECD.1-5

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

Если ПЗ не содержит расширенные функциональные требования безопасности, то этот шаг оценивания не применим и считается удовлетворенным.

Оценщик делает заключение о том, что расширенный функциональный компонент согласуется с пунктом 6.1.3 "Структура компонента" ИСО/МЭК 15408-2.

Если в расширенном функциональном компоненте используются операции, оценщик делает заключение о том, что расширенный функциональный компонент согласуется с подразделом 7.1 "Операции" ИСО/МЭК 15408-1.

Если расширенный функциональный компонент находится в иерархической зависимости по отношению к существующему функциональному компоненту, оценщик делает заключение о том, что расширенный функциональный компонент согласуется с пунктом 6.2.1 "Выделение изменений в компоненте" ИСО/МЭК 15408-2.

8.7.1.3.6 Шаг оценивания APE_ECD.1-6

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

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

Оценщик делает заключение о том, что все новые функциональные семейства совместимы с пунктом 6.1.2 "Структура семейства" ИСО/МЭК 15408-2.

8.7.1.3.7 Шаг оценивания APE_ECD.1-7

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

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

Оценщик делает заключение о том, что все новые функциональные классы согласуются с пунктом 6.1.1 "Структура класса" ИСО/МЭК 15408-2.

8.7.1.3.8 Шаг оценивания APE_ECD.1-8

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

Если в ПЗ не содержатся расширенные требования доверия к безопасности, то этот шаг оценивания не применим и считается удовлетворенным.

Оценщик делает заключение о том, что "Определение расширенных компонентов" согласуется с пунктом 6.1.3 "Структура компонента" ИСО/МЭК 15408-3.

Если в расширенном компоненте доверия используются операции, оценщик делает заключение о том, что расширенный компонент доверия согласуется с подразделом 7.1 "Операции" ИСО/МЭК 15408-1.

Если расширенный компонент доверия находится в иерархической зависимости по отношению к существующему компоненту доверия, оценщик делает заключение о том, что расширенный компонент доверия согласуется с пунктом 6.1.3 "Структура компонента" ИСО/МЭК 15408-3.

8.7.1.3.9 Шаг оценивания APE_ECD.1-9

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

Если ПЗ не содержит расширенные требования доверия к безопасности, то этот шаг оценивания не применим и считается удовлетворенным.

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

8.7.1.3.10 Шаг оценивания APE_ECD.1-10

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

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

Оценщик делает заключение о том, что все новые семейства доверия совместимы с пунктом 6.1.2 "Структура семейства" ИСО/МЭК 15408-3.

8.7.1.3.11 Шаг оценивания APE_ECD.1-11

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

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

Оценщик делает заключение о том, что все новые классы доверия согласуются с пунктом 6.1.1 "Структура класса" ИСО/МЭК 15408-3.

ИСО/МЭК 15408-3 APE_ECD.1.5C: Расширенные компоненты должны состоять из измеримых объективных элементов, чтобы была возможность продемонстрировать соответствие или несоответствие этим элементам.

8.7.1.3.12 Шаг оценивания APE_ECD.1-12

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

Если ПЗ не содержит расширенные требования безопасности, то этот шаг оценивания не применим и считается удовлетворенным.

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

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

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

8.7.1.4 Действие APE_ECD.1.2E

8.7.1.4.1 Шаг оценивания APE_ECD.1-13

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

Если ПЗ не содержит расширенные требования доверия к безопасности, этот шаг оценивания не применим, и считается удовлетворенным.

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

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

8.8 Требования безопасности (APE_REQ)

8.8.1 Подвид деятельности по оценке (APE_REQ.1)

8.8.1.1 Цели

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

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

Свидетельством оценки для этого подвида деятельности является ПЗ.

8.8.1.3 Действие APE_REQ.1.1E

ИСО/МЭК 15408-3 APE_REQ.1.1C: Изложение "Требований безопасности" должно содержать описание ФТБ и ТДБ.

8.8.1.3.1 Шаг оценивания APE_REQ.1-1

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

Оценщик делает заключение о том, что каждое ФТБ идентифицировано одним из следующих способов:

a) ссылкой на конкретный компонент ИСО/МЭК 15408-2;

b) ссылкой на расширенный компонент в "Определении расширенных компонентов" ПЗ;

c) ссылкой на ПЗ, о соответствии с которым утверждается в ПЗ;

d) ссылкой на пакет требований безопасности, о соответствии с которым утверждается в ПЗ;

e) с помощью воспроизведения в ПЗ.

Не обязательно использовать одинаковые способы идентификации для всех ФТБ.

8.8.1.3.2 Шаг оценивания APE_REQ.1-2

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

Оценщик делает заключение о том, что каждое ТДБ идентифицировано одним из следующих способов:

a) ссылкой на конкретный компонент ИСО/МЭК 15408-3;

b) ссылкой на расширенный компонент в "Определении расширенных компонентов" ПЗ;

c) ссылкой на ПЗ, о соответствии с которым утверждается в ПЗ;

d) ссылкой на пакет требований безопасности, о соответствии с которым утверждается в ПЗ;

e) с помощью воспроизведения отображения в ПЗ.

Не обязательно использовать одинаковые способы идентификации для всех ТДБ.

ИСО/МЭК 15408-3 APE_REQ.1.2C: Все субъекты, объекты, операции, атрибуты безопасности, внешние сущности и другие понятия, используемые в ФТБ и ТДБ, должны быть определены.

8.8.1.3.3 Шаг оценивания APE_REQ.1-3

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

Оценщик делает заключение о том, что ПЗ определяет все:

- субъекты и объекты (их типы), которые используются в ФТБ;

- атрибуты безопасности (их типы) субъектов, пользователей, объектов, информации, сеансов и/или ресурсов, возможные значения, которые могут принимать данные атрибуты и любые отношения между этими значениями (например, "Совершенно секретно" выше, чем "Секретно");

- операции (их типы), которые используются в ФТБ, включая результаты выполнения этих операций;

- типы внешних сущностей в ФТБ;

- прочие элементы, которые введены в ФТБ и/или ТДБ путем выполнения операций, если эти элементы не являются ясными без дополнительного объяснения или используются вне их словарных значений.

Цель этого шага оценивания состоит в том, чтобы удостовериться, что ФТБ и ТДБ были четко определены и что не может произойти их неправильного понимания из-за употребления неопределенных терминов. При выполнении этого шага оценивания не следует доходить до крайностей, вынуждая автора ПЗ определять каждое слово. Предполагается, что у широкой аудитории, на которую рассчитан набор требований безопасности, есть понимание ИТ в целом, основ информационной безопасности и знание "Критериев оценки безопасности информационных технологий".

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

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

ИСО/МЭК 15408-3 APE_REQ.1.3C: В изложении "Требований безопасности" должны быть идентифицированы все выполняемые над требованиями безопасности операции.

8.8.1.3.4 Шаг оценивания APE_REQ.1-4

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

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

ИСО/МЭК 15408-3 APE_REQ.1.4C: Все операции должны выполняться правильно.

8.8.1.3.5 Шаг оценивания APE_REQ.1-5

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

Руководство по правильному выполнению операций представлено в приложении С "Руководство по выполнению операций" ИСО/МЭК 15408-1.

8.8.1.3.6 Шаг оценивания APE_REQ.1-6

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

Руководство по правильному выполнению операций представлено в приложении С "Руководство по выполнению операций" ИСО/МЭК 15408-1.

8.8.1.3.7 Шаг оценивания APE_REQ.1-7

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

Руководство по правильному выполнению операций представлено в приложении С "Руководство по выполнению операций" ИСО/МЭК 15408-1.

8.8.1.3.8 Шаг оценивания APE_REQ.1-8

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

Руководство по правильному выполнению операций представлено в приложении С "Руководство по выполнению операций" ИСО/МЭК 15408-1.

ИСО/МЭК 15408-3 APE_REQ.1.5C: Каждая зависимость от "Требований безопасности" должна быть либо удовлетворена, либо должно приводиться обоснование неудовлетворения данной зависимости.

8.8.1.3.9 Шаг оценивания APE_REQ.1-9

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

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

В логическом обосновании того, что зависимость не удовлетворена, следует указывать либо:

a) почему зависимость не является полезной или необходимой, в этом случае не требуется предоставлять дополнительную информацию; либо

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

ИСО/МЭК 15408-3 APE_REQ.1.6C: Изложение "Требований безопасности" должно быть внутренне непротиворечивым.

8.8.1.3.10 Шаг оценивания APE_REQ.1-10

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

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

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

Некоторые примеры возможных конфликтов:

a) расширенное ТДБ определяет, что проект некоторого криптографического алгоритма должен содержаться в секрете, а другое расширенное ТДБ предписывает свободный доступ к просмотру его исходных кодов;

b) компонент FAU_GEN.1 "Генерация данных аудита безопасности" определяет, что идентификатор субъекта должен регистрироваться в журнале; компонент FDP_ACC.1 "Ограниченное управление доступом" определяет, кто имеет права доступа к этим журналам, а компонент FPR_UNO.1 "Скрытность" определяет, что не рекомендуется, чтобы некоторые действия субъектов были доступны для просмотра другим субъектам. Если субъект, которому не следует иметь возможность видеть действия других субъектов, может получить доступ к журналам регистрации данных действий, эти ФТБ являются конфликтующими;

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

d) многократные итерации компонента FDP_ACC.1 "Ограниченное управление доступом", особенно если некоторые итерации касаются одних и тех же субъектов, объектов или операций. Если одно ФТБ по управлению доступом позволяет субъекту выполнять операцию над объектом, тогда как другое ФТБ по управлению доступом не позволяет это, эти требования являются конфликтующими.

8.8.2 Подвид деятельности по оценке (APE_REQ.2)

8.8.2.1 Цели

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

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

Свидетельством оценки для этого подвида деятельности является ПЗ.

8.8.2.3 Действие APE_REQ.2.1E

ИСО/МЭК 15408-3 APE_REQ.2.1С: Изложение "Требований безопасности" должно содержать описание ФТБ и ТДБ.

8.8.2.3.1 Шаг оценивания APE_REQ.2-1

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

Оценщик делает заключение о том, что каждое ФТБ идентифицировано одним из следующих способов:

a) ссылкой на конкретный компонент ИСО/МЭК 15408-2;

b) ссылкой на расширенный компонент в "Определении расширенных компонентов" ПЗ;

c) ссылкой на конкретный компонент ПЗ, о соответствии с которым утверждается в ПЗ;

d) ссылкой на конкретный компонент в пакете требований безопасности, о соответствии с которым утверждается в ПЗ;

e) с помощью воспроизведения в ПЗ.

Не обязательно использовать одинаковые способы идентификации для всех ФТБ.

8.8.2.3.2 Шаг оценивания APE_REQ.2-2

Оценщик должен проверить, что изложение "Требований безопасности" содержит описание требований доверия к безопасности.

Оценщик делает заключение о том, что каждое ТДБ идентифицировано одним из следующих способов:

a) ссылкой на конкретный компонент ИСО/МЭК 15408-3;

b) ссылкой на расширенный компонент в "Определении расширенных компонентов" ПЗ;

c) ссылкой на конкретный компонент ПЗ, о соответствии с которым утверждается в ПЗ;

d) ссылкой на конкретный компонент в пакете требований безопасности, о соответствии с которым утверждается в ПЗ;

e) с помощью воспроизведения в ПЗ.

Не обязательно использовать одинаковые способы идентификации для всех ТДБ.

ИСО/МЭК 15408-3 APE_REQ.2.2C: Все субъекты, объекты, операции, атрибуты безопасности, внешние сущности и другие понятия, используемые в ФТБ и ТДБ, должны быть определены.

8.8.2.3.3 Шаг оценивания APE_REQ.2-3

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

Оценщик делает заключение о том, что ПЗ определяет все:

- субъекты и объекты (их типы), используемые в ФТБ;

- атрибуты безопасности субъектов (их типы), пользователей, объектов, информации, сеансов и/или ресурсов, возможные значения, которые могут принимать данные атрибуты и любые отношения между этими значениями (например, "Совершенно секретно" выше, чем "Секретно");

- операции (их типы), которые используются в ФТБ, включая результаты выполнения этих операций;

- внешние сущности (их типы) в ФТБ;

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

Цель этого шага оценивания состоит в том, чтобы удостовериться, что ФТБ и ТДБ четко определены и что не может произойти их неправильного понимания из-за употребления неопределенных терминов. При выполнении этого шага оценивания не следует доходить до крайностей, вынуждая автора ПЗ определять каждое слово. Предполагается, что у широкой аудитории, на которую рассчитан набор требований безопасности, есть понимание ИТ в целом, основ информационной безопасности и знание "Критериев оценки безопасности информационных технологий".

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

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

ИСО/МЭК 15408-3 APE_REQ.2.3C: В изложении "Требований безопасности" должны быть идентифицированы все операции над требованиями безопасности.

8.8.2.3.4 Шаг оценивания APE_REQ.2-4

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

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

ИСО/МЭК 15408-3 APE_REQ.2.4C: Все операции должны быть выполнены правильно.

8.8.2.3.5 Шаг оценивания APE_REQ.2-5

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

Руководство по правильному выполнению операций представлено в приложении С "Руководство по выполнению операций" ИСО/МЭК 15408-1.

8.8.2.3.6 Шаг оценивания APE_REQ.2-6

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

Руководство по правильному выполнению операций представлено в приложении С "Руководство по выполнению операций" ИСО/МЭК 15408-1.

8.8.2.3.7 Шаг оценивания APE_REQ.2-7

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

Руководство по правильному выполнению операций представлено в приложении С "Руководство по выполнению операций" ИСО/МЭК 15408-1.

8.8.2.3.8 Шаг оценивания APE_REQ.2-8

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

Руководство по правильному выполнению операций представлено в приложении С "Руководство по выполнению операций" ИСО/МЭК 15408-1.

ИСО/МЭК 15408-3 APE_REQ.2.5C: Каждая зависимость от "Требований безопасности" должна быть либо удовлетворена, либо должно приводиться обоснование неудовлетворения зависимости.

8.8.2.3.9 Шаг оценивания APE_REQ.2-9

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

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

В логическом обосновании того, что зависимость не удовлетворена, следует указать либо:

a) почему зависимость не является полезной или необходимой, в этом случае не требуется предоставлять дополнительную информацию; либо

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

ИСО/МЭК 15408-3 APE_REQ.2.6C: В "Обосновании требований безопасности" должно быть представлено прослеживание соответствия каждого ФТБ к целям безопасности для ОО.

8.8.2.3.10 Шаг оценивания APE_REQ.2-10

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

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

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

ИСО/МЭК 15408-3 APE_REQ.2.7C: В "Обосновании требований безопасности" должно быть продемонстрировано, что ФТБ обеспечивают выполнение всех целей безопасности для ОО.

8.8.2.3.11 Шаг оценивания APE_REQ.2-11

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

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

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

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

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

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

ИСО/МЭК 15408-3 APE_REQ.2.8C: В "Обосновании требований безопасности" должно приводиться пояснение того, почему выбраны определенные ТДБ.

8.8.2.3.12 Шаг оценивания APE_REQ.2-12

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

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

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

ИСО/МЭК 15408-3 APE_REQ.2.9C: Изложение "Требований безопасности" должно быть внутренне непротиворечивым.

8.8.2.3.13 Шаг оценивания APE_REQ.2-13

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

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

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

Некоторые примеры возможных конфликтов:

a) расширенное ТДБ определяет, что проект некоторого криптографического алгоритма должен содержаться в секрете, а другое расширенное ТДБ предписывает свободный доступ к просмотру его исходных кодов;

b) компонент FAU_GEN.1 "Генерация данных аудита безопасности" определяет, что идентификатор субъекта должен регистрироваться в журнале; компонент FDP_ACC.1 "Ограниченное управление доступом" определяет, кто имеет права доступа к этим журналам, а компонент FPR_UNO.1 "Скрытность" определяет, что не рекомендуется, чтобы некоторые действия субъектов были доступны для просмотра другим субъектам. Если субъект, которому не следует иметь возможность видеть действия других субъектов, может получить доступ к журналам регистрации данных действий, эти ФТБ являются конфликтующими;

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

d) многократные итерации компонента FDP_ACC.1 "Ограниченное управление доступом", особенно если некоторые итерации касаются одних и тех же субъектов, объектов или операций. Если одно ФТБ по управлению доступом позволяет субъекту выполнять операцию над объектом, тогда как другое ФТБ по управлению доступом не позволяет это, эти требования являются конфликтующими.

9 Класс ASE: Оценка задания по безопасности

9.1 Введение

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

Методология оценки в этом разделе основана на требованиях к ЗБ, определенных в классе ASE "Оценка ЗБ" из ИСО/МЭК 15408-3.

Данный раздел следует использовать вместе с приложениями А, В и С в ИСО/МЭК 15408-1, поскольку в этих приложениях разъясняются приведенные здесь понятия и приводятся многочисленные примеры.

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

9.2.1 Использование результатов оценки сертифицированных ПЗ

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

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

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

a) набор новых и/или измененных требований внутренне непротиворечив, и

b) набор всех новых и/или измененных требований не противоречит исходным требованиям.

Оценщик отмечает в ТОО каждый случай, где исследования не сделаны или сделаны только частично по этой причине.

9.3 Введение ЗБ (ASE_INT)

9.3.1 Подвид деятельности по оценке (ASE_INT.1)

9.3.1.1 Цели

Цель этого подвида деятельности - сделать заключение о том, правильно ли идентифицированы ЗБ и ОО, правильно ли описан ОО по трем уровням представления ("Ссылка на ОО", "Аннотация ОО" и "Описание ОО") и согласованы ли данные описания друг с другом.

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

Свидетельством оценки для этого подвида деятельности является ЗБ.

9.3.1.3 Действие ASE_INT.1.1E

ИСО/МЭК 15408-3 ASE_INT.1.1С: "Введение ЗБ" должно содержать "Ссылку на ЗБ", "Ссылку на ОО", "Аннотацию ОО" и "Описание ОО".

9.3.1.3.1 Шаг оценивания ASE_INT.1-1

Оценщик должен проверить, содержит ли "Введение ЗБ" "Ссылку на ЗБ", "Ссылку на ОО", "Аннотацию ОО" и "Описание ОО".

ИСО/МЭК 15408-3 ASE_INT.1.2C: "Ссылка на ЗБ" должна однозначно идентифицировать ЗБ.

9.3.1.3.2 Шаг оценивания ASE_INT.1-2

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

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

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

ИСО/МЭК 15408-3 ASE_INT.1.3C: "Ссылка на ОО" должна однозначно идентифицировать ОО.

9.3.1.3.3 Шаг оценивания ASE_INT.1-3

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

Оценщик выносит заключение о том, что "Ссылка на ОО" идентифицирует ОО так, что ясно, к какому ОО относится ЗБ, и что она идентифицирует версию ОО, например благодаря включению номера версии/даты выпуска/создания.

9.3.1.3.4 Шаг оценивания ASE_INT.1-4

Оценщик должен исследовать "Ссылку на ОО", чтобы сделать заключение о том, что она не вводит в заблуждение.

Если ОО связан с одним или более широко известными продуктами, допускается отразить этот факт в "Ссылке на ОО". Однако это не следует использовать для введения пользователей в заблуждение: не позволяется допускать ситуации, когда в "Ссылке на ОО" не отражено, что оценена только небольшая часть продукта.

ИСО/МЭК 15408-3 ASE_INT.1.4C: В "Аннотации ОО" должна быть представлена краткая информация о его использовании и основных функциональных возможностях безопасности ОО.

9.3.1.3.5 Шаг оценивания ASE_INT.1-5

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

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

В "Аннотации ОО" в ЗБ для составных ОО следует представить описание использования и основных характеристик безопасности для составного ОО, а не для отдельных ОО в его составе.

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

ИСО/МЭК 15408-3 ASE_INT.1.5C: В "Аннотации ОО" должен быть идентифицирован тип ОО.

9.3.1.3.6 Шаг оценивания ASE_INT.1-6

Оценщик должен проверить, идентифицирован ли в "Аннотации ОО" тип ОО.

9.3.1.3.7 Шаг оценивания ASE_INT.1-7

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

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

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

ИСО/МЭК 15408-3 ASE_INT.1.6C: В "Аннотации ОО" должны быть идентифицированы любые не входящие в ОО аппаратные, программные, а также программно-аппаратные средства, требуемые ОО.

9.3.1.3.8 Шаг оценивания ASE_INT.1-8

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

В то время как некоторые ОО являются автономными, другим ОО (особенно если ОО является программным средством) для работы необходимы дополнительные аппаратные, программные или программно-аппаратные средства. Если ОО не требуется каких-либо аппаратных, программных, программно-аппаратных средств, этот шаг оценивания не применим и считается удовлетворенным.

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

ИСО/МЭК 15408-3 ASE_INT.1.7С: "Описание ОО" должно включать описание физических границ ОО.

9.3.1.3.9 Шаг оценивания ASE_INT.1-9

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

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

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

ИСО/МЭК 15408-3 ASE_INT.1.8С: "Описание ОО" должно включать описание логических границ ОО.

9.3.1.3.10 Шаг оценивания ASE_INT.1-10

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

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

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

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

9.3.1.4 Действие ASE_INT.1.2E

9.3.1.4.1 Шаг оценивания ASE_INT.1-11

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

9.4 Утверждения о соответствии (ASE_CCL)

9.4.1 Подвид деятельности по оценке (ASE_CCL.1)

9.4.1.1 Цели

Цель этого подвида деятельности состоит в том, чтобы определить правомерность различных утверждений о соответствии. Он описывает, каким образом ЗБ и ОО соответствует ИСО/МЭК 15408, и как ЗБ соответствует ПЗ и пакетам требований.

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

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

a) ЗБ;

b) другие ПЗ, о соответствии которым утверждается в ЗБ;

c) пакеты требований, о соответствии которым утверждается в ЗБ.

9.4.1.3 Действие ASE_CCL.1.1E

ИСО/МЭК 15408-3 ASE_CCL.1.1C: В "Утверждения о соответствии" должно быть включено "Утверждение о соответствии ИСО/МЭК 15408", которое определяет, для какой редакции ИСО/МЭК 15408 утверждается соответствие ЗБ и ОО.

9.4.1.3.1 Шаг оценивания ASE_CCL.1-1

Оценщик должен проверить, что в "Утверждении о соответствии" включено "Утверждение о соответствии ИСО/МЭК 15408", которое определяет, для какой редакции ИСО/МЭК 15408 утверждается о соответствии в ЗБ и ОО.

Оценщик делает заключение о том, что в "Утверждении о соответствии ИСО/МЭК 15408" идентифицируется редакция ИСО/МЭК 15408, которая использовалась для разработки данного ЗБ. В "Утверждение" следует включать номер редакции ИСО/МЭК 15408 и, если не использовалась международная редакция стандарта ИСО/МЭК 15408 на английском языке, то в нем должен быть указан язык используемой редакции ИСО/МЭК 15408.

Для составного ОО оценщик должен рассмотреть любые отличия между редакцией ИСО/МЭК 15408, о соответствии которой утверждается в ОО-компоненте, и редакцией ИСО/МЭК 15408, о соответствии которой утверждается в составном ОО. Если редакции отличаются, оценщик должен определить, приведут ли различия между редакциями к противоречивым утверждениям.

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

ИСО/МЭК 15408-3 ASE_CCL.1.2C: В "Утверждении о соответствии ИСО/МЭК 15408" должно приводиться описание соответствия ЗБ ИСО/МЭК 15408-2; ЗБ либо описывается как соответствующее требованиям ИСО/МЭК 15408-2, либо как содержащее расширенные по отношению к ИСО/МЭК 15408-2 требования.

9.4.1.3.2 Шаг оценивания ASE_CCL.1-2

Оценщик должен проверить, что "Утверждение о соответствии ИСО/МЭК 15408" описывает соответствие ЗБ ИСО/МЭК 15408-2; ЗБ либо описывается как соответствующее требованиям ИСО/МЭК 15408-2, либо как содержащее расширенные по отношению к ИСО/МЭК 15408-2 требования.

Для составного ОО оценщик рассматривает, совместимо ли "Утверждение о соответствии" не только с ИСО/МЭК 15408-2, но и с "Утверждениями о соответствии ИСО/МЭК 15408-2" каждого из ОО-компонентов составного ОО. Т.е. если в одном или более ОО-компонентах утверждается, что ЗБ содержит расширенные по отношению к ИСО/МЭК 15408-2 требования, то и в составном ОО тоже следует приводить утверждение о соответствии расширению относительно ИСО/МЭК 15408-2.

"Утверждение о соответствии ИСО/МЭК 15408" для составного ОО может включать утверждение о соответствии расширению ИСО/МЭК 15408-2, даже если ОО-компоненты соответствуют ИСО/МЭК 15408-2, в случае, если к базовому ОО предъявляются расширенные ФТБ (см. Руководство по составным ОО для ASE_CCL.1.6C).

ИСО/МЭК 15408-3 ASE_CCL.1.3C: В "Утверждении о соответствии ИСО/МЭК 15408" должно приводиться описание соответствия ПЗ ИСО/МЭК 15408-3; ЗБ либо описывается как соответствующее требованиям ИСО/МЭК 15408-3, либо как содержащее расширенные по отношению к ИСО/МЭК 15408-3 требования.

9.4.1.3.3 Шаг оценивания ASE_CCL.1-3

Оценщик должен проверить, что в "Утверждении о соответствии ИСО/МЭК 15408" в ЗБ описывает соответствие ЗБ ИСО/МЭК 15408-3; ЗБ либо описывается как соответствующее требованиям ИСО/МЭК 15408-3, либо как содержащее расширенные по отношению к ИСО/МЭК 15408-3 требования.

ИСО/МЭК 15408-3 ASE_CCL.1.4C: "Утверждение о соответствии ИСО/МЭК 15408" должно согласовываться с "Определением расширенных компонентов".

9.4.1.3.4 Шаг оценивания ASE_CCL.1-4

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

Если в "Утверждении о соответствии ИСО/МЭК 15408" указывается о соответствии ИСО/МЭК 15408-2, оценщик делает заключение о том, что "Определение расширенных компонентов" не определяет функциональные компоненты.

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

9.4.1.3.5 Шаг оценивания ASE_CCL.1-5

Оценщик должен исследовать "Утверждение о соответствии ИСО/МЭК 15408" в отношении ИСО/МЭК 15408-3, чтобы сделать заключение о его согласованности с "Определением расширенных компонентов".

Если в "Утверждении о соответствии ИСО/МЭК 15408" указывается о соответствии ИСО/МЭК 15408-3, оценщик делает заключение о том, что "Определение расширенных компонентов" не определяет компоненты требований доверия.

Если в "Утверждении о соответствии ИСО/МЭК 15408" указывается о соответствии расширению ИСО/МЭК 15408-3, оценщик делает заключение о том, что "Определение расширенных компонентов" определяет хотя бы один расширенный компонент требований доверия.

ИСО/МЭК 15408-3 ASE_CCL.1.5C: В "Утверждении о соответствии" должны быть идентифицированы все ПЗ и пакеты требований безопасности, о соответствии которым утверждается в ЗБ.

9.4.1.3.6 Шаг оценивания ASE_CCL.1-6

Оценщик должен проверить, что в "Утверждении о соответствии" содержится "Утверждение о соответствии ПЗ", идентифицирующее все ПЗ, о соответствии которым утверждается в ЗБ.

Если в ЗБ не утверждается о соответствии ПЗ, то этот шаг оценивания не применим и считается удовлетворенным.

Оценщик делает заключение о том, что все ПЗ, на которые имеется ссылка, однозначно идентифицированы (например, названием и номером версии или идентификацией, включенной во введение этого ПЗ).

Оценщику следует помнить, что утверждения о частичном соответствии ПЗ недопустимы. Поэтому, соответствие ПЗ, требующее составного решения, может быть указано в ЗБ для составного ОО. Соответствие такому ПЗ не было бы возможно в процессе оценки ОО-компонентов, так как такие ОО не удовлетворяют составному решению. Возможность такого соответствия будет иметься только в тех случаях, когда "составной" ПЗ допускает использование подхода к оценке композиции (использование компонентов класса АСО "Композиция").

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

9.4.1.3.7 Шаг оценивания ASE_CCL.1-7

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

Если в ЗБ не утверждается о соответствии ЗБ какому-либо пакету требований, то этот шаг оценивания не применим и считается удовлетворенным.

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

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

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

ИСО/МЭК 15408-3 ASE_CCL.1.6C: В "Утверждении о соответствии ЗБ пакету требований" должно приводиться описание любого соответствия ЗБ некоторому пакету требований; ЗБ либо описывается как соответствующее пакету требований, либо как содержащее расширенные по отношению к пакету требования.

9.4.1.3.8 Шаг оценивания ASE_CCL.1-8

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

Если в ЗБ не утверждается о соответствии ЗБ какому-либо пакету требований, то этот шаг оценивания не применим и считается удовлетворенным.

Если в утверждении о соответствии пакетам содержится утверждение о соответствии именованному пакету, оценщик делает заключение о том, что:

а) если пакет является пакетом требований доверия, то ЗБ содержит все ТДБ, включенные в пакет, но не содержит дополнительных ТДБ.

b) если пакет является функциональным, то ЗБ содержит все ФТБ, включенные в пакет, но не содержит дополнительных ФТБ.

Если в утверждении о соответствии пакетам содержится утверждение о соответствии расширению относительно именованного пакета, оценщик делает заключение о том, что:

a) если пакет является пакетом требований доверия, то ЗБ содержит все ТДБ, включенные в пакет, и по крайней мере одно дополнительное ТДБ или по крайней мере одно ТДБ, которое является иерархическим к ТДБ в пакете.

b) если пакет является функциональным, то ЗБ содержит все включенные в пакет ФТБ, и по крайней мере одно дополнительное ФТБ, или по крайней мере одно ФТБ, которое является иерархическим к ФТБ в пакете.

ИСО/МЭК 15408-3 ASE_CCL.1.7C: В "Обосновании утверждений о соответствии" должно быть продемонстрировано, что тип ОО согласуется с типом ОО в тех ПЗ, о соответствии которым утверждается.

9.4.1.3.9 Шаг оценивания ASE_CCL.1-9

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

Если в ЗБ не утверждается о соответствии ПЗ, то этот шаг оценивания не применим и считается удовлетворенным.

Отношение между типами может быть простым: например, в ЗБ межсетевого экрана утверждается о соответствии некоторому ПЗ межсетевого экрана, или более сложным: например, в ЗБ смарт-карты утверждается о соответствии нескольким ПЗ одновременно - ПЗ интегральной схемы, ПЗ для ОС смарт-карты, и двум ПЗ двух приложений на смарт-карте.

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

ИСО/МЭК 15408-3 ASE_CCL.1.8C: В "Обосновании утверждений о соответствии" должно быть продемонстрировано, что изложение определения проблемы безопасности согласуется с изложением определения проблемы безопасности в тех ПЗ, о соответствии которым утверждается.

9.4.1.3.10 Шаг оценивания ASE_CCL.1-10

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

Если в ЗБ не утверждается о соответствии ПЗ, то этот шаг оценивания не применим и считается удовлетворенным.

Если ПЗ не содержит изложение определения проблемы безопасности, то этот шаг оценивания не применим и считается удовлетворенным.

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

a) набор угроз в ЗБ расширенным или идентичным по отношению к перечню угроз в ПЗ, соответствие которому утверждается;

b) набор ПБОр в ЗБ расширенным или идентичным по отношению к ПБОр в ПЗ, соответствие которому утверждается;

c) набор предположений в ЗБ идентичным по отношению к предположениям в ПЗ, соответствие которому утверждается.

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

В качестве руководства о том, что считать "эквивалентным или более ограничительным" изложением, см. ИСО/МЭК 15408-1, приложение D "Соответствие ПЗ".

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

a) изложение угроз и ПБОр в ЗБ составного ОО не противоречат изложениям в ЗБ ОО-компонентов;

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

ИСО/МЭК 15408-3 ASE_CCL.1.9C: В "Обосновании утверждений о соответствии" должно быть продемонстрировано, что изложение "Целей безопасности" согласуется с изложением "Целей безопасности" в тех ПЗ, о соответствии которым утверждается.

9.4.1.3.11 Шаг оценивания ASE_CCL.1-11

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

Если в ЗБ не утверждается о соответствии ПЗ, то этот шаг оценивания не применим и считается удовлетворенным.

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

- ЗБ все цели безопасности для ОО того ПЗ, о соответствии которому утверждается. Следует отметить, что в оцениваемом ЗБ могут быть дополнительные цели безопасности для ОО;

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

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

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

В качестве руководства о том, что считать "эквивалентным или более ограничительным" изложением, см. ИСО/МЭК 15408-1, приложение D "Соответствие ПЗ".

Для составного ОО оценщик рассматривает, соответствуют ли "Цели безопасности" составного ОО определенным в ЗБ для ОО-компонентов. Заключение делается в виде демонстрируемого соответствия. В частности, оценщик исследует "Обоснование утверждений о соответствии", чтобы сделать заключение о том, что:

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

b) изложение "Целей безопасности" в составном ЗБ согласуется с изложением "Целей безопасности" в ЗБ ОО-компонентов.

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

ИСО/МЭК 15408-3 ASE_CCL.1.10C: В "Обосновании утверждений о соответствии" должно быть продемонстрировано, что изложение "Требований безопасности" согласуется с изложением "Требований безопасности" в тех ПЗ, о соответствии которым утверждается.

9.4.1.3.12 Шаг оценивания ASE_CCL.1-12

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

Если в ЗБ не утверждается о соответствии профилю защиты, то этот шаг оценивания не применим и считается удовлетворенным.

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

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

В качестве руководства о том, что считать "эквивалентным или более ограничительным" изложением, см. ИСО/МЭК 15408-1, приложение D "Соответствие ПЗ".

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

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

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

c) изложение "Требований безопасности" в составном ЗБ согласуется с изложением "Требований безопасности" в ЗБ ОО-компонентов.

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

9.5 "Определение проблемы безопасности" (ASE_SPD)

9.5.1 Подвид деятельности по оценке (ASE_SPD.1)

9.5.1.1 Цели

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

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

Свидетельством оценки для этого подвида деятельности является ЗБ.

9.5.1.3 Действие ASE_SPD.1.1E

ИСО/МЭК 15408-3 ASE_SPD.1.1C: "Определение проблемы безопасности" должно содержать описание угроз.

9.5.1.3.1 Шаг оценивания ASE_SPD.1-1

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

Если все цели безопасности получены из предположений и/или только из ПБОр, изложение угроз не обязательно должно присутствовать в ЗБ. В этом случае этот шаг оценивания не применим и считается удовлетворенным.

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

ИСО/МЭК 15408-3 ASE_SPD.1.2C: Описание всех угроз должно проводиться в терминах источника угрозы, активов и негативного действия.

9.5.1.3.2 Шаг оценивания ASE_SPD.1-2

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

Если все цели безопасности получены из предположений и/или только из ПБОр, изложение угроз не обязательно должно присутствовать в ЗБ. В этом случае этот шаг оценивания не применим и считается удовлетворенным.

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

ИСО/МЭК 15408-3 ASE_SPD.1.3C: В "Определение проблемы безопасности" должно быть включено описание ПБОр.

9.5.1.3.3 Шаг оценивания ASE_SPD.1-3

Оценщик должен проверить, что "Определение проблемы безопасности" включает описание ПБОр.

Если все цели безопасности получены из предположений и/или только из ПБОр, изложение угроз не обязательно должно присутствовать в ЗБ. В этом случае этот шаг оценивания не применим и считается удовлетворенным.

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

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

ИСО/МЭК 15408-3 ASE_SPD.1.4C: "Определение проблемы безопасности" должно содержать описание предположений относительно среды функционирования ОО.

9.5.1.3.4 Шаг оценивания ASE_SPD.1-4

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

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

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

9.6 Цели безопасности (ASE_OBJ)

9.6.1 Подвид деятельности по оценке (ASE_OBJ.1)

9.6.1.1 Цели

Цель данного подвида деятельности - сделать заключение о том, четко ли определены цели безопасности для среды функционирования.

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

Свидетельством оценки для этого подвида деятельности является ЗБ.

9.6.1.3 Действие ASE_OBJ.1.1E

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

9.6.1.3.1 Шаг оценивания ASE_OBJ.1-1

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

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

9.6.2 Подвид деятельности по оценке (ASE_OBJ.2)

9.6.2.1 Цели

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

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

Свидетельством оценки для этого подвида деятельности является ЗБ.

9.6.2.3 Действие ASE_OBJ.2.1Е

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

9.6.2.3.1 Шаг оценивания ASE_OBJ.2-1

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

Оценщик проверяет, что обе категории "Целей безопасности" ясно идентифицированы и отделены друг от друга.

ИСО/МЭК 15408-3 ASE_OBJ.2.2C: В "Обосновании целей безопасности" каждая цель безопасности для ОО должна быть прослежена к угрозам, на противостояние которым направлена эта цель безопасности, и к ПБОр, на осуществление которых направлена эта цель безопасности.

9.6.2.3.2 Шаг оценивания ASE_OBJ.2-2

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

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

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

ИСО/МЭК 15408-3 ASE_OBJ.2.3C: В "Обосновании целей безопасности" каждая цель безопасности для ОО должна быть прослежена к угрозам, на противостояние которым направлена эта цель безопасности, к ПБОр, на осуществление которых направлена эта цель безопасности, а также к предположениям, поддерживаемым данной целью безопасности.

9.6.2.3.3 Шаг оценивания ASE_OBJ.2-3

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

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

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

ИСО/МЭК 15408-3 ASE_OBJ.2.4C: В "Обосновании целей безопасности" должно быть продемонстрировано, что цели безопасности направлены на противостояние всем идентифицированным угрозам.

9.6.2.3.4 Шаг оценивания ASE_OBJ.2-4

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

Если ни одна цель безопасности не прослежена к конкретной угрозе, то результат данного шага оценивания отрицательный (выносится отрицательный вердикт).

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

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

Следует отметить, что прослеживание целей безопасности к угрозам в "Обосновании целей безопасности" может быть частью логического обоснования, но само по себе оно не является логическим обоснованием. Даже в том случае, когда цель безопасности является просто заявлением, отражающим намерение предотвратить реализацию конкретной угрозы, то все равно требуется логическое обоснование, хотя в этом случае оно может быть минимальным и иметь вид: "Цель безопасности X непосредственно противостоит Угрозе Y".

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

ИСО/МЭК 15408-3 ASE_OBJ.2.5C: В "Обосновании целей безопасности" должно быть продемонстрировано, что цели безопасности направлены на осуществление всех ПБОр.

9.6.2.3.5 Шаг оценивания ASE_OBJ.2-5

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

Если ни одна цель безопасности не прослежена к определенной ПБОр, то результат данного шага оценивания отрицательный (выносится отрицательный вердикт).

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

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

Следует отметить, что прослеживание целей безопасности к ПБОр в "Обосновании целей безопасности" может быть частью логического обоснования, но само по себе оно не является логическим обоснованием. Даже в том случае, когда цель безопасности является просто заявлением, отражающим намерение реализовать конкретную ПБОр, то все равно требуется логическое обоснование, хотя в этом случае оно может быть минимальным и иметь вид: "Цель безопасности X непосредственно обеспечивает осуществление ПБОр Y".

ИСО/МЭК 15408-3 ASE_OBJ.2.6C: В "Обосновании целей безопасности" должно быть продемонстрировано, что цели безопасности для среды функционирования поддерживают все предположения.

9.6.2.3.6 Шаг оценивания ASE_OBJ.2-6

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

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

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

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

Следует отметить, что прослеживание целей безопасности для среды функционирования к предположениям в "Обосновании целей безопасности" может быть частью логического обоснования, но само по себе оно не является логическим обоснованием. Даже в том случае, когда цель безопасности для среды функционирования представляет собой просто перефразированное предположение, то все равно требуется логическое обоснование, хотя в этом случае оно может быть минимальным и иметь вид: "Цель безопасности X непосредственно обеспечивает выполнение Предположения Y".

9.7 Определение расширенных компонентов (ASE_ECD)

9.7.1 Подвид деятельности по оценке (ASE_ECD.1)

9.7.1.1 Цели

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

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

Свидетельством оценки для этого подвида деятельности является ЗБ.

9.7.1.3 Действие ASE_ECD.1.1E

ИСО/МЭК 15408-3 ASE_ECD.1.1С: В изложении "Требований безопасности" должны быть идентифицированы все расширенные требования безопасности.

9.7.1.3.1 Шаг оценивания ASE_ECD.1-1

Оценщик должен проверить, что все требования безопасности в изложении "Требований безопасности", которые не идентифицированы как расширенные требования, присутствуют в ИСО/МЭК 15408-2 или в ИСО/МЭК 15408-3.

ИСО/МЭК 15408-3 ASE_ECD.1.2C: В "Определении расширенных компонентов" должен определяться расширенный компонент для каждого расширенного требования безопасности.

9.7.1.3.2 Шаг оценивания ASE_ECD.1-2

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

Если ЗБ не содержит расширенные требования безопасности, то этот шаг оценивания не применим и считается удовлетворенным.

Единственный расширенный компонент может быть использован для определения множественных итераций расширенного требования безопасности, не обязательно повторять это определение для каждой итерации данного требования.

ИСО/МЭК 15408-3 ASE_ECD.1.3C: В "Определении расширенных компонентов" должно указываться, как каждый расширенный компонент связан с существующими компонентами, семействами и классами ИСО/МЭК 15408.

9.7.1.3.3 Шаг оценивания ASE_ECD.1-3

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

Если ЗБ не содержит расширенные требования безопасности, то этот шаг оценивания не применим и считается удовлетворенным.

Оценщик делает заключение о том, что каждый расширенный компонент является:

a) компонентом семейства ИСО/МЭК 15408-2 или ИСО/МЭК 15408-3, или

b) компонентом нового семейства, определенного в ЗБ.

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

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

Если ЗБ определяет новые семейства, оценщик делает заключение о том, что каждое новое семейство или:

a) входит в состав существующего класса ИСО/МЭК 15408-2 или ИСО/МЭК 15408-3, или

b) входит в состав нового класса, определенного в ЗБ.

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

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

9.7.1.3.4 Шаг оценивания ASE_ECD.1-4

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

Если ЗБ не содержит расширенные требования безопасности, то этот шаг оценивания не применим и считается удовлетворенным.

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

ИСО/МЭК 15408-3 ASE_ECD.1.4C: В "Определении расширенных компонентов" должны использоваться в качестве модели представления компоненты, семейства, классы и методология ИСО/МЭК 15408.

9.7.1.3.5 Шаг оценивания ASE_ECD.1-5

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

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

Оценщик делает заключение о том, что расширенный функциональный компонент согласуется с пунктом 6.1.3 "Структура компонента" ИСО/МЭК 15408-2.

Если расширенный функциональный компонент использует операции, оценщик делает заключение о том, что расширенный функциональный компонент согласуется с подразделом 7.1 "Операции" ИСО/МЭК 15408-1.

Если расширенный функциональный компонент находится в иерархической зависимости по отношению к существующему функциональному компоненту, оценщик делает заключение о том, что расширенный функциональный компонент согласуется с пунктом 6.2.1 "Выделение изменений в компоненте" ИСО/МЭК 15408-2.

9.7.1.3.6 Шаг оценивания ASE_ECD.1-6

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

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

Оценщик делает заключение о том, что все новые функциональные семейства определяются в соответствии с пунктом 6.1.2 "Структура семейства" ИСО/МЭК 15408-2.

9.7.1.3.7 Шаг оценивания ASE_ECD.1-7

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

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

Оценщик делает заключение о том, что все новые функциональные классы определяются в соответствии с пунктом 6.1.1 "Структура класса" ИСО/МЭК 15408-2.

9.7.1.3.8 Шаг оценивания ASE_ECD.1-8

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

Если ЗБ не содержит расширенные ТДБ, то этот шаг оценивания не применим и считается удовлетворенным.

Оценщик делает заключение о том, что "Определение расширенных компонентов" согласуется с пунктом 6.1.3 "Структура компонента" ИСО/МЭК 15408-3.

Если расширенный компонент доверия использует операции, оценщик делает заключение о том, что расширенный компонент доверия согласуется с подразделом 7.1 "Операции" ИСО/МЭК 15408-1.

Если расширенный компонент доверия находится в иерархической зависимости по отношению к существующему компоненту доверия, оценщик делает заключение о том, что расширенный компонент доверия согласуется с пунктом 6.1.3 "Структура компонента" ИСО/МЭК 15408-3.

9.7.1.3.9 Шаг оценивания ASE_ECD.1-9

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

Если ЗБ не содержит расширенные ТДБ, то этот шаг оценивания не применим и считается удовлетворенным.

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

9.7.1.3.10 Шаг оценивания ASE_ECD.1-10

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

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

Оценщик делает заключение о том, что все новые семейства требований доверия определяются в соответствии с пунктом 6.1.2 "Структура семейства" ИСО/МЭК 15408-3.

9.7.1.3.11 Шаг оценивания ASE_ECD.1-11

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

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

Оценщик делает заключение о том, что все новые классы доверия определяются в соответствии с пунктом 6.1.1 "Структура класса" ИСО/МЭК 15408-3.

ИСО/МЭК 15408-3 ASE_ECD.1.5C: Расширенные компоненты должны состоять из измеримых объективных элементов, чтобы была возможность продемонстрировать соответствие или несоответствие этим элементам.

9.7.1.3.12 Шаг оценивания ASE_ECD.1-12

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

Если ЗБ не содержит расширенные требования безопасности, то этот шаг оценивания не применим и считается удовлетворенным.

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

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

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

9.7.1.4 Действие ASE_ECD.1.2E

9.7.1.4.1 Шаг оценивания ASE_ECD.1-13

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

Если ЗБ не содержит расширенные требования безопасности, этот шаг оценивания не применим и считается удовлетворенным.

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

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

9.8 Требования безопасности ИТ (ASE_REQ)

9.8.1 Подвид деятельности по оценке (ASE_REQ.1)

9.8.1.1 Цели

Цель данного подвида деятельности - сделать заключение, является ли описание ФТБ и ТДБ ясным, четким, полным и внутренне непротиворечивым.

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

Свидетельством оценки для этого подвида деятельности является ЗБ.

9.8.1.3 Действие ASE_REQ.1.1E

ИСО/МЭК 15408-3 ASE_REQ.1.1С: В изложении "Требований безопасности" должно быть включено описание ФТБ и ТДБ.

9.8.1.3.1 Шаг оценивания ASE_REQ.1-1

Оценщик должен проверить, что изложение "Требований безопасности" содержит описание ФТБ.

Оценщик делает заключение о том, что каждое ФТБ идентифицировано одним из следующих способов:

a) ссылкой на конкретный компонент ИСО/МЭК 15408-2;

b) ссылкой на расширенный компонент в "Определении расширенных компонентов" ЗБ;

c) ссылкой на ПЗ, с которым утверждается соответствие в ЗБ;

d) ссылкой на пакет требований безопасности, с которым утверждается соответствие ЗБ;

e) с помощью воспроизведения в ЗБ.

Не обязательно использовать одинаковые способы идентификации для всех ФТБ.

9.8.1.3.2 Шаг оценивания ASE_REQ.1-2

Оценщик должен проверить, что изложение "Требований безопасности" содержит описание ТДБ.

Оценщик делает заключение о том, что каждое ТДБ идентифицировано одним из следующих способов:

a) ссылкой на конкретный компонент ИСО/МЭК 15408-3;

b) ссылкой на расширенный компонент в "Определении расширенных компонентов" ЗБ;

c) ссылкой на ПЗ, с которым утверждается соответствие в ЗБ;

d) ссылкой на пакет требований безопасности, с которым утверждается соответствие ЗБ;

e) с помощью воспроизведения в ЗБ.

Не обязательно использовать одинаковые способы идентификации для всех ТДБ.

ИСО/МЭК 15408-3 ASE_REQ.1.2C: Все субъекты, объекты, операции, атрибуты безопасности, внешние сущности и другие понятия, используемые в ФТБ и ТДБ, должны быть определены.

9.8.1.3.3 Шаг оценивания ASE_REQ.1-3

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

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

- субъекты и объекты (их типы), используемые в ФТБ;

- атрибуты безопасности субъектов (их типы), пользователей, объектов, информации, сеансов и/или ресурсов, возможные значения, которые могут принимать данные атрибуты и любые отношения между этими значениями (например, "Совершенно секретно" выше, чем "Секретно");

- операции (их типы), которые используются в ФТБ, включая результаты этих операций;

- внешние сущности (их типы) в ФТБ;

- прочие понятия, которые введены в ФТБ и/или ТДБ путем выполнения операций, если эти понятия не являются ясными без объяснения или использованы вне их словарных значений.

Цель этого шага оценивания состоит в том, чтобы удостовериться, чтобы ФТБ и ТДБ были четко определены и что нет возможности их недопонимания или неверной интерпретации из-за употребления неопределенных терминов. При выполнении этого шага оценивания не следует доходить до крайностей, вынуждая автора ЗБ определять каждое слово. Предполагается, что у широкой аудитории, на которую рассчитан набор требований безопасности, есть понимание ИТ в целом, основ информационной безопасности и знание "Критериев оценки безопасности информационных технологий".

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

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

ИСО/МЭК 15408-3 ASE_REQ.1.3C: Изложение "Требований безопасности" должно идентифицировать все выполненные над требованиями безопасности операции.

9.8.1.3.4 Шаг оценивания ASE_REQ.1-4

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

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

ИСО/МЭК 15408-3 ASE_REQ.1.4C: Все операции должны выполняться правильно.

9.8.1.3.5 Шаг оценивания ASE_REQ.1-5

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

Руководство по правильному выполнению операций представлено в приложении С "Руководство по выполнению операций" ИСО/МЭК 15408-1.

9.8.1.3.6 Шаг оценивания ASE_REQ.1-6

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

Руководство по правильному выполнению операций представлено в приложении С "Руководство по выполнению операций" ИСО/МЭК 15408-1.

9.8.1.3.7 Шаг оценивания ASE_REQ.1-7

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

Руководство по правильному выполнению операций представлено в приложении С "Руководство по выполнению операций" ИСО/МЭК 15408-1.

9.8.1.3.8 Шаг оценивания ASE_REQ.1-8

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

Руководство по правильному выполнению операций представлено в приложении С "Руководство по выполнению операций" ИСО/МЭК 15408-1.

ИСО/МЭК 15408-3 ASE_REQ.1.5C: Каждая зависимость от требований безопасности должна быть либо удовлетворена, либо должно приводиться обоснование неудовлетворения данной зависимости.

9.8.1.3.9 Шаг оценивания ASE_REQ.1-9

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

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

В логическом обосновании того, что зависимость не удовлетворена, следует указывать либо:

a) почему зависимость не является полезной или необходимой, в этом случае не требуется предоставлять дополнительную информацию; либо

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

ИСО/МЭК 15408-3 ASE_REQ.1.6C: Изложение "Требований безопасности" должно быть внутренне непротиворечивым.

9.8.1.3.10 Шаг оценивания ASE_REQ.1-10

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

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

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

Некоторые примеры возможных конфликтов:

a) расширенное ТДБ определяет, что проект некоторого криптографического алгоритма должен содержаться в секрете, а другое расширенное ТДБ предписывает свободный доступ к просмотру его исходных кодов;

b) компонент FAU_GEN.1 "Генерация данных аудита безопасности" определяет, что идентификатор субъекта должен регистрироваться в журнале; компонент FDP_ACC.1 "Ограниченное управление доступом" определяет, кто имеет права доступа к этим журналам, а компонент FPR_UNO.1 "Скрытность" определяет, что рекомендуется, чтобы некоторые действия субъектов не были доступны для просмотра другим субъектам. Если субъект, которому не следует иметь возможность видеть действия других субъектов, может получить доступ к журналам регистрации данных действий, эти ФТБ являются конфликтующими;

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

d) многократные итерации компонента FDP_ACC.1 "Ограниченное управление доступом", особенно если некоторые итерации касаются одних и тех же субъектов, объектов или операций. Если одно ФТБ по управлению доступом позволяет субъекту выполнять операцию над объектом, тогда как другое ФТБ по управлению доступом не позволяет это, эти требования являются конфликтующими.

9.8.2 Подвид деятельности по оценке (ASE_REQ.2)

9.8.2.1 Цели

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

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

Свидетельством оценки для этого подвида деятельности является ЗБ.

9.8.2.3 Действие ASE_REQ.2.1E

ИСО/МЭК 15408-3 ASE_REQ.2.1C: Изложение "Требований безопасности" должно содержать описание ФТБ и ТДБ.

9.8.2.3.1 Шаг оценивания ASE_REQ.2-1

Оценщик должен проверить, что изложение "Требований безопасности" содержит описание ФТБ.

Оценщик делает заключение о том, что каждое ФТБ идентифицировано одним из следующих способов:

a) ссылкой на конкретный компонент ИСО/МЭК 15408-2;

b) ссылкой на расширенный компонент в "Определении расширенных компонентов" ЗБ;

c) ссылкой на конкретный компонент ПЗ, о соответствии с которым утверждается в ЗБ;

d) ссылкой на конкретный компонент в пакете требований безопасности, о соответствии с которым утверждается в ЗБ;

e) с помощью воспроизведения в ЗБ.

Не обязательно использовать одинаковые способы идентификации для всех ФТБ.

9.8.2.3.2 Шаг оценивания ASE_REQ.2-2

Оценщик должен проверить, что изложение "Требований безопасности" содержит описание ТДБ.

Оценщик делает заключение о том, что каждое ТДБ идентифицировано одним из следующих способов:

a) ссылкой на конкретный компонент ИСО/МЭК 15408-3;

b) ссылкой на расширенный компонент в "Определении расширенных компонентов" ЗБ;

c) ссылкой на конкретный компонент в ПЗ, о соответствии с которым утверждается в ЗБ;

d) ссылкой на конкретный компонент в пакете требований безопасности, о соответствии с которым утверждается в ЗБ;

e) с помощью воспроизведения в ЗБ.

Не обязательно использовать одинаковые способы идентификации для всех ТДБ.

ИСО/МЭК 15408-3 ASE_REQ.2.2C: Все субъекты, объекты, операции, атрибуты безопасности, внешние сущности и другие понятия, используемые в ФТБ и ТДБ, должны быть определены.

9.8.2.3.3 Шаг оценивания ASE_REQ.2-3

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

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

- субъекты и объекты (их типы), используемые в ФТБ;

- атрибуты безопасности субъектов (их типы), пользователей, объектов, информации, сеансов и/или ресурсов, возможные значения, которые могут принимать данные атрибуты и любые отношения между этими значениями (например, "Совершенно секретно" выше, чем "Секретно");

- операции (их типы), которые используются в ФТБ, включая результаты выполнения этих операций;

- внешние сущности (их типы) в ФТБ;

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

Цель этого шага оценивания состоит в том, чтобы удостовериться, что ФТБ и ТДБ четко определены и что не может произойти их неправильного понимания из-за употребления неопределенных терминов. При выполнении этого шага оценивания не следует доходить до крайностей, вынуждая автора ЗБ определять каждое слово. Предполагается, что у широкой аудитории, на которую рассчитан набор требований безопасности, есть понимание ИТ в целом, основ информационной безопасности и знание "Критериев оценки безопасности информационных технологий".

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

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

ИСО/МЭК 15408-3 ASE_REQ.2.3C: В изложении "Требований безопасности" должны быть идентифицированы все выполненные над требованиями безопасности операции.

9.8.2.3.4 Шаг оценивания ASE_REQ.2-4

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

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

ИСО/МЭК 15408-3 ASE_REQ.2.4C: Все операции должны выполняться правильно.

9.8.2.3.5 Шаг оценивания ASE_REQ.2-5

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

Руководство по правильному выполнению операций представлено в приложении С "Руководство по выполнению операций" ИСО/МЭК 15408-1.

9.8.2.3.6 Шаг оценивания ASE_REQ.2-6

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

Руководство по правильному выполнению операций представлено в приложении С "Руководство по выполнению операций" ИСО/МЭК 15408-1.

9.8.2.3.7 Шаг оценивания ASE_REQ.2-7

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

Руководство по правильному выполнению операций представлено в приложении С "Руководство по выполнению операций" ИСО/МЭК 15408-1.

9.8.2.3.8 Шаг оценивания ASE_REQ.2-8

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

Руководство по правильному выполнению операций представлено в приложении С "Руководство по выполнению операций" ИСО/МЭК 15408-1.

ИСО/МЭК 15408-3 ASE_REQ.2.5C: Каждая зависимость от "Требований безопасности" должна быть либо удовлетворена, либо должно приводиться обоснование неудовлетворения зависимости.

9.8.2.3.9 Шаг оценивания ASE_REQ.2-9

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

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

В логическом обосновании того, что зависимость не удовлетворена, следует указать либо:

a) то, почему зависимость не является полезной или необходимой, при этом не требуется предоставлять дополнительную информацию; либо

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

ИСО/МЭК 15408-3 ASE_REQ.2.6C: В "Обосновании требований безопасности" должно быть представлено прослеживание каждого ФТБ к целям безопасности для ОО.

9.8.2.3.10 Шаг оценивания ASE_REQ.2-10

Оценщик должен проверить, прослежены ли ФТБ в "Обосновании требований безопасности" к целям безопасности для ОО.

Оценщик делает заключение, прослежено ли каждое ФТБ по крайней мере к одной цели безопасности для ОО.

Неудача при попытке такого прослеживания означает, что либо "Обоснование требований безопасности" является неполным, либо цели безопасности для ОО являются неполными, либо ФТБ являются бесполезными.

ИСО/МЭК 15408-3 ASE_REQ.2.7C: В "Обосновании требований безопасности" должно быть продемонстрировано, что ФТБ обеспечивают выполнение всех целей безопасности для ОО.

9.8.2.3.11 Шаг оценивания ASE_REQ.2-11

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

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

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

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

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

ИСО/МЭК 15408-3 ASE_REQ.2.8C: В "Обосновании требований безопасности" должно приводиться пояснение того, почему выбраны определенные ТДБ.

9.8.2.3.12 Шаг оценивания ASE_REQ.2-12

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

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

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

ИСО/МЭК 15408-3 ASE_REQ.2.9С: Изложение "Требований безопасности" должно быть внутренне непротиворечивым.

9.8.2.3.13 Шаг оценивания ASE_REQ.2-13

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

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

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

Некоторые примеры возможных конфликтов:

a) в расширенном ТДБ определяется, что проект некоторого криптографического алгоритма должен содержаться в секрете, а другое расширенное ТДБ предписывает общий доступ к этим данным;

b) компонент FAU_GEN.1 "Генерация данных аудита" определяет, что некая сущность субъекта должна регистрироваться в журнале; FDP_ACC.1 "Ограниченное управление доступом" определяет, у кого есть право доступа к этим журналам и FPR_UNO.1; "Скрытность" определяет, что рекомендуется, чтобы некоторые действия субъектов не были доступны для просмотра другим субъектам. Если субъект, которому не следует иметь возможность видеть действия других субъектов, может получить доступ к журналам данных действий, эти ФТБ являются конфликтующими;

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

d) многократные итерации FDP_ACC.1 "Ограниченное управление доступом", особенно если некоторые итерации касаются одних и тех же субъектов, объектов или операций. Если одно ФТБ по управлению доступом позволяет субъекту выполнять операцию над объектом, тогда как другое ФТБ по управлению доступом не позволяет это, эти требования являются конфликтующими.

9.9 Краткая спецификация ОО (ASE_TSS)

9.9.1 Подвид деятельности по оценке (ASE_TSS.1)

9.9.1.1 Цели

Цель этого подвида деятельности состоит в том, чтобы определить, обращается ли краткая спецификация ОО ко всем ФТБ и совместима ли краткая спецификация ОО с другими описаниями ОО, в том числе составленными в повествовательной форме.

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

Свидетельством оценки для этого подвида деятельности является ЗБ.

9.9.1.3 Действие ASE_TSS.1.1E

ИСО/МЭК 15408-3 ASE_TSS.1.1С: Краткая спецификация ОО должна описывать, каким образом ОО выполняет каждое ФТБ.

9.9.1.3.1 Шаг оценивания ASE_TSS.1-1

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

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

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

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

9.9.1.4 Действие ASE_TSS.1.1E

9.9.1.4.1 Шаг оценивания ASE_TSS.1-2

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

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

9.9.2 Подвид деятельности по оценке (ASE_TSS.2)

9.9.2.1 Цели

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

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

Свидетельством оценки для этого подвида деятельности является ЗБ.

9.9.2.3 Действие ASE_TSS.2.1E

ИСО/МЭК 15408-3 ASE_TSS.2.1C: Краткая спецификация ОО должна описывать, каким образом ОО выполняет каждое ФТБ.

9.9.2.3.1 Шаг оценивания ASE_TSS.2-1

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

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

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

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

ИСО/МЭК 15408-3 ASE_TSS.2.2C: Краткая спецификация ОО должна описывать, каким образом ОО противостоит попыткам вмешательства и логического искажения.

9.9.2.3.2 Шаг оценивания ASE_TSS.2-2

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

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

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

ИСО/МЭК 15408-3 ASE_TSS.2.3C: Краткая спецификация ОО должна описывать, каким образом ОО противостоит попыткам обхода защиты.

9.9.2.3.3 Шаг оценивания ASE_TSS.2-3

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

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

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

9.9.2.4 Действие ASE_TSS.2.2E

9.9.2.4.1 Шаг оценивания ASE_TSS.2-4

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

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

10 Класс ADV: Разработка

10.1 Введение

Вид деятельности "Разработка" предназначен для того, чтобы оценить проектную документацию на предмет ее достаточности для понимания того, каким образом ФБО удовлетворяют ФТБ и возможно ли исказить или обойти реализацию этих ФТБ. Это понимание достигается путем исследования описаний в проектной документации ФБО, предоставляемых с увеличением детализации и качества описаний. Проектная документация состоит из функциональной спецификации (которая описывает интерфейсы ФБО), описания проекта ОО (которое описывает архитектуру ФБО с точки зрения того, как она обеспечивает выполнение функций, связанных с заявленными ФТБ) и описания реализации (описание на уровне исходного кода). Кроме того, в неё включается "Описание архитектуры безопасности" (которое описывает архитектурные свойства ФБО в целях объяснения того, каким образом обеспечение безопасности не может быть скомпрометировано или обойдено), описание внутреннего состава (которое описывает, как ФБО спроектированы в манере, обеспечивающей их понимание), а также модель политики безопасности (которая формально описывает политику безопасности, осуществляемую ФТБ).

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

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

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

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

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

10.3 Архитектура безопасности (ADV_ARC)

10.3.1 Подвид деятельности по оценке (ADV_ARC.1)

10.3.1.1 Цели

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

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

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

a) ЗБ;

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

c) проект ОО;

d) описание архитектуры безопасности;

e) представление реализации (при наличии);

f) руководство пользователя по эксплуатации.

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

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

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

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

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

10.3.1.4 Действие ADV_ARC.1.1E

ИСО/МЭК 15408-3 ADV_ARC.1.1C: Уровень детализации "Описания архитектуры безопасности" должен соответствовать представленному в проектной документации по ОО описанию абстракций (элементов представления ОО), осуществляющих выполнение ФТБ.

10.3.1.4.1 Шаг оценивания ADV_ARC.1-1

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

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

Если в оценку включается Подвид деятельности по оценке (ADV_TDS.1) или Подвид деятельности по оценке (ADV_TDS.2), оценщик удостоверяется в том, что "Описание архитектуры безопасности" содержит информацию о том, как функционируют подсистемы, которые способствуют разделению доменов ФБО.

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

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

ИСО/МЭК 15408-3 ADV_ARC.1.2C: В "Описании архитектуры безопасности" должно быть включено описание доменов безопасности, обеспеченных согласованностью ФБО с ФТБ.

10.3.1.4.2 Шаг оценивания ADV_ARC.1-2

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

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

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

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

10.3.1.4.3 Шаг оценивания ADV_ARC.1-3

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

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

Часто случается, что компоненты, которые выполняют эту функцию инициализации, недоступны после того, как безопасное состояние достигнуто; в этом случае "Описание архитектуры безопасности" идентифицирует компоненты и объясняет, что они недоступны для недоверенных сущностей после установления ФБО. В этом отношении необходимо сохранить свойство этих компонентов, заключающееся в том, что они либо 1) недоступны для недоверенных сущностей после достижения безопасного состояния, либо 2) в случае, если они предоставляют интерфейсы недоверенным сущностям, эти ИФБО не могут быть использованы для вмешательства в ФБО.

В этом случае, компоненты ОО, связанные с инициализацией ФБО, рассматриваются как часть ФБО и анализируются с этой точки зрения. Следует отметить, что хотя их рассматривают как часть ФБО, скорее всего, может быть сделано логическое обоснование (что допускается семейством ADV_ INT "Внутренняя структура ФБО") о том, что эти компоненты не должны отвечать требованиям по внутренней структуре из ADV_INT.

ИСО/МЭК 15408-3 ADV_ARC.1.4C: В "Описании архитектуры безопасности" должно быть продемонстрировано, что ФБО обеспечивают собственную защиту от вмешательства.

10.3.1.4.4 Шаг оценивания ADV_ARC.1-4

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

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

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

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

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

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

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

10.3.1.4.5 Шаг оценивания ADV_ARC.1-5

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

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

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

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

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

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

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

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

В качестве последнего примера использования функций безопасности, а не защищенного ресурса, рассмотрим ЗБ, которое содержит раздел FCO_NRO.2 "Принудительное доказательство отправления", где представлено требование, чтобы в ФБО были представлены свидетельства отправления для типов информации, определенных в ЗБ. Предположим, что к "типам информации" относится вся информация, которую ОО посылает через электронную почту. В этом случае оценщику следует исследовать описание, чтобы удостовериться, что все ИФБО, которые могут быть вызваны для отправки электронного письма, осуществляют функцию "свидетельство отправления" с должной степенью детализации. Описание может ссылаться на руководство пользователя для выявления всех мест отправления писем электронной почты (например, почтовая программа, уведомления скриптов/пакетных заданий) и затем того, как каждое из этих мест вызывает функцию генерации свидетельств.

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

10.4 Функциональная спецификация (ADV_FSP)

10.4.1 Подвид деятельности по оценке (ADV_FSP.1)

10.4.1.1 Цели

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

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

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

a) ЗБ;

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

c) руководство пользователя по эксплуатации.

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

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

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

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

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

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

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

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

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

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

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

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

См. пояснение по поводу идентификации осуществляющих и поддерживающих выполнение ФТБ интерфейсов в шаге оценивания ADV_FSP.1-1.

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

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

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

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

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

См. пояснение по поводу идентификации осуществляющих и поддерживающих выполнение ФТБ интерфейсов в шаге оценивания ADV_FSP.1-1.

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

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

ИСО/МЭК 15408-3 ADV_FSP.1.3C: В функциональной спецификации должно приводиться обоснование неявного категорирования интерфейсов как не влияющих на выполнение ФТБ.

10.4.1.3.4 Шаг оценивания ADV_FSP.1-4

Оценщик должен исследовать обоснование, предоставленное разработчиком для неявной классификации интерфейсов как не влияющих на выполнение ФТБ, чтобы сделать заключение о том, что это обоснование является точным.

В случае, если разработчик предоставил соответствующую документацию для проведения анализа, требуемого по остальным шагам оценивания этого компонента, явно не идентифицируя ИФБО как осуществляющие или поддерживающие ФТБ, этот шаг оценивания следует считать удовлетворенным.

Этот шаг оценивания предназначен для тех случаев, когда разработчик не описал часть ИФБО, утверждая, что они не влияют на выполнение ФТБ и поэтому не являются предметом предъявления требований данного компонента. В этом случае разработчик предоставляет обоснование для этой характеристики с достаточной степенью детализации для понимания оценщиком обоснования, особенностей затрагиваемых интерфейсов (например, их функции верхнего уровня в отношении ОО, такие как "управление палитрой цветов"), и то, что заявление о том, что интерфейсы являются не влияющими на выполнение ФТБ, поддержано. Учитывая уровень доверия, оценщику не следует ожидать более высокой степени детализации, чем при описании осуществляющих или поддерживающих ФТБ интерфейсов; фактически детализации следует быть намного меньшей. В большинстве случаев к отдельным интерфейсам не обязательно обращаться в предоставленном разработчиком подразделе "Обоснование".

ИСО/МЭК 15408-3 ADV_FSP1.4C: В прослеживании должно быть продемонстрировано прослеживание ФТБ к ИФБО в функциональной спецификации.

10.4.1.3.5 Шаг оценивания ADV_FSP.1-5

Оценщик должен проверить, что прослеживание соотносит ФТБ с соответствующими ИФБО.

Прослеживание предоставляется разработчиком в качестве руководства по тому, какие ИФБО относятся к каким ФТБ. Это прослеживание может быть представлено в простом виде, например в виде таблицы; оно используется в качестве исходных данных для оценщика при использовании в последующих шагах оценивания, в которых оценщик верифицирует полноту и точность этого прослеживания.

10.4.1.4 Действие ADV_FSP.1.2E

10.4.1.4.1 Шаг оценивания ADV_FSP.1-6

Оценщик должен исследовать функциональную спецификацию, чтобы сделать заключение, является ли она полным отображением ФТБ.

Чтобы удостовериться, что все ФТБ охвачены функциональной спецификацией, а также анализом покрытия тестами, оценщик может основываться на прослеживании, предоставленном разработчиком (см. ADV_FSP.1-5 для прослеживания между ФТБ для ОО и ИФБО). Следует учесть, что такое прослеживание иногда необходимо представлять на уровне детализации ниже, чем уровень детализации компонента или даже элемента требований, из-за операций (назначения, уточнения, выбора), выполняемых над функциональным требованием автором ЗБ.

Например, компонент FDP_ACC.1 содержит элемент с операциями назначения. Если бы в ЗБ содержалось, например, десять правил в отношении назначения для данного компонента FDP_ACC.1, и эти правила были бы охвачены тремя различными ИФБО, то для оценщика некорректно было бы проследить FDP_ACC.1 к ИФБО А, В и С и утверждать о завершении шага оценивания. Вместо этого оценщик должен был бы проследить FDP_ACC.1 (правило 1) к ИФБО A; FDP_ACC.1 (правило 2) к ИФБО В и т.д. Может иметь место и случай, когда интерфейс является интерфейсом адаптера (например, IOCTL), и тогда прослеживание должно быть определенным к набору параметров для данного интерфейса.

Оценщик должен осознавать, что для требований, которые незначительно проявляются или не проявляются вовсе на границах ФБО (например, FDP_RIP), не ожидается, что эти требования будут прослежены к ИФБО. Анализ таких требований будет выполняться в процессе анализа проекта ОО (ADV_TDS), когда он включен в ЗБ. Важно отметить, что так как параметры, связанные с ИФБО, должны быть полностью специфицированы, оценщику следует быть в состоянии сделать заключение о том, все ли аспекты ФТБ реализованы на интерфейсном уровне.

10.4.1.4.2 Шаг оценивания ADV_FSP.1-7

Оценщик должен исследовать функциональную спецификацию, чтобы сделать заключение, что она является точным отображением ФТБ.

Для каждого функционального требования в ЗБ, которое оказывает видимый эффект на границах ФБО, информация в связанном с ним ИФБО специфицирует требуемые функции, описанные в требовании. Например, если в ЗБ содержится требование наличия списков контроля доступа и единственный ИФБО, прослеживаемый к этому требованию, специфицирует функции Unix-подобных разрядов защиты, тогда функциональная спецификация не является точной в отношении требований.

Оценщик должен осознавать, что для требований, которые незначительно проявляются или не проявляются вовсе на границах ФБО (например, FDP_RIP), не ожидается, что эти требования будут прослежены к ИФБО. Анализ таких требований будет выполняться в процессе анализа проекта ОО (ADV_TDS), когда он включается в ЗБ.

10.4.2 Подвид деятельности по оценке (ADV_FSP.2)

10.4.2.1 Цели

Цель данного подвида деятельности - сделать заключение, предоставил ли разработчик описание ИФБО в терминах их назначения, метода использования и параметров. Кроме того, для каждого осуществляющего ФТБ интерфейса ФБО описываются действия, результаты и сообщения об ошибках, осуществляющие выполнение ФТБ.

10.4.2.2 Исходные данные

Свидетельствами оценки для этого подвида деятельности, требуемыми шагами оценивания, являются:

a) ЗБ;

b) функциональная спецификация;

c) проект ОО.

Свидетельствами оценки для этого подвида деятельности, которые используются в случае их включения в ЗБ по ОО, являются:

a) описание архитектуры безопасности;

b) руководство пользователя по эксплуатации.

10.4.2.3 Действие ADV_FSP.2.1E

ИСО/МЭК 15408-3 ADV_FSP2.1C: В функциональной спецификации должны быть полностью представлены ФБО.

10.4.2.3.1 Шаг оценивания ADV_FSP.2-1

Оценщик должен исследовать функциональную спецификацию, чтобы сделать заключение о том, что в ней полностью представлены ФБО.

Идентификация ИФБО - необходимая предпосылка для всех действий данного подвида деятельности. Для идентификации ИФБО должны быть идентифицированы ФБО (в рамках шагов оценивания семейства ADV_TDS "Проект ОО"). Эта деятельность может быть проведена на высоком уровне, чтобы удостовериться, что не упущены крупные группы интерфейсов (сетевых протоколов, аппаратных средств, файлов конфигурации), или на низком уровне - как часть оценки функциональной спецификации.

При проведении данного шага оценивания оценщик делает заключение о том, что все части ФБО описаны в терминах интерфейсов, перечисленных в функциональной спецификации. Для всех частей ФБО следует иметь соответствующее описание интерфейсов или, при отсутствии соответствующих интерфейсов для части ФБО, оценщик делает заключение, что такое отсутствие допустимо и приемлемо.

ИСО/МЭК 15408-3 ADV_FSP.2.2C: В функциональной спецификации должны быть описаны назначение и метод использования всех ИФБО.

10.4.2.3.2 Шаг оценивания ADV_FSP.2-2

Оценщик должен исследовать функциональную спецификацию, чтобы сделать заключение о том, что в ней указано назначение каждого ИФБО.

Назначение ИФБО - это общее утверждение, кратко описывающее функциональные возможности, предоставляемые интерфейсом. Не подразумевается, что оно должно быть полным изложением всех действий и результатов, относящихся к интерфейсу, а, скорее, оно должно помочь читателю составить общее представление о предполагаемом использовании данного интерфейса. Оценщику следует не только сделать заключение о том, что такое назначение существует и что оно точно отражает ИФБО, с учетом другой информации об интерфейсе, такой как описание действий и сообщений об ошибках.

10.4.2.3.3 Шаг оценивания ADV_FSP.2-3

Оценщик должен исследовать функциональную спецификацию, чтобы сделать заключение о том, что в ней содержится описание метода использования для каждого ИФБО.

Метод использования для ИФБО предоставляет краткую информацию по поводу того, каким образом в результате управления интерфейсом вызывают действия и получают результаты, связанные с ИФБО. Оценщику следует посредством чтения материалов в функциональной спецификации вынести заключение о том, как использовать каждый интерфейс. Это не обязательно означает, что для каждого ИФБО нужен отдельный метод использования, поскольку можно, например, описать в общем, как происходит системный вызов ядра, а затем идентифицировать каждый интерфейс, используя общий для всех интерфейсов стиль. Различные типы интерфейсов требуют различных спецификаций по методу их использования. У интерфейсов программирования приложений (API), сетевых протоколов, параметров системной конфигурации и шины аппаратных средств абсолютно разные методы использования, и это следует учитывать разработчику при разработке функциональной спецификации, так же, как и оценщику при проведении её оценки.

Для интерфейсов администрирования, функции которых документированы как недоступные недоверенным пользователям, оценщик удостоверяется в том, что метод, благодаря которому данные функции являются недоступными таким пользователям, описан в функциональной спецификации. Следует отметить, что разработчику необходимо протестировать эту недоступность при проведении испытаний.

Оценщику следует не только сделать заключение о существовании подмножества описаний методов использования, но и о том, что описания точно охватывают каждый ИФБО.

ИСО/МЭК 15408-3 ADV_FSP.2.3C: В функциональной спецификации должны быть идентифицированы и описаны все параметры, связанные с каждым ИФБО.

10.4.2.3.4 Шаг оценивания ADV_FSP.2-4

Оценщик должен исследовать представление ИФБО, чтобы сделать заключение, полностью ли идентифицированы в нем все параметры, связанные с каждым ИФБО.

Оценщик исследует функциональную спецификацию, чтобы сделать заключение, что в ней описаны все параметры для каждого ИФБО. Параметры - явные исходные данные или данные на выходе интерфейса, которые контролируют режим функционирования этого интерфейса. Например, параметрами являются: аргументы, поставляемые интерфейсу программирования приложений; различные поля в пакете для данного сетевого протокола; индивидуальные значения ключа в реестре Windows; сигналы, проходящие через контакты чипа и т.д.

Для вынесения заключения о том, что все данные параметры присутствуют в ИФБО, оценщику следует исследовать остальные описания интерфейса (действия, сообщения об ошибках и т.д.) и сделать заключение, что эффекты этих параметров перечислены в описании. Оценщику следует также проверить другие свидетельства, предоставленные для оценки (например, проект ОО, описание архитектуры безопасности, руководство пользователя по эксплуатации, представление реализации) на предмет того, есть ли там описания режимов функционирования интерфейса или дополнительных параметров, отсутствующие в функциональной спецификации.

10.4.2.3.5 Шаг оценивания ADV_FSP.2-5

Оценщик должен исследовать представление ИФБО, чтобы сделать заключение, полно ли и точно ли описаны в нем все параметры, связанные с каждым ИФБО.

Как только все параметры идентифицированы, оценщику нужно удостовериться, что они описаны точно и что описание параметров проведено полно. Описание параметра некоторым значащим образом определяет, что представляет собой данный параметр. Например, интерфейс foo (i) может быть описан как имеющий "параметр i", который является целым числом"; но такое описание параметра не приемлемо. Более приемлемое описание - "параметр i - целое число, указывающее на число пользователей, которые в настоящий момент зарегистрированы в системе".

Для вынесения заключения о том, что описание параметра является полным, оценщику следует исследовать остальные описания интерфейса (назначение, метод использования, действия интерфейса, сообщения об ошибках и т.д.) и сделать заключение о том, что описания этих параметров перечислены в описании. Оценщику следует также проверить другие предоставленные свидетельства (например, проект ОО, проект архитектуры, руководство пользователя по эксплуатации, представление реализации) на предмет того, есть ли там описания режима функционирования интерфейса или его дополнительных параметров, отсутствующие в функциональной спецификации.

ИСО/МЭК 15408-3 ADV_FSP.2.4C: Для каждого ИФБО, осуществляющего выполнение ФТБ, функциональная спецификация должна содержать описание связанных с данным ИФБО действий, осуществляющих выполнение ФТБ.

10.4.2.3.6 Шаг оценивания ADV_FSP.2-6

Оценщик должен исследовать представление ИФБО, чтобы сделать заключение о том, что в нем полно и точно описаны все осуществляющие выполнение ФТБ действия, связанные с осуществляющими выполнение ФТБ интерфейсами.

Если действие, доступное через интерфейс, может быть прослежено к одному из ФТБ по ФБО, то этот интерфейс является осуществляющим выполнение ФТБ. Это относится не только к политикам управления доступом, но также и к любым функциям, определенным одним из ФТБ, содержащимся в ЗБ. Следует отметить, что у интерфейса могут быть различные действия и результаты его вызова, некоторые из которых могут быть осуществляющими ФТБ, а некоторые - нет.

От разработчика не требуется "маркировать" интерфейсы как осуществляющие выполнение ФТБ, и также не требуется идентифицировать доступные через интерфейс действия как осуществляющие выполнение ФТБ. Оценщик обязан исследовать свидетельства, представленные разработчиком, и сделать заключение о том, что требуемая информация в них присутствует. В случае, если разработчик идентифицировал осуществляющие выполнение ФТБ ИФБО и доступные через эти ИФБО осуществляющие выполнение ФТБ действия, оценщик должен оценить полноту и точность данной идентификации, основываясь на информации, поставленной для оценки (например, на проекте ОО, описании архитектуры безопасности, руководстве пользователя по эксплуатации), и информации, представленной для данных интерфейсов (параметры и описания этих параметров, сообщения об ошибках и т.д.).

В этом случае (когда разработчик предоставил только касающуюся осуществления выполнения ФТБ информацию для осуществляющих выполнение ФТБ интерфейсов) оценщик также удостоверяется в том, что все интерфейсы правильно категорированы путем исследования информации, предоставленной для оценки (например, проекта ОО, описания архитектуры безопасности, руководства пользователя по эксплуатации), и информации по интерфейсам (параметров и описаний этих параметров, например, не идентифицированным как осуществляющие выполнение ФТБ).

В случае, если разработчик предоставил информацию одинаковой степени полноты и детализации для всех интерфейсов, оценщик выполняет такой же анализ, описанный в предыдущих параграфах. Оценщику следует сделать заключение о том, какие интерфейсы являются осуществляющими выполнение ФТБ, а какие не являются, а затем удостовериться в том, что осуществляющие выполнение ФТБ аспекты осуществляющих выполнение ФТБ действий правильно описаны.

Осуществляющие выполнение ФТБ действия - это те, которые видимы в любом внешнем интерфейсе и предусматривают удовлетворение предъявляемых ФТБ. Например, если требования по аудиту включены в ЗБ, то связанные с аудитом действия являются осуществляющими выполнение ФТБ и поэтому должны быть описаны, даже если результат этого действия обычно невозможно наблюдать через вызванный интерфейс (при проведении аудита обычной является ситуация, когда пользовательское действие в одном интерфейсе производит контрольный отчет, видимый только через другой интерфейс).

Требуемый уровень описания - достаточный для того, чтобы читатель понял роль действий ИФБО по отношению к ФТБ. Оценщику следует иметь в виду, что рекомендуется, чтобы описание было детализировано в достаточной мере для поддержки создания (и оценки) тестовых ситуаций для данного интерфейса. Если описание неясно или недостаточно детализировано и поэтому значимое тестирование ИФБО не может быть проведено, скорее всего, описание является несоответствующим предъявляемым к нему требованиям.

ИСО/МЭК 15408-3 ADV_FSP.2.5C: Для ИФБО, осуществляющих выполнение ФТБ, функциональная спецификация должна содержать описание сообщений о непосредственных ошибках, возникающих в результате функционирования, связанного с действиями, осуществляющими выполнение ФТБ.

10.4.2.3.7 Шаг оценивания ADV_FSP.2-7

Оценщик должен исследовать представление ИФБО, чтобы сделать заключение о том, что в нем полно и точно описаны сообщения о связанных с осуществляющими выполнение ФТБ интерфейсами ошибках, которые могут быть последствием действий, осуществляющих выполнение ФТБ.

Этот шаг оценивания следует выполнять вместе с шагом оценивания ADV_FSP.2-6 или после него, чтобы удостовериться, что набор осуществляющих выполнение ФТБ интерфейсов и осуществляющих выполнение ФТБ действий правильно идентифицирован. Разработчик может предоставить больше информации, чем требуется (например, все сообщения об ошибках, связанные с каждым интерфейсом). В этом случае оценщику следует ограничиться при оценке полноты и точности этой информации рассмотрением только той информации, которая относится к осуществляющим выполнение ФТБ действиям осуществляющих выполнение ФТБ интерфейсов.

Ошибки могут принимать различные формы, в зависимости от описываемого интерфейса. В случае интерфейса программирования приложений интерфейс сам может вернуть код ошибки, установить состояние глобальной ошибки или определенный параметр с кодом ошибки. В случае файла конфигурации неправильно настроенный параметр может привести к появлению в системном журнале сообщения об ошибке. В случае аппаратных средств, например шины ввода/вывода, возникновение ошибки может подать на шину сигнал или вызвать особое состояние центрального процессора.

Ошибки (и связанные с ними сообщения об ошибках) проявляются через запрос интерфейса. Обработка, которая происходит в ответ на запрос интерфейса, может столкнуться с некоторыми условиями, вызывающими ошибку и сообщение об этой ошибке (путем определенного механизма, специфического для данной реализации). В некоторых случаях это может быть возвращаемое самим интерфейсом значение; в других случаях глобальное значение может быть назначено и проверено после запроса интерфейса. Скорее всего, в ОО будет много сообщений об ошибках низкого уровня, которые являются результатом фундаментальных условий для ресурсов, например "недостаточно места на диске" или "ресурс заблокирован". Несмотря на то что эти сообщения об ошибках могут быть прослежены к большому количеству ИФБО, их можно использовать для выявления тех случаев, когда часть описания интерфейса была опущена. Например, если есть ИФБО, который выдает сообщение "недостаточно места на диске", но для которого не представлено ясное описание того, почему этому ИФБО следует позволять получение доступа к диску, оценщику может потребоваться исследовать другие свидетельства (семейств ADV_ARC "Архитектура безопасности", ADV_TDS "Проект ОО"), связанные с этим ИФБО, чтобы сделать заключение о том, является ли точным его описание.

Чтобы вынести заключение о том, что описание сообщений об ошибках ИФБО составлено точно и полно, оценщик сравнивает длину данного описания интерфейса с другими представленными для оценки свидетельствами (например, с проектом ОО, описанием архитектуры безопасности, руководством пользователя по эксплуатации), а также с другими свидетельствами по данному ИФБО (его параметрами, результатами шага оценивания ADV_FSP.2-6).

ИСО/МЭК 15408-3 ADV_FSP.2.6C: В прослеживании соответствия должно быть продемонстрировано прослеживание ФТБ к ИФБО в функциональной спецификации.

10.4.2.3.8 Шаг оценивания ADV_FSP.2-8

Оценщик должен проверить, что прослеживание соотносит ФТБ с соответствующими ИФБО.

Прослеживание предоставляется разработчиком в качестве руководства для определения того, каким образом ФТБ связаны с ИФБО. Это прослеживание может быть представлено в простом виде, например в виде таблицы; оно используется в качестве исходных данных для оценщика для использования в последующих шагах оценивания, в которых оценщик верифицирует полноту и точность этого прослеживания.

10.4.2.4 Действие ADV_FSP.2.2E

10.4.2.4.1 Шаг оценивания ADV_FSP.2-9

Оценщик должен исследовать функциональную спецификацию, чтобы сделать заключение, является ли она полным отображением ФТБ.

Чтобы удостовериться, что все ФТБ охвачены функциональной спецификацией, а также анализом покрытия тестами, оценщик может основываться на прослеживании, предоставленном разработчиком (см. ADV_FSP.1-5 для прослеживания между ФТБ для ОО и ИФБО). Следует учесть, что такое прослеживание иногда необходимо представлять на уровне детализации ниже, чем уровень детализации компонента или даже элемента требований, из-за операций (назначения, уточнения, выбора), выполняемых над функциональным требованием автором ЗБ.

Например, компонент FDP_ACC.1 содержит элемент с операциями назначения. Если бы в ЗБ содержалось, например, десять правил в отношении назначения для данного компонента FDP_ACC.1 и эти правила были бы охвачены тремя различными ИФБО, то для оценщика некорректно было бы проследить FDP_ACC.1 к ИФБО А, В и С и утверждать о завершении шага оценивания. Вместо этого оценщик должен был бы проследить FDP_ACC.1 (правило 1) к ИФБО A; FDP_ACC.1 (правило 2) к ИФБО В и т.д. Может иметь место и случай, когда интерфейс является интерфейсом адаптера (например, IOCTL), и тогда прослеживание должно быть определенным к набору параметров для данного интерфейса.

Оценщик должен осознавать, что для требований, которые незначительно проявляются или не проявляются вовсе на границах ФБО (например, FDP_RIP), не ожидается, что эти требования будут прослежены к ИФБО. Анализ таких требований будет выполняться в процессе анализа проекта ОО (ADV_TDS), когда он включен в ЗБ. Важно отметить, что, так как параметры, связанные с ИФБО, должны быть полностью специфицированы, оценщику следует быть в состоянии сделать заключение о том, все ли аспекты ФТБ реализованы на интерфейсном уровне.

10.4.2.4.2 Шаг оценивания ADV_FSP.2-10

Оценщик должен исследовать функциональную спецификацию, чтобы сделать заключение, что она является точным отображением ФТБ.

Для каждого функционального требования в ЗБ, которое оказывает видимый эффект на границах ФБО, информация в связанном с ним ИФБО специфицирует требуемые функции, описанные в требовании. Например, если в ЗБ содержится требование наличия списков контроля доступа и единственный ИФБО, прослеживаемый к этому требованию, специфицирует функции Unix-подобных разрядов защиты, тогда функциональная спецификация не является точной в отношении требований.

Оценщик должен осознавать, что для требований, которые незначительно проявляются или не проявляются вовсе на границах ФБО (например, FDP_RIP), не ожидается, что эти требования будут прослежены к ИФБО. Анализ таких требований будет выполняться в процессе анализа проекта ОО (ADV_TDS), когда он включен в ЗБ.

10.4.3 Подвид деятельности по оценке (ADV_FSP.3)

10.4.3.1 Цели

Цель данного подвида деятельности - сделать заключение, предоставил ли разработчик описание ИФБО в терминах их назначения, метода использования и параметров. Кроме того, действия, результаты и сообщения об ошибках для каждого ИФБО описываются в достаточной мере для того, чтобы была возможность сделать заключение о том, являются ли они осуществляющими выполнение ФТБ, причем интерфейсы, осуществляющие выполнение ФТБ, описываются с большей степенью детализации, чем остальные ИФБО.

10.4.3.2 Исходные данные

Свидетельствами оценки для этого подвида деятельности, требуемыми шагами оценивания, являются:

a) ЗБ;

b) функциональная спецификация;

c) проект ОО.

Свидетельствами оценки для этого подвида деятельности, которые используются в случае их включения в ЗБ по ОО, являются:

a) описание архитектуры безопасности;

b) представление реализации;

c) описание внутреннего состава ФБО;

d) руководство пользователя по эксплуатации.

10.4.3.3 Действие ADV_FSP.3.1E

ИСО/МЭК 15408-3 ADV_FSP.3.1C: В функциональной спецификации должны быть полностью представлены ФБО.

10.4.3.3.1 Шаг оценивания ADV_FSP.3-1

Оценщик должен исследовать функциональную спецификацию, чтобы сделать заключение о том, что в ней полностью представлены ФБО.

Идентификация ИФБО - необходимая предпосылка для всех действий данного подвида деятельности. Для идентификации ИФБО должны быть идентифицированы ФБО (в рамках шагов оценивания семейства ADV_TDS "Проект ОО"). Эта деятельность может быть проведена на высоком уровне, чтобы удостовериться, что не упущены крупные группы интерфейсов (сетевых протоколов, аппаратных средств, файлов конфигурации) или на низком уровне - как часть оценки функциональной спецификации.

При проведении данного шага оценивания оценщик делает заключение о том, что все части ФБО описаны в терминах интерфейсов, перечисленных в функциональной спецификации. Для всех частей ФБО следует иметь соответствующее описание интерфейсов или, при отсутствии соответствующих интерфейсов для части ФБО, оценщик делает заключение, что такое отсутствие допустимо и приемлемо.

ИСО/МЭК 15408-3 ADV_FSP.3.2C: В функциональной спецификации должны быть описаны назначение и метод использования всех ИФБО.

10.4.3.3.2 Шаг оценивания ADV_FSP.3-2

Оценщик должен исследовать функциональную спецификацию, чтобы сделать заключение о том, что в ней указано назначение каждого ИФБО.

Назначение ИФБО - это общее утверждение, кратко описывающее функциональные возможности, обеспеченные интерфейсом. Не подразумевается, что оно не должно быть полным изложением всех действий и результатов, относящихся к интерфейсу, а, скорее, оно должно помочь читателю составить общее представление о предполагаемом использовании данного интерфейса. Оценщику следует не только сделать заключение о том, что такое назначение существует, но и что оно точно отражает ИФБО, с учетом другой информации об интерфейсе, такой как описание действий и сообщений об ошибках.

10.4.3.3.3 Шаг оценивания ADV_FSP.3-3

Оценщик должен исследовать функциональную спецификацию, чтобы сделать заключение о том, что в ней содержится описание метода использования для каждого ИФБО.

Метод использования для ИФБО предоставляет краткую информацию по поводу того, каким образом в результате управления интерфейсом вызывают действия и получают результаты, связанные с ИФБО. Оценщику следует быть в состоянии посредством чтения материалов в функциональной спецификации вынести заключение о том, как использовать каждый интерфейс. Это не обязательно означает, что для каждого ИФБО нужен отдельный метод использования, поскольку можно, например, описать в общем, как происходит системный вызов ядра, а затем идентифицировать каждый интерфейс, используя общий для всех интерфейсов стиль. Различные типы интерфейсов требуют различных спецификаций по методу их использования. У интерфейсов программирования приложений, сетевых протоколов, параметров системной конфигурации и шины аппаратных средств абсолютно разные методы использования, и это следует учитывать разработчику при разработке функциональной спецификации, так же, как и оценщику при проведении её оценки.

Для администрирующих интерфейсов, функции которых документированы как недоступные недоверенным пользователям, оценщик удостоверяется в том, что метод, благодаря которому данные функции являются недоступными таким пользователям, описан в функциональной спецификации. Следует отметить, что разработчику необходимо протестировать эту недоступность при проведении испытаний.

Оценщику следует не только сделать заключение о существовании подмножества описаний методов использования, но и о том, что описания точно охватывают каждый ИФБО.

ИСО/МЭК 15408-3 ADV_FSP.3.3C: В функциональной спецификации должны быть идентифицированы и описаны все параметры, связанные с каждым ИФБО.

10.4.3.3.4 Шаг оценивания ADV_FSP.3-4

Оценщик должен исследовать представление ИФБО, чтобы сделать заключение, полностью ли идентифицированы в нем все параметры, связанные с каждым ИФБО.

Оценщик исследует функциональную спецификацию, чтобы сделать заключение, что в ней описаны все параметры для каждого ИФБО. Параметры - явные исходные данные или данные на выходе интерфейса, которые контролируют режим функционирования этого интерфейса. Например, параметрами являются: аргументы, поставляемые интерфейсу программирования приложений; различные поля в пакете для данного сетевого протокола; индивидуальные значения ключа в реестре Windows; сигналы, проходящие через контакты чипа и т.д.

Для заключения о том, что все данные параметры присутствуют в ИФБО, оценщику следует исследовать остальные описания интерфейса (действия, сообщения об ошибках и т.д.) и сделать заключение о том, что эффекты этих параметров перечислены в описании. Оценщику следует также проверить другие свидетельства, предоставленные для оценки (например, проект ОО, описание архитектуры безопасности, руководство пользователя по эксплуатации, представление реализации) на предмет того, есть ли там описания режима функционирования интерфейса или дополнительных параметров, отсутствующие в функциональной спецификации.

10.4.3.3.5 Шаг оценивания ADV_FSP.3-5

Оценщик должен исследовать представление ИФБО, чтобы сделать заключение, полно ли и точно ли описаны в нем все параметры, связанные с каждым ИФБО.

Как только все параметры идентифицированы, оценщику нужно удостовериться, что они описаны точно и что описание параметров проведено полно. Описание параметра некоторым значащим образом определяет, что представляет собой данный параметр. Например, интерфейс foo (i) может быть описан как имеющий "параметр i, который является целым числом"; но такое описание параметра неприемлемо. Более приемлемое описание - "параметр i - целое число, указывающее на число пользователей, которые в настоящий момент зарегистрированы в системе".

Для вынесения заключения о том, что описание параметра является полным, оценщику следует исследовать остальные описания интерфейса (назначение, метод использования, действия интерфейса, сообщения об ошибках и т.д.) и сделать вывод о том, что описания этих параметров перечислены в описании. Оценщику следует также проверить другие предоставленные свидетельства (например, проект ОО, проект архитектуры, руководство пользователя по эксплуатации, представление реализации) на предмет того, есть ли там описания режима функционирования интерфейса или его дополнительных параметров, отсутствующие в функциональной спецификации.

ИСО/МЭК 15408-3 ADV_FSP.3.4C: Для каждого ИФБО, осуществляющего выполнение ФТБ, функциональная спецификация должна содержать описание связанных с данным ИФБО действий, осуществляющих выполнение ФТБ.

10.4.3.3.6 Шаг оценивания ADV_FSP.3-6

Оценщик должен исследовать представление ИФБО, чтобы сделать заключение о том, что в нем полно и точно описаны все осуществляющие выполнение ФТБ действия, связанные с осуществляющими выполнение ФТБ интерфейсами.

Если действие, доступное через интерфейс, может быть прослежено к одному из ФТБ по ФБО, то этот интерфейс является осуществляющим выполнение ФТБ. Это относится не только к политикам управления доступом, но также и к любым функциям, определенным одним из ФТБ, содержащимся в ЗБ. Следует отметить, что у интерфейса могут быть различные действия и результаты его вызова, некоторые из которых могут быть осуществляющими ФТБ, а некоторые - нет.

От разработчика не требуется "маркировать" интерфейсы как осуществляющие выполнение ФТБ и также не требуется идентифицировать доступные через интерфейс действия как осуществляющие выполнение ФТБ. Оценщик обязан исследовать свидетельства, представленные разработчиком, и сделать заключение о том, что требуемая информация в них присутствует. В случае, если разработчик идентифицировал осуществляющие выполнение ФТБ ИФБО и доступные через эти ИФБО осуществляющие выполнение ФТБ действия, оценщик должен оценить полноту и точность данной идентификации, основываясь на информации, поставленной для оценки (например, на проекте ОО, описании архитектуры безопасности, руководстве пользователя по эксплуатации) и информации, представленной для данных интерфейсов (параметры и описания этих параметров, сообщения об ошибках и т.д.).

В этом случае (когда разработчик предоставил только касающуюся осуществления выполнения ФТБ информацию для осуществляющих выполнение ФТБ интерфейсов) оценщик также удостоверяется в том, что все интерфейсы правильно категорированы путем исследования информации, предоставленной для оценки (например, проекта ОО, описания архитектуры безопасности, руководства пользователя по эксплуатации), и информации по интерфейсам (параметров и описаний этих параметров, например, не идентифицированным как осуществляющие выполнение ФТБ).

В случае, если разработчик предоставил информацию одинаковой степени полноты и детализации для всех интерфейсов, оценщик выполняет такой же анализ, описанный в предыдущих параграфах. Оценщику следует сделать заключение о том, какие интерфейсы являются осуществляющими выполнение ФТБ, а какие не являются, а затем удостовериться в том, что осуществляющие выполнение ФТБ аспекты осуществляющих выполнение ФТБ действий правильно описаны.

Осуществляющие выполнение ФТБ действия - это те, которые видимы в любом внешнем интерфейсе и предусматривают удовлетворение предъявляемых ФТБ. Например, если требования по аудиту включены в ЗБ, то связанные с аудитом действия являются осуществляющими выполнение ФТБ и поэтому должны быть описаны, даже если результат этого действия обычно невозможно наблюдать через вызванный интерфейс (при проведении аудита обычной является ситуация, когда пользовательское действие в одном интерфейсе производит контрольный отчет, видимый только через другой интерфейс).

Под требуемым уровнем описания понимается достаточный для того, чтобы читатель понял роль действий ИФБО по отношению к ФТБ. Оценщику следует иметь в виду, что рекомендуется, чтобы описание было детализировано в достаточной степени для поддержки создания (и оценки) тестовых ситуаций для данного интерфейса. Если описание неясно или недостаточно детализировано и поэтому значимое тестирование ИФБО не может быть проведено, то, скорее всего, описание является несоответствующим предъявляемым к нему требованиям.

ИСО/МЭК 15408-3 ADV_FSP.3.5C: Для каждого ИФБО, осуществляющего выполнение ФТБ, функциональная спецификация должна содержать описание сообщений о непосредственных ошибках, возникающих в результате влияющих на безопасность эффектов и нештатных ситуаций, связанных с вызовом данного ИФБО.

10.4.3.3.7 Шаг оценивания ADV_FSP.3-7

Оценщик должен исследовать представление ИФБО, чтобы сделать заключение о том, что в нем полно и точно описаны сообщения о связанных с осуществляющими выполнение ФТБ интерфейсами ошибках, которые могут быть последствием действий, осуществляющих выполнение ФТБ.

Этот шаг оценивания следует выполнять вместе с шагом оценивания ADV_FSP.3-6 или после него, чтобы удостовериться, что набор осуществляющих выполнение ФТБ интерфейсов правильно идентифицирован. Оценщику следует иметь в виду, что требования и связанные с ними шаги оценивания предписывают необходимость описания всех сообщений о непосредственных ошибках, связанных с ИФБО и действиями, осуществляющими выполнение ФТБ. На данном уровне доверия дополнительную информацию, полученную из описаний сообщений об ошибках, следует использовать для вынесения заключения о том, все ли аспекты осуществляющих выполнение ФТБ интерфейсов ФБО были описаны правильно. Например, если в связанном с ИФБО сообщении об ошибке (например, в сообщении вида "в доступе отказано") указывается, что произошло действие или принято решение, осуществляющее выполнение ФТБ, но в описании осуществляющих выполнение ФТБ действий нет упоминания этого конкретного механизма, осуществляющего выполнение ФТБ, тогда описание может быть признано неполным.

Ошибки могут принимать различные формы в зависимости от описываемого интерфейса. В случае интерфейса программирования приложений интерфейс сам может вернуть код ошибки, установить состояние глобальной ошибки или определенный параметр с кодом ошибки. В случае файла конфигурации неправильно настроенный параметр может привести к появлению в системном журнале сообщения об ошибке. В случае аппаратных средств, например шины ввода/вывода, возникновение ошибки может подать на шину сигнал или вызвать особое состояние центрального процессора.

Ошибки (и связанные с ними сообщения об ошибках) проявляются через запрос интерфейса. Обработка, которая происходит в ответ на запрос интерфейса, может столкнуться с некоторыми условиями, вызывающими ошибку и сообщение об этой ошибке (путем определенного механизма, специфического для данной реализации). В некоторых случаях это может быть возвращаемое самим интерфейсом значение; в других случаях глобальное значение может быть назначено и проверено после запроса интерфейса. Скорее всего, в ОО будет много сообщений об ошибках низкого уровня, которые являются результатом фундаментальных условий для ресурсов, например "недостаточно места на диске" или "ресурс заблокирован". Несмотря на то что сообщения об ошибках могут быть прослежены к большому количеству ИФБО, их можно использовать для выявления тех случаев, когда некоторые детали в описании интерфейса были опущены. Например, если есть ИФБО, который выдает сообщение "недостаточно места на диске", но для которого не представлено ясное описание того, почему этому ИФБО следует позволять получение доступа к диску, оценщику может потребоваться исследовать другие свидетельства (семейств ADV_ARC "Архитектура безопасности", ADV_TDS "Проект ОО"), связанные с этим ИФБО, чтобы сделать заключение о том, является ли точным его описание.

Чтобы вынести заключение о том, что описание сообщений об ошибках ИФБО составлено точно и полно, оценщик сравнивает длину данного описания интерфейса с другими представленными для оценки свидетельствами (например, с проектом ОО, описанием архитектуры безопасности, руководством пользователя по эксплуатации), а также с другими свидетельствами по данному ИФБО (описанием осуществляющих выполнение ФТБ действий, кратким изложением поддерживающих и не влияющих на выполнение ФТБ действий и результатов).

ИСО/МЭК 15408-3 ADV_FSP.3.6C: В функциональной спецификации должны быть приведены все связанные с каждым ИФБО действия, поддерживающие или не влияющие на выполнение ФТБ.

10.4.3.3.8 Шаг оценивания ADV_FSP.3-8

Оценщик должен исследовать представление ИФБО, чтобы вынести заключение о том, что в нем приводится краткое описание связанных с каждым ИФБО действий, поддерживающих или не влияющих на выполнение ФТБ.

Цель этого шага оценивания состоит в том, чтобы детализировать описания осуществляющих выполнение ФТБ действий (которые приводятся в шаге оценивания ADV_FSP.3-6) и кратко описать все остальные действия (то есть те, которые не являются осуществляющими выполнение ФТБ). Это охватывает все поддерживающие и не влияющие на выполнение ФТБ действия, неважно, вызваны ли они осуществляющими выполнение ФТБ интерфейсами, поддерживающими или не влияющими на выполнение ФТБ. Такая краткая информация о поддерживающих и не влияющих на выполнение ФТБ действиях помогает получить более полную картину функций, обеспеченных ФБО, и должна использоваться оценщиком при определении того, верно ли категорированы действия или ИФБО.

Предоставляемая информация более абстрактна, чем требуемая для описания действий, осуществляющих выполнение ФТБ. Этой информации следует быть детализированной в достаточной степени для того, чтобы читатель мог понять суть действия, но описание не обязательно должно быть детализировано до такой степени, чтобы обеспечить, например, возможность письменного тестирования. Для оценщика главное то, что информация должна быть достаточной для вынесения положительного заключения о том, что действие является поддерживающим или не влияющим на выполнение ФТБ. Если представленной информации для этого недостаточно, то краткое описание признается недостаточно полным, и необходимо получить больший объем информации.

ИСО/МЭК 15408-3 ADV_FSP.3.7C: В прослеживании соответствия должно быть продемонстрировано прослеживание ФТБ к ИФБО в функциональной спецификации.

10.4.3.3.9 Шаг оценивания ADV_FSP.3-9

Оценщик должен проверить, что прослеживание соотносит ФТБ с соответствующими ИФБО.

Прослеживание предоставляется разработчиком в качестве руководства для определения того, каким образом ФТБ связаны с ИФБО. Это прослеживание может быть представлено в простом виде, например в виде таблицы; оно используется в качестве исходных данных для оценщика при использовании в последующих шагах оценивания, в которых оценщик верифицирует полноту и точность этого прослеживания.

10.4.3.4 Действие ADV_FSP.3.2E

10.4.3.4.1 Шаг оценивания ADV_FSP.3-10

Оценщик должен исследовать функциональную спецификацию, чтобы сделать заключение, является ли она полным отображением ФТБ.

Чтобы удостовериться, что все ФТБ охвачены функциональной спецификацией, а также анализом покрытия тестами, оценщик может основываться на прослеживании, предоставленном разработчиком (см. ADV_FSP.3-9 для прослеживания между ФТБ для ОО и ИФБО). Следует учесть, что такое прослеживание иногда необходимо представлять на уровне детализации ниже, чем уровень детализации компонента или даже элемента требований из-за операций (назначения, уточнения, выбора), выполняемых над функциональным требованием автором ЗБ.

Например, компонент FDP_ACC.1 содержит элемент с операциями назначения. Если бы в ЗБ содержалось, например, десять правил в отношении назначения для данного компонента FDP_ACC.1 и эти правила были бы охвачены тремя различными ИФБО, то для оценщика некорректно было бы проследить FDP_ACC.1 к ИФБО А, В и С и утверждать о завершении шага оценивания. Вместо этого оценщик должен был бы проследить FDP_ACC.1 (правило 1) к ИФБО A; FDP_ACC.1 (правило 2) к ИФБО В и т.д. Может иметь место и случай, когда интерфейс является интерфейсом адаптера (например, IOCTL), и тогда прослеживание должно быть определенным к набору параметров для данного интерфейса.

Оценщик должен осознавать, что для требований, которые незначительно проявляются или не проявляются вовсе на границах ФБО (например, FDP_RIP), не ожидается, что эти требования будут прослежены к ИФБО. Анализ таких требований будет выполняться в процессе анализа проекта ОО (ADV_TDS), когда он включен в ЗБ. Важно отметить, что, так как параметры, связанные с ИФБО, должны быть полностью специфицированы, оценщику следует быть в состоянии сделать заключение о том, все ли аспекты ФТБ реализованы на интерфейсном уровне.

10.4.3.4.2 Шаг оценивания ADV_FSP.3-11

Оценщик должен исследовать функциональную спецификацию, чтобы сделать заключение, что она является точным отображением ФТБ.

Для каждого функционального требования в ЗБ, которое оказывает видимый эффект на границах ФБО, информация в связанном с ним ИФБО специфицирует требуемые функции, описанные в требовании. Например, если в ЗБ содержится требование наличия списков контроля доступа и единственный ИФБО, прослеживаемый к этому требованию, специфицирует функции Unix-подобных разрядов защиты, тогда функциональная спецификация не является точной в отношении требований.

Оценщик должен осознавать, что для требований, которые незначительно проявляются или не проявляются вовсе на границах ФБО (например, FDP_RIP), не ожидается, что эти требования будут прослежены к ИФБО. Анализ таких требований будет выполняться в процессе анализа проекта ОО (ADV_TDS), когда он включен в ЗБ.

10.4.4 Подвид деятельности по оценке (ADV_FSP.4)

10.4.4.1 Цели

Цель данного подвида деятельности - сделать заключение, предоставил ли разработчик описание ИФБО таким образом, чтобы оценщик имел возможность сделать вывод о том, полно ли и точно ли описаны ИФБО и реализуют ли они функциональные требования безопасности ЗБ.

10.4.4.2 Исходные данные

Свидетельствами оценки для этого подвида деятельности, требуемыми шагами оценивания, являются:

a) ЗБ;

b) функциональная спецификация;

c) проект ОО.

Свидетельствами оценки для этого подвида деятельности, которые используются в случае их включения в ЗБ по ОО, являются:

a) описание архитектуры безопасности;

b) представление реализации;

c) описание внутреннего состава ФБО;

d) руководство пользователя по эксплуатации.

10.4.4.3 Замечания по применению

Функциональная спецификация описывает интерфейсы ФБО (ИФБО) структурированным образом. Из-за зависимости от Подвида деятельности по оценке (ADV_TDS.1) ожидается, что оценщик идентифицирует ФБО до начала работы по этому подвиду деятельности. Без точного знания того, что включают в себя ФБО, невозможно оценить полноту ИФБО.

При выполнении различных шагов оценивания, включенных в оценивание этого семейства, оценщика просят оценить точность и полноту нескольких факторов (описание самих ИФБО, а также их индивидуальных компонентов - параметров, действий, сообщений об ошибках и т.д.). Ожидается, что при выполнении этого анализа оценщик будет использовать документацию, предоставленную для оценки - т.е. ЗБ, проект ОО и некоторую другую документацию - руководство пользователя по эксплуатации, описание архитектуры безопасности и представление реализации. Документацию следует исследовать итеративным способом. Оценщик может прочитать, например в проекте ОО, каким образом реализована определенная функция, но не обнаружить там способа вызова этой функции через интерфейс. Это может заставить оценщика подвергнуть сомнению полноту конкретного описания ИФБО или сделать заключение о том, что данный интерфейс был упущен из виду при составлении функциональной спецификации. Описание подобных действий по оценке в ТОО является ключевым методом в представлении обоснования того, что шаги оценивания были выполнены верным образом.

Следует учесть, что есть функциональные требования, функциональные возможности которых проявляются (полностью или частично) архитектурно, а не через определенный механизм. Пример этого - внедрение механизмов, осуществляющих требования семейства "Защита остаточной информации" (FDP_RIP). Такие механизмы, как правило, реализуются для обеспечения отсутствия того или иного режима функционирования системы, а это трудно протестировать и поэтому верификация осуществляется путем анализа. В случаях, где такие функциональные требования включены в ЗБ, ожидается, что оценщик выявит наличие ФТБ, для которых нет интерфейсов, и что это не следует считать недостатком функциональной спецификации.

10.4.4.4 Действие ADV_FSP.4.1E

ИСО/МЭК 15408-3 ADV_FSP.4.1C: В функциональной спецификации должны быть полностью представлены ФБО.

10.4.4.4.1 Шаг оценивания ADV_FSP.4-1

Оценщик должен исследовать функциональную спецификацию, чтобы сделать заключение о том, что в ней полностью представлены ФБО.

Идентификация ИФБО - необходимая предпосылка для всех действий данного подвида деятельности. Для идентификации ИФБО должны быть идентифицированы ФБО (в рамках шагов оценивания семейства ADV_TDS "Проект ОО"). Эта деятельность может быть проведена на высоком уровне, чтобы удостовериться, что не упущены крупные группы интерфейсов (сетевых протоколов, аппаратных средств, файлов конфигурации), или на низком уровне как часть оценки функциональной спецификации.

При проведении данного шага оценивания оценщик делает заключение о том, что все части ФБО описаны в терминах интерфейсов, перечисленных в функциональной спецификации. Для всех частей ФБО следует иметь соответствующее описание интерфейсов или, при отсутствии соответствующих интерфейсов для части ФБО, оценщик делает заключение, что такое отсутствие допустимо и приемлемо.

ИСО/МЭК 15408-3 ADV_FSP.4.2C: В функциональной спецификации должны быть описаны назначение и метод использования всех ИФБО.

10.4.4.4.2 Шаг оценивания ADV_FSP.4-2

Оценщик должен исследовать функциональную спецификацию, чтобы сделать заключение о том, что в ней указано назначение каждого ИФБО.

Назначение ИФБО - это общее утверждение, кратко описывающее функциональные возможности, обеспеченные интерфейсом. Не подразумевается, что оно должно быть полным изложением всех действий и результатов, относящихся к интерфейсу, а, скорее, оно должно помочь читателю составить общее представление о предполагаемом использовании данного интерфейса. Оценщику следует не только сделать заключение о том, что такое назначение существует, но и что оно точно отражает ИФБО, с учетом другой информации об интерфейсе, такой как описание действий и сообщений об ошибках.

10.4.4.4.3 Шаг оценивания ADV_FSP.4-3

Оценщик должен исследовать функциональную спецификацию, чтобы сделать заключение о том, что в ней содержится описание метода использования для каждого ИФБО.

Метод использования для ИФБО предоставляет краткую информацию по поводу того, каким образом в результате управления интерфейсом вызывают действия и получают результаты, связанные с ИФБО. Оценщику следует быть в состоянии посредством чтения материалов в функциональной спецификации вынести заключение о том, как использовать каждый интерфейс. Это не обязательно означает, что для каждого ИФБО нужен отдельный метод использования, поскольку можно, например, описать в общем, как происходит системный вызов ядра, а затем идентифицировать каждый интерфейс, используя общий для всех интерфейсов стиль. Различные типы интерфейсов требуют различных спецификаций по методу их использования. У интерфейсов программирования приложений, сетевых протоколов, параметров системной конфигурации и шины аппаратных средств абсолютно разные методы использования, и это следует учитывать разработчику при разработке функциональной спецификации, так же, как и оценщику при проведении её оценки.

Для администрирующих интерфейсов, функции которых документированы как недоступные недоверенным пользователям, оценщик удостоверяется в том, что метод, благодаря которому данные функции являются недоступными таким пользователям, описан в функциональной спецификации. Следует отметить, что разработчику необходимо протестировать эту недоступность при проведении испытаний.

Оценщику следует не только сделать заключение о том, что имеется подмножество описаний методов использования, но и что эти описания точно охватывают каждый ИФБО.

10.4.4.4.4 Шаг оценивания ADV_FSP.4-4

Оценщик должен исследовать функциональную спецификацию, чтобы определить полноту ИФБО.

Оценщик должен использовать проектную документацию, чтобы идентифицировать возможные типы интерфейсов. Оценщик должен осуществить поиск проектной документации и руководств для потенциальных ИФБО, не описанных в документации, предоставленной разработчиком, таким образом указав на то, что набор ИФБО, определенный разработчиком, является неполным. Оценщик должен исследовать аргументы, представленные разработчиком для свидетельства полноты описания ИФБО, и проверить все уровни представления проектной документации вплоть до проекта самого низкого уровня и представления реализации на предмет того, что не существует никаких дополнительных ИФБО.

ИСО/МЭК 15408-3 ADV_FSP.4.3C: В функциональной спецификации должны быть идентифицированы и описаны все параметры, связанные с каждым ИФБО.

10.4.4.4.5 Шаг оценивания ADV_FSP.4-5

Оценщик должен исследовать представление ИФБО, чтобы сделать заключение, полностью ли идентифицированы в нем все параметры, связанные с каждым ИФБО.

Оценщик исследует функциональную спецификацию, чтобы удостовериться, что в ней описаны все параметры для каждого ИФБО. Параметры - явные исходные данные или данные на выходе интерфейса, которые контролируют режим функционирования этого интерфейса. Например, параметрами являются: аргументы, поставляемые интерфейсу программирования приложений; различные поля в пакете для данного сетевого протокола; индивидуальные значения ключа в реестре Windows; сигналы, проходящие через контакты чипа и т.д.

Для вынесения заключения о том, что все данные параметры присутствуют в ИФБО, оценщику следует исследовать остальные описания интерфейса (действия, сообщения об ошибках и т.д.) и сделать заключение о том, что эффекты этих параметров перечислены в описании. Оценщику следует также проверить другие свидетельства, предоставленные для оценки (например, проект ОО, описание архитектуры безопасности, руководство пользователя по эксплуатации, представление реализации) на предмет того, есть ли там описания режима функционирования интерфейса или дополнительных параметров, отсутствующие в функциональной спецификации.

10.4.4.4.6 Шаг оценивания ADV_FSP.4-6

Оценщик должен исследовать представление ИФБО, чтобы сделать заключение, полно ли и точно ли описаны в нем все параметры, связанные с каждым ИФБО.

Как только все параметры идентифицированы, оценщику нужно удостовериться, что они описаны точно и что описание параметров проведено полно. Описание параметра некоторым значащим образом определяет, что представляет собой данный параметр. Например, интерфейс foo (i) может быть описан как имеющий "параметр i, который является целым числом"; но такое описание параметра неприемлемо. Более приемлемое описание - "параметр i - целое число, указывающее на число пользователей, которые в настоящий момент зарегистрированы в системе".

Для вынесения заключения о том, что описание параметра является полным, оценщику следует исследовать остальные описания интерфейса (назначение, метод использования, действия интерфейса, сообщения об ошибках и т.д.) и сделать вывод о том, что описания этих параметров перечислены в описании. Оценщику следует также проверить другие предоставленные свидетельства (например, проект ОО, проект архитектуры, руководство пользователя по эксплуатации, представление реализации) на предмет того, есть ли там описания режима функционирования интерфейса или его дополнительных параметров, отсутствующие в функциональной спецификации.

ИСО/МЭК 15408-3 ADV_FSP.4.4C: В функциональной спецификации должны быть описаны все действия, связанные с каждым ИФБО.

10.4.4.4.7 Шаг оценивания ADV_FSP.4-7

Оценщик должен исследовать представление ИФБО, чтобы сделать заключение о том, что в нем полно и точно описаны все действия, связанные с каждым ИФБО.

Оценщик осуществляет проверку для того, чтобы удостовериться, что все действия описаны. Действия, доступные через интерфейс, описывают, что именно делает данный интерфейс (в противоположность проекту ОО, где описывается, как действия предоставляются ФБО).

Действия интерфейса описывают функциональную возможность, которая может быть вызвана через интерфейс и может быть отнесена к стандартным действиям и относящимся к ФТБ действиям. Стандартные действия - описания того, что делает интерфейс. Количество информации, предоставляемой данным описанием, зависит от сложности интерфейса. Относящиеся к ФТБ действия - те, которые являются видимыми в любом внешнем интерфейсе (например, следует предоставить описание деятельности по аудиту, которая требуется при вызове интерфейса (предполагаем, что требования аудита включены в ЗБ), даже если результат этого действия вообще не наблюдается через вызываемый интерфейс). В зависимости от параметров интерфейса может быть много различных действий, которые вызываются через интерфейс (например, у интерфейса программирования приложений первый параметр может быть "подкомандой", а последующие параметры могут быть специфическими для этой подкоманды. Пример подобного интерфейса - интерфейс программирования приложений IOCTL в некоторых системах Unix).

Для вынесения заключения о том, что действия ИФБО описаны полностью, оценщику следует рассмотреть остальные части описания интерфейса (описания параметров, сообщений об ошибках и т.д.) и сделать заключение, перечислены ли в них описанные действия. Оценщику следует также проанализировать другие свидетельства, предоставленные для оценки (например проект ОО, описание архитектуры безопасности, руководство пользователя по эксплуатации, представление реализации), чтобы определить, есть ли там свидетельства действий интерфейса, отсутствующие в функциональной спецификации.

ИСО/МЭК 15408-3 ADV_FSP.4.5C: Функциональная спецификация должна содержать описание сообщений обо всех непосредственных ошибках, которые могут возникнуть при вызове каждого ИФБО.

10.4.4.4.8 Шаг оценивания ADV_FSP.4-8

Оценщик должен исследовать представление ИФБО, чтобы сделать заключение о том, что в нем полно и точно описаны все сообщения об ошибках, возникающих при вызове ИФБО.

Ошибки могут принимать различные формы в зависимости от описываемого интерфейса. В случае интерфейса программирования приложений интерфейс сам может вернуть код ошибки, установить состояние глобальной ошибки или определенный параметр с кодом ошибки. В случае файла конфигурации неправильно настроенный параметр может привести к появлению в системном журнале сообщения об ошибке. В случае аппаратных средств, например шины ввода/вывода, возникновение ошибки может подать на шину сигнал или вызвать особое состояние центрального процессора.

Ошибки (и связанные с ними сообщения об ошибках) появляются через запрос интерфейса. Обработка, которая происходит в ответ на запрос интерфейса, может столкнуться с некоторыми условиями, вызывающими ошибку и сообщение об этой ошибке (путем определенного механизма, специфического для данной реализации). В некоторых случаях это может быть возвращаемое самим интерфейсом значение; в других случаях глобальное значение может быть назначено и проверено после запроса интерфейса. Скорее всего, у ОО будет много сообщений об ошибках низкого уровня, которые являются результатом фундаментальных условий для ресурсов, например "недостаточно места на диске" или "ресурс заблокирован". Несмотря на то что эти сообщения об ошибках могут быть прослежены к большому количеству ИФБО, их можно использовать для выявления тех случаев, когда часть описания интерфейса была опущена. Например, если есть ИФБО, который выдает сообщение "недостаточно места на диске", но для которого не представлено ясное описание того, почему этому ИФБО следует позволять получение доступа к диску, оценщику может потребоваться исследовать другие свидетельства (семейств ADV_ARC "Архитектура безопасности", ADV_TDS "Проект ОО"), связанные с этим ИФБО, чтобы сделать заключение о том, является ли его описание полным и точным.

Оценщик делает заключение о том, что для каждого ИФБО определен точный набор сообщений об ошибках, которые выдаются при вызове этого интерфейса. Оценщик рассматривает свидетельства, представленные по интерфейсу, чтобы сделать заключение о том, кажется ли приведенный набор ошибок полным. Он сверяет эту информацию с другими предоставленными для оценки свидетельствами (например, проект ОО, описание архитектуры безопасности, руководство пользователя по эксплуатации, представление реализации), чтобы удостовериться, что нет ошибок, возникающих при обработке вызовов упомянутых интерфейсов, описание которых отсутствует в функциональной спецификации.

10.4.4.4.9 Шаг оценивания ADV_FSP.4-9

Оценщик должен исследовать представление ИФБО, чтобы сделать заключение о том, что в нем полно и точно описаны значения всех ошибок, связанных с вызовами каждого ИФБО.

Для определения степени точности описания оценщик должен быть в состоянии понять значение ошибки. Например, если интерфейс возвращает числовое значение 0, 1 или 2, оценщик не в состоянии понять ошибку, если в функциональной спецификации описано только следующее: "возможные ошибки, возникающие при вызове интерфейса foo () - 0, 1 или 2". Вместо этого оценщик выполняет проверку, чтобы удостовериться, что ошибки описаны иначе, например: "возможные ошибки, возникающие при вызове интерфейса foo () - 0 (обработка успешно выполнена), 1 (файл не найден) или 2 (неверная спецификация имени файла)".

Для вынесения заключения о том, что ошибки, возникающие в результате вызовов ИФБО, описаны полностью, оценщик исследует остальную часть описания интерфейса (описания параметров, действий и т.д.) и делает заключение, перечислены ли в ней возможные условия возникновения ошибок, которые могут возникнуть вследствие использования данного интерфейса. Оценщик также проверяет другие свидетельства, предоставленные для оценки (например, проект ОО, описание архитектуры безопасности, руководство пользователя по эксплуатации, представление реализации), чтобы определить, что нет ошибок, возникающих при обработке вызовов упомянутых интерфейсов, описание которых отсутствует в функциональной спецификации.

ИСО/МЭК 15408-3 ADV_FSP.4.6C: В прослеживании соответствия должно быть продемонстрировано прослеживание ФТБ к ИФБО в функциональной спецификации.

10.4.4.4.10 Шаг оценивания ADV_FSP.4-10

Оценщик должен проверить, что прослеживание соотносит ФТБ с соответствующими ИФБО.

Прослеживание предоставляется разработчиком в качестве руководства для определения того, каким образом ФТБ связаны с ИФБО. Это прослеживание может быть представлено в простом виде, например в виде таблицы; оно используется в качестве исходных данных для оценщика при использовании в последующих шагах оценивания, в которых оценщик верифицирует полноту и точность этого прослеживания.

10.4.4.5 Действие ADV_FSP.4.2E

10.4.4.5.1 Шаг оценивания ADV_FSP.4-11

Оценщик должен исследовать функциональную спецификацию, чтобы сделать заключение, является ли она полным отображением ФТБ.

Чтобы удостовериться, что все функциональные ФТБ охвачены функциональной спецификацией, а также анализом покрытия тестами, оценщик может основываться на прослеживании, предоставленном разработчиком (см. ADV_FSP.4-10 для прослеживания между ФТБ для ОО и ИФБО). Следует учесть, что такое прослеживание иногда необходимо представлять на уровне детализации ниже, чем уровень детализации компонента или даже элемента требований из-за операций (назначения, уточнения, выбора), выполняемых над функциональным требованием автором ЗБ.

Например, компонент FDP_ACC.1 содержит элемент с операциями назначения. Если бы в ЗБ содержалось, например
десять правил в отношении назначения для данного компонента FDP_ACC.1, и эти правила были бы охвачены тремя различными ИФБО, то для оценщика некорректно было бы проследить FDP_ACC.1 к ИФБО А, В и С и утверждать о завершении шага оценивания. Вместо этого оценщик должен был бы проследить FDP_ACC.1 (правило 1) к ИФБО A; FDP_ACC.1 (правило 2) к ИФБО В и т.д. Может иметь место и случай, когда интерфейс является интерфейсом адаптера (например, IOCTL), и тогда прослеживание должно быть определенным к набору параметров для данного интерфейса.

Оценщик должен осознавать, что для требований, которые незначительно проявляются или не проявляются вовсе на границах ФБО (например, FDP_RIP), не ожидается, что эти требования будут прослежены к ИФБО. Анализ таких требований будет выполняться в процессе анализа проекта ОО (ADV_TDS), когда он включен в ЗБ. Важно отметить, что так как параметры, связанные с ИФБО, должны быть полностью специфицированы, оценщику следует быть в состоянии сделать заключение о том, все ли аспекты ФТБ реализованы на интерфейсном уровне.

10.4.4.5.2 Шаг оценивания ADV_FSP.4-12

Оценщик должен исследовать функциональную спецификацию, чтобы сделать заключение, что она является точным отображением ФТБ.

Для каждого функционального требования в ЗБ, которое оказывает видимый эффект на границах ФБО, информация в связанном с ним ИФБО специфицирует требуемые функции, описанные в требовании. Например, если в ЗБ содержится требование наличия списков контроля доступа и единственный ИФБО, прослеживаемый к этому требованию, специфицирует функции Unix-подобных разрядов защиты, тогда функциональная спецификация не является точной в отношении требований.

Оценщик должен осознавать, что для требований, которые незначительно проявляются или не проявляются вовсе на границах ФБО (например, FDP_RIP), не ожидается, что эти требования будут прослежены к ИФБО. Анализ таких требований будет выполняться в процессе анализа проекта ОО (ADV_TDS), когда он включен в ЗБ.

10.4.5 Подвид деятельности по оценке (ADV_FSP.5)

10.4.5.1 Цели

Цель данного подвида деятельности - сделать заключение, предоставил ли разработчик описание ИФБО таким образом, чтобы оценщик имел возможность сделать вывод о том, полно ли и точно ли описаны ИФБО и реализуют ли они функциональные требования безопасности ЗБ. Полнота описания интерфейсов оценивается на основании представления реализации.

10.4.5.2 Исходные данные

Свидетельствами оценки для этого подвида деятельности, требуемыми шагами оценивания, являются:

a) ЗБ;

b) функциональная спецификация;

c) проект ОО;

d) представление реализации.

Свидетельствами оценки для этого подвида деятельности, которые используются в случае их включения в ЗБ по ОО, являются:

a) описание архитектуры безопасности;

b) описание внутреннего состава ФБО;

c) модель формальной политики безопасности;

d) руководство пользователя по эксплуатации.

10.4.5.3 Действие ADV_FSP.5.1E

ИСО/МЭК 15408-3 ADV_FSP.5.1С: В функциональной спецификации должны быть полностью представлены ФБО.

10.4.5.3.1 Шаг оценивания ADV_FSP.5-1

Оценщик должен исследовать функциональную спецификацию, чтобы сделать заключение о том, что в ней полностью представлены ФБО.

Идентификация ИФБО - необходимая предпосылка для всех действий данного подвида деятельности. Для идентификации же ИФБО должны быть идентифицированы ФБО (в рамках шагов оценивания семейства ADV_TDS "Проект ОО"). Эта деятельность может быть проведена на высоком уровне, чтобы удостовериться, что не упущены крупные группы интерфейсов (сетевых протоколов, аппаратных средств, файлов конфигурации), или на низком уровне - как часть оценки функциональной спецификации.

При проведении данного шага оценивания оценщик делает заключение о том, что все части ФБО описаны в терминах интерфейсов, перечисленных в функциональной спецификации. Для всех частей ФБО следует иметь соответствующее описание интерфейсов или, при отсутствии соответствующих интерфейсов для части ФБО, оценщик делает заключение, что такое отсутствие допустимо и приемлемо.

ИСО/МЭК 15408-3 ADV_FSP.5.2C: Функциональная спецификация должна содержать полуформальное описание ИФБО.

10.4.5.3.2 Шаг оценивания ADV_FSP.5-2

Оценщик должен исследовать функциональную спецификацию, чтобы сделать заключение о том, что она представлена в полуформальном стиле описания.

Полуформальное описание характеризуется стандартизированным форматом с четким синтаксисом, уменьшающим двусмысленность, которая может возникнуть в неформальных описаниях. Так как цель полуформального описания состоит в том, чтобы повысить способность читателя понять данное описание, целесообразно, хотя и не обязательно, использовать определенные структурированные методы представления (псевдокод, блок-схемы, графики).

В целях этой деятельности оценщику следует удостовериться, что описания интерфейсов отформатированы в структурированной, последовательной манере и используют общую терминологию. Полуформальное описание интерфейсов также подразумевает, что уровень детализации представления для интерфейсов в основном согласован для всех ИФБО. Для функциональной спецификации приемлемо ссылаться на внешние спецификации для некоторых частей интерфейса, если эти внешние спецификации также представлены в полуформальном стиле описания.

ИСО/МЭК 15408-3 ADV_FSP.5.3C: В функциональной спецификации должны быть описаны назначение и метод использования всех ИФБО.

10.4.5.3.3 Шаг оценивания ADV_FSP.5-3

Оценщик должен исследовать функциональную спецификацию, чтобы сделать заключение о том, что в ней указано назначение каждого ИФБО.

Назначение ИФБО - это общее утверждение, кратко описывающее функциональные возможности, обеспеченные интерфейсом. Не подразумевается, что оно не должно быть полным изложением всех действий и результатов, относящихся к интерфейсу, а, скорее, оно должно помочь читателю составить общее представление о предполагаемом использовании данного интерфейса. Оценщику следует не только сделать заключение о том, что такое назначение существует, но и что оно точно отражает ИФБО, с учетом другой информации об интерфейсе, такой как описание действий и сообщений об ошибках.

10.4.5.3.4 Шаг оценивания ADV_FSP.5-4

Оценщик должен исследовать функциональную спецификацию, чтобы сделать заключение о том, что в ней содержится описание метода использования для каждого ИФБО.

Метод использования для ИФБО предоставляет краткую информацию по поводу того, каким образом в результате управления интерфейсом вызывают действия и получают результаты, связанные с ИФБО. Оценщику следует посредством чтения материалов в функциональной спецификации вынести заключение о том, как использовать каждый интерфейс. Это не обязательно означает, что для каждого ИФБО нужен отдельный метод использования, поскольку можно описать в общем, как происходит системный вызов ядра, а затем идентифицировать каждый интерфейс, используя общий для всех интерфейсов стиль. Различные типы интерфейсов требуют различных спецификаций по методу использования. У интерфейсов программирования приложений, сетевых протоколов, параметров системной конфигурации и шины аппаратных средств абсолютно разные методы использования, и это следует учитывать разработчику при разработке функциональной спецификации, так же, как и оценщику при проведении её оценки.

Для администрирующих интерфейсов, функции которых документированы как недоступные недоверенным пользователям, оценщик удостоверяется в том, что метод, благодаря которому данные функции являются недоступными таким пользователям, описан в функциональной спецификации. Следует отметить, что разработчику необходимо протестировать эту недоступность при проведении испытаний.

Оценщику следует не только сделать заключение о том, что имеется подмножество описаний методов использования, но и что эти описания точно охватывают каждый ИФБО.

10.4.5.3.5 Шаг оценивания ADV_FSP.5-5

Оценщик должен исследовать функциональную спецификацию, чтобы определить полноту ИФБО.

Оценщик должен использовать проектную документацию, чтобы идентифицировать возможные типы интерфейсов. Оценщик должен осуществить поиск проектной документации и руководств для потенциальных ИФБО, не описанных в документации, предоставленной разработчиком, таким образом указав на то, что набор ИФБО, определенный разработчиком, является неполным. Оценщик должен исследовать аргументы, представленные разработчиком для доказательства полноты описания ИФБО, и проверить все уровни представления проектной документации вплоть до проекта самого низкого уровня и представления реализации на предмет того, что не существует никаких расширенных ИФБО.

ИСО/МЭК 15408-3 ADV_FSP.5.4C: В функциональной спецификации должны быть идентифицированы и описаны все параметры, связанные с каждым ИФБО.

10.4.5.3.6 Шаг оценивания ADV_FSP.5-6

Оценщик должен исследовать представление ИФБО, чтобы сделать заключение, полностью ли идентифицированы в нем все параметры, связанные с каждым ИФБО.

Оценщик исследует функциональную спецификацию, чтобы удостовериться, что в ней описаны все параметры для каждого ИФБО. Параметры - явные исходные данные или данные на выходе интерфейса, которые контролируют режим функционирования этого интерфейса. Например, параметрами являются: аргументы, поставляемые интерфейсу программирования приложений; различные поля в пакете для данного сетевого протокола; индивидуальные значения ключа в Реестре Windows; сигналы, проходящие через контакты чипа и т.д.

Для вынесения заключения о том, что все данные параметры присутствуют в ИФБО, оценщику следует исследовать остальные описания интерфейса (действия, сообщения об ошибках и т.д.) и сделать заключение о том, что эффекты этих параметров перечислены в описании. Оценщику следует также проверить другие свидетельства, предоставленные для оценки (например, проект ОО, описание архитектуры безопасности, руководство пользователя по эксплуатации, представление реализации) на предмет того, есть ли там описания режима функционирования интерфейса или дополнительных параметров, отсутствующие в функциональной спецификации.

10.4.5.3.7 Шаг оценивания ADV_FSP.5-7

Оценщик должен исследовать представление ИФБО, чтобы сделать заключение, полно ли и точно ли описаны в нем все параметры, связанные с каждым ИФБО.

Как только все параметры были идентифицированы, оценщику нужно удостовериться, что они описаны точно и описание параметров проведено полно. Описание параметра некоторым значащим образом определяет, что представляет собой данный параметр. Например, интерфейс foo (i) может быть описан как имеющий "параметр i, который является целым числом"; но такое описание параметра не приемлемо. Более приемлемое описание - "параметр i - целое число, указывающее на число пользователей, которые в настоящий момент зарегистрированы в системе".

Для вынесения заключения о том, что описание параметра является полным, оценщику следует исследовать остальные описания интерфейса (назначение, метод использования, действия интерфейса, сообщения об ошибках и т.д.) и сделать вывод о том, что описания этих параметров перечислены в описании. Оценщику следует также проверить другие предоставленные свидетельства (например, проект ОО, проект архитектуры, руководство пользователя по эксплуатации, представление реализации) на предмет того, есть ли там описания режима функционирования интерфейса или его дополнительных параметров, отсутствующие в функциональной спецификации.

ИСО/МЭК 15408-3 ADV_FSP.5.5C: В функциональной спецификации должны быть описаны все действия, связанные с каждым ИФБО.

10.4.5.3.8 Шаг оценивания ADV_FSP.5-8

Оценщик должен исследовать представление ИФБО, чтобы сделать заключение о том, что в нем полно и точно описаны все действия, связанные с каждым ИФБО.

Оценщик осуществляет проверку для того, чтобы удостовериться, что все действия описаны. Действия, доступные через интерфейс, описывают, что именно делает данный интерфейс (в противоположность проекту ОО, где описывается, как действия предоставляются ФБО).

Действия интерфейса описывают функциональную возможность, которая может быть вызвана через интерфейс и может быть отнесена к стандартным действиям и относящимся к ФТБ действиям. Стандартные действия - описания того, что делает интерфейс. Количество информации, предоставляемой данным описанием, зависит от сложности интерфейса. Относящиеся к ФТБ действия - те, которые являются видимыми в любом внешнем интерфейсе (например, следует предоставить описание деятельности по аудиту, которая требуется при вызове интерфейса (предполагаем, что требования аудита включены в ЗБ), даже если результат этого действия вообще не наблюдается через вызываемый интерфейс). В зависимости от параметров интерфейса может быть много различных действий, которые вызываются через интерфейс (например, у интерфейса программирования приложений первый параметр может быть "подкомандой", а последующие параметры могут быть специфическими для этой подкоманды. Пример подобного интерфейса - интерфейс программирования приложений IOCTL в некоторых системах Unix).

Для вынесения заключения о том, что действия ИФБО описаны полностью, оценщику следует рассмотреть остальные части описания интерфейса (описания параметров, сообщений об ошибках и т.д.) и сделать заключение, перечислены ли в них описанные действия. Оценщику следует также проанализировать другие свидетельства, предоставленные для оценки (например, проект ОО, описание архитектуры безопасности, руководство пользователя по эксплуатации, представление реализации), чтобы определить, есть ли там свидетельства действий интерфейса, отсутствующие в функциональной спецификации.

ИСО/МЭК15408-3 ADV_FSP.5.6C: Функциональная спецификация должна содержать описание сообщений обо всех непосредственных ошибках, которые могут возникнуть при вызове каждого ИФБО.

10.4.5.3.9 Шаг оценивания ADV_FSP.5-9

Оценщик должен исследовать представление ИФБО, чтобы сделать заключение о том, что в нем полно и точно описаны все сообщения об ошибках, возникающих при вызове ИФБО.

Ошибки могут принимать различные формы в зависимости от описываемого интерфейса. В случае интерфейса программирования приложений интерфейс сам может вернуть код ошибки, установить состояние глобальной ошибки или определенный параметр с кодом ошибки. В случае файла конфигурации неправильно настроенный параметр может привести к появлению в системном журнале сообщения об ошибке. В случае аппаратных средств, например шины ввода/вывода, возникновение ошибки может подать на шину сигнал или вызвать особое состояние центрального процессора.

Ошибки (и связанные с ними сообщения об ошибках) появляются через запрос интерфейса. Обработка, которая происходит в ответ на запрос интерфейса, может столкнуться с некоторыми условиями, вызывающими ошибку и сообщение об этой ошибке (путем определенного механизма, специфического для данной реализации). В некоторых случаях это может быть возвращаемое самим интерфейсом значение; в других случаях глобальное значение может быть назначено и проверено после запроса интерфейса. Скорее всего, у ОО будет много сообщений об ошибках низкого уровня, которые являются результатом фундаментальных условий для ресурсов, например "недостаточно места на диске" или "ресурс заблокирован". Несмотря на то что эти сообщения об ошибках могут быть прослежены к большому количеству ИФБО, их можно использовать для выявления тех случаев, когда часть описания интерфейса была опущена. Например, если есть ИФБО, который выдает сообщение "недостаточно места на диске", но для которого не представлено ясное описание того, почему этому ИФБО следует позволять получение доступа к диску, оценщику может потребоваться исследовать другие свидетельства (семейств ADV_ARC "Архитектура безопасности", ADV_TDS "Проект ОО"), связанные с этим ИФБО, чтобы сделать заключение о том, является ли его описание полным и точным.

Оценщик делает заключение о том, что для каждого ИФБО определен точный набор сообщений об ошибках, которые выдаются при вызове этого интерфейса. Оценщик рассматривает свидетельства, представленные по интерфейсу, чтобы сделать заключение о том, кажется ли приведенный набор ошибок полным. Он сверяет эту информацию с другими предоставленными для оценки свидетельствами (например, проект ОО, описание архитектуры безопасности, руководство пользователя по эксплуатации, представление реализации), чтобы удостовериться, что нет ошибок, возникающих при обработке вызовов упомянутых интерфейсов, описание которых отсутствует в функциональной спецификации.

10.4.5.3.10 Шаг оценивания ADV_FSP.5-10

Оценщик должен исследовать представление ИФБО, чтобы сделать заключение о том, что в нем полно и точно описаны значения всех ошибок, связанных с вызовами каждого ИФБО.

Для определения степени точности описания оценщик должен быть в состоянии понять значение ошибки. Например, если интерфейс возвращает числовое значение 0, 1 или 2, оценщик не в состоянии понять ошибку, если в функциональной спецификации описано только следующее: "возможные ошибки, возникающие при вызове интерфейса foo () - 0, 1 или 2". Вместо этого оценщик выполняет проверку, чтобы удостовериться, что ошибки описаны иначе, например: "возможные ошибки, возникающие при вызове интерфейса foo () - 0 (обработка успешно выполнена), 1 (файл не найден) или 2 (неверная спецификация имени файла)".

Для вынесения заключения о том, что ошибки, возникающие в результате вызовов ИФБО, описаны полностью, оценщик исследует остальную часть описания интерфейса (описания параметров, действий и т.д.) и делает заключение, перечислены ли в ней возможные условия возникновения ошибок, которые могут возникнуть вследствие использования данного интерфейса. Оценщик также проверяет другие свидетельства, предоставленные для оценки (например, проект ОО, описание архитектуры безопасности, руководство пользователя по эксплуатации, представление реализации), чтобы определить, что нет ошибок, возникающих при обработке вызовов упомянутых интерфейсов, описание которых отсутствует в функциональной спецификации.

ИСО/МЭК 15408-3 ADV_FSP.5.7C: Функциональная спецификация должна содержать описание всех сообщений об ошибках, возникающих не в результате вызова ИФБО.

10.4.5.3.11 Шаг оценивания ADV_FSP.5-11

Оценщик должен исследовать функциональную спецификацию, чтобы сделать заключение о том, что она полностью и точно описывает все сообщения об ошибках, возникающих не в результате вызова ИФБО.

Этот шаг оценивания дополняет шаг оценивания ADV_FSP.5-9, в котором описываются те сообщения об ошибках, которые возникают в результате вызова ИФБО. Вместе эти шаги оценивания охватывают все сообщения об ошибках, которые могли быть вызваны ФБО.

Оценщик оценивает полноту и точность функциональной спецификации, сравнивая ее содержание с примерами создания сообщений об ошибке в представлении реализации. Большинство этих сообщений об ошибках будет уже охвачено в шаге оценивания ADV_FSP.5-9.

Сообщения об ошибках, связанные с этим шагом оценивания, как правило, являются такими, которые будут выданы с малой степенью вероятности, но всё же запрограммированы в целях соблюдения лучших практик. Например, оператор выбора, определяющий действия, происходящие в случае выбора конкретного пункта, может заканчиваться условным оператором else для возможности применения в ситуациях, которые не ожидаются; эта практика обеспечивает невозможность перехода ФБО в неопределенное состояние. Однако не ожидается, что при исполнении программы когда-нибудь дойдет до этого условного оператора; таким образом, никогда не будет создано сообщение об ошибке, связанной с выполнением этого оператора. Но даже если эта ошибка не возникает, она должна быть включена в функциональную спецификацию.

ИСО/МЭК 15408-3 ADV_FSP.5.8C: Функциональная спецификация должна содержать обоснование каждого сообщения об ошибке, содержащегося в реализации ФБО, но не являющегося результатом вызова ИФБО.

10.4.5.3.12 Шаг оценивания ADV_FSP.5-12

Оценщик должен исследовать функциональную спецификацию, чтобы сделать заключение о том, что в ней представлено обоснование для каждого сообщения об ошибке, содержащегося в реализации ФБО, но не являющегося результатом вызова ИФБО.

Оценщик удостоверяется, что каждое сообщение об ошибке, обнаруженное в процессе выполнения шага оценки ADV_FSP.5-11, содержит обоснование, описывающее, почему это сообщение об ошибке не является результатом вызова ИФБО.

Как описано в предыдущем шаге оценивания, это обоснование может быть настолько же целенаправленным, как и факт, что рассматриваемое сообщение об ошибке предоставлено для полноты логики выполнения программы и что оно, как ожидается, никогда не будет выдано. Оценщик убеждается, что обоснование каждого такого сообщения об ошибке является логичным.

ИСО/МЭК 15408-3 ADV_FSP.5.9C: В прослеживании соответствия должно быть продемонстрировано прослеживание ФТБ к ИФБО в функциональной спецификации.

10.4.5.3.13 Шаг оценивания ADV_FSP.5-13

Оценщик должен проверить, что прослеживание соотносит ФТБ с соответствующими ИФБО.

Прослеживание предоставляется разработчиком в качестве руководства для определения того, каким образом ФТБ связаны с ИФБО. Это прослеживание может быть представлено в простом виде, например в виде таблицы; оно используется в качестве исходных данных для оценщика для использования в последующих шагах оценивания, в которых оценщик верифицирует полноту и точность этого прослеживания.

10.4.5.4 Действие ADV_FSP.5.2E

10.4.5.4.1 Шаг оценивания ADV_FSP.5-14

Оценщик должен исследовать функциональную спецификацию, чтобы сделать заключение, является ли она полным отображением ФТБ.

Чтобы удостовериться, что все ФТБ охвачены функциональной спецификацией, а также анализом покрытия тестами, оценщик может основываться на прослеживании, предоставленном разработчиком (см. ADV_FSP.5-13 для прослеживания между ФТБ и ИФБО). Следует учесть, что такое прослеживание иногда необходимо представлять на уровне детализации ниже, чем уровень детализации компонента или даже элемента требований из-за операций (назначения, уточнения, выбора), выполняемых над функциональным требованием автором ЗБ.

Например, компонент FDP_ACC.1 содержит элемент с операциями назначения. Если бы в ЗБ содержалось, например, десять правил в отношении назначения для данного компонента FDP_ACC.1, и эти правила были бы охвачены тремя различными ИФБО, то для оценщика некорректно было бы проследить FDP_ACC.1 к ИФБО А, В и С и утверждать о завершении шага оценивания. Вместо этого оценщик должен был бы проследить FDP_ACC.1 (правило 1) к ИФБО A; FDP_ACC.1 (правило 2) к ИФБО В и т.д. Может иметь место и случай, когда интерфейс является интерфейсом адаптера (например, IOCTL), и тогда прослеживание должно быть определенным к набору параметров для данного интерфейса.

Оценщик должен осознавать, что для требований, которые незначительно проявляются или не проявляются вовсе на границах ФБО (например, FDP_RIP), не ожидается, что эти требования будут прослежены к ИФБО. Анализ таких требований будет выполняться в процессе анализа проекта ОО (ADV_TDS), когда он включен в ЗБ. Важно отметить, что так как параметры, связанные с ИФБО, должны быть полностью специфицированы, оценщику следует быть в состоянии сделать заключение о том, все ли аспекты ФТБ реализованы на уровне интерфейсов.

10.4.5.4.2 Шаг оценивания ADV_FSP.5-15

Оценщик должен исследовать функциональную спецификацию, чтобы сделать заключение, что она является точным отображением ФТБ.

Для каждого функционального требования в ЗБ, которое оказывает видимый эффект на границах ФБО, информация в связанном с ним ИФБО специфицирует требуемые функции в требовании. Например, если в ЗБ содержится требование наличия списков контроля доступа и единственный ИФБО, прослеживаемый к этому требованию, специфицирует функции Unix-подобных разрядов защиты, тогда функциональная спецификация не является точной в отношении требований.

Оценщик должен осознавать, что для требований, которые незначительно проявляются или не проявляются вовсе на границах ФБО (например FDP_RIP), не ожидается, что эти требования будут прослежены к ИФБО. Анализ таких требований будет выполняться в процессе анализа проекта ОО (ADV_TDS), когда он включен в ЗБ.

10.4.6 Подвид деятельности по оценке (ADV_FSP.6)

Общее руководство отсутствует; за консультациями по выполнению данного подвида деятельности следует обращаться в конкретную систему оценки.

10.5 Представление реализации (ADV_IMP)

10.5.1 Подвид деятельности по оценке (ADV_IMP.1)

10.5.1.1 Цели

Цель данного подвида деятельности - сделать заключение, является ли полученное от разработчика представление реализации пригодным для использования в других видах деятельности по оценке; эта пригодность оценивается по степени соответствия требованиям данного компонента.

10.5.1.2 Исходные данные

Свидетельствами оценки для этого подвида деятельности являются:

a) представление реализации;

b) документация по инструментам разработки, как следует из ALC_TAT;

c) описание проекта ОО.

10.5.1.3 Замечания по применению

Представление реализации предоставляется для того, чтобы удостовериться, что действия по анализу не были сокращены из-за нехватки информации. Это, однако, не подразумевает, что при выполнении действий оценщика исследуется все представление. Практически всегда это представляется непрактичным, особенно с учетом того факта, что, скорее всего, исследование представления целиком не будет приводить к более высокому уровню доверия ОО по сравнению с предполагаемым по представлению реализации. Для данного подвида деятельности это еще более справедливо. Для оценщика не представляется целесообразным проводить большое количество времени, проверяя требования для одной части представления реализации, а затем использовать различные части представления реализации при выполнении анализа в других шагах оценивания. Поэтому поощряется выполнение выборки представления реализации ОО из областей ОО, которые будут представлять наибольший интерес во время проведения анализа, выполняемого в рамках шагов оценивания других семейств (например, ATE_IND, AVA_VAN и ADV_INT).

10.5.1.4 Действие ADV_IMP.1.1E

ИСО/МЭК 15408-3 ADV_IMP.1.1С: Представление реализации должно определить ФБО на таком уровне детализации, что ФБО могут быть созданы без дополнительных проектных решений.

10.5.1.4.1 Шаг оценивания ADV_IMP.1-1

Оценщик должен проверить представление реализации, чтобы сделать заключение, определены ли однозначно в нем ФБО на таком уровне детализации, что ФБО могут быть сгенерированы без каких бы то ни было дальнейших проектных решений.

Исходный код или диаграммы аппаратных средств и/или программный код модели интегральных схем или размещения данных, которые используются для построения фактических аппаратных средств, являются примерами частей представления реализации. Оценщик оценивает выборку представления реализации, чтобы приобрести уверенность в том, что этот уровень является приемлемым, а не, например, псевдокодовым представлением, которое требует дополнительных проектных решений. Поощряется выполнение быстрой проверки, сначала проанализировав представление реализации, чтобы удостовериться, что разработчик находится на верном пути. Однако поощряется также выполнение большей части этой проверки при работе на других шагах оценивания, на которых необходимо исследовать представление реализации; это поможет удостовериться в том, что выборка, исследованная во время этого шага оценивания, является релевантной.

ИСО/МЭК 15408-3 ADV_IMP.1.2C: Представление реализации должно быть изложено в том виде, какой используется персоналом, занимающимся разработкой.

10.5.1.4.2 Шаг оценивания ADV_IMP.1-2

Оценщик должен проверить, что представление реализации изложено в виде, используемом персоналом разработки.

Представление реализации выполняется разработчиком таким образом, чтобы потом была возможность превращения этого представления в фактическую реализацию. Например, разработчик может работать с файлами, содержащими исходный текст программ, который потом будет скомпилирован и станет частью ФБО. Разработчик делает доступным представление реализации в той форме, в какой он его использует, благодаря чему оценщик может применять методы автоматизированного анализа. Это также увеличивает уверенность в том, что оцениваемое представление реализации является именно тем, которое используется при производстве ФБО (в отличие от того случая, когда оно сопровождается альтернативным форматом представления, например документом текстового процессора). Следует отметить, что разработчик может использовать различные формы представления реализации; они также должны прилагаться. Основная цель - снабдить оценщика такой информацией, которая позволила бы максимизировать эффективность его усилий по анализу.

Оценщик исследует выборку представления реализации, чтобы приобрести уверенность в том, что оцениваемая версия является приемлемой для использования разработчиком. Выборка должна быть такой, чтобы у оценщика имелось доверие к тому, что все области представления реализации удовлетворяют требованию; однако не требуется проводить полное исследование всего представления реализации.

Соглашения в некоторых формах представления реализации могут затруднить или сделать невозможным только по представлению реализации сделать заключение о том, каким будет фактический результат компиляции или интерпретации при запуске. Например, директивы компилятора на языке Си приведут к тому, что компилятор исключит или включит целые части программного кода.

Для некоторых форм представления реализации требуется дополнительная информация, поскольку их довольно сложно понять и проанализировать. В качестве примера можно привести "скрытый" или каким-либо образом запутанный фрагмент исходного текста программы, который сложно понять и/или проанализировать. Подобные формы представления реализации чаще всего возникают, когда разработчик ОО применяет к некоторой версии представления реализации некие программы по сокрытию или запутыванию кода. Хотя представление со скрытыми участками кода является именно тем, что будет в дальнейшем подвергнуто компиляции, а потому может быть даже ближе к реализации (по структуре), чем оригинальная версия, но предоставление оценщику запутанного программного кода может привести к тому, что анализ рисков, связанных с данным представлением реализации, потребует значительно больше времени. При создании подобных форм представления в компонентах данного семейства должны быть детализированы примененные средства/алгоритмы сокрытия, что позволит снабдить оценщика представлением до применения сокрытия участков кода, а дополнительная информация может быть использована для приобретения уверенности в том, что процесс сокрытия участков кода не нарушил выполнение каких-либо функций безопасности.

Оценщик рассматривает выборку представления реализации для того, чтобы была получена вся информация, которая необходима для интерпретации представления реализации. Следует отметить, что на инструментальные средства этого ссылаются компоненты семейства "Инструментальные средства и методы" (АLС_ТАТ). Поощряется выполнение быстрой проверки, сначала проанализировав представление реализации, чтобы удостовериться, что разработчик находится на верном пути. Однако также поощряется выполнить большую часть этой проверки при работе на других шагах оценивания, на которых необходимо исследовать представление реализации; это поможет удостовериться в том, что выборка, исследованная во время этого шага оценивания, является релевантной.

ИСО/МЭК 15408-3 ADV_IMP.1.ЗС: В прослеживании между выборкой представления реализации и описанием проекта OO должно быть продемонстрировано их соответствие.

10.5.1.4.3 Шаг оценивания ADV_IMP.1-3

Оценщик должен исследовать прослеживание между описанием проекта ОО и образцом представления реализации, чтобы сделать заключение о том, что оно является точным.

Оценщик усиливает заключение о существовании (описанное в шаге оценивания ADV_IMP.1-1), проверяя точность части представления реализации и описания проекта ОО. Для тех частей ОО, которые представляют особый интерес, оценщик проверяет, что представление реализации точно отражает описание, представленное в проекте ОО.

Например, в описании проекта ОО может быть идентифицирован модуль логина, который используется для идентификации и подтверждения подлинности пользователей. Если аутентификация пользователя достаточно значима, оценщик верифицирует, что соответствующий код фактически осуществляет тот сервис, который описан в описании проекта ОО. Возможно, необходимо также верифицировать, что код принимает те параметры, которые описаны в функциональной спецификации.

Стоит указать, что разработчик должен выбрать, выполнить ли прослеживание для всего представления реализации, таким образом обеспечивая охват выборки прослеживанием, или перед выполнением прослеживания подождать выборки. В первом случае возможен больший объем работы, но она может быть закончена еще до начала самой оценки. Во втором случае объем работы меньше, но на время производства необходимых свидетельств придется приостановить деятельность по оценке.

10.5.2 Подвид деятельности по оценке (ADV_IMP.2)

Общее руководство отсутствует; за консультациями по выполнению данного подвида деятельности следует обращаться в конкретную систему оценки.

10.6 Внутренняя структура ФБО (ADV_INT)

10.6.1 Подвид деятельности по оценке (ADV_INT.1)

10.6.1.1 Цели

Цель данного подвида деятельности - сделать заключение, является ли определенное подмножество ФБО спроектированным и структурированным таким образом, что снижается вероятность уязвимостей и что обслуживание ФБО может быть выполнено без введения уязвимостей.

10.6.1.2 Исходные данные

Свидетельствами оценки для этого подвида деятельности являются:

a) ЗБ;

b) описание проекта ОО;

c) представление реализации (если ADV_IMP является частью требуемого доверия);

d) описание архитектуры безопасности;

e) документация по стандартам кодирования, как следует из ALC_TAT.

10.6.1.3 Замечания по применению

Роль описания внутренней структуры ФБО заключается в том, чтобы представить свидетельства структуры проекта и реализации ФБО.

У структуры проекта есть два аспекта: составные части ФБО и процедуры, использованные при проектировании ФБО. В случае, если ФБО разработаны в манере, совместимой с проектом, представленном в проекте ОО (см. ADV_TDS), оценка проекта ФБО проводится очевидным образом. В случае выполнения процедур проектирования (см. ALC_TAT) оценка методики проектирования ФБО также очевидна.

В случае, когда ФБО реализуются, используя основанное на выполнении процедур программное обеспечение, структура оценивается на основе ее модульности; модули, идентифицированные в описании внутренней структуры, совпадают с теми модулями, которые идентифицированы в проекте ОО (семейство ADV_TDS "Проект ОО"). Модуль состоит из одного или более файлов исходного кода, которые являются наименьшими структурными единицами.

Использование операции назначения в этом компоненте налагает более строгие ограничения на подмножество ФБО, явно идентифицированное в назначении ADV_INT.1.1D, чем на остальную часть ФБО. Несмотря на то что все ФБО должны быть разработаны с использованием хороших технических принципов и практик и в результате представлять собой хорошо структурированные ФБО, только указанное подмножество анализируется на предмет соответствия этой характеристике. Оценщик делает заключение о том, что применение разработчиком стандартов кодирования приводит к понятным ФБО.

Основная цель этого компонента состоит в том, чтобы удостовериться, что представление реализации подмножества ФБО достаточно понятно для облегчения обслуживания и анализа этого подмножества (как для разработчика, так и для оценщика).

10.6.1.4 Действие ADV_INT.1.1E

ИСО/МЭК 15408-3 ADV_INT.1.1С: В логическом обосновании должно приводиться объяснение того, на основании каких характеристик оценивается "полнота определения" внутренней структуры.

10.6.1.4.1 Шаг оценивания ADV_INT.1-1

Оценщик должен исследовать логическое обоснование, чтобы сделать заключение о том, что в нём идентифицирована основа для вынесения заключения о том, полно ли определена внутренняя структура ФБО.

Оценщик проверяет, что критерии для определения полноты и правильности определения внутренней структуры ФБО ясно определены в логическом обосновании. Приемлемые критерии, как правило, представлены в промышленных стандартах для технологической дисциплины. Например, процедурное программное обеспечение, которое выполняется линейно, традиционно считается в полной мере структурированным, если оно было написано в соответствии с лучшими техническими практиками программирования, такими, например как определенные в Стандарте IEEE (Стандарт. IEEE 610.12-1990). Это определяет критерии для процедурных частей программного обеспечения подмножества ФБО:

a) процесс, используемый для модульной декомпозиции,

b) стандарты кодирования, используемые при разработке реализации,

c) описание максимального допустимого уровня связности между модулями, представленными в подмножестве ФБО, и

d) описание минимального допустимого уровня связности между модулями, представленными в подмножестве ФБО.

Для других типов технологий, используемых в ОО, таких как непроцедурное программное обеспечение (например, объектно-ориентированного программирования), широко распространенные в качестве товаров аппаратные средства (например, микропроцессоры персональных компьютеров) и аппаратные средства специального назначения (например, процессоры смарт-карт), оценщику следует получить руководство от органа оценки для того, чтобы определить по заданным критериям полноту определения внутренней структуры.

ИСО/МЭК 15408-3 ADV_INT.1.2C: В описании внутренней структуры ФБО должно быть продемонстрировано, что внутренняя структура заданного подмножества ФБО является полностью определенной.

10.6.1.4.2 Шаг оценивания ADV_INT.1-2

Оценщик должен проверить описание внутренней структуры ФБО, чтобы сделать заключение о том, что в ней идентифицировано означенное подмножество ФБО.

Это подмножество может быть идентифицировано в терминах внутренней структуры ФБО на любом уровне абстракции. Например, в терминах структурных элементов ФБО, идентифицированных в проекте ОО (например, подсистема аудита), или в терминах реализации (например, файлы encrypt.с и decrypt.с или чип 6227 интегральной схемы).

Недостаточно просто идентифицировать это подмножество в терминах требуемых ФТБ (например, части ФБО, которые обеспечивают анонимность, как определено в FPR_ANО.2), поскольку при этом не определено, на чем следует сосредоточить деятельность по анализу.

10.6.1.4.3 Шаг оценивания ADV_INT.1-3

Оценщик должен исследовать описание внутренней структуры ФБО, чтобы сделать заключение о том, что оно демонстрирует, что внутренняя структура означенного подмножества ФБО является полностью определенной.

Оценщик исследует описание внутренней структуры, чтобы удостовериться, что оно предоставляет полное объяснение того, каким образом подмножество ФБО соответствует критериям ADV_INT.1-1.

Например, это объясняет, каким образом процедурные части программного обеспечения подмножества ФБО удовлетворяют следующим требованиям по наличию:

a) непосредственного соответствия модулей, идентифицированных в подмножестве ФБО и модулей, описанных в проекте ОО (ADV_TDS),

b) описания того, как в проекте ФБО отражен процесс модульной декомпозиции,

c) логического обоснования всех случаев, где стандарты кодирования не используются или им нет соответствия, и

d) логического обоснования любой связности вне приемлемых границ.

10.6.1.5 Действие ADV_INT.1.2E

10.6.1.5.1 Шаг оценивания ADV_INT.1-4

Оценщик должен сделать заключение о том, что проект ОО для означенного подмножества ФБО имеет полностью определенную внутреннюю структуру.

Оценщик исследует образец проекта ОО, чтобы верифицировать точность логического обоснования. Например, образец проекта ОО анализируется в целях определения его соответствия нормам проектирования и т.д. Как и во всех областях, где оценщик выполняет действия над подмножеством, оценщик предоставляет логическое обоснование объема выборки и области оценивания.

Описание декомпозиции ОО на подсистемы и модули приведет к доводу о том, что полнота определения внутренней структуры ФБО является очевидной. Верификация того, что процедуры структурирования ФБО (как исследуется в ALC_TAT) выполняются, сделает очевидным полноту определения внутренней структуры ФБО.

10.6.1.5.2 Шаг оценивания ADV_INT.1-5

Оценщик должен сделать заключение о том, что означенное подмножество ФБО имеет полностью определенную внутреннюю структуру.

Если ADV_IMP не является частью требуемого доверия, то этот шаг оценивания не применим и поэтому считается удовлетворенным.

Оценщик исследует образец подмножества ФБО, чтобы верифицировать точность описания внутренней структуры. Например, образец процедурных частей программного обеспечения подмножества ФБО анализируется в целях определения его связности и приверженности стандартам кодирования т.д. Как и во всех областях, где оценщик выполняет действия над подмножеством, оценщик предоставляет логическое обоснование объема выборки и области оценивания.

10.6.2 Подвид деятельности по оценке (ADV_INT.2)

10.6.2.1 Цели

Цель данного подвида деятельности - сделать заключение, является ли определенное подмножество ФБО спроектированным и структурированным таким образом, что снижается вероятность уязвимостей и обслуживание ФБО может выполняться без введения уязвимостей.

10.6.2.2 Исходные данные

Свидетельствами оценки для этого подвида деятельности являются:

a) описание модульного проекта;

b) представление реализации (если ADV_IMP является частью требуемого доверия);

c) описание внутренней структуры ФБО;

d) документация по стандартам кодирования, как следует из ALC_TAT.

10.6.2.3 Замечания по применению

Роль описания внутренней структуры ФБО - представить свидетельства структуры проекта и реализации ФБО.

У структуры проекта есть два аспекта: составные части ФБО и процедуры, использованные при проектировании ФБО. В случае, если ФБО разработаны в манере, совместимой с проектом, представленном в проекте ОО (см. ADV_TDS), оценка проекта ФБО проводится очевидным образом. В случае выполнения процедур проектирования (см. ALC_TAT), оценка методики проектирования ФБО также очевидна.

В случае, когда ФБО реализуются, используя основанное на выполнении процедур программное обеспечение, структура оценивается на основе ее модульности; модули, идентифицированные в описании внутренней структуры, совпадают с теми модулями, которые идентифицированы в проекте ОО (семейство ADV_TDS "Проект ОО"). Модуль состоит из одного или более файлов исходного кода, которые являются наименьшими структурными единицами.

Основная цель этого компонента состоит в том, чтобы удостовериться, что представление реализации подмножества ФБО достаточно понятно для облегчения обслуживания и анализа этого подмножества (как для разработчика, так и для оценщика).

10.6.2.4 Действие ADV_INT.2.1E

ИСО/МЭК 15408-3 ADV_INT.2.1С: В логическом обосновании должно приводиться объяснение того, на основании каких характеристик оценивается "полнота определения" внутренней структуры.

10.6.2.4.1 Шаг оценивания ADV_INT.2-1

Оценщик должен исследовать логическое обоснование, чтобы сделать заключение, что в нём идентифицирована основа для вынесения заключения о том, полно ли определена внутренняя структура ФБО.

Оценщик проверяет, что критерии для определения полноты и правильности определения внутренней структуры ФБО ясно определены в логическом обосновании. Приемлемые критерии, как правило, представлены в промышленных стандартах для технологической дисциплины. Например, процедурное программное обеспечение, которое выполняется линейно, традиционно считается в полной мере структурированным, если оно было написано в соответствии с лучшими техническими практиками программирования, такими, например, как определенные в Стандарте IEEE (Стандарт. IEEE 610.12-1990). Это определяет критерии для процедурных частей программного обеспечения подмножества ФБО:

a) процесс, используемый для модульной декомпозиции,

b) стандарты кодирования, используемые при разработке реализации,

c) описание максимального допустимого уровня связности между модулями, представленными в подмножестве ФБО, и

d) описание минимального допустимого уровня связности между модулями, представленными в подмножестве ФБО.

Для других типов технологий, используемых в ОО, таких как непроцедурное программное обеспечение (например, объектно-ориентированного программирования), широко распространенные в качестве товаров аппаратные средства (например, микропроцессоры персональных компьютеров) и аппаратные средства специального назначения (например, процессоры смарт-карт), оценщик должен получить руководство от органа оценки для того, чтобы определить по заданным критериям полноту определения внутренней структуры.

ИСО/МЭК 15408-3 ADV_INT.2.2C: В описании внутренней структуры ФБО должно быть продемонстрировано, что внутренняя структура означенного подмножества ФБО является полностью определенной.

10.6.2.4.2 Шаг оценивания ADV_INT.2-2

Оценщик должен исследовать описание внутренней структуры ФБО, чтобы сделать заключение о том, что оно демонстрирует, что внутренняя структура означенного подмножества ФБО является полностью определенной.

Оценщик исследует описание внутренней структуры, чтобы удостовериться, что оно предоставляет полное объяснение того, каким образом подмножество ФБО соответствует критериям ADV_INT.1-1.

Например, это объясняет, каким образом процедурные части программного обеспечения подмножества ФБО удовлетворяют следующим требованиям по наличию:

a) непосредственного соответствия модулей, идентифицированных в подмножестве ФБО и модулей, описанных в проекте ОО (ADV_TDS),

b) описания того, как в проекте ФБО отражен процесс модульной декомпозиции,

c) логического обоснования всех случаев, где стандарты кодирования не используются или им нет соответствия, и

d) логического обоснования любой связности вне приемлемых границ.

10.6.2.5 Действие ADV_INT.2.2E

10.6.2.5.1 Шаг оценивания ADV_INT.2-3

Оценщик должен сделать заключение о том, что проект ОО имеет полностью определенную внутреннюю структуру.

Оценщик исследует образец проекта ОО, чтобы верифицировать точность логического обоснования. Например, образец проекта ОО анализируется в целях определения его соответствия нормам проектирования и т.д. Как и во всех областях, где оценщик выполняет действия над подмножеством, оценщик предоставляет логическое обоснование объема выборки и области оценивания.

Описание декомпозиции ОО на подсистемы и модули приведет к выводу о том, что полнота определения внутренней структуры ФБО является очевидной. Верификация того, что процедуры структурирования ФБО (как исследуется в АLС_ТАТ) выполняются, сделает очевидным полноту определения внутренней структуры ФБО.

10.6.2.5.2 Шаг оценивания ADV_INT.2-4

Оценщик должен сделать заключение о том, что означенное подмножество ФБО имеет полностью определенную внутреннюю структуру.

Если ADV_IMP не является частью требуемого доверия, то этот шаг оценивания не применим и поэтому считается удовлетворенным.

Оценщик исследует образец подмножества ФБО, чтобы верифицировать точность описания внутренней структуры. Например, образец процедурных частей программного обеспечения подмножества ФБО анализируется в целях определения его связности и приверженности стандартам кодирования. Как и во всех областях, где оценщик выполняет действия над подмножеством, оценщик предоставляет логическое обоснование объема выборки и области оценивания.

10.6.3 Подвид деятельности по оценке (ADV_INT.3)

Общее руководство отсутствует; за консультациями по выполнению данного подвида деятельности следует обращаться в конкретную систему оценки.

10.7 Моделирование политики безопасности (ADV_SMP)

10.7.1 Подвид деятельности по оценке (ADV_SPM.1)

Общее руководство отсутствует; за консультациями по выполнению данного подвида деятельности следует обращаться в конкретную систему оценки.

10.8 Проект ОО (ADV_TDS)

10.8.1 Подвид деятельности по оценке (ADV_TDS.1)

10.8.1.1 Исходные данные

Свидетельствами оценки для этого подвида деятельности являются:

a) ЗБ;

b) функциональная спецификация;

c) описание архитектуры безопасности;

d) проект ОО.

10.8.1.2 Действие ADV_TDS.1.1E

ИСО/МЭК 15408-3 ADV_TDS.1.1C: В проекте должно приводиться описание структуры ОО на уровне подсистем.

10.8.1.2.1 Шаг оценивания ADV_TDS.1-1

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что структура всего ОО описана в терминах подсистем.

Оценщик удостоверяется, что все подсистемы ОО идентифицированы. Это "Описание ОО" будет использоваться в качестве исходных данных для шага оценивания ADV_TDS.1-2, где идентифицированы части ОО, которые составляют ФБО. Таким образом, это требование относится ко всему ОО, а не только к ФБО.

ОО (и ФБО) может быть описан на нескольких уровнях детализации (то есть подсистем и модулей). В зависимости от сложности ОО, его проект может быть описан в терминах подсистем и модулей, как описано в ИСО/МЭК 15408-3, Приложение А.4 ADV_TDS: "Подсистемы и модули". На этом уровне доверия декомпозиция требуется только на уровне подсистем.

При выполнении этой деятельности оценщик исследует другие свидетельства, представленные ОО (например, ЗБ, пользовательское руководство оператора), чтобы сделать заключение о том, что "Описание ОО" в таких свидетельствах совместимо с описанием, содержавшимся в проекте ОО.

ИСО/МЭК 15408-3 ADV_TDS.1.2C: В проекте должны быть идентифицированы все подсистемы ФБО.

10.8.1.2.2 Шаг оценивания ADV_TDS.1-2

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что все подсистемы ФБО идентифицированы.

В шаге оценивания ADV_TDS.1-1 были идентифицированы все подсистемы ОО и вынесено заключение о том, что подсистемы, не относящиеся к ФБО, правильно охарактеризованы. Основываясь на этом, подсистемы, которые не характеризовались как не относящиеся к ФБО, следует точно идентифицировать. Оценщик делает заключение о том, что для аппаратного и программного обеспечения, установленного и настроенного согласно руководству в семействе AGD_PRE "Подготовительные процедуры", каждая подсистема идентифицирована или как являющаяся частью ФБО или как не являющаяся.

ИСО/МЭК 15408-3 ADV_TDS.1.3C: В проекте должно приводиться описание режима функционирования для каждой подсистемы, поддерживающей выполнение ФТБ или не влияющей на их выполнение, с предоставлением детальной информации, достаточной для того, чтобы установить, что подсистема не является осуществляющей выполнение ФТБ.

10.8.1.2.3 Шаг оценивания ADV_TDS.1-3

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что каждая подсистема ФБО, являющаяся поддерживающей выполнение ФТБ или не влияющей на выполнение ФТБ, описана таким образом, что оценщик может сделать вывод о том, что подсистема является поддерживающей выполнение ФТБ или не влияющей на выполнение ФТБ.

Поддерживающие и не влияющие на выполнение ФТБ подсистемы не нужно описывать подробно относительно того, как они функционируют в системе. Однако оценщик на основании свидетельств, предоставленных разработчиком, делает заключение, что подсистемами, у которых нет описаний верхнего уровня, являются поддерживающие выполнение ФТБ или не влияющие на выполнение ФТБ. Следует отметить, что если разработчик предоставляет однородный уровень детализации при предоставлении документации, тогда этот шаг оценивания будет в основном выполнен, так как смысл категоризации подсистем в том, чтобы позволить разработчику предоставлять меньше информации относительно поддерживающих и не влияющих на выполнение ФТБ подсистем, чем для подсистем, осуществляющих выполнение ФТБ.

Поддерживающая выполнение ФТБ подсистема - та, которая зависит от осуществляющей выполнение ФТБ в удовлетворении ФТБ, но не играет в этом роль напрямую в отличие от осуществляющей выполнение ФТБ подсистемы. Подсистема, не влияющая на выполнение ФТБ, это та подсистема, которая не является поддерживающей или помогающей в выполнении ФТБ, от неё в плане выполнения ФТБ другие подсистемы не зависят.

ИСО/МЭК 15408-3 ADV_TDS.1.4C: В проекте должна приводиться аннотация осуществляющих выполнение ФТБ режимов безопасности тех подсистем, которые являются осуществляющими выполнение ФТБ.

10.8.1.2.4 Шаг оценивания ADV_TDS.1-4

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что он предоставляет полное и точное описание верхнего уровня для обеспечивающего выполнение ФТБ режима функционирования подсистем, обеспечивающих выполнение ФТБ.

Разработчик может определять подсистемы как обеспечивающие выполнение ФТБ, поддерживающие выполнение ФТБ или не влияющие на выполнение ФТБ, но эти "категории" используются только для того, чтобы описать количество и тип информации, которую должен предоставить разработчик, и может использоваться для ограничения количества информации, которую должен предоставить разработчик в том случае, если сам процесс разработки не производит требуемую документацию. Были подсистемы категоризированы разработчиком или нет, в обязанности оценщика входит задача вынести заключение о том, что в подсистемы включена соответствующая их роли в ОО (обеспечивающие выполнение ФТБ и т.д.) информация и получить соответствующую информацию от разработчика в случае, если разработчик не в состоянии предоставить необходимую информацию для конкретной подсистемы.

Обеспечивающий выполнение ФТБ режим функционирования ссылается на то, каким образом подсистемой выполняются функции, которые обеспечивают выполнение ФТБ. Описание верхнего уровня не должно относиться к определенным структурам данных (хотя такой случай возможен), но описывает в общем потоки данных, потоки сообщений и взаимоотношения контроля в пределах подсистемы. Цель этих описаний состоит в том, чтобы предоставить оценщику достаточно информации для понимания того, каким образом достигается обеспечивающий выполнение ФТБ режим функционирования. Следует отметить, что для данного шага оценивания оценщику следует считать недопустимым заявления об обеспечении выполнения ФТБ в документации проекта ОО. Также следует отметить, что заключение оценщика, с точки зрения описания верхнего уровня, выносится для конкретного ОО, и оценщик для вынесения правильного вердикта по данному шагу оценивания должен получить достаточно информации от разработчика.

Чтобы определить полноту и точность, оценщик исследует другую доступную информацию (например, функциональную спецификацию, описание архитектуры безопасности, представление реализации). Описаниям функций в этих документах следует быть совместимыми с тем, что предоставлено в свидетельствах данного шага оценивания.

ИСО/МЭК 15408-3 ADV_TDS.1.5С: В проекте должно приводиться описание взаимодействий между осуществляющими выполнение ФТБ подсистемами ФБО, а также между ними и другими подсистемами ФБО.

10.8.1.2.5 Шаг оценивания ADV_TDS.1-5

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что в нем приведены описания взаимодействий между подсистемами ФБО.

Цель описания взаимодействий между осуществляющими выполнение ФТБ подсистемами и другими подсистемами состоит в том, чтобы предоставить читателю лучшее понимание того, каким образом ФБО выполняют свои функции. Эти взаимодействия не должны быть характеризованы на уровне реализации (например, параметры из процедуры в одной подсистеме переходят к процедуре другой подсистемы; глобальные переменные; сигналы аппаратных средств (например, прерывания) от подсистемы аппаратных средств до системы обработки прерываний), но элементы данных, идентифицированных для конкретной подсистемы, которые будут использоваться другой подсистемой, должны быть охвачены этим рассмотрением. Любые отношения контроля между подсистемами (например, имеется подсистема, ответственная за формирование базовых правил для межсетевого экрана, и подсистема, которая фактически реализует эти правила) также следует включать в описание.

Оценщику нужно использовать свое собственное суждение при оценивании полноты описания. Если причина взаимодействия подсистем неясна или если есть относящиеся к выполнению ФТБ взаимодействия (выявленные, например, в ходе анализа описания режимов функционирования подсистемы), которые недостаточно ясно описаны, оценщику следует удостовериться, что эта информация предоставлена разработчиком. Однако, если оценщик может сделать заключение о том, что взаимодействия между конкретным набором подсистем, хотя и не полностью описаны разработчиком, не помогут ни в понимании общих функций, ни в понимании функций безопасности, обеспечиваемых ФБО, тогда оценщик может считать описание достаточным; полнота описания ради самой полноты не преследуется.

ИСО/МЭК 15408-3 ADV_TDS.1.6C: В прослеживании должно быть продемонстрировано, что все описанные в проекте ОО режимы функционирования прослеживаются к вызывающим их ИФБО.

10.8.1.2.6 Шаг оценивания ADV_TDS.1-6

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что он содержит полное и точное прослеживание от ИФБО, описанных в функциональной спецификации, к подсистемам ФБО, описанным в проекте ОО.

В описании подсистем в проекте ОО предоставляется описание того, каким образом ФБО реализуются, достаточно детально для обеспечивающих выполнение ФТБ частей ФБО и на более высоком уровне представления для других частей ФБО. ИФБО обеспечивают описание того, каким образом осуществлена реализация. Свидетельства от разработчика идентифицируют подсистему, которая вовлечена в процесс запроса операции от ИФБО, и идентифицируют различные подсистемы, которые прежде всего ответственны за реализацию функций. Следует отметить, что для данного шага оценивания не требуется предоставление полного "дерева вызовов" для каждого ИФБО.

Оценщик оценивает полноту прослеживания, удостоверяясь, что каждый ИФБО прослежен по крайней мере к одной подсистеме. Проверка точности сложнее.

Первый аспект точности заключается в том, что каждый ИФБО прослеживается к подсистеме, находящейся в пределах ФБО. Такое заключение может быть сделано при рассмотрении описания подсистем и их взаимодействия и определении места подсистемы в архитектуре безопасности на основании данной информации. Следующий аспект точности - то, что прослеживание имеет смысл. Например, прослеживание ИФБО, обеспечивающего контроль доступа, к подсистеме, которая проверяет пароли, не будет являться точным. Оценщику и в этом случае при вынесении заключения следует использовать свое суждение. Цель состоит в том, что эта информация поможет оценщику в понимании системы, реализации выполнения ФТБ и способов, которыми сущности в пределах ФБО могут взаимодействовать с ФБО. Большая часть оценки того, точно ли описаны ФТБ подсистемами, выполняется при проведении других шагов оценивания.

10.8.1.3 Действие ADV_TDS.1.2E

10.8.1.3.1 Шаг оценивания ADV_TDS.1-7

Оценщик должен исследовать ФТБ ОО и проект ОО, чтобы сделать заключение о том, что все ФТБ в ЗБ охвачены в проекте ОО.

Оценщик может провести прослеживание между ФТБ для ОО и проектом ОО. Это прослеживание, вероятно, будет проводиться от функционального требования до ряда подсистем и будет по уровню детализации ниже, чем для компонента или даже для элемента требований, из-за операций (назначения, уточнения, выбора), которые выполняются над функциональным требованием автором ЗБ.

Например, компонент FDP_ACC.1 "Ограниченное управление доступом" содержит элемент с операцией назначения. Если бы в ЗБ содержалось, например, десять правил в назначении для данного компонента FDP_ACC.1, и эти правила применялись бы в определенных местах в пределах пятнадцати модулей, то для оценщика некорректно было бы проследить компонент FDP_ACC.1 к одной подсистеме и утверждать о завершении шага оценивания. Вместо этого оценщик должен проследить первое правило компонента FDP_ACC.1 к подсистеме А и режимам функционирования х, у и z; второе правило компонента FDP_ACC.1 к подсистеме А и режимам функционирования х, р и q; и т.д.

10.8.1.3.2 Шаг оценивания ADV_TDS.1-8

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что в нем точно представлены все ФТБ.

Оценщик удостоверяется, что для каждого из ФТБ, перечисленных в подразделе ЗБ "Функциональные требования безопасности", есть соответствующее описание в проекте ОО, которое детализирует, каким образом ФБО отвечают этому требованию. Это требуется для того, чтобы оценщик идентифицировал собрание подсистем, которые отвечают за осуществление данного функционального требования, а затем исследовал эти подсистемы, чтобы понять, каким образом выполняется требование. Наконец, оценщик оценивает точность выполнения требования.

Например, если требования в ЗБ определяют основанный на ролевой модели механизм управления доступом, то оценщик сначала идентифицирует подсистемы, которые способствуют реализации этого механизма. Это может быть сделано с применением углубленного изучения или с применением понимания проекта ОО или работ, полученных в предыдущих шагах оценивания. Следует отметить, что это прослеживание необходимо только для идентификации подсистем и не является полным анализом.

Следующий шаг - понять, какой из механизмов подсистемы осуществляется. Например, если в проекте описывается реализация управления доступом, основанная на битах защиты UNIX, то проект не является точным отражением требований по управлению доступом в ЗБ для того примера, который использовался выше. Если оценщик не может сделать заключение о том, что механизм был реализован точным образом из-за недостаточной детализации предоставленной ему информации, то ему нужно будет оценить, были ли все осуществляющие выполнение ФТБ подсистемы идентифицированы и был ли предоставлен для этих подсистем достаточный уровень детализации.

10.8.2 Подвид деятельности по оценке (ADV_TDS.2)

10.8.2.1 Исходные данные

Свидетельствами оценки для этого подвида деятельности являются:

a) ЗБ;

b) функциональная спецификация;

c) описание архитектуры безопасности;

d) проект ОО.

10.8.2.2 Действие ADV_TDS.2.1E

ИСО/МЭК 15408-3 ADV_TDS.2.1С: В проекте должно приводиться описание структуры ОО на уровне подсистем.

10.8.2.2.1 Шаг оценивания ADV_TDS.2-1

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что структура всего ОО описана в терминах подсистем.

Оценщик удостоверяется, что все подсистемы ОО идентифицированы. Это "Описание ОО" будет использоваться в качестве исходных данных для шага оценивания ADV_TDS.2-2, где идентифицированы части ОО, которые составляют ФБО. Таким образом, это требование относится ко всему ОО, а не только к ФБО.

ОО (и ФБО) может быть описан на нескольких уровнях детализации (то есть подсистем и модулей). В зависимости от сложности ОО его проект может быть описан в терминах подсистем и модулей, как описано в ИСО/МЭК 15408-3, приложение А.4 ADV_TDS: "Подсистемы и модули". На этом уровне доверия декомпозиция требуется только на уровне подсистем.

При выполнении этой деятельности оценщик исследует другие свидетельства, представленные ОО (например, ЗБ, пользовательское руководство оператора), чтобы сделать заключение о том, что "Описание ОО" в таких свидетельствах совместимо с описанием, содержавшимся в проекте ОО.

ИСО/МЭК 15408-3 ADV_TDS.2.2C: В проекте должны быть идентифицированы все подсистемы ФБО.

10.8.2.2.2 Шаг оценивания ADV_TDS.2-2

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что все подсистемы ФБО идентифицированы.

В шаге оценивания ADV_TDS.2-1 были идентифицированы все подсистемы ОО и вынесено заключение о том, что подсистемы, не относящиеся к ФБО, правильно охарактеризованы. Основываясь на этом, подсистемы, которые не характеризовались как не относящиеся к ФБО, следует точно идентифицировать. Оценщик делает заключение о том, что для аппаратного и программного обеспечения, установленного и настроенного согласно руководству в семействе "Подготовительные процедуры" (AGD_PRE), каждая подсистема идентифицирована или как являющаяся частью ФБО, или как не являющаяся.

ИСО/МЭК 15408-3 ADV_TDS.2.3C: В проекте должно приводиться описание режима функционирования для каждой подсистемы ФБО, не влияющей на выполнение ФТБ, с предоставлением детальной информации, достаточной для того, чтобы установить, что подсистема не влияет на выполнение ФТБ.

10.8.2.2.3 Шаг оценивания ADV_TDS.2-3

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что каждая подсистема ФБО, не влияющая на выполнение ФТБ, описана таким образом, что оценщик может сделать вывод о том, что подсистема является не влияющей на выполнение ФТБ.

Не влияющие на выполнение ФТБ подсистемы не нужно описывать подробно относительно того, как они функционируют в системе. Однако оценщик на основании свидетельств, предоставленных разработчиком, выносит заключение, что подсистемами, у которых нет описаний верхнего уровня, являются не влияющие на выполнение ФТБ. Следует отметить, что если разработчик предоставляет однородный уровень детализации при предоставлении документации, тогда этот шаг оценивания будет в основном выполнен, так как смысл категоризации подсистем в том, чтобы позволить разработчику предоставлять меньше информации относительно не влияющих на выполнение ФТБ подсистем, чем для подсистем, осуществляющих выполнение ФТБ и поддерживающих выполнение ФТБ.

Не влияющая на выполнение ФТБ подсистема та, от которой не зависят осуществляющие и поддерживающие выполнение ФТБ; она не играет роли в осуществлении функций выполнения ФТБ.

ИСО/МЭК 15408-3 ADV_TDS.2.4C: В проекте должно приводиться описание осуществляющих выполнение ФТБ режимов безопасности тех подсистем, которые являются осуществляющими выполнение ФТБ.

10.8.2.2.4 Шаг оценивания ADV_TDS.2-4

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что он предоставляет полное, точное и детальное описание для обеспечивающего выполнение ФТБ режима функционирования подсистем, обеспечивающих выполнение ФТБ.

Разработчик может определять подсистемы как обеспечивающие выполнение ФТБ, поддерживающие выполнение ФТБ или не влияющие на выполнение ФТБ, но эти "категории" используются только для того, чтобы описать количество и тип информации, которую должен предоставить разработчик, и может использоваться для ограничения количества информации, которую должен предоставить разработчик в том случае, если сам процесс разработки не производит требуемую документацию. Были подсистемы категорированы разработчиком или нет, в обязанности оценщика входит задача вынести заключение о том, что в подсистемы включена соответствующая их роли в ОО (обеспечивающие выполнение ФТБ и т.д.) информация и получить соответствующую информацию от разработчика в случае, если разработчик не предоставил необходимую информацию для конкретной подсистемы.

Обеспечивающий выполнение ФТБ режим функционирования ссылается на то, каким образом подсистемой выполняются функции, которые обеспечивают выполнение ФТБ. Детализированное описание режима функционирования, хотя и не приводится на уровне алгоритмического описания, описывает то, каким образом предоставляется функциональная возможность, в терминах того, что представляют собой данные ключа и структуры данных, какие взаимоотношения контроля существуют внутри подсистемы и каким образом данные элементы функционируют вместе для предоставления обеспечивающего выполнение ФТБ режима функционирования. Такое описание также ссылается на поддерживающий выполнение ФТБ режим функционирования, который следует рассматривать оценщику при выполнении последующих шагов оценивания.

Чтобы определить полноту и точность, оценщик исследует другую доступную информацию (например, функциональную спецификацию, описание архитектуры безопасности, представление реализации). Описаниям функций в этих документах следует быть совместимыми с тем, что предоставляется в свидетельствах данного шага оценивания.

ИСО/МЭК 15408-3 ADV_TDS.2.5C: В проекте должна приводиться аннотация поддерживающих и не влияющих на выполнение ФТБ режимов безопасности тех подсистем, которые являются осуществляющими выполнение ФТБ.

10.8.2.2.5 Шаг оценивания ADV_TDS.2-5

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что он предоставляет полное и точное описание верхнего уровня для поддерживающих и не влияющих на выполнение ФТБ режимов функционирования подсистем, обеспечивающих выполнение ФТБ.

Разработчик может определять подсистемы как обеспечивающие выполнение ФТБ, поддерживающие выполнение ФТБ или не влияющие на выполнение ФТБ, но эти "категории" используются только для того, чтобы описать количество и тип информации, которую должен предоставить разработчик, и может использоваться для ограничения количества информации, которую должен предоставить разработчик в том случае, если сам процесс разработки не производит требуемую документацию. Были подсистемы категорированы разработчиком или нет, в обязанности оценщика входит задача вынести заключение о том, что в подсистемы включена соответствующая их роли в ОО (обеспечивающие выполнение ФТБ и т.д.) информация и получить соответствующую информацию от разработчика в случае, если разработчик не предоставил необходимую информацию для конкретной подсистемы.

В отличие от предыдущего шага оценивания, на этом шаге оценивания требуется, чтобы оценщик оценил поддерживающую и не влияющую на выполнение ФТБ информацию, предоставленную для осуществляющих выполнение ФТБ подсистем. У этой оценки двойная цель. Во-первых, следует, чтобы оценивание предоставило оценщику лучшее понимание способа функционирования для каждой подсистемы. Во-вторых, оценщик делает заключение о том, что описаны все осуществляющие выполнение ФТБ режимы функционирования, имеющиеся в подсистеме. В отличие от предыдущего шага оценивания, информация, предусмотренная для описания поддерживающих или не влияющих на выполнение ФТБ режимов функционирования, не должна быть настолько детализированной, как информация по осуществляющему выполнение ФТБ режиму функционирования. Например, для структуры данных или элементов данных, которые не относятся к осуществляющим выполнение ФТБ функциям, не должно быть приведено подробных описаний (а также описания могут быть вовсе не нужны). Решение относительно того, что "высокий уровень" описания значит для конкретного ОО, возлагается на оценщика, и оценщик должен получить достаточно информации от разработчика (даже если она окажется эквивалентной информации, предусмотренной для подсистем, которые являются осуществляющими выполнение ФТБ) для вынесения положительного вердикта по данному шагу оценивания.

Оценщику следует помнить, однако, что целью данного шага оценивания не является приобретение "совершенного" доверия, поэтому суждение оценщика должно применяться при внесении заключения о количестве и составе свидетельств, требуемых для вынесения вердикта для данного шага оценивания.

Чтобы определить полноту и точность, оценщик исследует другую доступную информацию (например, функциональную спецификацию, описание архитектуры безопасности, представление реализации). Описаниям функций в этих документах следует быть совместимыми с тем, что обеспечено свидетельствами данного шага оценивания. В частности, следует использовать функциональную спецификацию для вынесения заключения о том, что режим функционирования, необходимый для осуществления интерфейсов ФБО, описанных в функциональной спецификации, полностью описан подсистемой, так как режим функционирования будет или осуществляющим, или поддерживающим, или не влияющим на выполнение ФТБ.

ИСО/МЭК 15408-3 ADV_TDS.2.6C: В проекте должна приводиться аннотация режимов безопасности тех подсистем, которые являются осуществляющими выполнение ФТБ.

10.8.2.2.6 Шаг оценивания ADV_TDS.2-6

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что он предоставляет полное и точное описание верхнего уровня для режимов функционирования подсистем, поддерживающих выполнение ФТБ.

Разработчик может определять подсистемы как обеспечивающие выполнение ФТБ, поддерживающие выполнение ФТБ или не влияющие на выполнение ФТБ, но эти "категории" используются только для того, чтобы описать количество и тип информации, которую должен предоставить разработчик, и может использоваться для ограничения количества информации, которую должен предоставить разработчик в том случае, если сам процесс разработки не производит требуемую документацию. Были подсистемы категорированы разработчиком или нет, в обязанности оценщика входит задача вынести заключение о том, что в подсистемы включена соответствующая их роли в ОО (обеспечивающие выполнение ФТБ и т.д.) информация и получить соответствующую информацию от разработчика в случае, если разработчик не предоставил необходимую информацию для конкретной подсистемы.

В отличие от предыдущих двух шагов оценивания, на этом шаге оценивания требуется, чтобы разработчик предоставил, а оценщик оценил информацию по поводу поддерживающих выполнение ФТБ подсистем. На такие подсистемы следует ссылаться в описаниях осуществляющих выполнение ФТБ подсистем, так же, как и в описаниях взаимодействий для шага оценивания ADV_TDS.2-7. У этой оценки, как и на предыдущем шаге оценивания, двойная цель. Во-первых, следует, чтобы оценивание предоставляло оценщику лучшее понимание способа функционирования для каждой поддерживающей выполнение ФТБ подсистемы. Во-вторых, оценщик делает заключение о том, что все режимы функционирования, имеющиеся в подсистеме, описаны в должной степени детализации для ясного определения способа поддержания подсистемой режима функционирования и того, что сам режим при этом не является осуществляющим выполнение ФТБ. Информация, предусмотренная для описания режимов функционирования подсистем, поддерживающих выполнение ФТБ, не должна быть такой же детализированной, как информация по осуществляющему выполнение ФТБ режиму функционирования. Например, для структуры данных или элементов данных, которые не относятся к осуществляющим выполнение ФТБ функциям, не должно быть приведено подробных описаний (а также описания могут быть вовсе не нужны). Решение относительно того, что "высокий уровень" описания значит для конкретного ОО, возлагается на оценщика, и оценщик должен получить достаточно информации от разработчика (даже если она окажется эквивалентной информации, предусмотренной для подсистем, которые являются осуществляющими выполнение ФТБ) для вынесения вердикта по данному шагу оценивания.

Оценщику следует помнить, однако, что целью данного шага оценивания не является приобретение "совершенного" доверия, поэтому суждение оценщика должно применяться при внесении заключения о количестве и составе свидетельств, требуемых для вынесения вердикта для данного шага оценивания.

Чтобы определить полноту и точность, оценщик исследует другую доступную информацию (например, функциональную спецификацию, описание архитектуры безопасности, представление реализации). Описаниям функций в этих документах следует быть совместимыми с тем, что предоставлено в свидетельствах данного шага оценивания. В частности, следует использовать функциональную спецификацию для вынесения заключения о том, что режим функционирования, необходимый для осуществления интерфейсов ФБО, описанных в функциональной спецификации, полностью описан подсистемой, так как режим функционирования будет или осуществляющим, или поддерживающим, или не влияющим на выполнение ФТБ.

ИСО/МЭК 15408-3 ADV_TDS.2.7C: В проекте должно приводиться описание взаимодействий всех подсистем ФБО между собой.

10.8.2.2.7 Шаг оценивания ADV_TDS.2-7

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что в нем приведены описания взаимодействия между подсистемами ФБО.

Цель описания взаимодействий между осуществляющими выполнение ФТБ подсистемами и другими подсистемами состоит в том, чтобы предоставить читателю лучшее понимание того, каким образом ФБО выполняют свои функции. Эти взаимодействия не должны быть характеризованы на уровне реализации (например, параметры из одной процедуры в одной подсистеме переходят к процедуре другой подсистемы; глобальные переменные; сигналы аппаратных средств (например, прерывания) от подсистемы аппаратных средств до системы обработки прерываний), но элементы данных, идентифицированных для конкретной подсистемы, которые будут использоваться другой подсистемой, должны быть охвачены этим рассмотрением. Любые отношения контроля между подсистемами (например, имеется подсистема, ответственная за формирование базовых правил для межсетевого экрана и подсистемы, которая фактически реализует эти правила) также следует включать в описание.

Следует отметить, что хотя разработчику следует характеризовать все взаимодействия между подсистемами, оценщику нужно использовать свое собственное суждение при оценивании полноты описания. Если причина взаимодействия подсистем не ясна или если есть относящиеся к выполнению ФТБ взаимодействия (выявленные, например, в ходе анализа описания режимов функционирования подсистемы), которые недостаточно ясно описаны, оценщику следует удостовериться, что эта информация предоставлена разработчиком. Однако, если оценщик может сделать заключение о том, что взаимодействия между конкретным набором подсистем, хотя и не полностью описаны разработчиком, не помогут ни в понимании общих функций, ни в понимании функций безопасности, обеспечиваемых ФБО, тогда оценщик может считать описание достаточным; полнота описания ради самой полноты не преследуется.

ИСО/МЭК 15408-3 ADV_TDS.2.8C: В прослеживании должно быть продемонстрировано, что все описанные в проекте ОО режимы функционирования прослеживаются к вызывающим их ИФБО.

10.8.2.2.8 Шаг оценивания ADV_TDS.2-8

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что он содержит полное и точное прослеживание от ИФБО, описанных в функциональной спецификации, к подсистемам ФБО, описанным в проекте ОО.

Описание подсистем в проекте ОО представляет описание того, каким образом ФБО реализуются, достаточно детально для обеспечивающих выполнение ФТБ частей ФБО, и на более высоком уровне представления для других частей ФБО. ИФБО обеспечивают описание того, каким образом осуществлена реализация. Свидетельства от разработчика идентифицируют подсистему, которая вовлечена в процесс запроса операции от ИФБО, и идентифицируют различные подсистемы, которые прежде всего ответственны за реализацию функций. Следует отметить, что для данного шага оценивания не требуется предоставления полного "дерева вызовов" для каждого ИФБО.

Оценщик оценивает полноту прослеживания, удостоверяясь, что каждый ИФБО прослежен по крайней мере к одной подсистеме. Проверка точности более сложна.

Первый аспект точности заключается в том, что каждый ИФБО прослеживается к подсистеме, находящейся в пределах ФБО. Такое заключение может быть сделано при рассмотрении описания подсистем, их взаимодействия и при определении места подсистемы в архитектуре безопасности на основании данной информации. Следующий аспект точности - то, что прослеживание имеет смысл. Например, прослеживание ИФБО, обеспечивающего контроль доступа, к подсистеме, которая проверяет пароли, не будет являться точным. Оценщику и в этом случае следует при вынесении заключения использовать свое суждение. Цель состоит в том, что эта информация поможет оценщику в понимании системы, реализации выполнения ФТБ и способов, которыми сущности в пределах ФБО могут взаимодействовать с ФБО. Большая часть оценки того, точно ли описаны ФТБ подсистемами, выполняется при проведении других шагов оценивания.

10.8.2.3 Действие ADV_TDS.2.2E

10.8.2.3.1 Шаг оценивания ADV_TDS.2-9

Оценщик должен исследовать ФТБ ОО и проект ОО, чтобы сделать заключение о том, что все ФТБ в ЗБ охвачены в проекте ОО.

Оценщик может провести прослеживание между ФТБ для ОО и проектом ОО. Это прослеживание, вероятно, будет проводиться от функционального требования до ряда подсистем. Следует отметить, что это прослеживание, вероятно, будет по уровню детализации ниже, чем для компонента или даже для элемента требований, из-за операций (назначения, уточнения, выбора), которые выполняются над функциональным требованием автором ЗБ.

Например, компонент FDP_ACC.1 "Ограниченное управление доступом" содержит элемент с операцией назначения. Если бы в ЗБ содержалось, например, десять правил в назначении для данного компонента FDP_ACC.1, и эти правила применялись бы в определенных местах в пределах пятнадцати модулей, то для оценщика некорректно было бы проследить компонент FDP_ACC.1 к одной подсистеме и утверждать о завершении шага оценивания. Вместо этого оценщик должен проследить первое правило компонента FDP_ACC.1 к подсистеме А и режимам функционирования х, у и z; второе правило компонента FDP_ACC.1 к подсистеме А и режимам функционирования х, р и q; и т.д.

10.8.2.3.2 Шаг оценивания ADV_TDS.2-10

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что в нем точно представлены все ФТБ.

Оценщик удостоверяется, что для каждого из ФТБ, перечисленных в подразделе ЗБ "Функциональные требования безопасности", есть соответствующее описание в проекте ОО, которое детализирует, каким образом ФБО отвечают этому требованию. Это требуется для того, чтобы оценщик идентифицировал собрание подсистем, которые отвечают за осуществление данного функционального требования, а затем исследовал эти подсистемы, чтобы понять, каким образом выполняется требование. Наконец, оценщик оценивает точность выполнения требования.

Например, если требования в ЗБ определяют основанный на ролевой модели механизм управления доступом, оценщик сначала идентифицирует подсистемы, которые способствуют реализации этого механизма. Это может быть сделано с применением углубленного изучения или с применением понимания проекта ОО или работ, полученных в предыдущих шагах оценивания. Следует отметить, что это прослеживание необходимо только для идентификации подсистем и не является полным анализом.

Следующий шаг - понять, какой из механизмов подсистемы осуществляется. Например, если в проекте описывается реализация управления доступом, основанная на битах защиты UNIX, то проект не является точным отражением требований по управлению доступом в ЗБ для того примера, который использовался выше. Если оценщик не может сделать заключение о том, что механизм был реализован точным образом из-за недостаточной детализации предоставленной ему информации, то ему нужно будет оценить, были ли все осуществляющие выполнение ФТБ подсистемы идентифицированы и был ли предоставлен для этих подсистем достаточный уровень детализации.

10.8.3 Подвид деятельности по оценке (ADV_TDS.3)

10.8.3.1 Цели

Цель этого подвида деятельности состоит в том, чтобы определить, обеспечено ли в проекте ОО "Описание ОО" в терминах подсистем, достаточное для определения границ ФБО, и обеспечено ли описание внутренней структуры ФБО в терминах модулей (и, опционально, представлений верхнего уровня). Оценщику предоставляется подробное описание осуществляющих выполнение ФТБ модулей и достаточный объем информации о поддерживающих и не влияющих на выполнение ФТБ модулей, чтобы сделать заключение о том, что ФТБ полностью и точно осуществлены; как таковой, проект ОО предоставляет объяснение представления реализации.

10.8.3.2 Исходные данные

Свидетельствами оценки для этого подвида деятельности являются:

a) ЗБ;

b) функциональная спецификация;

c) описание архитектуры безопасности;

d) проект ОО.

10.8.3.3 Замечания по применению

Есть три типа деятельности, которую оценщик должен предпринять относительно проекта ОО. Во-первых, оценщик делает заключение о том, что границы ФБО описаны достаточным образом. Во-вторых, оценщик делает заключение о том, что разработчик предоставил документацию, которая соответствует содержанию и требованиям представления для этой подсистемы, и эта документация совместима с другой документацией, предусмотренной для ОО. Наконец, оценщик должен проанализировать информацию о проекте, включая описание осуществляющих выполнение ФТБ модулей (подробно) и поддерживающих и не влияющих на выполнение ФТБ (менее подробно) для того, чтобы понять, каким образом реализована система, и с этим пониманием удостовериться, что ИФБО в функциональной спецификации описаны достаточным образом и что тестовая информация в достаточной мере тестирует ФБО (проводится в шагах оценивания класса ATE: Тестирование).

Важно отметить, что, в то время как разработчик обязан обеспечить полное описание ФБО (хотя и в меньшей степени детализации для поддерживающих и не влияющих на выполнение ФТБ модулей, чем для осуществляющих выполнение ФТБ), предполагается, что оценщик будет использовать собственное суждение при выполнении анализа ФБО. Хотя и ожидается, что оценщик будет исследовать каждый модуль, степень детализации при таком рассмотрении может быть различной. Оценщик анализирует каждый модуль, чтобы определить степень влияния функций модуля на безопасность системы; глубина анализа может изменяться в зависимости от роли модуля в системе. Важный аспект этого анализа - то, что оценщику следует использовать другую предоставленную ему документацию (краткую и функциональную спецификацию ОО, описание архитектуры безопасности, документацию по внутренней структуре ФБО), чтобы сделать заключение о том, что описанные функции правильны и что неявное обозначение поддерживающих или не влияющих на выполнение ФТБ модулей (см. ниже) поддерживается их ролью в системной архитектуре.

Разработчик может определять модули как обеспечивающие выполнение ФТБ, поддерживающие выполнение ФТБ или не влияющие на выполнение ФТБ, но эти "категории" используются только для того, чтобы описать количество и тип информации, которую должен предоставить разработчик, и может использоваться для ограничения количества информации, которую должен предоставить разработчик в том случае, если сам процесс разработки не производит требуемую документацию. Были модули категорированы разработчиком или нет, в обязанности оценщика входит задача вынести заключение о том, что в модули включена соответствующая их роли в ОО (обеспечивающие выполнение ФТБ и т.д.) информация и получить соответствующую информацию от разработчика в случае, если разработчик не предоставил необходимую информацию для конкретного модуля.

10.8.3.4 Действие ADV_TDS.3.1E

ИСО/МЭК 15408-3 ADV_TDS.3.1C: В проекте должно приводиться описание структуры ОО на уровне подсистем.

10.8.3.4.1 Шаг оценивания ADV_TDS.3-1

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что структура всего ОО описана в терминах подсистем.

Оценщик удостоверяется, что все подсистемы ОО идентифицированы. Это "Описание ОО" будет использоваться в качестве исходных данных для шага оценивания ADV_TDS.3-2, где идентифицированы части ОО, которые составляют ФБО. Таким образом, это требование относится ко всему ОО, а не только к ФБО.

ОО (и ФБО) может быть описан на нескольких уровнях детализации (то есть подсистем и модулей). В зависимости от сложности ОО его проект может быть описан в терминах подсистем и модулей, как описано в ИСО/МЭК 15408-3, приложение А.4 ADV_TDS: "Подсистемы и модули". Для очень простого ОО, который может быть описан исключительно на уровне "модуля" (см. ADV_TDS.3-2), этот шаг оценивания не применим и поэтому считается удовлетворенным.

При выполнении этой деятельности оценщик исследует другие свидетельства, представленные по ОО (например, ЗБ, пользовательское руководство оператора), чтобы сделать заключение о том, что "Описание ОО" в таких свидетельствах совместимо с описанием, содержавшимся в проекте ОО.

ИСО/МЭК 15408-3 ADV_TDS.3.2C: Проект должен содержать описание ФБО на уровне модулей.

10.8.3.4.2 Шаг оценивания ADV_TDS.3-2

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что все ФБО описаны в терминах модулей.

Оценщик исследует модули на определенные свойства на других шагах оценивания; на этом шаге оценивания оценщик делает заключение о том, что модульное описание касается всего ФБО, а не только части ФБО. При вынесении этого заключения оценщик использует и другие свидетельства (например, функциональную спецификацию, описание архитектуры безопасности). Например, если функциональная спецификация содержит интерфейсы функции, которая не описана в явном виде в описании проекта ОО, может возникнуть ситуация, что часть ФБО не была включена в описание достаточным образом. Вынесение этого заключения, вероятно, будет повторяющимся процессом, поскольку чем больший анализ проводится для других свидетельствах, тем больше доверия может быть приобретено относительно полноты документации.

В отличие от подсистем, модули описывают реализацию на уровне детализации, которая может служить руководством по рассмотрению представления реализации. Рекомендуется, чтобы описание модулей было таким, чтобы можно было реализовать модуль по описанию, и полученная реализация будет: 1) идентичной фактической реализации ФБО в терминах интерфейсов, представленных и используемых модулем, и 2) алгоритмически идентичной модулю ФБО. Например, в RFC 793 предоставлено описание верхнего уровня протокола TCP. Это описание обязательно является независимой реализацией. Хотя требуемый уровень детализации обеспечен, это описание проекта не является достаточным, потому что не является определенным для реализации. Фактическая реализация может быть добавлена к протоколу, определенному в RFC, и выбор реализации (например, использование глобальных данных относительно локальных данных в различных частях реализации) может оказать влияние на выполненный анализ. В описании проекта модуля TCP должны быть перечислены интерфейсы, предоставленные в реализации (а не просто определенные в RFC 793), а также описание алгоритма обработки, связанного с модулями, осуществляющими TCP (предполагается, что это часть ФБО).

ИСО/МЭК 15408-3 ADV_TDS.3.3C: В проекте должны быть идентифицированы все подсистемы ФБО.

10.8.3.4.3 Шаг оценивания ADV_TDS.3-3

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что все подсистемы ФБО идентифицированы.

Если проект представлен исключительно в терминах модулей, то подсистемы в этих требованиях эквивалентны модулям, и деятельность следует выполнить на уровне модуля.

В шаге оценивания ADV_TDS.3-1 были идентифицированы все подсистемы ОО и вынесено заключение о том, что подсистемы, не относящиеся к ФБО, правильно охарактеризованы. Основываясь на этом, подсистемы, которые не характеризовались как не относящиеся к ФБО, следует точно идентифицировать. Оценщик делает заключение о том, что для аппаратного и программного обеспечения, установленного и настроенного согласно руководству в семействе "Подготовительные процедуры" (AGD_PRE), каждая подсистема идентифицирована или как являющаяся частью ФБО или как не являющаяся.

ИСО/МЭК 15408-3 ADV_TDS.3.4C: В проекте должно приводиться описание каждой из подсистем ФБО.

10.8.3.4.4 Шаг оценивания ADV_TDS.3-4

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что для каждой подсистемы ФБО описана роль в осуществлении ФТБ, описанных в ЗБ.

Если проект представлен исключительно в терминах модулей, то этот шаг оценивания считается удовлетворенным оценкой, сделанной на последующих шагах оценивания; в этом случае от оценщика не требуется явных действий.

Для достаточно сложных систем, где, помимо модульного описания, предоставлено описание уровня подсистем ФБО, цель описания на уровне подсистем состоит в том, чтобы предоставить оценщику контекст для последующего модульного описания. Поэтому оценщик удостоверяется, что описание на уровне подсистем содержит описание того, каким образом ФТБ достигаются в проекте, но на уровне представления выше модульного описания. В этом описании следует рассмотреть механизмы, используемые на уровне, который равен уровню модульных описаний; это предоставит оценщику план действий для разумной оценки информации, содержащейся в описании модуля. Правильно составленный набор описаний подсистемы может помочь оценщику в определении модулей, которые являются самыми важными для анализа, таким образом сфокусировав деятельность оценки на частях ФБО, которые имеют наибольшее значение для осуществления ФТБ.

Оценщик удостоверяется, что описаны все подсистемы ФБО. Описание следует сосредоточить на роли, которую подсистема играет в осуществлении или поддержке реализации выполнения ФТБ и должно быть предоставлено достаточно информации для понимания функций, имеющих значение для выполнения ФТБ.

ИСО/МЭК 15408-3 ADV_TDS.3.5C: В проекте должно приводиться описание взаимодействий всех подсистем ФБО между собой.

10.8.3.4.5 Шаг оценивания ADV_TDS.3-5

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что в нем приведены описания взаимодействий между подсистемами ФБО.

Если проект представлен только в терминах модулей, тогда этот шаг оценивания будет считаться удовлетворенным оцениванием, сделанным во время последующих шагов оценивания. В таком случае от оценщика не требуется никаких явных действий.

По системам, которые достаточно сложные, чтобы предоставлять описание ФБО на уровне подсистем в дополнение к модульному описанию, цель описания взаимодействий между подсистемами состоит в том, чтобы предоставить читателю лучшее понимание того, каким образом ФБО выполняют свои функции. Эти взаимодействия не нужно характеризовать на уровне реализации (например, параметры из процедуры в одной подсистеме переходят к процедуре другой подсистемы; глобальные переменные; сигналы аппаратных средств (например, прерывания) от подсистемы аппаратных средств до системы обработки прерываний), но элементы данных, идентифицированных для конкретной подсистемы, которые будут использоваться другой подсистемой, следует охватить этим рассмотрением. Любые отношения контроля между подсистемами (например, имеется подсистема, ответственная за формирование базовых правил для межсетевого экрана и подсистемы, которая фактически реализует эти правила) также следует включать в описание.

Следует отметить, что, хотя разработчику следует характеризовать все взаимодействия между подсистемами, оценщику нужно использовать свое собственное суждение при оценивании полноты описания. Если причина взаимодействия подсистем не ясна, или если есть относящиеся к выполнению ФТБ взаимодействия (выявленные, например, в ходе анализа описания режимов функционирования подсистемы), которые не описаны в явном виде, оценщику следует удостовериться, что эта информация предоставлена разработчиком. Однако, если оценщик может сделать заключение о том, что взаимодействия между конкретным набором подсистем, хотя и не полностью описаны разработчиком, не помогут ни в понимании общих функций, ни в понимании функций безопасности, обеспечиваемых ФБО, тогда оценщик может считать описание достаточным; полнота описания ради самой полноты не преследуется.

ИСО/МЭК 15408-3 ADV_TDS.3.6C: В проекте должно быть осуществлено прослеживание подсистем ФБО с модулями ФБО.

10.8.3.4.6 Шаг оценивания ADV_TDS.3-6

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что прослеживание между подсистемами ФБО и модулями ФБО осуществлено в полной мере.

Если проект представлен исключительно в терминах модулей, то этот шаг оценивания считается удовлетворенным.

Для ОО, которые достаточно сложны для описания на уровне подсистем ФБО в дополнение к модульному описанию, разработчик предоставляет простое прослеживание, показывающее, каким образом модули ФБО размещаются по подсистемам. Это предоставит оценщику руководство по выполнению оценки на уровне модулей. Чтобы определить полноту, оценщик исследует каждое прослеживание и делает заключение о том, что все подсистемы прослежены, по крайней мере, к одному модулю, и что все модули прослежены хотя бы к одной подсистеме.

10.8.3.4.7 Шаг оценивания ADV_TDS.3-7

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что прослеживание между подсистемами ФБО и модулями ФБО является точным.

Если проект представлен исключительно в терминах модулей, то этот шаг оценивания считается удовлетворенным.

Для ОО, которые достаточно сложны для предоставления описания на уровне подсистем ФБО в дополнение к модульному описанию, разработчик предоставляет простое прослеживание, показывающее, каким образом модули ФБО размещаются по подсистемам. Это предоставит оценщику руководство по выполнению оценки на уровне модулей. Оценщик может проверить точность прослеживания при выполнении других шагов оценивания. "Неточное" прослеживание - такое, где модуль по ошибке связан с подсистемой, а его функции не используются в пределах подсистемы. Поскольку прослеживание предназначается в качестве руководства для поддержки более подробного анализа, оценщику следует применить соответствующее усилие к этому шагу оценивания. Не следует тратить слишком много усилий на проверку точности прослеживания.

Погрешности, которые приводят к недопониманию проекта и которые раскрываются при выполнении этого или иных шагов оценивания, следует связать с этим шагом оценивания и исправить.

ИСО/МЭК 15408-3 ADV_TDS.3.7C: В проекте должен быть описан каждый осуществляющий выполнение ФТБ модуль с точки зрения его назначения и взаимодействия с другими модулями.

10.8.3.4.8 Шаг оценивания ADV_TDS.3-8

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что описание назначения каждого осуществляющего выполнение ФТБ модуля является полным и точным.

Разработчик может определять модули как обеспечивающие выполнение ФТБ, поддерживающие выполнение ФТБ или не влияющие на выполнение ФТБ, но эти "категории" используются только для того, чтобы описать количество и тип информации, которую должен предоставить разработчик, и может использоваться для ограничения количества информации, которую должен предоставить разработчик в том случае, если сам процесс разработки не производит требуемую документацию. Были модули категорированы разработчиком или нет, в обязанности оценщика входит задача вынести заключение о том, что в модули включена соответствующая их роли в ОО (обеспечивающие выполнение ФТБ и т.д.) информация и получить соответствующую информацию от разработчика в случае, если разработчик не предоставил необходимую информацию для конкретного модуля.

В назначении модуля приводится описание, указывающее на выполняемые модулем функции. Следует предостеречь оценщика о следующем. Этот шаг оценивания следует направить на то, чтобы предоставить оценщику понимание функционирования модуля таким образом, чтобы можно было сделать заключение о достаточности реализации выполнения ФТБ, а также для поддержания архитектурного анализа, выполняемого для компонента ADV_ARC. Пока у оценщика есть хорошее понимание функционирования модуля и его взаимодействия с другими модулями и с ОО в целом, оценщику следует считать цель шага оценивания достигнутой и не участвовать в проверке документации разработчика (требуя, например, полного алгоритмического описания для очевидного представления реализации).

ИСО/МЭК 15408-3 ADV_TDS.3.8C: В проекте должен быть описан каждый осуществляющий выполнение ФТБ модуль с точки зрения его относящихся к ФТБ интерфейсов, значений, предоставляемых этими интерфейсами в ответ на запросы, взаимодействий с другими модулями и вызываемыми интерфейсами этих модулей.

10.8.3.4.9 Шаг оценивания ADV_TDS.3-9

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что описание интерфейсов, представленных каждым осуществляющим выполнение ФТБ модулем, содержит точное и полное описание относящихся к ФТБ интерфейсов, значений, предоставляемых этими интерфейсами в ответ на запросы, взаимодействий с другими модулями и вызываемыми интерфейсами этих модулей.

Относящиеся к ФТБ интерфейсы модуля - это интерфейсы, используемые другими модулями в качестве средства вызова относящихся к ФТБ операций, и для получения исходных или результирующих данных от модуля. Цель спецификации этих интерфейсов состоит в том, чтобы сделать заключение об их осуществлении во время тестирования. Межмодульные интерфейсы, которые не связаны с ФТБ, не должны определяться и описываться, так как они не рассматриваются в тестировании. Также и другие внутренние интерфейсы, которые не рассматриваются при пересечении связанных с ФТБ путей выполнения (например, фиксированных внутренних путей) не должны определяться и описываться, так как они не рассматриваются в тестировании.

Относящиеся к ФТБ интерфейсы описываются в терминах того, как они вызываются, и какие значения возвращают. Это описание включает перечень связанных с ФТБ параметров и описание этих параметров. Следует отметить, что глобальные данные также считаются параметрами, если используются модулем (или как исходные, или как данные на выходе) при вызове. Если у параметра есть ряд значений (например, параметр "флажок"), то определяется полный комплект значений параметра, который будет влиять на обработку модуля. Также и параметры, представляющие структуры данных, описываются таким образом, чтобы каждая область структуры данных была идентифицирована и описана. Следует отметить, что в различных языках программирования могут быть дополнительные "интерфейсы", которые были бы неявными, например оператор/функция перезагрузки в C++. Этот "неявный интерфейс" в описании класса должен быть также описан как часть проекта ОО нижнего уровня. Следует отметить, что хотя модуль может представлять только один интерфейс, чаще всего он представляет собой набор связанных интерфейсов.

В терминах оценки параметров (на входе и выходе) модуля нужно также рассмотреть любое использование глобальных данных. Модуль "использует" глобальные данные, если он читает или записывает данные. Для того чтобы удостовериться, что описание таких параметров (если оно используется), выполнено полно, оценщик использует иную информацию, предоставленную о модуле в проекте ОО (интерфейсы, алгоритмическое описание и т.д.), а также описание особого набора глобальных данных, оцениваемого в шаге оценивания ADV_TDS.3-9. Например, оценщик может сначала сделать заключение об обработке модуля, исследуя его функцию и представленные интерфейсы (особенно параметры интерфейсов). Тогда он может проверить, "касается" ли обработка какой-либо из глобальных областей данных, идентифицированных в проекте ОО. Затем оценщик делает заключение о том, что для каждой глобальной области данных, которая "затронута", глобальная область данных описана как исходные данные или данные на выходе исследуемого оценщиком модуля.

Запрос - описание программно-справочного типа, которое можно использовать, чтобы правильно вызвать интерфейс модуля при написании программы для использования функций модуля через данный интерфейс. Это включает необходимые данные на входе и выходе, включая любую настройку глобальных переменных.

Значения, возвращаемые через интерфейс, относятся к значениям, которые передаются через параметры или сообщения; значениям, которые сам вызов функции возвращает в стиле "С" вызова функции программы; значениям, которые прошли через глобальные средства (такие как определенные ошибочные процедуры в *iх-подобных операционных системах).

Чтобы удостовериться в полноте описания, оценщик исследует другую доступную информацию (например, функциональную спецификацию, описание архитектуры безопасности, представление реализации), чтобы удостовериться, что все данные, необходимые для того, чтобы выполнить функции модуля, предоставлены модулю, и что любые значения, которые необходимы другим модулям от оцениваемого модуля, идентифицированы как возвращаемые модулем. Оценщик определяет точность описания, удостоверяясь, что описание обработки соответствует информации, обозначенной как получаемой или передаваемой от интерфейса.

Поскольку модули на таком низком уровне, может быть трудно определить воздействие полноты и точности на основании анализа другой документации, такой как руководство пользователя по эксплуатации, функциональная спецификация, внутренняя структура ФБО или "Описание архитектуры безопасности". Однако оценщик использует информацию этих документов по мере возможности, чтобы удостовериться в точности и полноте описания назначения. Такому анализу может помочь анализ, выполняемый для шагов оценивания элемента ADV_TDS.3.10С, при котором прослеживаются ИФБО в функциональной спецификации к модулям ФБО.

ИСО/МЭК 15408-3 ADV_TDS.3.9C: В проекте должен быть описан каждый поддерживающий и не влияющий на выполнение ФТБ модуль с точки зрения его назначения и взаимодействия с другими модулями.

10.8.3.4.10 Шаг оценивания ADV_TDS.3-10

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что поддерживающие выполнение ФТБ и не влияющие на выполнение ФТБ модули правильно категорированы.

В случаях, когда разработчик обеспечил различное количество информации для различных модулей, была сделана неявная классификация. Таким образом, модули (например) с детализацией, представленной на связанных с ФТБ интерфейсах (см. ADV_TDS.3.10C), являются модулями-кандидатами на категорию осуществляющих выполнение ФТБ, хотя проведенный оценщиком анализ может привести к заключению, что некоторые из них - поддерживающие или не влияющие на выполнение ФТБ. Те, для которых приводится только описание назначения и взаимодействия с другими модулями, например "неявно категорируются" как поддерживающие или не влияющие на выполнение ФТБ.

В этих случаях усилия оценщика направлены на попытку сделать заключение на основе свидетельств, предусмотренных для каждого модуля, неявно категорированного как поддерживающий или не влияющий на выполнение ФТБ, и информации об оценке других модулей (в проекте ОО, функциональной спецификации, описании архитектуры безопасности и руководстве пользователя по эксплуатации), является ли модуль действительно поддерживающим или не влияющим на выполнение ФТБ. На этом уровне доверия может быть допущена некоторая ошибка; оценщик не обязан быть абсолютно уверен, что данный модуль - поддерживающий или не влияющий на выполнение ФТБ, даже если он маркирован как таковой. Однако, если предоставленные свидетельства указывают, что поддерживающие или не влияющие на выполнение ФТБ модули являются на самом деле осуществляющими выполнение ФТБ, оценщик запрашивает дополнительную информацию от разработчика, чтобы сделать заключение о явной несогласованности. Например, предположим, что в документации для Модуля А (который является осуществляющим выполнение ФТБ) указано, что он вызывает Модуль В для проверки доступа некой конструкции. Когда оценщик исследует информацию, связанную с Модулем В, он обнаруживает, что разработчик предоставил только назначение и ряд взаимодействий (таким образом неявно категорируя Модуль В как поддерживающий или не влияющий на выполнение ФТБ). При исследовании назначения и взаимодействий Модуля А оценщик не находит упоминания о Модуле В, выполняющем проверку доступа, а Модуль А не отмечен как модуль, с которым взаимодействует Модуль В. В этом пункте оценщику следует обратиться к разработчику, чтобы сделать заключение о несоответствии между информацией, предоставленной в Модуле А и в Модуле В.

Другой пример, когда оценщик исследует прослеживание ИФБО к модулям в соответствии c ADV_TDS.3.2D. Этот анализ показывает, что Модуль С связан с требуемой по ФТБ идентификацией пользователя. Опять же, когда оценщик исследует информацию, связанную с Модулем С, он обнаруживает, что разработчик предоставил только назначение и ряд взаимодействий (таким образом неявно категорируя Модуль С как поддерживающий или не влияющий на выполнение ФТБ). Исследуя назначение и ряд Модуля С, оценщик не способен определить, почему Модуль С, перечисленный в прослеживании к ИФБО, касающемуся пользовательской идентификации, не классифицирован как осуществляющий выполнение требований ФТБ. И в этом случае оценщику следует обратиться к разработчику для того, чтобы сделать заключение о том, что это несоответствие.

Последний пример касается обратного случая. Допустим, разработчик предоставил информацию, связанную с Модулем D, по назначению и ряду взаимодействий (таким образом неявно категорируя Модуль В как поддерживающий или не влияющий на выполнение ФТБ). Оценщик исследует все свидетельства, включая назначение и взаимодействия для Модуля D. В назначении дается значимое описание функции Модуля D в ОО; взаимодействия совместимы с этим описанием, и нет ничего, указывающего на возможную принадлежность Модуля D к осуществляющим выполнение ФТБ. В этом случае оценщику не следует требовать дополнительную информацию о Модуле D "просто для уверенности", что он правильно категорирован. Разработчик выполнил свои обязательства, и приобретенного оценщиком доверия от неявной классификации Модуля D (по определению) достаточно для этого уровня доверия.

10.8.3.4.11 Шаг оценивания ADV_TDS.3-11

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что описание назначения каждого поддерживающего или не влияющего на выполнение ФТБ модуля выполнено полно и точно.

Описание назначения модуля указывает на то, какие функции выполняет модуль. Из описания оценщику следует быть в состоянии получить общее представление о роли модуля. Чтобы удостовериться, что описание достаточно полно, оценщик использует информацию, предоставленную о взаимодействиях модуля с другими модулями для оценки совместимости причин вызовов модуля с назначением модуля. Если описание взаимодействия содержит функции, которые не очевидны из назначения модуля или являются конфликтующими с ним, оценщик должен сделать заключение, является ли это несоответствие проблемой точности или полноты описания. Оценщику следует с подозрением относиться к слишком коротким описаниям назначения, так как значимый анализ, основанный на назначении только с одним предложением, вероятно, будет провести невозможно.

В этих случаях усилия оценщика направлены на попытку сделать заключение на основе свидетельств, предусмотренных для каждого модуля, неявно категорированного как поддерживающий или не влияющий на выполнение ФТБ, и информации об оценке других модулей (в проекте ОО, функциональной спецификации, описании архитектуры безопасности и руководстве пользователя по эксплуатации), является ли модуль действительно поддерживающим или не влияющим на выполнение ФТБ. На этом уровне доверия может быть допущена некоторая ошибка; оценщик не обязан быть абсолютно уверен, что данный модуль - поддерживающий или не влияющий на выполнение ФТБ, даже если он маркирован как таковой. Однако, если предоставленные свидетельства указывают, что поддерживающие или не влияющие на выполнение ФТБ модули являются на самом деле осуществляющими выполнение ФТБ, оценщик запрашивает дополнительную информацию от разработчика, чтобы сделать заключение о явной несогласованности. Например, предположим, что в документации для Модуля А (который является осуществляющим выполнение ФТБ) указано, что он вызывает Модуль В для проверки доступа некой конструкции. Когда оценщик исследует информацию, связанную с Модулем В, он обнаруживает, что разработчик предоставил только назначение и ряд взаимодействий (таким образом неявно категорируя Модуль В как поддерживающий или не влияющий на выполнение ФТБ). При исследовании назначения и взаимодействий Модуля А оценщик не находит упоминания о Модуле В, выполняющем проверку доступа, а Модуль А не отмечен как модуль, с которым взаимодействует Модуль В. Оценщику следует обратиться к разработчику, чтобы сделать заключение о несоответствии между информацией, предоставленной в Модуле А и Модуле В.

10.8.3.4.12 Шаг оценивания ADV_TDS.3-12

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что описание взаимодействия каждого поддерживающего или не влияющего на выполнение ФТБ модуля с другими модулями является полным и точным.

Важно отметить, что в терминах требований ИСО/МЭК 15408-3 и этого шага оценивания термин взаимодействие является менее строгим, чем интерфейс. Взаимодействие не обязательно должно быть характеризовано на уровне реализации (например, параметры из одной процедуры в одной подсистеме переходят к процедуре другой подсистемы; глобальные переменные; сигналы аппаратных средств (например, прерывания) от подсистемы аппаратных средств до системы обработки прерываний), но элементы данных, идентифицированных для конкретного модуля, которые будут использоваться другим модулем, следует охватить этим рассмотрением. Любые отношения контроля между подсистемами (например, имеется подсистема, ответственная за формирование базовых правил для межсетевого экрана и подсистемы, которая фактически реализует эти правила) также следует включать в описание.

Поскольку модули на таком низком уровне, может быть трудно определить воздействие полноты и точности на основании анализа другой документации, такой как руководство пользователя по эксплуатации, функциональная спецификация, внутренняя структура ФБО или "Описание архитектуры безопасности". Однако оценщик использует информацию этих документов по мере возможности, чтобы удостовериться в точности и полноте описания функций. Такому анализу может помочь анализ, выполняемый для шагов оценивания элемента ADV_TDS.3.10С, при котором прослеживаются ИФБО в функциональной спецификации к модулям ФБО.

Взаимодействие модуля с другими модулями рассматривается вне документа, где зафиксировано "дерево вызовов". Взаимодействие описывается с функциональной точки зрения и касается того, почему данный модуль взаимодействует с другими модулями. В назначении модуля описывается, какие функции модуль предоставляет другим модулям; во взаимодействиях следует описать, от каких модулей зависит данный модуль для выполнения своих функций.

Поскольку модули на таком низком уровне, может быть трудно определить воздействие полноты и точности на основании анализа другой документации, такой как руководство пользователя по эксплуатации, функциональная спецификация, внутренняя структура ФБО или "Описание архитектуры безопасности". Однако оценщик использует информацию этих документов по мере возможности, чтобы удостовериться в точности и полноте описания взаимодействий.

ИСО/МЭК 15408-3 ADV_TDS.3.10С: В прослеживании должно быть продемонстрировано, что все описанные в проекте ОО режимы функционирования прослеживаются к вызывающим их ИФБО.

10.8.3.4.13 Шаг оценивания ADV_TDS.3-13

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что он содержит полное и точное прослеживание от ИФБО, описанных в функциональной спецификации, к модулям ФБО, описанным в проекте ОО.

Описание модулей в проекте ОО предоставляет описание того, каким образом ФБО реализуются. ИФБО обеспечивает описание того, каким образом осуществляется реализация. Свидетельства от разработчика идентифицируют модуль, который вовлечен в процесс запроса операции от ИФБО, и идентифицируют цепочку модулей, которые прежде всего отвечают за реализацию функций. Однако для данного шага оценивания не требуется предоставить полное "дерево вызовов" для каждого ИФБО. Случаи, в которых требуется идентифицировать больше одного модуля, это модули "точки входа" или модули адаптера интерфейса, единственные функции которых - приведение исходных данных к требуемым условиям и демультиплексирование исходных данных. Прослеживание к этим модулям не дало бы оценщику никакой полезной информации.

Оценщик оценивает полноту прослеживания, удостоверяясь, что каждый ИФБО прослежен по крайней мере к одной подсистеме. Проверка точности более сложна.

Поскольку модули на таком низком уровне, может быть трудно определить воздействие полноты и точности на основании анализа другой документации, такой как руководство пользователя по эксплуатации, функциональная спецификация, внутренняя структура ФБО или "Описание архитектуры безопасности". Однако оценщик использует информацию этих документов по мере возможности, чтобы удостовериться в точности и полноте описания взаимодействий.

10.8.3.5 Действие ADV_TDS.3.2E

10.8.3.5.1 Шаг оценивания ADV_TDS.3-14

Оценщик должен исследовать ФТБ ОО и проект ОО, чтобы сделать заключение о том, что все ФТБ в ЗБ охвачены в проекте ОО.

Оценщик может провести прослеживание между ФТБ для ОО и проектом ОО. Это прослеживание, вероятно, будет проводиться от функционального требования до ряда подсистем и далее до модулей. Следует отметить, что это прослеживание, вероятно, будет по уровню детализации ниже, чем для компонента или даже для элемента требований, из-за операций (назначения, уточнения, выбора), которые выполняются над функциональным требованием автором ЗБ.

Например, компонент FDP_ACC.1 "Ограниченное управление доступом" содержит элемент с операцией назначения. Если бы в ЗБ содержалось, например, десять правил в назначении для данного компонента FDP_ACC.1, и эти правила применялись бы в определенных местах в пределах пятнадцати модулей, то для оценщика некорректно было бы проследить компонент FDP_ACC.1 к одной подсистеме и утверждать о завершении шага оценивания. Вместо этого оценщик должен проследить первое правило компонента FDP_ACC.1 к подсистеме А и режимам функционирования х, у и z; второе правило компонента FDP_ACC.1 к подсистеме А и режимам функционирования х, р и q; и т.д.

10.8.3.5.2 Шаг оценивания ADV_TDS.3-15

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что в нем точно представлены все ФТБ.

Оценщик может провести прослеживание между ФТБ для ОО и проектом ОО. Это прослеживание, вероятно, будет проводиться от функционального требования до ряда подсистем. Следует отметить, что это прослеживание, вероятно, будет по уровню детализации ниже, чем для компонента или даже для элемента требований, из-за операций (назначения, уточнения, выбора), которые выполняются над функциональным требованием автором ЗБ.

Например, если требования в ЗБ определяют основанный на ролевой модели механизм управления доступом, оценщик сначала идентифицирует подсистемы, которые способствуют реализации этого механизма. Это может быть сделано с применением углубленного изучения или с применением понимания проекта ОО или работ, полученного в предыдущих шагах оценивания. Следует отметить, что это прослеживание необходимо только для идентификации подсистем и не является полным анализом.

Следующий шаг - понять, какой из механизмов подсистем и модулей осуществляется. Например, если в проекте описывается реализация управления доступом, основанная на битах защиты UNIX, то проект не является точным отражением требований по управлению доступом в ЗБ для того примера, который использовался выше. Если оценщик не может сделать заключение о том, что механизм был реализован точным образом из-за недостаточной детализации предоставленной ему информации, то ему нужно будет оценить, были ли все осуществляющие выполнение ФТБ подсистемы идентифицированы и был ли предоставлен для этих подсистем достаточный уровень детализации.

10.8.4 Подвид деятельности по оценке (ADV_TDS.4)

10.8.4.1 Цели

Цель этого подвида деятельности состоит в том, чтобы определить, обеспечено ли в проекте ОО описание ОО в терминах подсистем, достаточное для определения границ ФБО, и обеспечено ли описание внутренней структуры ФБО в терминах модулей (и, опционально, представлений верхнего уровня). Оценщику предоставляется подробное описание осуществляющих и поддерживающих выполнение ФТБ модулей и достаточный объем информации о не влияющих на выполнение ФТБ модулей, чтобы сделать заключение о том, что ФТБ полно и точно осуществлены; как таковой, проект ОО предоставляет объяснение представления реализации.

10.8.4.2 Исходные данные

Свидетельствами оценки для этого подвида деятельности являются:

a) ЗБ;

b) функциональная спецификация;

c) описание архитектуры безопасности;

d) проект ОО.

10.8.4.3 Замечания по применению

Есть три типа деятельности, которую оценщик должен предпринять относительно проекта ОО. Во-первых, оценщик делает заключение о том, что границы ФБО описаны достаточным образом. Во-вторых, оценщик делает заключение о том, что разработчик предоставил документацию, которая соответствует содержанию и требованиям представления для этой подсистемы, и эта документация совместима с другой документацией, предусмотренной для ОО. Наконец, оценщик должен проанализировать информацию о проекте, включая описания осуществляющих выполнение ФТБ модулей (подробно) и поддерживающих и не влияющих на выполнение ФТБ (менее подробно) для того, чтобы понять, каким образом реализована система, и с этим пониманием удостовериться, что ИФБО в функциональной спецификации описан достаточным образом и что тестовая информация в достаточной мере тестирует ФБО (проводится в шагах оценивания класса ATE).

10.8.4.4 Действие ADV_TDS.4.1E

ИСО/МЭК 15408-3 ADV_TDS.4.1С: В проекте должно приводиться описание структуры ОО на уровне подсистем.

10.8.4.4.1 Шаг оценивания ADV_TDS.4-1

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что структура всего ОО описана в терминах подсистем.

Оценщик удостоверяется, что все подсистемы ОО идентифицированы. Это "Описание ОО" будет использоваться в качестве исходных данных для шага оценивания ADV_TDS.4-5, где идентифицированы части ОО, которые составляют ФБО. Таким образом, это требование относится ко всему ОО, а не только к ФБО.

ОО (и ФБО) может быть описан на нескольких уровнях детализации (то есть подсистем и модулей). В зависимости от сложности ОО его проект может быть описан в терминах подсистем и модулей, как описано в ИСО/МЭК 15408-3, приложение А.4 ADV_TDS: "Подсистемы и модули". Для очень простого ОО, который может быть описан исключительно на уровне "модуля" (см. ADV_TDS.4-3), этот шаг оценивания не применим и поэтому считается удовлетворенным.

При выполнении этой деятельности оценщик исследует другие свидетельства, представленные ОО (например, ЗБ, пользовательское руководство оператора), чтобы сделать заключение о том, что "Описание ОО" в таких свидетельствах совместимо с описанием, содержавшимся в проекте ОО.

10.8.4.4.2 Шаг оценивания ADV_TDS.4-2

Оценщик должен исследовать проектную документацию, чтобы сделать заключение о том, что полуформальную запись, используемую для описания подсистем, модулей и их интерфейсов, определяют или на нее ссылаются.

Полуформальная запись может быть определена или спонсором, или ссылкой на соответствующий стандарт. Оценщику следует предоставить прослеживание функций безопасности и их интерфейсов, уделяя особое внимание тому, какая часть документации функции или интерфейса полуформально описана и какая запись для этого используется. Оценщик исследует все использованные полуформальные записи, чтобы удостовериться, что они написаны в полуформальном стиле, а также чтобы обосновать уместность способа, которым полуформальные записи используются для ОО.

Оценщику следует помнить, что полуформальное изложение характеризуется стандартизированным форматом с четким синтаксисом, который уменьшает степень двусмысленности, возможной при неформальном изложении. Синтаксис всех полуформальных записей, используемых в функциональной спецификации, должен быть определен или должен сопровождаться ссылкой на соответствующий стандарт. Оценщик проверяет, что полуформальные записи, используемые для отражения функциональной спецификации, способны отражать особенности, относящиеся к безопасности. Чтобы определить это, оценщик может обратиться к ФТБ и сравнить заявленные в ЗБ механизмы безопасности ФБО и описанные в функциональной спецификации с использованием полуформальных записей.

ИСО/МЭК 15408-3 ADV_TDS.4.2C: В проекте должно приводиться описание структуры ОО на уровне модулей, с присвоением каждому модулю категории либо осуществляющего выполнение ФТБ, либо поддерживающего, либо не влияющего на выполнение ФТБ.

10.8.4.4.3 Шаг оценивания ADV_TDS.4-3

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что весь ФБО описан в терминах модулей.

Оценщик исследует модули на определенные свойства на других шагах оценивания; на этом шаге оценивания оценщик делает заключение о том, что модульное описание касается всего ФБО, а не только части ФБО. При вынесении этого заключения оценщик использует и другие свидетельства (например, функциональную спецификацию, описание архитектуры безопасности). Например, если функциональная спецификация содержит интерфейсы функции, которая не описана в явном виде в описании проекта ОО, может возникнуть ситуация, что часть ФБО не была включена в описание достаточным образом. Внесение этого заключения, вероятно, будет повторяющимся процессом, поскольку чем больше анализа проводится на других свидетельствах, тем больше доверия может быть приобретено относительно полноты документации.

В отличие от подсистем, модули описывают реализацию на уровне детализации, которая может служить руководством по рассмотрению представления реализации. Рекомендуется, чтобы описание модулей было таким, чтобы можно было реализовать модуль по описанию, и полученная реализация будет: 1) идентичной фактической реализации ФБО в терминах интерфейсов, представленных и используемых модулем, и 2) алгоритмически идентичной модулю ФБО. Например, в RFC 793 предоставлено описание верхнего уровня протокола TCP. Это обязательно независимая реализация. В то время как обеспечен уровень детализации, это описание проекта не является достаточным, потому что не является определенным для реализации. Фактическая реализация может быть добавлена к протоколу, определенному в RFC, и выбор реализации (например, использование глобальных данных относительно локальных данных в различных частях реализации) может оказать влияние на выполненный анализ. В описании проекта модуля TCP должны быть перечислены интерфейсы, предоставленные в реализации (а не просто определенные в RFC 793), а также описание алгоритма обработки, связанного с модулями, осуществляющими TCP (предполагается, что это часть ФБО).

10.8.4.4.4 Шаг оценивания ADV_TDS.4-4

Оценщик должен проверить проект ОО, чтобы сделать заключение о том, что модули ФБО идентифицированы или как осуществляющие выполнение ФТБ, или как не влияющие на выполнение ФТБ.

Цель определения каждого модуля (согласно роли, которую каждый конкретный модуль играет в осуществлении ФТБ) состоит в том, чтобы позволить разработчикам предоставлять меньше информации о тех частях ФБО, которые играют незначительную роль в обеспечении безопасности. Разработчик всегда может предоставить больше информации или с большей степенью детализации, чем требуется. Чаще всего это может произойти, когда информация была собрана вне контекста оценки. В таких случаях разработчик должен все равно определять модули или как осуществляющие выполнение ФТБ, или как не влияющие на выполнение ФТБ.

Точность этих обозначений постоянно рассматривается на протяжении оценивания. Проблемный вопрос - неправильное обозначение модулей как менее важных (и следовательно, предоставление меньшего объема информации), чем они являются в действительности. В то время как явные неправильные обозначения могут быть очевидными (например, определение модуля аутентификации не как осуществляющего выполнение ФТБ, притом что "Идентификация пользователей" (FIA_UID) включена в состав ФТБ), другие неправильные обозначения не могут быть обнаружены, пока не получено лучшее понимание ФБО. Оценщик поэтому должен учитывать, что эти обозначения - начальное максимальное усилие разработчика, которое в дальнейшем может подвергаться изменениям. Дальнейшее руководство предоставлено в шаге оценивания ADV_TDS.4-16, в котором исследуется точность этих обозначений.

ИСО/МЭК 15408-3 ADV_TDS.4.3C: В проекте должны быть идентифицированы все подсистемы ФБО.

10.8.4.4.5 Шаг оценивания ADV_TDS.4-5

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что все подсистемы ФБО идентифицированы.

Если проект представлен исключительно в терминах модулей, то подсистемы в этих требованиях эквивалентны модулям, и деятельность следует выполнить на уровне модуля.

В шаге оценивания ADV_TDS.4-1 были идентифицированы все подсистемы ОО, и вынесено заключение о том, что подсистемы, не относящиеся к ФБО, правильно охарактеризованы. Основываясь на этом, подсистемы, которые не характеризовались как не относящиеся к ФБО, следует точно идентифицировать. Оценщик делает заключение о том, что для аппаратного и программного обеспечения, установленного и настроенного согласно руководству в семействе "Подготовительные процедуры" (AGD_PRE), каждая подсистема идентифицирована или как являющаяся частью ФБО или как не являющаяся.

ИСО/МЭК 15408-3 ADV_TDS.4.4C: В проекте должно приводиться полуформальное описание каждой из подсистем ФБО, сопровождающееся вспомогательным пояснительным неформальным текстом, если это представляется целесообразным.

10.8.4.4.6 Шаг оценивания ADV_TDS.4-6

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что для каждой подсистемы ФБО описана роль в осуществлении ФТБ, описанных в ЗБ.

Если проект представлен исключительно в терминах модулей, то этот шаг оценивания считается удовлетворенным оценкой, сделанной на последующих шагах оценивания; в этом случае от оценщика не требуется явных действий.

Для достаточно сложных систем, где помимо модульного описания, предоставлено описание уровня подсистем ФБО, цель описания на уровне подсистем состоит в том, чтобы предоставить оценщику контекст для последующего модульного описания. Поэтому оценщик удостоверяется, что описание на уровне подсистем содержит описание того, каким образом ФТБ достигаются в проекте, но на уровне представления выше модульного описания. В этом описании следует рассмотреть механизмы, используемые на уровне, который равен уровню модульных описаний; это предоставит оценщику план действий для разумной оценки информации, содержащейся в описании модуля. Хорошо составленный набор описаний подсистемы может помочь оценщику в определении модулей, которые являются самыми важными для анализа, таким образом сфокусировав деятельность оценки на частях ФБО, которые имеют наибольшее значение для осуществления ФТБ.

Оценщик удостоверяется, что описаны все подсистемы ФБО. Хотя описание следует сосредоточить на роли, которую подсистема играет в осуществлении или поддержке реализации выполнения ФТБ, должно быть предоставлено достаточно информации для понимания функций, имеющих значение для выполнения ФТБ.

ИСО/МЭК 15408-3 ADV_TDS.4.5C: В проекте должно приводиться описание взаимодействий всех подсистем ФБО между собой.

10.8.4.4.7 Шаг оценивания ADV_TDS.4-7

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что в нем приведены описания взаимодействия между подсистемами ФБО.

Если проект представлен исключительно в терминах модулей, то этот шаг оценивания считается удовлетворенным оценкой, сделанной на последующих шагах оценивания; в этом случае от оценщика не требуется явных действий.

Для достаточно сложных систем, где помимо модульного описания, предоставлено описание уровня подсистем ФБО, цель описания взаимодействий между осуществляющими выполнение ФТБ подсистемами и другими подсистемами состоит в том, чтобы предоставить читателю лучшее понимание того, каким образом ФБО выполняют свои функции. Эти взаимодействия не должны быть характеризованы на уровне реализации (например, параметры из одной процедуры в одной подсистеме переходят к процедуре другой подсистемы; глобальные переменные; сигналы аппаратных средств (например, прерывания) от подсистемы аппаратных средств до системы обработки прерываний), но элементы данных, идентифицированных для конкретной подсистемы, которые будут использоваться другой подсистемой, должны быть охвачены этим рассмотрением. Любые отношения контроля между подсистемами (например, имеется подсистема, ответственная за формирование базовых правил для межсетевого экрана и подсистемы, которая фактически реализует эти правила) также следует включать в описание.

Следует отметить, что, хотя разработчику следует охарактеризовать все взаимодействия между подсистемами, оценщик должен использовать свое собственное суждение при оценивании полноты описания. Если причина взаимодействия подсистем неясна или если есть относящиеся к выполнению ФТБ взаимодействия (выявленные, например в ходе анализа описания режимов функционирования подсистемы), которые не описаны в явном виде, оценщику следует удостовериться, что эта информация предоставлена разработчиком. Однако, если оценщик может сделать заключение о том, что взаимодействия между конкретным набором подсистем хотя и не полностью описаны разработчиком, не помогут ни в понимании общих функций, ни в понимании функций безопасности, обеспеченных ФБО, тогда оценщик может считать описание достаточным; полнота описания ради самой полноты не преследуется.

ИСО/МЭК 15408-3 ADV_TDS.4.6C: В проекте должно быть осуществлено прослеживание подсистем ФБО с модулями ФБО.

10.8.4.4.8 Шаг оценивания ADV_TDS.4-8

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что прослеживание между подсистемами ФБО и модулями ФБО осуществлено в полной мере.

Если проект представлен исключительно в терминах модулей, то этот шаг оценивания считается удовлетворенным.

Для ОО, которые достаточно сложны для предоставления описания на уровне подсистем ФБО в дополнение к модульному описанию, разработчик предоставляет простое прослеживание, показывающее, каким образом модули ФБО размещаются по подсистемам. Это предоставит оценщику руководство по выполнению оценки на уровне модулей. Чтобы сделать заключение о полноте, оценщик исследует каждое прослеживание и делает заключение о том, что все подсистемы прослежены по крайней мере к одному модулю, и что все модули прослежены хотя бы к одной подсистеме.

10.8.4.4.9 Шаг оценивания ADV_TDS.4-9

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что прослеживание между подсистемами ФБО и модулями ФБО является точным.

Если проект представлен исключительно в терминах модулей, то этот шаг оценивания считается удовлетворенным.

Для ОО, которые достаточно сложны для предоставления описания на уровне подсистем ФБО в дополнение к модульному описанию, разработчик предоставляет простое прослеживание, показывающее, каким образом модули ФБО размещаются по подсистемам. Это предоставит оценщику руководство по выполнению оценки на уровне модулей. Оценщик может проверить точность прослеживания при выполнении других шагов оценивания. "Неточное" прослеживание - такое, где модуль по ошибке связан с подсистемой, а его функции не используются в пределах подсистемы. Поскольку прослеживание предназначается в качестве руководства для поддержки более подробного анализа, оценщику следует применить соответствующее усилие к этому шагу оценивания. Не следует тратить слишком много усилий на проверку точности прослеживания. Погрешности, которые приводят к недопониманию по проекту, которые раскрываются при выполнении этого или иных шагов оценивания, следует связать с этим шагом оценивания и исправить.

ИСО/МЭК 15408-3 ADV_TDS.4.7C: В проекте должен быть описан каждый осуществляющий и поддерживающий выполнение ФТБ модуль с точки зрения его назначения и взаимодействия с другими модулями.

10.8.4.4.10 Шаг оценивания ADV_TDS.4-10

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что описание назначения каждого осуществляющего и поддерживающего выполнение ФТБ модуля является полным и точным.

Разработчик может определять модули как обеспечивающие выполнение ФТБ, поддерживающие выполнение ФТБ или не влияющие на выполнение ФТБ, но эти "категории" используются только для того, чтобы описать количество и тип информации, которую должен предоставить разработчик, и может использоваться для ограничения количества информации, которую должен предоставить разработчик в том случае, если сам процесс разработки не производит требуемую документацию. Были модули категорированы разработчиком или нет, в обязанности оценщика входит вынести заключение о том, что в модули включена соответствующая их роли в ОО (обеспечивающие выполнение ФТБ и т.д.) информация и получить соответствующую информацию от разработчика в случае, если разработчик не предоставил необходимую информацию для конкретного модуля.

В назначении модуля приводится описание, указывающее на выполняемые модулем функции. Следует предостеречь оценщика о следующем. Этот шаг оценивания следует направить на то, чтобы предоставить оценщику понимание функционирования модуля таким образом, чтобы можно было сделать заключение о достаточности реализации выполнения ФТБ, а также для поддержания архитектурного анализа, выполняемого для компонента ADV_ARC. Пока у оценщика есть хорошее понимание функционирования модуля и его взаимодействия с другими модулями и с ОО в целом, оценщику следует считать цель шага оценивания достигнутой и не участвовать в проверке документации разработчика (требуя, например, полного алгоритмического описания для очевидного представления реализации).

ИСО/МЭК 15408-3 ADV_TDS.4.8C: В проекте должен быть описан каждый осуществляющий и поддерживающий выполнение ФТБ модуль с точки зрения относящихся к ФТБ интерфейсов, значений, предоставляемых этими интерфейсами в ответ на запросы, взаимодействий с другими модулями и вызываемыми интерфейсами этих модулей.

10.8.4.4.11 Шаг оценивания ADV_TDS.4-11

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что описание интерфейсов, представленных каждым осуществляющим и поддерживающим выполнение ФТБ модулем, содержит точное и полное описание относящихся к ФТБ интерфейсов, значений, предоставляемых этими интерфейсами в ответ на запросы, взаимодействий с другими модулями и вызываемыми интерфейсами этих модулей.

Относящиеся к ФТБ интерфейсы модуля - это интерфейсы, используемые другими модулями в качестве средства вызова относящихся к ФТБ операций, и для получения исходных или результирующих данных от модуля. Цель спецификации этих интерфейсов состоит в том, чтобы сделать заключение об их осуществлении во время тестирования. Межмодульные интерфейсы, которые не связаны с ФТБ, не должны определяться и описываться, так как они не рассматриваются в тестировании. Также и другие внутренние интерфейсы, которые не рассматриваются при пересечении связанных с ФТБ путей выполнения (например, фиксированных внутренних путей), не должны определяться и описываться, так как они не рассматриваются в тестировании.

Относящиеся к ФТБ интерфейсы описываются в терминах того, как они вызываются и какие значения возвращают. Это описание включает перечень связанных с ФТБ параметров и описание этих параметров. Следует отметить, что глобальные данные также считаются параметрами, если используются модулем (или как исходные, или как данные на выходе) при вызове. Если у параметра есть ряд значений (например, параметр "флажок"), то определяется полный комплект значений параметра, который будет влиять на обработку модуля. Также и параметры, представляющие структуры данных, описываются таким образом, чтобы каждая область структуры данных была идентифицирована и описана. Следует отметить, что в различных языках программирования могут быть дополнительные "интерфейсы", которые были бы неявными; например оператор/функция перезагрузки в C++. Этот "неявный интерфейс" в описании класса должен быть также описан как часть проекта ОО нижнего уровня. Следует отметить, что, хотя модуль может представлять только один интерфейс, чаще всего он представляет собой набор связанных интерфейсов.

В терминах оценки параметров (на входе и выходе) модуля нужно также рассмотреть любое использование глобальных данных. Модуль "использует" глобальные данные, если он читает или записывает данные. Чтобы удостовериться, что описание таких параметров (если оно используется) выполнено полно, оценщик использует иную информацию, предоставленную о модуле в проекте ОО (интерфейсы, алгоритмическое описание, и т.д.), а также описание особого набора глобальных данных, оцениваемого в шаге оценивания ADV_TDS.4-10. Например, оценщик может сначала сделать заключение об обработке модуля, исследуя его функцию и представленные интерфейсы (особенно параметры интерфейсов). Тогда он может проверить, "касается" ли обработка какой-либо из глобальных областей данных, идентифицированных в проекте ОО. Затем оценщик делает заключение о том, что для каждой глобальной области данных, которая "затронута", глобальная область данных описана как исходные данные или данные на выходе исследуемого оценщиком модуля.

Запросы - описание программно-справочного типа, которое можно использовать, чтобы правильно вызвать интерфейс модуля при написании программы для использования функций модуля через данный интерфейс. Это включает необходимые данные на входе и выходе, включая любую настройку глобальных переменных.

Значения, возвращаемые через интерфейс, относятся к значениям, которые передаются через параметры или сообщения; значениям, которые сам вызов функции возвращает в стиле "С" вызова функции программы; значениям, которые прошли через глобальные средства (такие как определенные ошибочные процедуры в *iх-подобных операционных системах).

Чтобы удостовериться в полноте описания, оценщик исследует другую доступную информацию (например, функциональную спецификацию, описание архитектуры безопасности, представление реализации), чтобы удостовериться, что все данные, необходимые для того, чтобы выполнить функции модуля, предоставлены модулю, и что любые значения, которые необходимы другим модулям от оцениваемого модуля, идентифицированы как возвращаемые модулем. Оценщик определяет точность описания, удостоверяясь, что описание обработки соответствует информации, обозначенной как получаемая или передаваемая от интерфейса.

Поскольку модули на таком низком уровне, то может быть трудно сделать заключение о воздействии на полноту и точность на основании анализа другой документации, такой как руководство пользователя по эксплуатации, функциональная спецификация, внутренняя структура ФБО или "Описание архитектуры безопасности". Однако оценщик использует информацию этих документов по мере возможности, чтобы удостовериться в точности и полноте описания назначения. Такому анализу может помочь анализ, выполняемый для шагов оценивания элемента ADV_TDS.4.10С, при котором прослеживаются ИФБО в функциональной спецификации к модулям ФБО.

ИСО/МЭК 15408-3 ADV_TDS.4.9C: В проекте должен быть описан каждый не влияющий на выполнение ФТБ модуль с точки зрения его назначения и взаимодействия с другими модулями.

10.8.4.4.12 Шаг оценивания ADV_TDS.4-12

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что не влияющие на выполнение ФТБ модули правильно категорированы.

Как упоминалось в шаге оценивания ADV_TDS.4-3, меньше информации запрашивается о модулях, которые не влияют на выполнение ФТБ. В этих случаях усилия оценщика направлены на попытку сделать заключение на основе свидетельств, предусмотренных для каждого модуля, неявно категорированного как не влияющего на выполнение ФТБ, и информации об оценке других модулей (в проекте ОО, функциональной спецификации, описании архитектуры безопасности и руководстве пользователя по эксплуатации), является ли модуль действительно не влияющим на выполнение ФТБ. На этом уровне доверия может быть допущена некоторая ошибка; оценщик не обязан быть абсолютно уверен, что данный модуль - не влияющий на выполнение ФТБ, даже если он маркирован как таковой. Однако если предоставленные свидетельства указывают, что не влияющие на выполнение ФТБ модули являются на самом деле осуществляющими или поддерживающими выполнение ФТБ, оценщик запрашивает дополнительную информацию от разработчика, чтобы сделать заключение о явной несогласованности. Например, предположим, что в документации для Модуля А (который является осуществляющим выполнение ФТБ) указано, что он вызывает Модуль В для проверки доступа некой конструкции. Когда оценщик исследует информацию, связанную с Модулем В, он обнаруживает, что разработчик предоставил только назначение и ряд взаимодействий (таким образом неявно категорируя Модуль В как поддерживающий или не влияющий на выполнение ФТБ). При исследовании назначения и взаимодействий Модуля А, оценщик не находит упоминания о Модуле В, выполняющем проверку доступа, а Модуль А не отмечен как модуль, с которым взаимодействует Модуль В. В этом пункте оценщику следует обратиться к разработчику, чтобы сделать заключение о несоответствии между информацией, предоставленной в Модуле А и Модуле В.

В случаях, когда разработчик обеспечил различное количество информации для различных модулей, была сделана неявная классификация. Таким образом, модули, например, с детализацией, представленной на связанных с ФТБ интерфейсах (см. ADV_TDS.3.10C), являются модулями-кандидатами на категорию осуществляющих выполнение ФТБ, хотя проведенный оценщиком анализ может привести к заключению, что некоторые из них поддерживающие или не влияющие на выполнение ФТБ. Те, для которых приводится только описание назначения и взаимодействия с другими модулями, например "неявно категорируются" как поддерживающие или не влияющие на выполнение ФТБ.

Другой пример - когда оценщик исследует прослеживание ИФБО к модулям в соответствии с ADV_TDS.4.2D. Этот анализ показывает, что Модуль С связан с требуемой по ТФБ идентификацией пользователя. Опять же, когда оценщик исследует информацию, связанную с Модулем С, он обнаруживает, что разработчик предоставил только назначение и ряд взаимодействий (таким образом неявно категорируя Модуль С как поддерживающий или не влияющий на выполнение ФТБ). Исследуя назначение и ряд Модуля С, оценщик не способен сделать заключение, почему Модуль С, перечисленный в прослеживании к ИФБО, касающемуся пользовательской идентификации, не классифицирован как осуществляющий выполнение требований ФТБ. И в этом случае оценщику следует обратиться к разработчику для того, чтобы сделать заключение о том, что это несоответствие.

Последний пример касается обратного случая. Допустим, разработчик предоставил информацию, связанную с Модулем D, по назначению и ряду взаимодействий (таким образом неявно категорируя Модуль В как поддерживающий или не влияющий на выполнение ФТБ). Оценщик исследует все свидетельства, включая назначение и взаимодействия для Модуля D. В назначении дается значимое описание функции Модуля D в ОО, взаимодействия совместимы с этим описанием, и нет ничего, указывающего на возможную принадлежность Модуля D к осуществляющим выполнение ФТБ. В этом случае оценщику не следует требовать дополнительную информацию о Модуле D "просто для уверенности", что он правильно категорирован. Разработчик выполнил свои обязательства и приобретенного оценщиком доверия от неявной классификации Модуля D (по определению) достаточно для этого уровня доверия.

10.8.4.4.13 Шаг оценивания ADV_TDS.4-13

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что описание назначения каждого не влияющего на выполнение ФТБ модуля выполнено полно и точно.

Описание назначения модуля указывает на то, какие функции выполняет модуль. Из описания оценщику следует быть в состоянии получить общее представление о роли модуля. Чтобы удостовериться, что описание достаточно полно, оценщик использует информацию, предоставленную о взаимодействиях модуля с другими модулями для оценки совместимости причин вызовов модуля с назначением модуля. Если описание взаимодействия содержит функции, которые не очевидны из назначения модуля или являются конфликтующими с ним, оценщик должен сделать заключение, является ли это несоответствие проблемой точности или полноты описания. Оценщику следует с подозрением относиться к слишком коротким описаниям назначения, так как значимый анализ, основанный на назначении только с одним предложением, вероятно, будет невозможно провести.

Поскольку модули на таком низком уровне, может быть трудно сделать заключение о воздействии на полноту и точность на основании анализа другой документации, такой как руководство пользователя по эксплуатации, функциональная спецификация, внутренняя структура ФБО или "Описание архитектуры безопасности". Однако оценщик использует информацию этих документов по мере возможности, чтобы удостовериться в точности и полноте описания назначения. Такому анализу может помочь анализ, выполняемый для шагов оценивания элемента ADV_TDS.4.10С, при котором прослеживаются ИФБО в функциональной спецификации к модулям ФБО.

10.8.4.4.14 Шаг оценивания ADV_TDS.4-14

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что описание взаимодействия каждого не влияющего на выполнение ФТБ модуля с другими модулями является полным и точным.

Важно отметить, что в терминах требований ИСО/МЭК 15408-3 и этого шага оценивания, термин взаимодействие является менее строгим, чем интерфейс. Взаимодействие не обязательно должно быть характеризовано на уровне реализации (например, параметры из одной процедуры в одной подсистеме переходят к процедуре другой подсистемы; глобальные переменные; сигналы аппаратных средств (например, прерывания) от подсистемы аппаратных средств до системы обработки прерываний), но элементы данных, идентифицированных для конкретного модуля, которые будут использоваться другим модулем, следует охватить этим рассмотрением. Любые отношения контроля между подсистемами (например, имеется подсистема, ответственная за формирование базовых правил для межсетевого экрана и подсистемы, которая фактически реализует эти правила) также следует включать в описание.

Поскольку модули на таком низком уровне, то может быть трудно сделать заключение о воздействии на полноту и точность на основании анализа другой документации, такой как руководство пользователя по эксплуатации, функциональная спецификация, внутренняя структура ФБО или "Описание архитектуры безопасности". Однако оценщик использует информацию этих документов по мере возможности, чтобы удостовериться в точности и полноте описания функций. Такому анализу может помочь анализ, выполняемый для шагов оценивания элемента ADV_TDS.3.10С, при котором прослеживаются ИФБО в функциональной спецификации к модулям ФБО.

Взаимодействие модуля с другими модулями может быть отражено различными способами. Цель для проекта ОО состоит в том, чтобы предоставить оценщику понимание (частично посредством анализа взаимодействий модуля) роли поддерживающих и не влияющих на выполнение ФТБ модулей в общем проекте ОО. Понимание этой роли поможет оценщику на последующем шаге оценивания ADV_TDS.4-7.

Взаимодействие модуля с другими модулями рассматривается вне документа, где зафиксировано дерево вызовов. Взаимодействие описывается с функциональной точки зрения и касается того, почему данный модуль взаимодействует с другими модулями. В назначении модуля описывается, какие функции модуль предоставляет другим модулям; во взаимодействиях следует описать, от каких модулей зависит данный модуль для выполнения своих функций.

Поскольку модули на таком низком уровне, то может быть трудно сделать заключение о воздействии на полноту и точность на основании анализа другой документации, такой как руководство пользователя по эксплуатации, функциональная спецификация, внутренняя структура ФБО или "Описание архитектуры безопасности". Однако оценщик использует информацию этих документов по мере возможности, чтобы удостовериться в точности и полноте описания взаимодействий.

ИСО/МЭК 15408-3 ADV_TDS.4.10С: В прослеживании должно быть продемонстрировано, что все описанные в проекте ОО режимы функционирования прослеживаются к вызывающим их ИФБО.

10.8.4.4.15 Шаг оценивания ADV_TDS.4-15

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что он содержит полное и точное прослеживание от ИФБО, описанных в функциональной спецификации, к модулям ФБО, описанным в проекте ОО.

Описание модулей в проекте ОО предоставляют описание того, каким образом ФБО реализуются. ИФБО обеспечивают описание того, каким образом осуществляется реализация. Свидетельства от разработчика идентифицируют модуль, который вовлечен в процесс запроса операции от ИФБО, и идентифицируют цепочку модулей, которые прежде всего отвечают за реализацию функций. Однако для данного шага оценивания не требуется предоставить полное "дерево вызовов" для каждого ИФБО. Случаи, в которых требуется идентифицировать больше одного модуля - это модули "точки входа" или модули адаптера интерфейса, единственные функции которых - приведение исходных данных к требуемым условиям и демультиплексирование исходных данных. Прослеживание к этим модулям не дало бы оценщику никакой полезной информации.

Оценщик оценивает полноту прослеживания, удостоверяясь, что каждый ИФБО прослежен по крайней мере к одной подсистеме. Проверка точности более сложна.

Первый аспект точности заключается в том, что каждый ИФБО прослеживается к подсистеме, находящейся в пределах ФБО. Такое заключение может быть сделано при рассмотрении описания подсистем и их взаимодействия и определении места подсистемы в архитектуре безопасности на основании данной информации. Следующий аспект точности - то, что прослеживание имеет смысл. Например, прослеживание ИФБО, обеспечивающего контроль доступа, к подсистеме, которая проверяет пароли, не будет являться точным. Оценщику и в этом случае при вынесении заключения следует использовать свое суждение. Цель состоит в том, что эта информация поможет оценщику в понимании системы, реализации выполнения ФТБ и способов, которыми сущности в пределах ФБО могут взаимодействовать с ФБО. Большая часть оценки того, точно ли описаны ФТБ подсистемами, выполняется при проведении других шагов оценивания.

10.8.4.5 Действие ADV_TDS.4.2E

10.8.4.5.1 Шаг оценивания ADV_TDS.4-16

Оценщик должен исследовать ФТБ ОО и проект ОО, чтобы сделать заключение о том, что все ФТБ в ЗБ охвачены в проекте ОО.

Оценщик может провести прослеживание между ФТБ для ОО и проектом ОО. Это прослеживание, вероятно, будет проводиться от функционального требования до ряда подсистем и далее до модулей. Следует отметить, что это прослеживание, вероятно, будет по уровню детализации ниже, чем для компонента или даже для элемента требований из-за операций (назначения, уточнения, выбора), которые выполняются над функциональным требованием автором ЗБ.

Например, компонент FDP_ACC.1 "Ограниченное управление доступом" содержит элемент с операцией назначения. Если бы в ЗБ содержалось, например, десять правил в назначении для данного компонента FDP_ACC.1, и эти правила применялись бы в определенных местах в пределах пятнадцати модулей, то для оценщика некорректно было бы проследить компонент FDP_ACC.1 к одной подсистеме и утверждать о завершении шага оценивания. Вместо этого оценщик должен проследить первое правило компонента FDP_ACC.1 к подсистеме А и режимам функционирования х, у и z; второе правило компонента FDP_ACC.1 к подсистеме А и режимам функционирования х, р и q; и т.д.

10.8.4.5.2 Шаг оценивания ADV_TDS.4-17

Оценщик должен исследовать проект ОО, чтобы сделать заключение о том, что в нем точно представлены все ФТБ.

Оценщик может провести прослеживание между ФТБ для ОО и проектом ОО. Это прослеживание, вероятно, будет проводиться от функционального требования до ряда подсистем. Следует отметить, что это прослеживание, вероятно, будет по уровню детализации ниже, чем для компонента или даже для элемента требований из-за операций (назначения, уточнения, выбора), которые выполняются над функциональным требованием автором ЗБ.

Например, если требования в ЗБ определяют основанный на ролевой модели механизм управления доступом, оценщик сначала идентифицирует подсистемы, которые способствуют реализации этого механизма. Это может быть сделано с применением углубленного изучения или с применением понимания проекта ОО или работ, полученного в предыдущих шагах оценивания. Следует отметить, что это прослеживание необходимо только для идентификации подсистем и не является полным анализом.

Следующий шаг - понять, какой из механизмов подсистем и модулей осуществляется. Например, если в проекте описывается реализация управления доступом, основанная на битах защиты UNIX, то проект не является точным отражением требований по управлению доступом в ЗБ для того примера, который использовался выше. Если оценщик не может сделать заключение о том, что механизм был реализован точным образом из-за недостаточной детализации предоставленной ему информации, то ему нужно будет оценить, были ли все осуществляющие выполнение ФТБ подсистемы и модули идентифицированы, или был ли предоставлен для этих подсистем и модулей достаточный уровень детализации.

10.8.5 Подвид деятельности по оценке (ADV_TDS.5)

Общее руководство отсутствует; за консультациями по выполнению данного подвида деятельности следует обращаться в конкретную систему оценки.

10.8.6 Подвид деятельности по оценке (ADV_TDS.6)

Общее руководство отсутствует; за консультациями по выполнению данного подвида деятельности следует обращаться в конкретную систему оценки.

11 Класс AGD: Руководства

11.1 Введение

Вид деятельности "Руководства" предназначен для определения достаточности документации, регламентирующей, как пользователь может работать с ОО безопасным образом. В такой документации следует учитывать различные типы пользователей (например, тех, кто принимает, устанавливает, администрирует и осуществляет эксплуатацию ОО), чьи неправильные действия могли бы отрицательно повлиять на безопасность ОО или их собственных данных.

Класс "Руководства" разделен на два семейства, которые касаются, во-первых, руководства пользователя по подготовительным процедурам (о том, что должно делаться для перевода поставленного ОО в его оцененную конфигурацию для среды функционирования согласно описанию в ЗБ, то есть руководство по приемке и установке ОО), а во-вторых - руководства пользователя по эксплуатации (о том, что должно делаться во время функционирования ОО в его оцененной конфигурации, то есть функционирование и администрирование).

11.2 Замечания по применению

Вид деятельности "Руководства" применяется к тем функциям и интерфейсам, которые связаны с безопасностью ОО. Безопасная конфигурация ОО описывается в ЗБ.

11.3 Руководство пользователя по эксплуатации (AGD_OPE)

11.3.1 Подвид деятельности по оценке (AGD_OPE.1)

11.3.1.1 Цели

Цели данного подвида деятельности состоят в том, чтобы сделать заключение, описаны ли в руководстве пользователя для каждой пользовательской роли функции безопасности и интерфейсы, предоставляемые ФБО; предоставлены ли инструкции и указания по безопасному использованию ОО; адресуются ли процедуры безопасности ко всем возможным режимам функционирования; способствует ли руководство упрощению предотвращения и обнаружения потенциально опасных состояний ОО и не является ли руководство необоснованным и вводящим в заблуждение.

11.3.1.2 Исходные данные

Свидетельствами оценки для этого подвида деятельности являются:

a) ЗБ;

b) функциональная спецификация;

c) проект ОО, если он применим;

d) руководство пользователя.

11.3.1.3 Действие AGD_OPE.1.1E

ИСО/МЭК 15408-3 AGD_OPE.1.1C: В руководстве пользователя по эксплуатации для каждой пользовательской роли должно быть представлено описание доступных пользователям функций, возможных прав и обязанностей, которыми следует управлять в защищенной среде функционирования, а также уместных предупреждений.

11.3.1.3.1 Шаг оценивания AGD_OPE.1-1

Оценщик должен исследовать руководство пользователя, чтобы сделать заключение, описаны ли в нем для каждой пользовательской роли доступные пользователю функции и привилегии, которыми следует управлять в среде функционирования, а также соответствующие предостережения.

В зависимости от конфигурации ОО различные пользовательские роли могут иметь различные привилегии при использовании некоторых функций ОО. Это означает, что некоторым пользователям разрешено выполнять определенные функции, в то время как другим пользователям это не разрешается. Эти функции и привилегии следует описать в руководстве пользователя для каждой пользовательской роли.

Для каждой пользовательской роли в руководстве идентифицируются функции и привилегии, которыми нужно управлять, типы команд, требуемых для них, а также причины таких команд. Рекомендуется, чтобы руководство пользователя содержало предупреждения относительно использования этих функций и привилегий. В предупреждениях следует описывать ожидаемые последствия, возможные побочные эффекты и возможные взаимодействия с другими функциями и привилегиями.

ИСО/МЭК 15408-3 AGD_OPE.1.2C: В руководстве пользователя по эксплуатации в рамках каждой пользовательской роли должно быть представлено описание принципов безопасной работы с предоставленными в ОО интерфейсами.

11.3.1.3.2 Шаг оценивания AGD_OPE.1-2

Оценщик должен исследовать руководство пользователя по эксплуатации, чтобы сделать заключение, описаны ли в нем для каждой пользовательской роли принципы безопасной работы с предоставляемыми ОО интерфейсами.

В руководстве пользователя следует представить рекомендации относительно эффективного использования ФБО (например, практика пересмотра и смены пароля, предполагаемая частота создания резервных копий файлов пользователей, обсуждение влияния изменения пользовательских привилегий на доступ).

ИСО/МЭК 15408-3 AGD_ОPE.1.3С: В руководстве пользователя по эксплуатации должно быть представлено описание доступных для каждой пользовательской роли функций и интерфейсов, в особенности всех параметров безопасности под управлением пользователя, с указанием безопасных значений, если это уместно.

11.3.1.3.3 Шаг оценивания AGD_ОPE.1-3

Оценщик должен исследовать руководство пользователя по эксплуатации, чтобы сделать заключение о том, что оно описывает для каждой пользовательской роли доступные функции безопасности и интерфейсы, в особенности все параметры безопасности под управлением пользователя, с указанием для них безопасных значений.

В руководство пользователя следует включать краткий обзор функциональных возможностей безопасности, видимых через пользовательские интерфейсы.

В руководстве пользователя следует идентифицировать и описать назначение, режимы функционирования, а также взаимосвязи интерфейсов и функций безопасности.

Для каждого интерфейса и каждой функции безопасности в руководстве пользователя следует описать:

a) метод (методы) вызова интерфейса (например, с использованием командной строки, системных вызовов языка программирования, меню, командной клавиши);

b) параметры, которые устанавливаются пользователем, их назначение, допустимые значения и значения по умолчанию, а также безопасное и небезопасное использование данных параметров как по отдельности, так и в некой комбинации;

c) реакцию, сообщения или возвращаемый код непосредственно от ФБО.

Оценщику следует рассмотреть функциональную спецификацию и ЗБ в целях вынесения заключения о том, что описанные в этих документах ФБО согласованы с руководством пользователя по эксплуатации. Оценщик должен удостовериться, что руководство пользователя по эксплуатации достаточно полно для того, чтобы позволить всем типам пользователей безопасное использование ФБО через доступные ИФБО. В рамках оказания содействия оценщик может подготовить неформальное прослеживание между руководством и этими документами. Любые упущения в этом прослеживании могут указывать на неполноту руководства.

ИСО/МЭК 15408-3 AGD_ОPE.1.4С: В руководстве пользователя по эксплуатации для каждой пользовательской роли должно быть четкое представление каждого типа имеющих значение для безопасности событий, связанных с доступными пользователю обязательными для выполнения функциями, включая изменение характеристик безопасности сущностей, находящихся под управлением ФБО.

11.3.1.3.4 Шаг оценивания AGD_OPE.1-4

Оценщик должен исследовать руководство пользователя по эксплуатации, чтобы сделать заключение о том, что оно содержит для каждой пользовательской роли описание каждого типа относящихся к безопасности событий, связанных с доступными пользователю обязательными для выполнения функциями, включая изменение характеристик безопасности сущностей, находящихся под управлением ФБО, и операции, предпринимаемые после сбоя или ошибки эксплуатации.

Все типы событий, имеющих значение для безопасности, детализируются для каждой пользовательской роли таким образом, что каждый пользователь знает, какие события могут произойти и какие меры (если таковые возможны) ему, скорее всего, придется применить для поддержания безопасности. События, имеющие значение для безопасности, которые могут произойти во время функционирования ОО (переполнение журнала аудита, падение системы, обновления записей пользователей, например удаление учетной записи пользователя при его увольнении из организации), определены в руководстве соответствующим образом для того, чтобы позволить пользователю вмешаться в функционирование ОО в целях поддержания безопасного функционирования.

ИСО/МЭК 15408-3 AGD_OPE.1.5C: В руководстве пользователя по эксплуатации должны быть идентифицированы все возможные режимы работы ОО (включая операции после сбоев или ошибок эксплуатации), их последствия и участие в обеспечении безопасного функционирования.

11.3.1.3.5 Шаг оценивания AGD_OPE. 1-5

Оценщик должен исследовать руководство пользователя по эксплуатации и другие свидетельства оценки, чтобы сделать заключение о том, что в руководстве идентифицированы все возможные режимы работы ОО (включая, если возможно, операции восстановления после сбоев или ошибок эксплуатации), их последствия и участие в обеспечении безопасного функционирования.

Другие свидетельства оценки, в особенности функциональная спецификация, являются источниками информации, которые оценщику следует использовать, чтобы сделать заключение о том, что руководство содержит достаточную информацию.

Если тестовая документация включена в пакет доверия, то информация, предоставленная в этих свидетельствах, может также использоваться для того, чтобы сделать заключение о том, что документация руководств достаточна. Детализация, предоставленная на этапах тестирования, может использоваться для подтверждения того, что предоставленное руководство является достаточным для использования и администрирования ОО.

Оценщику следует сосредоточить усилия на одном видимом пользователю ИФБО единовременно, сравнивая руководство по безопасному использованию ИФБО с другими свидетельствами оценки в целях вынесения заключения о том, что руководство, связанное с ИФБО, достаточно для безопасного использования этого ИФБО (то есть соответствует ФТБ). Оценщику следует также рассмотреть отношения между интерфейсами в поисках возможных конфликтов.

ИСО/МЭК 15408-3 AGD_OPE.1.6C: В руководстве пользователя по эксплуатации для каждой пользовательской роли должно быть описание всех мер безопасности, предназначенных для выполнения целей безопасности для среды функционирования согласно описанию в ЗБ.

11.3.1.3.6 Шаг оценивания AGD_OPE.1-6

Оценщик должен исследовать руководство пользователя по эксплуатации, чтобы сделать заключение о том, что оно описывает для каждой пользовательской роли меры безопасности, предназначенных для выполнения целей безопасности для среды функционирования согласно описанию в ЗБ.

Оценщик анализирует цели безопасности для среды функционирования в ЗБ и делает заключение о том, что для каждой пользовательской роли в руководстве пользователя описаны соответствующие меры безопасности.

Следует, чтобы меры безопасности, описанные в руководстве пользователя, включали все меры, имеющие отношение к внешним процедурам, меры физической защиты, организационные меры, связанные с персоналом, а также меры обеспечения связности.

Следует отметить, что меры, имеющие значение для безопасной установки ОО, исследуются в рамках семейства "Подготовительные процедуры" (AGD_PRE).

ИСО/МЭК 15408-3 AGD_ОPE.1.7С: руководство пользователя по эксплуатации должно быть понятным и обоснованным.

11.3.1.3.7 Шаг оценивания AGD_OPE.1-7

Оценщик должен исследовать руководство пользователя по эксплуатации, чтобы сделать заключение о том, что оно является ясным.

Руководство считается неясным, если оно может быть неверно истолковано администратором или пользователем и использовано способом, небезопасным и потенциально вредным для ОО или для мер/средств безопасности ОО.

11.3.1.3.8 Шаг оценивания AGD_OPE.1-8

Оценщик должен исследовать руководство пользователя по эксплуатации, чтобы сделать заключение о том, что оно является обоснованным.

Руководство считается необоснованным, если его реализация требует такого использования ОО или среды его функционирования, которое не согласуется с ЗБ или слишком обременительно для поддержания безопасности.

11.4 Подготовительные процедуры (AGD_PRE)

11.4.1 Подвид деятельности по оценке (AGD_PRE.1)

11.4.1.1 Цели

Цель этого подвида деятельности состоит в том, чтобы сделать заключение о том, были ли процедуры и шаги, предпринятые для безопасной подготовки ОО к использованию, документированы и привели ли они к безопасной конфигурации ОО.

11.4.1.2 Исходные данные

Свидетельствами оценки для этого подвида деятельности являются:

a) ЗБ;

b) ОО, включая связанные с ним подготовительные процедуры;

c) описание процедур поставки, используемых разработчиком (если применимо).

11.4.1.3 Замечания по применению

Подготовительные процедуры относятся ко всем процедурам приемки и установки, необходимым для перевода ОО в безопасную конфигурацию согласно описанию в ЗБ.

11.4.1.4 Действие AGD_PRE.1.1Е

ИСО/МЭК 15408-3 AGD_PRE.1.1C: В подготовительных процедурах должны описываться все шаги, необходимые для безопасной приемки поставленного ОО в соответствии с процедурами поставки разработчика.

11.4.1.4.1 Шаг оценивания AGD_PRE.1-1

Оценщик должен исследовать представленные процедуры приемки, чтобы сделать заключение о том, что они описывают шаги, необходимые для безопасной приемки ОО в соответствии с процедурами поставки разработчика.

Если от процедур поставки разработчика не ожидается, что процедуры приемки будут применяться или могут быть применены, то этот шаг оценивания не применим и потому считается удовлетворенным.

В процедуры приемки следует включать как минимум то, что пользователь должен проверить, что все части ОО, как указано в ЗБ, были поставлены в правильной версии.

В процедурах приемки следует отразить подразумеваемые процедурами поставки разработчика шаги, которые должен предпринять пользователь для осуществления приемки поставленного ОО.

В процедурах приемки следует предоставить подробную информацию о следующем, если это применимо:

a) о проведенной проверке того, что ОО поставлен полностью и в оцененной комплектации;

b) об обнаружении модификации/подмены ОО при поставке.

ИСО/МЭК 15408-3 AGD_PRE.1.2C: В подготовительных процедурах должны описываться все необходимые шаги для безопасной установки ОО и безопасной подготовки среды функционирования в соответствии с целями безопасности для среды функционирования, описанными в ЗБ.

11.4.1.4.2 Шаг оценивания AGD_PRE. 1-2

Оценщик должен исследовать представленные процедуры установки, чтобы сделать заключение о том, что они описывают шаги, необходимые для безопасной установки ОО и безопасной подготовки среды функционирования в соответствии с целями безопасности в ЗБ.

Если не ожидается, что процессы установки будут применяться или могут быть применены для ОО и среды его функционирования (например, потому что ОО может уже быть поставлен в рабочем состоянии и нет никаких требований к среде функционирования), то этот шаг оценивания не применим и поэтому считается удовлетворенным.

В процедурах установки следует предоставить подробную информацию о следующем, если это применимо:

a) о минимальных системных требованиях для безопасной установки;

b) о требованиях для среды функционирования в соответствии с целями безопасности, представленными в ЗБ;

c) о шагах, которые должен выполнить пользователь, чтобы используемый ОО соответствовал его оцененной конфигурации. Такое описание должно включать - для каждого шага - понятную схему для решения по поводу следующего шага в зависимости от успеха, сбоя или проблем на текущем шаге;

d) об изменении характерных для установки характеристик безопасности сущностей, управляемых ФБО (например, параметров, настроек, паролей);

e) об обработке исключений и проблем.

11.4.1.5 Действие AGD_PRE.1.2E

11.4.1.5.1 Шаг оценивания AGD_PRE.1-3

Оценщик должен выполнить все пользовательские процедуры, необходимые для подготовки ОО, чтобы сделать заключение, могут ли ОО и среда его функционирования быть защищенным образом подготовлены с использованием только предоставленного руководства пользователя по подготовительным процедурам.

По подготовительным процедурам требуется, чтобы оценщик перевел ОО от состояния, в котором он находился на момент поставки, до состояния функционирования, включая приемку и установку ОО и осуществление выполнения ФТБ, совместимых с целями безопасности для ОО, определенными в ЗБ.

Оценщику можно следовать только процедурам разработчика и выполнять действия, которые ожидаются от заказчика (пользователя ОО) для приемки и установки ОО, используя только предоставленное ему руководство пользователя по подготовительным процедурам. Любые трудности, с которыми сталкивается оценщик во время осуществления этих действий, могут быть признаками неполного, неясного или необоснованного руководства.

Этот шаг оценивания может быть выполнен вместе с действиями по оценке семейства "Независимое тестирование" (ATE_IND).

Если известно, что ОО будет использоваться в качестве зависимого компонента для оценки составного ОО, то оценщику следует удостовериться, что базовый компонент составного ОО удовлетворяет требованиям к среде функционирования ОО.

12 Класс ALC: Поддержка жизненного цикла

12.1 Введение

Вид деятельности "Поддержка жизненного цикла" предназначен для определения достаточности процедур, применяемых разработчиком во время разработки и сопровождения ОО. Эти процедуры включают в себя модель жизненного цикла, применяемую разработчиком, управление конфигурацией, меры безопасности во время разработки ОО, инструментальные средства, используемые разработчиком на протяжении жизненного цикла ОО, обработка недостатков безопасности и деятельность по поставке ОО.

Плохое управление разработкой и сопровождением ОО могут привести к уязвимостям в реализации. Соответствие определенной модели жизненного цикла может помочь улучшить меры управления в этих областях. Используемая для ОО измеримая модель жизненного цикла может снизить неоднозначность при оценивании процесса разработки ОО.

Вид деятельности "Управление конфигурацией" предназначен для помощи потребителю в идентификации оцениваемого ОО, чтобы удостовериться, что элементы конфигурации уникально идентифицированы, а также что процедуры, которые используются разработчиком для выявления и управления изменениями ОО, являются достаточными и обоснованными. Сюда же относится и детальная информация о том, какие изменения отслеживаются, каким образом комбинируются потенциальные изменения, и до какой степени используется автоматизация для уменьшения диапазона ошибки.

Процедуры безопасности, применяемые разработчиком, предназначены для защиты ОО и связанной с ним проектной информации от вмешательства или раскрытия. Вмешательство в процесс разработки может позволить преднамеренно внести уязвимости в ОО. Раскрытие информации о проекте может облегчить использование уязвимостей. Адекватность рассматриваемых процедур будет зависеть от свойств ОО и процесса его разработки.

Использование полностью определенных инструментальных средств разработки помогает удостовериться в том, что уязвимости не были непреднамеренно внесены в процессе уточнения ФБО.

Деятельность по исправлению недостатков предназначена для того, чтобы выявить недостатки защиты, сделать заключение о необходимых корректирующих действиях и донести информацию о корректирующих действиях до пользователей.

Цель деятельности по поставке состоит в том, чтобы оценить достаточность документации процедур, используемых для обеспечения того, что ОО поставлен потребителю без внесения изменений.

12.2 Возможности УК (ALC_CMC)

12.2.1 Подвид деятельности по оценке (ALC_CMC.1)

12.2.1.1 Цели

Цель данного подвида деятельности - сделать заключение, четко ли разработчик идентифицировал ОО.

12.2.1.2 Исходные данные

Свидетельства оценки для этого подвида деятельности:

a) ЗБ;

b) ОО, пригодный для тестирования.

12.2.1.3 Действие ALC_CMC.1.1Е

ИСО/МЭК 15408-3 ALC_CMC1.1С: ОО должен быть помечен уникальной маркировкой.

12.2.1.3.1 Шаг оценивания ALC_CMC.1-1

Оценщик должен проверить, что ОО, представленный для оценки, имеет собственную маркировку.

Оценщику следует удостовериться, что ОО содержит уникальную маркировку, изложенную в ЗБ. Этого можно достичь, используя маркированную упаковку или носители, или же маркировку, отображаемую ОО при функционировании. Это предоставляет потребителю возможность идентификации ОО (например, при приобретении или использовании).

ОО может предоставить способ, посредством которого он может быть легко идентифицирован. Например, ОО, являющийся программным продуктом, может отображать свое название и номер версии при запуске программы или в ответ на запрос через командную строку. Аппаратный или программно-аппаратный ОО может быть идентифицирован путем нанесения на нем соответствующего номера штампом.

Возможен и альтернативный вариант, когда уникальная маркировка ОО представляет собой комбинацию уникальных маркировок каждого компонента, из которых состоит ОО (например, в случае составного ОО).

12.2.1.3.2 Шаг оценивания ALC_CMC.1-2

Оценщик должен проверить непротиворечивость используемой маркировки ОО.

Если ОО маркирован несколько раз, то необходима согласованность маркировок. Например, следует предусмотреть возможность связать любое маркированное руководство, поставляемое в составе ОО, с оцененным функционирующим ОО. Этим обеспечивается уверенность потребителя в том, что он приобрел оцененную версию ОО, установил эту же версию и располагает надлежащей редакцией руководства, необходимой для эксплуатации данного ОО в соответствии с его ЗБ.

Оценщик также верифицирует, что маркировка ОО согласуется с ЗБ.

Если этот шаг оценивания будет применяться к составному ОО, то применимо следующее. Составной ОО ИТ не будет маркирован уникальной (составной) маркировкой, только отдельные компоненты будут соответственно маркированы. Для этого требуется маркировать дальнейшую разработку ОО ИТ, например во время запуска и/или функционирования составной маркировкой. Если составной ОО будет поставляться как часть целого, состоящего из ОО-компонентов, то ОО-компоненты не будут маркированы составной маркировкой. Однако в ЗБ составного ОО будет включена уникальная маркировка составного ОО, а также будут идентифицированы компоненты, включенные в составной ОО, благодаря чему потребители будут в состоянии сделать заключение о том, имеются ли у них соответствующие компоненты.

12.2.2 Подвид деятельности по оценке (ALC_CMC.2)

12.2.2.1 Цели

Цели этого подвида деятельности состоят в том, чтобы сделать заключение о том, использует ли разработчик систему УК, которая уникально идентифицирует все элементы конфигурации.

12.2.2.2 Исходные данные

Свидетельства оценки для этого подвида деятельности:

a) ЗБ;

b) ОО, пригодный для тестирования;

c) документация по управлению конфигурацией.

12.2.2.3 Замечания по применению

Этот компонент содержит неявное действие оценщика, требуемое для того, чтобы сделать заключение, используется ли система УК. Поскольку требования здесь ограничены идентификацией ОО и предоставленным списком конфигурации, это действие уже охвачено и ограничено существующими шагами оценивания. При применении "Подвида деятельности по оценке" ALC_CMC.3 требования расширяются, и требуются более явные свидетельства функционирования системы УК помимо двух, указанных выше.

12.2.2.4 Действие ALC_CMC.2.1Е

ИСО/МЭК 15408-3 ALC_CMC.2.1С: ОО должен быть помечен уникальной маркировкой.

12.2.2.4.1 Шаг оценивания ALC_CMC.2-1

Оценщик должен проверить, что ОО, представленный для оценки, имеет собственную маркировку.

Оценщику следует удостовериться, что ОО содержит уникальную маркировку, изложенную в ЗБ. Этого можно достичь, используя маркированную упаковку или носители, или же маркировку, отображаемую ОО при функционировании. Это предоставляет потребителю возможность идентификации ОО (например, при приобретении или использовании).

ОО может предоставить способ, посредством которого он может быть легко идентифицирован. Например, ОО, являющийся программным продуктом, может отображать свое название и номер версии при запуске программы или в ответ на запрос через командную строку. Аппаратный или программно-аппаратный ОО может быть идентифицирован путем нанесения на нем соответствующего номера штампом.

Возможен и альтернативный вариант, когда уникальная маркировка ОО представляет собой комбинацию уникальных маркировок каждого компонента, из которых состоит ОО (например, в случае составного ОО).

12.2.2.4.2 Шаг оценивания ALC_CMC.2-2

Оценщик должен проверить непротиворечивость используемой маркировки ОО.

Если ОО маркирован несколько раз, то необходима согласованность меток. Например, следует предусмотреть возможность связать любое маркированное руководство, поставляемое в составе ОО, с оцененным функционирующим ОО. Этим обеспечивается уверенность потребителя в том, что он приобрел оцененную версию ОО, установил эту же версию и располагает надлежащей редакцией руководства, необходимой для эксплуатации данного ОО в соответствии с его ЗБ.

Оценщик также верифицирует, что маркировка ОО согласуется с ЗБ.

Если этот шаг оценивания будет применяться к составному ОО, то применимо следующее. Составной ОО ИТ не будет маркирован уникальной (составной) маркировкой; только отдельные компоненты будут соответственно маркированы. Для этого требуется маркировать дальнейшую разработку ОО ИТ, например во время запуска и/или функционирования, составной маркировкой. Если составной ОО будет поставляться как часть целого, состоящего из ОО-компонентов, то компоненты ОО не будут маркированы составной маркировкой. Однако в ЗБ составного ОО будет включена уникальная маркировка составного ОО, а также будут идентифицированы компоненты, входящие в составной ОО, благодаря чему потребители будут в состоянии сделать заключение о том, имеются ли у них соответствующие компоненты.

ИСО/МЭК 15408-3 ALC_CMC.2.2C: В документации УК должно содержаться описание метода, используемого для уникальной идентификации элементов конфигурации.

12.2.2.4.3 Шаг оценивания ALC_CMC.2-3

Оценщик должен исследовать метод идентификации элементов конфигурации, чтобы сделать заключение о том, что в нем описано, каким образом уникально идентифицирован каждый элемент конфигурации.

В процедурах следует описать, каким образом состояние каждого элемента конфигурации может быть прослежено на любом этапе жизненного цикла ОО. Процедуры такого прослеживания могут быть детально описаны в плане УК или по всей документации УК. В эту информацию следует включать описание:

a) метода уникальной идентификации элементов, такой, что есть возможность отследить версии конкретного элемента конфигурации;

b) метода назначения уникальных идентификаторов элементам конфигурации и метода их введения в систему УК;

c) метода, который будет использоваться для идентификации новых версий элементов конфигурации, замещающих старые.

ИСО/МЭК 15408-3 ALC_CMC.2.3C: В системе УК должны быть уникальным образом идентифицированы все элементы конфигурации.

12.2.2.4.4 Шаг оценивания ALC_CMC.2-4

Оценщик должен исследовать элементы конфигурации, чтобы сделать заключение о том, что они идентифицированы способом, который не противоречит документации УК.

Доверие тому, что система УК уникально идентифицирует все элементы конфигурации, приобретается путем исследования идентификаторов элементов конфигурации. И для элементов конфигурации, которые включены в ОО, и для проектов элементов конфигурации, которые предоставлены разработчиком как свидетельства оценки, оценщик подтверждает, что каждый элемент конфигурации обладает уникальным идентификатором, присвоенным ему способом, совместимым с методом уникальной идентификации, описанным в документации по УК.

12.2.3 Подвид деятельности по оценке (ALC_CMC.3)

12.2.3.1 Цели

Цели этого подвида деятельности состоят в том, чтобы сделать заключение о том, использует ли разработчик систему УК, которая уникально идентифицирует все элементы конфигурации, и правильно ли управляется способность изменять эти элементы.

12.2.3.2 Исходные данные

Свидетельства оценки для этого подвида деятельности:

a) ЗБ;

b) ОО, пригодный для тестирования;

c) документация по управлению конфигурацией.

12.2.3.3 Действие ALC_CMC.3.1 E

ИСО/МЭК 15408-3 ALC_CMC.3.1С: ОО должен быть помечен уникальной маркировкой.

12.2.3.3.1 Шаг оценивания ALC_CMC.3-1

Оценщик должен проверить, что ОО, представленный для оценки, имеет собственную маркировку.

Оценщику следует удостовериться, что ОО содержит уникальную маркировку, позволяющую отличать разные версии ОО. Этого можно достичь, используя маркированную упаковку или носители, или же маркировку, отображаемую ОО при функционировании. Это предоставляет потребителю возможность идентификации ОО (например, при приобретении или использовании).

ОО может предоставить способ, посредством которого он может быть легко идентифицирован. Например, ОО, являющийся программным продуктом, может отображать свое название и номер версии при запуске программы или в ответ на запрос через командную строку. Аппаратный или программно-аппаратный ОО может быть идентифицирован путем нанесения на нем соответствующего номера штампом.

Возможен и альтернативный вариант, когда уникальная маркировка ОО представляет собой комбинацию уникальных маркировок каждого компонента, из которых состоит ОО (например, в случае составного ОО).

12.2.3.3.2 Шаг оценивания ALC_CMC.3-2

Оценщик должен проверить непротиворечивость используемой маркировки ОО.

Если ОО маркирован несколько раз, то необходима согласованность меток. Например, следует предусмотреть возможность связать любое маркированное руководство, поставляемое в составе ОО, с оцененным функционирующим ОО. Этим обеспечивается уверенность потребителя в том, что он приобрел оцененную версию ОО, установил эту же версию и располагает надлежащей редакцией руководства, необходимой для эксплуатации данного ОО в соответствии с его ЗБ.

Оценщик также верифицирует, что маркировка ОО согласуется с ЗБ.

Если этот шаг оценивания будет применяться к составному ОО, то применимо следующее. Составной ОО ИТ не будет маркирован уникальной (составной) маркировкой; только отдельные компоненты будут соответственно маркированы. Для этого требуется маркировать дальнейшую разработку ОО ИТ, например во время запуска и/или функционирования, составной маркировкой. Если составной ОО будет поставляться как часть целого, состоящего из ОО-компонентов, то компоненты ОО не будут маркированы составной маркировкой. Однако в ЗБ составного ОО будет включена уникальная маркировка составного ОО, а также будут идентифицированы компоненты, включенные в составной ОО, благодаря чему потребители будут в состоянии сделать заключение о том, имеются ли у них соответствующие компоненты.

ИСО/МЭК 15408-3 ALC_CMC.3.2C: В документации УК должно содержаться описание метода, используемого для уникальной идентификации элементов конфигурации.

12.2.3.3.3 Шаг оценивания ALC_CMC.3-3

Оценщик должен исследовать метод идентификации элементов конфигурации, чтобы сделать заключение о том, что в нем описано, каким образом уникально идентифицирован каждый элемент конфигурации.

В процедурах следует описать, каким образом состояние каждого элемента конфигурации может быть прослежено на любом этапе жизненного цикла ОО. Процедуры такого прослеживания могут быть детально описаны в плане УК или по всей документации УК. В эту информацию следует включать описание:

a) метода уникальной идентификации элементов, такой, что есть возможность отследить версии конкретного элемента конфигурации;

b) метода назначения уникальных идентификаторов элементам конфигурации и метода их введения в систему УК;

c) метода, который будет использоваться для идентификации новых версий элементов конфигурации, замещающих старые.

ИСО/МЭК 15408-3 ALC_CMC.3.3C: В системе УК должны быть уникальным образом идентифицированы все элементы конфигурации.

12.2.3.3.4 Шаг оценивания ALC_CMC.3-4

Оценщик должен исследовать элементы конфигурации, чтобы сделать заключение о том, что они идентифицированы способом, который не противоречит документации УК.

Доверие тому, что система УК уникально идентифицирует все элементы конфигурации, приобретается путем исследования идентификаторов элементов конфигурации. И для элементов конфигурации, которые включены в ОО, и для проектов элементов конфигурации, которые предоставлены разработчиком как свидетельства оценки, оценщик подтверждает, что каждый элемент конфигурации обладает уникальным идентификатором, присвоенным ему способом, совместимым с методом уникальной идентификации, описанным в документации по УК.

ИСО/МЭК 15408-3 ALC_CMC.3.4C: В системе УК должны быть предусмотрены такие меры, при применении которых в элементы конфигурации могут быть внесены только санкционированные изменения.

12.2.3.3.5 Шаг оценивания ALC_CMC.3-5

Оценщик должен исследовать меры контроля доступа в УК, описанные в плане УК, чтобы сделать заключение об их эффективности по предотвращению несанкционированного доступа к элементам конфигурации.

Оценщик может использовать несколько методов для вынесения заключения об эффективности мер контроля доступа в УК. Например, оценщик может опробовать меры контроля доступа, чтобы удостовериться, что процедуры нельзя обойти. Оценщик может использовать выходные материалы, сгенерированные процедурами системы УК и уже подвергавшиеся исследованию на шаге оценивания ALC_CMC.3.8С. Оценщику может быть также продемонстрирована система УК, чтобы он убедился, что используемые меры контроля доступа выполняются эффективно.

ИСО/МЭК 15408-3 ALC_CMC.3.5C: Документация УК должна включать в себя план УК.

12.2.3.3.6 Шаг оценивания ALC_CMC.3-6

Оценщик должен проверить, что представленная документация УК содержит план УК.

План УК не обязательно должен быть единым, связанным документом, но рекомендуется, чтобы имелся некий документ с описанием того, где представлены различные части плана УК. На тот случай, если план УК не является единым документом, в следующем шаге оценивания приведен список, содержащий подсказки по поводу его содержания.

ИСО/МЭК 15408-3 ALC_CMC.3.6C: В плане УК должно быть описание того, каким образом система УК используется для разработки ОО.

12.2.3.3.7 Шаг оценивания ALC_CMC.3-7

Оценщик должен исследовать план УК в целях вынесения заключения о том, что в нем описывается, каким образом система УК используется для разработки ОО.

Описания, содержащиеся в плане УК, могут включать:

a) все операции, выполняемые в среде разработки ОО, которые подчинены процедурам управления конфигурацией (например, создание, модификация или удаление элемента конфигурации, создание резервной копии данных, архивация);

b) средства (например, инструменты УК, формы), которые должны быть доступны;

c) использование инструментов УК: необходимая детальная информация для пользователя системы УК, чтобы он мог правильно управлять инструментами УК в целях поддержания целостности ОО;

d) описание того, какие еще объекты (компоненты разработки, инструменты, среда оценки и т.д.) взяты под управление системы УК;

e) роли и обязанности должностных лиц, требуемые для выполнения операций над отдельными элементами конфигурации (для различных типов элементов конфигурации (например проектная документация или исходный код) могут быть идентифицированы различные пользовательские роли);

f) описание того, каким образом введены и укомплектованы организационно-штатные единицы системы УК (например, совет по управлению изменениями, рабочие группы контроля интерфейсов);

g) описание управления изменениями;

h) процедуры, которые используются для обеспечения того, чтобы только уполномоченные лица могли изменять элементы конфигурации;

i) процедуры, которые используются для исключения проблем параллелизма, возникающих в случае одновременного изменения элементов конфигурации;

j) свидетельство, которое генерируется в результате применения процедур. Например, при изменении элемента конфигурации система УК может зафиксировать описание изменения, ответственность за изменение, идентификацию всех затронутых элементов конфигурации, статус изменения (например, "не завершено" или "завершено"), а также дату и время внесения изменения. Эта информация может быть занесена в журнал аудита произведенных изменений или в протокол контроля изменений;

k) подход к контролю версий и уникальной маркировке версий ОО (охватывающий, например выпуск исправлений ("патчей") для операционных систем и последующее обнаружение их применения).

ИСО/МЭК 15408-3 ALC_CMC.3.7C: В свидетельствах должно быть продемонстрировано, что все элементы конфигурации сопровождаются системой УК

12.2.3.3.8 Шаг оценивания ALC_CMC.3-8

Оценщик должен проверить, что элементы конфигурации, идентифицированные в списке конфигурации, сопровождаются системой УК.

Следует, чтобы система УК, используемая разработчиком, поддерживала целостность ОО. Оценщику следует проверить, что для каждого типа элементов конфигурации (например, проектная документация или модули исходного кода), содержащихся в списке элементов конфигурации, есть примеры свидетельств, которые являются результатами производимых процедур, описанных в плане УК. В этом случае подход к осуществлению выборки будет зависеть от степени детализации, используемой в системе УК для управления элементами УК. Там, где, например, в списке элементов конфигурации идентифицировано 10000 модулей исходного кода, должна быть применена иная стратегия осуществления выборки по сравнению с тем случаем, где идентифицировано только пять таких модулей или вовсе один. Деятельность в рамках данного шага оценивания следует в первую очередь направить на оценку того, правильно ли функционирует система УК, а не на обнаружение любой незначительной ошибки.

Руководство по выборке см. в приложении А.2 "Выборка".

ИСО/МЭК 15408-3 ALC_CMC.3.8C: В свидетельствах должно быть продемонстрировано, что система УК функционирует в соответствии с планом УК

12.2.3.3.9 Шаг оценивания ALC_CMC.3-9

Оценщик должен проверить документацию УК, чтобы удостовериться, что она включает записи системы УК, определенные планом УК.

Следует, чтобы выходные материалы системы УК обеспечили свидетельство, необходимое оценщику для уверенности, что план УК применяется, а все элементы конфигурации поддерживаются системой УК, как это требуется в ALC_CMC.3.7C. Пример выходных материалов может включать формы контроля изменений или формы разрешения доступа к элементам конфигурации.

12.2.3.3.10 Шаг оценивания ALC_CMC.3-10

Оценщик должен исследовать свидетельство, чтобы сделать заключение, что система УК используется в соответствии с планом УК.

Оценщику следует осуществить и исследовать выборку из свидетельства, охватывающую каждый тип операций по УК, выполняемых над элементами конфигурации (например, создание, модификация, удаление, возврат к более ранней версии), чтобы подтвердить, что все операции системы УК выполнялись в соответствии с документированными процедурами. Оценщик подтверждает, что свидетельство включает всю информацию, идентифицированную для этой операции в плане УК. При исследовании свидетельства может потребоваться доступ к используемым инструментальным средствам УК. Оценщику разрешается остановиться на выборочной проверке свидетельства.

Руководство по выборке см. в приложении А.2 "Выборка".

Дополнительное доверие правильному функционированию системы УК и эффективному сопровождению элементов конфигурации может быть приобретено посредством проведения интервью с выбранными для этого участниками разработки. При проведении подобных интервью оценщику следует стремиться получить более глубокое понимание практического применения системы УК, а также удостовериться, что процедуры УК применяются в соответствии с документацией УК. Отметим, что такие интервью следует проводить скорее в дополнение, а не вместо исследования документального свидетельства; при этом они могут и не потребоваться, если документальное свидетельство само по себе удовлетворяет требованиям. Тем не менее, учитывая широкую область применения плана УК, возможно, что некоторые аспекты (например роли, и обязанности) могут быть непонятны из одного только плана и протоколов УК. Это один из случаев, когда для разъяснения понадобится интервью.

Предполагается, что для поддержки этих действий оценщик посетит объект разработки.

Руководство по посещению объектов см. в приложении А.4 "Посещение объектов".

12.2.4 Подвид деятельности по оценке (ALC_CMC.4)

12.2.4.1 Цели

Цели этого подвида деятельности состоят в том, чтобы сделать заключение, идентифицировал ли разработчик ОО и связанные с ним элементы конфигурации однозначно и четко, а также организовано ли управление возможностями изменения этих элементов правильно с использованием автоматизированных инструментов, позволяющих сделать систему УК менее восприимчивой к человеческим ошибкам и ошибкам, допущенным по небрежности.

12.2.4.2 Исходные данные

Свидетельства оценки для этого подвида деятельности:

a) ЗБ;

b) ОО, пригодный для тестирования;

c) документация по управлению конфигурацией.

12.2.4.3 Действие ALC_CMC.4.1Е

ИСО/МЭК 15408-3 ALC_CMC.4.1С: ОО должен быть помечен уникальной маркировкой.

12.2.4.3.1 Шаг оценивания ALC_CMC.4-1

Оценщик должен проверить, что ОО, представленный для оценки, имеет собственную маркировку.

Оценщику следует удостовериться, что ОО содержит уникальную маркировку, позволяющую отличать разные версии ОО. Этого можно достичь, используя маркированную упаковку или носители, или же маркировку, отображаемую ОО при функционировании. Это предоставляет потребителю возможность идентификации ОО (например, при приобретении или использовании).

ОО может предоставить способ, посредством которого он может быть легко идентифицирован. Например, ОО, являющийся программным продуктом, может отображать свое название и номер версии при запуске программы или в ответ на запрос через командную строку. Аппаратный или программно-аппаратный ОО может быть идентифицирован путем нанесения на нем соответствующего номера штампом.

Возможен и альтернативный вариант, когда уникальная маркировка ОО представляет собой комбинацию уникальных маркировок каждого компонента, из которых состоит ОО (например, в случае составного ОО).

12.2.4.3.2 Шаг оценивания ALC_CMC.4-2

Оценщик должен проверить непротиворечивость используемой маркировки ОО.

Если ОО маркирован несколько раз, то необходима согласованность меток. Например, следует предусмотреть возможность связать любое маркированное руководство, поставляемое в составе ОО, с оцененным функционирующим ОО. Этим обеспечивается уверенность потребителя в том, что он приобрел оцененную версию ОО, установил эту же версию и располагает надлежащей редакцией руководства, необходимой для эксплуатации данного ОО в соответствии с его ЗБ.

Оценщик также верифицирует, что маркировка ОО согласуется с ЗБ.

Если этот шаг оценивания будет применяться к составному ОО, то применимо следующее. Составной ОО ИТ не будет маркирован уникальной (составной) маркировкой, только отдельные компоненты будут соответственно маркированы. Для этого требуется маркировать дальнейшую разработку ОО ИТ, например во время запуска и/или функционирования составной маркировкой. Если составной ОО будет поставляться как часть целого, состоящего из ОО-компонентов, то компоненты ОО не будут маркированы составной маркировкой. Однако в ЗБ составного ОО будет включена уникальная маркировка составного ОО, а также будут идентифицированы компоненты, включенные в составной ОО, благодаря чему потребители будут в состоянии сделать заключение о том, имеются ли у них соответствующие компоненты.

ИСО/МЭК 15408-3 ALC_CMC.4.2C: В документации УК должно содержаться описание метода, используемого для уникальной идентификации элементов конфигурации.

12.2.4.3.3 Шаг оценивания ALC_CMC.4-3

Оценщик должен исследовать метод идентификации элементов конфигурации, чтобы сделать заключение о том, что в нем описано, каким образом уникально идентифицирован каждый элемент конфигурации.

В процедурах следует описать, каким образом состояние каждого элемента конфигурации может быть прослежено на любом этапе жизненного цикла ОО. Процедуры такого прослеживания могут быть детально описаны в плане УК или по всей документации УК. В эту информацию следует включать описание:

a) метода уникальной идентификации элементов, такой, что есть возможность отследить версии конкретного элемента конфигурации;

b) метода назначения уникальных идентификаторов элементам конфигурации и метода их введения в систему УК;

c) метода, который будет использоваться для идентификации новых версий элементов конфигурации, замещающих старые.

ИСО/МЭК 15408-3 ALC_CMC.4.3C: В системе УК должны быть уникальным образом идентифицированы все элементы конфигурации.

12.2.4.3.4 Шаг оценивания ALC_CMC.4-4

Оценщик должен исследовать элементы конфигурации, чтобы сделать заключение о том, что они идентифицированы способом, который не противоречит документации УК.

Доверие тому, что система УК уникально идентифицирует все элементы конфигурации, приобретается путем исследования идентификаторов для элементов конфигурации. И для элементов конфигурации, которые включены в ОО, и для проектов элементов конфигурации, которые предоставлены разработчиком как свидетельства оценки, оценщик подтверждает, что каждый элемент конфигурации обладает уникальным идентификатором, присвоенным ему способом, совместимым с методом уникальной идентификации, описанным в документации по УК.

ИСО/МЭК 15408-3 ALC_CMC.4.4C: В системе УК должны быть предусмотрены такие автоматизированные меры, при применении которых в элементы конфигурации могут быть внесены только санкционированные изменения.

12.2.4.3.5 Шаг оценивания ALC_CMC.4-5

Оценщик должен исследовать меры контроля доступа в УК, описанные в плане УК (см. ALC_CMC.4.6C), чтобы сделать заключение, что они автоматизированы и эффективны для предотвращения несанкционированного доступа к элементам конфигурации.

Оценщик может использовать несколько методов для вынесения заключения об эффективности мер контроля доступа в УК. Например, оценщик может опробовать меры контроля доступа, чтобы удостовериться, что процедуры нельзя обойти. Оценщик может использовать выходные материалы, сгенерированные процедурами системы УК, требуемые на шаге оценивания ALC_CMC.4-10С. Оценщику может быть также продемонстрирована система УК, чтобы он убедился, что используемые меры контроля доступа выполняются эффективно.

ИСО/МЭК 15408-3 ALC_CMC.4.5C: Система УК должна поддерживать производство ОО автоматизированными средствами.

12.2.4.3.6 Шаг оценивания ALC_CMC.4-6

Оценщик должен проверить план УК (см. ALC_CMC.4.6C) для оценки автоматизированных процедур, предназначенных для поддержки производства ОО.

Термин "производство" применяется по отношению к процессам, принятым разработчиком для перевода ОО от представления реализации до состояния, приемлемого для поставки конечному потребителю.

Оценщик проверяет существование автоматизированных процедур поддержки производства ОО в рамках плана УК.

Примеры автоматизированных средств поддержки производства ОО:

- инструмент "создать" (предусмотренный во многих средствах разработки программного обеспечения) для случая ОО, являющегося программным продуктом;

- инструмент, автоматически обеспечивающий (например, посредством штрих-кодов) комбинирование только тех частей, которые должны быть интегрированы для случая аппаратного ОО.

12.2.4.3.7 Шаг оценивания ALC_CMC.4-7

Оценщик должен исследовать процедуры, поддерживающие производство ОО, чтобы сделать заключение о том, что они эффективны для приобретения доверия, что сгенерированный ОО отражает представление его реализации.

В процедурах поддержки производства следует описать, какие инструменты должны использоваться для производства окончательной версии ОО из представления реализации полностью определенным способом. Соглашения, директивы и другие необходимые логические конструкции описаны в семействе ALC_TAT.

Оценщик делает заключение о том, что при выполнении процедур поддержки производства для производства ОО используются корректные элементы конфигурации. Например, в случае, когда ОО является программным обеспечением, это может включать проверку того, что автоматизированные производственные процедуры обеспечивают включение в компилированный объектный код всех исходных файлов и связанных с ними библиотек. Кроме того, процедурами следует обеспечить уникальное определение опций компилятора и других сопоставимых опций. Для аппаратных ОО в этот шаг оценивания может быть включена проверка того, что автоматизированные производственные процедуры предоставляют уверенность в том, что принадлежащие ОО части собраны вместе, и нет недостающих частей.

Клиент в этом случае может быть уверен, что версия ОО, поставленного для установки, получена из представления реализации однозначным способом и осуществляет ФТБ согласно описанию в ЗБ.

Оценщику следует учитывать, что система УК не должна обязательно обладать способностью производства ОО, но ей следует поддерживать этот процесс таким образом, который поможет уменьшить вероятность человеческой ошибки.

ИСО/МЭК 15408-3 ALC_CMC.4.6C: Документация УК должна включать в себя план УК.