9.3 Вид деятельности «Оценка задания по безопасности»

9.3.1 Оценка раздела «Описание ОО» (ASE_DES.1)

9.3.1.1 Цели

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

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

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

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

Между ОО и продуктом, который может приобрести потребитель, могут существовать некоторые отличия. Материалы по данному вопросу представлены в А.6 «Границы ОО» (приложение А).

9.3.1.4 Действие ASE_DES.1.1E

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

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

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

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

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

9.3.1.4.2 Шаг оценивания ASE_DES.1-2

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

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

Если ОО не тождествен продукту, то оценщик делает заключение, описано ли надлежащим образом в «Описании ОО» физическое соотношение между ОО и продуктом.

9 3.1.4.3 Шаг оценивания ASE_DES.1-3

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

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

Если ОО не тождествен продукту, то оценщик делает заключение, описано ли надлежащим образом в «Описании ОО» логическое соотношение между ОО и продуктом.

9.3.1.5 Действие ASE_DES. 1.2E

9.3.1.5.1 Шаг оценивания ASE_DES. 1-4

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

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

9.3.1.5.2 Шаг оценивания ASE_DES. 1-5

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

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

Руководство по анализу непротиворечивости см в А.3 «Анализ непротиворечивости» (приложение А).

9.3.1.6 Действие ASE_DES. 1.3E

9.3.1.6.1 Шаг оценивания ASE_DES. 1-6

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

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

Руководство по анализу непротиворечивости см. в A.3 «Анализ непротиворечивости» (приложение А).

9.3.2 Оценка раздела «Среда безопасности ОО» (ASE_ENV.1)

9.3.2.1 Цели

Цель данного подвида деятельности — сделать заключение, обеспечивает ли изложение раздела «Среда безопасности ОО» в ЗБ четкое и непротиворечивое определение проблемы безопасности, решение которой возложено на ОО и его среду.

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

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

9.3.2.3 Действие ASE_ENV.1.1E

9.3.2.3.1 Шаг оценивания ASE_ENV.1-1

ИСО/МЭК 15408-3 ASE_ENV.1. 1C: Изложение среды безопасности ОО должно идентифицировать и объяснить каждое предположение о предполагаемом применении ОО и среде использования ОО.

Оценщик должен исследовать изложение раздела «Среда безопасности ОО», чтобы сделать заключение, идентифицированы и разъяснены ли в нем какие-либо предположения.

Предположения могут быть разделены на предположения относительно использования ОО и предположения относительно среды использования ОО.

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

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

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

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

- предполагают, что консоли администраторов находятся в некоторой зоне, доступ в которую ограничен только персоналом, являющимся администраторами;

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

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

- предполагают, что пользователи имеют конкретные навыки или специальные знания;

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

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

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

- предполагают, что для хранения файлов регистрации, генерируемых ОО, доступным является, по крайней мере, 100 Мб внешнего дискового пространства;

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

- предполагают, что дисковод ОО для накопителей на гибком магнитном диске отключен;

- предполагают, что ОО не будет подключен к недоверенной сети.

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

9.3.2.3.2 Шаг оценивания ASE_ENV.1-2

ИСО/МЭК 15408-3 ASE_ENV. 1.2C: Изложение среды безопасности ОО должно идентифицировать и объяснить каждую известную или предполагаемую угрозу активам, от которой будет требоваться защита посредством ОО или его среды.

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

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

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

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

9.3.2.3.3 Шаг оценивания ASE_ENV.1-3

ИСО/МЭК 15408-3 ASE_ENV. 1.3C: Изложение среды безопасности ОО должно идентифицировать и объяснить каждую политику безопасности организации, соответствие которой для ОО необходимо.

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

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

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

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

9.3.2.4 Действие ASE_ENV.1.2E

9. 3. 2.4.1 Шаг оценивания ASE_ENV.1-4

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

Изложение раздела «Среда безопасности ОО» является логически упорядоченным, если его структура и содержание понятны целевой аудитории (т.е. оценщикам и потребителям).

9.3.2.4.2 Шаг оценивания ASE_ENV.1-5

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

Примерами внутренне противоречивого изложения раздела «Среда безопасности ОО» являются:

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

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

