Профили защиты на основе "Общих критериев"

Аналитический обзор

В.Б. Бетелин (член-корреспондент РАН)
В.А. Галатенко
М.Т. Кобзарь
А.А. Сидак
И.А. Трифаленков

Содержание

Аннотация
Введение
Общие требования к сервисам безопасности
     Общие предположения безопасности
     Общие угрозы безопасности
     Общие элементы политики безопасности
     Общие цели безопасности для объекта оценки
     Общие цели безопасности для среды
     Общие функциональные требования
     Общие требования доверия безопасности
Специфические требования к сервисам безопасности
     Управление доступом
     Межсетевые экраны
     Системы активного аудита
     Анонимизаторы
     Выпуск и управление сертификатами
     Анализ защищенности
Специфические требования к комбинациям и приложениям сервисов безопасности
     Операционные системы
     Системы управления базами данных
     Виртуальные частные сети
     Виртуальные локальные сети
     Смарт-карты
Заключение
Литература

Аннотация

В статье анализируются профили защиты и их проекты, построенные на основе международного стандарта ISO/IEC 15408, описывающие сервисы безопасности, их комбинации и приложения. Выделяются общие требования, которые могут войти в состав функционального пакета, применимого ко всем сервисам, упрощающего разработку и понимание профилей для конкретных сервисов. Анализ профилей защиты позволяет оценить сильные и слабые стороны "Общих критериев", наметить возможные направления новых исследований.

Введение

В 1990 году под эгидой Международной организации по стандартизации (ИСО) были развернуты работы по созданию стандарта в области оценки безопасности информационных технологий (ИТ). Разработка этого стандарта преследовала следующие основные цели:

В июне 1993г. организации по стандартизации и обеспечению безопасности США, Канады, Великобритании, Франции, Германии и Нидерландов объединили свои усилия в рамках проекта по созданию единой совокупности критериев оценки безопасности ИТ. Этот проект получил название "Общие критерии" (ОК).

Общие критерии были призваны обеспечить взаимное признание результатов стандартизованной оценки безопасности на мировом рынке ИТ.

Разработка версии 1.0 "Общих критериев" (ОК) была завершена в январе 1996 года и одобрена ИСО в апреле 1996 года. Был проведен ряд экспериментальных оценок на основе версии 1.0 ОК, а также организовано широкое обсуждение документа.

В мае 1998 года была опубликована версия 2.0 ОК, и на ее основе в июне 1999 года принят международный стандарт ИСО/МЭК 15408. Официальный текст стандарта издан 1 декабря 1999 года [1] [2] [3]. Изменения, внесенные в стандарт на завершающей стадии его принятия, учтены в версии 2.1 ОК, идентичной стандарту по содержанию.

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

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

В России Центром безопасности информации (ЦБИ), Центром "Атомзащитаинформ", ЦНИИАТОМИНФОРМ, ВНИИстандарт при участии экспертов Международной рабочей группы по Общим критериям был подготовлен проект ГОСТ Р ИСО/МЭК 15408, содержащий полный аутентичный текст международного стандарта. Стандарт [4]  [5]  [6]  принят постановлением Госстандарта России от 4.04.2002 года № 133-ст с датой введения в действие 1 января 2004 года.

Для практической апробации ОК и нормативно-методических документов, разработанных в их поддержку [9]  [10], до ввода в действие ГОСТ Р ИСО/МЭК 15408 принят и введен в действие с 19.06.2002 года руководящий документ Гостехкомиссии России [7], полностью соответствующий указанному ГОСТ. Международный стандарт ISO/IEC 15408, а также его российский вариант ГОСТ Р ИСО/МЭК 15408 "Критерии оценки безопасности информационных технологий" в применении к оценке безопасности изделий информационных технологий (ИТ) являются по сути метасредствами, задающими систему понятий, в терминах которых должна производиться оценка, и содержащими относительно полный каталог требований безопасности (функциональных и доверия), но не предоставляющих конкретных наборов требований и критериев для тех или иных типов продуктов и систем ИТ, выполнение которых необходимо проверять. Эти требования и критерии фигурируют в профилях защиты (ПЗ) и заданиях по безопасности (ЗБ). Предполагается, что профили защиты, в отличие от заданий по безопасности, носят относительно универсальный характер: они характеризуют определенный класс изделий ИТ вне зависимости от специфики условий применения.

Именно официально принятые профили защиты образуют построенную на основе "Общих критериев" (ОК) и используемую на практике нормативную базу в области информационной безопасности (ИБ). В настоящее время такая база и в мире (см., например, [11], [12]), и в России только создается. В России эту работу курирует Государственная техническая комиссия при Президенте РФ (Гостехкомиссия России). Представляется, что анализ разрабатываемых профилей, произведенный на относительно ранней стадии, является вполне своевременным и, более того, весьма важным, поскольку позволяет выявить только намечающиеся тенденции, взять на вооружение положительный опыт и попытаться избежать типичных ошибок. Вообще говоря, профили защиты могут характеризовать отдельные сервисы безопасности, комбинации подобных сервисов, реализованные, например, в операционной системе, а также прикладные изделия ИТ, для которых обеспечение информационной безопасности критически важно (пример - смарт-карты).

