Общие критерии, версия 3.0. Что нового?

В. Г. Грибунин , к. т. н.

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

 

Работа над ошибками

В июле 2005 года на сайте Общих критериев (ОК) – www.commoncriteriaportal. org – был опубликован проект новой версии ОК, получивший номер 3.0. Изменения по сравнению с предыдущими версиями очень существенные. По сути, это первая серьезная модификация ОК за семь лет. Можно было бы подумать, что данная модификация вызвана прогрессом информационных технологий, но это не так. Версия 3.0 во многом создана для устранения недостатков прежних редакций.

В числе целей разработки версии 3.0 декларируются:

• устранение избыточной деятельности по оценке;

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

• уточнение терминологии ОК;

• перенацеливание деятельности по оценке на те области, где доверие к безопасности может быть усилено;

• добавление новых требований.

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

В настоящей статье описываются основные особенности версии 3.0 ОК в сравнении с их предыдущими вариантами.

Первоначальный взгляд

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

 

Таблица

	Количество страниц	Количество классов	Количество семейств
Часть II, 2.2/3.0	365/127	11/6	67/45
Часть III, 2.2/3.0	171/242	9/8	40/38
Часть I, 2.2/3.0	64/79	–	–
ОМО	351/466	–	–

Как видно из таблицы, наибольшим изменениям подверглись вторая и третья части стандарта. И действительно, многие классы и семейства удалены, другие добавлены, оставшиеся подверглись серьезным изменениям.

Мы не будем рассматривать далее ОМО, поэтому ограничимся лишь замечанием, что виды и подвиды деятельности в этом документе упорядочены по классам доверия ОК, а не по оценочным уровням доверия, как это было в версии 2.2. Таким образом, разработчики вернулись к структуре ОМО версии 1.1а, которая легла в основу отечественного РД.

Изменения терминов и определений

Терминология ОК подверглась значительной переработке. В частности, обращает на себя внимание то, что слово «компонент» теперь может относиться не только к набору требований текста ОК, но и к объекту оценки (ОО). То есть «компонент» = «подсистема» или «множество подсистем ОО». Такое определение сделано с целью ввести требования композиции ОО в третьей части ОК, что является ее наиболее заметным изменением.

В прежних версиях существовало разделение ОО на системы и продукты. В новой – понятие «системы» исчезло, имеется лишь достаточно абстрактное определение продукта, как «совокупности программных, программно-аппаратных, аппаратных средств и/или руководств». Таким образом, согласно определению, руководство пользователя тоже является продуктом.

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

Убрано понятие «стойкости функции безопасности». И это совершенно правильно, всегда казалось, что оно «притянуто за уши». В самом деле, данное понятие применяется при оценке «некриптографических вероятностных и перестановочных механизмов». Что это такое – никто не знает. Приведение в качестве примеров механизмов генерации паролей и хэш-функций не выдерживает никакой критики.

В тексте ОК не встречаются больше понятия «функция безопасности», «политика функции безопасности», которые вызывали справедливые нарекания. Теперь эти понятия заменены на «функциональность безопасности ОО» и «политика безопасности ОО».

Разработчики ОК ушли от понятия «доверенный канал», «доверенный путь», посчитав достаточным понятие «интерфейса функциональности безопасности ОО».

Новые правила написания профилей защиты и заданий по безопасности

Прежде всего, надо отметить, что изменена структура этих документов. Некоторые разделы и подразделы переставлены местами, и отсутствует раздел «Обоснование». По всей видимости, это сделано для облегчения труда разработчиков ПЗ, заданий по безопасности (ЗБ) и уменьшения объема документов. Конечно, обоснование предъявляемых требований будет выполняться в любом случае, но по ходу изложения, а не в отдельном разделе.

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

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

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

Введено понятие ПЗ/ЗБ с низким доверием – с урезанным содержанием (для ОУД1). В этих документах нет постановки проблемы безопасности, обоснования целей и требований, меньше целей безопасности. Также в них не надо соблюдать зависимости между компонентами.

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

