Лекция 19 Метод генерации изолированной программной среды
Для создания гарантированно защищенной КС (в смысле выполнения заданной политики безопасности) необходимо:
1. Убедиться в попарной корректности субъектов, замыкаемых в ИПС (либо убедиться в корректности любого субъекта относительно МБО и МБС);
2. Спроектировать и реализовать программно (или программно-аппаратно) МБС так, чтобы:
— для любого субъекта и любого объекта производился контроль порождения субъектов (т.е. чтобы реализация МБС соответствовала его определению);
— порождение любого субъекта происходило с контролем неизменности объекта-источника.
3. Реализовать МБО в рамках априорно сформулированной политики безопасности.
Важную роль при проектировании ИПС играет свойство КС, заключающееся в поэтапной активизации субъектов из объектов различного уровня представления информации. Рассмотрим в таблице 4.1 иерархию уровней при загрузке операционной системы.
В общем случае можно говорить о рекурсивной структуре объектов некоторого уровня, вмещающей объекты предыдущего уровня. На нулевом уровне первичный объект (элементарная структура нижнего уровня) в таблице 1 соответствует термину «сектор».
С учетом иерархической структуры представления объектов можно говорить о том, что в начальные этапы активизации КС декомпозиция на субъекты и объекты динамически изменяется. Следовательно, основная теорема ИПС может быть примёнима только на отдельных интервалах времени, когда уровень представления объектов постоянен и декомпозиция фиксирована. Можно утверждать, что ППС, действующую от момента активизации до момента окончания работы КС, невозможно сформировать в начальный момент активизации КС.
Пусть в КС выделяется конечное число уровней представления объектов U={0,….,R}, R — максимальный уровень представления объекта.
С точки зрения выполнения условий безопасности имело бы смысл говорить о некотором «стационарном» состоянии КС, когда в отображениях Stream и Create участвуют только объекты уровня R. Тогда реализация МБС может быть значительно упрощена (в том смысле, что все аргументы-объекты операции Create имеют тот же уровень).
Необходимо обратить внимание на то, что такое требование, с одной стороны, может накладывать ограничительные условия на свойства прикладного ПО (невозможность инициирования потоков, включающих объекты уровня менее R, прикладными программами), а с другой стороны, быть следствием проектировочных решений реализации субъекта, локализованного в ядре операционной системы (примером является ОС Windows 4.0, запрещающая операции ниже уровня «файл» со стороны субъектов прикладного уровня).
Практическая реализация всех операционных систем позволяет выделить две фазы их работы: активизация субъектов с ростом уровня представления объектов (фаза загрузки или начальная фаза) и фаза стационарного состояния (когда уровень представления объектов не увеличивается). Конечно, необходимо сделать оговорку, касающуюся возможности реализации Потоков к объектам нижнего уровня (операционные системы типа DOS, в которых возможна операция с любым объектом нижнего уровня (сектор) из программ прикладного уровня).
Тогда практическая реализация ИПС может состоять из двух этапов: предопределенное выполнение начальной фазы, включающее в себя момент активизации МБС (и МБО), и работа в стационарной фазе в режиме ИПС (возможно, с, контролем неизменности объектов-источников).
Введем понятие последовательности активизации компонент КС. Смысл вводимых понятий и формулируемых ниже утверждений состоит в необходимости приведения субъектов КС в одно и то же состояние после активизации первичного субъекта аппаратно-программного уровня, или, иначе говоря, в задании предопределенной последовательности активизации субъектов КС.
Обозначим: Zl— последовательность пар (i, j)t ( t= 0, 1, 2,..., 1-1 — моменты времени) длины 1, такие, что Create (Si, Оj)[t]->Sm [t+1].
Обозначим также:
Sz - множество всех субъектов, включенных в последовательность Zl,
Оz - множество всех объектов, включенных в последовательность Zl.
Для многопотоковых КС можно рассматривать несколько (возможно, зависимых друг от друга) последовательностей Zl и соответственно множеств Sz и Оz.
Состоянием КС в момент времени t называется упорядоченная совокупность состояний субъектов.
Напомним, что каждый объект есть слово в априорно определенном языке, а понятие состояния субъекта сформулировано выше.
Состояние КС в моменты времени tx1 и tх2 (tx1 и tх2 исчисляются для двух отрезков активности КС от нулевого момента активизации КС t01 и t02 — например, включения питания аппаратной части) одинаково, если:
1. tx1=tx2,
2. тождественны субъекты Si [t01] и Si [t02],
З. неизменньт все объекты из множества Оz,
4. неизменна последовательность Z L.
Необходимо заметить, что последовательность Zl локализуется в некотором объекте либо совокупности объектов (например, для DOS последовательность активизации субъектов предопределена содержанием файлов АUТОЕХЕС.ВАТ и СОNFIG.SYS) и неизменность последовательности Zl тождественна неизменности указанных объектов, для ОС Windows NT последовательность активизации компонент определена содержанием соответствующих ключей реестра (registry).
Пусть в последовательности Zl можно выделить zi такое, что для любого Zk, k> i отображений Stream и Create используют только объекты уровня R. Другими словами, с момента времени i наступает стационарная фаза функционирования КС.
В этих условиях, а также при попарной корректности субъектов и действии МБС с контролем неизменности объектов- источников на уровне R с момента времени m > k верно:
При условии неизменности Zl и неизменности объектов из Оz в КС с момента времени установления неизменности Zl и Оz действует изолированная программная среда.
Рассмотрим процесс практического проектирования защищенного фрагмента КС.
Первоначально необходимо убедиться в выполнении условий корректности или абсолютной корректности для субъектов, участвующих в порождении ИПС. Указанные субъекты в основном могут быть локализованы на уровне программно-аппаратной компоненты ЭВМ (программы ПЗУ, загрузчики операционных сред), т.е. работать на уровне, близком к взаимодействию с оборудованием КС, либо на уровне операционной средs. Доказательство корректности субъектов программно-аппаратного уровня значительно отличается от соответствующих доказательств для субъектов прикладного уровня. В связи с этим выделим проверку условий корректности субъектов в два шага. Шагом 1 назовем доказательство корректности субъектов программно-аппаратного уровня. Понятие модуль обозначает реализацию объекта источника, а совокупность субъекта, порожденного из объекта источника и всего множества ассоциированных с этим субъектом объектов в течение всего времени существования субъекта, называете 1 как правило, процессом (или задачей, заданием).
Далее необходимо определить состав программных средств базовой вычислительной среды, т.е. определить конкретную операционную среду, дополнительные программные средства сервиса (например программные оболочки или средства теле - коммуникации) и программные средства поддержки дополнительного оборудования (программы управления принтером и др.). После этого наступает самый трудоемкий этап (Шаг 2), на котором необходимо убедиться в корректности субъектов описанного базового набора программных средств. При этом важно заметить следующее.
В составе ПО КС не должно быть целого класса возможностей — назовем их инструментальными. Прежде всего - это возможность изменения состояния ассоциированных объектов со стороны субъекта (например, изменение содержимого оперативной памяти) других субъектов (изменение содержания подразумевает существование операций Stream типа запись), возможность инициирования и прекращения выполнения процессов нестандартным образом (помимо механизмов операционной среды). Кроме того, при реализации МБС и МБО на стационарной фазе функционирования КС необходимо отсутствие в любых субъектах, замкнутых в ИПС, операций порождения потоков Stream к объектам уровня k <R.
Обобщенно достаточные условия к базовому набору ПО можно сформулировать следующим утверждением.
для того чтобы ИПС поддерживалась в течение всего времени активности КС, достаточно, чтобы в составе программного обеспечения, могущего быть инициированным в ИПС, не было функций порождения субъектов и прекращения их работы, кроме заранее предопределенных при реализации МБС, и не существовало возможностей влияния на среду выполнения (под средой выполнения понимается множество ассоциированных объектов) любого процесса, а также инициирования потоков к объектам логического уровня менее R.
Легко видеть, что данное утверждение есть собранные воедино условия выполнения приводимых выше утверждений. Поясним требование невозможности прекращения выполнения процесса каким-либо иным образом, кроме предопределенного. В данном случае необходимо учитывать, что во множестве субъектов, замкнутых в ИПС, выделены два особых субъекта — МБС и МБО. Прекращение существования МБС означает нарушение условия замкнутости среды, а прекращение существования МБО означает допустимость потоков множества Л т.е. несанкционированный доступ. Шаг З заключается в проектировании и разработке программных или программно-аппаратных средств защиты в КС, а затем и их тестировании. Он подразумевает проектирование и реализацию в заданном множестве субъектов МБС и МБО.
Практически шаги 1—З могут быть выполнены исходя из описанных в литературе методик разработки и тестирования ПО.
Шаг 4 заключается в «замыкании» всего комплекса программного обеспечения, включая, и средства защиты, в изолированную программную среду.
Итак, показано, что основными элементами поддержания изолированности программной среды являются контроль целостности и контроль порождения процессов.
Выше мы уже сформулировали понятия МБС и порождения субъектов с контролем их неизменности. Необходимо заметить, что для достоверного контроля неизменности объекта (т.е. с вероятностью ошибки, равной 0) необходимо убедиться в полном тождестве проверяемого объекта и образца. Из этого следует, что эталон должен содержать не меньше информации, чем проверяемый объект. Из этого в свою очередь следует, что эталонный объект должен быть как минимум одинаковой длины с Проверяемым. На практике такой подход может быть применен е серьезными ограничениями (например, для объектов небольшого объема типа программ ПЗУ или загрузчиков ОС).
В связи с этим для контроля целостности применяют объекты, содержащие информацию, зависящую от всего содержания объекта, но тем не менее значительно меньшего объема, вычисленную при помощи класса функций типа «хэш». Очевидно, Что в этом случае процесс установления неизменности объекта становится вероятностным.
Исходя из данного факта невозможно говорить о гарантированных (детерминированно) свойствах системы, поскольку Неизменность объекта гарантируется лишь с некоторой вероятностью, не равной 1. Следовательно, все условия утверждений выполняются с некоторой вероятностью, зависящей от свойств применяемых для контроля целостности хэш-функций. Для подчеркивания изменившихся условий будем говорить далее не о контроле неизменности объекта, а о контроле целостности (КЦ) объекта.
Необходимо отметить также, что в процедуре контроля неизменности (которая теперь принимает вероятностный характер) участвуют как минимум два объекта: объект контроля и эталонный объект (хэш-значение), а также субъект, реализующий хэш-функцию и производящий сравнение.
Поэтому для субъекта контроля целостности важным является выполнение следующих условий:
— качественный алгоритм контроля целостности (термин «качественный» будет пояснен ниже);
— контроль реальных данных (т.е. отображение состояния контролируемого и эталонного объектов в ассоциированные объекты-данные субъекта контроля целостности, совпадающие с тождественным).
Поясним подробнее второй пункт. Контроль целостности всегда сопряжен с чтением данных (т.е. с инициированием потоков от объектов к ассоциированным объектам-данным субъекта контроля целостности, причем потоки могут соответствовать различному уровню представления информации — чтение по секторам, по файлам и т.д.). Например, встроенный в BIOS ПЭВМ субъект (практически это программная закладка — см. ниже) может навязывать при чтении вместо одного сектора другой или редактировать непосредственно буфер, в котором были прочитаны данные. Аналогичный эффект может быть вызван субъектами операционной среды, например, субъектами, локализованными в первичных загрузчиках ОС. С другой стороны, даже контроль самого ВIОS может происходить «под наблюдением» какой-либо дополнительной аппаратуры и не показать его изменения. Аналогичные эффекты могут возникать и при обработке файла. Цель организации режима чтения реальных данных состоит в тождественном отображении параметров чтения на АО субъекта чтения (поток от АО субъекта КЦ к АО субъекта чтения) и тождественном отображении считываемого объекта (в соответствии с параметрами, переданными субъекту чтения) на ассоциированные объекты-данные субъекта КЦ.
Поясним теперь понятие качественного КЦ с точки зрения математических свойств функции КЦ. Предположим, что имеется некоторый объект F и некоторый алгоритм Н, преобразующий объект F в некоторый объект М, который представляется словом того же языка, но меньшей длины. Этот алгоритм таков, что при случайном равновероятном выборе двух объектов F 1 и F 2 из множества возможных соответствующие им объекты М1 = Н(F 1) и М2 = Н(F 2) с высокой вероятностью различны. Тогда проверка целостности данных строится так: рассматриваем объект F, по известному алгоритму Н строим К = Н(F) и сравниваем М, заранее вычисленное как М = Н(F), с К. При совпадении считаем объект неизменным. Алгоритм Н называют, как правило, хэш-функцией или (реже) контрольной суммой, а число М— хэш-значением.
Качество КЦ определяется в данном случае выполнением следующих условий:
1. По известному объекту М = Н(F) нахождение другого объекта G, не тождественного F, такого, что М = Н(G), является задачей с трудоемкостью не менее заданной Th.
2. Объект М должен быть недоступен для изменения.
3. Длина объекта М должна обеспечивать условную вероятность Р(Н(F 1) = Н(F 2)/ F 1 не тождествен F 2) не более заданной Рh.
Поясним смысл этих условий. Пусть программа злоумышленника изменила объект F (статическое искажение). Тогда, вообще говоря, хэш-значение М для данного объекта изменится. Если субъекту злоумышленника доступен для изменения объект М (существует соответствующий поток), то он может по известному алгоритму Н вычислить новое хэш-значение для измененного объекта и заместить им исходное.
Пусть хэш-значение недоступно, тогда можно попытаться так построить измененный объект, чтобы хэш-значение его не изменилось; принципиальная возможность этого имеется, поскольку отображение, задаваемое алгоритмом хэширования Н, не биективно (неоднозначно).
Таким образом, при условии недоступности хэш-значения для изменения и доступности для изменения объекта-источника трудоемкость нарушения ИПС с КЦ объектов-источников (т.е. возможность породить субъект из объекта-источника, не тождественного исходному объекту) совпадает с Th. При однократной попытке инициировать субъект из случайно равновероятно выбранного объекта-источника вероятность нарушения ИПС (успешное порождение субъекта) не превосходит Рь. Итак, «качество» ИПС определяется свойствами хэш-функции Н, а именно: величинами Тh и Рh.
Обобщим приводимые выше рассуждения в методе «безопасной загрузки», или ступенчатого контроля. Он заключается в постепенном установлении неизменности компонент программно-аппаратной среды: сначала проверяется неизменность программ ПЗУ, при положительном исходе через проверенные на целостность программы ПЗУ считывается загрузочный сектор и драйверы операционной системы (по секторам) и их неизменность также проверяется, кроме того, проверяется целостность объекта, определяющего последовательность активизации компонент; через функции чтения проверенной ОС инициируется процесс контроля порождения процессов (реализация МБС); инициирование процесса контроля доступа к объектам завершает проектирование гарантировано защищенной КС.
Рассматривая вопросы программно-технической реализации ИПС, необходимо заметить, что мощность множества субъектов в некотором сегменте КС (выделенном по признаку принадлежности одной ЭВМ) с момента включения питания до момента запуска процессов пользователя увеличивается. Первоначально активизируются субъекты аппаратно-программного уровня (программы ПЗУ), затем указанные субъекты порождают из объектов-источников данного уровня (это, как правило, сектора внешних носителей информации) субъектов уровня операционной среды.
Субъекты уровня операционной среды, как уже отмечалось, также делятся на два подуровня: нижний уровень — субъекты — первичные загрузчики ОС (работающие с информацией уровня секторов) и верхний уровень — субъекты-драйверы (порождаемые субъектами — первичными загрузчиками из объектов-секторов), работающие с объектами уровня «файл» (последовательности секторов). На этапе перехода от субъектов загрузчиков к субъектам-драйверам происходит переход и к другой декомпозиции КС на объекты (от секторов к файлам). Указанная иерархия действует в любой известной на сегодняшний день КС и естественным образом предопределяет архитектуру, в рамках которой формируется и функционирует ИПС.
Например, аппаратная архитектура ПЭВМ типа IВМ РС задает следующие этапы активизации различных субъектов КС. При включении питания ПЭВМ происходит тестирование ОП, инициализация таблицы векторов прерываний и поиск расширений ВIОS. При их наличии управление передается на них. После отработки расширений ВIOS в память считывается первый сектор дискеты или винчестера и управление передается на него (образуется код загрузчика), затем код загрузчика считывает драйверы операционной системы, далее интерпретируются файлы конфигурации, подгружается командный интерпретатор и выполняется файл автозапуска.
При реализации ИПС на нее должна быть возложена функция контроля запусков программ и контроля целостности.
При описании методологии проектирования ИПС упоминалась проблема контроля реальных данных. Эта проблема состоит в том, что контролируемая на целостность информация может представляться по-разному на разных уровнях.
Внедренный в систему субъект может влиять на процесс чтения-записи данных на уровне файлов (или на уровне секторов) и предъявлять системе контроля некоторые другие вместо реально существующих данных. Этот механизм неоднократно реализовался в STELS-вирусах. Однако верно утверждение.
Если субъект, обслуживающий процесс чтения данных (т.е.указанный субъект инициируется запрашивающим данные субъектом и участвует в потоке), содержал только функции тождественного отображения данных на ассоциированные объекты данные любого субъекта, инициирующего поток чтения, и объекта-источника для этого субъекта зафиксирована, то при его последующей неизменности чтение с использованием порожденного субъекта будет чтением реальных данных.
- Министерство образования и науки российской федерации
- Лекция 1
- Предмет и задачи программно-аппаратной защиты информации.
- Лекция 2
- Информационная безопасность
- В компьютерных системах
- Компьютерная система как объект защиты информации
- Понятие угрозы информационной безопасности в кс
- Классификация и общий анализ угроз информационной безопасности в кс
- Лекция 3 Случайные угрозы информационной безопасности
- Лекция 4 понятие политики безопасности в компьютерных системах
- 1. Разработка политики информационной безопасности
- 2. Методология политики безопасности компьютерных систем
- 3. Основные положения политики информационной безопасности
- 4. Жизненный цикл политики безопасности
- 5. Принципы политики безопасности
- Лекция 5 Идентификации субъекта. Понятие протокола идентификации. Идентифицирующая информация. Пароли. Программно-аппаратные средства идентификации и аутентификации пользователей
- Идентификация и аутентификация. Основные понятия и классификация
- Лекция 6 Простая аутентификация
- 1. Аутентификация на основе многоразовых паролей
- 2. Аутентификация на основе одноразовых паролей
- 3. Аутентификация, на основе сертификатов
- Лекция 7
- 2. Строгая аутентификация
- 2.1. Протоколы аутентификации с симметричными алгоритмами шифрования
- 2.2. Протоколы, основанные на использовании однонаправленных ключевых хэш-функций
- Лекция 8 Аутентификация с использованием асимметричных алгоритмов шифрования
- Электронная цифровая подпись (эцп). Аутентификация, основанная на использовании цифровой подписи
- Протоколы аутентификации с нулевой передачей значений
- Упрощенная схема аутентификации с нулевой передачей знаний
- Лекция 9 системы идентификации и аутентификации
- Классификация систем идентификации и аутентификации
- Комбинированные системы
- Лекция 10 Бесконтактные смарт-карты и usb-ключи
- Гибридные смарт-карты
- Биоэлектронные системы
- 1. Ключи. Организация хранения ключей
- Утверждение о подмене эталона
- Защита баз данных аутентификации операционных систем класса Windows nt.
- Алгоритм вычисления хэша lanman
- Хэш ntlm
- 2. Распределение ключей
- Лекция 12 Использование комбинированной криптосистемы
- Метод распределения ключей Диффи-Хеллмана
- Протокол вычисления ключа парной связи ескер
- Лекция 13 Основные подходы к защите данных от нсд. Защита пэвм от несанкционированного доступа
- 1) Физическая защита пэвм и носителей информации;
- 1. Полностью контролируемые компьютерные системы.
- Программная реализация функций кс.
- Аппаратная реализация функций кс.
- 2. Частично контролируемые компьютерные системы.
- Основные элементы и средства защиты от несанкционированного доступа. "Снег-2.0"
- Лекция 15 Устройства криптографической защиты данных серии криптон.
- Устройства для работы со смарт-картами.
- Лекция 16 Программные эмуляторы функций шифрования устройств криптон
- Системы защиты информации от несанкционированного доступа Система криптографической защиты информации от нсд криптон –вето
- Лекция 17 Комплекс криптон -замок для ограничения доступа компьютеру.
- Система защиты конфиденциальной информации Secret Disk.
- Система защиты данных Crypton Sigma.
- Лекция 18 Модель компьютерной системы. Методы и средства ограничения доступа к компонентам эвм. Понятие изолированной программной среды.
- 1. Понятие доступа и монитора безопасности
- 2. Обеспечение гарантий выполнения политики безопасности
- 3. Методология проектирования гарантированно защищенных кс
- Лекция 19 Метод генерации изолированной программной среды
- Лекция 20
- Модели управления доступом
- Системы разграничения доступа
- Диспетчер доступа
- Списки управления доступом к объекту
- Списки полномочий субъектов
- Атрибутные схемы
- Лекция 21
- 1. Подходы к защите информационных систем Устойчивость к прямому копированию
- Устойчивость к взлому
- Аппаратные ключи
- 2. Структура системы защиты от несанкционированного копирования
- Блок установки характеристик среды
- 3. Защита дискет от копирования
- Лекция 22 Электронные ключи hasp
- Лекция 23
- 1. Разрешения для файлов и папок
- 2. Шифрующая файловая система (efs)
- 2.1. Технология шифрования
- 2.2. Восстановление данных
- Лекция 24
- 1. Драйвер еfs
- 2. Библиотека времени выполнения efs (fsrtl)
- 4. Win32 api
- 11.4. Взаимодействие файловой системы защиты ntfs и защиты ресурса общего доступа (Sharing)
- 11.5. Типовые задачи администрирования
- Оснастка Локальные пользователи и группы (Local Users and Groups)
- 11.6. Администрирование дисков в Windows 2000
- Лекция 25
- 2. Обзор современных средств защиты
- Лекция 26 Защита файлов от изменения. Защита программ от изучения. Защита от дизассемблирования. Защита от отладки. Защита от трассировки по прерываниям. Защита от исследований.
- Обычные проблемы хакера
- Защита от исследований на уровне текстов
- Защита от исследований в режиме отладки.
- Защита программ от трассировки
- Лекция 27
- 1. Базовые методы нейтрализации систем защиты от несанкционированного использования
- 2. Понятие и средства обратного проектирования
- Лекция 28 Локализация кода модуля защиты посредством отлова WinApi функций в режиме отладки
- Базовые методы противодействия отладчикам
- Лекция 29 Базовые методы противодействия дизассемблированию по
- Защита от отладки, основанная на особенностях конвейеризации процессора
- Лекция 30 Использование недокументированных инструкций и недокументированных возможностей процессора
- Шифрование кода программы как универсальный метод противодействия отладке и дизассемблированию
- Основные модели работы рпв
- Компьютерные вирусы.
- Классификация вирусов
- Лекция 32 Механизмы заражения компьютерными вирусами
- Признаки появления вирусов
- Методы и средства защиты от компьютерных вирусов
- Лекция 33
- Ibm antivirus/dos
- Viruscan/clean-up
- Panda Antivirus
- Профилактика заражения вирусами компьютерных систем
- Антивирус. Алгоритм работы
- Проверочные механизмы
- Постоянная проверка и проверка по требованию
- Лекция 34 Структура антивирусной защиты предприятия
- Функциональные требования
- Общие требования
- Пример вируса
- Список литературы Основная литература
- Дополнительная литература
- Периодические издания
- Методические указания к лабораторным занятиям
- Методические указания к практическим занятиям
- Методические указания к курсовому проектированию и другим видам самостоятельной работы