ГОСТ Р ИСО/МЭК 15408-3-2002
оценки. В некоторых случаях изменения могут быть настолько значительными, что для дальнейшей
поддержки доверия переоценка обязательна. Таким образом, требования этого класса имеют дополни
тельную цель по обеспечению, при необходимости, экономически оправданной переоценки ОО.
Следует отметить, что вполне возможна переоценка каждой новой версии ОО по критериям из
разделов 4—5 и 8 - 14вообще без учета требований класса АМА. Однако класс ЛМЛ включает в себя
требования, которые могут быть использованы для поддержки любой такой переоценки.
Действия разработчика и оценщика по поддержке предполагается выполнять после того, как ОО
был оценен и сертифицирован, хотя, как описано ниже, некоторые требования могут применяться и
на стадии оценки. Примеры использования терминов в описании парадигмы:
а) сертифицированная версия ОО —версия, которая была оценена и сертифицирована:
б) текущая версия ОО —версия, которая в некотором смысле отличается от сертифицированной
версии; это может быть, например:
—новый выпуск ОО,
—сертифицированная версия с обновлениями, внесенными для исправления вновь обнаружен
ных ошибок,
—га же самая базовая версия ОО. но на другой аппаратной или программной платформе.
Роли разработчика и оценщика в этом классе такие же. как и описанные в ГОСТ Р ИСО/МЭК
15408-1. Однако совершенно необязательно, чтобы оценщик, упоминаемый втребованиях этого клас
са. ранее прнпихзат участие в оценке сертифицированной версии ОО.
Чтобы сделать возможным продолжение поддержки доверия к ОО без обязательной формальной
переоценки, требования этого класса накладывают на разработчика обязанность представить свиде
тельство. показывающие, что ОО по-прежнему удовлетворяет своему заданию по безопасности (на
пример, свидетельство тестирования разработчиком).
15.2 Цикл поддержки доверия
Этот подраздел описывает один из возможных подходов к использованию семейств и компонен
тов поддержки доверия с целью проиллюстрировать использование рассматриваемых понятий. Вкаче
стве примера приведен «цикл поддержки доверия*, разделенный на три следующие фазы:
а) приемка ОО <Ьяподдержки —начато цикла, когда планы и процедуры разработчика по
поддержке доверия в течение цикла устанавливает разработчик и затем их правильность неза
висимо подтверждает оценщик;
б) мониторинг —разработчик предоставляет в одной или нескольких контрольных точках цикла
свидетельство, что доверие к ОО поддерживается в соответст вии с установленными планами и
процедурами; это свидетельство поддержки доверия затем независимо проверяет оценщик:
в) переоценка —окончание цикла, когда обновленная версия ОО представляется на рассмотре
ние дтя переоценки, основанной на изменениях, которым подверглась сертифицированная
версия ОО.
Семейства класса АМА связаны прежде всего сдвумя первыми фазами, обеспечивая поддержку
для третьей. Эти фазы введены здесьтолько для того, чтобы понятнее описать применение требований
поддержки доверия. Не ставится цельсделатьстрого обязательной схему поддержки доверия, которая
формально включает в себя эти три фазы.
Цикл поддержки доверия проиллюстрирован на рисунке 15.1.
Врассматриваемом примере можно переходил, к фазе мониторинга ОО только после успешного
завершения фазы приемки (т. е. когда планы и процедуры разработчика по поддержке доверия уже
приняты). Если разработчик вносит изменения в эти планы или процедуры в фазе мониторинга,
необходимо вернуться к фазе приемки ОО. чтобы учесть произведенные изменения.
Вфазе мониторинга разработчик выполняет планы и процедуры поддержки доверия, проводя
анализ влияния на безопасность изменений, которым подвергается ОО (анализ влияния на безопас
ность). В определенных контрольных точках этой фазы оценщик независимо проверяет (посредством
аудита) деятельность разработчика. От разработчика требуется четкое выполнение планов и процедур
поддержки и анализа влияния на безопасность.
Поэтому при нахождении ОО в фазе мониторинга появляется возможность убедиться, что дове
рие к ОО поддерживается дтя новых версий ОО. выпущенных разработчиком.
ОО. который подвергается изменениям, не может пребывать в фазе мониторинга постоянно; в
какой-то момент времени переоценка ОО становится необходимой. Время принятия решения о необхо
димости переоценки зависит от накопления изменений в ОО, а также от особо значительных измене-