"Общие критерии", часть 1. Основные идеи

Основные понятия и идеи "Общих критериев"

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

Система - это специфическое воплощение информационных технологий с конкретным назначением и условиями эксплуатации.

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

Объект оценки рассматривается в определенном контексте - среде безопасности, в которую включается все, что имеет отношение к его безопасности, а именно:

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

Дальнейший этап технологического цикла подготовки к оценке, согласно " Общим критериям ", - описание следующих аспектов среды ОО:

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

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

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

Для структуризации пространства требований в " Общих критериях " введена иерархия класс - семейство - компонент - элемент.

Классы определяют наиболее общую (как правило, предметную) группировку требований.

Семейства в пределах класса различаются по строгости и другим характеристикам требований.

Компонент - минимальный набор требований, фигурирующий как целое.

Элемент - неделимое требование.

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

" Общие критерии " содержат два основных вида требований безопасности:

• функциональные, соответствующие активному аспекту защиты, предъявляемые к функциям безопасности ОО и реализующим их механизмам;
• требования доверия, которые соответствуют пассивному аспекту, предъявляются к технологии и процессу разработки и эксплуатации ОО.

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

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

Для проектируемого изделия за выработкой требований следует разработка краткой спецификации, входящей в задание по безопасности (ЗБ).

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

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

При проведении оценки изделия ИТ главными являются следующие вопросы:

• отвечают ли функции безопасности ОО функциональным требованиям?
• корректна ли реализация функций безопасности?

Если оба ответа положительны, можно говорить о достижении целей безопасности.