- •Иногда знание общих законов способно
- •Введение
- •Глава 1
- •1.1. Основные понятия и определения
- •1.3. Структуризация методов обеспечения информационной безопасности
- •1.4. Основные методы реализации угроз информационной безопасности
- •1.5. Основные принципы обеспечения
- •Список литературы к главе 1
- •Глава 2
- •2.1. Построение систем защиты от угрозы нарушения конфиденциальности информации. Организационно-режимные меры защиты носителей информации в ас.
- •Парольные системы для защиты от несанкционированного доступа к информации
- •Общие подходы к построению парольных систем
- •Передача пароля по сети
- •Криптографические методы защиты
- •Утечки информации по техническим каналам:
- •Требования к скзи.
- •Способы и особенности реализации криптографических подсистем
- •Криптографическая защита транспортного уровня ас
- •Особенности сертификации и стандартизации криптографических средств.
- •Защита от угрозы нарушения конфиденциальности на уровне содержания информации.
- •2.2. Построение систем защиты от угрозы нарушения целостности информации
- •Целостность данных в ас
- •Модель контроля целостности Кларка-Вилсона
- •Защита памяти
- •Барьерные адреса
- •Динамические области памяти
- •Адресные регистры
- •Страницы и сегменты памяти
- •Цифровая подпись
- •Защита от угрозы нарушения целостности информации на уровне содержания
- •2.3. Построение систем защиты от угрозы отказа доступа к информации
- •Защита от сбоев программно-аппаратной среды
- •Обеспечение отказоустойчивости по ас
- •Предотвращение неисправностей в по ас.
- •2.4. Построение систем защиты от угрозы раскрытия параметров информационной системы
- •2.5. Методология построения защищенных ас
- •Иерархический метод разработки по ас
- •Исследование корректности реализации и верификация ас
- •Теория безопасных систем (тсв)
- •Глава 3 политика безопасности
- •3.1. Понятие политики безопасности
- •3.2. Понятия доступа и монитора безопасности
- •3.3. Основные типы политики безопасности
- •3.4. Разработка и реализация политики безопасности
- •3.5. Домены безопасности
- •Глава 4
- •4.1. Модель матрицы доступов hru
- •4.2. Модель распространения прав доступа take-grant
- •Санкционированное получение прав доступа.
- •Возможность похищения прав доступа
- •Расширенная модель Take-Grant
- •4.3. Модель системы безопасности белла-лападула Основные положения модели
- •Пример некорректного определения безопасности в модели бл
- •Подход Read-Write (rw)
- •Подход Transaction (т)
- •Проблемы использования модели бл
- •Модель Low-Water-Mark
- •4.4. Модель безопасности информационных потоков
- •Пример автоматной модели системы защиты gm
- •Глава 5 основные критерии защищенности ас. Классификация систем защиты ас.
- •5.1. Руководящие документы государственной технической комиссии россии
- •Основные положения концепции защиты свт и ас от нсд к информации.
- •Показатели защищенности средств вычислительной техники от нсд.
- •5.2. Критерии оценки безопасности компьютерных систем министерства обороны сша ("оранжевая книга")
- •Общая структура требований tcsec
- •5.3. Европейские критерии безопасности информационных технологий
- •5.4. Федеральные критерии безопасности информационных технологий
- •Функциональные требования к продукту информационных технологий
- •Структура функциональных требований
- •Ранжирование функциональных требований
- •Требования к процессу разработки продукта информационных технологий
- •Требования к процессу сертификации продукта информационных технологий
- •Заключение
Подход Transaction (т)
В данном подходе используются определения безопасных состояния, реализации и системы подхода Read-Write. Однако в подходе Transaction основной акцент делается на определении свойств безопасности функции переходов T. При этом на T накладывается дополнительное ограничение: за один шаг работы системы вносится только одно изменение в один из параметров, т.е. изменяется на один элемент множество доступов или одно из значений одной из функций. При этом остальные параметры остаются неизменными.
Определение 20. Функция переходов T(q,(b,f))=(b*,f*) обладает ss-свойством, если выполнены условия:
• если (s,o, read) b*\b, to fs(s)=fo(o) и f*=f;
• если fs(s)fs*(s), то fo*= fo, b*=b и (s,o,read)b. где fs*(s)<fo(o) ,
• если fo(o) fo*(o), то fs*=fs, b*=b и (s, o,readb, где fs(s)<fo*(o).
Определение 21. Функция переходов T(q,(b,f))=(b*,f*) обладает
*-свойством, если выполнены условия:
• если {(s,x,read),(s,y,wrife)}b* и {(s,x,read), (s,y,write)}b. то fo(y) fo(х) и f=f*;
• если fo*(y) fo(y), то b=b*. или {(s,x,read),(s,y,write)} b, где fo*(y) fo(y),
или {(s, у, read), (s,x, write)} b, где fo(y) fo*(y).
Определение 22. Функция переходов T безопасна, если она обладает ss-свойством и *-свойством.
Теорема BST-T. Система (V,T,zo) безопасна для безопасного начального состояния zo, ее функция переходов безопасна.
Доказательство. По аналогии с доказательством теоремы А1 необходимо показать, что если функция переходов T(q,(b,f))=(b*,f*)безопасна, то состояние (b*, f*) безопасно в смысле, определенном в подходе Read-Write. Этот факт, очевидно, следует из условий определений 20 и 21. Таким образом, при безопасном начальном состоянии любая реализация системы, а следовательно, и система в целом будут безопасными.
В рамках подхода Transaction можно рассмотреть вопрос о возможностях смены уровня безопасности субъектов и объектов. Пусть xS, cs(x) S -множество субъектов, имеющих право менять уровень допуска субъекта х; eO, сo(у)S-множество субъектов, имеющих право менять гриф секретности объекта у. В этом случае в функции переходов необходимо внести еще один параметр, определяющий субъекта, дающего запрос системе.
Определение 23. Функция переходов T(q,(b,f))=(b*,f*) безопасна в смысле изменения уровней, если выполнены условия:
• если fs*(x)fs(x), то scs(x);
• если fo*(y)fo(y), то sco (у).
Таким образом, задавая множества cs(x) и сo(у), можно рассматривать случаи. когда все субъекты могут менять уровни безопасности, никто не может, или только системный администратор может менять уровни безопасности.
Проблемы использования модели бл
Кроме отмеченной выше проблемы некорректного определения безопасности в модели БЛ возможно возникновение трудностей иного рода, возникающих при использовании модели БЛ в реальных компьютерных системах. Ниже по [12] мы рассмотрим ряд примеров программ, написанных на некотором абстрактном языке программирования высокого уровня, иллюстрирующих трудности практического использования положений классической модели БЛ.
Пример 1. Временной канал утечки информации. Пусть:
F1 - секретный файл, который может содержать или запись "A" или запись "В";
F2 - несекретный файл;
S1 - субъект, работающий по программе:
Process S1 (F1: file):
Open F1 for read
While F1 ="A" Do End
Close F1
End:
S2-субъект злоумышленник, работающий по программе: Process S2(F1: file, F2: file): Start S1(F1) Wait10 seconds Open F2 for write
If slop S1 Then
Write "B" to F2
Else
Write "A" to F2
End if
Close F2
End;
Субъект-злоумышленник S2, не открывая на чтение секретные файлы, запускает процесс S1 и в зависимости от результатов его выполнения (процесс S1 либо сразу завершится, либо "зависнет") записывает информацию в несекретный файл. При этом предполагается, что злоумышленник S2 имеет уровень доступа секретно, так как S1 наследует права запустившего его процесса.
Пример 2. Каналы утечки информации через локальную и логическую переменные.
Пусть F1 и F2- секретный и несекретный файлы соответственно. Приведенные ниже процедуры реализуют каналы утечки информации через локальную переменную (процедура P1) и логическую переменную (процедура Р2).
Procedure P1 (F1: file. F2: file):
Open F1 for read
Read A from F1
Close
Open F2 for write
Write A toF2
Close F2
End:
Procedure P2 (F1: file. F2: file):
// Считаем, что файл F1может содержать либо запись "А", либо запись"B"
Open F1 for read
If F1= "A" Then
Close F1
Open F2 for write
Write "A"to F2
Else
Close F1
Open F2 for write
Write "B" to F2
End If
Close F2
End;
Для предотвращения возникновения каналов утечки информации через локальные или логические переменные при написании программ можно предложить руководствоваться следующими рекомендациями:
открывать все файлы, необходимые для работы программы вначале ее выполнения;
закрывать все файлы в конце выполнения программы;
непосредственную обработку информации из открытых файлов осуществлять во внутренних процедурах, использующих только локальные переменные.
Таким образом, без дополнительных уточнений свойств безопасности и порядка написания кода программ классическая модель БЛ не способна предотвратить возникновение некоторых каналов утечки информации. В тоже время слишком строгая политика безопасности может привести к трудностям или даже невозможности практического использования системы защиты. Кроме того, как уже отмечалось выше, доопределение и усложнение свойств безопасности также несет в себе скрытую угрозу.