Руководство по анализу непротиворечивости см. в A.3 «Анализ непротиворечивости», (приложение А).

9.3.3 Оценка раздела «Введение ЗБ» (ASE_INT.1)

9.3.3.1 Цели

Цель данного подвида деятельности — сделать заключение, является ли раздел «Введение ЗБ» полным и согласованным со всеми другими частями ЗБ и правильно ли в нем идентифицировано ЗБ.

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

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

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

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

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

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

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

a) информацию, необходимую для контроля и уникальной идентификации ЗБ (например, наименование ЗБ, номер версии, дату публикации, авторов);

b) информацию, необходимую для контроля и уникальной идентификации ОО, на который данное ЗБ ссылается (например, идентификационную информацию ОО, номер версии ОО);

c) указание версии ИСО/МЭК 15408, использованной при разработке ЗБ;

d) дополнительную информацию в соответствии с требованиями системы оценки.

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

ИСО/МЭК 15408-3 ASE_INT.1.2C: Введение ЗБ должно содержать аннотацию ЗБ с общей характеристикой ЗБ в описательной форме.

Оценщик должен проверить, представлена ли в разделе «Введение ЗБ» «Аннотация ЗБ» в повествовательной форме.

«Аннотация ЗБ» предназначена для того, чтобы предоставить краткое резюме содержания ЗБ (более детальное описание приведено в разделе «Описание ОО»), которое является достаточно подробным, чтобы позволить потенциальному потребителю сделать заключение, представляет ли для него интерес данный ОО (а значит, и все остальные части ЗБ).

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

ИСО/МЭК 15408-3 ASE_INT.1.3C: Введение ЗБ должно содержать утверждение о соответствии ИСО/МЭК 15408, излагающее все оцениваемые утверждения о соответствии ОО ИСО/МЭК 15408.

Оценщик должен проверить, содержит ли «Введение ЗБ» подраздел «Утверждение о соответствии ИСО/МЭК 15408», в котором изложено утверждение о соответствии ОО ИСО/МЭК 15408.

Оценщик делает заключение, соответствует ли «Утверждение о соответствии ИСО/МЭК 15408» подразделу 6.4 ИСО/МЭК 15408-1.

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

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

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

Если утверждается о соответствии именованному пакету, оценщик делает заключение, сформулировано ли в подразделе «Утверждение о соответствии ИСО/МЭК 15408», какой пакет заявлен.

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

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

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

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

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

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

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

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

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

Анализ внутренней непротиворечивости, естественно, опирается на краткий обзор ЗБ, представляющий собой резюме содержания ЗБ.

Руководство по анализу непротиворечивости см. в А.3 «Анализ непротиворечивости» (приложение А).

9.3.3.5 Действие ASE_INT.1.3E

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

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

Оценщик делает заключение, предоставляет ли «Аннотация ЗБ» точную общую характеристику ОО. В частности, оценщик делает заключение, согласована ли «Аннотация ЗБ» с разделом «Описание ОО» и не предполагается ли в нем наличие характеристик безопасности, которые выходят за рамки оценки.

Оценщик также делает заключение, согласовано ли «Утверждение о соответствии ИСО/МЭК 15408» с другими частями ЗБ.

Руководство по анализу непротиворечивости см. в А.3 «Анализ непротиворечивости» (приложение А).

9.3.4 Оценка целей безопасности (ASE_OBJ.1)

9.3.4.1 Цели

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

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

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

9.3.4.3 Действие ASE_OBJ.1E

9.3.4.3.1 Шаг оценивания ASE_OBJ.1-1

ИСО/МЭК 15408-3 ASE_OBJ.1.1C: Изложение целей безопасности должно определить цели безопасности для ОО и его среды.

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

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

9.3.4.3.2 Шаг оценивания ASE_OBJ.1-2

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

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

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

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

9.3.4.3.3 Шаг оценивания ASE_OBJ.1-3

ИСО/МЭК 15408-3 ASE_OBJ.1.3C: Цепи безопасности для среды должны быть сопоставлены с теми аспектами идентифицированных угроз, которым ОО противостоит не полностью, и/или с политикой безопасности организации или предположениями, не полностью выполняемыми ОО.

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

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

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

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

