Введены в действие "Общие критерии" v1.0

История создания и текущий статус "Общих критериев"

В 1990 году Рабочая группа 3 Подкомитета 27 Первого совместного технического комитета (JTC1/SC27/WG3) Международной организации по стандартизации (ISO) приступила к разработке "Критериев оценки безопасности информационных технологий" (Evaluation Criteria for IT Security, ECITS). Несколько позже, в 1993 году, правительственные организации шести североамериканских и европейских стран - Канады, США, Великобритании, Германии, Нидерландов и Франции - занялись составлением так называемых "Общих критериев оценки безопасности информационных технологий" (Common Criteria for IT Security Evaluation). За этим документом исторически закрепилось более короткое название - "Общие критерии", или ОК (Common Criteria, CC).

Рабочая группа ISO, возглавляемая представителем Швеции, функционировала на общественных началах и действовала весьма неторопливо, пытаясь собрать и увязать между собой мнения экспертов примерно из двух десятков стран, в то время как коллектив "Проекта ОК", финансируемый своими правительствами, несмотря на первоначальное трехлетнее отставание, весьма быстро начал выдавать реальные результаты. Объяснить это нетрудно: в "Проекте ОК" требовалось объединить и развить всего три весьма продвинутых и близких по духу документа - "Гармонизированные критерии Европейских стран", а также "Канадские критерии оценки доверенных компьютерных продуктов" и "Федеральные критерии безопасности информационных технологий" (США). (Сами разработчики "Общих критериев" относят к числу первоисточников еще и "Оранжевую книгу".)

Как правило, круг людей, заседающих в комитетах и комиссиях по информационной безопасности, довольно узок, поэтому нет ничего удивительного в том, что одни и те же представители стран (в частности, США и Великобритании) входили в обе группы разработчиков. Естественно, в таких условиях между коллективом "Проекта ОК" и Рабочей группой 3 установилось тесное взаимодействие. Практически это означало, что группа WG3 стала бесплатным приложением к "Проекту ОК", а сами "Общие критерии" автоматически должны были получить статус не межгосударственного, а международного стандарта.

В ОС Unix есть утилита tee, создающая ответвления каналов путем копирования стандартного вывода в файлы и довольно точно моделирующая взаимоотношения между коллективом "Проекта ОК" и группой WG3. С 1994 года ранние версии ОК становятся рабочими проектами WG3. В 1996 году появилась версия 1.0 "Общих критериев", которая, помимо публикации в Internet для всеобщего свободного доступа, была одобрена ISO и обнародована в качестве Проекта Комитета.

Широкое открытое обсуждение документа и "опытная эксплуатация" привели к его существенной переработке и выходу версии 2.0 ОК в мае 1998 года. Разумеется, эксперты WG3 не могли ее не отредактировать. Их замечания были учтены в версии 2.1 ОК [34-36], принятой в августе 1999 года. Соответствующий международный стандарт ISO/IEC 15408-1999 [53-55] введен в действие с 1 декабря 1999 года. Таким образом, фактически стандарт ISO/IEC 15408-1999 и версия 2.1 ОК совпадают, а если пренебречь описываемыми ниже нюансами, их названия могут считаться взаимозаменяемыми. Однако, строго говоря, "Критерии оценки безопасности информационных технологий" и "Общие критерии оценки безопасности информационных технологий" - разные документы, поскольку выпущены под эгидой разных организаций, руководствующихся разными правилами распространения и обновления.

