36. Гост р 15408:2002. Часть 3. Представление требований доверия к безопасности. Структура класса, семейства, компонента, элемента и оценочных уровней доверия.

2. Требования доверия к безопасности

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

Имя класса

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

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

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

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

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

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

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

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

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

Цели

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цели

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

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

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

Зависимости

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

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

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

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

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

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

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

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

б) Элементы содержания и представления свидетельств, а именно: требуемое свидетельство; что свидетельство должно демонстрировать; какую информацию свидетельство должно отражать. Требования к содержанию и представлению свидетельств помечаются добавлением буквы "C" после номера элемента.

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

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

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

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

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

Имя ОУД

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

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

Цели

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

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

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

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

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

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

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

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

37. ГОСТ Р 15408:2002. Часть 3. ПАРАДИГМА ПОДДЕРЖКИ ДОВЕРИЯ. Цикл поддержки доверия. Приемка ОО. Мониторинг ОО. Переоценка. Обзор класса AMA - Поддержка доверия. План поддержки доверия. Отчет о категорировании компонентов ОО. Свидетельство поддержки доверия. Анализ влияния на безопасность.

Парадигма поддержки доверия

Введение

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

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

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

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

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

а) сертифицированная версия ОО – версия, которая была оценена и сертифицирована;

б) текущая версия ОО – версия, которая в некотором смысле отличается от сертифицированной версии; это может быть, например:

– новый выпуск ОО,

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

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

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

Цикл поддержки доверия

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

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

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

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

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

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

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

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

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