Ролевое управление доступом
Ролевое управление доступом (Role-Based Access Control, RBAC) представляет собой универсальный каркас, нейтральный по отношению к конкретной дисциплине разграничения доступа и предназначенный в первую очередь для упрощения администрирования ИС с большим числом пользователей и различных ресурсов.
Ниже рассматриваются специфические требования для профиля RBAC [77], [75], основанного на версии 2.0 "Общих критериев".
Разделение обязанностей - существенная и специфичная для ролевого управления доступом цель безопасности. Возможность ее достижения - важное достоинство ролевого доступа.
Еще одна особая и методологически важная цель безопасности - организация иерархии ролей с наследованием прав доступа. Применение идей и методов объектно-ориентированного подхода необходимо для успешной работы с большими системами.
Для ролевого управления доступом характерны следующие функции:
создание и удаление ролей; создание, удаление и модификация атрибутов ролей и отношений между ролями;
формирование и поддержка ассоциаций между пользователями и ролями;
формирование и поддержка ассоциаций между правами доступа и ролями.
Эти функции обслуживаются тремя классами функциональных требований, на которых мы и остановимся:
ограниченное управление доступом (FDP_ACC.1.1). По крайней мере для части операций субъектов над объектами должно действовать ролевое управление доступом, которое в общем случае может существовать с другими дисциплинами разграничения доступа;
управление доступом, основанное на атрибутах безопасности (FDP_ACF.1.1). В число учитываемых атрибутов безопасности следует включить, помимо прочих, присвоенные субъекту роли и права доступа этих ролей;
управление данными функций безопасности (FMT_MTD). Только администратор должен иметь возможность определения и изменения ролей, их атрибутов, связей между ними и ограничений на подобные связи (FMT_MTD.1.1). Необходимы и другие требования класса FMT, но они в данном случае носят прямолинейный характер и рассматриваться не будут.
Требования безопасности при сбое (семейство FPT_FLS) имеют технический характер. Должно сохраняться безопасное состояние в ситуациях, когда база данных ролей недоступна или повреждена (FPT_FLS.1.1). Как и в случае управления безопасностью, другие требования этого класса необходимы, но не нуждаются в детальном рассмотрении.
Можно видеть, что функциональные требования "Общих критериев" полезны для достижения тактических целей безопасности. Стратегические цели, носящие концептуальный или архитектурный характер, - организация иерархии ролей с небольшим числом сущностей на каждом уровне или следование принципу разделения обязанностей - приходится формулировать отдельно, без стандартизованной понятийной базы.
Межсетевое экранирование
Для межсетевых экранов (МЭ) разработан целый ряд профилей защиты и проектов подобных профилей (см. [43], [60], [59], [23], [24]). Отметим, что экранирование - это, видимо, единственный сервис безопасности, для которого Гостехкомиссия России одной из первых в мире разработала и ввела в действие Руководящий документ [18], его основные идеи получили международное признание и фигурируют в профилях защиты, имеющих официальный статус в таких странах, как США.
Межсетевые экраны классифицируются на основании уровней эталонной семиуровневой модели, на которых осуществляется фильтрация потоков данных. Далее рассматриваются специфические требования двух видов профилей, соответствующих фильтрации на уровнях вплоть до транспортного (пакетная фильтрация) и на всех уровнях, включая прикладной (комплексное экранирование).
Изложение вопросов пакетной фильтрации основывается на профиле [43], наиболее представительном среди документов аналогичного назначения.
В общем случае рассматривается многокомпонентный межсетевой экран. Политика безопасности МЭ базируется на принципе "все, что не разрешено, запрещено".
Информация, поступающая в МЭ, может предназначаться для фильтрации или для изменения параметров самого МЭ. В первом случае идентификация/аутентификация не требуется, во втором она обязательна, причем используются одноразовые пароли (идентифицироваться и аутентифицироваться должны как операторы, осуществляющие удаленное администрирование, так и устройства, в частности маршрутизаторы, посылающие информацию для МЭ, например, измененные таблицы маршрутизации). Для формального описания перечисленных требований применяются компоненты 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. На наш взгляд, этого недостаточно для защиты критически важных систем, функционирующих в среде со средним уровнем риска.
Отметим, что за пределами рассмотрения в профиле остались такие технологические аспекты, как согласованность базы правил фильтрации для многокомпонентных конфигураций, удобство административного интерфейса (необходимое условие уменьшения числа ошибок администрирования), защита от атак на доступность.
Переходя к вопросам комплексного экранирования, отметим, что современные комплексные межсетевые экраны, осуществляющие фильтрацию на всех уровнях, включая прикладной, по сравнению с пакетными фильтрами обеспечивают более надежную защиту, что нашло отражение в дополнительных требованиях безопасности, включенных в профили [59] и [23], [24].
В состав комплексных межсетевых экранов могут входить серверы-посредники, они требуют от пользователей соответствующих сетевых услуг (таких, например, как FTP или Telnet) идентификации и аутентификации (с помощью механизмов, основанных на данных одноразового использования и соответствующих компоненту FIA_UAU.4).
В правилах фильтрации могут фигурировать команды протоколов прикладного уровня и параметры команд.
В проекте профиля [23] предписывается организация полного управления межсетевым доступом (компонент FDP_ACC.2), а также предотвращение угроз доступности (FDP_IFC.2.1).
Важным моментом проекта [23] являются требования анонимности (FPR_ANO.1.1), псевдонимности (FPR_PSE.1) и невозможности ассоциации (FPR_UNL.1.1) межсетевого доступа для сущностей, ассоциированных с защищаемой сетью или самим межсетевым экраном. Эти требования могут быть выполнены на основе использования механизма трансляции адресов и применения серверов-посредников.
Пример проекта [23] показывает, что в российских условиях можно обойти формальные, но не содержательные, проблемы, связанные с криптографией. В любом случае криптографические аппаратные и программные модули необходимо разрабатывать и/или оценивать, даже если само слово "криптография" в профиле защиты отсутствует.
Шифрование и контроль целостности необходимы для организации доверенного канала с целью обеспечения безопасности удаленного администрирования (соответствующие требования были рассмотрены ранее в числе общих для различных сервисов). Для них существуют российские ГОСТы, которыми можно воспользоваться при построении аналогов профилей [43] и [59]. Аутентификация, устойчивая к сетевым угрозам, также обязательна, однако национальный криптографический ГОСТ для нее не принят. Приходится, как это сделано в [23], ограничиваться общими требованиями верификации секретов (FIA_SOS.1) и защищенности от подделки (FIA_UAU.3). Впрочем, в любом случае привлечение национальных (а не международных) стандартов создает проблемы взаимодействия с иностранными партнерами и осложняет взаимное признание сертификатов разными странами.
Системы активного аудита
В работе [6] приведен набросок семейства профилей защиты для классификации систем активного аудита, а также соображения по расширению набора функциональных требований "Общих критериев". Проекты ПЗ для важнейших компонентов подобных систем - анализатора и сенсора - представлены в [57], [58].
Под подозрительной активностью понимается поведение пользователя или компонента информационной системы - злоумышленное (в соответствии с заранее определенной политикой безопасности) или нетипичное (согласно принятым критериям).
Назначение активного аудита - оперативно выявлять подозрительную активность и предоставлять средства для автоматического реагирования на нее.
По целому ряду причин, из числа которых мы выделим обеспечение масштабируемости, средства активного аудита строятся в архитектуре менеджер/агент. Основными агентскими компонентами являются компоненты извлечения регистрационной информации (сенсоры). Анализ, принятие решений - функции менеджеров. Очевидно, между менеджерами и агентами должны быть сформированы доверенные каналы.
В число функций безопасности, специфичных для средств активного аудита, входят генерация и извлечение регистрационной информации, ее анализ и реагирование на подозрительную активность.
Отметим, что такой универсальный аспект, как безопасное администрирование, для средств активного аудита приобретает особое значение, если включить в него автоматическую коррекцию (в первую очередь - пополнение) базы сигнатур атак. Тем не менее, соответствующие требования целесообразно отнести к числу общих, поскольку аналогичная возможность нужна, например, другому сервису безопасности - анализу защищенности.
Из существенных для активного аудита компонентов класса FAU "Аудит безопасности" в "Общих критериях" отсутствуют анализ на соответствие политике безопасности (пороговый, статистический и сигнатурный анализы в семействе FAU_SAA предусмотрены), хранилища для описаний контролируемых объектов и для анализируемой информации, а также все интерфейсные компоненты. Слабо отражена возможность выбора рассматриваемых событий как сенсорами (агентами), так и анализаторами (менеджерами).
С целью адекватного отражения специфики средств активного аудита в [6] предложен ряд добавлений к стандартному набору функциональных требований.
В семейство 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 позволяет выявлять сложные, многоэтапные атаки, осуществляемые группой злоумышленников.
Предусматривается возможность настройки всех четырех компонентов путем добавления, модификации или удаления правил, отслеживаемых субъектов и сигнатур.
В [6] вводится еще один компонент, FAU_SAA.5, фиксирующий нарушения политики безопасности. Задавать политики предлагается с помощью предикатов первого порядка.
Что касается автоматического реагирования на подозрительную активность, то "Общие критерии", по сути, ограничились констатацией подобной возможности. В [6] рассматривается более сложная сущность - решатель, который, получив рекомендации от компонентов анализа, определяет, действительно ли имеет место подозрительная активность, и, при необходимости, надлежащим образом реагирует (выбирая форму реакции в зависимости от серьезности выявленных нарушений).
Это значит, что решатель должен уметь:
ранжировать подозрительную активность;
реагировать в соответствии с рангом нарушения.
Управление обоими аспектами поручено администратору безопасности.
В качестве отдельной возможности, присущей системам высокого класса, фигурирует проведение корреляционного анализа информации.
Описание контролируемых объектов и хранение соответствующей информации - важнейшая составная часть средств активного аудита, придающая им свойства расширяемости и настраиваемости. К этому компоненту предъявляются главным образом технологические требования.
Мониторы, организующие оболочки для менеджеров средств активного аудита, должны обладать двумя группами свойств:
обеспечивать защиту процессов, составляющих менеджер , от злоумышленных воздействий;
обеспечивать высокую доступность этих процессов.
Первая группа обслуживается семейством 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 (доступность экспортируемых данных).
На рабочем месте администратора безопасности необходимо иметь стандартные для средств управления функции: графический интерфейс, возможность настройки способа визуализации, уровня детализации и отбора отображаемых событий.
Специфичной для средств активного аудита является возможность получения объяснений от анализаторов и решателей по поводу обнаруженной подозрительной активности. Такие объяснения помогают выбрать адекватный способ реагирования.
При формировании классификационной схемы средств активного аудита в [23] предлагается выделить базовый (минимальный) ПЗ, а дополнительные требования компоновать в функциональные пакеты.
Профили защиты, соответствующие классам защищенности, строятся на основе базового ПЗ и соответствующих комбинаций ФП.
В [23] предлагается зафиксировать профили для следующих разновидностей средств активного аудита:
класс 5 - защита одного информационного сервиса с отслеживанием фиксированного набора характеристик и пороговым анализом (базовый ПЗ);
класс 4 - защита однохостовой конфигурации с произвольным набором информационных сервисов, отслеживанием сетевого трафика, системных и прикладных событий, пороговым и простым сигнатурным анализом в реальном масштабе времени;
класс 3 - защита сегмента локальной сети от многоэтапных атак при сохранении остальных предположений класса 4;
класс 2 - защита произвольной конфигурации с выявлением нетипичного поведения при сохранении остальных предположений класса 3;
класс 1 - наложение всех требований с возможностью обеспечения заданного соотношения между ошибками первого и второго рода.
В контексте "Общих критериев" важным и сложным является поднятый в [23] вопрос о целесообразности разработки и применения жестких классификационных схем для сервисов безопасности. С одной стороны, гибкость требований ОК такова, что на их основе можно разработать множество профилей защиты с минимальными требованиями, учитывающими специфику информационных систем и их окружения и позволяющими добиться необходимого уровня безопасности с минимальными затратами. С другой стороны, едва ли не все ИС имеют тенденцию к частым и многочисленным изменениям, способным нарушить истинность сделанных в ПЗ предположений безопасности. Слишком точная подгонка профилей защиты (равно как и характеристик ИС) опасна, у них должен быть запас прочности. В приведенной выше классификации предусмотрено изменение защищаемой конфигурации, поэтому заказчик может выбрать класс "на вырост".
Классификационная схема показывает способы усиления функций безопасности (для средств активного аудита это в первую очередь расширение спектра отслеживаемых параметров, повышение оперативности и усложнение методов анализа регистрационной информации), что важно при выборе подходящей реализации сервиса безопасности из большого числа доступных вариантов.
Наконец, наличие большого числа несравнимых между собой минимальных профилей создает проблемы и для производителей сервисов безопасности, поскольку вовлекает их в многочисленные процедуры сертификации. Конечно, при этом могут быть использованы результаты предыдущих испытаний, но у каждой процедуры все равно остается существенная постоянная часть (финансовая и временная).
Можно сделать вывод, что для совокупности профилей защиты целесообразно с самого начала планировать построение иерархии наследования с применением соответствующих функциональных пакетов. Часть узлов в этой иерархии (например, общие требования к сервисам безопасности) могут быть фиктивными в том смысле, что им не соответствуют профили для законченных изделий ИТ, однако они столь же необходимы, как и (обобщенные) интерфейсы в объектно-ориентированных системах.
Анонимизаторы
Анонимизаторы предназначены для выполнения функциональных требований приватности (класс FPR "Общих критериев"). В данном разделе, основываясь на статье [74] и профиле защиты [48], мы рассмотрим одну из разновидностей анонимизаторов - сеть серверов пересылки, обеспечивающую приватность пользователей электронной почты.
Вероятно, приватность - это единственный класс функциональных требований ОК, направленных не на обеспечение безопасности иерархически организованных, жестко администрируемых систем, а на защиту специфических интересов пользователей информационных сервисов. В "Оранжевой книге" Министерства обороны США и Руководящих документах Гостехкомиссии России подобных требований не было, поэтому необходимо накапливать опыт по их применению, что придает работам [74] и [48] особую ценность. Происходит становление так называемой многоаспектной информационной безопасности, когда делается попытка учесть весь спектр интересов (порой конфликтующих между собой) всех субъектов информационных отношений, а также все виды конфигураций ИС, в том числе децентрализованные, не имеющие единого центра управления.
Напомним, что класс FPR содержит четыре семейства: FPR_ANO (анонимность - возможность совершать действия, не раскрывая идентификационных данных пользователя), FPR_PSE (псевдонимность - анонимность с сохранением подотчетности), FPR_UNL (невозможность ассоциации - анонимность с сокрытием связи между действиями одного пользователя), FPR_UNO (скрытность, или ненаблюдаемость - сокрытие самого факта использования ресурса или услуги). Псевдонимность полезна, например, когда за многократное обращение к каким-то специфическим платным услугам полагаются скидки. Невозможность ассоциации позволяет защититься от раскрытия личности пользователя путем анализа профиля его поведения. Назначение семейств FPR_ANO и FPR_UNO очевидно.
Сеть серверов пересылки почты состоит из независимо администрируемых узлов. Отправитель определяет в ней путь сообщения, которое шифруется таким образом, что каждому серверу известны только предыдущий и следующий узлы. В результате достигается невозможность установления ассоциации между отправителем и получателем. Если в сообщении отсутствуют идентификационные данные отправителя, то обеспечиваются анонимность, невозможность ассоциации и, отчасти, скрытность. Псевдонимность может быть реализована путем применения особым образом заданных обратных адресов. Отметим, что на тех же принципах организуется работа анонимизаторов для других информационных сервисов, в частности, для Web-доступа. Существуют свободно распространяемые (Mixmaster) и коммерческие (компании Zero Knowledge Systems) реализации сетей серверов пересылки.
Сеть серверов пересылки можно рассматривать двояко: изнутри и извне. Традиционный взгляд изнутри, с точки зрения гипотетического администратора сети, обязанного обеспечить ее безопасность и высокую доступность, ведет к традиционному же профилю защиты, требования которого противоречат приватности. Действительно, для защиты сети от атак на доступность необходимо выявлять подозрительную активность путем накопления и анализа регистрационной информации, уметь прослеживать пользователей и т.п. В силу указанных причин в данном разделе мы будем придерживаться взгляда извне, с точки зрения пользователя сервиса анонимизации; с этих позиций и разработан профиль [48].
Для сети серверов пересылки сообщений выделяются следующие специфические угрозы безопасности:
возможность установления ассоциации между отправителем и получателем, если путь сообщения проходит только через один сервер пересылки;
установление контроля над несколькими серверами пересылки и проведение совместного анализа их регистрационной информации.
Отметим также, что многие общие угрозы (маскарад сервера с целью распространения поддельных криптографических ключей, установление контроля над одним из серверов пересылки для извлечения необходимой конфиденциальной информации, перенаправление потоков данных с целью подмены части сети пересылки, анализ потоков данных между пользовательской системой и сетью пересылки и т.п.) приобретают в указанном контексте специфический характер, так как направлены на нарушение приватности пользователей.
Формулируются два специфических положения политики безопасности:
обеспечение анонимности сообщений, т. е. получатель не может узнать идентификационных данных отправителя, если последний сам не поместил их в сообщение в явном виде;
обеспечение невозможности прослеживать сообщения, т. е. в результате перехвата нельзя одновременно узнать отправителя и получателя.
Перечислим специфические цели безопасности:
серверы пересылки должны принимать и обрабатывать сообщения, не опираясь на какую-либо информацию об отправителе;
содержание сообщений на всем пути следования скрыто от сторонних наблюдателей;
сеть серверов пересылки необходимо построить таким образом, чтобы успешно противостоять попыткам анализа потоков данных, в частности, потоков между пользовательской системой и сетью;
сеть серверов пересылки следует построить с учетом того, чтобы пользователь мог (и, более того, был обязан) корректно распределять между узлами сети данные, существенные для невозможности прослеживания адресатов сообщения, а также выбирать узлы, участвующие в обработке сообщения. Сеть пересылки обязана реализовать пользовательский выбор;
пользователи и узлы сети пересылки должны однозначно идентифицироваться, а сообщения - доставляться в нужные узлы с сохранением конфиденциальности соответствующих данных;
сеть серверов пересылки должна быть построена так, чтобы использование, распространение и интервал времени доступности данных, влияющих на возможность ассоциации пользователей, были минимальными;
ни одному субъекту (пользователю, администратору, злоумышленнику) нельзя предоставлять возможность получения информации, достаточной для прослеживания отправителей сообщений.
Специфические цели безопасности для среды:
узлы сети пересылки должны администрироваться независимо и, более того, антагонистично;
сеть пересылки должна быть топологически распределенной.
Чтобы лучше понять приведенные ниже специфические функциональные требования, целесообразно помнить, что рассматриваемый профиль защиты сформирован с позиций пользователя, так что в объект оценки (ОО) входят как серверы пересылки, так и клиентские системы. Все потоки данных контролируются функциями безопасности ОО; экспорта или импорта данных не происходит.
В пределах области действия функций безопасности имеют место следующие виды операций:
передача сообщения клиентской системой серверу пересылки;
пересылка сообщений, а также управляющей информации (в том числе ключевой), между серверами;
доставка сообщения с сервера на клиентскую систему;
обработка сервером пересылки (транзитных) сообщений;
операции, выполняемые сервером с криптографическими ключами: генерация, распространение, хранение, доступ, использование, уничтожение;
порождение сервером пересылки фиктивных сообщений.
Для отправки сообщения пользователь должен задать целевой адрес и цепочку серверов пересылки. При получении почты требуется аутентификация, так как входящие сообщения нуждаются в расшифровании.
В пределах объекта оценки действует специфическая форма политики принудительного управления доступом, состоящая в том, что каждый элемент пользовательских данных приписывается определенному субъекту, и только этот субъект получает право на доступ к приписанным ему данным. Далее провозглашается политика борьбы со скрытыми каналами, чтобы противостоять попыткам анализа потоков данных.
Специфические функциональные требования состоят в следующем.
полное управление доступом (FDP_ACC.2). Политика принудительного управления доступом должна распространяться на всех субъектов (серверы пересылки, клиентское ПО, пользователи, администраторы), все объекты (в том числе на содержание и маршрутную информацию сообщений) и все операции;
ограниченное управление информационными потоками (FDP_IFC.1). Должна проводиться в жизнь политика борьбы со скрытыми каналами применительно к серверам пересылки, клиентскому ПО, сообщениям, передаче и приему сообщений (FDP_IFC.1.1);
частичное устранение неразрешенных информационных потоков (FDP_IFF.4). Политику борьбы со скрытыми каналами необходимо внедрять, чтобы уменьшить до заданных пределов утечку информации о работе пользователей с сетью пересылки, возникающую за счет анализа периферийных потоков данных (FDP_IFF.4.1). Получение профилей поведения компонентов сети пересылки путем анализа периферийных потоков данных должно быть невозможным (FDP_IFF.4.2);
полное управление временем хранения данных (FDP_IRC.2). Все объекты, нужные для нормальной работы сети пересылки, удаляются сразу после завершения операций с ними. Отметим, что это не просто специфическое, но новое функциональное требование, предложенное автором профиля защиты;
управление атрибутами безопасности (FMT_MSA.1). Согласно политике принудительного управления доступом, только пользователь, сгенерировавший данные, может выполнять операции над их атрибутами безопасности, в число которых входят маршрут сообщения и его рандомизация, минимальное число пересылок, число отправляемых избыточных сообщений, параметры потоков данных и криптографических алгоритмов и т.п. (FMT_MSA.1.1);
анонимность без запроса информации (FPR_ANO.2). Должны обеспечиваться невозможность определения подлинного имени отправителя сообщения, обрабатываемого сетью серверов пересылки (FPR_ANO.2.1), а также невозможность отслеживания и анонимность пересылки сообщений для всех пользователей без запроса какой-либо ссылки на подлинное имя пользователя (FPR_ANO.2.2);
размещение информационных ресурсов (FPR_TRD.2). Сеть пересылки должна состоять из отдельных взаимодействующих частей, в каждой из которых реализуются свои правила аутентификации и управления доступом (FPR_TRD.2.1). Доступ к данным другой части предоставляется только по явному запросу (FPR_TRD.2.2). Данные, критичные для невозможности ассоциации (маршрут, время и т.п.), должны храниться в виде, исключающем их полное чтение одной частью сети, чтобы обеспечить невозможность прослеживания всей цепочки между отправителем и получателем сообщения (FPR_TRD.2.3). Этот и два последующих компонента предложены автором профиля защиты;
распределение обработки сообщений (FPR_TRD.3). По своей сути этот компонент аналогичен предыдущему с точностью до замены слова "храниться" на "обрабатываться";
невозможность ассоциации пользователей (FPR_UNL.2). Должна обеспечиваться невозможность установления факта отправки сообщений одним и тем же пользователем.
Для мер доверия безопасности предлагается оценочный уровень 5. Напомним, что его характерными особенностями являются применение формальной модели политики безопасности, полуформальных функциональной спецификации и проекта верхнего уровня с демонстрацией соответствия между ними, а также проведение анализа скрытых каналов разработчиками и оценщиками. Это очень высокий уровень, но в данном случае его выбор представляется оправданным, поскольку, с одной стороны, объект оценки относительно прост, с легко формализуемой политикой безопасности, а с другой, в функциональных требованиях предусмотрен анализ скрытых каналов.
Рассмотренный профиль защиты, на наш взгляд, весьма поучителен. Он демонстрирует как достоинства, так и недостатки "Общих критериев". К числу достоинств можно отнести богатый набор современных функциональных требований, особо выделив требования приватности. К сожалению, как мы уже отмечали, они носят "точечный", а не концептуальный или архитектурный характер. Для требования распределенности архитектуры пришлось вводить новое семейство - FPR_TRD. Отметим, в свою очередь, что отнесение его к классу приватности не кажется нам оправданным. Распределенность принципиально важна для целого ряда систем, но если в системах электронных платежей, как и в сети серверов пересылки, это необходимое условие приватности (в профиле новое семейство получило наименование "распределения доверия"), то во многих других случаях она играет инфраструктурную роль, обеспечивая живучесть (устойчивость к отказам) и/или масштабируемость (в сочетании с архитектурой менеджер/агент). Очевидно, архитектурные требования заслуживают отдельного класса.
Требования безопасности повторного использования, безусловно, должны быть дополнены требованиями минимизации времени хранения объектов, что и сделано в рассмотренном профиле. Это важно, помимо приватности, практически для всех приложений криптографии, в ситуациях, когда образуются временные файлы с информацией ограниченного доступа и т.п.
Авторы работ [74], [48] справедливо замечают, что введение новых функциональных требований имеет свои оборотные стороны. Конкретные профили получаются проще, естественнее, однако их сравнение с нестандартными компонентами усложняется. Возможный выход подсказывает технология программирования, предусматривающая проблемно-ориентированные расширения базовых интерфейсов, как это выполнено, например, в Java-системах [27]. Подобные расширения можно разработать и стандартизовать быстрее, чем полный набор требований, поскольку они затрагивают более узкий круг специалистов, объединенных к тому же общностью интересов.
Выпуск и управление сертификатами
В документе [66] предлагается упорядоченное семейство из четырех профилей защиты для аппаратно-программных компонентов, реализующих выпуск, аннулирование и управление сертификатами открытых ключей (удовлетворяющими, например, спецификациям X.509) (Certificate Issuing and Management Components, CIMC).
Таким образом, перед нами жесткая классификационная схема , рассчитанная на применение в разнообразных средах. Каждый заказчик, учитывая степень критичности ИС и реальные риски, сам выбирает необходимый уровень защищенности и соответствующий ему профиль. На нижнем (первом) уровне потенциал злоумышленников и риски предполагаются низкими, прежде всего обеспечивается защита от случайных ошибок авторизованных пользователей (например, за счет использования принципа разделения обязанностей). При переходе на более высокие уровни угрозы нарастают, а требования ужесточаются. На верхнем (четвертом) уровне злоумышленниками могут быть и авторизованные пользователи, а требования безопасности оказываются настолько жесткими, что удовлетворить им могут только перспективные изделия ИТ. Это разумный подход, снабжающий ориентирами и заказчиков, и разработчиков.
Объект оценки в профилях из [66] является элементом инфраструктуры открытых ключей и в общем случае включает нижеследующие функциональные компоненты:
центр выпуска и аннулирования сертификатов (именуемый также удостоверяющим центром, УЦ). Это - ядро ОО. Сгенерированная информация помещается в хранилище (см. далее). Между различными УЦ могут существовать отношения доверия;
центры приема пользовательских запросов на создание сертификатов или изменение их статуса. Обязательные компоненты объекта оценки, которые верифицируют представленные пользователем данные;
серверы, обслуживающие протокол оперативной выдачи статуса сертификатов. Этот компонент может отсутствовать или находиться за пределами ОО;
серверы восстановления и/или распространения секретного ключевого материала - дополнительная функция.
Отметим, что хранилище сертификатов и информации об их статусе, обслуживающее запросы приложений, находится вне рамок ОО.
Помимо функциональных, в объект оценки входят инфраструктурные компоненты:
криптографический модуль. Он подписывает сертификаты и списки их аннулирования, при необходимости генерирует криптографические ключи. Требования безопасности, предъявляемые к криптографическим модулям, изложены в федеральном стандарте США FIPS PUB 140-2 [44], заменившем FIPS PUB 140-1 (см. [39]);
модуль администрирования;
модуль идентификации и аутентификации;
модуль ролевого управления доступом;
модуль протоколирования и аудита.
Представленная выше логическая компонентная архитектура не обязательно совпадает с физической структурой объекта оценки. В принципе возможна монолитная реализация ОО, объединение/расщепление компонентов и т.д.
Переходя к специфическим функциональным требованиям безопасности для среды, отметим выделение в [66] четырех ролей:
администратор (отвечает за установку, конфигурирование, обслуживание нужд пользователей и т.п.);
оператор (выполняет резервное копирование и восстановление);
инспектор (ведает запросами и утверждением сертификатов и их статуса);
аудитор (анализирует регистрационную информацию).
В соответствии с компонентом 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).
Среди специфических (более того, дополнительных, по сравнению с "Общими критериями") функциональных требований безопасности для объекта оценки выделим наиболее значимые:
инициирование и обработка события подписывания регистрационного журнала (FPT_CIMC_TSP.1), выполняемого с конфигурируемой периодичностью. Подпись должна контролировать целостность по крайней мере тех регистрационных записей, которые появились после предыдущего подписывания. В регистрационной записи о самом событии подписывания присутствуют электронная цифровая подпись, значение хэш-функции или имитовставка аналогичного назначения;
инициирование и обработка события постановки третьей стороной подписанных меток времени (FPT_CIMC_TSP.2). Этот компонент аналогичен предыдущему и обеспечивает дополнительный контроль целостности регистрационных данных (например, на случай компрометации объекта оценки);
резервное копирование и восстановление (FDP_CIMC_BKP.1), с дополнительными (криптографическими) мерами контроля целостности и обеспечения конфиденциальности (FDP_CIMC_BKP.2), с точностью до последней завершенной транзакции (FDP_CIMC_BKP.3). Названные компоненты направлены на безопасное (в том числе свободное от внедрения вредоносного кода) восстановление. Отметим, что подобные требования полезны также для СУБД и других систем с транзакциями;
принудительные доказательство и верификация подлинности источника данных о статусе сертификатов и других данных, критичных для безопасности (FCO_NRO_CIMC.3). Аналогично должны контролироваться заявки на регистрацию сертификатов. Предпочтительный способ доказательства подлинности - цифровые подписи (FCO_NRO_CIMC.4).;
экспортируемая информация об изменении статуса сертификатов должна иметь формат, описанный в спецификациях X.509 для списков аннулирования или RFC 2560 для протокола оперативной выдачи статуса сертификатов (FDP_CIMC_CSE.1);
защита конфиденциальности секретных ключей пользователей (FDP_ACF_CIMC.2) и функций безопасности (FMT_MTD_CIMC.4). Секретные ключи обслуживающего персонала и функций безопасности объекта оценки должны храниться в стандартном криптографическом модуле или шифроваться стандартными методами. Секретные ключи пользователей шифруются с помощью долговременных ключей защиты. Аналогичные требования предъявляются к хранению секретных ключей симметричных методов шифрования (FDP_ACF_CIMC.3 и FMT_MTD_CIMC.5);
секретные ключи должны экспортироваться либо в зашифрованном виде, либо с использованием процедур разделения знаний (FDP_ETC_CIMC.4, FDP_ETC_CIMC.5, FMT_MTD_CIMC.6, FMT_MTD_CIMC.7);
контроль целостности хранимых открытых ключей (FDP_DSI_CIMC.3). Открытые ключи, хранимые в объекте оценки вне криптографического модуля, нужно защитить от несанкционированного изменения стандартными криптографическими методами. Проверку целостности требуется производить при каждом доступе к ключу;
обнуление секретных ключей (FCS_CKM_CIMC.5). Функции безопасности должны обеспечить обнуление открытого представления секретных ключей в криптографическом модуле;
контроль допустимости значений полей сертификатов (FMT_MOF_CIMC.3). Функции безопасности контролируют значения полей сертификатов в соответствии с правилами, заданными администратором. Аналогичные проверки необходимо производить для списков аннулированных сертификатов (FMT_MOF_CIMC.5) и сообщений протокола оперативной выдачи статуса сертификатов (FMT_MOF_CIMC.6);
генерация сертификатов (FDP_CIMC_CER.1). Генерируются только корректные сертификаты, удовлетворяющие требованиям стандарта (X.509) и правилам, заданным администратором. Такие же требования должны выполняться для списков аннулированных сертификатов (FDP_CIMC_CRL.1) и сообщений протокола оперативной выдачи статуса сертификатов (FDP_CIMC_OCSP.1). До выпуска сертификата необходимо убедиться, что его предполагаемый владелец обладает секретным ключом, ассоциированным с открытым ключом из сертификата.
Требования доверия безопасности усиливаются параллельно с возрастанием выбранного уровня профиля защиты. Для верхнего, четвертого уровня используются в основном требования ОУД4 и, частично, ОУД5, а также требование ALC_FLR.3 (систематическое устранение недостатков), не входящее ни в один ОУД.
На наш взгляд, рассмотренное семейство профилей может служить примером при построении классификационных схем в Руководящих документах Гостехкомиссии России.
Анализ защищенности
Анализ защищенности - сравнительно новый, но весьма популярный сервис безопасности, помогающий реализовать профилактический подход к обеспечению защиты информационных систем. Суть его весьма проста, но "Общими критериями" он поддержан крайне слабо. Посмотрим, как можно изменить это положение.
Предлагается ввести новый класс функциональных требований - FPA: анализ защищенности. В нем может быть три семейства:
FPA_HLP: описание уязвимости, выдача рекомендаций по ее устранению;
FPA_RAD: автообнаружение контролируемых объектов;
FPA_SPA: анализ характеристик защищенности.
Семейство FPA_HLP может состоять из одного компонента:
FPA_HLP.1 - описание, выдача (возможно, с заданным уровнем детализации) сведений об уязвимостях, информация о которых содержится в базе данных системы анализа защищенности (эта база данных аналогична базе правил в компоненте анализа регистрационной информации FAU_SAA.1).
Для семейства FPA_HLP предусмотрено многократное использование (например, для выдачи сведений об атаках средствами активного аудита). Его роль сравнима с ролью комментариев в языках программирования; отсутствие подобного семейства, на наш взгляд, является методологической недоработкой авторов "Общих критериев". Выдача пояснений полезна не только для анализа защищенности, но и для выбора реакции на обнаруженную атаку. (Почему система анализа решила, что атака имеет место? Какие правила при этом сработали? Насколько серьезна обнаруженная атака? На все эти вопросы администратор безопасности должен получить оперативные, информативные ответы.)
Семейство FPA_RAD может располагать одним компонентом:
FPA_RAD.1 - автообнаружение компонентов анализируемой ИС, описание которых содержится в базе данных системы анализа защищенности.
В семействе FPA_SPA возможно присутствие трех компонентов:
FPA_SPA.1 - проверка наличия в системе и/или сети сущностей, указанных в базе данных системы анализа защищенности (имеются в виду небезопасные сервисы, такие, например, как TFTP);
FPA_SPA.2 - анализ характеристик выявленных сущностей (номеров версий, конфигурационных параметров, атрибутов доступа, слабых паролей - и здесь анализируется то, что перечислено в базе данных). Правила для анализа могут быть сложными, охватывающими несколько характеристик;
FPA_SPA.3 - проверка реакции объекта на выполнение определенных действий (имитация атак, перечисленных в базе).
Надеемся, что предлагаемый класс функциональных требований безопасности поможет в разработке профиля защиты для систем анализа защищенности.
|