ISO не предоставляет свободный доступ к своим стандартам, они относительно статичны, поскольку их обновляют или подтверждают один раз в пять лет (какие-либо изменения в стандарте ISO/IEC 15408 можно ожидать в 2004 году). Напротив, портал "Проекта ОК" ( http://www.commoncriteria.org) открыт для всех желающих, а разработчики "Общих критериев" постоянно предлагают и принимают изменения, уточнения, интерпретации отдельных положений и готовят третью версию своего документа. Поэтому, с формальной точки зрения, международный стандарт ISO/IEC 15408-1999 по-русски правильнее сокращенно именовать КОБИТ, а не ОК. (Правда, велика вероятность, что рабочая группа ISO любезно согласится и дальше пользоваться плодами "Проекта ОК", естественно, внося в них свои редакторские правки...)

Уточним, что далее, в рамках этой темы, мы будем иметь в виду именно "Общие критерии", а не стандарт ISO.

С целью унификации процедуры сертификации по "Общим критериям" в августе 1999 года была опубликована "Общая методология оценки безопасности информационных технологий" (Common Methodology for Information Technology Security Evaluation) [37], описывающая минимальный набор действий при проведении оценки. "Проект ОК" с самого начала носил не только технический, но и экономико-политический характер. Его цель состояла, в частности, в том, чтобы упростить, удешевить и ускорить выход сертифицированных изделий информационных технологий (ИТ) на мировой рынок. Для этого в мае 2000 года уполномоченные правительственные организации шести стран-основателей "Проекта ОК", а также Австралии и Новой Зеландии, Греции, Италии, Испании, Норвегии, Финляндии и Швеции подписали соглашение "О признании сертификатов по Общим критериям в области безопасности информационных технологий" (позднее к нему присоединились Австрия и Израиль).

Участие в соглашении предполагает соблюдение двух независимых условий: признание сертификатов, выданных соответствующими органами других стран-участниц, а также возможность осуществления подобной сертификации. Очевидно, от взаимного признания сертификатов выигрывают не только производители, но и потребители изделий ИТ. Что же касается их выдачи, то соглашение предусматривает жесткий контроль при получении и подтверждении этого права (например, предусмотрено проведение так называемых теневых сертификационных испытаний под контролем независимых экспертов). Таким образом, для полноценного участия в соглашении, помимо желания, государство должно располагать органами сертификации с достаточными ресурсами и штатом специалистов, квалификация которых получила официальное международное признание. По данным на конец 2002 года, правом выдачи сертификатов, признаваемых участниками соглашения, обладали Австралия и Новая Зеландия, Великобритания, Германия, Канада, США и Франция.

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

Определяя статус "Общих критериев" в России, следует отметить, что отечественные специалисты с самого начала внимательно следили за этим проектом, публиковали аналитические обзоры и переводы (см., например, [JI981K]). В 1999 году была организована работа по подготовке российского стандарта и Руководящего документа (РД) Гостехкомиссии России на основе аутентичного перевода ОК. Она велась в тесном контакте с зарубежными коллегами и успешно завершена в 2002 году. Именно тогда был официально издан ГОСТ Р ИСО/МЭК 15408-2002 "Критерии оценки безопасности информационных технологий" [10-12] с датой введения в действие 1 января 2004 года. А пока положение регулируется РД Гостехкомиссии России [19], который, как и "Общие критерии", по замыслу разработчиков, должен быть динамичнее стандарта, модифицируясь вместе с ОК.

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

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

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

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

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

законодательная среда - законы и нормативные акты, затрагивающие ОО;

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

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

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

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

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

положения политики безопасности, предназначенные для применения к объекту оценки. Для системы ИТ такие положения могут быть описаны точно, для продукта - в общих чертах.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

корректна ли реализация функций безопасности?

Основные понятия и идеи "Общей методологии оценки безопасности информационных технологий"

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

Следуя принципам структурной декомпозиции, разработчики выделили в процессе оценки три задачи (этапа):

входная задача;

задача оценки;

выходная задача.

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

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

На всех этапах оценки должна обеспечиваться конфиденциальность.

Задача оценки в общем случае разбивается на следующие подзадачи:

оценка задания по безопасности;

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

оценка документации по передаче ОО потребителю и эксплуатационной документации;

оценка документации разработчиков;

оценка руководств;

оценка поддержки жизненного цикла ОО;

оценка тестов;

тестирование;

оценка анализа уязвимостей.

Нередко проводятся выборочные проверки, когда вместо всего (относительно однородного) множества свидетельств анализируется представительное подмножество, что позволяет сэкономить ресурсы при сохранении необходимого уровня доверия безопасности. Размер выборки должен быть обоснован математически и экономически, но при анализе реализации объекта оценки он должен составлять не менее 20%.

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

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

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

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

Необходимый элемент оценки - проверка внутренней согласованности каждого из представленных свидетельств, а также внешней взаимной согласованности различных свидетельств.

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

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

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

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

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

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

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

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

Анализ уязвимостей применяется ко всем функциям безопасности; при этом не делается каких-либо предположений относительно корректности их реализации, сохранения целостности, возможности обхода и т.п.

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

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

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