9.3.4.3.4 Шаг оценивания ASE_OBJ.1-4

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

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

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

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

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

Примеры устранения угрозы:

- устранение для источника угрозы (нарушителя) возможности использовать какой-либо метод нападения;

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

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

Примеры снижения угрозы:

- ограничение для источника угрозы возможности использования методов нападения;

- ограничение возможностей источников угрозы;

- снижение вероятности успешного результата инициированного нападения;

- повышенные требования к компетентности и ресурсам источника угрозы.

Примеры компенсации последствий реализации угрозы:

- частое создание резервных копий активов;

- наличие резервных копий ОО;

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

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

9.3.4.3.5 Шаг оценивания ASE_OBJ.1-5

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

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

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

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

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

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

9.3.4.3.6 Шаг оценивания ASE_OBJ.1-6

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

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

Предположение является или предположением относительно предполагаемого использования ОО, или предположением относительно среды использования ОО.

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

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

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

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

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

9.3.4.4 Действие ASE_OBJ.2E

9.3.4.4.1 Шаг оценивания ASE_OBJ.1-7

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

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

9.3.4.4.2 Шаг оценивания ASE_OBJ.1-8

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

Изложение раздела «Цели безопасности» является полным, если цели безопасности достаточны для противостояния всем идентифицированным угрозам и покрывают все идентифицированные политики безопасности организации и предположения. Данный шаг оценивания может быть выполнен совместно с шагами оценивания ASE_OBJ.1-4, ASE_OBJ.1-5 и ASE_OBJ.1-6.

9 3.4.4.3 Шаг оценивания ASE_OBJ.1-9

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

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

Руководство по анализу непротиворечивости см. в А.3 «Анализ непротиворечивости» (приложение А).

9.3.5 Оценка раздела «Утверждение о соответствии ПЗ» (ASE_PPC.1)

9.3.5.1 Цели

Цель данного подвида деятельности — сделать заключение, является ли ЗБ корректным отображением любою ПЗ, соответствие которому заявлено в ЗБ.

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

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

a) ЗБ;

b) профиль (профили) защиты, о соответствии которому (которым) заявлено в ЗБ.

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

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

9.3.5.4 Действие ASE_PPC.1.1E

9.3.5.4.1 Шаг оценивания ASE_PPC.1-1

ИСО/МЭК 15408-3 ASE_PPC.1.1C: Каждое утверждение о соответствии ПЗ должно идентифицировать ПЗ, соответствие которому утверждается, включая необходимые уточнения, связанные с этим утверждением.

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

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

9 3.5.4.2 Шаг оценивания ASE_PPC.1-2

ИСО/МЭК 15408-3 ASE_PPC.1.2C: Каждое утверждение о соответствии ПЗ должно идентифицировать формулировки требований безопасности ИТ, в которых завершены разрешенные операции или иначе выполнено дальнейшее уточнение требований ПЗ.

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

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

9.3.5.4.3 Шаг оценивания ASE_PPC.1-3

ИСО/МЭК 15408-3 ASE_PPC.1.3C: Каждое утверждение о соответствии ПЗ должно идентифицировать формулировки содержащихся в ЗБ целей безопасности и требований безопасности ИТ, которые дополняют имеющиеся в ПЗ.

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

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

9.3.5.5 Действие ASE_PPC.1.2E

9.3.5.5.1 Шаг оценивания ASE_PPC.1-4

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

Данный шаг оценивания охватывает не только незавершенные операции «назначение» и «выбор» в ПЗ, но также и любое применение операции «уточнение» по отношению к требованиям безопасности, взятым из ПЗ.

9.3.6 Оценка раздела «Требования безопасности ИТ» (ASE_REQ.1)

9.3.6.1 Цели

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

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

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

9.3.6.3 Действие ASE_REQ.1.1E

9.3.6.3.1 Шаг оценивания ASE_REQ.1-1

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

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

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

9.3.6.3.2 Шаг оценивания ASE_REQ.1-2

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

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

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

9.3.6.3.3 Шаг оценивания ASE_REQ.1-3

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