Нас в первую очередь будут интересовать профили защиты сервисов безопасности, поскольку последние являются универсальными строительными блоками, позволяющими формировать защитные рубежи информационных систем (ИС) различного назначения, разной степени критичности. В работах В.Б. Бетелина и В.А. Галатенко (см., например, [13]) были выделены следующие базовые сервисы безопасности:

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

Общие требования к сервисам безопасности

Если придерживаться объектно-ориентированного подхода, то целесообразно выделить, по крайней мере, два уровня в иерархии наследования требований к сервисам безопасности:

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

Общие предположения безопасности

Предположения безопасности являются частью описания среды, в которой функционирует объект оценки. Можно выделить следующие общие предположения.

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

Общие угрозы безопасности

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

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

Общие элементы политики безопасности

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

Общие цели безопасности для объекта оценки

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

Общие цели безопасности для среды

Цели безопасности для среды дополняют цели безопасности объекта оценки и состоят в следующем.

Общие функциональные требования

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

Класс FAU: Аудит безопасности

Для сервисов безопасности предусматриваются следующие требования по протоколированию и аудиту.

Класс FCS: Криптографическая поддержка

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

Класс FDP: Защита данных пользователя

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

Класс FIA: Идентификация и аутентификация

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

Класс FMT: Управление безопасностью

Управление - важнейший аспект информационной безопасности, а требования управления, несомненно, принадлежат к числу общих.

Только администратор должен иметь возможность определения ограничений размеров регистрационных журналов, сроков действия учетных записей субъектов доступа, паролей, криптографических ключей, числа неудачных попыток аутентификации, интервалов бездействия пользователей (FMT_MTD.2.1). При выходе за допустимые границы должны выполняться определенные администратором действия, такие как сигнализация администратору, блокирование или удаление учетной записи, запрос на смену пароля или ключа и т.д. (FMT_MTD.2.2). Следует обеспечить присваивание данным функций безопасности только безопасных значений (FMT_MTD.3.1).

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

Класс FPR: Приватность

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

Класс FPT: Защита функций безопасности

Собственная защищенность - важная характеристика любого сервиса безопасности. В число общих входят следующие требования. Тестирование абстрактной машины (FPT_AMT.1). Для демонстрации выполнения предположений безопасности, обеспечиваемых абстрактной машиной, положенной в основу сервиса безопасности, при запуске и/или по запросу администратора должен выполняться пакет тестовых программ (FPT_AMT.1.1).

Класс FTA: Доступ к объекту оценки

Требования данного класса направлены на обеспечение защищенности от агрессивного потребления ресурсов.

Класс FTP: Доверенный маршрут/канал

Обеспечение защищенного взаимодействия сервисов безопасности в распределенной среде - одно из важнейших общих требований.

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

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

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

В число требований доверия третьего оценочного уровня входят:

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

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

Специфические требования к сервисам безопасности

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

Управление доступом

Профиль защиты для дискреционного управления доступом

Дальнейшее изложение основано на первой редакции проекта [14] "Контролируемый доступ. Профиль защиты" (ПЗ КД), подготовленного в Центре безопасности информации. Его прототип [15], базирующийся на версии 2.0 "Общих критериев", был подготовлен в 1999 году в Агентстве национальной безопасности США и лег в основу сертификации многих продуктов ИТ, в том числе операционной системы Windows 2000.

В принципе ПЗ КД соответствует классу безопасности C2 "Оранжевой книги" [16] или пятому классу защищенности по классификации Гостехкомиссии России для средств вычислительной техники [17], однако применение методологии и обширного набора требования безопасности из "Общих критериев" позволило сделать профиль, по сравнению с упомянутыми документами, существенно более детальным и обоснованным.

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

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

Профиль защиты для мандатного управления доступом

В данном подразделе рассматривается первая редакция проекта [18] "Меточная защита. Профиль защиты" (ПЗ МЗ), подготовленного в Центре безопасности информации (см. также [19]). ПЗ МЗ соответствует классу безопасности B1 "Оранжевой книги" [16] или четвертому классу защищенности по классификации Гостехкомиссии России для средств вычислительной техники [17].

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

Ролевое управление доступом

Ролевое управление доступом (Role-Based Access Control, RBAC) представляет собой универсальный каркас, нейтральный по отношению к конкретной дисциплине разграничения доступа и предназначенный в первую очередь для упрощения администрирования информационных систем с большим числом пользователей и различных ресурсов.

Ниже рассматриваются специфические требования для профиля RBAC [20], [21], основанного на версии 2.0 "Общих критериев".

Разделение обязанностей - существенная и специфичная для ролевого управления доступом цель безопасности. Возможность ее достижения - важное достоинство ролевого доступа.

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

Функциями, специфичными для ролевого управления доступом, являются:

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

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

Межсетевые экраны

