.RU

6. Лекция: Профили защиты, разработанные на основе "Общих критериев". Часть 2. Частные требования к сервисам безопасности


^ 6. Лекция: Профили защиты, разработанные на основе "Общих критериев". Часть 2. Частные требования к сервисам безопасности Биометрическая идентификация и аутентификация
Системы биометрической идентификации и аутентификации, общие сведения о которых можно найти в курсе [91] "Основы информационной безопасности", весьма актуальны и интересны с точки зрения оценки их безопасности. В данном разделе рассматривается профиль защиты [30], разработанный специалистами Министерства обороны США для оценки коммерческих продуктов, применяемых в среде со средними требованиями к безопасности.

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

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

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

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

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

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

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

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

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

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

Выделим ряд специфических функциональных требований:
^ Требования к произвольному (дискреционному) управлению доступом
Дальнейшее изложение основано на первой редакции проекта [1] Руководящего документа Гостехкомиссии России "Безопасность информационных технологий. Контролируемый доступ. Профиль защиты" (ПЗ КД), подготовленной в Центре безопасности информации. Его прототип [38], базирующийся на версии 2.0 "Общих критериев", был разработан в 1999 году в Агентстве национальной безопасности США.

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

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

Из числа частных функциональных требований ПЗ КД выделим наиболее важные:

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

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

Перечислим специфичные для ПЗ МЗ функциональные требования:

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

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

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

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

Для ролевого управления доступом характерны следующие функции:

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

Требования безопасности при сбое (семейство 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] предлагается зафиксировать профили для следующих разновидностей средств активного аудита:

В контексте "Общих критериев" важным и сложным является поднятый в [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].

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

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

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

Перечислим специфические цели безопасности:

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

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

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

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

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

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

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

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

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

Авторы работ [74], [48] справедливо замечают, что введение новых функциональных требований имеет свои оборотные стороны. Конкретные профили получаются проще, естественнее, однако их сравнение с нестандартными компонентами усложняется. Возможный выход подсказывает технология программирования, предусматривающая проблемно-ориентированные расширения базовых интерфейсов, как это выполнено, например, в Java-системах [27]. Подобные расширения можно разработать и стандартизовать быстрее, чем полный набор требований, поскольку они затрагивают более узкий круг специалистов, объединенных к тому же общностью интересов.
^ Выпуск и управление сертификатами
В документе [66] предлагается упорядоченное семейство из четырех профилей защиты для аппаратно-программных компонентов, реализующих выпуск, аннулирование и управление сертификатами открытых ключей (удовлетворяющими, например, спецификациям X.509) (Certificate Issuing and Management Components, CIMC).

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

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

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

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

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

Переходя к специфическим функциональным требованиям безопасности для среды, отметим выделение в [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).

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

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

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

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

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

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

Семейство FPA_RAD может располагать одним компонентом:

В семействе FPA_SPA возможно присутствие трех компонентов:

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