Оценщик делает заключение, правильно ли воспроизведены требования в подразделе «Функциональные требования безопасности ОО»; при этом исследование разрешенных операций не проводится. Исследование правильности операций над компонентами осуществляется при выполнении шагов оценивания ASE_REQ.1-11 и ASE_REQ.1-12.

9.3.6.3.4 Шаг оценивания ASE_REQ.1-4

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

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

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

9.3.6.3.5 Шаг оценивания ASE_REQ.1-5

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

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

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

9.3.6.3.6 Шаг оценивания ASE_REQ.1-6

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

Оценщик делает заключение, правильно ли воспроизведены требования в подразделе «Требования доверия к безопасности ОО»; при этом исследование выполнения разрешенных операций не проводится. Исследование правильности операций над компонентами осуществляется при выполнении шагов оценивания ASE_REQ.1-11 и ASE_REQ.1-12.

9.3.6.3.7 Шаг оценивания ASE_REQ.1-7

ИСО/МЭК 15408-3 ASE_REQ.1.3C: В изложение требований доверия к ОО следует включить оценочный уровень доверия (ОУД), как определено в ИСО/МЭК 15408-3.

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

Если никакой из ОУД не включен, то оценщик делает заключение, указана ли в логическом обосновании причина невключения ОУД в подраздел «Требования доверия к безопасности ОО». Это логическое обоснование может указывать либо на причину невозможности, нежелательности или нецелесообразности включения ОУД. либо на причину невозможности, нежелательности или нецелесообразности включения конкретных компонентов семейств, составляющих ОУД1 (АСМ_САР «Возможности УК», ADO_IGS «Установка, генерация и запуск», ADV_FSP «Функциональная спецификация», ADV_RCR «Соответствие представлений», AGD_ADM «Руководство администратора», AGD_USR «Руководство пользователя» и ATE_IND «Независимое тестирование»).

9.3.6.3.8 Шаг оценивания ASE_REQ.1-8

ИСО/МЭК 15408-3 ASE_REQ.1.4C: Свидетельство должно содержать логическое обоснование, что изложение требований доверия к ОО является соответствующим.

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

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

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

Логическое обоснование может также включать в себя основания, подобные следующим:

a) требования доверия, включенные в ПЗ, соответствие которым заявлено в ЗБ;

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

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

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

e) требования потребителей.

Краткий обзор назначения и целей для каждого ОУД приведен в ИСО/МЭК 15408-3 (подраздел 10.2).

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

Если подраздел «Требования доверия к безопасности ОО» не содержит какой-либо ОУД, то данный шаг оценивания может быть выполнен совместно с шагом оценивания ASE.REQ.1-7.

9.3.6.3.9 Шаг оценивания ASE_REQ.1-9

ИСО/МЭК 15408-3 ASE_REQ.1.5C: ЗБ должно, при необходимости, идентифицировать каждое требование безопасности для среды ИТ.

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

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

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

Пример требований безопасности для среды ИТ — межсетевой экран полагается на базовую операционную систему в части обеспечения аутентификации администраторов и долговременного хранения данных аудита. В этом случае требования безопасности для среды ИТ обычно содержат компоненты из классов FAU «Аудит безопасности» и FIA «Идентификация и аутентификация».

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

Пример зависимости от среды ИТ — программный криптомодуль, который периодически проверяет свой код и, в случае обнаружения несанкционированной модификации, самоотключается. Для обеспечения возможности восстановления предусмотрено требование FPT_RCV.2 «Автоматическое восстановление». Поскольку криптомодуль не может самостоятельно восстановить свой код после самоотключения, то требование по восстановлению становится требованием к среде ИТ. Одной из зависимостей компонента FPT_RCV.2 «Автоматическое восстановление» является компонент AGD_ADM.1 «Руководство администратора». Следовательно, это требование доверия становится требованием доверия для среды ИТ.

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

9.3.6.3.10 Шаг оценивания ASE_REQ.1-10

ИСО/МЭК 15408-3 ASE_REQ.1.6C: Операции, предусмотренные в требованиях безопасности ИТ, включенных в ЗБ,. должны быть идентифицированы и выполнены.

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

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

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

9.3.6.3.11 Шаг оценивания ASE_REQ.1-11

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

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

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

9.3.6.3.12 Шаг оценивания ASE_REQ.1-12

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

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