Для межсетевых экранов (МЭ) разработан целый ряд профилей защиты и проектов таких профилей (см. [22] [23] [24] [25] [26]). Отметим, что экранирование - это, видимо, единственный сервис безопасности, для которого Гостехкомиссия России одной из первых в мире разработала и ввела в действие Руководящий документ [27], основные идеи которого получили международное признание и фигурируют в профилях защиты, имеющих официальный статус в таких странах, как США.

Межсетевые экраны классифицируются на основании уровней эталонной семиуровневой модели, на которых осуществляется фильтрация потоков данных.

Пакетная фильтрация

Дальнейшее изложение основывается на профиле [24], как наиболее представительном среди документов аналогичного назначения.

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

Информация, поступающая в МЭ, может предназначаться для фильтрации или для изменения параметров самого МЭ. В первом случае идентификация/аутентификация не требуется, во втором она является обязательной, причем должны использоваться одноразовые пароли (идентифицироваться и аутентифицироваться должны как операторы, осуществляющие удаленное администрирование, так и устройства, такие как маршрутизаторы, посылающие информацию для МЭ, например, измененные таблицы маршрутизации). Для формального описания перечисленных требований используются компоненты FMT_MSA.1 (управление атрибутами безопасности), FMT_MSA.3 (статическая инициализация атрибутов) и FIA_UAU.5 (сочетание механизмов аутентификации).

Поскольку "Общие критерии" не предназначены для оценки специфических качеств криптографических алгоритмов, рассматриваемый профиль ссылается на федеральный стандарт США FIPS PUB 140-1, требуя согласованности с ним для средств аутентификации, шифрования и контроля целостности. Формальной оболочкой для данного требования является компонент ОК FCS_COP.1.

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

Выборочный просмотр регистрационной информации (FAU_SAR.3.1) может основываться на адресах, диапазонах адресов, номерах портов, диапазонах дат и времени.

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

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

Следует также отметить, что чисто пакетные фильтры практически никогда не являются собственно межсетевыми экранами (исключая может быть средства отечественного производства), а составляют часть ПО в операционных системах (как ip-chains в Linux) или специализированном ПО активного сетевого оборудования (как Cisco IOS).

Комплексное экранирование

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

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

В правилах фильтрации могут фигурировать команды протоколов прикладного уровня и параметры команд. В проекте профиля [25] требуется полное управление межсетевым доступом (компонент FDP_ACC.2), а также предотвращение угроз доступности (FDP_IFC.2.1).

Важным моментом проекта [25] являются требования анонимности (FPR_ANO.1.1), псевдонимности (FPR_PSE.1) и невозможности ассоциации (FPR_UNL.1.1) межсетевого доступа для сущностей, ассоциированных с защищаемой сетью или самим межсетевым экраном. Эти требования могут быть выполнены на основе использования механизма трансляции адресов и применения серверов-посредников.

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

Шифрование и контроль целостности необходимы для организации доверенного канала с целью обеспечения безопасности удаленного администрирования (соответствующие требования были рассмотрены ранее в числе общих для различных сервисов). Для них существуют российские ГОСТы, которыми можно воспользоваться при построении аналогов профилей [22] и [24]. Аутентификация, устойчивая к сетевым угрозам, также обязательна, однако для нее национальный криптографический ГОСТ отсутствует. Приходится, как это сделано в [25], ограничиваться общими требованиями верификации секретов (FIA_SOS.1) и защищенности от подделки (FIA_UAU.3). Впрочем, в любом случае привлечение национальных (а не международных) стандартов создает проблемы взаимодействия с иностранными партнерами и взаимного признания сертификатов разными странами.

Системы активного аудита

В работе [28] приведен набросок семейства профилей защиты для классификации систем активного аудита, а также соображения по расширению набора функциональных требований "Общих критериев". Проекты ПЗ для важнейших компонентов подобных систем - анализатора и сенсора - представлены в [29], [30]">.

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

Назначение активного аудита - оперативно выявлять подозрительную активность и предоставлять средства для автоматического реагирования на нее.

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

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

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

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

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

С целью адекватного отражения специфики средств активного аудита, в [28] предложен ряд добавлений к стандартному набору функциональных требований.

В семейство FAU_GEN (генерация данных аудита безопасности) предлагается включить два новых компонента. FAU_GEN.3 - ассоциирование объекта, операция с которым вызвала событие, с включением в регистрационные записи имени (идентификатора) этого объекта. На минимальном уровне должны протоколироваться открытие/закрытие объекта (установление/разрыв соединения и т.п.), на базовом - все промежуточные операции. На детальном уровне в регистрационные записи должны входить все операнды операции с объектом. Компонент FAU_GEN.3 добавлен по двум причинам. Во-первых, должна соблюдаться симметрия между субъектами и объектами. Во-вторых, статистические профили целесообразно строить не для субъектов, а для объектов, но для этого нужно располагать соответствующей информацией. Еще один предлагаемый компонент - FAU_GEN.4 - предназначен для обеспечения неотказуемости сервиса, пользующегося услугами семейства FAU_GEN, от регистрации события. Вообще говоря, неотказуемость реализуется безотносительно к использованию коммуникаций, поэтому здесь нельзя воспользоваться классом FCO.

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

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

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

