Законодательная база Российской Федерации

"МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ. КРИТЕРИИ ОЦЕНКИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ. Часть 3. ТРЕБОВАНИЯ ДОВЕРИЯ К БЕЗОПАСНОСТИ. ГОСТ Р ИСО/МЭК 15408-3-2008" (утв. Приказом Ростехрегулирования от 18.12.2008 N 521-ст)

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

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

6.1.1 Структура класса

Структура класса доверия показана на рисунке 1.

6.1.1.1 Имя класса

Каждому классу доверия присвоено уникальное имя. Это имя указывает на тематические разделы, на которые распространяется данный класс доверия.

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

6.1.1.2 Представление класса

Каждый класс доверия имеет вводный подраздел, в котором наложены состав и назначение класса.

6.1.1.3 Семейства доверия

Каждый класс доверия содержит, по меньшей мере, одно семейство доверия. Структура семейств доверия описана в 6.1.2.

6.1.2 Структура семейства доверия

Рисунок 1 иллюстрирует структуру семейства доверия.

6.1.2.1 Имя семейства

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

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

6.1.2.2 Цели

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

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

6.1.2.3 Ранжирование компонентов

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

В семействах доверия, содержащих более одного компонента, выполнено ранжирование компонентов и приведено его обоснование. Это обоснование сформулировано в терминах области применения, глубины и/или строгости.

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

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

6.1.2.5 Компоненты доверия

Каждое семейство содержит как минимум один компонент доверия. Структура компонентов доверия представлена в 6.1.3.

6.1.3 Структура компонента доверия

Структура компонента доверия показана на рисунке 2.

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

6.1 3.1 Идентификация компонента

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

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

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

6.1.3.2 Цели

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

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

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

6.1.3.4 Зависимости

Зависимости среди компонентов доверия возникают, если компонент не самодостаточен, а зависит от наличия другого компонента.

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

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

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

6.1.3.5 Элементы доверия

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

Каждый элемент доверия принадлежит к одному из трех типов:

1) элементы действий разработчика, определяющие действия, которые должны выполняться разработчиком. Этот набор действий далее уточняется доказательным материалом, упоминаемым в следующем наборе элементов. Требования к действиям разработчика обозначены латинской буквой "D" после номера элемента:

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

3) элементы действий оценщика, определяющие действия, которые должны выполняться оценщиком. Этот набор действий непосредственно включает в себя подтверждение того, что требования, предписанные элементам и содержания и представления свидетельств, выполнены, а также - конкретные действия и анализ, выполняемые в дополнение к уже проведенным разработчиком. Должны также выполняться не указанные в явном виде действия оценщика как результат элементов действий разработчика, не охваченных требованиями к содержанию и представлению свидетельств. Требования к действиям оценщика обозначены латинской буквой "Е" после номера элемента:

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

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

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

6.1.4 Элементы доверил

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

6.1.5 Структура ОУД

Структура ОУД, определенная а настоящем стандарта, представлена на рисунке 3. Компоненты доверия, содержание которых показано на данном рисунке, включены в ОУД посредством ссылок на компоненты доверия, приведенные в настоящем стандарта.

6.1.5.1 Имя ОУД

Каждому ОУД присвоено уникальное имя. Имя представляет описательную информацию о предназначении ОУД.

Представлена также уникальная краткая форма имени ОУД. Она является основным средством ссылки на ОУД.

6.1.5.2 Цели

В пункте целей ОУД приведено назначение ОУД.

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

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

6.1.5.3.1 Компоненты доверия

Для каждого ОУД выбран набор компонентов доверия.

Более высокий уровень доверия, чем предоставляемый данным ОУД, может быть достигнут:

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

b) заменой компонента доверия иерархичным компонентом из этого же семейства доверия.

6.1.5.4 Связь между требованиями и уровнями доверия

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

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

Класс, содержащий одно семейство, показан на рисунке 5. Семейство содержит три компонента, являющиеся линейно иерархичными (то есть компонент 2 содержит более высоте, чем компонент 1, требования к конкретным действиям, приводимым свидетельствам или строгости действий и/или свидетельств). Все семейства доверия в настоящем стандарте являются линейно иерархичными, хотя линейность не обязательна для семейств доверия, которые могут быть добавлены в дальнейшем.

Рисунок 5 - Типовая диаграмма декомпозиции класса

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

Названия классов АРЕ и ASE, составляющих их семейств, и их краткие имена приведены в таблицах 2, 3, 4, 5 раздела 7 настоящего стандарта. Содержание разделов ПЗ, рассматриваемых в семействах класса АРЕ, представлено в ИСО/МЭК 15408-1, приложение А, а содержание разделов ЗБ, рассматриваемых в семействах класса ASE - в 15408-1, приложение В.

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

6.4.1. логически упорядоченный (coherent): Сущность логически упорядочена и имеет очевидный смысл. Применительно к документации этот термин относится как к тексту, таки к структуре, указывая, что они понятны потенциальной аудитории.

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

6.4.3. подтверждать (confirm): Используется для указания необходимости подробного рассмотрения чего-либо: при этом требуется независимое заключение о его достаточности. Требуемый уровень строгости зависит от характера предмета оценки. Применим только к действиям оценщика.

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

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

6.4.6. демонстрировать (demonstrate): Относится к анализу, который приводит к заключению, но является менее строгим, чем "доказательство" ("proof").