a) для операции «назначение» — выбраны ли значения параметров или переменных в соответствии с указанным типом, требуемым операцией «назначение»;

b) для операции «выбор» — принадлежит ли выбранный пункт или пункты множеству пунктов, указанных во фрагменте «выбор» данного элемента. Оценщик также делает заключение, приемлемо ли число выбранных пунктов для данного требования. Для некоторых требований необходим выбор только одного пункта (например, FAU_GEN.1.1.b), в других случаях приемлем выбор нескольких пунктов (например, вторая операция в FDP_ITT.1.1);

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

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

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

Пример редакционного уточнения — FAU_ARP.1 с единственным действием. Вместо записи: «ФБО должны предпринять информировать оператора при обнаружении возможного нарушения безопасности» допускается, чтобы разработчик ЗБ написал: «ФБО должны информировать оператора при обнаружении возможного нарушения безопасности».

Оценщику необходимо иметь в виду, что редакционные уточнения должны быть четко идентифицированы (см. шаг оценивания ASE_REQ.1-10);

d) для операции «итерация» — отличается ли каждая итерация компонента от каждой другой итерации этого компонента (по крайней мере, один элемент одной итерации компонента должен отличаться от соответствующего элемента другой итерации компонента), или что компонент применяется к разным частям ОО.

9.3.6.3.13 Шаг оценивания ASE_REQ.1-13

ИСО/МЭК 15408-3 ASE_REQ.1.7C: Зависимости между требованиями безопасности ИТ, включенными в ЗБ, следует удовлетворить.

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

Зависимости могут быть удовлетворены включением соответствующего компонента (или компонента, иерархичного по отношению к последнему) в подраздел «Требования безопасности для ОО» или в подраздел «Требования безопасности для среды ИТ».

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

Зависимости требований безопасности для среды ИТ следует излагать и удовлетворять в ЗБ.

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

9.3.6.3.14 Шаг оценивания ASE_REQ.1-14

ИСО/МЭК 15408-3 ASE_REQ.1.8C: Свидетельство должно содержать логическое обоснование каждого неудовлетворения зависимостей.

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

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

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

Пример приемлемого логического обоснования —Для программного ОО имеется цель безопасности следующего содержания: «Случаи неуспешной аутентификации должны быть зарегистрированы с указанием идентификационной информации о пользователе, времени и дате», и для удовлетворения данной цели безопасности используется функциональное требование на основе компонента FAU_GEN.1 «Генерация данных аудита». Компонент FAU_GEN.1 содержит зависимость от компонента FPT_STM.1 «Надежные метки времени». Так как ОО не имеет встроенных часов, то FPT_STM.1 определяется разработчиком ЗБ как требование безопасности для среды ИТ. Разработчик ЗБ указывает на то, что данное требование не подлежит удовлетворению, приводя следующее логическое обоснование: «В данной конкретной среде существуют возможности проведения атак на механизм меток времени; таким образом, среда может не обеспечить надежные метки времени. Но имеющиеся источники угроз не способны к проведению атак на механизмы меток времени, а другие атаки со стороны этих источников угроз могут быть подвергнуты анализу с регистрацией времени и даты осуществления».

9.3.6.3.15 Шаг оценивания ASE_REQ.1-15

ИСО/МЭК 15408-3 ASE_REQ.1.9C: ЗБ должно включать в себя изложение приемлемого минимального уровня стойкости функций безопасности (СФБ) для функциональных требований безопасности ОО: базовой, средней или высокой СФБ.

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

Если требования доверия к безопасности ОО не включают в себя компонент AVA_SOF.1 «Оценка стойкости функции безопасности ОО», то данный шаг оценивания не применяют и поэтому считают удовлетворенным.

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

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

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

9.3.6.3.16 Шаг оценивания ASE_REQ.1-16

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

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

Если подраздел «Требования доверия к безопасности ОО» не содержит компонент AVA_SOF.1 «Оценка стойкости функции безопасности ОО», то данный шаг оценивания не применяют и поэтому считают удовлетворенным.

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

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

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

9.3.6.3.17 Шаг оценивания ASE_REQ.1-17

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

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