FAU_SAA.1 ориентирован на обнаружение превышения порогов, заданных фиксированным набором правил.

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

FAU_SAA.3 направлен на выявление простых атак путем проведения сигнатурного анализа.

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

В [28] вводится еще один компонент, FAU_SAA.5, позволяющий выявлять нарушения политики безопасности. Задавать политики предлагается с помощью предикатов первого порядка.

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

Это значит, что решатель должен уметь:

Оба аспекта должны управляться администратором безопасности.

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

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

Мониторы, как организующие оболочки для менеджеров средств активного аудита, должны обладать двумя группами свойств:

Первая группа обслуживается семейством FPT_SEP.

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

В плане безопасности целесообразно следовать требованиям FPT_FLS.1 (невозможность перехода в небезопасное состояние в случае сбоя или отказа), а также FPT_RCV.2, FPT_RCV.3, FPT_RCV.4 (надежное восстановление в автоматическом режиме, без потери данных, с точностью до функции безопасности).

Безопасность интерфейсов монитора (с другими мониторами, сенсорами, администратором безопасности) может обеспечиваться компонентами FPT_ITI.1, FPT_ITI.2 (обнаружение и исправление модификации экспортируемых данных), FPT_ITC.1 (конфиденциальность экспортируемых данных), FPT_ITA.1 (доступность экспортируемых данных).

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

При формировании классификационной схемы средств активного аудита в [28] предлагается выделить базовый (минимальный) ПЗ, а дополнительные требования компоновать в функциональные пакеты.

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

ПЗ, соответствующие классам защищенности, строятся на основе базового ПЗ и соответствующих комбинаций ФП.

В [28] предлагается зафиксировать профили для следующих разновидностей средств активного аудита:

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

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

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

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

Анонимизаторы

Анонимизаторы предназначены для выполнения функциональных требований приватности (класс FPR "Общих критериев"). В данном разделе, основываясь на статье [31] и профиле защиты [32], мы рассмотрим одну из разновидностей анонимизаторов - сеть серверов пересылки, обеспечивающую приватность пользователей электронной почты.

Вероятно, приватность - это единственный класс функциональных требований ОК, направленных не на обеспечение безопасности иерархически организованных, жестко администрируемых систем, а на защиту специфических интересов пользователей информационных сервисов. В "Оранжевой книге" Министерства обороны США и Руководящих документах Гостехкомиссии России подобных требований не было, поэтому опыт по их применению необходимо нарабатывать, что придает работам [31] и [32] особую ценность. Происходит становление так называемой многоаспектной информационной безопасности, когда делается попытка учесть весь спектр интересов (порой конфликтующих между собой) всех субъектов информационных отношений, а также все виды конфигураций ИС, в том числе децентрализованные, не имеющие единого центра управления.

Как известно (см., например, [33]), класс FPR содержит четыре семейства: FPR_ANO (анонимность - возможность совершать действия, не раскрывая идентификационных данных пользователя), FPR_PSE (псевдонимность - анонимность с сохранением подотчетности), FPR_UNL (невозможность ассоциации - анонимность с сокрытием связи между действиями одного пользователя), FPR_UNO (скрытность или ненаблюдаемость - сокрытие самого факта использования ресурса или услуги).

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

Сеть серверов пересылки почты состоит из независимо администрируемых узлов.

Отправитель определяет путь сообщения в этой сети. Само сообщение шифруется таким образом, что каждому серверу пересылки известны только предыдущий и следующий узлы. В результате достигается невозможность установления ассоциации между отправителем и получателем. Если в сообщении отсутствуют идентификационные данные отправителя, обеспечиваются анонимность, невозможность ассоциации и, отчасти, скрытность. Псевдонимность может быть реализована путем использования особым образом заданных обратных адресов. Отметим, что на тех же принципах могут быть реализованы анонимизаторы для других информационных сервисов, в частности, для Web-доступа. Существуют свободно распространяемые (Mixmaster) и коммерческие (компании Zero Knowledge Systems) реализации сетей серверов пересылки.

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

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

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

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

Формулируются два специфических положения политики безопасности.

Специфические цели безопасности для среды:

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

В пределах области действия функций безопасности имеют место следующие виды операций:

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

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

Специфические функциональные требования состоят в следующем.

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

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

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

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

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

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

Авторы работ [31] [32] справедливо замечают, что введение новых функциональных требований имеет свои оборотные стороны. Конкретные профили получаются проще, естественнее, однако сравнение профилей с нестандартными компонентами усложняется. Возможный выход подсказывает технология программирования, предусматривающая проблемно-ориентированные расширения базовых интерфейсов, как это сделано, например, в Java-системах [34]. Подобные расширения можно разработать и стандартизовать быстрее, чем полный набор требований, поскольку они затрагивают более узкий круг специалистов, объединенных к тому же общностью интересов.

Выпуск и управление сертификатами

В документе [35] предлагается упорядоченное семейство из четырех профилей защиты для аппаратно-программных компонентов, реализующих выпуск, аннулирование и управление сертификатами открытых ключей (удовлетворяющими, например, спецификациям X.509) (Certificate Issuing and Management Components, CIMC).

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

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

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

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

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

