8.3 Вид деятельности «Оценка профиля защиты»
8.3.1 Оценка раздела «Описание ОО» (APE_DES.1)
8 3.1.1 Цели
Цель данного подвида деятельности — сделать заключение, содержит
ли «Описание ОО» соответствующую для понимания назначения ОО и его функциональных возможностей информацию, а также является ли описание ОО полным и непротиворечивым.
8.3.1.2 Исходные данные
Свидетельством оценки для этого подвида деятельности является ПЗ.
8.3.1.3 Действие APE_DES.1.1E
8.3.1.3.1 Шаг оценивания APE_DES.1-1
ИСО/МЭК 15408-3 APE_DES.1.1C: Описание ОО должно
включать в себя тип продукта и общие свойства ИТ,
присущие ОО.
Оценщик должен исследовать раздел «Описание ОО», чтобы сделать заключение, описан пи в нем тип продукта или системы для ОО.
Оценщик делает заключение, достаточно ли «Описание ОО» для общего понимания
предполагаемого использования продукта или системы и обеспечивает
ли, таким образом, контекст оценки. Примерами некоторых типов продуктов и систем являются: межсетевой экран, смарт-карта, криптомодем, веб-сервер,
интрасеть.
Существуют ситуации, когда является очевидным, что у ОО ожидается наличие некоторых функциональных возможностей, определяемых типом продукта или системы. Если эти функциональные возможности отсутствуют, то оценщик делает заключение, адекватно ли это отсутствие рассмотрено в разделе «Описание ОО». Примером этого является ОО типа «межсетевой экран», в «Описании ОО» которого изложено, что он не может быть подключен к сетям.
8.3.1.3.2 Шаг оценивания APE_DES.1-2
Оценщик должен исследовать раздел «Описание ОО», чтобы сделать заключение, описаны ли в нем в общих чертах ИТ-характеристики ОО.
Оценщик делает заключение, рассмотрены
ли в разделе «Описание ОО» ИТ-характеристики и в особенности характеристики безопасности, предоставляемые ОО, на таком уровне детализации, который достаточен для общего понимания этих характеристик.
8.3.1.4 Действие APE_DES.1.2E
8.3.1.4.1 Шаг оценивания APE_DES.1-3
Оценщик должен исследовать ПЗ, чтобы сделать заключение, является
ли «Описание ОО» логически упорядоченным.
Изложение раздела «Описание ОО» является логически упорядоченным, если его структура и содержание понятны целевой аудитории (т.е. разработчикам, оценщикам и потребителям).
8.3.1.4.2 Шаг оценивания APE_DES.1-4
Оценщик должен исследовать ПЗ, чтобы сделать заключение, является
ли «Описание ОО» внутренне непротиворечивым.
Оценщику необходимо иметь в виду, что данный раздел ПЗ предназначен только для того, чтобы определить общее назначение ОО.
Руководство по анализу непротиворечивости см.
в А.3 «Анализ непротиворечивости» (приложение А).
8.3.1.5 Действие APE_DES.1.3E
8.3.1.5.1 Шаг оценивания APE_DES.1-5
Оценщик должен исследовать ПЗ, чтобы сделать заключение, согласовано
ли «Описание ОО» с другими частями ПЗ.
Оценщик делает заключение, в частности, что в разделе «Описание ОО» не описаны угрозы, характеристики безопасности или конфигурации ОО, которые не рассмотрены в каком-либо другом месте ПЗ.
Руководство по анализу непротиворечивости см. в
A.3 «Анализ непротиворечивости» (приложение А).
8.3.2 Оценка раздела «Среда безопасности ОО»
(APE_ENV.1)
8.3.2.1 Цели
Цель данного подвида деятельности — сделать
заключение, обеспечивает ли изложение раздела «Среда безопасности ОО» в ПЗ четкое и непротиворечивое определение проблемы безопасности, решение которой возложено на ОО и его среду.
8.3.2.2 Исходные данные
Свидетельством оценки для этого подвида деятельности является ПЗ.
8.3.2.3 Действие APE_ENV.1E
8.3.2.3.1 Шаг оценивания APE_ENV.1-1
ИСО/МЭК 15408-3 APE_ENV.1.1C: Изложение среды безопасности ОО должно идентифицировать и объяснить каждое предположение о предполагаемом применении ОО и среде использования ОО.
Оценщик должен исследовать изложение раздела «Среда безопасности ОО», чтобы сделать заключение, идентифицированы и разъяснены ли в нем какие-либо предположения.
Предположения могут быть разделены на предположения относительно использования ОО и предположения относительно среды использования ОО.
Оценщик делает заключение, учитывают ли предположения относительно
использования ОО такие аспекты, как предполагаемое применение ОО, потенциальная ценность активов, требующих защиты со стороны ОО, и возможные ограничения использования ОО.
Оценщик делает заключение, достаточно ли подробно разъяснено каждое предположение относительно использования ОО для того, чтобы дать возможность потребителям решить, соответствует ли предполагаемое использование ими ОО сделанным предположениям. Если предположения не являются четкими и понятными, то это может, в конечном счете, привести к тому, что потребители будут использовать ОО в среде, для которой он не предназначен.
Оценщик делает заключение, охватывают
ли предположения относительно среды использования
ОО аспекты физической среды, персонала и внешних связей:
a) Физические аспекты включают в себя предположения, которые необходимо сделать относительно
физического расположения ОО или подключенных периферийных устройств для того, чтобы ОО функционировал безопасным образом. Несколько примеров:
- предполагают, что консоли администраторов находятся в некоторой зоне, доступ в которую ограничен только персоналом, являющимся администраторами;
- предполагают, что хранение всех файлов для ОО осуществляется на той рабочей станции, на
которой функционирует ОО.
b) Аспекты, имеющие отношение к персоналу,
включают в себя предположения, которые необходимо
сделать относительно пользователей и администраторов ОО или других лиц (включая потенциальные источники угроз) внутри среды ОО для того, чтобы ОО функционировал безопасным образом. Несколько
примеров:
- предполагают, что пользователи имеют конкретные навыки или специальные знания;
- предполагают. что пользователи имеют определенный минимальный допуск;
- предполагают, что администраторы обновляют антивирусную базу данных ежемесячно.
c) Аспекты внешних связей включают в себя предположения, которые необходимо
сделать относительно связей между ОО и другими внешними по отношению к ОО системами
или продуктами ИТ (аппаратными, программными и программно-аппаратными средствами или их комбинацией) для того, чтобы ОО
функционировал безопасным образом. Несколько примеров:
- предполагают, что для хранения файлов регистрации, генерируемых ОО, доступным является, по крайней мере, 100 Мб внешнего дискового пространства;
- предполагают, что ОО является единственным приложением, не относящимся к операционной системе, выполняемым на отдельной рабочей станции;
- предполагают, что дисковод ОО для накопителей на гибком магнитном диске отключен;
- предполагают, что ОО не будет подключен к недоверенной сети.
Оценщик делает заключение, достаточно ли подробно разъяснено каждое предположение относительно среды использования ОО для того, чтобы предоставить возможность потребителям решить, соответствует ли их предполагаемая среда сделанным предположениям о среде ОО. Если предположения не являются четкими и понятными, то это может, в конечном счете, привести к тому, что ОО будет использован в среде, в которой он не будет функционировать безопасным образом.
8.3.2.3.2 Шаг оценивания APE_ENV.1-2
ИСО/МЭК 15408-3 APE_ENV.1.2C: Изложение среды безопасности ОО
должно идентифицировать и объяснить каждую известную или предполагаемую угрозу активам, от которой будет требоваться защита посредством ОО или его среды.
Оценщик должен исследовать изложение раздела «Среда безопасности ОО», чтобы сделать заключение, идентифицированы и разъяснены
ли в нем какие-либо угрозы.
Если цели безопасности для ОО и его среды получены только на основе предположений и политики безопасности организации, то изложение угроз в ПЗ не потребуется. В таком случае данный шаг оценивания не применяют и поэтому считают удовлетворенным.
Оценщик делает заключение, все ли идентифицированные угрозы ясно разъяснены в терминах идентифицированного источника угрозы, нападения и актива, являющегося объектом нападения.
Оценщик также делает заключение, охарактеризованы ли источники угроз (нарушители) через их компетентность, ресурсы и мотивацию, а нападения - через методы нападения, какие-либо используемые уязвимости и возможность нападения.
8.3.2.3.3 Шаг оценивания APE_ENV.1-3
ИСО/МЭК 15408-3 APE_ENV.1.ЗC: Изложение среды безопасности ОО должно идентифицировать и объяснить каждую
политику безопасности организации, соответствие которой для ОО необходимо.
Оценщик должен исследовать изложение раздела «Среда безопасности ОО», чтобы сделать заключение, идентифицированы и разъяснены ли в нем какие-либо политики безопасности организации.
Если цели безопасности для ОО и его среды получены только на основе предположений и угроз, то нет необходимости в том, чтобы политика безопасности организации была представлена в ПЗ. В таком случае данный шаг оценивания не применяют и поэтому считают удовлетворенным.
Оценщик делает заключение, изложена ли политика безопасности организации в виде правил, практических приемов или руководств, установленных организацией, контролирующей среду использования ОО, которым должен следовать ОО или его среда. Примером политики безопасности организации является требование генерации и шифрования паролей в соответствии с национальным стандартом.
Оценщик делает заключение, достаточно ли подробно разъяснена и/или интерпретирована каждая политика безопасности организации для того, чтобы она была ясной для понимания; ясное представление формулировок политик является необходимым для того, чтобы дать возможность проследить
цели безопасности по отношению к ним.
8.3.2.4 Действие APE_ENV.1.2E
8.3.2.4.1 Шаг оценивания APE_ENV.1-4
Оценщик должен исследовать изложение раздела «Среда безопасности ОО», чтобы сделать заключение, является ли оно логически упорядоченным.
Изложение раздела «Среда безопасности ОО» является логически упорядоченным, если его структура и содержание понятны целевой аудитории (т.е. оценщикам и потребителям).
8.3.2.4.2 Шаг оценивания APE_ENV.1-5
Оценщик должен исследовать изложение раздела «Среда безопасности ОО», чтобы сделать заключение, является ли оно внутренне непротиворечивым.
Примерами внутренне противоречивого изложения раздела «Среда безопасности ОО» являются:
a) изложение раздела «Среда безопасности ОО», которое содержит угрозу, метод нападения для которой не может быть реализован источником угрозы;
b) изложение раздела «Среда безопасности ОО», которое содержит правило политики безопасности организации «ОО не должен быть подключен к Интернету» и угрозу, источником которой является злоумышленник из Интернета.
Руководство по анализу непротиворечивости см.
в А.3 «Анализ непротиворечивости» (приложение А).
8.3.3 Оценка раздела «Введение ПЗ» (APE_INT.1)
8.3.3.1 Цели
Цель данного подвида деятельности - сделать заключение, является ли раздел «Введение ПЗ» полным и согласованным со всеми другими частями ПЗ и правильно ли в нем идентифицирован ПЗ.
8.3.3.2 Исходные данные
Свидетельством оценки для этого подвида деятельности является ПЗ.
8.3.3.3 Действие APE_INT.1.1E
8.3.3.3.1 Шаг оценивания APE_INT.1-1
ИСО/МЭК 15408-3 APE_INT.1.1C: Введение ПЗ должно содержать данные идентификации ПЗ, которые предоставляют маркировку и описательную информацию, необходимые для идентификации, каталогизации, регистрации ПЗ и ссылок на него.
Оценщик должен проверить, представлена ли в разделе «Введение ПЗ» идентификационная информация, необходимая для идентификации, каталогизации, регистрации и перекрестной ссылки на ПЗ.
Оценщик делает заключение, включает ли в
себя идентификационная информация ПЗ:
a) информацию, необходимую для контроля и уникальной идентификации ПЗ (например, наименование ПЗ, номер версии, дату публикации, авторов, организацию-заявителя);
b) указание версии ИСО/МЭК 15408, использованной при разработке ПЗ;
c) регистрационную информацию, если перед оценкой ПЗ был зарегистрирован;
d) перекрестные ссылки, если ПЗ сопоставляется с другим (другими) ПЗ;
e) дополнительную информацию в соответствии с требованиями системы оценки.
8.3.3.3.2 Шаг оценивания APE_INT.1-2
ИСО/МЭК 15408-3 APE_INT.1.2C: Введение ПЗ должно содержать аннотацию ПЗ с общей характеристикой ПЗ
в описательной форме.
Оценщик должен проверить, представлена ли в разделе «Введение ПЗ» «Аннотация ПЗ» в повествовательной форме.
«Аннотация ПЗ» предназначена для того, чтобы предоставить краткое резюме содержания ПЗ (более детальное описание приведено в разделе «Описание ОО»), которое является достаточно подробным, чтобы позволить потенциальному пользователю ПЗ сделать заключение, представляет ли для него интерес данный ПЗ.
8.3.3.4 Действие APE_INT.1.2E
8.3.3.4.1 Шаг оценивания APE_INT.1-3
Оценщик должен исследовать «Введение ПЗ», чтобы сделать заключение, является ли оно логически упорядоченным.
«Введение ПЗ» является логически упорядоченным, если его структура и содержание понятны целевой аудитории
(т.е. разработчикам, оценщикам и потребителям).
8.3.3.4.2 Шаг оценивания APE_INT.1-4
Оценщик должен исследовать «Введение ПЗ», чтобы сделать заключение, является ли оно внутренне непротиворечивым.
Анализ внутренней непротиворечивости, естественно, опирается на краткий обзор ПЗ, представляющий собой резюме содержания ПЗ.
Руководство по анализу непротиворечивости см. в
A.3 «Анализ непротиворечивости» (приложение А).
8.3.3.5 Действие APE_INT.1 .ЗE
8.3.3.5.1 Шаг оценивания APE_INT.1-5
Оценщик должен исследовать ПЗ, чтобы сделать заключение, согласовано пи «Введение ПЗ» с другими частями ПЗ.
Оценщик делает заключение, предоставляет ли «Аннотация ПЗ» точную общую характеристику ОО. В частности,
оценщик делает заключение, согласована ли «Аннотация ПЗ» с разделом «Описание ОО» и не предполагается пи в нем наличие характеристик безопасности, которые выходят за рамки оценки.
Оценщик также делает заключение, согласовано ли «Утверждение о соответствии ИСО/МЭК 15408» с другими частями ПЗ.
Руководство по анализу непротиворечивости см.
в А.3 «Анализ непротиворечивости» (приложение А).
8.3.4 Оценка раздела «Цели безопасности»
(APE_OBJ.1)
8.3.4.1 Цели
Цель данного подвида деятельности — сделать заключение, полностью ли и согласованно описаны цели безопасности, направлены ли цели безопасности на противостояние идентифицированным угрозам,
на достижение идентифицированной политики безопасности организации и согласованы ли они с приведенными предположениями.
8.3.4.2 Исходные данные
Свидетельством оценки для этого подвида деятельности является ПЗ.
8.3.4.3 Действие APE_OBJ.1.1E
8.3.4.3.1 Шаг оценивания APE_OBJ.1-1
ИСО/МЭК 15408-3 APE_OBJ.1.1 C: Изложение целей безопасности должно определить цели безопасности для ОО и его среды.
Оценщик должен проверить, определены ли в изложении целей безопасности цели безопасности для ОО и его среды.
Оценщик делает заключение, ясно ли определено для каждой цели безопасности, относится она к ОО, к среде или к тому и другому.
8.3.4.3.2 Шаг оценивания APE_OBJ.1-2
ИСО/МЭК 15408-3 APE_OBJ.1.1.2C: Цели безопасности для ОО должны быть сопоставлены с теми аспектами идентифицированных угроз, которым будет противостоять ОО, и/или с
политикой безопасности организации, которая будет выполняться ОО.
Оценщик должен исследовать «Обоснование целей безопасности», чтобы сделать заключение, все ли цели безопасности для ОО прослежены к аспектам идентифицированных угроз, которым необходимо противостоять, и/или к аспектам политики безопасности организации, которой должен следовать ОО.
Оценщик делает заключение, прослежена ли каждая цель безопасности для ОО, по крайней мере, к одной угрозе или политике безопасности организации.
Неудача при попытке такого прослеживания свидетельствует о том, что либо обоснование целей безопасности является неполным, либо изложение угроз/политики безопасности организации является неполным, либо цель безопасности для ОО является бесполезной.
Поэтому угрозе полностью может соответствовать одна или более цель для среды. Крайний случай
- это когда отсутствуют цели безопасности для ОО. Хотя и в этом случае использование конструкции ПЗ/ЗБ остается правомерным, определение ОО, для которого все угрозы и политики безопасности организации учитываются средой, вряд ли бы имело какой-то практический смысл, так как для такого ОО не было бы никаких функциональных требований безопасности. Решение о сертификации подобных ОО является прерогативой системы оценки.
8.3.4.3.3 Шаг оценивания APE_OBJ.1-3
ИСО/МЭК 15408-3 APE_OBJ.1.3C: Цели безопасности для среды должны быть сопоставлены с теми аспектами идентифицированных угроз, которым ОО противостоит не полностью, и/или с
политикой безопасности организации или предположениями, не полностью выполняемыми ОО.
Оценщик должен исследовать «Обоснование целей безопасности», чтобы сделать заключение, прослежены ли цели безопасности для среды к тем идентифицированным угрозам, которым должна противостоять среда ОО, и/или к аспектам политики безопасности организации, которым должна удовлетворять среда ОО, и/или к предположениям, которым должна удовлетворять среда ОО.
Оценщик делает заключение, прослежена ли каждая цель безопасности для среды, по крайней мере, к одному предположению, угрозе или политике безопасности организации.
Неудача при попытке такого прослеживания свидетельствует о том, что либо обоснование целей безопасности является неполным, либо изложение
предположений/угроз/политики безопасности организации является неполным, либо цель безопасности для среды является бесполезной.
8.3.4.3.4 Шаг оценивания APE_OBJ.1-4
ИСО/МЭК 15408-3 APE_OBJ.1.4C: Обоснование целей безопасности должно демонстрировать, что изложенные цели безопасности пригодны для противостояния всем идентифицированным угрозам безопасности.
Оценщик должен исследовать «Обоснование целей безопасности», чтобы сделать заключение, содержится ли в нем для каждой угрозы приемлемое логическое обоснование того, что цели безопасности пригодны для противостояния данной угрозе.
Если ни одна цель безопасности не прослежена к конкретной угрозе, то результат данного шага оценивания отрицательный.
Оценщик делает заключение, демонстрирует ли логическое обоснование для угрозы то, что, если все цели безопасности, прослеживаемые к угрозе, достигнуты, то угроза либо устранена, либо снижена до приемлемого уровня, либо последствия ее реализации в достаточной мере компенсированы.
Оценщик такие делает заключение, действительно ли каждая цель безопасности, которая прослежена к угрозе, будучи достигнутой, вносит вклад в устранение, снижение или компенсацию последствий реализации данной угрозы.
Примеры устранения угрозы:
- устранение для источника угрозы (нарушителя) возможности использовать какой-либо метод нападения;
- устранение мотивации источника угрозы (нарушителя) путем применения сдерживающих факторов;
- устранение источника угрозы (например, отключение от сети машин, часто приводящих к фатальному сбою этой сети).
Примеры снижения угрозы:
- ограничение для источника угрозы возможности использования методов нападения;
- ограничение возможностей источников угрозы;
- снижение вероятности успешного результата инициированного нападения;
- повышенные требования к компетентности и ресурсам источника угрозы.
Примеры компенсации последствий реализации угрозы:
- частое создание резервных копий активов;
- наличие резервных копий ОО;
- частая смена ключей, используемых в течение сеанса связи, чтобы последствия компрометации одного ключа были относительно незначительными.
Несмотря на то, что прослеживание целей безопасности к угрозам в обосновании целей безопасности может быть частью логического обоснования, само по себе оно не является логическим обоснованием. Даже в том случае, когда цель безопасности является только заявлением, отражающим намерение предотвратить реализацию конкретной угрозы, все равно требуется логическое обоснование, хотя в данном случае оно может быть минимальным.
8.3.4.3.5 Шаг оценивания APE_OBJ..1-5
ИСО/МЭК 15408-3 APE_OBJ.1.5C: Обоснование целей безопасности должно демонстрировать, что изложенные цели безопасности пригодны для охвата всех установленных положений политики безопасности организации и предположений.
Оценщик должен исследовать «Обоснование целой безопасности», чтобы
сделать заключение, содержится ли в нем для каждого аспекта политики безопасности организации приемлемое логическое обоснование того, что цели безопасности покрывают данный аспект политики безопасности организации.
Если ни одна цель безопасности не прослежена к политике безопасности организации,
то результат данного шага оценивания отрицательный.
Оценщик делает заключение, демонстрирует ли логическое обоснование для политики безопасности организации то, что, если все цели безопасности, прослеженные к политике безопасности организации, достигнуты, то политика безопасности организации реализована.
Оценщик также делает заключение, действительно ли каждая цель безопасности, которая прослежена к политике безопасности организации, будучи достигнутой, вносит вклад
в реализацию политики безопасности организации.
Несмотря на то, что прослеживание целей безопасности к политике безопасности организации в обосновании
целей безопасности может быть частью логического обоснования, само по себе оно не является логическим обоснованием. Даже в том случае, когда цель безопасности является только заявлением, отражающим намерение реализовать конкретную политику безопасности, все равно требуется логическое обоснование, хотя в данном случав оно может быть минимальным.
8.3.4.3.6 Шаг оценивания APE_OBJ.1-6
Оценщик должен исследовать «Обоснование целой безопасности», чтобы сделать заключение, содержится ли в
нем для каждого предположения приемлемое логическое обоснование того, что цели безопасности для среды пригодны для покрытия данного предположения.
Если ни одна цель безопасности для среды не прослежена к приведенному предположению, то результат данного шага оценивания отрицательный.
Предположение является или предположением относительно предполагаемого использования ОО, или предположением относительно среды использования
ОО.
Оценщик делает заключение, демонстрирует ли логическое обоснование для предположения относительно предполагаемого использования ОО то, что, если все цели безопасности для среды, прослеженные к данному предположению, достигнуты, предполагаемое использование ОО поддерживается.
Оценщик также делает заключение, действительно ли каждая
цель безопасности для среды, прослеживаемая к некоторому предположению относительно предполагаемого использования ОО, будучи достигнутой, вносит вклад в поддержку предполагаемого использования.
Оценщик делает заключение, демонстрирует ли
логическое обоснование для
предположения относительно среды использования ОО то, что, если все цели безопасности для среды,
прослеженные к данному предположению, достигнуты, среда согласуется с данным предположением.
Оценщик также делает заключение, действительно ли каждая цель безопасности для среды, которая прослежена к предположению
относительно среды использования ОО, будучи достигнутой, вносит вклад в достижение согласованности среды с
предположением.
Несмотря на то, что прослеживание целей безопасности для среды к предположениям относительно среды использования ОО в
подразделе «Обоснование целей безопасности» может быть частью логического обоснования, само по себе оно не является логическим обоснованием. Даже в том случае, когда цель безопасности представляет собой перефразированное предположение, все равно требуется логическое обоснование,
хотя в данном случае оно может быть минимальным.
8.3.4.4 Действие APE_OBJ.1 2E
8.3.4.4.1 Шаг оценивания APE_OBJ.1-7
Оценщик должен исследовать изложение раздела «Цели безопасности», чтобы сделать заключение, является ли оно логически упорядоченным.
Изложение раздела «Цели безопасности» является логически упорядоченным, если его структура и содержание понятны целевой аудитории (т.е. оценщикам и потребителям).
8.3.4.4.2 Шаг оценивания APE_OBJ.1-8
Оценщик должен исследовать изложение раздела «Цели безопасности», чтобы сделать
заключение, является ли оно полным.
Изложение раздела «Цели безопасности» является полным, если цели безопасности достаточны для противостояния всем идентифицированным угрозам и покрывают все идентифицированные политики безопасности организации и предположения. Данный шаг оценивания может быть выполнен совместно с шагами оценивания
APE_OBJ.1-4, APE_OBJ.1-5 и APE_OBJ.1-6.
8.3.4.4.3 Шаг оценивания APE_OBJ.1-9
Оценщик должен исследовать изложение раздела «Цели безопасности», чтобы сделать заключение, является ли оно внутренне непротиворечивым.
Изложение раздела «Цели безопасности» является внутренне непротиворечивым, если цели безопасности не противоречат друг другу. Примером противоречия могут служить следующие две цели безопасности «Идентификатор пользователя но подлежит раскрытию» и «Идентификатор пользователя должен быть доступен другим пользователям».
Руководство по анализу непротиворечивости см. в
A.3 «Анализ непротиворечивости» (приложение А).
8.3.5 Оценка раздела «Требования безопасности ИТ»
(APE_REQ.1)
8.3.5.1 Цели
Цель данного подвида деятельности — сделать заключение, является ли описание требований безопасности ОО (как функциональных требований безопасности
ОО, так и требований доверия к безопасности ОО) и требований безопасности для среды ИТ полным и непротиворечивым и обеспечивают ли данные требования безопасности адекватную основу для разработки ОО, который бы достигал своих целей безопасности.
8.3.5.2 Исходные данные
Свидетельством оценки для этого подвида деятельности является
ПЗ.
8.3.5.3 Действие APE_REQ.1.1E
8.3.5.3.1 Шаг оценивания APE_REQ.1-1
ИСО/МЭК 15408-3 APE_REQ.1.1C: Изложение функциональных требований безопасности ОО должно идентифицировать функциональные требования безопасности ОО, составленные из компонентов функциональных требовании ИСО/МЭК 15408-2.
Оценщик должен проверить изложение функциональных требований безопасности ОО, чтобы сделать заключение, идентифицированы ли в нем функциональные требования безопасности ОО, составленные из компонентов функциональных требовании по ИСО/МЭК 15408-2.
Оценщик делает заключение, что все компоненты функциональных требований безопасности ОО, взятые из ИСО/МЭК
15408-2, идентифицированы либо путем ссыпки на отдельные компоненты по ИСО/МЭК
15408-2, либо путем воспроизведения их в ПЗ.
8.3.5.3.2 Шаг оценивания APE_REQ.1-2
Оценщик должен проверить, что каждая ссылка на компонент функциональных требований безопасности ОО является правильной.
Для каждой ссылки на компонент функционального требования безопасности ОО по ИСО/МЭК 15408-2 оценщик делает заключение, существует ли упомянутый компонент в ИСО/МЭК 15408-2.
8.3.5.3.3 Шаг оценивания APE_REQ.1-3
Оценщик должен проверить, что каждый компонент функциональных требований безопасности ОО, взятый из ИСО/МЭК 15408-2 и воспроизведенный в ПЗ, воспроизведен правильно.
Оценщик делает заключение, правильно ли воспроизведены требования в подразделе «Функциональные требования безопасности ОО», при этом исследование разрешенных операций не проводится. Исследование правильности операций над компонентами осуществляется при выполнении шага оценивания
APE_REQ.1-11.
8.3.5.3.4 Шаг оценивания APE_REQ.1-4
ИСО/МЭК 15408-3 APE_REQ.1.2C: Изложение требований доверия к ОО должно идентифицировать требования доверия к ОО, составленные из компонентов требований доверия ИСО/МЭК 15408-3.
Оценщик должен проверить изложение подраздела «Требования доверия к безопасности ОО», чтобы сделать заключение, идентифицированы ли
в нем требования доверия к безопасности ОО, составленные из компонентов требований доверия ИСО/МЭК 15408-3.
Оценщик делает заключение, все ли компоненты требований доверия к безопасности ОО, взятые из ИСО/МЭК
15408-3, идентифицированы либо путем ссылки на некоторый
ОУД, либо на отдельные компоненты из ИСО/МЭК
15408-3, либо путем их воспроизведения в ПЗ.
8.3.5.3.5 Шаг оценивания APE_REQ.1-5
Оценщик должен проверить, что каждая ссылка на компоненты требований доверия к безопасности ОО является правильной.
Для каждой ссылки на компонент требований доверия к безопасности ОО по ИСО/МЭК 15408-3 оценщик делает заключение, существует ли упомянутый компонент в ИСО/МЭК 15408-3.
8.3.5.3.6 Шаг оценивания APE_REQ.1-6
Оценщик должен проверить, что каждый компонент требований доверия к безопасности ОО, взятый из ИСО/МЭК 15408-3 и воспроизведенный в ПЗ, воспроизведен правильно.
Оценщик делает заключение, правильно ли воспроизведены требования в подразделе «Требования доверия к безопасности ОО»; при этом исследование выполнения разрешенных операций не проводится. Исследование правильности операций над компонентами осуществляется при
выполнении шага оценивания APE_REQ.1-11.
8.3.5.3.7 Шаг оценивания APE_REQ.1-7
ИСО/МЭК 15408-3 APE_REQ.1.ЗC: В изложение требований доверия к ОО следует включить оценочный уровень доверия
(ОУД). как определено в ИСО/МЭК 15408-3.
Оценщик должен исследовать изложение подраздела «Требования доверия к безопасности ОО», чтобы сделать заключение, содержит ли оно ОУД, определенный в ИСО/МЭК
15408-3, либо в нем логически обосновано отсутствие ОУД.
Если никакой из ОУД не включен, то оценщик делает заключение, указана ли в логическом обосновании причина невключения ОУД в подраздел «Требования доверия к безопасности ОО». Это
логическое обоснование может указывать либо
на причину невозможности, нежелательности или нецелесообразности включения ОУД в ПЗ, либо на причину невозможности, нежелательности или нецелесообразности включения конкретных компонентов семейств, составляющих ОУД1 (ACM_CAP «Возможности УК»,
ADO_IGS «Установка, генерация и запуск»,
ADV_FSP «Функциональная спецификация», ADV_RCR «Соответствие
представлений», AGD_ADM «Руководство администратора»,
AGD_USR «Руководство пользователя» и ATE_IND «Независимое тестирование»).
8.3.5.3.8 Шаг оценивания APE_REQ.1-8
ИСО/МЭК 15408-3 APE_REQ.1.4C: Свидетельство должно содержать логическое обоснование, что изложение требований доверия к ОО является соответствующим.
Оценщик должен исследовать «Обоснование требований безопасности», чтобы сделать заключение, достаточно ли логично в нем обосновано то, что изложение требований доверия к безопасности ОО является приемлемым.
Если требования доверия содержат какой-либо ОУД, то в логическом обосновании допустимо рассматривать выбор конкретного ОУД в целом, а не каждого отдельного компонента данного ОУД. Если подраздел «Требования доверия к безопасности ОО» содержит компоненты, усиливающие выбранный ОУД,
оценщик делает заключение, дано ли логическое обоснование каждого такого усиления. Если подраздел «Требования доверия к безопасности ОО» содержит требования доверия, сформулированные в явном виде, оценщик делает заключение, приведено
ли логическое обоснование использования каждого сформулированного в явном виде требования доверия.
Оценщик делает заключение, дано ли в подразделе «Обоснование требований безопасности» достаточно логичное обоснование, что требования доверия достаточны для изложенной среды безопасности и целей безопасности. Например, если требуется защита от хорошо осведомленных нарушителей, то было бы неприемлемым специфицировать компонент
AVA_VLA.1 «Анализ уязвимостей разработчиком», который является несвойственным для обнаружения недостатков безопасности, не являющихся очевидными.
Логическое обоснование может также включать в себя основания, подобные следующим:
a) специфические требования, установленные конкретной системой оценки, национальным правительством или другими организациями;
b) требования доверия, которые содержались в зависимостях функциональных требований безопасности ОО;
c) требования доверия систем и/или продуктов, предназначенных для совместного использования с
ОО;
d) требования потребителей.
Краткий обзор назначения и целей для каждого ОУД приведен в ИСО/МЭК 15403-3,
подраздел 10.2.
Оценщику необходимо иметь в виду, что заключение о том, являются ли требования доверия приемлемыми, может быть субъективным, а значит, анализ достаточности логического обоснования не следует проводить слишком строго.
Если подраздел «Требования доверия к безопасности ОО» не содержит какой-либо ОУД, то данный шаг оценивания может быть выполнен совместно с шагом оценивания
APE_REQ.1-7.
8.3.5.3.9 Шаг оценивания APE_REQ.1-9
ИСО/МЭК 15408-3 APE_REQ.1.5C: ПЗ должен, при необходимости, идентифицировать каждое требование безопасности для среды ИТ.
Оценщик должен проверить, что в ПЗ, при необходимости, идентифицированы требования безопасности для среды ИТ.
Если ПЗ не содержит требований безопасности для среды ИТ, то данный шаг оценивания не применяют и поэтому считают удовлетворенным.
Оценщик делает заключение, все ли зависимости ОО от других ИТ в рамках его среды, направленные на обеспечение каких-либо функциональных возможностей безопасности, чтобы достичь целей безопасности для ОО, четко идентифицированы в ПЗ как требования безопасности для среды ИТ.
Пример требований безопасности для среды ИТ — межсетевой экран
полагается на базовую операционную систему в части обеспечения аутентификации администраторов и долговременного хранения данных аудита. В этом случае требования безопасности для среды ИТ обычно содержат компоненты из классов
FAU «Аудит безопасности» и FIA «Идентификация и аутентификация».
Необходимо отметить, что «Требования безопасности для среды ИТ» могут содержать как функциональные требования, так и требования доверия.
Пример зависимости от среды ИТ — программный
криптомодуль, который периодически проверяет свой код и, в случае обнаружения несанкционированной модификации, самоотключается. Для обеспечения возможности восстановления предусмотрено требование
FPT_RCV.2 «Автоматическое восстановление». Поскольку криптомодуль не может самостоятельно восстановить свой код после самоотключения, то требование по восстановлению становится требованием к среде ИТ. Одной из зависимостей компонента
FPT_RCV.2 «Автоматическое восстановление» является компонент
AGD_ADM.1 «Руководство администратора». Следовательно, это требование доверия становится требованием доверия для среды ИТ.
Оценщику необходимо иметь в виду, что ссылка требований безопасности для среды ИТ на
ФБО относится к функциям безопасности среды, а не к функциям безопасности ОО.
8.3.5.3.10 Шаг оценивания APE_REQ.1-10
ИСО/МЭК 15408-3 APE_REQ.1.6C: Все завершенные операции над требованиями безопасности ИТ включенными в ПЗ, должны быть идентифицированы.
Оценщик должен проверить, что все завершенные операции над требованиями безопасности ИТ идентифицированы.
Допустимо, чтобы ПЗ содержал элементы с незавершенными операциями, т.е. ПЗ может содержать формулировки функциональных требований безопасности, которые включают в себя незавершенные операции «назначение» или «выбор». Данные операции должны быть впоследствии завершены в ЗБ. отображающем этот ПЗ, что позволяет разработчику ЗБ проявлять большую гибкость при разработке ОО и соответствующего ЗБ, в котором утверждается о соответствии конкретному ПЗ.
Разрешенными операциями для компонентов по ИСО/МЭК 15408-2 и ИСО/МЭК 15408-3 являются «назначение», «итерация», «выбор» и «уточнение». Операции «назначение» и «выбор» разрешены только в специально обозначенных местах компонента. Операции «итерация» и «уточнение» разрешены для всех компонентов.
Оценщик делает заключение, все ли операции идентифицированы в каждом компоненте, где они используются. Необходимо, чтобы завершенные и незавершенные операции были идентифицированы таким образом, чтобы они могли быть различимы и было ясно, завершена ли конкретная операция или нет. Идентификация может быть осуществлена либо путем введения типографских различий, либо путем использования явной идентификации в сопроводительном тексте, либо любым другим
способом.
8.3.5.3.11 Шаг оценивания APE_REQ.1-11
Оценщик должен исследовать изложение раздела «Требования безопасности ИТ», чтобы сделать заключение, корректно ли выполнены операции.
Оценщику следует иметь в виду, что операции над требованиями безопасности необязательно должны быть выполнены и завершены в ПЗ.
Оценщик сравнивает каждую формулировку требований в ПЗ с элементом, из которого она получена, чтобы сделать заключение:
a) для операции «назначение» — выбраны ли значения параметров или переменных в соответствии с указанным типом, требуемым операцией «назначение»;
b) для операции «выбор» — принадлежит ли выбранный пункт или пункты множеству пунктов, указанных во фрагменте «выбор» данного элемента. Оценщик также делает заключение, приемлемо ли число выбранных пунктов для данного требования. Для некоторых требований необходим выбор только одного пункта (например,
FAU_GEN.1.1.b), в других случаях приемлем выбор нескольких пунктов (например, вторая операция в
FDP_ITT.1.1);
c) для операции «уточнение» — уточнен ли компонент таким образом, что ОО, удовлетворяющий уточненному требованию, также удовлетворяет и
неуточненному требованию. Если уточненное требование выходит за эти рамки, то его считают расширенным требованием.
Пример ADV_SPM.1.2C — Модель ПБО должна содержать описание правил и характеристик всех политик ПБО, которые могут быть смоделированы. Уточнение: Модель ПБО должна охватывать только управление доступом. Если политика управления доступом является единственной политикой ПБО, то такое уточнение является правомерным. Если в ПБО также имеются политики идентификации и аутентификации, а уточнение означает, что моделировать следует только управление доступом, то это уточнение не является правомерным.
Особым случаем уточнения является редакционное уточнение, когда в требование вносят небольшие изменения, а именно переформулирование предложения в соответствии с правилами грамматики. Не допускается, чтобы такое изменение каким-либо образом изменяло смысл требования.
Пример редакционного уточнения — FAU_ARP.1 с единственным действием. Вместо записи: «ФБО должны предпринять информировать оператора при обнаружении возможного нарушения безопасности» допускается, чтобы разработчик ПЗ написал: «ФБО должны информировать оператора при обнаружении возможного нарушения безопасности».
Оценщику необходимо иметь в виду, что редакционные уточнения должны быть четко идентифицированы (см. шаг оценивания
APE_REQ.1-10);
d) для операции «итерация» — отличается ли каждая итерация компонента от каждой другой итерации этого компонента (по крайней мере, один элемент одной итерации компонента должен отличаться от соответствующего элемента другой итерации компонента), или что компонент применяется к разным частям ОО.
8.3.5.3.12 Шаг оценивания APE_REQ.1-12
ИСО/МЭК15408-3 APE_REQ.1.7C: Любые незавершенные операции над требованиями безопасности ИТ, включенными в ПЗ, должны быть идентифицированы.
Оценщик должен исследовать изложение раздела «Требования безопасности ИТ», чтобы сделать заключение, идентифицированы
ли все незавершенные операции над требованиями безопасности ИТ, включенными в ПЗ.
Оценщик делает заключение, все ли операции идентифицированы в каждом компоненте, где такая операция используется. Необходимо, чтобы завершенные и незавершенные операции были идентифицированы таким образом, чтобы они могли быть различимы и было ясно, завершена
ли операция или нет.
Идентификация может быть осуществлена либо путем введения типографских различий, либо путем явной идентификации в сопроводительном тексте, либо любым другим способом.
8.3.5.3.13 Шаг оценивания APE_REQ.1-13
ИСО/МЭК 15408-3 APE_REQ.1.8C: Зависимости между требованиями безопасности ИТ, включенными
в ПЗ, следует удовлетворить.
Оценщик должен исследовать изложение раздела «Требования безопасности ИТ», чтобы сделать заключение, удовлетворены ли зависимости, требуемые компонентами, используемыми при изложении раздела «Требования безопасности ИТ».
Зависимости могут быть удовлетворены включением соответствующего компонента (или компонента, иерархичного по отношению к последнему) в подраздел «Требования безопасности для ОО» или в подраздел «Требования безопасности для среды ИТ».
Хотя ИСО/МЭК 15408 поддерживает проведение анализа зависимостей путем их включения в описание компонентов требований, сам по себе данный факт не является логическим обоснованием того, что никакие другие зависимости не существуют. Пример существования таких зависимостей: элемент, в который включена ссылка «все объекты» или «все субъекты», может иметь зависимость по отношению к уточнению в другом элементе или наборе элементов, в котором перечислены данные объекты или субъекты.
Зависимости требований безопасности для среды ИТ следует излагать и удовлетворять в ПЗ.
Оценщику необходимо иметь в виду, что в соответствии с ИСО/МЭК 15408 не требуется, чтобы все зависимости были удовлетворены: см. следующий шаг оценивания.
8.3.5.3.14 Шаг оценивания APE_REQ.1-14
ИСО/МЭК 15408-3 APE_REQ.1.9C: Свидетельство должно содержать логическое обоснование каждого неудовлетворения зависимостей.
Оценщик должен исследовать «Обоснование требований безопасности», чтобы сделать заключение, содержится ли в нем приемлемое логическое обоснование для каждого случая, когда зависимости требований безопасности
не удовлетворены.
Оценщик с учетом идентифицированных
целей безопасности делает заключение, объяснено ли в логическом обосновании, почему удовлетворение зависимости не требуется.
Оценщик подтверждает, что никакое неудовлетворение зависимости не препятствует тому, чтобы набор требований безопасности адекватно учитывал цели безопасности. Такой анализ проводят в соответствии с
APE_REQ.1.13C.
Пример приемлемого логического обоснования
- Для программного ОО имеется цель безопасности следующего содержания: «Случаи неуспешной аутентификации должны быть зарегистрированы с указанием идентификационной информации о пользователе, времени и дате»,
- и для удовлетворения данной цели безопасности используется функциональное требование на основе компонента
FAU_GEN.1 «Генерация данных аудита». Компонент FAU_GEN.1 содержит зависимость от компонента FPT_STM.1 «Надежные метки времени». Так как ОО не имеет встроенных часов, то FPT_STM.1 определяется разработчиком ПЗ как требование безопасности для
среды ИТ. Разработчик ПЗ указывает на то, что данное требование не подлежит удовлетворению, приводя следующее логическое обоснование: «8 данной конкретной среде существуют возможности проведения атак на механизм меток времени; таким образом, среда может не обеспечить надежные метки времени. Но имеющиеся источники угроз не способны к проведению атак на механизмы меток времени, а другие атаки со стороны этих источников угроз могут быть подвергнуты анализу с регистрацией времени и даты осуществления».
8.3.5.3.15 Шаг оценивания APE_REQ.1-15
ИСО/МЭК 15408-3 APE_REQ.1.10С: ПЗ должен включать в себя изложение приемлемого минимального уровня
стойкости функций безопасности (СФБ) для функциональных
требований безопасности ОО: базовой, средней или высокой СФБ.
Оценщик должен проверить, включено ли в ПЗ заявление минимального уровня стойкости функции безопасности для функциональных требований безопасности ОО и определен ли этот уровень СФБ как базовый, средний или высокий.
Если требования доверия к безопасности ОО не включают в себя компонент AVA_SOF.1 «Оценка стойкости функции безопасности ОО», то данный шаг оценивания не применяют и поэтому считают удовлетворенным.
Стойкость криптографических алгоритмов находится вне области действия ИСО/МЭК 15408. Стойкость функции безопасности применяют только к вероятностным и перестановочным механизмам, которые являются не криптографическими. Следовательно, когда в ПЗ содержится утверждение о минимальном
уровне СФБ, оно не применимо к каким бы то
ни было криптографическим механизмам, с точки зрения оценки по ИСО/МЭК 15408. Когда такие криптографические механизмы входят в состав ОО, то оценщик делает заключение, представлено ли в ПЗ четкое изложение того, что оценка стойкости криптографических алгоритмов не является частью оценки.
ОО может состоять из нескольких отдельных доменов, тогда автор ПЗ может посчитать более приемлемым иметь минимальный уровень стойкости функций безопасности для каждого домена, а не иметь один общий минимальный уровень стойкости функций безопасности для всего ОО. В этом случае допускается разделить функциональные требования безопасности ОО на отдельные
поднаборы и иметь различные минимальные уровни стойкости функций безопасности, ассоциированные с каждым поднабором.
Примером этого является распределенная терминальная система, включающая в себя терминалы пользователей, расположенные в общедоступных местах, и терминалы администраторов, расположенные
в физически защищенном месте. С требованиями по аутентификации для терминалов пользователей связана средняя СФБ, в то время как с требованиями по аутентификации для терминалов администраторов связана базовая СФБ. Вместо заявления о базовой СФБ как о минимальном уровне СФБ для ОО, что могло бы утвердить потенциальных потребителей ОО во мнении, что провести успешную атаку на механизмы аутентификации на терминалах пользователя относительно несложно, автор ПЗ разделяет ОО на два домена: домен пользователей и домен администраторов; разделяет функциональные требования безопасности
ОО на два поднабора, соответствующих выделенным доменам ОО; назначает в качестве минимального уровня СФБ базовую СФБ для поднабора требований, соответствующих домену администраторов, и среднюю СФБ для поднабора требований, соответствующих домену пользователей.
8.3.5.3.16 Шаг оценивания APE_REQ.1-16
ИСО/МЭК 15408-3 APE_REQ.1.11С: При изложении
требований безопасности должны быть идентифицированы все функциональные требования безопасности, для которых требуется явное заявление стойкости функции, с явным
заявлением стойкости функции для каждого такого функционального требования безопасности.
Оценщик должен проверить, что в ПЗ идентифицированы все конкретные функциональные требования безопасности ОО, для которых целесообразна заявленная в явном виде стойкость функции безопасности вместе с
конкретной метрикой.
Если подраздел «Требования доверия к безотказности
ОО» не содержит компонент
AVA_SOF.1 «Оценка стойкости функции безопасности ОО», то данный шаг оценивания не применяют и поэтому считают удовлетворенным.
Заявленной в явном виде стойкостью функции безопасности может быть «базовая СФБ», «средняя СФБ», «высокая СФБ» или заданная специфическая метрика. Когда используется специфическая метрика, оценщик делает заключение, является ли она приемлемой для конкретного типа функциональных требований и имеется ли возможность оценки утверждений о СФБ, выраженных в данной метрике. Данный шаг оценивания относится к тому случаю, когда автор ПЗ требует определить конкретные требования СФБ (т.е. выше, чем общее требование к СФБ в ПЗ) или — конкретную метрику СФБ. Конкретные требования к СФБ для функциональных требований безопасности ОО могут быть определены автором ПЗ. При отсутствии каких-либо конкретных требований к СФБ общее требование к СФБ в ПЗ применяют ко всем функциональным требованиям безопасности
ОО, изложенным в ПЗ. Оценщику следует удостовериться, что наличие или отсутствие требований к СФБ, сформулированных в явном виде, согласовано с другими частями данного ПЗ.
Потенциально в ПЗ определения требований к СФБ
могут варьироваться. В ПЗ может иметься общее требование к СФБ, кроме того, в рамках ПЗ для конкретных функциональных требований безопасности ОО могут иметься требования
к СФБ, определенные специально для этих функциональных требований.
Дальнейшие указания по приемлемости и допустимости метрик стойкости функций безопасности могут быть представлены конкретной системой оценки.
8.3.5.3.17 Шаг оценивания APE_REQ.1-17
ИСО/МЭК 15408-3 APE_REQ.1.12С: Обоснование требовании безопасности должно демонстрировать, что минимальный уровень стойкости функции в ПЗ, как и каждое явное указание стойкости функции, согласуются с целями безопасности ОО.
Оценщик должен исследовать «Обоснование требований безопасности», чтобы сделать заключение, демонстрирует ли оно согласованность минимального уровня стойкости функций, а также каждой заявленной в явном виде стойкости функции с целями безопасности для ОО.
Если в подраздел «Требования доверия к безопасности ОО» не включен компонент
AVA_SOF.1, то данный шаг оценивания не применяют и поэтому считают удовлетворенным.
Оценщик делает заключение, учтены ли в подразделе «Обоснование требований безопасности» детали, имеющие отношение к предполагаемой компетентности, ресурсам и мотивации нарушителей, описанные в разделе «Среда безопасности ОО». Например, утверждение о базовой СФБ неприемлемо, если требуется, чтобы ОО обеспечил защиту от нарушителей, обладающих высоким потенциалом нападения.
Оценщик также делает заключение, учтены ли в подразделе «Обоснование требований безопасности» все специфические, связанные со стойкостью
функций безопасности, характеристики целей безопасности. Оценщик может
использовать прослеживание от требований к цепям безопасности, чтобы сделать заключение, что требования, прослеженные к целям безопасности со специфическими, связанными со стойкостью функций безопасности, характеристиками, при необходимости, включают в себя соответствующее утверждение о стойкости связанных с этими требованиями функций безопасности.
8.3.5.3.18 Шаг оценивания APE_REQ.1-18
ИСО/МЭК 15408-3 APE_REQ.1.13С: Обоснование
требований безопасности должно демонстрировать, что требования безопасности ИТ пригодны для достижения целей безопасности.
Оценщик должен исследовать подраздел «Обоснование требований безопасности», чтобы сделать заключение, прослежены ли требования безопасности ОО к целям безопасности для ОО.
Оценщик делает заключение, прослежено
ли каждое функциональное требование безопасности ОО по крайней мере к одной цепи безопасности для ОО.
Неудача при попытке такого прослеживания означает, что-либо подраздел «Обоснование требований безопасности» является
неполным, либо раздел «Цели безопасности» является
неполным, либо функциональное требование безопасности ОО является бесполезным.
Допустимо также, но необязательно, прослеживание отдельных или всех
требований доверия к безопасности ОО к цепям безопасности для ОО.
Пример прослеживания требования доверия к безопасности ОО к цели безопасности для ОО - ПЗ, содержащий угрозу: «Пользователь непреднамеренно раскрывает информацию, используя изделие, которое он принимает за ОО» и цель безопасности для ОО для противостояния данной угрозе: «ОО
должен быть четко помечен соответствующим номером версии». Изложенная цель безопасности для ОО может быть достигнута путем выполнения
требований компонента АСМ_САР.1 «Номера версий», и поэтому разработчик ПЗ прослеживает данный компонент
к рассматриваемой цели безопасности для ОО.
8.3.5.3.19 Шаг оценивания APE_REQ.1-19
Оценщик должен исследовать подраздел «Обоснование требований безопасности», чтобы сделать заключение, прослежены ли требования безопасности для среды ИТ к целям безопасности для среды.
Оценщик делает заключение, прослежено ли каждое функциональное требование безопасности для среды ИТ по крайней мере к одной цели безопасности для среды.
Неудача при попытке такого прослеживания означает, что либо подраздел «Обоснование требований безопасности» является
неполным, либо подраздел «Цели безопасности для среды» является
неполным, либо функциональное требование безопасности для среды ИТ является бесполезным.
Допустимо также, но необязательно, для некоторых или всех требований доверия к безопасности для среды ИТ прослеживание к
целям безопасности для среды.
8.3.5.3.20 Шаг оценивания APE_REQ.1-20
Оценщик должен исследовать подраздел «Обоснование требований безопасности», чтобы сделать заключение, содержится ли в нем для каждой
цели безопасности для ОО приемлемое логическое обоснование того, что требования безопасности ОО пригодны для удовлетворения данной цели безопасности
для ОО.
Если никакие требования безопасности ОО не прослежены к конкретной
цели безопасности для ОО, то результат данного шага оценивания отрицательный.
Оценщик делает заключение, демонстрирует ли логическое обоснование для цели безопасности для ОО, что если все требования безопасности ОО, прослеженные к данной цели, удовлетворены, то цель безопасности для ОО достигнута.
Оценщик также делает заключение, действительно ли каждое требование безопасности ОО, прослеженное к
цели безопасности для ОО, будучи удовлетворенным, вносит вклад в достижение данной цели безопасности.
Несмотря на то, что прослеживание от требований безопасности ОО к целям безопасности для ОО, представленное в
подразделе «Обоснование требований безопасности», может быть частью логического
о6основания, само по себе оно не является логическим обоснованием.
8.3.5.3.21 Шаг оценивания APE_REQ.1-21
Оценщик должен исследовать подраздел «Обоснование требований безопасности», чтобы сделать заключение, содержит ли он для каждой цепи безопасности для среды ИТ приемлемое
логическое обоснование, что требования безопасности для среды ИТ пригодны для удовлетворения данной цели безопасности для среды ИТ.
Если никакие требования безопасности для среды ИТ не прослежены к конкретной цели безопасности для среды ИТ, то результат данного шага оценивания отрицательный.
Оценщик делает заключение, демонстрирует ли логическое обоснование для цели безопасности для среды, что если все требования безопасности для среды ИТ, прослеженные к данной цели безопасности для среды ИТ, удовлетворены, то цель безопасности для среды ИТ достигнута.
Оценщик также делает заключение, действительно ли каждое требование безопасности для среды ИТ, прослеженное к цели безопасности для среды ИТ, будучи удовлетворенным, вносит вклад в достижение данной цели безопасности.
Несмотря на то, что прослеживание требований безопасности для среды ИТ к целям безопасности для среды ИТ, представленное в подразделе «Обоснование требований безопасности», может быть частью логического обоснования, само по себе оно не является логическим обоснованием.
8.3.5.3.22 Шаг оценивания APE_REQ.1-22
ИСО/МЭК 15408-3 APE_REQ.1.14С: Обоснование требований безопасности должно демонстрировать, что совокупность требований безопасности ИТ образует взаимно согласованное и внутренне непротиворечивое целое.
Оценщик должен исследовать подраздел «Обоснование требований безопасности», чтобы
сделать заключение, демонстрирует ли он внутреннюю непротиворечивость совокупности требований безопасности ИТ.
Оценщик делает заключение, что во всех случаях, когда различные требования безопасности ИТ имеют отношение к одним и тем же типам событий, операций, данных,
тестов, подлежащих выполнению, и т.д. и данные требования могут вступать в противоречие друг с другом, приведено приемлемое логическое обоснование отсутствия таких противоречий.
Например, если ПЗ содержит требования, связанные как с индивидуальной подотчетностью пользователей, так и с их анонимностью, необходимо, чтобы было показано, что данные требования не противоречат друг другу. Сюда может входить показ того, что ни одно из подлежащих аудиту событий, для которых требуется индивидуальная подотчетность пользователей, не имеет отношения к действиям, для которых требуется анонимность пользователей.
Руководство по анализу непротиворечивости см. в А.3 «Анализ непротиворечивости» (приложение А).
8.3.5.3.23 Шаг оценивания APE_REQ.1-23
Оценщик должен исследовать подраздел «Обоснование требований безопасности», чтобы сделать заключение, демонстрирует ли он, что совокупность требований безопасности ИТ образует взаимно поддерживающее
целое.
Данный шаг оценивания основан на заключениях, сделанных в ходе выполнения шагов оценивания
APE_REQ.1-18 и APE_REQ.1-19, связанных с исследованием прослеживания от требований безопасности
ИТ к целям безопасности, и шагов оценивания
APE_REQ.1-20 и APE_REQ.1-21, связанных с исследованием пригодности требований безопасности ИТ для удовлетворения целей безопасности. Данный шаг оценивания требует от оценщика рассмотреть возможность фактического недостижения какой-либо цели безопасности из-за недостаточной поддержки со стороны других требований безопасности ИТ.
Данный шаг оценивания основан также на анализе зависимостей, выполняемом на предыдущих шагах оценивания, поскольку если функциональное требование
A имеет зависимость от функционального требования
B, то B поддерживает A по определению.
Оценщик делает заключение, демонстрирует ли
подраздел «Обоснование требовании безопасности» поддержку функциональными требованиями друг друга, где необходимо, даже когда нет явного указания на наличие зависимостей между этими требованиями. Предполагается, что такая демонстрация охватывает те функциональные требования безопасности, которые направлены:
a) на предотвращение обхода механизмов, реализующих другие функциональные требования безопасности, такие, например, как FPT_RVM.1 «Невозможность обхода ПБО»;
b) на предотвращение вмешательства в работу механизмов, реализующих другие функциональные требования безопасности, такие, например, как FPT_SEP «Разделение домена»;
c) на предотвращение деактивации механизмов, реализующих другие функциональные требования безопасности, такие, например, как FMT_MOF.1 «Управление режимом выполнения функций безопасности»;
d) на обеспечение обнаружения нападений (атак), направленных на нарушение работы механизмов, реализующих другие функциональные требования безопасности, такие, например, как компоненты класса FAU «Аудит безопасности».
В своем анализе оценщик учитывает результаты выполненных операций, чтобы сделать заключение, затрагивают ли они взаимную поддержку требованиями друг друга.
8.3.5.4 Действие APE_REQ.1.2E
8.3.5.4.1 Шаг оценивания APE_REQ.1-24
Оценщик должен исследовать изложение раздела «Требования безопасности ИТ», чтобы сделать заключение, является ли оно логически упорядоченным.
Изложение требований безопасности ИТ является логически упорядоченным, если его структура и содержание понятны целевой аудитории (т.е. оценщикам и потребителям).
8.3.5.4.2 Шаг оценивания APE_REQ.1-25
Оценщик должен исследовать изложение раздела «Требования безопасности ИТ», чтобы сделать заключение, является ли оно полным.
При выполнении данного шага оценивания используют результаты шагов оценивания, выполняемых в соответствии с требованиями APE_REQ,1.1E и APE_SRE.1.1E, и в особенности — результаты исследования оценщиком подраздела «Обоснование требований безопасности».
Изложение раздела «Требования безопасности ИТ» является полным, если оценщик считает требования безопасности достаточными для того, чтобы удостовериться, что все цели безопасности для ОО удовлетворены.
8.3.5.4.3 Шаг оценивания APE_REQ.1-26
Оценщик должен исследовать изложение раздела «Требования безопасности ИТ», чтобы сделать заключение, является ли оно внутренне непротиворечивым.
При выполнении данного шага оценивания используют результаты шагов оценивания, выполняемых в соответствии с требованиями
APE_REQ.1.1E и APE_SRE.1.1E, и в особенности - результаты исследования оценщиком подраздела «Обоснование требований безопасности».
Изложение раздела «Требования безопасности ИТ» является внутренне непротиворечивым, если оценщик делает заключение, что ни одно требование безопасности не противоречит любому другому требованию безопасности таким образом, что цель безопасности не будет полностью удовлетворена.
Руководство по анализу непротиворечивости см.
в А.3 «Анализ непротиворечивости» (приложение А).
8.3.6 Оценка требований безопасности ИТ, сформулированных в явном виде
(APE_SRE.1)
8.3.6.1 Цели
Цель данного подвида деятельности — сделать заключение, являются ли функциональные требования и/или требования доверия к безопасности, сформулированные без ссылки на ИСО/МЭК
15408, приемлемыми и адекватными.
8.3.6.2 Исходные данные
Свидетельством оценки для этого подвида деятельности является ПЗ.
8.3.6.3 Замечания по применению
Этот пункт применяют только в случае, если в ПЗ содержатся требования безопасности, сформулированные в явном виде без ссылки на ИСО/МЭК 15408-2 или ИСО/МЭК 15408-3.
В противном случае все шаги оценивания, описанные в данном пункте, не применяют и поэтому считают удовлетворенными.
Требования семейства APE_SRE «Требования безопасности ИТ, сформулированные в явном виде» не заменяют требования семейства
APE_REQ «Требования безопасности ИТ», а являются дополнительными к ним. Это означает, что требования безопасности, сформулированные в явном виде без ссылки на ИСО/МЭК 15408-2 или ИСО/МЭК
15408-3, должны быть оценены на соответствие критериям семейства APE_SRE, а также в сочетании со всеми остальными требованиями безопасности - на соответствие критериям семейства
APE_REQ.
8.3.6.4 Действие APE_SRE.1.1E
8.3.6.4.1 Шаг оценивания APE_SRE.1-1
ИСО/МЭК 15408-3 APE_SRE.1.1C: Все требования
безопасности ОО, которые сформулированы в явном виде без ссылки на ИСО/МЭК
15408, должны быть идентифицированы.
Оценщик должен проверить, что в изложении раздела «Требования безопасности ИТ» идентифицированы все требования безопасности ОО, которые сформулированы в явном виде без ссылки на ИСО/МЭК 15408.
Необходимо, чтобы все функциональные требования безопасности ОО, которые не специфицированы на основе функциональных компонентов из ИСО/МЭК 15408-2, были четко идентифицированы как таковые. Аналогично необходимо, чтобы все требования доверия к безопасности ОО, которые не специфицированы на основе компонентов доверия из ИСО/МЭК
15408-3, были четко идентифицированы как таковые.
8.3.6.4.2 Шаг оценивания APE_SRE.1-2
ИСО/МЭК 15408-3 APE_SRE.1.2C: Все требования безопасности для среды ИТ, которые сформулированы в явном виде без ссылки на ИСО/МЭК 15408, должны быть идентифицированы.
Оценщик должен проверить, что в изложении раздела «Требования безопасности ИТ» идентифицированы все требования безопасности для среды ИТ, которые сформулированы в явном виде без ссылки на ИСО/МЭК 15408.
Необходимо, чтобы все функциональные требования безопасности для среды ИТ, которые не специфицированы на основе функциональных компонентов из ИСО/МЭК 15408-2, были четко идентифицированы как
таковые. Аналогично необходимо, чтобы все требования доверия к среде ИТ, которые не специфицированы на основе компонентов доверия по ИСО/МЭК 15408-3, были четко идентифицированы как таковые.
8.3.6.4.3 Шаг оценивания APE_SRE.1-3
ИСО/МЭК 15408-3 APE_SRE.1.3C: Свидетельство должно содержать логическое обоснование, почему требования безопасности должны быть сформулированы в явном виде.
Оценщик должен исследовать «Обоснование требований безопасности», чтобы сделать заключение, содержится
ли в нем приемлемое логическое обоснование, почему каждое из сформулированных в явном виде требований безопасности пришлось сформулировать в явном виде.
Оценщик для каждого сформулированного в явном виде требования безопасности ИТ делает заключение, объяснено
ли в логическом обосновании, почему существующие функциональные компоненты или компоненты доверия (из ИСО/МЭК 15408-2 и ИСО/МЭК 15408-3 соответственно) не могли быть использованы для выражения требований безопасности, сформулированных в явном виде. При вынесении заключения оценщик принимает во внимание возможность выполнения операций (т.е. назначение, итерация, выбор и уточнение) над этими существующими компонентами.
8.3.6.4.4 Шаг оценивания APE_SRE.1-4
ИСО/МЭК 15408-3 APE_SRE.1.4C: Сформулированные в явном виде требования безопасности ИТ должны использовать компоненты, семейства и классы требований ИСО/МЭК 15408 как образец для представления.
Оценщик должен исследовать каждое сформулированное в явном виде требование безопасности ИТ, чтобы сделать заключение, использованы ли для этого требования в качестве модели для представления компоненты, семейства и классы требований по ИСО/МЭК 15408.
Оценщик делает заключение, представлены ли сформулированные в явном виде требования безопасности ИТ в том же стиле и на сопоставимом уровне детализации, что и компоненты из ИСО/МЭК 15408-2 или ИСО/МЭК 15408-3. Оценщик также делает заключение, разделены ли функциональные требования на отдельные функциональные элементы и определяют ли требования доверия элементы действий разработчика, содержания и представления свидетельств, а также действий оценщика.
8.3.6.4.5 Шаг оценивания APE_SRE.1-5
ИСО/МЭК 15408-3 APE_SRE.1.5C: Сформулированные в явном виде требования безопасности ИТ должны быть измеримы и устанавливать объективные требования оценки, такие, чтобы соответствие или несоответствие им ОО могло быть определено и последовательно продемонстрировано.
Оценщик должен исследовать каждое сформулированное в явном виде требование безопасности ИТ, чтобы сделать заключение, измеримо ли оно и устанавливает ли объективные требования оценки такие, что соответствие или несоответствие им ОО может быть определено и продемонстрировано систематическим методом.
Оценщик делает заключение, изложены ли функциональные требования таким образом, что они тестируемы и прослеживаемы к соответствующим представлениям ФБО. Оценщик также делает заключение, что требования доверия не приводят к необходимости вынесения о них субъективного суждения со стороны оценщика.
Имеющиеся в ИСО/МЭК 15408 функциональные требования и требования доверия должны быть использованы как образец.
8.3.6.4.6 Шаг оценивания APE_SRE.1-6
ИСО/МЭК 15408-3 APE_SRE.1.6C: Сформулированные в явном виде требования безопасности ИТ должны быть четко и недвусмысленно выражены.
Оценщик должен исследовать каждое сформулированное в явном виде требование безопасности ИТ, чтобы сделать заключение, выражено ли оно четко и однозначно.
Имеющиеся в ИСО/МЭК 15408 функциональные требования и требования доверия должны быть использованы как образец.
8.3.6.4.7 Шаг оценивании APE_SRE.1-7
ИСО/МЭК 15408-3 APE_SRE.1.7C: Обоснование требований безопасности должно демонстрировать, что требования доверия применимы и пригодны для поддержки каждого из сформулированных в явном виде функциональных требований безопасности ОО.
Оценщик должен исследовать «Обоснование требований безопасности», чтобы сделать заключение, демонстрирует ли оно, что требования доверия применимы и приемлемы для поддержки любых сформулированных в явном виде функциональных требований безопасности ОО.
Оценщик делает заключение, приведет ли применение специфицированных требований доверия к получению значимого результата оценки для каждого сформулированного в явном виде функционального требования безопасности или следует специфицировать какие-либо другие требования доверия. Например,
сформулированное в явном виде функциональное требование может предполагать потребность в конкретном документальном свидетельстве (таком, например, как модель ПБО), конкретной глубине тестирования или конкретном анализе (таком, как анализ стойкости функций безопасности ОО или анализ скрытых каналов).
8.3.6.5 Действие APE_SRE.1.2E
8.3.6.5.1 Шаг оценивания APE_SRE.1-8
Оценщик должен исследовать изложение раздела «Требования безопасности ИТ», чтобы сделать заключение, все ли зависимости сформулированных в явном виде требований безопасности ИТ были идентифицированы.
Оценщик подтверждает, что никакие подлежащие удовлетворению зависимости не были пропущены разработчиком ПЗ.
Примеры возможных зависимостей: компоненты класса FAU «Аудит безопасности», если в сформулированном в явном виде функциональном требовании упоминается аудит, компоненты семейства
ADV_IMP «Представление реализации», если в сформулированном в явном виде требовании доверия упоминается исходный код или представление реализации ОО.
Далее
>>> |