afganistan-bolit-v-moej-dushe.html
afganskaya-vojna-stalina-bitva-za-centralnuyu-aziyu-afganskaya-vojna-nachalas-dlya-sssr-ne-v-1979-godu-kogda-sovetskie-vojska-voshli-v-afganistan-a-na-60-let-ran-stranica-22.html
afganskaya-vojna-stalina-bitva-za-centralnuyu-aziyu-afganskaya-vojna-nachalas-dlya-sssr-ne-v-1979-godu-kogda-sovetskie-vojska-voshli-v-afganistan-a-na-60-let-ran-stranica-40.html
afgryaznov-kak-vozmozhna-pravilosoobraznaya-deyatelnost-filosofskie-idei-lyudviga.html
afina-funkcii-eyo-kulta-otobrazhenie-eyo-obraza-v-drevnegrecheskom-iskusstve.html
afinskij-sud-i-ugolovnij-process-chast-3.html
  • upbringing.bystrickaya.ru/koordinaciya-deyatelnosti-mbou-sosh-20-po-poiskovo-prosvetitelskoj-ekspedicii-imya-kubani.html
  • ekzamen.bystrickaya.ru/rossijskij-dokumentalnij-film-v-nebe-russkie-vityazi.html
  • kolledzh.bystrickaya.ru/avtoritet-rukovoditelya-chast-3.html
  • doklad.bystrickaya.ru/v-sankt-peterburge-zakrilsya-punkt-obogreva-bezdomnih-s-molotka-ushli-gitara-kostnera-i-kniga-kinga-15.html
  • zanyatie.bystrickaya.ru/razvitie-narodnogo-hozyajstva-sssr-v-poslevoennij-period.html
  • studies.bystrickaya.ru/giena-vostochnoj-evropi-vojna-i-mi-voennoe-delo-glazami-grazhdanina.html
  • kontrolnaya.bystrickaya.ru/raspisanie-zanyatij-studentov.html
  • upbringing.bystrickaya.ru/metodicheskie-rekomendacii-po-normirovaniyu-truda-professorsko-prepodavatelskogo-sostava-obrazovatelnih-uchrezhdenij-visshego-professionalnogo-obrazovaniya-federalnoj-sluzhbi-ispolneniya-nakazanij-stranica-9.html
  • obrazovanie.bystrickaya.ru/primernaya-programma-naimenovanie-disciplini-gigiena-zhivotnih-rekomenduetsya-dlya-napravleniya-podgotovki-specialnosti.html
  • kontrolnaya.bystrickaya.ru/realizaciya-vospitatelnogo-potenciala-vneurochnoj-deyatelnosti-shkolnikov-srednego-i-starshego-zvena.html
  • lecture.bystrickaya.ru/bektld-kegoc-a-basarmasini.html
  • education.bystrickaya.ru/4-energosbitovaya-deyatelnost-plan-komplektovaniya-uchebnih-grupp-na-2009-god-chast-2.html
  • pisat.bystrickaya.ru/tematicheskoe-planirovanie-kursa-3-klass.html
  • znanie.bystrickaya.ru/4-uchebno-tematicheskij-plan-disciplini-uchebno-metodicheskij-kompleks-disciplini-anatomiya-fiziologiya-i-patologiya.html
  • uchebnik.bystrickaya.ru/uchebno-metodicheskij-kompleks-po-discipline-istori-ografiya-istorii-rossii-specialnost-050401-istoriya.html
  • student.bystrickaya.ru/10-klass-himiko-biologicheskij-profil.html
  • literatura.bystrickaya.ru/roza-majskaya-roza-maialis-zadachami-issledovaniya-yavlyayutsya-sleduyushie.html
  • shkola.bystrickaya.ru/uchebnij-plan-s-14-22-sistema-vneurochnoj-deyatelnosti-i-dopolnitelnogo-obrazovaniya-s-23-27-upravlenie-realizaciej-obrazovatelnoj-programmi-s-28-29-stranica-7.html
  • letter.bystrickaya.ru/obyazatelni-li-rodovie-boli-net-test-d-pirsona-schitaj-do-10-mame-nado-bit-silnoj.html
  • doklad.bystrickaya.ru/uchebnoe-posobie-k-laboratornim-rabotam-po-discipline-cifrovie-vichislitelnie-ustrojstva-i-mikroprocessori-pribornih-kompleksov.html
  • turn.bystrickaya.ru/osuzhdenie-eretikov-v-p-pazilovoj-oformlenie-perepleta-hudozhnika-e.html
  • nauka.bystrickaya.ru/voprosi-dlya-podgotovki-k-ekzamenam-dlya-aspirantov-po-kursu.html
  • books.bystrickaya.ru/e-a-belov-bryan-gos-tehn-un-t-nauch-red-s-m-brundasov-bryansk-izd-vo-bgtu-2010-349-s-isbn-5-89838-495-1-90-r-84-k.html
  • report.bystrickaya.ru/i-e-leshev-glavnij-arhitektor-proekta.html
  • laboratornaya.bystrickaya.ru/programma-xl-i-h-mezhdunarodnoj-nauchnoj-studencheskoj-konferencii-student-i-nauchno-tehnicheskij-progress-16-20aprelya-2011g-stranica-3.html
  • laboratornaya.bystrickaya.ru/razdel-11-priglashenie-k-uchastiyu-v-aukcione-o-provedenii-otkritogo-aukciona-v-elektronnoj-forme.html
  • exam.bystrickaya.ru/vibuhov-rechovini-ta-zasobi-pdrivannya.html
  • essay.bystrickaya.ru/d-oklad-o-strategicheskih-prioritetah-dejstvij-dolgovr-emennoe-ispolzovanie-razvitie-i-sohranenie-geneticheskih-resursov-zhivotnih-dlya-prodovolstviya-i-selskogo-hozyajstva-stranica-7.html
  • student.bystrickaya.ru/21-procedura-zashiti-vipusknoj-kvalifikacionnoj-raboti-kompleks-trebovanij-k-vipuskniku-po-specialnosti-finansi.html
  • notebook.bystrickaya.ru/itogi-oblastnogo-konkursa-festival-tvorcheskogo-pisma-po-inostrannim-yazikam.html
  • ekzamen.bystrickaya.ru/rezultati-uchastiya-sostoyanie-i-razvitie-sistemi-obrazovaniya-v-2008-2009-uchebnom-godu.html
  • education.bystrickaya.ru/3317-podpis-dokumenta-instrukciya-po-deloproizvodstvu-v-gou-vpo-bashkirskij-gosudarstvennij-pedagogicheskij-universitet.html
  • college.bystrickaya.ru/28-fevralya-2006-g-n-33-ob-utverzhdenii-instrukcii-o-poryadke-realizacii-vzimaniya-podohodnogo-naloga-s-fizicheskih-lic-i-formah-nalogovogo-ucheta-stranica-15.html
  • klass.bystrickaya.ru/administrativnoe-upravlenie-glavnoe-arhivnoe-upravlenie-pri-sovete-ministrov-sssr.html
  • write.bystrickaya.ru/g-sochi-krasnaya-polyana-20-25-marta-2012-g-protokol-sorevnovanij.html
  • © bystrickaya.ru
    Мобильный рефератник - для мобильных людей.