Переходя к специфическим функциональным требованиям безопасности для среды, отметим выделение в [35] четырех ролей:

В соответствии с компонентом FMT_SMR.2 (ограничения на роли безопасности), один пользователь не может выступать более чем в одной из перечисленных выше ролей (FMT_SMR.2.3). Среда должна обеспечить защиту конфиденциальности данных пользователя при передаче между функциями безопасности (FDP_UCT). Более точно должна быть обеспечена базовая конфиденциальность обмена данными (FDP_UCT.1). Аналогичная защита должна обеспечиваться для конфиденциальных данных самой среды (FPT_ITC.1, FPT_ITT.1). Кроме того, требуется контроль целостности данных.

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

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

Требования доверия безопасности усиливаются параллельно с возрастанием выбранного уровня профиля защиты. Для верхнего, четвертого уровня используются в основном требования ОУД4 и, частично, ОУД5, а также требование ALC_FLR.3 (систематическое устранение недостатков), не входящее ни в один ОУД.

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

Анализ защищенности

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

Предлагается ввести новый класс функциональных требований - FPA: анализ защищенности. В нем может быть три семейства.

Семейство FPA_HLP может состоять из одного компонента.

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

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

Семейство FPA_RAD может состоять из одного компонента.

Семейство FPA_SPA может состоять из трех компонентов.

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

Специфические требования к комбинациям и приложениям сервисов безопасности

Операционные системы

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

Для операционных систем разработан целый ряд профилей защиты (см. [38] [39] [40] [41] [42] [43]). К этой же группе документов можно отнести руководство по разработке профилей для перспективных коммерческих продуктов ИТ [44], поскольку оно, как и [38] [39] [40] [41], ориентировано на класс безопасности C2 "Оранжевой книги".

Мы, однако, рассмотрим проект [42] (адаптированный вариант профиля [43]), в целом соответствующий третьему классу защищенности по классификации Гостехкомиссии России для средств вычислительной техники, поскольку он более представителен с точки зрения требований безопасности.

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

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

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

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

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

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

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

Документация анализа должна содержать описание всех предположений, сделанных в процессе анализа скрытых каналов (AVA_CCA_EXP.1.3C). Документация анализа должна содержать описание метода, используемого для оценки пропускной способности канала для случая наиболее опасного сценария (AVA_CCA_EXP.1.4C). Документация анализа должна содержать описание наиболее опасного сценария использования каждого идентифицированного скрытого канала (AVA_CCA_EXP.1.5C). Оценщик должен подтвердить, что представленная информация удовлетворяет всем требованиям к содержанию и представлению свидетельств (AVA_CCA_EXP.1.1E). Оценщик должен подтвердить, что результаты анализа скрытых каналов показывают, что криптографический модуль удовлетворяет функциональным требованиям (AVA_CCA_EXP.1.2E). Оценщик должен выборочно подтвердить правильность результатов анализа скрытых каналов, применяя тестирование (AVA_CCA_EXP.1.3E).

Можно видеть, что в проекте профиля [42] вопросы криптографии изложены весьма пространно, однако смысл всех требований предельно прост: соответствие национальным стандартам (их три) и требованиям ФАПСИ. На наш взгляд, целесообразно выделить требования к криптографическим модулям в отдельный документ, как это сделано в федеральном стандарте США FIPS PUB 140-2 [36], а не перегружать ими профиль защиты ОС.

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

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

Отдельного рассмотрения заслуживают специфические функциональные требования, присутствующие в проекте [38]. Выше, в разделе "Системы активного аудита", мы отмечали важность требований к интерфейсам и их безопасности. В [38] предложен дополнительный элемент FAU_GEN.1-CSPP.3, предписывающий предоставление прикладного программного интерфейса для добавления собственных данных к общему регистрационному журналу и/или для ведения приложениями собственных журналов.

Для управления экспортом данных пользователя в соответствии с политикой безопасности введен элемент FDP_ETC.1-CSPP.3, предусматривающий выделение отдельного пула выходных каналов (например, путем резервирования номеров TCP-портов), недоступных обычным приложениям.

Для поддержки распределенных конфигураций предлагается целый ряд дополнительных требований, направленных на обеспечение конфиденциальности (FPT_ITC.1.1-CSPP), целостности (FPT_ITI.1.1-CSPP), согласованности (FPT_SYN-CSPP.1.1) критичных данных функций безопасности. В заключение этого подраздела следует отметить, что в Центре безопасности информации разработан проект базового профиля защиты для ОС и разрабатывается профиль защиты ОС в средах, требующих высокую робастность (защищенность), с тем, чтобы иметь завершенное семейство профилей защиты операционных систем.

Системы управления базами данных

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

Дальнейшее изложение основано на проекте ПЗ [45] (его прототип [46] соответствует классу безопасности C2 "Оранжевой книги").

В проекте вводится понятие аутентификационного пакета, который предоставляет для СУБД механизм подтверждения подлинности заявляемого идентификатора пользователя.

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

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

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