Изменения в функциональных требованиях

Перейдем теперь к рассмотрению изменений во второй части ОК. Согласно [1], все классы функциональных требований версии 2.2 ОК можно разделить в зависимости от того, реализуют ли они элементарные сервисы безопасности (FAU, FIA, FRU), производные от элементарных (FCO, FPR), направлены на высокоуровневые цели безопасности (FDP, FPT) или играют инфраструктурную роль (FCS, FMT, FTA, FTP).

Прежде всего, заметим, что из новой редакции ОК исчезли классы FCS, FMT, FPR, FRU, FTA, FTP и добавлен новый класс FMI «Разное». Остальные классы переработаны процентов на 70–80.

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

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

FAU. Итак, рассмотрим изменения в классе аудита безопасности FAU. Из шести семейств этого класса осталось три: убраны FAU_SAR, FAU_SEL, FAU_STG. Изменено ключевое семейство класса FAU_GEN. Разработчики решили отказаться от нескольких уровней аудита, оставив один-единственный. Кроме того, теперь будет возможным ведение аудита без времени – в случаях, когда нет надежного источника последнего. Таким образом, несмотря на то что компоненты семейства сохранили свое наименование, их содержание изменено.

FIA. В классе FIA, напротив, вместо шести семейств теперь одиннадцать. Внимания заслуживает добавление FIA_TBR – правил сопоставления ФБО (например, кому-то можно работать с 8.00 до 20.00, кому-то – нет), FIA_SUA – аутентификации субъекта/ФБО (для реализации взаимной аутентификации), FIA_TIN – информации ФБО (например, истории доступа), FIA_LOB – временной блокировки сопоставлений (в качестве примера можно привести скринсейвер с паролем), FIA_TOB – прекращения сопоставлений (может быть активизирована как ФБО, так и пользователем), FIA_URE – регистрации пользователя. Вместо спецификации секретов теперь имеется семейство качества аутентификационных данных, а семейство определения атрибутов пользователя отсутствует. Семейство FIA_SOS переименовано в FIA_QAD, а семейство FIA_ATD удалено.

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

Иной смысл теперь у семейства FIA_USB: атрибуты пользователя могут меняться или оставаться неизменными при связывании пользователь/субъект.

FCO. Теперь класс FCO вместо двух семейств «Связь» включает в себя двенадцать. В него включены все требования по передаче информации, которые ранее были в нем и в классе FDP, а также новые семейства, такие как доступность экспортируемых данных FCO_AED, преобразование экспортируемых/импортируемых данных (и атрибутов безопасности) FCO_TED/TID, ненаблюдаемость экспорта (возможно, и в целях стеганографии) FCO_UNE.

FDP. Так как термин «пользовательские данные» больше не используется, этот класс называется «Защита и приватность данных». В нем из тринадцати бывших семейств осталось всего два. Часть из них были перемещены в класс FCO, а часть вообще ликвидирована. Обращает на себя внимание отсутствие семейств контроля информационных потоков FDP_IFC, FDP_IFF, семейства функций управления доступом FDP_ACF.

В класс добавлены четыре новых семейства: инициализации атрибутов доступа FDP_ISA, управления ими FDP_MSA, невозможности установления связи различных событий FDP_UNL (то есть того, что разные события взаимосвязаны) и семейство ненаблюдаемости действий FDP_UNO. Кстати говоря, выполнение требований последнего семейства может полностью предотвратить появление скрытых каналов в системе.

FPT. Из шестнадцати семейств данного класса осталось девять, из них три называются так же, как ранее, остальные шесть – новые. К семейству самотестирования ФБО добавилось семейство тестирования пользователей FPT_TOU. При этом название семейства обманчиво. Под пользователями здесь понимаются не только и не столько люди, сколько любая программа, запущенная вне ОО, к которой ОО имеет доступ. В класс FPT вошли все три семейства из класса FRU, а также семейство защиты остаточной информации из класса FDP.

