Оценочные уровни доверия безопасности

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

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

В ОУД не включены требования классов APE, ASE и АМА, поскольку они находятся за пределами основного цикла разработки продуктов и систем ИТ.

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

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

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



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

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



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

– структурированное представление реализации;

– полуформальное представление проекта нижнего уровня;

– иерархическая структура проекта объекта оценки;

– устойчивость к попыткам проникновения нарушителей с высоким потенциалом нападения;

– проверка правильности систематического анализа разработчиком скрытых каналов;

– использование структурированного процесса разработки;

– полная автоматизация управления конфигурацией объекта оценки.

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

Контрольные вопросы

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

2. Можно ли изменять (если да, то каким образом) состав оценочных уровней доверия безопасности?

3. Какой максимальный оценочный уровень доверия может быть подтвержден при оценке объекта оценки без участия разработчика?

4. Объясните, что может считаться полуформальным представлением функциональной спецификации объекта оценки-программного продукта, используемым в ОУД 6?

5. Объясните различия между функциональным, структурным и систематическим тестированием объекта оценки, требуемым в ОУД 1 – ОУД 3.

6. Что такое систематическое проектирование, требуемое в ОУД 4?


obvedi-ne-otrivaya-karandasha-dorisuj-i-raskras.html
obvedi-vspomogatelnij-glagol-postav-vopros.html
    PR.RU™