6.4.7. описывать (describe). Требует, чтобы некоторые конкретные подробности сущности были представлены.

6.4.8. делать заключение (determine): Требуется независимый анализ для того, чтобы сделать конкретное заключение. Термин отличается от "подтверждать" ("confirm") или "верифицировать" ("verify"), так как последние подразумевают, что требует проверки анализ, проведенный ранее, в то время как термин "делать заключение" подразумевает совершенно независимый анализ обычно при отсутствии любого предшествующего анализа.

6.4.9. обеспечивать (ensure): Подразумевает сильную причинно-следственную связь между не которым действием и его последствиями. Часто ему предшествует термин "способствует" (whelps"), указывающий, что одно данное действие не полностью определяет последствия.

6.4.10 исчерпывающий (exhaustive): Используется применительно к проведению анализа или другой деятельности. Аналогичен термину "систематический" ("systematic:"), но более точен, так как указывает не только на то, что в соответствии с некоторым конкретным планом проведения анализа или другой деятельности был применен методический подход, но также и на то, что этот план достаточен для обеспечения проведения исследования по всем возможным направлениям.

6.4.11. объяснять (explain): Отличается от терминов "описывать" ("describe") "демонстрировать" ("demonstrate"). Предназначен для ответа на вопрос "Почему?" без попытки аргументировать, что код предпринимаемых действий обязательно оптимален.

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

6.4.13. логическое обоснованно (justification): Относится к анализу, ведущему -. заключению, но является более строгим, чем термин "демонстрация" ("demonstration.")- в смысле точных и подробные объяснений каждого шага логическим суждений.

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

6.4.15 доказывать (prove): Относится к формальному анализу в математическом смысле, полностью строгому во всех отношениях. Обычно используется, когда желательно показать соответствие между двумя представлениями ФБО на высоком уровне строгости.

6.4.16. специфицировать (specify): Используется в том же контексте, что и "описывать" ("describe"), но является более строгим и точным. Аналогичен термину "определять" ("define").

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

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

Классы и семейства доверия, а также их краткие имена приведены в таблице 1.

Таблица 1 - КЛАССЫ И СЕМЕЙСТВА ДОВЕРИЯ

Ниже приведены краткие списания классов и семейств доверия из разделов 12 - 18, представленные в том же порядке, е котором они - изложены в этим разделах.

6.6.1 Класс АСМ: Управление конфигурации.

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

6.6.1.1 Автоматизация УК (ACM_AUT)

Семейство "Автоматизация управления конфигурацией устанавливает уровень автоматизации, используемый для управления элементами конфигурации.

6.6.1.2 Возможности УК (АСМ_САР)

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

6.6.1.3 Область УК (ACM_SCP)

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

6.6.2 Класс ADO: Поставкам эксплуатация

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

6.6.2.1 Поставка (ADO_DEL)

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

6.6.2.2 Установка, генерация и запуск (ADO_IGS)

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

6.6. 3 Класс ADV: Разработка

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

6.6.3.1 Функциональная спецификация (ADV_FSP)

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

6.6.3.2 Проект верхнего уровня (ADV_HLD)

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

6.6.3.3 Представление- реализаций (AOV_IMP)

Представление реализации - наименее абстрактное представление ФБО. Оно фиксирует детализированное внутреннее содержание ФБО на уровне исходного текста, аппаратных схем и т.п.

6.6.3.4 Внутренняя структура ФБО (ADV_INT)

Требования к внутренней структуре ФБО определяют необходимое внутреннее структурирование ФБО.

6.6.3.5 Проект нижнего уровня (ADV_LLD)

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

6.6.3.6 Соответствие представлений (ADV_RCR)

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

6.6.3.7 Моделирование политики безопасности (ADV_SPM)

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

6.6.4 Класс AGD: Руководства

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

6.6.4.1 Руководство администратора (AGD_ADM)

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

6.6.4.2.Руководство пользователя (AGD_USR)

6.6.5 Класс ALC: Поддержка жизненного цикла

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

6.6.5.1 Безопасность разработки (ALC_OVS)

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

6.6.5.2 Устранение недостатков (ALC_FLR)

6.6.5.3 Определение жизненного цикла (ALC_LCD)

6.6.5.4 Инструментальные средства и метода (АLС_ТАТ)

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

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

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

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

6.6.8 Класс ATE: Тестирование

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

6.6.8.1 Покрытие (ATE_COV)

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

6.6.8.2 Глубина (АТЕ_СРТ)

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

6.6.8.3 Функциональное тестирование (ATE_FUN)

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

6.6.8.4 Независимое тестирование (ATE_IND)

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

6.6.9 Класс AVA: Оценка уязвимостей

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

6.6.9.1 Анализ скрытых каналов (AVA_CCA)

Семейство "Анализ скрытых каналов" направлено на выявление и анализ непредусмотренных коммуникационных каналов, которые могут применяться для нарушения предписанной ПВО.

6.6.9.2 Неправильное применение (AVA_MSU)

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

6.6.9.3 Стоимость функций безопасности ОО (AVA_SOF)

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

6.6.9.4 Анализ уязвимостей (AVA_VLA)

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

1) полноты ФБО (противостоят ли ФБО всем ожидаемым угрозам)

2) зависимостей между всеми функциями безопасности.

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