Эта возможность в проекте [45] не рассматривается.

Переходя к функциональным требованиям безопасности, укажем на важность требований согласованности данных между функциями безопасности (FPT_TDC), а также согласованности данных функций безопасности при дублировании в пределах распределенного объекта оценки (FPT_TRC). Согласованность может достигаться с помощью некоторой формы обработки распределенных транзакций или путем обновления дублируемых данных с использованием какого-либо протокола синхронизации. К сожалению, требования этих семейств в проекте [45] не представлены, равно как и требования распределенности хранения и обработки для повышения устойчивости к отказам. Конечно, в "Оранжевой книге" ничего подобного не было, однако в наше время, как показывает профиль [32], следование определенным архитектурным принципам является обязательным.

Для защиты от атак на доступность в рассматриваемом проекте предусмотрены реализация квот, выделяемых пользователям (FRU_RSA.1), а также базовые ограничения на параллельные сеансы (FTA_MCS.1).

В целом, на наш взгляд, при доработке проекта [45] необходимо учесть специфику современных СУБД, в частности, требования обеспечения динамической целостности данных, реализуемые механизмом транзакций. Требования безопасного восстановления носят слишком общий характер. Защита от стандартных угроз, существующих в сетевой среде, целиком переложена на базовую систему. Не учтены специфические для СУБД угрозы, описанные, например, в главе "Информационная безопасность систем управления базами данных" книги [47].

Виртуальные частные сети

Комбинация туннелирования и шифрования (наряду с необходимой криптографической инфраструктурой) на выделенных шлюзах и экранирования на маршрутизаторах поставщиков сетевых услуг (для разделения пространств "своих" и "чужих" сетевых адресов в духе виртуальных локальных сетей) позволяет реализовать такое важное в современных условиях защитное средство, как виртуальные частные сети. Подобные сети, наложенные обычно поверх Интернет, существенно дешевле и гораздо безопаснее, чем действительно собственные сети организации, построенные на выделенных каналах. Коммуникации на всем их протяжении физически защитить невозможно, поэтому лучше изначально исходить из предположения об уязвимости и соответственно обеспечивать защиту. Современные протоколы, поддерживающие спецификации IPsec (см., например, [48]), позволяют сделать это.

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

В качестве основы последующего изложения выбран проект профиля защиты [49]. В нем объектом оценки является совокупность опорных узлов. Требования к перспективным средствам аналогичного назначения представлены в документе [50].

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

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

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

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

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

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

Виртуальные локальные сети

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

Использование виртуальных локальных сетей позволяет:

Разграничение потоков данных обеспечивается путем фильтрации кадров данных.

Таким образом, объект оценки по сути оказывается межсетевым экраном канального уровня.

В проекте [51] рассматриваются следующие варианты построения виртуальных локальных сетей.<ul><li>Группировка портов объекта оценки. В этом случае каждый такой порт поддерживает только одну виртуальную сеть.</li><li>Использование специальной метрики для определения принадлежности к конкретной виртуальной локальной сети.</li></ul> Впрочем, предлагаемые в проекте требования безопасности в равной степени применимы к обоим вариантам.

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

Смарт-карты

Профиль защиты для смарт-карт [52] интересен необычностью объекта оценки. Он позволяет оценить гибкость и разнообразие требований "Общих критериев".

Необычность смарт-карт как объекта оценки заключается в следующем:

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

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

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

Предположения безопасности для среды состоят в данном случае в следующем.

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

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

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

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

Перейдем к рассмотрению специфических функциональных требований.

Для требований доверия безопасности в [52] используется усиленный оценочный уровень 4. Усиление обеспечивают компоненты AVA_VLA.3 (систематический поиск уязвимостей, обеспечение стойкости к нападениям, выполняемым нарушителем с умеренным потенциалом) и ADV_INT.1 (модульность).

Важным достоинством работы [52] является выделение двух функциональных пакетов: для интегральной схемы и базового ПО. Эти части могут разрабатываться независимыми производителями, поэтому целесообразно дать им возможность независимой же сертификации, оставив за интегратором (производителем смарт-карт) выбор поставщиков и интегральную сертификацию. В части функциональных требований пакет для базового ПО аналогичен рассмотренному профилю; к аппаратуре предъявляется меньшее число требований. Например, в функциональном пакете для интегральной схемы отсутствуют компоненты FAU_SAA.1 (анализ потенциального нарушения) и FPT_RPL.1 (обнаружение повторного использования), что представляется вполне естественным.

Заключение

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

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

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

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

Еще один технологический аспект - модульность ПЗ. Выделение функциональных пакетов для составных частей объекта оценки, реализованное в работе [52], дает больше свободы и разработчикам, и интеграторам, способствует раннему выявлению и устранению проблем, облегчает работу оценщиков.

Следующий вопрос касается технологии сопровождения множества профилей защиты.

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

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

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

Таким образом, проведенный анализ позволяет наметить следующие направления дальнейших исследований и разработок:

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

Литература

