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

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

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

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

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

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

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

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

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

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

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

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

Цикл поддержки доверия проиллюстрирован на рисунке 15.1.

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

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

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

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

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

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