Класс и семейства поддержки доверия

Для осуществления концепции поддержки доверия был разработан класс АМА, включающий в себя четыре семейства, приведенные в таблице 15.1.

Таблица 15.1 - Представление семейства поддержки доверия

Класс доверия	Семейство доверия	Краткое имя
	План поддержки доверия	АМА_AMP
АМА Поддержка доверия	Отчет о категорировании компонентов ОО	АМА_CAT
	Свидетельство поддержки доверия	АМА_EVD
	Анализ влияния на безопасность	AMA_SIA

15.3.1 План поддержки доверия

План поддержки доверия (ПД) определяет основную линию поведения при поддержке доверия в зависимости от результатов оценки и проведения категорирования компонентов ОО.

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

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

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

б) значительное изменение внешних интерфейсов ФБО, отнесенных к категории обеспечивающих осуществление ПБО;

в) значительное изменение подсистем ФБО, отнесенных к категории обеспечивающих осуществление ПБО (для случаев, когда требования доверия включают в себя ADV_HLD.1 или иерархичные компоненты).

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

Более подробная спецификация правил находится вне рамок ГОСТ Р ИСО/МЭК 15408, в частности, из-за того, что смысл выражения значительное изменение будет зависеть от типа оцененного ОО и содержания задания по безопасности.

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

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

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

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

ж) по устранению недостатков, включая отслеживание и исправление выявленных недостатков безопасности (как предусматривает ALC_FLR.1).

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

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

15.3.2 Отчет о категорировании компонентов ОО

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

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

Отчет о категорировании компонентов ОО распространяется на все представления ФБО на поддерживаемом уровне доверия. Отчет о категорировании компонентов ОО также идентифицирует:

а) любые аппаратные, программно-аппаратные и программные компоненты, которые являются внешними по отношению к ОО (например, аппаратные или программные платформы) и удовлетворяют требованиям безопасности ИТ, определенным в ЗБ;

б) любые инструментальные средства разработки, модификация которых будет влиять на требуемое доверие к тому, что ОО удовлетворяет своему ЗБ.

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

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

Представляется полезным включать в ЗБ компонент АМА_САТ.1, где имеется требование поддержки доверия в последующих версиях ОО. Оно применяется независимо от того, достигается ли поддержка доверия использованием требований этого класса или же периодической переоценкой ОО.

15.3.3 Свидетельство поддержки доверия

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

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

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

а) записи управления конфигурацией;

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

в) свидетельство отслеживания недостатков безопасности.

Проверка оценщиком анализа влияния на безопасность, проведенного разработчиком, (требуемая AMA_SIA.1, от которого зависит AMA_EVD.1) займет центральное место в аудите ПД. Аудит ПД будет, в свою очередь, способствовать подтверждению анализа, проведенного разработчиком (и, следовательно, уверенности в качестве анализа), обеспечивая подтверждение правильности утверждения разработчика, что доверие к ОО поддерживается для его текущей версии.

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

15.3.4 Анализ влияния на безопасность

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

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

Компоненты этого семейства могут использоваться для поддержки последующего аудита ПД или для переоценки ОО.

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

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

Следует, чтобы подготовка анализа влияния на безопасность для поддержки переоценки уменьшила трудозатраты оценщика, необходимые для установления требуемого уровня доверия к ОО. Применение AMA_SIA.2, который содержит требование полной экспертизы анализа влияния на безопасность, предоставит, как ожидается, максимальный выигрыш при переоценке. Детализация условий, при которых орган оценки мог бы на практике потребовать использование при переоценке анализа влияния на безопасность, находится за рамками ГОСТ Р ИСО/МЭК 15408.