Если в подраздел «Требования доверия к безопасности ОО» не включен компонент AVA_SOF.1, то данный шаг оценивания не применяют и поэтому считают удовлетворенным.

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

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

9.3.6.3.18 Шаг оценивания ASE_REQ.1-18

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

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

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

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

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

Пример прослеживания требования доверия к безопасности ОО к цели безопасности для ОО — ЗБ, содержащее угрозу: «Пользователь непреднамеренно раскрывает информацию, используя изделие, которое он принимает за ОО» и цель безопасности для ОО для противостояния данной угрозе: «ОО должен быть четко помечен соответствующим номером версии». Изложенная цель безопасности для ОО может быть достигнута путем выполнения требований компонента ACM_CAP.1 «Номера версий», и поэтому разработчик ЗБ прослеживает данный компонент к рассматриваемой цели безопасности для ОО.

9.3.6.3.19 Шаг оценивания ASE_REQ.1-19

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

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

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

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

9.3.6.3.20 Шаг оценивания ASE_REQ.1-20

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

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

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

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

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

9.3.6.3.21 Шаг оценивания ASE_REQ.1-21

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

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

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

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

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

9.3.6.3.22 Шаг оценивания ASE_REQ.1-22

ИСО/МЭК 15408-3 ASE_REQ.1.13C: Обоснование требований безопасности должно демонстрировать, что совокупность требований безопасности ИТ образует взаимно согласованное и внутренне непротиворечивое целое.

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

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

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

Руководство по анализу непротиворечивости см. в A.3 «Анализ непротиворечивости» (приложение А).

9.3.6.3.23 Шаг оценивания ASE_REQ.1-23

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

Данный шаг оценивания основан на заключениях, сделанных в ходе выполнения шагов оценивания ASE_REQ.1-18 и ASE_REQ.1-19, связанных с исследованием прослеживания от требований безопасности ИТ к целям безопасности, и шагов оценивания ASE_REQ.1-20 и ASE_REQ.1-21, связанных с исследованием пригодности требований безопасности ИТ для удовлетворения целей безопасности. Данный шаг оценивания требует от оценщика рассмотреть возможность фактического недостижения какой-либо цели безопасности из-за недостаточной поддержки со стороны других требований безопасности ИТ.

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

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

a) на предотвращение обхода механизмов, реализующих другие функциональные требования безопасности, такие, например, как FPT_RVM.1 «Невозможность обхода ПБО»;

b) на предотвращение вмешательства в работу механизмов, реализующих другие функциональные требования безопасности, такие, например, как FPT_SEP  «Разделение домена»;

c) на предотвращение деактивации механизмов, реализующих другие функциональные требования безопасности, такие, например, как FMT_MOF.1 «Управление режимом выполнения функций безопасности»;

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

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

9.3.6.4 Действие ASE_REQ.1.2E

9.3.6.4.1 Шаг оценивания ASE_REQ.1-24

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

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

9.3.6.4.2 Шаг оценивания ASE_REQ.1-25

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

При выполнении данного шага оценивания используют результаты шагов оценивания, выполняемых в соответствии с требованиями ASE_REQ.1.1Е и ASE_SRE.1.1Е, и в особенности — результаты исследования оценщиком подраздела «Обоснование требований безопасности».

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

9.3.6.4.3 Шаг оценивания ASE_REQ.1-26

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

При выполнении данного шага оценивания используют результаты шагов оценивания, выполняемых в соответствии с требованиями ASE_REQ.1.1Е и ASE_SRE.1.1Е, и в особенности — результаты исследования оценщиком подраздела «Обоснование требований безопасности».

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

Руководство по анализу непротиворечивости см. в A.3 «Анализ непротиворечивости» (приложение А).

9.3.7 Оценка требований безопасности ИТ, сформулированных в явном виде (ASE_SRE.1)

9.3.7.1 Цели

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

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

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

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

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

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

9.3.7.4 Действие ASE_SRE.1.1E

9.3.7.4.1 Шаг оценивания ASE_SRE.1-1

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

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

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

9.3.7.4.2 Шаг оценивания ASE_SRE.1-2

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

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

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

9.3.7.4.3 Шаг оценивания ASE_SRE.1-3

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

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

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

9.3.7.4.4 Шаг оценивания ASE_SRE.1-4

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

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

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