FMI. Новый класс «Разное» содержит три семейства. Семейство генерации случайных чисел FMI_RND позволяет задать метрику, которой должна удовлетворять выходная последовательность чисел (неясно, почему здесь говорится только о случайных, но не о псевдослучайных числах). Семейство временных меток FMI_TIM задает точность этого механизма для различных объектов. При помощи конструкции, описанной в семействе выбора FMI_CHO, разработчик ПЗ (но не ЗБ) может сопоставить целям безопасности множество разных функций, оставляя право их выбора за разработчиком ЗБ. Разработчик ЗБ в этом случае должен включить данный компонент, чтобы было ясно, что он сделал выбор из множества функций.

Таковы, вкратце, изменения в классах функциональных требований.

Изменения в третьей части ОК

Как видно из таблицы, третья часть ОК версии 3.0 почти в полтора раза больше предыдущей версии. Самым важным изменением этой версии можно считать добавление нового класса АСО – «Композиция», включающего пять семейств. Данный класс предназначен для построения сложного ОО на основе более простых, уже оцененных ОО. В тексте ОК подчеркивается, что составной ОО, так же как и его части, предназначен для использования в различных условиях, он не является системой, которая разрабатывается для конкретных условий эксплуатации. (Здесь разработчики ОК, по видимому, допустили ошибку, забыв о том, что деление изделий ИТ на продукты и системы ими в первой части ОК «отменено».)

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

В части 3 ОК приведено подробное изложение подхода к композиции ОО (приложение В). Его анализ выходит за рамки данной статьи. Отметим лишь, что для составного ОО в ОК введены три уровня доверия, которые включают требования компонентов из классов АСО «Композиция», ALC «Поддержка жизненного цикла» и ASE «Оценка ЗБ».

Другие изменения третьей части ОК. Разработчики учли тот факт, что все требования к управлению конфигурацией относятся к поддержке жизненного цикла изделий. Поэтому класс АСМ удален, а в класс ALC добавлены два семейства по управлению конфигурацией ALC_CMC, ALC_CMS и, кроме того, семейство «Поставка» ALC_DEL.

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

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

Сокращен класс AVA: из него убраны три семейства: «Анализ скрытых каналов», «Неправильное использование» и «Стойкость функций безопасности».

Табличное сравнение изменений в версии 3.0 ОК по сравнению с версией 2.2 вы можете найти в документе Common Criteria Version 3.0 Update [2].

Что дальше?

Итак, даже поверхностный анализ третьей версии ОК показывает, что изменения очень существенны. Предстоят большие затраты, ведь фактически придется переработать все имеющиеся ПЗ/ЗБ, а также РД ФСТЭК. Положение нашей страны особенно незавидное: ведь толькотолько ОК начали применяться в качестве инструмента для задания требований и оценки изделий, как уже потребовались серьезные изменения.

Стремление к пресловутой гармонизации нормативной базы привело к тому, что вдобавок к существующей технологической зависимости России от Запада добавляется еще и «нормативная» зависимость, причем эта зависимость проявляется в такой чувствительной для национальной безопасности сфере, как защита информации. Может быть, лучше наконец-то остановиться, проанализировать версии ОК, другие разработки, выбрать из них все наилучшее и создать свои «правила игры»? А там, глядишь, и другие страны подтянутся.

Разумеется, мы понимаем, что это предложение хорошо лишь в теории, по сути же оно наивно и вряд ли осуществимо: слишком большие средства уже потрачены на аутентичные переводы...

ЛИТЕРАТУРА

1. Галатенко В. А. Стандарты информационной безопасности. М.: Интернет-университет информационных технологий, 2004. 328 с.

2. http://www.commoncriteriaportal.org/public/files/ CCv3.0%20transition.pdf.

 

Защита информации. INSIDE № 6’2005