в момент s и в момент t,
При определенных условиях может оказаться опасным доступ от имени пользователя:
в момент s и в момент t, s
С некоторой избыточностью мы исчерпаем возможные каналы по памяти, если будем считать неблагоприятными какие-либо доступы p1,p2ÍR вида
, , (1)
которые мы и считаем каналами утечки.
Предположение 3. Если OÎD, то доступы в (1) при любых р1 и р2 не могут создать канал утечки.
Это значит, что мы предположили невозможным отразить какую-либо ценную информацию в объектах общего доступа. Это очень сильное предположение и оно противоречит, по крайней мере, возможности присваивать уникальные имена объектам. В самом деле, если объектам присвоены уникальные имена, то в D необходимо иметь информацию о уже присвоенных именах, что противоречит предположению 3 о том, что доступы от имени пользователей не отражаются в информации объектов общего пользования. В случае имен можно выйти из положения, используя случайные векторы, вероятности совпадения которых за обозримый период работы системы можно сделать как угодно малыми. Все построения и выводы возможны при стохастическом способе присвоения имен, но должны содержать элементы вероятностной конструкции. Чтобы не усложнять систему стохастическими элементами мы будем следовать сделанным выше предположениям.
Тогда в (1) достаточно ограничиться объектами О, не лежащими в D. Это значит, что в одном из доступов в (1) имеется , где OÎOt(Uj), . Таким образом, в системе считаются неблагоприятными доступы вида:
,
, OÎOt(Uj), . (2)
то есть доступы от имени какого-либо пользователя к объекту, созданному другим пользователем. Такие доступы будем далее называть утечкой информации.
Предположение 4. Если некоторый субъект S, SÎD, активизирован от имени пользователя Ui (т.e. ), в свою очередь субъекту S предоставлены в момент t доступ к объекту О, то либо OÎD, либо OÎOt(Ui), либо система прекращает работу и выключается. Определим следующую политику безопасности (ПБ):
Если , то при S,OÎOt(U) доступ разрешается, если SÎOt(Ui), OÎOt(Uj), i¹j, то доступ невозможен.
Теорема 1. Пусть в построенной системе выполняются предположения 1-4. Если все доступы осуществляются в соответствии с ПБ, то утечка информации (2) невозможна.
Доказательство. Предположим противное, то есть
Пусть S1,..., Sm - все активизированные субъекты, имеющие доступы bÊр, i=l,...,m, в момент t к объекту О. Тогда согласно лемме 2 множество этих субъектов разбивается на три непересекающиеся множества:
A = {S1|S1ÎD},
B = {S1|S1ÎOt(Ui)},
C = {S1|S1ÎOt(Uj),i¹j}.
Согласно лемме 1 для любого Sl, l=l.....m, существует единственный пользователь, от имени которого активизирован субъект Sl. Если S1ÎA, то согласно предположению 4 и условию теоремы 1, что доступ - разрешен, получаем, что S, активизирован от имени Uj. Это противоречит предположению.
Если S1ÎВ, то невозможен согласно политике безопасности. Значит, если , то существует цепочка длины (k+l)
,
и субъект .Тогда существует цепочка длины k такая, что
.
Повторяя эти рассуждения, через k шагов получим, что
.
Последний доступ невозможен, если выполняется ПБ. Поэтому предположение неверно и теорема 1 доказана.
Теперь построим удобное для реализации множество "услуг" более низкого уровня, поддерживающих ПБ. То есть мы хотим определить множество условий, реализованных в системе 2, таких, что можно доказать теорему о достаточности выполнения этих условий для выполнения правил ПБ.
Условие 1. (Идентификация и аутентификация). Если для любых tÎN, pÍR, S, ОÎОt, , то вычислены функции принадлежности S и О к множествам Оt(U1), Оt(U2), D.
Условие 2. (Разрешительная подсистема). Если SÎОt(Ui), OÎОt(Uj) и в момент t, то из i=j следует , и из i¹j следует (не разрешается доступ).
Условие 3. (Отсутствие обходных путей политики безопасности). Для любых tÎN, рÍR, если субъект S, активизированный к моменту t, получил в момент t доступ , то в момент t произошел запрос на доступ .
Теорема 2. Если в построенной системе å выполняются предположения 1-4 и условия 1-3, то выполняется политика безопасности.
Доказательство. Утверждение теоремы следует из двух утверждений:
а) Если для произвольного рÍR , SÎOt(Ui), OÎOt(Ui), то доступ разрешен.
б) Если SÎOt(Ui), OÎOt(Uj), i¹j, то какой-либо доступ в момент t субъекта S к объекту О невозможен.
Докажем а). Если , то по условию 1 вычислены функции принадлежности и определено, что SÎOt(Ui), OÎOt(Uj). Если i = j, то выполнена посылка условия 2. Тогда согласно условию 2 доступ разрешен.
Докажем теперь б). Если , вычислены функции принадлежности и определено, что SÎOt(Ui), OÎOt(Uj), i¹j. Тогда по условию 2 доступ не разрешен.
Если доступ стал возможен, минуя запрос , и S - активизирован к моменту t, то сделанное предположение противоречит условию 3. Если S - не активизирован, то наличие доступа противоречит определению доступа. Теорема доказана.
Теорема означает, что гарантировав выполнение условий 1-3, мы гарантируем выполнение политики безопасности.
Рассмотрим вопрос о создании системы, в которой можно с достаточной степенью уверенности поддерживать функции 1-3. Для этого рассмотрим следующую архитектуру:
1. В каждый момент только один пользователь может работать с системой. Физическое присутствие другого исключено.
2. При смене пользователей системы друг другом уходящий :
· записывает во внешнюю память все объекты, которые он хочет сохранить для дальнейших сеансов;
· выключает питание системы, после чего все содержимое оперативной памяти стирается, остаются записи на внешней памяти и ПЗУ, где хранятся объекты общего доступа.
3. Новый пользователь организует свою работу с включения системы и вызывает свои объекты из внешней памяти, опираясь на объекты общего пользования.
4. На шлюзе внешней памяти стоит шифратор К, который зашифровывает на текущем ключе k всю информацию, записываемую на внешнюю память, включая названия файлов. Наоборот, вся информация, поступающая из внешней памяти, расшифровывается на текущем ключе k. Внешняя память не имеет опции "просмотр директории", а любой запрос на выдачу файла функционирует так, что название запрашиваемого файла шифруется на текущем ключе k. При смене пользователей текущий ключ k автоматически стирается (вместе с содержимым оперативной памяти), а новый пользователь в качестве текущего устанавливает свой ключ.
Покажем, что функционирование системы данной архитектуры позволяет реализовать все описанные выше свойства и, в частности, выполнить условия теорем 1 и 2.
Предположение 1 и другие допущения в описании системы вполне приемлемы для рассматриваемой архитектуры. Так как неблагоприятные состояния системы и политики безопасности выражены в терминах доступов, то для приемлемости предположения 2 достаточно, чтобы возможные вычислительные процессы однозначно отражались в терминах последовательностей доступов и значений функций принадлежности объектов к множествам Оt(U1), Оt(U2),D. Если объект только создан и находится в оперативной памяти, то доступ к нему со стороны процессов от имени создавшего пользователя автоматически разрешен и можно считать, что функция принадлежности вычислена. Если объект вызван из внешней памяти, то сам вызов и доступ к информации в объекте возможны, если установлен правильный ключ, что эквивалентно вычислению функции принадлежности к Оt(U). Предположения 3 и 4 выполняются, так как вновь подключенный пользователь работает один и вызывает из ПЗУ функции и объекты D. В системе нет субъекта, реализующего разрешительную систему, она естественно реализована за счет того, что расшифрованная информация читается тогда и только тогда, когда в шифраторе К установлен нужный ключ. Если пользователь или процесс от его имени обращается за доступом к объекту на внешней памяти, то любой доступ разрешен, если ключ зашифрования объекта (ключ создателя объекта) совпадает с ключом текущего пользователя. Наоборот, при несовпадении ключей допуск автоматически не разрешается, так как имя объекта и его содержание не расшифровываются правильно.
Таким образом, автоматически вычисляются функции принадлежности процесса и объекта при обращении через внешнюю память, что обеспечивает выполнение условия 1. Также автоматически выполняется условие 2 о работе разрешительной системы. Условия 1 и 2 не касаются обращений процессов из D и к D. Поэтому вопросы идентификации здесь решаются за счет разделения сеансов пользователей и указанные условия выполняются.
Доступ к объекту возможен лишь при обращении к внешней памяти через шифратор, или в случае, когда объект создан в течение текущего сеанса, или вызван из ПЗУ. Если считать, что доступ к объектам в оперативной памяти автоматически опирается на данное пользователю разрешение на доступ к ним, а активизированными могут быть субъекты от его же имени, то можно считать, что любой доступ в этом случае выполняется в соответствии с условиями 1 и 2.
Что касается условия 3, то невозможность получить доступ минуя разрешительную систему определяется разнесенностью работы пользователей, отсутствием подслушивания, необходимостью расшифровывать информацию для получения доступа к ней. Это не касается объектов из D, или только созданных, где нет проблем из-за разнесенности сеансов. Также мы считаем, что отсутствует физическое проникновение и модификация системы.
В результате получим, что данная архитектура реализует условия теорем 1 и 2 и поддерживает политику безопасности.
Суммируем то, что обеспечивает гарантии в построенной системе (то есть, что поддерживает условия теорем 1 и 2):
· обеспечение работы только одного пользователя (охрана);
· отключение питания при смене пользователей;
· стойкость шифратора К и сохранность в тайне ключей каждого пользователя;
· недопустимость физического проникновения в аппаратную часть или подслушивание (охрана).
Известно, как обеспечивать эти требования, а гарантии их обеспечения являются гарантией защищенности системы в смысле выбранной политики безопасности.
Отметим некоторые стороны построенной модели, которые будут встречаться далее.
1) Гарантии построены при четкой политике безопасности.
2) Для поддержки политики потребовалась идентификация объектов (+ вычисление добавочной идентификационной функции).
3) Для поддержки политики потребовалась аутентификация субъекта, обращающегося за допуском.
4) Значительная часть условий определяет функциональную защищенность самой системы защиты.
Далее в обзоре "Оранжевой книги" мы встретим такие же условия.
4.3. «ОРАНЖЕВАЯ КНИГА» (ОК).
OK принята стандартом в 1985 г. Министерством обороны США (DOD). Полное название документа "Department of Defense Trusted Computer System Evaluation Criteria".
OK предназначается для следующих целей:
1. Предоставить производителям стандарт, устанавливающий, какими средствами безопасности следует оснащать свои новые и планируемые продукты, чтобы поставлять на рынок доступные системы, удовлетворяющие требованиям гарантированной защищенности (имея в виду, прежде всего, защиту от раскрытия данных) для использования при обработке ценной информации.
2. Предоставить DOD метрику для военной приемки и оценки защищенности ЭСОД, предназначенных для обработки служебной и другой ценной информации.
3. Обеспечить базу для исследования требований к выбору защищенных систем.
Рассматривают два типа оценки:
· без учета среды, в которой работает техника,
· в конкретной среде (эта процедура называется аттестованием).
В 1992 году Гостехкомиссия России издала от своего имени документы, аналогичные по задачам и содержанию ОК.
Во всех документах DOD, связанных с ОК, принято одно понимание фразы обеспечение безопасности информации. Это понимание принимается как аксиома и формулируется следующим образом: безопасность= контроль за доступом.
Аксиома. ЭСОД называется безопасной, если она обеспечивает, контроль за доступом информации так, что только надлежащим образом уполномоченные лица или процессы, которые функционируют от их имени, имеют право читать, писать, создавать или уничтожать информацию.
Из этой аксиомы вытекает шесть фундаментальных требований к защищенным ЭСОД. Прежде, чем их формулировать, напомним и введем некоторые определения.
Определение. Политика безопасности - это набор норм, правил и практических приемов, которые регулируют управление, защиту и распределение ценной информации в данной организации.
Определение. Идентификация - это распознавание имени объекта. Идентифицируемый объект есть однозначно распознаваемый.
Определение. Аутентификация это подтверждение того, что предъявленное имя соответствует объекту.
Определение. ТСВ (Trusted Computing Base) - совокупность механизмов защиты в вычислительной системе (включая аппаратную и программную составляющие), которые отвечают за поддержку политики безопасности.
Определение. Аудит или отслеживание, подотчетность - это регистрация событий, позволяющая восстановить и доказать факт происшествия этих событий.
Теперь сформулируем шесть основных требований.
ПОЛИТИКА
Требование 1 - Политика обеспечения безопасности - Необходимо иметь явную и хорошо определенную политику обеспечения безопасности. При задании идентифицированных субъектов и объектов необходимо иметь набор правил, используемых системой, для того, чтобы определить, можно ли разрешить указанному субъекту доступ к конкретному объекту. Представленные на аттестацию для использования в DOD вычислительные системы должны предусматривать реализацию мандатного контроля обеспечения безопасности, в рамках которого допускается эффективная реализация правил доступа, ориентированных на обработку конфиденциальной (например, секретной) информации. Эти правила включают такие требования: ни одно лицо, не обладающее надлежащим для допущенного персонала диапазоном полномочий, не получит доступа к секретной информации. Кроме того, также необходимы дискреционные (т.е. допускаемые по собственному усмотрению) средства управления безопасностью, которые гарантируют, что только выбранные пользователи или группы пользователей могут получить доступ к данным (реализация принципа "только те, которым необходимо знать").
Требование 2 - Маркировка - Метки, управляющие доступом, должны быть установлены и связаны с объектами. Для того, чтобы управлять доступом к информации в соответствии с правилами мандатной политики, должна быть предусмотрена возможность маркировать каждый объект меткой, которая надежно идентифицирует степень ценности объекта (например, секретности) и/или режимы допуска, предоставленные тем субъектам, которые потенциально могут запросить доступ к объекту.
ПОДОТЧЕТНОСТЬ.
Требование 3 - Идентификация - Субъекты индивидуально должны быть идентифицированы. Каждый доступ к информации должен быть рассмотрен на предмет того, кто запрашивает доступ к информации и на какие классы информации он имеет право получить доступ. Такого типа идентифицирующая и санкционирующая информация должна присутствовать и надежно защищаться вычислительной системой, а также быть связана с каждым активным элементом, выполняющим действия, имеющие отношение и к безопасности системы.
Требование 4 - Подотчетность - Аудиторская информация должна селективно храниться и защищаться так, чтобы со стороны ответственной за это группы имелась возможность отслеживать действия, влияющие на безопасность. Гарантированно защищенная система должна быть в состоянии регистрировать в аудиторском файле появление событий, имеющих отношение к безопасности системы. Возможность отбирать подлежащие регистрации отслеживаемые события необходима для того, чтобы сократить издержки на аудит и обеспечить эффективный анализ. Аудиторская информация должна быть защищена от модификации, несанкционированного уничтожения, чтобы позволять выявлять и "постфактум" исследовать нарушения правил безопасности.
ГАРАНТИИ.
Требование 5 - Гарантии - Вычислительная система в своем составе обязана иметь аппаратно-программные механизмы, допускающие независимую оценку для получения достаточного уровня гарантий того, что система обеспечивает выполнение изложенных выше требований с первого по четвертое. Для того, чтобы гарантировать, что указанные четыре требования по безопасности - политика, маркировка, идентификация и аудит - реализуются вычислительной системой, необходимо предусмотреть корректно определенный и объединенный в единое целое набор программных и аппаратных средств управления, реализующий указанные функции. Указанные механизмы стандартным образом встраиваются в операционную систему и проектируются так, чтобы выполнить порученные задачи безопасным образом. Основа гарантированности таких системных механизмов при задании исходных рабочих условий должна быть явно задокументирована так, что становится возможным независимый анализ доказательства достаточности проведенных оценок.
Требование 6 - Постоянная защита - Гарантированно защищенные механизмы, реализующие указанные базовые требования, должны быть постоянно защищены от "взламывания" и/или несанкционированного внесения изменений. Никакая вычислительная система не может считаться действительно безопасной, если базовые аппаратные и программные механизмы, реализующие принятую политику, сами могут быть подвергнуты несанкционированному внесению изменений или исправлений. Выполнение требований по непрерывной защите подразумевается в течение всего жизненного цикла вычислительной системы.
ИТОГОВАЯ ИНФОРМАЦИЯ ПО КЛАССАМ КРИТЕРИЕВ ОЦЕНКИ.
Классы систем, распознаваемые при помощи критериев оценки гарантированно защищенных вычислительных систем, определяются следующим образом. Они представлены в порядке нарастания требований с точки зрения обеспечения безопасности ЭВМ.
Класс (D): Минимальная защита. Этот класс зарезервирован для тех систем, которые были подвергнуты оцениванию, но в которых не удалось достигнуть выполнения требований более высоких классов оценок.
Класс (C1): Защита, основанная на разграничении доступа (DAC).
Гарантированно защищающая вычислительная база (ТСВ) систем класса (С1) обеспечивает разделение пользователей и данных. Она включает средства управления, способные реализовать ограничения по доступу, чтобы защитить проект или частную информацию и не дать другим пользователям случайно считывать или разрушать их данные. Предполагается, что среда класса (С1) является такой средой, в которой могут кооперироваться пользователи, обрабатывающие данные, принадлежащие одному и тому же уровню секретности.
ПОЛИТИКА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ.
ТСВ должна определять и управлять доступом между поименованными пользователями и поименованными объектами (например, файлами и программами) в системах автоматической обработки данных. Реализующий политику механизм (например, матрица доступа) должен позволять пользователям определять порядок и управлять использованием объектов поименованными лицами или определенными группами, а также теми и другими совместно.
ИДЕНТИФИКАЦИЯ И АУТЕНТИФИКАЦИЯ.
ТСВ должна требовать от пользователей, чтобы те идентифицировали себя перед тем, как начинать выполнять какие-либо действия, в которых ТСВ предполагается быть посредником. Более того, ТСВ обязательно должна использовать один из механизмов защиты (например, пароли) для того, чтобы проверять подлинность идентификации пользователей (аутентификация). ТСВ должна защищать аутентификационные данные таким образом, чтобы доступ к ним со стороны пользователя, не имеющего на это полномочий, был невозможен.
ГАРАНТИИ НА ПРАВИЛЬНУЮ РАБОТУ СИСТЕМЫ.АРХИТЕКТУРА СИСТЕМЫ.
ТСВ должна содержать домен, который должен обеспечивать ее собственную работу и защищать ее от внешнего воздействия или от внесения в нее несанкционированных изменений (например, от модификаций ее кодов или структур данных). Ресурсы, контролируемые ТСВ, могут составлять подмножество объектов ЭСОД.
ЦЕЛОСТНОСТЬ СИСТЕМЫ.
Должны быть предусмотрены аппаратные и/или программные средства, предназначенные для периодической проверки на правильность и корректность функционирования аппаратных и микропрограммных элементов ТСВ.
ГАРАНТИИ НА ЖИЗНЕННЫЙ ЦИКЛ. ТЕСТИРОВАНИЕ ФУНКЦИИ БОЗОПАСНОСТИ.
Механизм защиты должен соответствовать тем нормам, которые отражены в документации.
ДОКУМЕНТАЦИЯ.
1. Руководство пользователя по использованию средств обеспечения безопасности.
2. Руководство администратору системы на гарантированные средства защиты.
В руководстве, ориентированном на администратора системы автоматической обработки данных, должно содержаться описание мер предосторожности и полномочий, которые необходимо контролировать в процессе функционирования средства, имеющего отношение к обеспечению режима секретности.
3. Документация по тестам.
Разработчик системы должен предусмотреть для лиц, занятых оцениванием безопасности системы, документ, в котором дается описание плана тестирования, процедур тестирования, излагающих каким способом проверяются механизмы обеспечения безопасности, и где представлены итоговые результаты функционального тестирования механизмов обеспечения безопасности.
4. Документация по проекту. В наличии должна быть документация, в которой имеется описание основополагающих принципов защиты, выбранных изготовителем данного средства или системы, а также объяснение того, как эти принципы транслируются в гарантированно защищающую вычислительную базу. Если ТСВ составлена непосредственно из модулей, то должно быть дано описание интерфейсов между этими модулями.
Класс (С2): Защита, основанная на управляемом контроле доступом.
Все требования к классу (С1) переносятся на класс(С2). Кроме того, системы этого класса реализуют структурно более "тонкое" управление доступом, в сравнении с системами класса (С1), за счет дополнительных средств управления разграничением доступа и распространением прав, а также за счет системы регистрации событий (аудит), имеющих отношение к безопасности системы и разделению ресурсов. Специально вводится требование по "очищению" ресурсов системы при повторном использовании другими процессами.
Класс(BI): Мандатная защита, основанная на присваивании меток объектам и субъектам, находящимся под контролем ТСВ.
Требования для систем класса (В1) предполагают выполнение всех требований, какие были необходимы в классе (С2). Помимо этого, необходимо представить неформальное определение модели, на которой строится политика безопасности, присваивание меток данным и мандатное управление доступом поименованных субъектов к объектам. В системе необходимо иметь средство, которое позволяет точно и надежно присваивать метки экспортируемой информации.
Класс (B2): Структурированная защита. Все требования класса (В1) должны выполняться для системы класса (В2). В системах класса (В2) ТСВ основана на четко определенной и формально задокументированной модели, в которой управление доступом, распространяется теперь на все субъекты и объекты данной системы автоматической обработки данных. Помимо этого, должен быть проведен анализ, связанный с наличием побочных каналов утечек. Необходимо провести разбиение структуры ТСВ по элементам, критическим с точки зрения защиты, и некритическим, соответственно. Интерфейс ТСВ хорошо определен, а проект и реализация гарантированно защищающей вычислительной базы (ТСВ) выполнены так, что они позволяют проводить тщательное тестирование и полный анализ. Механизмы аутентификации усилены, управление защитой предусматривается в виде средств, предназначенных для администратора системы и для оператора, а на управление конфигурацией накладываются жесткие ограничения. Система относительно устойчива к попыткам проникновения в нее.
Класс (ВЗ): Домены безопасности.
Все требования для систем класса (B2) включены в требования к системам класса (ВЗ). ТСВ класса (ВЗ) должна реализовывать концепцию монитора обращений (RM):
· RM гарантированно защищен от несанкционированных изменений, порчи и подделки;
· RM обрабатывает все обращения;
· RM прост для анализа и тестирования на предмет правильности выполнения обработки обращений (должна быть полная система тестов, причем полнота должна быть доказана).
С этой точки зрения структура ТСВ выбирается такой, чтобы исключить коды, не существенные для реализации принятой политики обеспечения безопасности, одновременно с проработкой в процессе проектирования и реализации ТСВ системных инженерно-технических аспектов, направленных на минимизацию ее сложности. Предусматривается введение администратора безопасности системы, механизмы контроля (аудит) расширены так, чтобы обеспечить обязательную сигнализацию о всех событиях, связанных с возможным нарушением установленных в системе правил безопасности. Обязательным также является наличие процедур, обеспечивающих восстановление работоспособности системы. Система данного класса в высшей степени устойчива относительно попыток проникновения в нее.
Класс (AI): Верифицированный проект.
Системы этого класса (А1) функционально эквивалентны системам класса (ВЗ) в том отношении,
что в них не появляются какие-либо новые требования к политике обеспечения безопасности. Отличительной чертой систем данного класса является анализ ТСВ, основанный на формальной спецификации проекта и верификации ТСВ, а, в итоге, высокая степень уверенности в том, что гарантированно защищающая вычислительная база реализована правильно. Такого рода гарантия, по своей природе технологическая, начинается уже с формальной модели политики обеспечения безопасности и формальной спецификации проекта высокого уровня. Наряду с широким и глубоким анализом процесса проектирования и разработки ТСВ, который необходимо проводить для систем класса (А1), необходимо также выполнение более строгих мер по управлению конфигурацией и специальных процедур по безопасному размещению систем в местах их дислокации. Предусматривается введение администратора безопасности системы.
4.4. 0 ВЫБОРЕ КЛАССА ЗАЩИТЫ.
Продолжим изучение вопросов, связанных с американским стандартом защиты информации "Оранжевая книга". В предыдущем параграфе были определены семь классов систем защиты информации, причем требования в классах от С к А монотонно возрастали. Американцы не опубликовали детальный анализ риска, который определяет эти требования. Однако, одновременно со стандартом, был опубликован документ "Computer Security Requirements-Guidance for Applying the DoD Trusted Computer System Evaluation Criteria in Specific Environment" (далее будем называть его "Требования"), в котором изложен порядок выбора класса систем в различных условиях. Этот документ частично отражает результаты анализа риска, основания для выбора политики безопасности в связи с этими рисками и меры обеспечения гарантий соблюдения политики безопасности. Всюду далее предполагаем, что в информацию внесена MLS решетка ценностей. Выбор требуемого класса безопасности систем определяется следующими основными факторами, характеризующими условия работы системы.
1. Безопасность режима функционирования системы. Американцы различают 5 таких режимов:
а. Режим, в котором система постоянно обрабатывает ценную информацию одного класса в окружении, которое обеспечивает безопасность для работы с этим классом.
в. Режим особой секретности самой системы. Все пользователи и элементы системы имеют один класс и могут получить доступ к любой информации. Этот режим отличается от предыдущего тем, что здесь обрабатывается информация высших грифов секретности.
с. Многоуровневый режим, который позволяет системе обработку информации двух или более уровней секретности. Причем не все пользователи имеют допуск ко всем уровням обрабатываемой информации.
d. Контролирующий режим. Это многоуровневый режим обработки информации, при котором нет полной гарантии защищенности ТСВ. Это накладывает ограничения на допустимые классы ценной информации, подлежащей обработке.
е. Режим изолированной безопасности. Этот режим позволяет изолированно обрабатывать информацию различных классов или классифицированную и неклассифицированную информацию. Причем возможно, например, что безопасно обрабатывается только информация класса TS, а остальная информация не защищена вовсе.
2. Основой для выбора класса защиты является индекс риска. Он определяет минимальный требуемый класс.
Отобразим классы секретности в числа согласно таблице: U-0, С-1, S-2, TS-3. Эта таблица не совсем точно отражает соответствие из "Требований". Но здесь мы просто объясняем идею подхода. Определим Rmin - минимальный уровень допуска пользователя в системе, и Rmax - максимальный класс ценности информации, присутствующий в системе. В большинстве случаев индекс риска определяется по формуле:
Risk Index=Rmax-Rmin
Исключения касаются случая, когда , тогда
{ 1, если есть категории, к которым кто-либо из пользователей не имеет доступа
RiskIndex = {
{ 0, в противном случае
И также некоторые исключения есть в случае обработки TS-информации.
Пример 1. Если минимальный допуск пользователя в системе - С, а максимальный гриф обрабатываемой информации - S, то Rmin =2, Rmax=3. Тогда RiskIndex = l .
В результате учета всех ценностей и определения дополнительных классов у американцев получается восемь значений индекса риска от О до 7. Для этих значений индекса риска устанавливается следующее соответствие с минимальными требуемыми классами систем в случае, когда система функционирует во враждебном окружении.
RiskIndex
|
Безопасность режима функционирования
|
Минимальный класс по классификации “Оранжевой книги”
|
0
|
a
|
нет обязательного минимума
|
0
|
b
|
B1
|
1
|
c, d, e
|
B2
|
2
|
c, d, e
|
B3
|
3
|
c, d
|
A1
|
4
|
c
|
A1
|
5
|
c
|
*
|
6
|
c
|
*
|
7
|
c
|
*
|
Символ * означает, что в момент издания книги (1985 г.) минимальные требования по защите информации при данном значении индекса риска выше достигнутого уровня технологии.
Если система функционирует в окружении, которое можно назвать "безопасным периметром", то требования к минимальным классам значительно ниже.
Глава 5.Математические методы анализа политики безопасности.
Доказательство того факта, что соблюдение политики безопасности обеспечивает то, что траектории вычислительного процесса не выйдут в неблагоприятное множество, проводится в рамках некоторой модели системы. В этой главе мы рассмотрим некоторые модели и приведем примеры результатов, которые доказываются в данной области. В параграфе 5.1 рассматривается модель распространения прав доступа в системе с дискреционной политикой безопасности. Параграф 5.2 посвящен описанию модели Белла-Лападула и доказательству теоремы BST (основной теоремы безопасности для многоуровневых систем). К сожалению, полное описание модели Белла-Лападула остается секретным и недоступным. Поэтому приведенный вариант модели и теоремы касаются случая, когда уровень объекта не меняется. В параграфе 5.3 приводится пример (модель Low WaterMark), когда уровень объекта может меняться. В параграфе 5.4 описан подход Гогена и Месгауэра в моделировании безопасных систем. Наконец, в параграфе 5.5 приводится пример модели нарушителя, который используется при анализе политики аудита в реляционных базах данных.
5.1. МОДЕЛЬ "TAKE-GRANT" .
Будем по-прежнему описывать функционирование системы при помощи графов доступов Gt и траекторий в фазовом пространстве V={G}. Единственное дополнение - правила преобразования графов. Будем считать, что множество доступов R={r, w, c} , где r - читать, w - писать, с - вызывать. Допускается, что субъект X может иметь права aÍR на доступ к объекту Y, эти права записываются в матрице контроля доступов. Кроме этих прав мы введем еще два: право take (t) и право grant (g), которые также записываются в матрицу контроля доступов субъекта к объектам. Можно считать, что эти права определяют возможности преобразования одних графов состояний в другие. Преобразование состояний, то есть преобразование графов доступов, проводятся при помощи команд. Существует 4 вида команд, по которым один граф доступа преобразуется в другой.
1. Take. Пусть S - субъект, обладающий правом t к объекту X и aÍR некоторое право доступа объекта X к объекту Y. Тогда возможна команда "S take a forY from X". В результате выполнения этой команды в множество прав доступа субъекта S к объекту Y добавляется право a. Графически это означает, что, если в исходном графе доступов G был подграф
то в новом состоянии G', построенном по этой команде t, будет подграф
2. Grant. Пусть субъект S обладает правом g к объекту X и правом aÍR к объекту Y. Тогда возможна команда "S grant a for Y to X". В результате выполнения этой команды граф доступов G преобразуется в новый граф G', который отличается от G добавленной дугой (Х Y). Графически это означает, что если в исходном графе G был подграф
то в новом состоянии G' будет подграф
3. Create. Пусть S - субъект, bÍR. Команда "S create P for new object X" создает в графе новую вершину X и определяет Р как права доступов S к X. То есть по сравнению с графом G в новом состоянии G' добавляется подграф вида
4. Remove. Пусть S - субъект и X - объект, bÍR. Команда "S remove Р for X" исключает права доступа Р из прав субъекта S к объекту X. Графически преобразования графа доступа G в новое состояние G' в результате этой команды можно изобразить следующим образом:
в G в G’
Далее будем обозначать G|-cG', если команда с преобразует G в G', а также G |- G', если существует команда с, что G|-G'. Будем понимать под безопасностью возможность или невозможность произвольной фиксированной вершине Р получить доступ aÎR к произвольной фиксированной вершине X путем преобразования текущего графа G некоторой последовательностью команд в граф G', где указанный доступ разрешен.
Определение. В графе доступов G вершины Р и S называются tg-связными, если существует путь в G, соединяющий Р и S, безотносительно ориентации дуг, но такой, что каждое ребро этого пути имеет метку, включающую t или g.
Теорема 1. Субъект Р может получить доступа к, объекту X, если существует субъект S, имеющий доступ а, к вершине X такой, что субъекты Р и S связаны произвольно ориентированной дугой, содержащей хотя бы одно из прав t или g
Доказательство. Возможны 4 случая.
1. В G есть подграф
Тогда имеем право применить команду "Р take a for X from S" и получим в G' подграф
2. В G есть подграф
Тогда имеем право применить команду "S grant а for X to Р" и получим в G' подграф
3. В графе G есть подграф
Тогда применяем следующую последовательность разрешенных команд для преобразования графа G:"Р create tg for new object Y"
"Р grant g for Y to S"
"S grant a for X to Y"
"Р takes a for X from Y"
4. В графе G есть подграф
Тогда применяем следующую последовательность разрешенных команд для преобразования графа G в граф G' с дугой (Р X). "Р create tg for new object Y"
Далее будем записывать преобразования графов коротко
Теорема доказана.
Замечание. Метка с правом а на дуге в рассматриваемых графах не означает, что не может быть других прав. Это сделано для удобства.
Теорема. 2. Пусть в системе все объекты являются субъектами. Тогда субъект Р может получить доступ а к субъекту X тогда и только тогда, когда выполняются условия:
1. Существует субъект S такой, что в текущем графе G есть дуга.
2.S tg-связна с Р
Доказательство. 1. Достаточность.
Доказательство будем вести индукцией по длине n tg-пути, соединяющего S и Р. При n=l утверждение доказано в теореме 1. Пусть длина tg-пути в G, соединяющего S и Р равна n>1. Пусть также есть вершина Q на этом tg-пути, которая смежна с S. Тогда по теореме 1 можно перейти к графу G', в котором . Ясно, что проводимые при этом команды не уничтожают tg-пути, ведущего из Р в Q. При этом длина пути из Р в Q равна (n-1), что позволяет применить предположение индукции. Тогда возможен переход от G' к G", в котором есть дуга . Сквозной переход от G к G’ доказывает достаточность.
2. Необходимость.
Пусть для пары вершин Р и X в графе G нет дуги , а после выполнения некоторой последовательности команд в графе G' есть дуга . Если в G нет ни одной вершины S, для которой существует дуга , то для любой команды с преобразования графа G в графе G’ полученном G|-cG’ при помощи с, также нет ни одной вершины S, из которой выходит дуга . Это следует из просмотра всех четырех допустимых команд. Тогда для любой последовательности команд в графе G’, полученном из G применением этой последовательности команд, также нет какой-нибудь вершины S с дугой . Тогда такой вершины нет в графе G', что противоречит условию. Следовательно, в графе G есть S такая, что .
Пусть G' такой граф, когда впервые появляется дуга . Пусть G’ такой граф, из которого по некоторой команде получился G'. Тогда просмотр команд позволяет заключить, что дуга возникла применением к некоторому , команды take или grant. Это значит, что в графе G’ от Р к S существует tg-путь длины 1.
Пусть в графе G вершины Р и S не связаны tg-путем. Тогда при любой команде с в графе G’, полученном из G командой с G|-cG’ , также нет tg-пути из Р в S. В самом деле, возьмем take
Если в р не было take или grant, то новая дуга не увеличивает количество дуг с правом take или grant в новом графе, поэтому новый tg-путь возникнуть не может. Если в р есть t или g, то между V и Z существовал tg-путь и новая дуга не увеличила числа tg-связных вершин и поэтому не могла связать Р и S. Аналогично, если Y и Z были связаны дугой grant. Команда create также не может связать существующие вершины Р и S tg-путем.
Значит при любой последовательности команд c1,...cn, если в G нет tg-пути из Р в S, то их нет в G’ полученном из G G|-c1,...cnG’. Но это противоречит сделанному выше заключению о наличии такого пути длины 1 в графе G’. Теорема доказана.
5.2. МОДЕЛЬ БЕЛЛА-ЛАПАДУЛА (Б-Л).
Модель Б-Л построена для обоснования безопасности систем, использующих политику MLS. Материалы, в которых опубликована модель в 1976г., до сих пор недоступны. Поэтому в изложении модели Б-Л будем следовать работе J. McLean (1987), в которой классы объектов предполагаются неизменными. Для описания модели нам потребуется несколько другое описание самой вычислительной системы. Пусть определены конечные множества S, О, R, L.
S - множество субъектов системы;
О - множество объектов, не являющихся субъектами;
R - множество прав доступа; R = {read (r), write(w), execute (е), append (а)};
L - уровни секретности.
Множество V состояний системы определяется произведением множеств:
,
где сомножители определяются следующим образом. В - множество текущих доступов и есть подмножество множества подмножеств произведения . Множество подмножеств будем обозначать элементы множества В будем обозначать b и они представляют в текущий момент t графы текущего доступа (в каждый момент субъект может иметь только один вид доступа к данному объекту).
М - матрица разрешенных доступов, M=|Mij|, MijÍR. F - подмножество множества , где каждый , - вектор, который состоит из трех компонент, каждая из которых тоже вектор (или отображение).
fs - уровень допуска субъектов (это некоторое отображение f: S->L);
fo - уровень секретности объектов (это некоторое отображение f: O->L);
fc - текущий уровень секретности субъектов (этотоже некоторое отображение fc: S->L).
Элементы подмножества F, которые допущены для определения состояния, должны удовлетворять соотношению:
Н - текущий уровень иерархии объектов, в работе McLean этот уровень не изменяется, совпадает с f0 и далее не рассматривается.
Элементы множества V состояний будут обозначаться через v. Пусть определены множество Q - запросов в систему и множество D - решений по поводу этих запросов (D = {yes, nо, error}). Определим множество W действий системы как
.
Каждое действие системы (q, d, v2, v1) имеет следующий смысл: если система находилась в данный момент в состоянии v1, поступил запрос q, то принято решение d и система перешла в состояние v2.
Пусть Т - множество значений времени (для удобства будем считать, что T=N - множество натуральных чисел). Определим набор из трех функций (х, у, z)
x: T->Q,
у: T->D,
z: T->V,
и обозначим множества таких функций X, Y, Z соответственно.
Рассмотрим и определим понятие системы в модели Б-Л.
Определение. Системой å(Q, D, W, z0) называется подмножество такое, что,
(x, y, z)Îå(Q, D, W, z0)Û(xt, yt, zt, zt-1)ÎW
для каждого значения tÎT, где z0- начальное состояние системы.
Определение. Каждый набор (х, у, z)Îå(Q, D, W, z0) называется реализацией системы.
Определение. Если (х, у, z) - реализация системы, то каждая четверка (xt, yt, zt, zt-1) называется действием системы.
Нетрудно видеть, что при отсутствии ограничений на запросы таким образом определен некоторый автомат, у которого входной алфавит Q, а выходной D, а множество внутренних состояний V. Автомат задается множеством своих реализаций. Перейдем к определению понятий, связанных с безопасностью системы.
Определение. Тройка (S, О, X)ÎS´O´R удовлетворяет свойству простой секретности (ss-свойство) относительно f, если X=execute, или X=append, или, если X=read и fs(S)>fo(0), или X=write и fs(S)>f0(S).
Определение. Состояние v=(b, М, f, h) обладает ss-свойством, если для каждого элемента (S,О,Х)ÎB этот элемент обладает ss-свойством относительно f.
Определение. Состояние v=(b, М, f, h) обладает *-свойством, если для каждого (S, О, X)ÎB при X=write текущий уровень субъекта fc(S) равен уровню объекта f0(O), или при X=read fc(S)>f0(O), или при X=append fo(O)>fc(S).
Определение. Состояние обладает *-свойством относительно множества субъектов S', S'ÎS, если оно выполняется для всех троек (S, О, X) таких, что SÎS'
Определение. Субъекты из множества SS' называются доверенными.
Лемма. Из * -свойства для состояния v=(b, М, f, h) следует ss-свойство относительно f для всех (S, О,Х)ÎB.
Доказательство. Утверждение следует из условия fs(S)>fc(S).
Определение. Состояние v=(b, М, f, h) обладает ds -свойством, если "(S, О, X)Îb=>XÎmso, где M=||mso||- матрица доступа состояния v.
Определение. Состояние v = (b, М., f, h) называется безопасным, если оно обладает одновременно ss-свойством, *- свойством относительно S' и ds-свойством.
Напомним формулировку политики MLS, связанной с решеткой ценностей SC´L, где L - линейный порядок, SC - решетка подмножеств в информации: информационный поток между двумя объектами называется разрешенным, если класс объекта источника доминируется классом объекта получателя. Из определения ss-свойства следует, что в безопасном состоянии возможно чтение вниз, что согласуется с эквивалентным определением MLS политики. Кроме того, ss-свойство определяет ограничение на возможность модификации, которое связано с write:
fs(S)>fo(0).
Объясним *-свойство. Если субъект может понизить свой текущий допуск до fc(S)=f0(O), то, согласно *-свойству, он может писать в объект. При этом он не может читать объекты на более высоких уровнях, хотя допуск fs(S) ему это может позволить. Тем самым исключается возможный канал утечки:
High O fs(S)
^
| r
|
|
Low S ----à O2 fc(S)
w
Таким образом, при записи информационный поток опять не может быть направлен вниз. Исключение возможно только для доверенных субъектов, которым разрешено строить информационный поток вниз. При этом доверенность субъекта означает безопасность такого потока вниз (поэтому эти потоки считаются разрешенными). Сказанное выше означает, что безопасное состояние модели Б-Л поддерживает политику MLS. Значит, для того, чтобы доказать, что любой поток на траектории вычислительной системы разрешен, достаточно показать, что выходя из безопасного состояния и следуя допустимым действиям мы опять приходим в безопасное состояние, тем самым любая реализация процесса будет безопасной. Проведем строгое обоснование этого вывода.
Определение. Реализация (х, у, z) системы å(Q, D,W, z) обладает ss-свойством ( *-свойством, ds- свойством), если в последовательности (z0, z1,.....) каждое состояние zn обладает ss-свойством ( * -свойством , ds-свойством).
Определение. Система обладает ss-свойством ( соответственно, *-свойством, ds-свойством), если каждая ее реализация обладает ss-свойством (соответственно, *-свойством, ds-свойством).
Определение. Система называется безопасной, если она обладает одновременно ss-свойством, *-cвойством, и ds - свойством.
Теорема A1. å(Q, D, W, z0) обладает ss -свойством для любого начального z0, которое обладает ss-свойством тогда и только тогда, когда W удовлетворяет следующим условиям для каждого действия (q, d, (b*, М*, i*, h*), (b, М, f, h)):
(I) "(S, 0, X)Îb*| b обладает ss-свойством относительно f*.
(2) если (S, О, X)Îb и не обладает ss-свойством относительно f*, то (S, О, X)Ïb*
Доказательство. "(S, О, Х)Îb* возможно либо (S,О, Х)Îb, или (S, О, X)Îb*b. Условие (1) означает, что состояние (b*, М*, f*, h*) пополнилось элементами (S, О, X), обладающими ss - свойством относительно f*. Условие (2) означает, что элементы b*, перешедшие из b, обладают ss - свойством относительно f*. Следовательно, "(S, О, X)Îb* обладает ss-свойством относительно f*. Пусть любое состояние обладает ss-свойством относительно своего f. Тогда (1) выполняется, т.к. ss-свойство выполняется для всех (S, О,X) из b*. И, если (S, О, X)Îb и перешло в b*, то, в силу ss-свойства (S, О, X) обладает ss - свойством относительно f*. Что и требовалось доказать.
Теорема A2. Система å(R, D, W, z0) обладает *- свойством относительно S' для любого начального состояния z0, обладающего *-свойством относительно S' тогда и только тогда, когда W удовлетворяет следующим условиям для каждого действия (q, d, (b*, М*,f*, h*), (b, М, f, h)):
(I) "SÎS’, "(S, O, X)Îb* b обладает *-свойством относительно f*;
(II) "SÎS’, "(S, O, X)Îb и (S, O, X) обладает *-свойством относительно f*, то (S, O, X)Ïb*.
Доказательство проводится аналогично.
Упражнение. Доказать теорему А2.
Теорема АЗ. Система å(Q, D, W, z0) обладает ds-свойством тогда и только тогда, когда для любого начального состояния, обладающего ds-свойством, W удовлетворяет следующим условиям для любого действия (q, d, (b*, М*, f*, h*), (b, М, f, h)):
(I) (S, О, X)Îb*| b то ХÎтso*,
(II) (S, 0, X)Îb*| b XÏmso*, то (S, 0, X)Ïb*
Доказательство проводится аналогично.
Упражнение. Доказать теорему АЗ.
Теорема (Basic Security Theorem). Система å(Q, D, W, z0 ) - безопасная тогда и только тогда, когда z0 - безопасное состояние и W удовлетворяет условиям теорем A1, А2, АЗ для каждого действия.
Доказательство. Теорема BST следует из теорем А1, А2, АЗ.
5.3. МОДЕЛЬ LOW-WATER-MARK (LWM).
Данная модель является конкретизацией модели Б-Л, а также дает пример того, что происходит, когда изменения уровня секретности объекта возможны. Политика безопасности прежняя: все объекты системы классифицированы по узлам решетки ценностей (MLS) и поток информации разрешен только "снизу вверх" .
В рассматриваемой системе один объект (неактивный), три операции с объектом, включающие запросы на доступ:
· read,
· write,
· reset.
Эти операции используются несколькими субъектами (процессами), имеющими фиксированные уровни секретности (для простоты - классы секретности образуют линейный порядок). Напомним формальное требование политики о том, что информация может двигаться только "снизу вверх". Поток информации возможен тогда и только тогда, когда реализуется доступ субъекта к объекту вида w или r. При помощи r поток считается разрешенным, если fs(S)>fo(0).
При команде w поток считается разрешенным, если субъект S не может прочитать информацию в объекте уровня fs(S)0(0) и записать в объект, для которого fs(S)>f0(O), причем хотя бы в одном из этих соотношений неравенство строгое (напомним, что по условию текущие уровни субъектов fc(S)=fs(S) для любого S). Из этих свойств следует, что в системе должны выполняться условия ss и *. Условие ds автоматически выполняется, так как нет ограничений на доступ, кроме перечисленных.
Таким образом, условия ss в данной системе выглядят стандартно: если X=w или r, то могут быть разрешены доступы (S, 0, X) при выполнении fs(S)>f0(0).
Условие *:
если X=w, то fs(S)=f0(0),
если X=r, то fs(S)>fo(0).
Опишем функционирование системы и докажем, что выполняются условия ss и *. Уровень объекта О в LWM может меняться: при команде write может снизиться, а при команде reset подняться следующим образом. По команде reset класс объекта поднимается и становится максимальным в линейном порядке. После этого все субъекты приобретают право w, но read имеют право только субъекты, находящие на максимальном уровне решетки. При команде write гриф объекта снижается до уровня субъекта, давшего команду w. При снижении уровня секретности объекта вся прежняя информация в объекте стирается и записывается информация процессом, вызвавшем команду write. Право write имеет любой субъект, у которого fs(S)o(0), где f0(О) - текущий уровень объекта. Право reset имеет только тот субъект, который не имеет право write. Право read имеет любой субъект, для которого fs(S)>fo(0).Суммируем вышесказанное в следующей таблице.
Операция
|
Организация доступа
|
Результат операции
|
Read
|
fs(S)>fo(0)
|
Процесс S получает содержимое объекта O
|
Write (данные)
|
fs(S)o(0)
|
Уровень объекта становится равным уровню S. Данные от S записываются в O.
|
Reset
|
fs(S)>fo(0)
|
Уровень объекта устанавливается выше всех уровней процессов.
|
Лемма. Для любого состояния системы LWM выполнены условия ss и *.
Доказательство. Если fs(S)>fo(0), то r доступ S к О разрешен. Если fs(S)=fo(0), то w доступ S к О разрешен. Таким образом ss и * выполнены. Что и требовалось доказать.
Однако все рассуждения останутся теми же, если отказаться от условия, что при команде write в случае снижения уровня объекта все стирается. То есть здесь также будут выполняться условия * и ss, но ясно, что в этом случае возможна утечка информации. В самом деле, любой процесс нижнего уровня, запросив объект для записи, снижает гриф объекта, а получив доступ w, получает возможность r. Возникает канал утечки (¯w, ®r), при этом в предыдущей модели свойство * выбрано для закрытия канала ( r, ®w). Данный пример показывает, что определение безопасного состояния в модели Б-Л неполное и смысл этой модели только в перекрытии каналов указанных видов. Если "доверенный" процесс снижения грифа объекта работает неправильно, то система перестает быть безопасной.
5.4. МОДЕЛИ J.GOGUEN, J.MESEGUER (G-M).
Модели G-M - автоматные модели безопасных систем. Начнем с простейшего случая системы с "фиксированной" защитой. Пусть V - множество состояний системы (V - конечное и определяется программами, данными, сообщениями и пр.), С - множество команд, которые могут вызвать изменения состояния (также конечное множество), S - множество пользователей (конечное множество). Смена состояний определяется функцией:
do:V ´ S ´ С®V.
Некоторые действия пользователей могут не разрешаться системой. Вся информация о том, что разрешено ("возможности" пользователей) пользователям сведена в с-таблицу t. В рассматриваемом случае "возможности" в с-таблице t совпадают с матрицей доступа. Если пользователь не может осуществить некоторую команду с, то
do (v, S, c) = v.
Предположим, что для каждого пользователя S и состояния v определено, что "выдается" этому пользователю (т.е., что он видит) на выходе системы. Выход определяется функцией
out: V´ S®Out,
где Out - множество всех возможных выходов (экранов, листингов и т.д.).
Мы говорим о выходе для пользователя S, игнорируя возможности S подсмотреть другие выходы.
Таким образом получили определение некоторого класса автоматов, которые будут встречаться далее.
Определение. Автомат М состоит из множеств:
S - называемых пользователями;
V - называемых состояниями;
С - называемых командами;
Out - называемых выходами;
и функций:
· выходной функции out: V´ S ® Out, которая "говорит, что данный пользователь видит, когда автомат находится в данном состоянии ";
· функции переходов do: V´S´С®V, которая "говорит, как изменяется состояние автомата под действием команд";
и начального состояния v0.
Системы с изменяющимися "возможностями" защиты определяют следующими образами.
Пусть Capt - множество всех таблиц "возможностей", СС - множество с-команд (команд управления "возможностями"). Их эффект описывается функцией:
cdo: Capt´ S ´ CC®Capt.
При отсутствии у пользователя S права на с-команду положим cdo(t, S, c)=t. Пусть VC - множество команд, изменяющих состояние. Теперь можем определить С-автомат, который лежит в основе дальнейшего.
Определение. С-автомат М определяется множествами:
S - "пользователи";
V - "состояния";
VC - "команды состояния";
Out - "выходы";
Capt - "с-таблицы";
СС - "с-команды",
и функциями:
· выхода out: V´Capt´S®Out, которая "говорит, что данный пользователь видит, когда автомат находится в данном состоянии v, а допуски определяются с-таблицей";
· переходов do: V´Capt´S´VC®V, которая "говорит, как меняются состояния под действием команд";
· изменения с-таблиц cdo: Capt´S´СС®Capt, которая "говорит, как меняется с - таблица под действием с", и начального состояния, которое определяется с-таблицей t и состоянием v.
Будем считать
C=CCÈVC.
То, что мы определили на языке теории автоматов, называется последовательным соединением автоматов .
Определение. Подмножества множества команд С называются возможностями
Ab=2c.
Если дан С-автомат М, мы можем построить функцию переходов всей системы в множестве состояний V´Capt:
cvdo: V ´Capt´S´С®V´Capt,
где
cvdo(v, t, S, с) = (do(v, t, S, с), t), если cÎVC,
cvdo(v, t, S, с) = (v, cdo(t, S, c)), если cÎCC.
Стандартно доопределяется функция cvdo на конечных последовательностях входов
cvdo: V´Capt´(S´С)*®V´Capt
следующим образом:
cvdo(v, t, Nil) = (v, t),
если входная последовательность пустая;
cvdo(v, t, W(S, c))=cvdo(cvdo(v, t, W), S, c)),
где W(S, С) - входное слово, кончающееся на (S,С) и начинающееся подсловом W.
Определение. Если W входное слово, то[[W]] = (..., (vi ti),...), где последовательность состоянии вычисляется в соответствии с определенной выше функцией переходов под воздействием входной последовательности W.
Введем понятие информационного влияния одной группы на другую, смысл которого состоит в том, что используя некоторые возможности одна группа пользователей не влияет на то, что видит каждый пользователь другой группы. Для этого определим [[W]]s - выход для S при выполнении входного слова W С -автомата М:
[[W]]s=out([[W]], S),
где
out([[W]]s, S) = (... out(v, t, S)...),
[[W]] = (..., (vi, ti),...).
Пусть GÍS, AÍC, WÎ(S´C)*.
Определение. Pg(W) - подпоследовательность W, получающаяся выбрасыванием всех пар (S, с) при SÎG, Pa(W) - подпоследовательность W, получающаяся выбрасыванием из W всех пар (S, с) при cÎA, PGA(W) -подпоследовательность W, получающаяся выбрасыванием пар (S, с), SÎG и сÎА.
Пример 1. G={S, Р}, А={с1, с2}.
PGA((S', с), (S, сз), (S, с2), (Р', с))= (S', с), (S, с3), (Р', с). Определим несколько вариантов понятия независимости .
Пусть GÍS, G’ÍS.
Определение. G информационно не влияет на G' (обозначается G: | G'), если "WÎ(S´С)* и "SÎG' [[W]]s = [[PA(W)]]s
Аналогично определяется не влияние для возможностей А (или группы G и возможностей А).
Определение. А информационно не влияет на G (обозначается А: | G) , если "WÎ(S´С)* и "SÎG [[W]]s= [[PA(W)]]s
Определение. Пользователи G, используя возможности А, информационно не влияют на G' (обозначается A.G: | G'), если "WÎ( S´С)* и "S´G' [[W]]s=[[PA(W)]]s.
Пример 2. Если А: | {S}, то команды из А не влияют на выход, выданный S. Если A={create, write, modify, deleted} для файла F, то А: | {S} означает, что информация читаемая S в F не может измениться любой из команд в А. Если F не существовал, то для S будет всегда выдаваться информация, что F не существует.
Определение. Политика безопасности в модели G-М - это набор утверждений о не влиянии.
Пример 3. MLS политика. Пусть L - линейно упорядоченное множество уровней секретности и задано отображение
level: S->L.
Определим: "xÎL
S[-¥, x] = {SeS | level(S))
S[x,+¥] = {SeS| level(S)>x}.
Определение. MLS политика в модели G-M определяется следующим набором утверждений о не влиянии:
"xÎL, "x'ÎL, х>х',
S[x, +¥]:| S[ -¥, x'].
Говорят, что GÍS невидимо для остальных пользователей, если G:| , где = SG.
Используя это понятие легко обобщить определение MLS политики на случай, когда L - решетка.
Определение. MLS политика в модели G-M определяется следующим набором утверждений о не влиянии:
"xÎL SS[-¥, х] - невидимо для остальных пользователей.
Пример 4. Одним из важнейших примеров политики безопасности, легко выражаемой в G-M модели, является режим изоляции.
Определение. Группа G называется изолированной ,если G:| и :| G.
Система полностью изолирована, если каждый пользователь изолирован.
Пример 5. Контроль канала. В модели G-M канал определяется как набор команд АÍС .
Пусть G, G'ÍS.
Определение. G и G' могут связываться только через канал А тогда и только тогда, когда
и
Пример 6. Информационный поток Пусть а, b, с, d -процессы и А1, A2, Аз - каналы такие, что а, b, с, d могут связываться только по схеме
Эта картинка описывается следующими утверждениями о не влиянии:
{b, c, d}: | {a} A1, {a}: | {b, c, d}
{c, d}: | {b} A2, {b}: | {c}
{c}: | {d} A3, {b}: | {d}
{d} : | {c}
5.5. МОДЕЛЬ ВЫЯВЛЕНИЯ НАРУШЕНИЯ БЕЗОПАСНОСТИ.
Один из путей реализации сложной политики безопасности, в которой решения о доступах принимаются с учетом предыстории функционирования системы, - анализ данных аудита. Если такой анализ возможно проводить в реальном масштабе времени, то аудиторская информация (АИ) совместно с системой принятия решений превращаются в мощное средство поддержки политики безопасности. Такой подход представляется перспективным с точки зрения использования вычислительных средств общего назначения, которые не могут гарантировано поддерживать основные защитные механизмы. Но, даже не в реальном масштабе времени, АИ и экспертная система, позволяющая вести анализ АИ, являются важным механизмом выявления нарушений или попыток нарушения политики безопасности, так как реализуют механизм ответственности пользователей за свои действия в системе.
По сути анализ АИ имеет единственную цель выявлять нарушения безопасности (даже в случаях, которые не учитываются политикой безопасности). Далее мы изложим пример организации такого анализа, который известен из литературы под названием "Модель выявления нарушения безопасности". Эта модель, опубликованная D.Denning в 1987 г., явилась базисом создания экспертной системы IDES для решения задач выявления нарушений безопасности. Модель включает 6 основных компонент:
· субъекты, которые инициируют деятельность в системе, обычно - это пользователи;
· объекты, которые составляют ресурсы системы - файлы, команды, аппаратная часть;
· АИ - записи, порожденные действиями или нарушениями доступов субъектов к объектам;
· профили - это структуры, которые характеризуют поведение субъектов в отношении объектов в терминах статистических и поведенческих моделей;
· аномальные данные, которые характеризуют выявленные случаи ненормального поведения;
· правила функционирования экспертной системы при обработке информации, управление.
Основная идея модели - определить нормальное поведение системы с тем, чтобы на его фоне выявлять ненормальные факты и тенденции. Определению субъектов и объектов мы уделили достаточное внимание в параграфе 1.1. Остановимся подробнее на описании и примерах остальных элементов модели.
АИ - это совокупность записей, каждая из которых в модели представляет 6-мерный вектор, компоненты которого несут следующую информацию:
<субъект; действие; объект; условия для предоставления исключения; лист использования ресурсов; время>,
где смысл компонент следующий.
Действие - операция, которую осуществляет субъект и объект.
Условия для предоставления исключения, если они присутствуют, определяют, что дополнительно надо предпринять субъекту, чтобы получить требуемый доступ.
Лист использования ресурсов может содержать, например, число строчек, напечатанных принтером, время занятости CPU (центрального процессора) и т.д.
Время - уникальная метка времени и даты, когда произошло действие.
Так как АИ связана с субъектами и объектами, то данные АИ подобны по организации матрице доступа, где указаны права доступа каждого субъекта к любому объекту. В матрице АИ в клетках описана активность субъекта по отношению к объекту.
Пример 1. Рассмотрим команду
Copy-Game.exe to Game.exe,
которую использовал пользователь Smith для того, чтобы скопировать файл "Game" в библиотеку; копирование не выполнено, так как Smith не имеет права писать в библиотеку. АИ, соответствующая этому примеру будет состоять из записей:
(Smith, execute, < Library> Сору.ехе, О,
CPU = 00002, 11.05.85.21678)
(Smith, Read, Game.exe, 0, Records = 0,
11.05.85.21679)
(Smith, Write, Game.exe,
Write - violation. Records = 0, 1 1 .05.85.2 1 680).
Рассмотрим подробнее понятие "профиль". Профили описывают обычное поведение субъектов по отношению к объектам. Это поведение характеризуется набором статистических характеристик, вычисленных по наблюдениям за действиями субъекта по отношению к объекту, а также некоторой статистической моделью такого поведения. Приведем примеры таких статистических характеристик.
1. Частоты встречаемости событий. Например, частота встречаемости заданной команды в течение часа работы системы и т.д.
2. Длина временного промежутка между осуществлением некоторых событий.
3. Количество ресурсов, которые были затрачены в связи с каким-либо событием. Например, время работы CPU при запуске некоторой программы, число задействованных элементов аппаратной части и др.
Статистические модели строятся по наблюденным значениям статистических характеристик с учетом статистической обработки данных. Например, некоторый процесс характеризуется устойчивым средним числом встречаемости данной команды, которая может быть уверенно заключена в доверительный интервал в 3s, где s - стандартное отклонение частоты встречаемости этого события.
Чаще всего статистические модели являются многомерными и определяются многомерными статистическими методами. Наиболее сложные модели - это случайные процессы, характеристики моделей являются некоторыми функционалами от случайных процессов. Например, моменты остановки программы и т.д.
В нормальных условиях статистические характеристики находятся в границах своих значений. Если происходит ненормальное явление, то возможно наблюдать статистически значимое отклонение от средних параметров статистических моделей.
Пример 2. Реализация канала утечки по времени, приведенного в примере 4 параграфа 2.1, требует повторяющегося запроса на принтер, а затем отказа от него. Ясно, что в реализации такого канала частота обращения к принтеру возрастает, что, естественно, приведет к значимому отклонению этой характеристики от модели повседневного использования принтера данным пользователем.
Описание профиля или его структура состоит из 10 компонентов, которые, кроме собственно статистической модели, определяют АИ с ней связанную. Структура профиля может быть представлена следующим вектором:
<Имя переменной; отражаемые действия; имеющиеся исключения; данные использования ресурсов; период измерений; тип статистики; порог допустимых значений; субъект; объект; значение последнего наблюдения модели>.
К сожалению, анализ на уровне субъект - объект в значительной степени затруднен. Поэтому аналогичные структуры (профили) создаются для агрегированных субъектов и объектов. Например, для некоторого фиксированного множества субъектов в отношении всех возможных объектов. Другой пример: действия всех пользователей в отношении данного объекта.
Основной сложностью при внедрении этой модели является выбор и построение профилей.
Пример 3. Рассмотрим систему с 1000 пользователями; у каждого пользователя в среднем 200 файлов, что дает 200000 файлов в системе. Тогда имеем 200 млн. возможных комбинаций: пользователь-файл. Даже, если предположить, что каждый пользователь осуществляет доступ к 300 файлам, то необходимо создать 300 000 профилей.
Пример 3 показывает, что необходимо применять специальные приемы для сокращения информации.
Если обнаружено ненормальное поведение, то немедленно делается запись в сборнике аномальных фактов. Каждая запись в этом сборнике - трехмерный вектор, имеющий следующие компоненты:
<событие; время; в отношении какого профиля получено отклонение > .
Применение рассмотренной модели дало хорошие результаты. Вместе с тем требуют исследований такие вопросы:
· насколько надежно предложенный метод выявляет нарушения безопасности;
· какова доля нарушений безопасности, для которых работает метод;
·выбор инструментов статистической обработки данных и моделей профилей требует обоснования;
· идеология самого быстрого обнаружения ещене ясна.
Глава 6. Гарантированно защищенные распределительные системы.
Глава VI посвящена вопросам защиты сетей межмашинного обмена информацией. Основной аспект нашего изучения - распространение стандарта "Оранжевая книга" на распределенные системы обработки информации. Базисом для предложенного ниже подхода является "Trusted Network Interpretation", которая была выпущена DoD в 1987 г. в составе "радужной" серии. Эта книга известна под названием "Красная книга" (КК). В главе приведены результаты, заимствованные из КК и связанные с методами анализа защищенных сетей и синтеза гарантированно защищенных распределенных систем обработки информации.
В отличии от "монолитных" вычислительных систем, имеющих заданный периметр и спецификацию, распределенные системы не имеют ограниченного периметра, а число компонент их может меняться. Между компонентами в сетях существуют каналы, которые могут проходить по незащищенной или враждебной территории. Этими чертами различия между монолитной и распределенными вычислительными системами исчерпываются. Следовательно, если как-то учтены перечисленные различия, то все вопросы защиты вычислительных и распределенных систем одинаковы. Таким образом, к распределенным системам можно попытаться применить критерии гарантированной защищенности вычислительных систем, например, "Оранжевой книги".
Возможны два подхода к анализу и оценке защищенности распределенной системы.
1. Каждая компонента распределенной системы есть самостоятельная защищенная система, а, в целом, сеть представляет множество взаимодействующих, защищенных порознь систем. Такая сеть не есть одно целое и вопросы ее гарантированной защиты сводятся к доказательству защищенности компонент в условиях рассматриваемого окружения и организации защищенных шлюзов для взаимодействия компонент. Однако, никто не отвечает за информацию в сети целиком.
2. Все компоненты и связи между ними составляют единое целое. В этом случае существует лицо (центр), которое берет на себя обязательство обеспечить безопасность в сети. Здесь эта безопасность относится к сети в целом, несмотря на неопределенный периметр и изменяемую конфигурацию. Тогда должна существовать некоторая политика безопасности и средства сети, поддерживающие эту политику (NTCB). При этом средства поддержки безопасности в сети вовсе не должны составлять полный комплекс (удовлетворяющий стандарту OK) механизмов защиты в каждой отдельной компоненте. Однако они, в целом, должны составлять единый механизм защиты, который в случае использования дискреционной и мандатной политики может анализироваться на предмет соответствия стандарту ОК. В частности, для класса ВЗ и выше NTCB должна реализовывать монитор обращения во всей сети. Отсюда возникает задача синтеза из отдельных компонент NTCB, поддерживающую политику в сети, а также задача оценки защитных функций компонент, из которых NTCB возможно синтезировать. В КК все рассмотренные вопросы поставлены с точки зрения проведения оценки распределенной системы. Предложенный подход (он же применим в анализе и синтезе таких систем) состоит в том, чтобы по сети построить гипотетическую монолитную систему с ТСВ, совпадающей по функциям с NTCB, и ее оценивать. С другой стороны, при создании распределенной системы можно сначала создать гипотетический проект монолитной защищенной системы, а затем провести декомпозицию его по компонентам распределенной системы с сохранением защитных свойств. И, наконец, всем известна "слабость" ОК, состоящая в том, что слабо отработана проблема контроля защищенности при модификациях или замене подсистем. Если для монолитной вычислительной системы эта слабость была преодолима, то в распределенных системах проблема наращивания компонент без переоценки всего в целом становится принципиальной. В параграфе 6.1 на основе теоремы о синтезе монитора обращения в NTCB из мониторов обращений компонент строится главная составляющая NTCB - контроль за доступами. Отсюда следует описанная вкратце декомпозиция монолитных систем, в которых есть монитор обращения, и синтез распределенной системы в монолитную вычислительную систему с ТСВ, реализующей монитор обращения. В параграфе 6.2 описаны подходы КК к анализу компонент и примеры встраивания таких компонентв гарантированно защищенную распределенную систему, в которой функции NTCB распределены по компонентам.
6.1. СИНТЕЗ И ДЕКОМПОЗИЦИЯ ЗАЩИТЫ В РАСПРЕДЕЛЕННЫХ СИСТЕМАХ.
Рассмотрим сеть, компоненты которой связаны каналами связи, а каждая из компонент несет некоторые функции защиты. Основное требование при анализе безопасности распределенной системы как одного целого - является общая политика безопасности. Тогда вопрос защищенности распределенной системы как одного целого состоит в организации согласованного действия компонент защиты по поддержке политики безопасности всей сети. Решению этой проблемы противостоят опасности нарушения защиты информации при передаче ее по каналам связи, а также опасности асинхронного функционирования компонент защиты.
В связи с этим предположим, что ТСВ компонент в каждом локальном случае поддерживают функции монитора обращения. Единая политика безопасности в сети не означает, что все ТСВ компонент поддерживают одну и ту же политику и соответствуют требованиям одного класса. Например, одна компонента может быть классифицирована по классу С2 (хотя в ней тоже мы требуем дополнительно наличие монитора обращения), а другая - по классу ВЗ. При этом обе компоненты поддерживают единые дискреционную и мандатную политики, хотя первая компонента -
одноуровневая (соответствует одному классу обрабатываемой информации), а вторая - поддерживает MLS политику в полном объеме. Кроме того, в обоих компонентах предполагается единая система категорий и единые ограничения на распространение прав в дискреционной политике (по крайней мере она должна вкладываться в единую систему категорий и прав).
Рассмотрим вопрос, когда совокупность мониторов обращения в подсистемах реализует монитор обращения во всей распределенной сети. В КК формулируются условия, позволяющие это сделать.
Теорема. Пусть выполнены следующие условия.
1. Каждый субъект сети существует только в одной компоненте на протяжении всего жизненного цикла.
2. Каждый субъект может иметь доступ только к объектам своей компоненты.
3. Каждая компонента содержит отнесенный к этой компоненте монитор обращений, который рассматривает только обращения субъектов этой компоненты к объектам этой компоненты.
4. Все каналы, связывающие компоненты, не компрометируют безопасность информации, в них проходящей.
Тогда совокупность мониторов обращения компонент является монитором обращения в сети.
Доказательство. Этот результат потребует дополнительного уточнения некоторых основных понятий. Рассмотрим сеть из компонент, связанных безопасными каналами связи. Напомним, что любой объект представляет собой конечное непустое множество слов некоторого языка. Добавим к этому, что объект существует только при условии, что возможен доступ к содержанию объекта, то есть мы предполагаем наличие хотя бы одного слова из множества, определяющего объект, к которому возможен в данный момент доступ хотя бы одного субъекта. Тогда информация, передаваемая по безопасному каналу связи, не является объектом, так как до момента окончания приема, нет ни одного слова на приемном конце, к которому хотя бы один субъект может получить доступ. В самом канале, если он не может компрометировать информацию при передаче, мы считаем невозможным доступ к информации и поэтому это не объект. На передающем конце информация передается из некоторого объекта и при передаче мы считаем, что есть некоторый субъект на передающем конце, который в течение передачи имеет доступ к объекту на передающем конце и представляет собой интерфейс с многоуровневым прибором ввода/вывода (концепция такого экспорта информации изложена в OK). После окончания передачи на приемном конце сформировался новый объект, который, вообще говоря, не имеет отношения к объекту на передающем конце и из которого шла перекачка информации.
Рассмотрим формальное объединение мониторов обращения компонент. Тогда из вышесказанного следует, что нет объектов вне локальных компонент, а дистанционный доступ происходит за счет создания нового объекта, который полностью контролируется локальной ТСВ компоненты. Покажем, что формальное объединение мониторов обращения компонент-монитор обращения сети М.
1) Каждое обращение субъекта к объекту в системе происходит через М. В самом деле, каждый субъект существует только в одной компоненте по усл. 1 и может обращаться к объектам только своей компоненты по усл. 2. Поэтому все обращения в системе ограничены рамками компонент. А тогда каждое обращение обрабатывается монитором обращения соответствующей компоненты по определению монитора обращения.
2) Монитор обращения каждой компоненты по определению гарантированно защищен. Поэтому объединение их гарантированно защищено.
3)Функционирование всех мониторов обращения компонент полностью тестируется (то есть существует полная система тестов). Тогда совокупность тестов компонент полностью тестирует М.
Теорема доказана.
Теперь рассмотрим вопрос о синтезе единой вычислительной системы из компонент таким образом, что анализ защищенности сети эквивалентен анализу такой вычислительной системы. Пусть вычислительная система обладает следующими свойствами. Это многоуровневая, многопрограммная система, удовлетворяющая условиям соответствующего класса OK(например, ВЗ). В системе информация ТСВ распределена среди одновременно работающих процессоров, которые соединены одной шиной. В системе функционирует одна операционная система, которая поддерживает процесс на любом процессоре. Каждый процесс может использовать внешние приборы через запрос в ТСВ, где реализован монитор обращения. Можно показать, что единая NTCB в распределенной системе, эквивалентной описанной выше вычислительной системе, реализует в компонентах мониторы обращения, объединение которых дает монитор обращения NTCB (по доказанной теореме). А ТСВ вычислительной системы эквивалентна NTCB сети после декомпозиции этой вычислительной системы.
Этот подход позволяет проводить анализ распределенной системы как единой вычислительной системы. Можно действовать наоборот. Создать проект монолитной защищенной вычислительной системы описанного типа, а затем реализовать ее представление в виде распределенной сети.
Заметим, что некоторые компоненты монитора обращений NTCB могут быть вырожденными. Кроме того, наличие монитора обращений вовсе не означает, что в компоненте есть все функции ТСВ системы защиты по какому-либо классу. Единая распределенная система тем и хороша, что ТСВ сети можно построить из компонент, не содержащих в отдельности все функции защиты.
В заключение сформулируем требования, которым должен удовлетворять использованный в теореме безопасный канал связи:
1. Безопасность связи - устойчивость к несанкционированным раскрытию или модификации передаваемой ценной информации.
2. Надежность связи - не допускает отказ от доставки сообщения, неправильную доставку, доставку ошибочных данных.
3. Имитозащита - не допускает изменений в критичной для этого информации (метки и т.д.).
4. Не допускает скрытые каналы утечки за счет модуляции параметров канала.
6.2. АНАЛИЗ КОМПОНЕНТ РАСПРЕДЕЛЕННОЙ СИСТЕМЫ.
Анализ и оценка защиты распределенных систем, как единого целого, предполагает анализ частей, а затем построение оценки защищенности всей системы в целом. Анализ компонент и синтез единой оценки защищенности всей системы необходим также при модернизации системы, при замене старых компонент новыми, при синтезе системы из блоков или частей, для того, чтобы иметь возможность использовать разработки различных производителей, для доказательства существования NTCB, удовлетворяющей требованиям ОК.
При анализе возникают две проблемы.
1 . Как разделить сеть так, чтобы из анализа и оценки компонент можно построить оценку защищенности системы в целом.
2. Какими критериями надо пользоваться при анализе компонент и как из результатов для компонент синтезировать общую оценку.
В предыдущем параграфе мы наметили контуры ответа на первый вопрос. В случае, когда декомпозиция происходит так, что в каждой компоненте реализован монитор обращения, то, при выполнении условий теоремы предыдущего параграфа, во всей системе есть монитор обращения. Тогда гипотетическое объединение распределенной системы в единую вычислительную систему, как это было обозначено выше, позволяет провести анализ наличия всех остальных функций NTCB. И наоборот, декомпозиция единой гарантированно защищенной вычислительной системы из предыдущего параграфа так, что в любой компоненте реализован монитор обращений, позволяет рассредоточить функции NTCB по различным компонентам.
В "Красной книге" допускается, что ТСВ любого класса (с соответствующими оговорками) может быть синтезирована из реализации 4 функций:
· поддержки дискреционной политики (Д);
· поддержки мандатного контроля (М);
· функции идентификации/аутентификации (I);
· аудита (А).
Исходя из этого предполагается, что любая подсистема защиты, подлежащая отдельной оценке и экспертизе на предмет встраивания в распределенную систему, должна удовлетворять внутри себя условиям теоремы параграфа 6.1 и выполнять некоторый набор из перечисленных функций (всего имеется 16 вариантов таких наборов). При наличии этих свойств подсистема может быть компонентой распределенной сети и входить в NTCB. Приведем примеры включения таких подсистем.
Пример 1. Пусть дана М - компонента (то есть подсистема, единственной функцией которой является поддержка мандатного контроля доступа). Пусть также эта подсистема обладает монитором обращений, оценена как самостоятельная система по классу А1. Тогда ее можно включить как компоненту в гарантированно защищенную распределенную систему обработки информации, например, для выполнения функций многоуровневой коммутации пакетов. Покажем это на схеме, взятой из "Красной книги".
На приведенной схеме показана взаимосвязь М -компоненты с другими компонентами и, в частности, с подсистемами ТСВ. Минимальное взаимодействие необходимо с системой аудита.
Пример 2. Данный пример из "Красной книги" показывает использование Д-компоненты в качестве одноуровневого файлового сервера сети.
В этом примере обозначение С2+ показывает, что система может быть оценена по классу С2, но иметь дополнительные функции, которые присущи дискреционной политике и аудиту в классе ВЗ и выше. (Дополнительно требуется выполнение функции блокировки при превышении числа опасных событий выше порога, матрица запрещенных доступов и т.д.)
Пример 3. В данном примере мы покажем использование компоненты I для организации интерфейса с несекретными пользователями. Основная функция компоненты - контроль доступа терминала. Вся работа по аутентификации пользователя проводится в этой компоненте, а затем в разрешение доступа и аудиторскую информацию переписываются только идентификаторы вместе с соответствующей информацией.
Пример 4. В рассматриваемом примере, также взятом из "Красной книги", А - компонента выполняет функцию сбора одноуровневой АИ в сети. Обозначение C2+ показывает, что в системе, классифицированной уровнем С2, выполняются дополнительные (по классу ВЗ) функции.
Глава 7.Проблема построения гарантированно защищенных баз данных.
Создание гарантированно защищенных баз данных связано с некоторыми общими проблемами синтеза систем защиты. Эти проблемы отражены в "Розовой книге" (Trusted Database Management System Interpretation of the Trasted Computer System EvaluationCriteria, 1991). Промежуток в 4 года между второй, "Красной книгой", и "Розовой книгой" показывает, что за эти годы решались трудные задачи теории зашиты информации. В самом деле, если политика безопасности в базе данных не включает вопросов, связанных с взаимным выводом информации и каналов утечки, основанных на этом выводе, вопросов восстановления зашумленной информации путем повторных запросов в базу данных, то такая политика не является адекватной для безопасности информации. Однако, все эти вопросы нельзя включать в политику безопасности, поддерживаемую самой вычислительной системой, что приведет к симбиозу операционной системы и системы управления базой данных. Вместе с тем, сложилась такая практика, что производителями операционных систем и систем управления базами данных являются разные фирмы или организации, что делает такой симбиоз невозможным. Поэтому политика безопасности частично должна поддерживаться самой базой данных. Аналогичные проблемы возникают при модернизации защищенных систем и могут быть сформулированы как противоречие между единой оценкой защищенности всей системы и многопрофильностью подсистем, создаваемых различными производителями. С аналогичной проблемой мы сталкивались в главе VI. Однако теперь существенным образом возникает зависимость частей защиты друг от друга (ТСВ вычислительной системы управляет субъектами системы защиты (ТСВ), поддерживающей политику безопасности базы данных). Такая структура не вкладывается в систему независимых защищенных компонент распределенной сети. В параграфе 7.1 приводится описание модели ТСВ-подмножеств, иерархически связанных друг с другом, которые при выполнении некоторых дополнительных условий могут удовлетворять условиям ТСВ системы. В параграфе 7.2 приведены наиболее распространенные архитектуры защищенных баз данных, в которых теория параграфа 7.1 может быть реализована.
7.1. ИЕРАРХИЧЕСКИЙ МЕТОД ПОСТРОЕНИЯ ЗАЩИТЫ .
В данном параграфе рассматривается еще один пример иерархической декомпозиции сложных систем. Если в параграфе 1.2 мы рассматривали примеры, не связанные непосредственно с задачей защиты, то сейчас основное внимание будет посвящено иерархическому построению ТСВ в электронных системах обработки данных. Как и раньше, основная задача ТСВ - поддержка монитора обращений. Однако, в отличие от теории предыдущего параграфа, где мониторы обращения были независимыми, сейчас мы покажем, что одни ТСВ-подмножества могут использовать ресурсы в других ТСВ-подмножествах. А именно, рассмотрим следующую модель.
Определение. ТСВ-подмножество М есть совокупность программно-аппаратных ресурсов системы, которые управляют доступами множества S субъектов к множеству О объектов на основе четко определенной политики Р и удовлетворяет свойствам:
1) М определяет и контролирует каждый доступ кобъектам из О со стороны субъектов из S;
2) М гарантировано защищено;
3)М достаточно просто устроено, чтобы существовала возможность проанализировать его системой тестов, полнота которых доказана.
Зависимость ТСВ-подмножеств состоит в том, что М использует ресурсы точно определенного множества более примитивных ТСВ-подмножеств (то есть предполагается заданным некоторый частичный порядок на ТСВ-подмножествах), для того, чтобы создать объекты из О, создать и поддерживать структуры данных и поддерживать политику Р.
Если более примитивных ТСВ-подмножеств нет, то такое ТСВ-подмножество опирается в решении тех же задач на аппаратную часть.
Отметим, что кроме монитора обращений необходимо существование механизма поддержки этого монитора. Рассмотрим условия, при которых из ТСВ-подмножеств удается собрать ТСВ системы (то есть доказать, что выполняются все требования к ТСВ).
Пусть даны ТСВ-подмножества M(i), которые управляют доступом субъектов S(i) к объектам 0(i) в соответствии с политикой безопасности P(i). Предположим, что нет объектов в системе, которые контролируются более, чем одним ТСВ-подмножеством. Здесь принимается та же точка зрения, как в главе VI, состоящая в том, что ТСВ-подмножества могут экспортировать объекты, подлежащие управлению другим ТСВ-подмножеством. Однако принятый и переданный объекты - это разные объекты, контролируемые разными ТСВ-подмножествами. При этом политика безопасности P(i) ТСВ-подмножества M(i) может отличаться от политики безопасности P(j) ТСВ-подмножества M(j). Однако все вместе должны составлять единую политику Р системы, причем каждое правило из Р должно поддерживаться определенной системой ТСВ-подмножеств.
Необходимо также предполагать, что каждый доверенный субъект, то есть субъект, который может нарушать правила P(i) является частью ТСВ-подмножества M(i).
Рассмотрим ограничения на зависимости ТСВ-подмножеств.
Определение. ТСВ-подмножество А прямо зависит (в своей правильности) от ТСВ-подмножества В тогда и только тогда, когда доводы о подтверждении правильности А (верификация установки А обозначается vA) частично или полностью основаны на предположении, что В установлена верно в соответствии соспецификацией В (обозначается sB).
Определение. ТСВ-подмножество А менее примитивно, чем ТСВ-подмножество В, если:
а) А прямо зависит от В;
б) существует цепочка ТСВ-подмножеств от А к В такая, что каждый элемент цепи прямо зависит от предыдущего элемента цепи.
Рассмотрим примеры, поясняющие понятие зависимости, взятые из "Розовой книги".
Пример 1. Пусть ТСВ-подмножество В предоставляет услугу в виде "файла", которым В управляет в соответствии с политикой Р(В), а ТСВ-подмножествоА использует В-файл для хранения информации. Если vA использует факт, что различные В-файлы действительно различаются и доступ к ним определяется политикой Р(В), то vA полагается на факт, что sB и В соответствуют друг другу. Тогда А прямо зависит от В.
Пример 2. Пусть А и В взаимно не доверяющие друг другу системы бронирования авиабилетов, расположенные отдельно и принадлежащие различным организациям. Предположим sA и sB дают возможность получить заказ на бронирование по сети от других систем, используя взаимно согласованный протокол. Пусть этот протокол полностью определен и соответствует sA и sB. Пусть также vA и vB с заданной степенью уверенности подтверждают, что А и В соответствуют своим спецификациям sA и sB. А не зависит в правильности своей установки от правильности установки В, так как sA - полная, то есть какая бы последовательность бит не пришла от В, sA определяет, что А должна делать, а vA демонстрирует, что именно это и делается. Аналогично, В не зависит от правильности А. Поэтому А и В не зависят одна от другой.
Пример 3. Пусть А является сервером электронной почты, а В управляет запросами в базу данных. Спецификация sA может совсем не упоминать систему управления базой данных, она просто определяет интерфейс почтовой системы. Однако в vA мы находим, что программа обеспечения А использует таблицы, предоставляемые В, для хранения сообщений А и В на различных, связанных машинах. Ни sB, ни vB не упоминают о почтовой системе. Как и в предыдущем примере, sB полностью определяет поведение В для всех получаемых последовательностей бит. Здесь А прямо зависит от В, но В не зависит от А. Отметим, что информационные потоки в обоих направлениях являются законными и никоим образом не компрометируют целостность В. Зависимость находится в другой плоскости от потока данных.
Этот пример замечателен тем, что анализ структуры элементов не позволяет выявить существование зависимости, при этом архитектура системы внешне совпадает с приведенной в примере 2 архитектурой взаимно независимых систем. Кроме того, этот пример показывает, что описания интерфейса не достаточно для выявления зависимостей.
Пример 4. Пусть А и В взаимно зависимые системы. А зависит от В и В зависит от А. Это значит, что правильность установки vA доказывается из предположения, что В установлена правильно в соответствии с sB. Также правильность установки vB доказывается из предположения, что А установлена правильно в соответствии с sA. Пусть vA и vB подтверждают правильность установки А и В. Однако отсюда не следует, что А и В функционируют правильно.
В самом деле, если А и В функционируют правильно относительно sA и sB, то vA и vB поддерживают правильность установки. Если А установлено неправильно по отношению к sA и В установлено неправильно по отношению к sB, то никто не мешает возникновению ситуации, когда vA подтверждает правильность исходя из того, что В не соответствует sB. Аналогично, vB подтверждает правильность установки sB, хотя А не соответствует sA. Тогда можно доказать, что vA и vB подтверждают правильность А и В, хотя А и В установлены неверно.
Для того, чтобы понять возникающую здесь коллизию, рассмотрим две системы бронирования билетов на самолеты А и В, как в примере 2. Предположим, что А содержит информацию об исходных пунктах и времени вылета всех полетов в США, а В - в Европе. Пусть sA включает утверждение, что А обеспечивает пассажирам услугу в подборе вылета по транзиту, минимизирующем время ожидания следующего полета. Пусть sB предлагает аналогичные услуги. Из утверждения А соответствует sA и В соответствует sB можно вывести истинность утверждения, что А соответствует спецификации sA в предоставлении услуги подбора транзитного рейса в Европе и Америке. Аналогичное утверждение можно вывести для В. Однако, если А хранит информацию в местном времени, а В - во времени по Гринвичу, то транзитный маршрут, составленный А и В на основе информации, полученной друг от друга, будет неправильным из-за различия во времени. То есть каждая система функционирует правильно, но результат неверен. Это происходит из-за того, что А и В зависимы.
Гарантии защищенности ТСВ-подмножеств имеют большое значение в проблеме построения единой ТСВ системы из ТСВ-подмножеств. В случае зависимых ТСВ-подмножеств менее примитивное ТСВ-подмножество может использовать объекты и субъекты, предоставленные более примитивным ТСВ-подмножеством. Потому первая проблема состоит в доказательстве того факта, что невозможны никакие изменения данных, критических для политики безопасности, или кодов ТСВ-подмножества. То есть никакая внешняя по отношению к ТСВ-подмножеству система (кроме, может быть, более примитивных ТСВ-подмножеств) не может инициировать произвольное изменение кодов ТСВ-подмножества или его структур данных. Вторая проблема состоит в доказательстве того, что данные, хранящиеся в ТСВ-подмножестве и критичные для политики безопасности, не могут изменяться иначе, чем в соответствии с логикой ТСВ-подмножества. Разумеется, эти доказательства возможны при условии правильности той информации, которая вносится в ТСВ-подмножество более примитивным ТСВ-подмножеством.
Ясно, что в доказательстве возможности построения единой ТСВ системы из ТСВ-подмножеств присутствуют условия не только на локальные свойства ТСВ-подмножеств, но также интегральные требования.
Суммируем перечень всех условий, которые необходимо выполнить, чтобы из семейства ТСВ-подмножеств можно было бы синтезировать ТСВ системы. Если, кроме нижеприведенных требований, выполняются требования какого-либо класса в стандарте "Оранжевая книга", то построенная таким образом система может быть аттестована по соответствующему классу.
Условия:
1. ТСВ-подмножества четко определены.
2. Политика безопасности системы распределена по ТСВ-подмножествам.
3. Каждое ТСВ-подмножество M(i) включает доверенные процессы по отношению к своей политике безопасности P(i).
4. Архитектура ТСВ-подмножеств четко определена .
5. Все ТСВ-подмножества занимают различные домены.
6.Во всех случаях примитивные ТСВ-подмножества поддерживают правильное функционирование монитора обращений в менее примитивном ТСВ-подмножестве.
7.2. ГАРАНТИРОВАННО ЗАЩИЩЕННЫЕ БАЗЫ ДАННЫХ.
Будем предполагать, что гарантированно защищенная база данных может быть инсталирована только на платформе гарантированно защищенной вычислительной системы. Тогда ТСВ всей системы получается из ТСВ-подмножества вычислительной системы и ТСВ-подмножества базы данных. Причем в возникающей здесь иерархической структуре ТСВ-подмножество вычислительной системы является более примитивным,чем ТСВ-подмножество базы данных.
Рассмотрим несколько примеров архитектур баз данных, позволяющих говорить о гарантированной защищенности.
Пример 1. Одноуровневая база данных. Пусть все пользователи имеют одинаковый допуск ко всей информации, содержащейся в базе данных и в вычислительной системе. В этом случае возможно применение базы данных общего назначения на охраняемой вычислительной системе. В случае высокого класса хранящейся в базе данных информации, согласно "Требованиям" к применению "Оранжевой книги" должна использоваться система класса С2 (наличие аудита).
Пример 2. Многоуровневая база данных с ядерной архитектурой. Эта архитектура подробно рассматривалась в параграфах 1.6-1.7, 5.5 и в ряде примеров. Исследования по данной архитектуре проводились System Research Institute группой ученых под руководством D.Denning и T.Lunt. Цель исследований: построить гарантированно защищенную базу данных по классу А1. Данная архитектура может быть представлена следующей схемой.
На этой схеме ТСВ вычислительной системы разрешает формировать отношения, содержащие информацию, разрешенную для данного класса пользователя. Сама система управления базой данных является системой общего пользования. Однако в данной архитектуре серьезной проблемой является полиинстантинация. Вместе с тем, здесь на системном уровне видно, как доказывать, что база данных поддерживает MLS-политику (на уровне ядра реализована модель не влияния G - М).
Пример 3. Модификацией архитектуры примера 2 является дублирующая архитектура. Она основана на гарантированно правильном разделении пользователей.
Фактически система представляет композицию одноуровневых баз данных примера 1. Здесь также на системном уровне видно, как доказывать защищенность системы.
Пример 4. Исторически одной из первых была предложена архитектура "базы данных с замком целостности". Это разработка ВВС США, анонсированная в1983 г. Схематически данная архитектура может быть представлена следующим образом.
Недостатком этой архитектуры является то, что *-свойство приходится нарушать почти в каждой транзакции.
Пример 5. Базы данных, которые американцы называют архитектурой с "гарантированно защищенным субъектом". Эти системы предполагают наличие ТСВ-подмножеств в самой базе данных, причем ТСВ базы данных реализует свою составляющую политики безопасности.
К этому классу относятся системы управления базами данных ORACLE, INFORMIX, INGRES и т.д.
Основная сложность в том, что описания политик безопасности и доказательства их поддержки недоступны. Кроме того, большой объем программного обеспечения не позволяет провести достаточный анализ.
Пример 6. Базы данных с распределенным доменом защиты. Используется идея "Красной книги" о распределенной NTCB, как совокупность ТСВ компонент. Этот подход можно изобразить на схеме.
Каждая компонента на этой схеме гарантировано защищена.
Литература
I. Department of Defense Trusted Computer System Evaluation Criteria, DoD, 1985.
2. Computer Security Requirements. Guidence for Applying the Department of Defense Trusted Computer System Evaluation Criteria in Specific Environments, DoD, 1985.
3. Trusted Network Interpretation of the Trusted Computer System Evaluation Criteria, NCSC, 1987.
4. Trusted Database Management System Interpretation of the Trusted Computer System Evaluation Criteria, NCSC, 1991.
5. D. Denning, Cryptography and Data Security, Addison Wesley, Reading (MA), 1983.
6. Data Communications and Networks 3, Edited byR.L. Brewster, Redwood Books, Trowbridge, Wiltshire. 1994.
7. D.Russell, G.T.Gangemi Sr., Computer Security Basics, O'Reilly & Associates, Inc., 1991.
8. D. Denning, An Intrution Detection Model, IEEE Trunsactions on Software Engineering, v. SE-13,¹ I, 1987, pp 222-232.
9. J.A. Goguen, J. Meseguer, Securiti Policies and Securiti Models, Proceedings of the 1982 Sympsium
on Security and Privacy, IEEE, April 20-21, 1982.Oakland, CA, IEEE Catalog ¹82CHI753, pp. I 1-26.
10. J. McLean, Reasoning About Security Models, Proceedings, IEEE Symposium on Privasy and Security, Oakland, CA, April 27-29, 1987, IEEE Computer Society Press, 1987, pp. 123-131.
11. J Fellows, J. Hemenway, The Architecture of a Distributed Trusted Computing Base, Proceedings, 10th National Computer Security Conference, Baltimore, MD, September 21-24, 1987, National Bureau of Standards/National Computer SecurityCenter, 1987, pp. 68-77.
12. D. Denning, et al., Views for Multilevel Database Security, IEEE Trunsactions on Software Engineering, v. SE-13, ¹ 2, 1987, pp 129-140.
13. D. Denning, et al., Multilevel Relational DataModel, Proceedings, IEEE Symposium on Privasy and Security, Oakland, CA, April 27-29, 1987, IEEE Computer Society Press, 1987, pp. 220-242.
14. R.R Kenning, S.A Walker, Computer Architecture and Database Security, Proceedings, 9th National Computer Security Conference, Gaithersburg, MD, September 15-18, 1986, National Bureau of Standards/National Computer Security Center,1986, pp. 216-230.
15. R. Schell, D. Denning, Integrity in Trusted Database Systems, Proceedings, 9th National Computer Security Conference, Gaithersburg, MD, September 15-18, 1986, National Bureau of Standards/National Computer Security Center,1986, pp. 30-36.
16. S.G. Aki, D. Denning, Checking Classification Constraints for Consistency and Completeness, Proceedings, IEEE Symposium on Privasy and Security, Oakland, CA, April 27-29, 1987, IEEE Computer Society Press, 1987, pp. 196-201.
17. T-A. Su, G. Ozsoyoglu, Data Dependencies and Inference Control in Multilevel Relational Database Systems, Proceedings, IEEE Symposiumon Privasy and Security, Oakland, CA, April 27-29,1987, IEEE Computer Society Press, 1987, pp. 202-211.
МОСКОВСКАЯ ГОСУДАРСТВЕННАЯ АКАДЕМИЯ ПРИБОРОСТРОЕНИЯ И ИНФОРМАТИКИ КАФЕДРА АВТОМАТИЗИРОВАННЫХ СИСТЕМ ОБРАБОТКИ ИНФОРМАЦИИ И УПРАВЛЕНИЯ (ИТ-7) "Методы и средства защиты компьютерной информации" Методические указания к выполнению к