ASE_INT.1 Задание по безопасности, введение ЗБ, требования оценки
Зависимости
ASE_DES.1 Задание по безопасности, описание ОО, требования оценки
ASE_ENV.1 Задание по безопасности, среда безопасности, требования оценки
ASE_OBJ.1 Задание по безопасности, цели безопасности, требования оценки
ASE_PPC.1 Задание по безопасности, утверждения о соответствии ПЗ, требования оценки
ASE_REQ.1 Задание по безопасности, требования безопасности ИТ, требования оценки
ASE_TSS.1 Задание по безопасности, краткая спецификация ОО, требования оценки
Элементы действий разработчика
ASE_INT.1.1D Разработчик должен представить введение ЗБ как часть ЗБ.
Элементы содержания и представления свидетельств
ASE_INT.1.1C Введение ЗБ должно содержать данные идентификации ЗБ, которые предоставляют маркировку и описательную информацию, необходимые для идентификации и применения ЗБ и ОО, к которому оно относится.
ASE_INT.1.2C Введение ЗБ должно содержать аннотацию ЗБ с общей характеристикой ЗБ в описательной форме.
ASE_INT.1.3C Введение ЗБ должно содержать утверждение о соответствии ОК, излагающее все оцениваемые утверждения для ОО о соответствии ОК.
Элементы действия оценщика:
ASE_INT.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
ASE_INT.1.2E Оценщик должен подтвердить, что введение ЗБ является логически последовательным и внутренне непротиворечивым.
ASE_INT.1.3E Оценщик должен подтвердить, что введение ЗБ согласуется с другими частями ЗБ.
5.4Цели безопасности (ASE_OBJ)
Цели
Цели безопасности – краткое изложение предполагаемой реакции на задачу безопасности. Оценка целей безопасности требуется для демонстрации, что установленные цели адекватны проблеме безопасности. Существуют цели безопасности для ОО и цели безопасности для среды. Необходимо сопоставить цели безопасности для ОО и среды с идентифицированными угрозами, которым они противостоят, и/или с политикой и предположениями, которым они соответствуют.
ASE_OBJ.1 Задание по безопасности, цели безопасности, требования оценки
Зависимости
ASE_ENV.1 Задание по безопасности, среда безопасности, требования оценки
Элементы действий разработчика
ASE_OBJ.1.1D Разработчик должен представить изложение целей безопасности как часть ЗБ.
ASE_OBJ.1.2D Разработчик должен представить логическое обоснование целей безопасности.
Элементы содержания и представления свидетельств
ASE_OBJ.1.1C Изложение целей безопасности должно определить цели безопасности для ОО и его среды.
ASE_OBJ.1.2C Цели безопасности для ОО должны быть четко изложены и сопоставлены с идентифицированными угрозами, которым будет противостоять ОО, и/или с политикой безопасности организации, которая будет выполняться ОО.
ASE_OBJ.1.3C Цели безопасности для среды должны быть четко изложены и сопоставлены с теми аспектами идентифицированных угроз, которым ОО противостоит не полностью, и/или с политикой безопасности организации или предположениями, не полностью выполняемыми ОО.
ASE_OBJ.1.4C Логическое обоснование целей безопасности должно демонстрировать, что изложенные цели безопасности пригодны для противостояния всем идентифицированным угрозам безопасности.
ASE_OBJ.1.5C Логическое обоснование целей безопасности должно демонстрировать, что изложенные цели безопасности пригодны для охвата всех установленных положений политики безопасности организации и предположений.
Элементы действий оценщика
ASE_OBJ.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
ASE_OBJ.1.2E Оценщик должен подтвердить, что описание целей безопасности является полным, логически последовательным и внутренне непротиворечивым.
5.5Утверждения о соответствии ПЗ (ASE_PPC)
Цели
Цель оценки утверждений о соответствии ПЗ состоит в том, чтобы решить, является ли ЗБ корректным отображением ПЗ.
Замечания по применению
Семейство применяют только при наличии утверждений о соответствии ПЗ. В противном случае не требуется никаких действий разработчика и оценщика.
Хотя при наличии утверждений о соответствии ПЗ необходимы дополнительные действия по оценке, затраты на оценку ЗБ обычно все-таки меньше, чем в случае, когда никакой ПЗ не применяется, потому что при оценке ЗБ можно использовать результаты оценки этого ПЗ.
ASE_PPC.1 Задание по безопасности, утверждения о соответствии ПЗ, требования оценки
Зависимости
ASE_OBJ.1 Задание по безопасности, цели безопасности, требования оценки
ASE_REQ.1 Задание по безопасности, требования безопасности ИТ, требования оценки
Элементы действий разработчика
ASE_PPC.1.1D Разработчик должен представить каждое утверждение о соответствии ПЗ как часть ЗБ.
ASE_PPC.1.2D Разработчик должен представить логическое обоснование утверждений о соответствии ПЗ для каждого представленного утверждения о соответствии ПЗ.
Элементы содержания и представления свидетельств
ASE_PPC.1.1C Каждое утверждение о соответствии ПЗ должно идентифицировать ПЗ, соответствие которому утверждается, включая необходимые уточнения, связанные с этим утверждением.
ASE_PPC.1.2C Каждое утверждение о соответствии ПЗ должно идентифицировать формулировки требований безопасности ИТ, в которых завершены разрешенные операции или иначе выполнено дальнейшее уточнение требований ПЗ.
ASE_PPC.1.3C Каждое утверждение о соответствии ПЗ должно идентифицировать формулировки содержащихся в ЗБ целей безопасности и требований безопасности ИТ, которые дополняют имеющиеся в ПЗ.
Элементы действий оценщика
ASE_PPC.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
ASE_PPC.1.2E Оценщик должен подтвердить, что утверждения о соответствии профилям защиты являются корректным отображением соответствующих ПЗ.
5.6Требования безопасности ИТ (ASE_REQ)
Цели
Требования безопасности ИТ, выбранные для ОО и представленные или указанные в ЗБ, необходимо оценить для подтверждения их внутренней непротиворечивости и пригодности для разработки ОО, отвечающего его целям безопасности.
Это семейство представляет требования оценки, которые позволяют оценщику принять решение, что ЗБ пригодно для использования в качестве изложения требований к соответствующему ОО. Дополнительные критерии, необходимые для оценки требований, сформулированных в явном виде, приведены в семействе ASE_SRE.
Замечания по применению
Термин "требования безопасности ИТ" подразумевает "требования безопасности ОО" с возможным включением "требований безопасности для среды ИТ".
Термин "требования безопасности ОО" подразумевает "функциональные требования безопасности ОО" и/или "требования доверия к ОО".
В компоненте ASE_REQ.1 использованы несколько значений термина «appropriate» («соответствующий», «необходимый», «приемлемый», «целесообразный») для указания, что данные элементы допускают выбор в определенных случаях. Какой выбор является приемлемым, зависит от контекста ЗБ. Подробная информация по этим аспектам содержится в приложении В к части 1 ОК.
ASE_REQ.1 Задание по безопасности, требования безопасности ИТ, требования оценки
Зависимости
ASE_OBJ. 1 Задание по безопасности, цели безопасности, требования оценки
Элементы действий разработчика
ASE_REQ.1.1D Разработчик должен представить изложение требований безопасности ИТ как часть ЗБ.
ASE_REQ.1.2D Разработчик должен представить логическое обоснование требований безопасности.
Элементы содержания и представления свидетельств
ASE_REQ.1.1C Изложение функциональных требований безопасности ОО должно идентифицировать функциональные требования безопасности ОО, составленные из компонентов функциональных требований из части 2 ОК.
ASE_REQ.1.2C Изложение требований доверия к ОО должно идентифицировать требования доверия к ОО, составленные из компонентов требований доверия из части 3 ОК.
ASE_REQ.1.3C В изложение требований доверия к ОО следует включить оценочный уровень доверия (ОУД), как определено в части 3 ОК.
ASE_REQ.1.4C Свидетельство должно содержать строгое обоснование, что изложение требований доверия к ОО является соответствующим.
ASE_REQ.1.5C ЗБ должно, при необходимости, идентифицировать каждое требование безопасности для среды ИТ.
ASE_REQ.1.6C Операции, предусмотренные в требованиях безопасности ИТ, включенных в ЗБ, должны быть идентифицированы и выполнены.
ASE_REQ.1.7C Зависимости между требованиями безопасности ИТ, включенными в ЗБ, следует удовлетворить.
ASE_REQ.1.8C Свидетельство должно содержать строгое обоснование каждого неудовлетворения зависимостей.
ASE_REQ.1.9C ЗБ должно включать в себя изложение приемлемого минимального уровня стойкости функций безопасности (СФБ) для функциональных требований безопасности ОО: базовой, средней или высокой СФБ.
ASE_REQ.1.10C ЗБ должно идентифицировать все конкретные функциональные требования безопасности ОО, для которых целесообразно явное указание стойкости функции, так же как и конкретной метрики.
ASE_REQ.1.11C Логическое обоснование требований безопасности должно демонстрировать, что минимальный уровень стойкости функции в ЗБ, как и каждое явное указание стойкости функции согласуются с целями безопасности ОО.
ASE_REQ.1.12C Логическое обоснование требований безопасности должно демонстрировать, что требования безопасности ИТ пригодны для достижения целей безопасности.
ASE_REQ.1.13C Логическое обоснование требований безопасности должно демонстрировать, что совокупность требований безопасности ИТ образует взаимно согласованное и внутренне непротиворечивое целое.
Элементы действий оценщика
ASE_REQ.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
ASE_REQ.1.2E Оценщик должен подтвердить, что описание требований безопасности ИТ является полным, логически последовательным и внутренне непротиворечивым.
5.7Требования безопасности ИТ, сформулированные в явном виде (ASE_SRE)
Цели
Если, после тщательного рассмотрения, окажется, что ни один из компонентов требований частей 2 или 3 ОК не применим непосредственно ко всем или к части требований безопасности ИТ, разработчик ЗБ может сформулировать другие требования, которые не ссылаются на ОК. Использование таких требований должно быть строго обосновано.
Это семейство содержит требования оценки, которые позволяют оценщику сделать заключение, что сформулированные в явном виде требования четко и однозначно выражены. Оценка требований, выбранных из ОК и используемых наряду со сформулированными в явном виде допустимыми требованиями безопасности, определяется семейством ASE_REQ.
Сформулированные в явном виде требования безопасности ИТ для ОО, представленные или указанные в ЗБ, требуется оценить для демонстрации четкости и однозначности их выражения.
Замечания по применению
Формулировка в явном виде требований по структуре, сопоставимой со структурой существующих компонентов и элементов из ОК, включает в себя выбор аналогичного маркирования, способа выражения и уровня детализации.
Использование требований ОК как образца означает, что требования могут быть четко идентифицированы, что они автономны, и применение каждого требования возможно и даст значимый результат оценки, основанный на изложении соответствия ОО этому конкретному требованию.
Термин "требования безопасности ИТ" подразумевает "требования безопасности ОО" с возможным включением "требований безопасности для среды ИТ".
Термин "требования безопасности ОО" подразумевает "функциональные требования безопасности ОО" и/или "требования доверия к ОО".
ASE_SRE.1 Задание по безопасности, требования безопасности ИТ, сформулированные в явном виде, требования оценки
Зависимости
ASE_REQ.1 Задание по безопасности, требования безопасности ИТ, требования оценки
Элементы действий разработчика
ASE_SRE.1.1D Разработчик должен представить изложение требований безопасности ИТ как часть ЗБ.
ASE_SRE.1.2D Разработчик должен представить логическое обоснование требований безопасности.
Элементы содержания и представления свидетельств
ASE_SRE.1.1C Все требования безопасности ОО, которые сформулированы в явном виде без ссылки на ОК, должны быть идентифицированы.
ASE_SRE.1.2C Все требования безопасности для среды ИТ, которые сформулированы в явном виде без ссылки на ОК, должны быть идентифицированы.
ASE_SRE.1.3C Свидетельство должно содержать строгое обоснование, почему требования безопасности должны быть сформулированы в явном виде.
ASE_SRE.1.4C Сформулированные в явном виде требования безопасности ИТ должны использовать компоненты, семейства и классы требований ОК как образец для представления.
ASE_SRE.1.5C Сформулированные в явном виде требования безопасности ИТ должны быть измеримы и устанавливать объективные требования оценки, такие, что соответствие или несоответствие им ОО может быть определено и последовательно продемонстрировано.
ASE_SRE.1.6C Сформулированные в явном виде требования безопасности ИТ должны быть четко и недвусмысленно выражены.
ASE_SRE.1.7C Логическое обоснование требований безопасности должно демонстрировать, что требования доверия применимы и пригодны для поддержки каждого из сформулированных в явном виде функциональных требований безопасности ОО.
Элементы действий оценщика
ASE_SRE.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
ASE_SRE.1.2E Оценщик должен определить, что все зависимости сформулированных в явном виде требований безопасности ИТ были идентифицированы.
5.8Краткая спецификация ОО (ASE_TSS)
Цели
Краткая спецификация ОО предоставляет определение в самом общем виде функций безопасности, заявленных для удовлетворения функциональных требований, и мер доверия, выбранных для удовлетворения требований доверия.
Замечания по применению
Отношение между функциями безопасности ИТ и функциональными требованиями безопасности ОО может быть отношением типа "многие ко многим". Тем не менее, каждая функция безопасности должна способствовать удовлетворению, по меньшей мере, одного требования безопасности, чтобы можно было четко определить ФБО. Функции безопасности, которые не соответствуют этому требованию, обычно необязательны. Заметим, однако, что требование, чтобы функция безопасности способствовала удовлетворению, по меньшей мере, одного требования безопасности, сформулировано в наиболее общем виде, с тем, чтобы для всех функций безопасности, которые полезны для ОО, существовала бы возможность обоснования.
Изложение мер доверия уместно во всех случаях, когда в ЗБ включены требования доверия, не входящие в ОК. Если требования доверия к ОО в ЗБ основаны исключительно на оценочных уровнях доверия или других компонентах доверия из ОК, то меры доверия могут быть представлены в форме ссылки на документы, которые указывают на удовлетворение требований доверия.
В компоненте ASE_TSS.1 использованы несколько значений термина "appropriate" ("соответствующий", "необходимый") для указания, что данные элементы допускают выбор в определенных случаях. Какой выбор является приемлемым, зависит от контекста ЗБ. Подробная информация по этим аспектам содержится в приложении В к части 1 ОК.
ASE_TSS.1 Задание по безопасности, краткая спецификация ОО, требования оценки
Зависимости
ASE_REQ.1 Задание по безопасности, требования безопасности ИТ, требования оценки
Элементы действий разработчика
ASE_TSS.1.1D Разработчик должен представить краткую спецификацию ОО как часть ЗБ.
ASE_TSS.1.2D Разработчик должен представить логическое обоснование краткой спецификации ОО.
Элементы содержания и представления свидетельств
ASE_TSS.1.1C Краткая спецификация ОО должна содержать описание функций безопасности ИТ и мер доверия к ОО.
ASE_TSS.1.2C Краткая спецификация ОО должна сопоставить функции безопасности ИТ и функциональные требования безопасности ОО таким образом, чтобы можно было отметить, какие функции безопасности ИТ каким функциональным требованиям безопасности ОО удовлетворяют, и что каждая функция безопасности ИТ способствует удовлетворению, по меньшей мере, одного функционального требования безопасности ОО.
ASE_TSS.1.3C Функции безопасности ИТ должны быть определены в неформальном стиле на уровне детализации, необходимом для понимания их назначения.
ASE_TSS.1.4C Все ссылки на механизмы безопасности, включенные в ЗБ, должны быть сопоставлены с соответствующими функциями безопасности так, чтобы можно было отметить, какие механизмы безопасности использованы при реализации каждой функции.
ASE_TSS.1.5C Логическое обоснование краткой спецификации ОО должно демонстрировать, что функции безопасности ИТ пригодны для удовлетворения функциональных требований безопасности ОО.
ASE_TSS.1.6C Логическое обоснование краткой спецификации ОО должно демонстрировать, что сочетание специфицированных функций безопасности ИТ в совокупности способно удовлетворить функциональные требования безопасности ОО.
ASE_TSS.1.7C Краткая спецификация ОО должна сопоставить меры и требования доверия так, чтобы можно было отметить, какие меры способствуют удовлетворению каких требований.
ASE_TSS.1.8C Логическое обоснование краткой спецификации ОО должно демонстрировать, что меры доверия удовлетворяют все требования доверия к ОО.
ASE_TSS.1.9C Краткая спецификация ОО должна идентифицировать все функции безопасности ИТ, которые реализованы вероятностным или перестановочным механизмом соответственно.
ASE_TSS.1.10C Краткая спецификация ОО должна установить для каждой функции безопасности ИТ, для которой это необходимо, требование стойкости функции либо по специальной метрике, либо как базовую, среднюю или высокую СФБ.
Элементы действий оценщика
ASE_TSS.1.1E Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств.
ASE_TSS.1.2E Оценщик должен подтвердить, что краткая спецификация ОО является полной, логически последовательной и внутренне непротиворечивой.
6Оценочные уровни доверия
Оценочные уровни доверия (ОУД) образуют возрастающую шкалу, которая позволяет соотнести получаемый уровень доверия со стоимостью и возможностью достижения этой степени доверия. В части 3 ОК идентифицированы разделенные понятия доверия к ОО по завершению оценки и поддержки этого доверия в процессе эксплуатации ОО.
Важно обратить внимание, что не все семейства и компоненты из части 3 ОК включены в оценочные уровни доверия. Это не означает, что они не обеспечивают значимое и полезное доверие. Напротив, ожидается, что эти семейства и их компоненты будут рассматриваться для усиления ОУД в тех ПЗ и ЗБ, для которых они полезны.
6.1Краткий обзор оценочных уровней доверия (ОУД)
В таблице 6.1 представлено сводное описание ОУД. Графы таблицы представляют иерархически упорядоченный набор ОУД, а строки – семейства доверия. Каждый номер в образованной ими матрице идентифицирует конкретный компонент доверия, применяемый в данном случае.
Как показано в следующем подразделе, в части 3 ОК определены семь иерархически упорядоченных оценочных уровней доверия для ранжирования доверия к ОО. Каждый последующий ОУД представляет более высокое доверие, чем любой из предыдущих. Увеличение доверия от предыдущего ОУД к последующему достигается заменой какого-либо компонента доверия иерархичным компонентом из того же семейства доверия (т.е. увеличением строгости, области и/или глубины оценки) и добавлением компонентов из других семейств доверия (т.е. добавлением новых требований).
ОУД состоят из определенной комбинации компонентов доверия, как описано в разделе 2. Точнее, каждый ОУД включает в себя не более одного компонента каждого семейства доверия, а все зависимости каждого компонента доверия учтены.
Хотя в части 3 ОК определены именно ОУД, можно представлять другие комбинации компонентов доверия. Специально введенное понятие "усиление" ("augmentation") допускает добавление (из семейств доверия, до этого не включенных в ОУД) или замену компонентов доверия в ОУД (другими, иерархичными компонентами из того же самого семейства доверия). Из конструкций установления доверия, определенных в ОК, только ОУД могут быть усилены. Понятие "ОУД за исключением какого-либо составляющего его компонента доверия" не признано в ОК как допустимое утверждение. Вводящий усиление обязан строго обосновать полезность и дополнительную ценность добавленного к ОУД компонента доверия. ОУД может быть также расширен требованиями доверия, сформулированными в явном виде.
Класс доверия
|
Семейство доверия
|
Компоненты доверия из оценочного уровня доверия
|
ОУД1
|
ОУД2
|
ОУД3
|
ОУД4
|
ОУД5
|
ОУД6
|
ОУД7
|
Управление конфигурацией
|
ACM_AUT
|
|
|
|
1
|
1
|
2
|
2
|
ACM_CAP
|
1
|
2
|
3
|
4
|
4
|
5
|
5
|
ACM_SCP
|
|
|
1
|
2
|
3
|
3
|
3
|
Поставка и эксплуатация
|
ADO_DEL
|
|
1
|
1
|
2
|
2
|
2
|
3
|
ADO_IGS
|
1
|
1
|
1
|
1
|
1
|
1
|
1
|
Разработка
|
ADV_FSP
|
1
|
1
|
1
|
2
|
3
|
3
|
4
|
ADV_HLD
|
|
1
|
2
|
2
|
3
|
4
|
5
|
ADV_IMP
|
|
|
|
1
|
2
|
3
|
3
|
ADV_INT
|
|
|
|
|
1
|
2
|
3
|
ADV_LLD
|
|
|
|
1
|
1
|
2
|
2
|
ADV_RCR
|
1
|
1
|
1
|
1
|
2
|
2
|
3
|
ADV_SPM
|
|
|
|
1
|
3
|
3
|
3
|
Руководства
|
AGD_ADM
|
1
|
1
|
1
|
1
|
1
|
1
|
1
|
AGD_USR
|
1
|
1
|
1
|
1
|
1
|
1
|
1
|
Поддержка жизненного цикла
|
ALC_DVS
|
|
|
1
|
1
|
1
|
2
|
2
|
ALC_FLR
|
|
|
|
|
|
|
|
ALC_LCD
|
|
|
|
1
|
2
|
2
|
3
|
ALC_TAT
|
|
|
|
1
|
2
|
3
|
3
|
Тестирование
|
ATE_COV
|
|
1
|
2
|
2
|
2
|
3
|
3
|
ATE_DPT
|
|
|
1
|
1
|
2
|
2
|
3
|
ATE_FUN
|
|
1
|
1
|
1
|
1
|
2
|
2
|
ATE_IND
|
1
|
2
|
2
|
2
|
2
|
2
|
3
|
Оценка уязвимостей
|
AVA_CCA
|
|
|
|
|
1
|
2
|
2
|
AVA_MSU
|
|
|
1
|
2
|
2
|
3
|
3
|
AVA_SOF
|
|
1
|
1
|
1
|
1
|
1
|
1
|
AVA_VLA
|
|
1
|
1
|
2
|
3
|
4
|
4
|
Таблица 6.1 – Обзор оценочных уровней доверия
6.2Детализация оценочных уровней доверия
Следующие подразделы содержат определения ОУД с использованием полужирного шрифта для выделения новых требований и их описания.
6.2.1Оценочный уровень доверия 1 (ОУД1) – предусматривающий функциональное тестирование
Цели
ОУД1 применим, когда требуется некоторая уверенность в правильном функционировании, а угрозы безопасности не рассматривают как серьезные. Он будет полезен там, где требуется независимо полученное доверие утверждению, что было уделено должное внимание защите персональных данных или подобной информации.
ОУД1 обеспечивает оценку ОО в том виде, в каком он доступен потребителю, путем независимого тестирования на соответствие спецификации и экспертизы представленной документации. Предполагается, что оценка может успешно проводиться без помощи разработчика ОО и с минимальными затратами.
При оценке на этом уровне следует предоставить свидетельство, что ОО функционирует в соответствии с документацией и предоставляет приемлемую защиту против идентифицированных угроз.
Компоненты доверия
ОУД1 (см. таблицу 6.2) предоставляет базовый уровень доверия посредством анализа функций безопасности с использованием для понимания режима безопасности функциональной спецификации, спецификации интерфейсов и руководств.
Анализ поддержан независимым тестированием ФБО.
Этот ОУД обеспечивает значимое увеличение доверия по сравнению с неоцененным продуктом или системой ИТ.
Таблица 6.2 – ОЦЕНОЧНЫЙ УРОВЕНЬ ДОВЕРИЯ 1
Класс доверия
|
Компоненты доверия
|
Управление конфигурацией
|
ACM_CAP.1 Номера версий
|
Поставка и эксплуатация
|
ADO_IGS.1 Процедуры установки, генерации и запуска
|
Разработка
|
ADV_FSP.1 Неформальная функциональная спецификация
|
ADV_RCR.1 Неформальная демонстрация соответствия
|
Руководства
|
AGD_ADM.1 Руководство администратора
|
AGD_USR.1 Руководство пользователя
|
Тестирование
|
ATE_IND.1 Независимое тестирование на соответствие
|
|