[1] Information technology - Security techniques - Evaluation criteria for IT security -Part 1: Introduction and general model. -- ISO/IEC 15408-1.1999.
[2] Information technology - Security techniques - Evaluation criteria for IT security -Part 2: Security functional requirements. -- ISO/IEC 15408-2.1999.
[3] Information technology - Security techniques - Evaluation criteria for IT security -Part 3: Security assurance requirements. -- ISO/IEC 15408-3.1999.
[4] ГОСТ Р ИСО/МЭК 15408-1-2002. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 1. Введение и общая модель. -- М.: ИПК Издательство стандартов, 2002
[5] ГОСТ Р ИСО/МЭК 15408-2-2002. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные требования безопасности. -- М.: ИПК Издательство стандартов, 2002
[6] ГОСТ Р ИСО/МЭК 15408-3-2002. Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Требования доверия к безопасности. -- М.: ИПК Издательство стандартов, 2002
[7] Гостехкомиссия России. Руководящий документ. Безопасность информационных технологий. Критерии оценки безопасности информационных технологий. -- Москва, 2002
[8] Information technology - Security techniques - Guide for Production of Protection Profiles and Security Targets. Version. 0.9. -- ISO/IEC PDTR 15446, January 4, 2000
[9] Гостехкомиссия России. Руководство по разработке профилей защиты и заданий по безопасности (проект). -- Москва, 2002
[10] Гостехкомиссия России. Руководящий документ. Руководство по регистрации профилей защиты (проект). -- Москва, 2002
[11] Web-сервер с материалами по "Общим критериям"
[12] "Общие критерии" на сервере Национального института стандартов США.
[13] В.Б. Бетелин , В.А. Галатенко -- Информационная (компьютерная) безопасность с точки зрения технологии программирования. - Труды 4-й Ежегодной конференции консорциума ПрМ "Построение стратегического сообщества через образование и науку". с. 38-44. -- М.: МГУ им. М.В. Ломоносова, 2001
[14] Безопасность информационных технологий. Контролируемый доступ. Профиль защиты (первая редакция). -- Центр безопасности информации, 2002
[15] Controlled Access Protection Profile. Version 1.d. -- U.S. Information Systems Security Organization. U.S. National Security Agency, 8 October 1999
[16] Department of Defense Trusted Computer System Evaliation Criteria. -- DoD 5200.28-STD, 1985
[17] Гостехкомиссия России. Руководящий документ. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации. -- Москва, 1992
[18] Безопасность информационных технологий. Меточная защита. Профиль защиты (первая редакция). -- Центр безопасности информации, 2002
[19] Labeled Security Protection Profile. Version 1.b. -- U.S. Information Systems Security Organization. U.S. National Security Agency, 8 October 1999
[20] Reynolds J., Chandramouli R. Role-Based Access Control Protection Profile Version 1.0, July 30, 1998
[21] Rational for RBAC Protection Profile. Version 1.0, July 30, 1998.
[22] W., Jansen , J. Walsh -- Draft U.S. Government Application-Level Firewall Protection Profile for Low-Risk Environments. Version 1.b., September, 1998
[23] W., Jansen , J. Walsh , K. Dolan , P. Wright -- Final U.S. Government Traffic-Filter Firewall Protection Profile for Low-Risk Environments. Version 1.1., April, 1998.
[24] K. Dolan , P. Wright , R. Montequin , B. Mayer , L. Gilmore , C. Hall -- Final U.S Department of Defense Traffic-Filter Firewall Protection Profile For Medium Robustness Environments. Version 1.4. -- U.S. National Security Agency, May 1, 2000.
[25] Профиль защиты для межсетевых экранов корпоративного уровня. -- Инфосистемы Джет, 2002
[26] Профиль защиты для межсетевых экранов провайдерского уровня. -- Инфосистемы Джет, 2002
[27] Гостехкомиссия России. Руководящий документ. Средства вычислительной техники. Межсетевые экраны. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации. -- Москва, 1997
[28] В.Б. Бетелин , А.В. Галатенко , В.А. Галатенко , М.Т. Кобзарь , А.А. Сидак -- Классификация средств активного аудита в терминах "Общих критериев". - В сб. "Информационная безопасность. Инструментальные средства программирования. Базы данных" под ред. чл.-корр. РАН В.Б. Бетелина. с. 4-26. -- М.: НИИСИ РАН, 2001
[29] Intrusion Detection System Analyser Protection Profile. Draft 3. -- U.S. National Security Agency. Science Applications International Corporation. Center for Information Security Technology, September 15, 2000
[30] Intrusion Detection System Sensor Protection Profile. Draft 3. -- U.S. National Security Agency. Science Applications International Corporation. Center for Information Security Technology, September 15, 2000
[31] K. Rannenberg , G. Iachello -- Protection Profiles for Remailer Mixes - Do the New Evaluation Criteria Help? - Proceedings of the 16th Annual Computer Security Applications Conference (ACSAC'00). pp. 107-118. -- IEEE Press, 2000
[32] Iachello G. User-Oriented Protection Profile for Unobservable Message Delivery using MIX networks, Revision 2.4., June 6, 1999
[33] А.П. Трубачев , М.Ю. Долинин , М.Т. Кобзарь , А.А. Сидак , В.И. Сороковиков -- Оценка безопасности информационных технологий. Под общей редакцией В.А. Галатенко. -- М.: СИП РИА, 2001
[34] А. Таранов , В. Цишевский -- Java в три года. -- Jet Info, 11-12, 1998
[35] A. Lee -- Certificate Issuing and Management Components Family of Protection Profiles. Version 1.0. -- U.S. National Security Agency, October 31, 2001
[36] FIPS PUB 140-2: Security Requirements for Cryptographic Modules. -- U.S. Department of Commerce, NIST, May, 25, 2001  [37] Cryptographic Module Validation Program
[38] Stoneburner G. CSPP-OS - COTS Security Protection Profile - Operating Systems. Draft Version 0.4. -- U.S. Department of Commerce, NIST, February 5, 2001
[39] Stoneburner G. Rationale for CSPP - COTS Security Protection Profile - Operating Systems. Draft Version 0.4. -- U.S. Department of Commerce, NIST, February 5, 2001
[40] Безопасность информационных технологий. Одноуровневые операционные системы в средах, требующих среднюю робастность. Профиль защиты (вторая редакция). -- Центр безопасности информации, 2002
[41] Protection Profile For Single-level Operating Systems In Environments Requiring Medium Robustness. Version 1.22. -- Information Systems Assurance Directorate. U.S. National Security Agency, 23 May 2001
[42] Безопасность информационных технологий. Многоуровневые операционные системы в средах, требующих среднюю робастность. Профиль защиты (вторая редакция). -- Центр безопасности информации, 2002
[43] Protection Profile for Multilevel Operation Systems in Environments Requiring Medium Robustness. Version 1.22. -- Information Systems Assurance Directorate. U.S. National Security Agency, 23 May 2001
[44] Stoneburner G. CSPP - Guidance for COTS Security Protection Profiles. Version 1.0. NISTIR 6462. -- U.S. Department of Commerce, NIST, December, 1999
[45] Безопасность информационных технологий. Система управления базой данных. Профиль защиты (первая редакция). -- Центр безопасности информации, 2002
[46] Database Management System Protection Profile. Version 2.1., May, 2000
[47] Галатенко В.А. Информационная безопасность - практический подход. Под ред. В.Б. Бетелина. -- М.: Наука, 1998
[48] В. Галатенко , М. Макстенек , И. Трифаленков -- Сетевые протоколы нового поколения -- Jet Info, 7-8, 1998
[49] Средства построения виртуальных частных вычислительных сетей. Защита от несанкционированного доступа к информации. Базовый профиль защиты (проект, редакция 01). -- МИФИ, 2002
[50] M. Sheridan , E. Sohmer , R. Varnum -- A Goal VPN Protection Profile For Protecting Sensitive Information. Release 2.0. -- U.S. National Security Agency, 10 July, 2000
[51] Средства построения виртуальных локальных вычислительных сетей. Защита от несанкционированного доступа к информации. Базовый профиль защиты (проект, редакция 01). -- МИФИ, 2002
[52] Smart Card Protection Profile (SCSUG-SCPP). Version 3.0. -- Smart Card Security User Group, 9 September 20

 
Подробно о лучших книгах

Новинки, Классика, Базы данных, Internet/WWW, Сети, Программирование, UNIX, Windows, Безопасность, Графика, Software Engineering, ERP-системы, Hardware

Новые поступления в on-line библиотеку:

6 августа 2003 года

  • Черводинамика
  • Некоторые методы разрешения проблем мутации
  • Стандарт CobiT. Управление и аудит информационных технологий. Особенности проведения внешнего аудита ИТ.
  • Безопасность Web-сервисов
  • Множественная диспетчеризация

    4 августа 2003 года

  • Настройка сервера базы данных Oracle и Linux
  • Переменные связывания и совместное использование курсоров: новые тенденции в СУБД Oracle9i
  • Автоматизация: от идеи до утилизации
  • Расширяемая платформа добычи текстов
  • Восстановление паролей к PWL-файлам

    30 июля 2003 года

  • Linux HOWTO

    28 июля 2003 года

  • Ниша и внедрение CASE-средств
  • Google PR0 PageRank
  • Файловая система и менеджер томов Veritas

    25 июля

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

    23 июля

  • Профили защиты на основе "Общих критериев". Аналитический обзор
  • Вопросы обеспечения безопасности корпоративных беспроводных сетей стандарта 802.11. Специфика России.
  • PostgreSQL FAQ
  • Возможности PostgreSQL
  • Сборка PostgreSQL из исходных текстов и установка

    21 июля

  • Применение формальных методов для тестирования реализации IPv6
  • Архитектура современной информационно-аналитической системы

    16 июля

  • OLAP-средства и Web-технологии
  • Обзор OLAP-продуктов для Web
  • Web-сервисы на службе у Business Intelligence
  • PLM - не роскошь, а необходимость
  • Оценка эффективности ИТ-инвестиций

    Предыдущие новости >>>

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