- •П.Н. Девянин, о.О. Михальский, д.И. Правиков, а.Ю. Щербаков Теоретические основы компьютерной безопасности
- •Глава 1 структура теории компьютерной безопасности 8
- •Глава 2 методология построения систем защиты информации в ас 22
- •Глава 3 политика безопасности 72
- •Глава 4 модели безопасности 95
- •Глава 5 основные критерии защищенности ас. Классификация систем защиты ас 123
- •Введение
- •Глава 1структура теории компьютерной безопасности
- •1.1Основные понятия и определения
- •1.2 Анализ угроз информационной безопасности
- •1.3 Структуризация методов обеспечения информационной безопасности
- •1.4 Основные методы реализации угроз информационной безопасности
- •1.5Основные принципы обеспечения информационной безопасности в ас
- •1.6Причины, виды и каналы утечки информации
- •Глава 2методология построения систем защиты информации в ас
- •2.1 Построение систем защиты от угрозы нарушения конфиденциальности информации Организационно-режимные меры защиты носителей информации в ас
- •Передача пароля по сети
- •Криптографические методы защиты
- •Утечки информации по техническим каналам:
- •Требования к скзи
- •Требования надежности
- •Требования к средам разработки, изготовления и функционирования скзи.
- •Криптографическая защита транспортного уровня ас
- •Криптографическая защита на прикладном уровне ас
- •Особенности сертификации и стандартизации криптографических средств
- •Защита от угрозы нарушения конфиденциальности на уровне содержания информации
- •2.2Построение систем защиты от угрозы нарушения целостности информации Организационно-технологические меры защиты целостности информации на машинных носителях
- •Модель контроля целостности Кларка-Вилсона
- •Защита памяти
- •Барьерные адреса
- •Динамические области памяти
- •Адресные регистры
- •Страницы и сегменты памяти
- •Цифровая подпись
- •Защита от угрозы нарушения целостности информации на уровне содержания
- •2.3 Построение систем защиты от угрозы отказа доступа к информации
- •Защита от сбоев программно-аппаратной среды
- •Обеспечение отказоустойчивости по ас
- •Предотвращение неисправностей в по ac
- •Защита семантического анализа и актуальности информации
- •2.4 Построение систем защиты от угрозы раскрытия параметров информационной системы
- •2.5 Методология построения защищенных ас
- •Иерархический метод разработки по ас
- •Исследование корректности реализации и верификация ас
- •Теория безопасных систем (тсв)
- •Список литературы к главе 2
- •Глава 3политика безопасности
- •3.1 Понятие политики безопасности
- •3.2 Понятия доступа и монитора безопасности
- •3.3 Основные типы политики безопасности
- •3.4 Разработка и реализация политики безопасности
- •3.5Домены безопасности
- •Список литературы к главе 3
- •Глава 4модели безопасности
- •4.1 Модель матрицы доступов hru Основные положения модели
- •Безопасность системы
- •4.2 Модель распространения прав доступа take-grant Основные положения модели
- •Возможность похищения прав доступа
- •Расширенная модель Take-Grant
- •4.3 Модель системы безопасности белла-лападула Основные положения модели
- •Пример некорректного определения безопасности в модели бл
- •Эквивалентные подходы к определению безопасности в модели бл
- •Подход Read-Write (rw)
- •Подход Transaction (т)
- •Проблемы использования модели бл
- •Модель Low-Water-Mark
- •4.4Модель безопасности информационных потоков
- •Пример автоматной модели системы защиты gm
- •Список литературы к главе 4
- •Глава 5основные критерии защищенности ас. Классификация систем защиты ас
- •5.1Руководящие документы государственной технической комиссии россии
- •5.2 Критерии оценки безопасности компьютерных систем министерства обороны сша ("оранжевая книга")
- •Глава 5 Основные критерии защищенности ас. Классификация систем
- •Демонстрационный материал к учебной теме “Криптосистема rsa” Введение
- •Системные требования
- •Описание программы
4.3 Модель системы безопасности белла-лападула Основные положения модели
Классическая модель Белла-Лападула (БЛ) построена для анализа систем защиты, реализующих мандатное (полномочное) разграничение доступа. Возможность ее использования в качестве формальной модели таких систем непосредственно отмечена в критерии TCSEC ("Оранжевая книга"). Модель БЛ была предложена в 1975 г. [З]. Однако ее полное описание до сих пор недоступно, поэтому мы приведем его в урезанном виде по [1] и [10].
Пусть определены конечные множества: S-множество субъектов системы (например, пользователи системы и программы): О-множество объектов системы (например, все системные файлы); R = {read, write. append, execute}-множество видов доступа субъектов из S к объектам из О, где read-доступ на чтение, write-на запись, append-на запись в конец объекта, execute- на выполнение. 134
Обозначим:
– множество возможных множеств текущих
доступов в системе;
М – матрица разрешенных доступов,
где
– разрешенный доступ субъекта s
к объекту о;
L -множество уровней секретности, например L={U,C,S,TS}, где U < С < S < TS;
– тройка функций
,
определяющих:
• fs: S→L- уровень допуска субъекта;
• fo: 0→L- уровень секретности объекта;
• fc:
S→L-текущий уровень допуска
субъекта, при этом
;
H – текущий уровень иерархии объектов (далее не рассматривается);
– множество состояний системы;
Q – множество запросов системе;
D – множество решений по запросам, например {yes, no, error};
– множество действий системы, где
четверка
означает, что система по запросу q
с ответом d перешла
из состояния v1
в состояние v2;
Nо – множество значений времени (Nо =0, 1, 2, ...);
X – множество
функций
,
задающих все возможные последовательности
запросов к системе;
Y – множество функций
,
задающих все возможные последовательности
ответов системы по запросам;
Z - множество функций
,
задающих все возможные последова-тельности
состояний системы.
Определение 1.
называется системой, если выполняется
тогда и только тогда, когда
для каждого,
где z0 – начальное
состояние системы. При этом каждый набор
называется реализацией системы, а
– действием системы
.
Безопасность системы определяется с помощью трех свойств:
1) ss-свойства простой безопасности (simple security);
2) * – свойства "звезда";
3) ds – свойства дискретной безопасности (discretionary security).
Определение 2. Доступ
обладает ss-свойством относительно
,
если выполняется одно из условий:
•
;
•
и
.
Определение 3. Состояние системы
обладает ss-свойством, если каждый
элемент
обладает ss-свойством относительно
f.
Определение 4. Доступ удовлетворяет *-свойству относительно , если выполняется одно из условий:
• r = execute;
• r = append и fo(o)=fc(s);
• r=read и fc(s) =fo(o);
• r=write и fc(s) =fo{o).
Определение 5. Состояние системы обладает *-свойством, если каждый элемент обладает *-свойством относительно f.
Определение 6. Состояние системы
обладает *-свойством, относительно
подмножества
,
если каждый элемент
,
где
обладает *-свойством относительно f.
При этом S\S'
называются множеством доверенных
субъектов, т.е. субъектов, имеющих право
нарушать политику безопасности.
Определение 7. Состояние системы
обладает ds-свойством, если для
каждого элемента
выполняется
.
Определение 8. Состояние системы
называется безопасным, если обладает
*-свойством относительно S', ss-свойством
и ds-свойством.
Определение 9. Реализация системы обладает ss-свойством (*-свойством, ds-свойством), если в последовательности (z0,z1, ...) каждое состояние обладает ss-свойством (*-свойством, ds-свойством).
Определение 10. Система
обладает ss-свойством (*-свойством,
ds-свойством), если каждая ее реализация
обладает ss-свойством (*-свойством,
ds-свойством).
Определение 11. Система называется безопасной, если она обладает ss-свойством, *-свойством, ds-свойством одновременно.
Прокомментируем введенные выше свойства безопасности системы. Во-первых, из обладания доступом *-свойством относительно f следует обладание этим доступом ss-свойством относительно f. Во-вторых, из обладания системой ss-свойством следует, что в модели БЛ выполняется запрет на чтение вверх, принятый в мандатной (полномочной) политике безопасности. Кроме того, ss-свойство не допускает модификацию с использованием доступа write, если fs(s) <fo(o). Таким образом, функция fs(s) определяет для субъекта s верхний уровень секретности объектов, к которым он потенциально может получить доступ read или write.
В-третьих, поясним *-свойство. Если субъект s может понизить свой текущий доступ до fc(s) =fo(o), то он может получить доступ write к объекту о, но не доступ read к объекту о', с уровнем fo(o') >fc(s). Хотя при этом, возможно, выполняется fs(s) =fo(o'), и в каких-то других состояниях системы субъект s может получить доступ read к объекту о'. Таким образом, *-свойство исключает появление в системе канала утечки информации сверху вниз (пример на рис. 4.10) и соответствует требованиям мандатной (полномочной) политики безопасности,
Рис. 4.10. Иллюстрации к *-свойству
Проверка безопасности системы по определению в большинстве случаев не может быть реализована на практике в связи тем, что при этом требуется проверка безопасности всех реализаций системы, а их бесконечно много. Следовательно, необходимо определить и обосновать иные условия безопасности системы, которые можно проверять на практике. В классической модели БЛ эти условия определяются для множества действий системы W.
Теорема А1. Система
обладает ss-свойством для любого
начального состояния zo,
обладающего ss-свойством, тогда и
только тогда, когда
удовлетворяет условиям:
Условие 1.
обладает ss-свойством относительно
f*.
Условие 2. Если
и не обладает ss-свойством относительно
f*, то
.
Доказательство.
Достаточность. Пусть выполнены
условия 1 и 2 и пусть
– произвольная реализация системы.
Тогда
,
где
для
.
Для любого
выполняется или
,
или
.
Из условия 1 следует, что состояние
системы zt+1
пополнилось доступами, которые обладают
ss-свойством относительно f*.
Из условия 2 следует, что доступы из bt,
которые не обладают ss-свойством
относительно f*,
не входят в bt+1.
Следовательно,
обладают ss-свойством относительно
f и по определению состояние zt+1
обладает ss-свойством для
.
Так как по условию и состояние z0
обладает ss-свойством, то выбранная
нами произвольная реализация (x,y,z)
также обладает ss-свойством.
Достаточность доказана.
Необходимость. Пусть система
обладает ss-свойством. Будем считать,
что в множество W
входят только те действия системы,
которые используются в ее реализациях.
Тогда
и
.
Так как реализация системы (x,y,z)
обладает ss-свойством, то и состояние
обладает ss-свойством по определению.
Следовательно, условия 1 и 2 очевидно
выполняются. Необходимость доказана.
•
Теорема А2. Система
обладает *-свойством относительно
для любого начального состояния z0,
обладающего *-свойством относительно
S', тогда и только тогда, когда
удовлетворяет условиям:
Условие 1.
обладает *-свойством относительно f*.
Условие 2.
,
если
и не обладает *-свойством относительно
f*, то
.
Доказательство. Аналогично доказательству теоремы А1. •
Теорема A3. Система обладает ds-свойством для любого начального состояния z0, обладающего ds-свойством, тогда и только тогда, когда удовлетворяет условиям:
Условие 1.
,
выполняется
.
Условие 2. Если и , то .
Доказательство. Аналогично доказательству теоремы А1.
137
Теорема BST (Basic Security Theorem). Система безопасна тогда и только тогда, когда z0 безопасное состояние и множество действий системы W удовлетворяет условиям теорем А1, А2, A3.
Доказательство. Теорема BST следует из теорем А1, А2, A3.
Описанная выше классическая модель БЛ предлагает общий подход к построению систем, реализующих мандатную (полномочную) политику безопасности. В модели БЛ определяется, какими свойствами должны обладать состояния и действия системы, чтобы она была безопасной согласно определению 11. В то же время в модели не указывается конкретно, что должна делать система по запросам на доступ субъектов к объектам при переходе из состояния в состояние, как конкретно должны при этом изменяться значения элементов модели.
Пример 1. Воспользуемся рис. 4.10. Пусть субъект s запрашивает доступ read к объекту о'. В данной ситуации система может выбрать один из двух возможных путей:
1) запретить субъекту s запрашиваемый им доступ read на объект о';
2) закрыть доступ write субъекта s к объекту о; повысить текущий уровень секретности fc(s) до High; разрешить субъекту s запрашиваемый им доступ read к объекту о'.
Каждый из описанных путей соответствует требованиям безопасности модели БЛ.
В реальных системах возможны более сложные ситуации, чем ситуация, описанная в примере 1. Кроме того, возможно использование в системе каких-то других видов доступа субъектов к объектам, которые потребуют доопределения свойств безопасности, что не всегда легко сделать. В связи с этим большое значение имеет корректное определение свойств безопасности.
Ниже по [10] приводится пример некорректного определения безопасности в модели БЛ, где вместо *-свойства используется абсурдное с точки зрения здравого смысла *-свойство. Однако при этом не возникает никаких противоречий в логике доказательства теорем, определяющих условия безопасности системы.
