Основная теорема безопасности Белла-ЛаПадулы 


Мы поможем в написании ваших работ!



ЗНАЕТЕ ЛИ ВЫ?

Основная теорема безопасности Белла-ЛаПадулы



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

1. Начальное состояние безопасно.

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

- Если и , то

- Если и , то

- Если и , то

- Если и , то

Доказательство теоремы

1. Докажем необходимость утверждения.

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

2. Докажем достаточность утверждения.

Система может быть небезопасной в двух случаях:

  1. В случае если начальное состояние небезопасно. Однако данное утверждение противоречит условию теоремы.
  2. Если существует небезопасное состояние , достижимое из безопасного состояния путём применения конечного числа запросов из . Это означает, что на каком-то промежуточном этапе произошёл переход , где – безопасное состояние, а - небезопасное. Однако условия 1-4 делают данный переход невозможным.

Недостатки:

Деклассификация

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

Правило сильного спокойствия - уровни безопасности субъектов и объектов никогда не меняются в ходе системной операции.

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

Удаленное чтение

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


21. Основные положения критериев TCSEC. Фундаментальные требования компьютерной безопасности. Требования классов защиты.

 

Критерии оценки безопасности компьютерных систем" (Trusted Computer System Evaluation Criteria -TCSEC), получившие неформаль­ное, но прочно закрепившееся название "Оранжевая книга", были разра­ботаны и опубликованы Министерством обороны США в 1983 г.

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

Общая структура требований TCSEC

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

Политика безопасности

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

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

Подотчетность (аудит)

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

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

Гарантии (корректность)

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

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



Поделиться:


Последнее изменение этой страницы: 2017-02-22; просмотров: 835; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 18.227.0.192 (0.011 с.)