А.3 "Анализ непротиворечивости" (приложение А).
9.3.6.3.23 Шаг оценивания ASE_REQ.1-23
Оценщик должен исследовать подраздел "Обоснование требований безопасности", чтобы сделать заключение, демонстрирует ли он, что совокупность требований безопасности ИТ образует взаимно поддерживающее целое.
Данный шаг оценивания основан на заключениях, сделанных в ходе выполнения шагов оценивания ASE_REQ.1-18 и ASE_REQ.1-19, связанных с исследованием прослеживания от требований безопасности ИТ к целям безопасности, и шагов оценивания ASE_REQ.1-20 и ASЕ_КЕО.1-21, связанных с исследованием пригодности требований безопасности ИТ для удовлетворения целей безопасности. Данный шаг оценивания требует от оценщика рассмотреть возможность фактического недостижения какой-либо цели безопасности из-за недостаточной поддержки со стороны других требований безопасности ИТ.
Данный шаг оценивания основан также на анализе зависимостей, выполняемом на предыдущих шагах оценивания, поскольку если функциональное требование А имеет зависимость от функционального требования В, то В поддерживает А по определению.
Оценщик делает заключение, демонстрирует ли подраздел "Обоснование требований безопасности" поддержку функциональными требованиями друг друга, где необходимо, даже когда нет явного указания на наличие зависимостей между этими требованиями. Предполагается, что такая демонстрация охватывает те функциональные требования безопасности, которые направлены:
a) на предотвращение обхода механизмов, реализующих другие функциональные требования безопасности, такие, например, как FPT_RVM.1 "Невозможность обхода ПВО";
b) на предотвращение вмешательства в работу механизмов, реализующих другие функциональные требования безопасности, такие, например, как FPT_SEP "Разделение домена";
c) на предотвращение деактивации механизмов, реализующих другие функциональные требования безопасности, такие, например, как FMT_MOF.1 "Управление режимом выполнения функций безопасности";
d) на обеспечение обнаружения нападений (атак), направленных на нарушение работы механизмов, реализующих другие функциональные требования безопасности, такие, например, как компоненты класса FAU "Аудит безопасности".
В своем анализе оценщик учитывает результаты выполненных операций, чтобы сделать заключение, затрагивают ли они взаимную поддержку требованиями друг друга.
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Е, и в особенности - результаты исследования оценщиком подраздела "Обоснование требований безопасности".
Изложение раздела "Требования безопасности ИТ" является внутренне непротиворечивым, если оценщик делает заключение, что ни одно требование безопасности не противоречит любому другому требованию безопасности таким образом, что цель безопасности не будет полностью удовлетворена.
Руководство по анализу непротиворечивости см. в А.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.1Е
9.3.7.4.1 Шаг оценивания ASE_SRE.1-1
ИСО/МЭК 15408-3 ASE_SRE.1.1С: Все требования безопасности ОО, которые сформулированы в явном виде без ссылки на ИСО/МЭК 15408, должны быть идентифицированы.
Оценщик должен проверить, что в изложении раздела "Требования безопасности ИТ" идентифицированы все требования безопасности ОО, которые сформулированы в явном виде без ссылки на ИСО/МЭК 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.3С: Свидетельство должно содержать логическое обоснование, почему требования безопасности должны быть сформулированы в явном виде.
Оценщик должен исследовать "Обоснование требований безопасности", чтобы сделать заключение, содержится ли в нем приемлемое логическое обоснование, почему каждое из сформулированных в явном виде требований безопасности пришлось сформулировать в явном виде.
Оценщик для каждого сформулированного в явном виде требования безопасности ИТ делает заключение, объяснено ли в логическом обосновании, почему существующие функциональные компоненты или компоненты доверия (из ИСО/МЭК 15408-2 и ИСО/МЭК 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.1Е
9.3.8.3.1 Шаг оценивания ASE_TSS.1-1
ИСО/МЭК 15408-3 ASE_TSS.1.1С: Краткая спецификация ОО должна содержать описание функций безопасности ИТ и мер доверия к ОО.
Оценщик должен проверить, что раздел "Краткая спецификация ОО" содержит описание функций безопасности ИТ и мер доверия ОО.
Оценщик делает заключение, представлено ли в разделе "Краткая спецификация ОО" высокоуровневое определение функций безопасности, заявленных как предназначенные для удовлетворения функциональных требований, и мер доверия, заявленных как предназначенные для удовлетворения требований доверия к безопасности ОО.
Меры доверия могут быть сформулированы в явном виде или определены посредством ссылки на документы, которые удовлетворяют требованиям доверия к безопасности (например, соответствующие планы качества, планы жизненного цикла, планы управления).
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.7С: Краткая спецификация ОО должна сопоставить меры и требования доверия так, чтобы можно было отметить, какие меры способствуют удовлетворению каких требований.
Оценщик должен проверить раздел "Краткая спецификация ОО", чтобы сделать заключение, прослежена ли каждая мера доверия по крайней мере к одному требованию доверия к безопасности ОО.
Неудача при попытке такого прослеживания означает, что либо краткая спецификация ОО является неполной, либо изложение требований доверия к безопасности ОО является неполным, либо мера доверия является бесполезной.
9.3.8.3.9 Шаг оценивания ASE_TSS.1-9
ИСО/МЭК 15408-3 ASE_TSS.1.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.10С: Краткая спецификация ОО должна установить для каждой функции безопасности ИТ, для которой это необходимо, требование стойкости функции либо по специальной метрике, либо как базовую, среднюю или высокую СФБ.
Оценщик должен проверить, что для каждой функции безопасности ИТ, для которой это приемлемо, в разделе "Краткая спецификация ОО" установлено требование стойкости функции либо по специальной метрике, либо как базовая, средняя или высокая СФБ.
Если требования доверия к безопасности ОО не включают в себя компонент AVA_SOF.1, то данный шаг оценивания не применяют и поэтому считают удовлетворенным.
9.3.8.4 Действие ASE_TSS.1.2Е
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 "Анализ непротиворечивости" (приложение А).
|
