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

"РУКОВОДЯЩИЙ ДОКУМЕНТ. БЕЗОПАСНОСТЬ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ. КРИТЕРИИ ОЦЕНКИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ " (Утв. Приказом Гостехкомиссии РФ от 19.06.2002 N 187)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рисунок 15.1 - Пример цикла поддержки доверия

Рисунок 15.2. Пример подхода к приемке ОО

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

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

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

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

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

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

15.2.1 Приемка ОО

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

15.2.2 Мониторинг ОО

Фаза мониторинга ОО в цикле поддержки доверия будет уточнена ниже с использованием семейств "Свидетельство поддержки доверия" и "Анализ влияния на безопасность" класса AMA.

15.2.3 Переоценка

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

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

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

Таблица 15.1

ПРЕДСТАВЛЕНИЕ СЕМЕЙСТВ ПОДДЕРЖКИ ДОВЕРИЯ

Рисунок 15.3. Пример подхода к мониторингу ОО

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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