9.3.7.4.5 Шаг оценивания ASE_SRE.1-5

ИСО/МЭК 15408-3 ASE_SRE.1.5C: Сформулированные в явном виде требования безопасности ИТ должны быть измеримы и устанавливать объективные требования оценки, такие, чтобы соответствие или несоответствие им ОО могло быть определено и последовательно продемонстрировано.

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

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

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

9.3.7.4.6 Шаг оценивания ASE_SRE.1-6

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

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

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

9.3.7.4.7 Шаг оценивания ASE_SRE.1-7

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

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

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

9.3.7.5 Действие ASE_SRE.1.2E

9.3.7.5.1 Шаг оценивания ASE_SRE.1-8

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

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

Примеры возможных зависимостей, компоненты класса FAU «Аудит безопасности», если в сформулированном в явном виде функциональном требовании упоминается аудит, компоненты семейства ADV_IMP «Представление реализации», если в сформулированном в явном виде требовании доверия упоминается исходный код или представление реализации ОО.

9.3.8 Оценка раздела «Краткая спецификация ОО» (ASE_TSS.1)

9.3.8.1 Цели

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

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

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

9.3.8.3 Действие ASE_TSS.1.1E

9.3.8.3.1 Шаг оценивания ASE_TSS.1-1

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

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

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

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

9.3.8.3.2 Шаг оценивания ASE_TSS.1-2

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

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

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

9.3.8.3.3 Шаг оценивания ASE_TSS.1-3

ИСО/МЭК 15408-3 ASE_TSS.1.3C: Функции безопасности ИТ должны быть определены в неформальном стиле на уровне детализации, необходимом для понимания их назначения.

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

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

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

9.3.8.3.4 Шаг оценивания ASE_TSS.1-4

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

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

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

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

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

9.3.8.3.5 Шаг оценивания ASE_TSS.1-5

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

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

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

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

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

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

9.3.8.3.6 Шаг оценивания ASE_TSS.1-6

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

Для выполнения данного шага оценивания следует использовать результаты шага оценивания ASE_TSS.1-10.

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

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

9.3.8.3.7 Шаг оценивания ASE_TSS.1-7

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

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

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

9.3.8.3.8 Шаг оценивания ASE_TSS.1-8

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

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

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

9.3.8.3.9 Шаг оценивания ASE_TSS.1-9

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

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

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

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

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

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

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

9.3.8.3.10 Шаг оценивания ASE_TSS.1-10

ИСО/МЭК 15408-3 ASE_TSS.1.9C: Краткая спецификация ОО должна идентифицировать все функции безопасности ИТ, которые реализованы вероятностным или перестановочным механизмом соответственно.

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

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

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

9.3.8.3.11 Шаг оценивания ASE_TSS.1-11

ИСО/МЭК 15408-3 ASE_TSS.1.10C: Краткая спецификация ОО должна установить для каждой функции безопасности ИТ, для которой это необходимо, требование стойкости функции либо по специальной метрике, либо как базовую, среднюю или высокую СФБ.

Оценщик должен проверить, что для каждой функции безопасности ИТ, для которой это приемлемо, в разделе «Краткая спецификация ОО» установлено требование стойкости функции либо по специальной метрике, либо как базовая, средняя или высокая СФБ.

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

9. 3. 8.4 Действие ASE_TSS.1.2E

9.3.8.4.1 Шаг оценивания ASE_TSS.1-12

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

Раздел «Краткая спецификация ОО» является полным, если оценщик сделает вывод, что функции безопасности ИТ и меры доверия достаточны для удовлетворения всех специфицированных требований безопасности ОО. Данный шаг оценивания следует выполнять вместе с шагами оценивания ASE_TSS.1-5 и ASE_TSS.1-9.

9.3.8.4.2 Шаг оценивания ASE_TSS.1-13

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

Раздел «Краткая спецификация ОО» является логически упорядоченным, если его структура и содержание понятны целевой аудитории (т.е. оценщикам и разработчикам).

9.3.8.4.3 Шаг оценивания ASE_TSS.1-14

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

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

Руководство по анализу непротиворечивости см. в А.3 «Анализ непротиворечивости» (приложение А).

Далее >>>