Конспект лекций по дисциплине

«Программно-аппаратная защита информации»

специальность 090104 «Комплексная защита объектов информатизации»

Лекция № 1

Программные и аппаратные механизмы защиты

Многие механизмы защиты могут быть реализованы как на программном, так и на аппаратном уровне, однако более стойкими считаются аппаратные реализации. Это связано со следующими причинами:

1. Целостность программной защиты легко нарушить, это дает возможность злоумышленнику изменить алгоритм функционирования защиты необходимым образом, например, заставить процедуру контроля электронно-цифровой подписи всегда выдавать верные результаты. Нарушить целостность аппаратных реализаций зачастую невозможно в принципе в силу технологии их производства.

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

Программно-аппаратные средства идентификации и аутентификации пользователей

Парольные подсистемы идентификации и аутентификации

Реализуются в открытых компьютерных системах. Являются наиболее распространенными. В качестве идентификации используется Login (имя пользователя), в качестве аутентификации – секретный пароль.

Преимущества: дешевизна, возможность использовать во всех компьютерных системах.

Недостаток: самые уязвимые ко взлому:

- перебор пароля в интерактивном режиме;

- подсмотр, кража из общедоступного места;

- возможность преднамеренной передачи пароля другому лицу;

- кража БД учетных записей из общедоступного места;

- перехват вводимого пароля путем внедрения в КС программных закладок;

- перехват паролей передаваемых по сети;

- возможность применения социального инжиниринга.

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

Для уменьшения влияния человеческого фактора требуется реализовать ряд требований к подсистеме парольной аутентификации.

Требования:

1. задавание минимальной длины пароля для затруднения перебора паролей в лоб;

2. использование для составления пароля различных групп символов для усложнения перебора;

3. проверка и отбраковка паролей по словарю;

4. установка максимальных и минимальных сроков действия паролей;

5. применения эвристических алгоритмов, бракующих нехорошие пароли;

6. определение попыток ввода паролей;

7. использование задержек при вводе неправильных паролей;

8. поддержка режима принудительной смены пароля;

9. запрет на выбор паролей самим пользователем и назначение паролей администратором, формирование паролей с помощью автоматических генераторов стойких паролей.

Количественная оценка стойкости парольной защиты

А – мощность алфавита символов, из которых состоит пароль;

L – длина пароля;

V – скорость перебора паролей злоумышленником;

T – срок действия паролей;

P – вероятность подбора паролей злоумышленником за время t, меньшее срока действия паролей

Лекция №2

Хранение аутентифицирующей информации в открытых компьютерных системах. Типовые схемы хранения ключевой информации. Защита БД аутентификации .

При работе с открытыми КС необходимо обеспечить защиту аутентифицирующей информации, хранимой в КС. В открытых КС часто отсутствуют внешние максимально защищенные от НСД устройства, хранящие аутентифицирующую информацию, и данную информацию, используемую для аутентификации, приходится хранить в реальном объекте файловой системы (БД аутентификации).

Эту информацию необходимо защищать от 2 основных видов угроз:

- угроза непосредственного доступа злоумышленника к БД аутентификации с целью ее копирования, модификации, удаления;

- угроза несанкционированного изучения БД аутентификации.

Защита от первого вида угрозы реализуется, как правило, на уровне ядра ОС путем ограничения доступа к той БД аутентификации всех субъектов, за исключением привилегированных. Либо защита от данного вида угроз реализуется путем определения дискреционной политики безопасности. Однако, как правило, способы защиты от угроз первого вида не работают корректно и их можно обойти, используя существующие уязвимости.

Поэтому при защите БДА большее внимание уделяется защите от несанкционированного исследования их содержимого.

Методы:

1). Шифрование

Такой подход к закрытию содержимого БД аутентификации не является стойким, так как:

1. Шифрование должно быть на ключах, которые необходимо хранить. Хранение в операционной системе недопустимо.

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

2). Хэширование

Для защиты от исследования БДА используется две типовых схемы хранения ключевой информации:

Схема 1

Пусть пользователь с Ni имеет идентификатор и ключ идентификации , тогда первая типовая схема предполагает наличие в БД аутентификации двух основных полей:

– функция хэширования. Функция должна удовлетворять следующим свойствам:

1). Необратимостью: восстановить возможно было бы только полным перебором

2). Вероятность совпадения хэшей 2 произвольно взятых сообщений должна быть чрезмерно мала, если длина сообщения меньше длины хэша, то вероятность должна быть равна нулю.

3) Рассеивание – при малейшем изменении сообщения его хэш должен существенным образом изменяться.

При использовании такой схемы хранения ключевой информации, ОС в явном виде не знает те ключи, пароли, которые используются пользователем для входа в систему.

Алгоритм аутентификации пользователя будет выглядеть следующем образом:

Пользователь вводит идентификатор при входе в систему. Подсистема аутентификации ищет наличие данного идентификатора в БД аутентификации. Если данный идентификатор не найден, то идентификация отклоняется. Если же введенный идентификатор равен некому _, то подсистема аутентификации извлекает , соответствующий ему. Далее пользователь вводит пароль k. Подсистема аутентификации вычисляет . Если , то аутентификация принимается.

Недостатком данной схемы является то, что достаточно часто закрытые образы паролей формируются как . Тогда пользователи, имеющие одинаковые пароли, будут иметь одни и те же хэши. Злоумышленник, обнаружив подобную ситуацию, может сделать вывод, что пользователи используют одинаковые пароли.

Для устранения этого вводится вторая схема аутентификации.

Схема 2

Вторая типовая схема предполагает хранение вместе с идентификатором случайной информации , формирующейся при создании учетной записи. называется символом привязки.

В этом случае хэши будут различны. Данная схема используется в системах класса Unix.

Утверждение о подмене эталона

Если злоумышленник имеет доступ на запись в БД аутентификации, то он может пройти аутентификацию как любой пользователь КС, отраженный в ней, в том числе и как администратор. Следовательно, доступ на запись в БД аутентификации должны иметь только привилегированные субъекты.

Защита баз данных аутентификации операционных систем класса Windows NT .

В данных ОС БД аутентификации хранится в каталоге: winnt\system32\config

БДА носит название SAM, а файл System, в котором хранится ключ шифрования БД аутентификации.

В данной БД аутентификации хранится 2 вида хэшей:

- LANMAN, используемый для удаленной сетевой аутентификации с ранних версий Windows;

- NTLM, используется для локальной аутентификации.

Алгоритм вычисления хэша LANMAN

Например, если пароль будет состоять из заглавных букв английского алфавита (26), прописных букв английского алфавита (26), цифр (10), специальных символов (13), то

Тогда время подбора сек

Используя хэш LANMAN, получим, что

Время подбора пароля

Минусы:

- все символы пароля преобразуются в заглавные, что уменьшает энтропию паролей, сокращает пространство их перебора;

- пароль разбивается на две части, которые образуются независимо друг от друга;

При выборе паролей больше 14 символов хэши LANMANиз БД исчезают, следовательно, необходимо выбирать пароли из 15-16 символов.

Хэш NTLM

Хэш NTLM имеет длину 16 байт. Каждому из паролей длины меньшей или равной 16 символов соответствует единственный хэш NTLM, по которому ОС будет определять корректность его ввода пользователем. Однако если выбрать пароли больше 17 символов, то для них найдутся другие с длинной меньше или равной 16 символам, которые будут иметь тот же самый хэш. В этом случае ОС будет пускать пользователя на пароле меньшей длины. Есть вероятность, что длина таких паролей будет очень мала. Поэтому в целях безопасности использование паролей длиной больше или равной 17 символов необходимо запретить. Для ОС, построенных на технологии NT, следует выбирать пароли 15-16 символов.

Лекция № 3

Протоколы стойкой удаленной аутентификации пользователей. Протокол CHAP, S/KEY. Удаленная аутентификация в Windows с использованием хэша LANMAN

При удаленной аутентификации требуется обеспечить защиту от двух основных видов угроз: 1) от угрозы прослушивания канала связи злоумышленником; 2) от атак методом повторов (злоумышленник, видя информацию, передаваемую при аутентификации, может использовать её при прохождении последующих аутентификаций, даже не зная пароля).

Для разрешения этих проблем требуется:

1) Передавать ключ аутентификации в закрытом виде

2) От клиента серверу должны передаваться при каждой аутентификации различные последовательности. Причем злоумышленник не должен быть способен восстановить последовательность, требуемую для аутентификации, зная всю предысторию передачи сообщений.

При построении протокола удаленной безопасной передачи для разрешения вышеперчисленных проблем используется 2 подхода:

1). Передача от сервера клиенту при запросе на аутентификацию случайного числа, которое будет использовано при закрытии пароля.

2). Независимое формирование клиентом и сервером последовательности одноразовых паролей, которые не могут быть построены злоумышленником. Каждый из таких паролей действует на протяжении одной аутентификации.

Протокол CHAP

При необходимости аутентификации клиента на сервере, сервер посылает клиенту запрос на аутентификацию, предварительно сформировав на своей стороне случайное число n, которое он включает в запрос. Клиент, зная пароль k, с помощью которого он будет проходить аутентификацию, формирует следующую последовательность и отсылает ее серверу. Сервер, зная ключ аутентификации клиента и сформированное им число , также вычисляет . После чего сравнивает с . При аутентификация принимается.

Протокол использования одноразовых ключей S / KEY

В данном случае для безопасной аутентификации клиентом и сервером независимо друг от друга формируются последовательности одноразовых ключей, которые не может сформировать злоумышленник. Эти пароли последовательно передаются от клиента к серверу при каждой следующей аутентификации. Если клиент и сервер используют ключ аутентификации k. Тогда последовательность одноразовых ключей формируется следующим образом:

Ключи передаются в обратной последовательности от клиента серверу. В этом случае злоумышленник, слушающий канал связи, зная одноразовый ключ S_i , узнать следующий одноразовый ключ S_{i -1} , не может в силу необратимости функции хэширования. Он может найти этот ключ только с помощью перебора. Сервер независимо от клиента может формировать ту же последовательность и выполнить проверку одноразовых паролей, переданных клиентом.

Недостатки:

- после исчерпания списка одноразовых ключей возникает вопрос, какой ключ передавать следующим. Зацикливать эту последовательность нельзя, так как злоумышленник, слушающий канал связи, мог видеть всю предысторию передаваемых паролей, а значит, сможет корректно формировать пароли.

Для устранения этого недостатка, используют подход, основанный на передаче перед формированием последовательности одноразовых ключей случайного числа R от сервера клиенту. Это случайное число будет участвовать в формировании последовательности одноразовых ключей. Когда клиент исчерпает весь список паролей сервер передает клиент другое случайное число, и сформированная последовательность ключей будет другой:

Лекция № 4

Технические устройства идентификации и аутентификации

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

1. iButton (Touch Memory)

2. бесконтактные радиочастотные карты Proximity

3. пластиковые карты (со штрих-кодом и магнитной полосой)

4. карты с памятью

5. смарт-карты

6. электронные ключи e-Token

Устройства iButton (Touch Memory)

Разработано DallasSemiconductor.Представляет собой устройство идентификации пользователя, включает в себя уникальные идентификаторы, присваиваемые пользователю. Данное устройство включает в себя 3 компонента:

1. ПЗУ, которое хранит 64-разрядный код, состоит из 8-битового кода устройства, 48 бит – код идентификатора, 8 бит – контрольная сумма. Содержание ПЗУ уникально и не может быть перепрошито в дальнейшем.

2. ОЗУ (энергонезависимая статическая память) предназначена для хранения некой информации. В одном из типов эта энергонезависимая память защищена от НСД. В остальных типах – не защищена.

3. Элемент питания – встроенная литиевая батарейка 3В, питающая энергонезависимую память

После истечения 10 лет, память становится не доступна. Данное устройство может быть использовано для решения задачи идентификации (доступно только ПЗУ).

Виды устройств:

iButton с идентификатиром

i Button с энергонезависимой памятью

Статическая память не защищена от несанкционированного доступа операции чтения и записи возможны без ограничений. Элемент питания подпитывает статическую память и буфер обмена для хранения в них информации. В случае разряда литиевой батарейки доступ возможен только к ПЗУ. Буфер используется для обеспечения корректной записи данных в статическую память для защиты от сбоев. При записи данных происходит следующий процесс: диспетчер памяти вначале записывает данные в буфер, далее читает эти данные из буфера и сравнивает их с эталонными, в случае совпадения диспетчер памяти дает команду на перенос информации из блокнотной памяти в статическую

.

i Button с энергонезависимой памятью и таймером

Данный тип содержит внутри себя энергонезависимый таймер, который может использоваться для защиты устройств по сроку использования.

DS 1994 L

В регистр статуса помещают свои флаги по наступлению событий таймер-календарь, интервальный таймер и счетчик цикла.

В регистр управления могут закладываться ограничения на доступ к таймеру-календарю, интервальному таймеру, регистру статуса, условия для таймера-календаря, интервального таймера, счетчика цикла, для которого будут устанавливаться флаги в регистре статуса. Например, идентификатор может быть выдан пользователю на 3 месяца. В этом случае можно заложить условие установки в регистр статуса флага, говорящего об истечении срока действия идентификатора.

Преимущества: небольшая стоимость, может использоваться в промышленных приложениях «с жесткими условиями внешней среды»

Недостатки: сравнительно низкая скорость передачи информации от iButtonа к устройству чтения, большая вероятность сбоя в процессе чтения\записи.

Вообще iButton не предназначена для хранения аутентифицирующей информации в силу того, что энергонезависимая память не защищена от НСД. Однако, при использовании различных приемов на внешних устройствах его можно приспособить для хранения конфиденциальной информации. Например в устройствах «Соболь» (плата) в iButton хранятся закрытые пароли пользователей. Замок Соболь хранит некий ключ внутри себя, который используется при шифровании пароля. В iButton же в энергонезависимой памяти хранятся зашифрованные на этом ключе пароль пользователя.

Бесконтактные радиочастотные карты Proximity

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

Proximity-карта содержит внутри себя ПЗУ с идентификационным кодом, питающиеся через антенну при попадании в электромагнитное поле считывателя. Считыватель Proximity-карт постоянно генерирует электромагнитное излучение определенной частоты, карта, попадая в электромагнитное поле запитывается через антенну, заряжается конденсатор, который «выстреливает» идентификационным кодом на определенной частоте. Идентификационный код принимается считывателем. Сама карта элемента питания не имеет.

Пластиковые карты

Пластиковая карта – пластина 85,6*53,9*0,76 мм, изготовлена из специальной устойчивой к термическим и механическим воздействиям пластмассы.

Все требования к пластиковым картам изложены в стандарте ISO7816.

Данные карты выполняют функцию идентификации владельца, а отдельные типы карт еще и функцию аутентификации.

Выделяют 2 типа пластиковых карт: пассивные и активные.

Пассивные карты выполняют только функцию хранения информации без её обработки в активном режиме работы.

Активные карты могут кроме хранения информации выполнять её обработку.

К пассивным картам относятся карты со штрих-кодом и карты с магнитной полосой.

Карты со штрих-кодом нашли наибольшее применение при идентификации товаров в магазинах и на складах. В настоящее время часто для решения этой задачи также используют бесконтактные радиочастотные карты.

Карты с магнитной полосой используют магнитную полосу для хранения информации. Магнитная полоса состоит из трех дорожек, расположенных с обратной стороны карты имеют ширину 0,5 дюйма.

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

Для изготовления этих карт используют устройства типа Plextor, Cardpress.

Активные карты: относят карты-счетчики, карты с памятью и карты с микропроцессором. Данные карты позволяют выполнять обработку информации.

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

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

Карты с микропроцессором используются для защиты, хранения и обработки информации, хранимой на них.

Архитектура SMART- карт

Данные карты содержат следующие основные компоненты:

1. CPU - микропроцессор, используемый для обработки и защиты информации, хранимой и обрабатываемой на смарт-карте

2. ROM - ПЗУ, хранение ОС смарт-карты (8 Кб)

3. RAM - оперативная память (256 б), используется для временного хранения информации при выполнение криптографических операций

4. EEPROM - энергонезависимая память, используется для хранения файловой системы.

5. система ввода/вывода

Файловая система – система каталогов, каждый из которых отвечает за поддержку какого – либо приложения. В этих каталогах хранятся различные типы файлов. Каждый из каталогов ответственен за определенное приложение, например, электронный кошелек, ключи VPN для создания криптозащищенных тоннелей, защищенной электронной почты, ЭЦП. Для доступа к конкретному приложению и связи с ним файла требуется применение ключа, для каждого приложения такой ключ уникален. Для каждого типа объектов файловой системы определены свои операции, которые могут быть выполнены над одним типом объектов, но не могут быть применены к объектам других типов. Например, для файла ключей не определено операций чтения, зато определена операция «использовать».

Лекция № 5

Идентификация и аутентификация пользователей с помощью биометрических устройств

Архитектура

Например, (390, 418, 502,471,355)

(389, 416, 501, 468, 353)

. Устанавливается пороговое значение.

N – количество попыток аутентификации легальных пользователей

M – количество отказов легальным пользователям

- коэффициент ошибочных отказов

K – общее количество попыток аутентификации нелегальных пользователей

L – количество процедур аутентификации

- коэффициент ошибочных подтверждений

Системы контроля доступа (СКД)

Системы контроля доступа используется для реализации заданного режима доступа на охраняемый объект и реализуют следующие основные функции:

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

- сигнализация при попытках НСД;

- ведение списка пользователей;

- учет рабочего времени сотрудников;

- учет движения сотрудников по организации;

- определение текущего местоположения;

- ведение архивов событий.

Основными составными элементами СКД являются:

- устройство чтения идентификаторов;

- исполнительные устройства (электронные замки, турникеты, шлюзы, шлагбаумы);

- ПО, которое управляет СКД, содержит политику разграничения доступа и осуществляет комплексный сбор и мониторинг информации;

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

По способу управления преграждающими устройствами СКД можно поделить на следующие типы:

- автономные (локальные) используется для управления одним или несколькими преграждающими устройствами без передачи информации на центральный пульт и без контроля со стороны оператора;

- централизованные (сетевые) используется для управления преграждающими устройствами с обменом информацией с центральным пультом, контролем и управлением системой со стороны оператора;

- универсальные – включает в себя функции как автономных, так и централизованных СКД. Работают в сетевом режиме под руководством центрального пульта, но способны перейти в автономный режим при отказе сети.

По количеству точек доступа СКД делится на 3 класса:

- малые, для которых единица точек доступа - это офис;

- средние – десятки точек доступа, тысячи пользователей;

- большие – сотни точек доступа, десятки тысяч пользователей.

Схемы СКД

Автономные

Такая система состоит из автономного контроллера, который хранит в себе БД идентификаторов. Он управляет работой всех остальных элементов системы. В качестве исполняющего устройства выступает электронный замок, либо защелка, которой контроллер дает команды на открывание. Для идентификации пользователя используются Proximity или iButton, подсоединенный к считывателю. Этот считыватель работает только на вход, как правило. Для выхода пользователя из помещения предусмотрена кнопка открывания двери. Дверной контакт фиксирует открывание двери и используется для обеспечения корректной работы системы. В подобных системах может использоваться компьютерная техника для управления автономным контроллером, загрузки и считыванию из него информации. Через специальную плату данный контроллер подключается к ЭВМ, стоящей в помещении, на которую загружается специальное ПО, позволяющее обновлять перечень зарегистрированных идентификаторов в автономном контроллере, изменять политику разграничения доступа. Это ПО позволяет в удобном для пользователя виде предоставлять информацию о проходах пользователей через эту дверь, вести учет рабочего времени, визуально контролировать личность сотрудника.

Сетевые СКД

Контроллеры УД выполняют принятие решения о допуске\недопуске пользователя с конкретным идентификатором. В зависимости от типа СКД контроллер может использовать для хранения от 2000 до 32000 идентификаторов, обладает внутренней памятью определенного объема, в которой накапливается информация о проходах.

Диспетчерский пункт, общаясь с контроллером, загружает в него списки идентификаторов и политику разграничения доступа. С контроллера на диспетчерский пункт загружается статистика проходов. В случае потери связи с диспетчерским пунктом КУД переходит в автономный режим работы. Адаптеры используются для непосредственного подключения исполняющих устройств и передачи от них информации КУД.

Лекция № 6

Защита программного обеспечения от несанкционированного использования

Включает в себя:

1. Организационно-правовые меры

2. Правовые меры (распространение на программное обеспечение авторского права)

3. Технические меры

Модульная архитектура технических средств защиты ПО от несанкционированного копирования

Особенностью всех технических мер защиты является то, xто их реализация построена на выделении, либо принудительном введении каких – либо идентифицирующих элементов в среде функционирования программы, на которые настраивается система защиты. В качестве таких характеристик среды может быть использованы серийный номер, ключевой файл, информация в реестре, в конфигурации файлов, конфигурация аппаратуры, физический дефект носителей информации.

Основные требования к системе защиты ПО от несанкционированного копирования:

1. такая система должна достоверно выявлять факт несанкционированного использования программы

2. реагировать на факт несанкционированного использования

3. противодействовать возможным атакам, направленным на нейтрализацию защитных механизмов

Система защиты ПО от несанкционированного копирования работает по следующему алгоритму:

1. разработчик ПО разрабатывает и внедряет защитные механизмы в исполнительную программу

2. в эти защитные механизмы закладываются эталонные характеристики среды, которые идентифицируют конкретную копию программы и относительно которой будет проверяться легальность запуска

3. при каждом запуске программы выполняются следующие действия:

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

За установку текущих характеристик среды отвечает блок ответной реакции. Выход этого блока поступает на блок сравнения характеристик среды, который сравнивает текущие характеристики среды с эталонными.

По способу внедрения защитного кода в защищаемую программу различают встроенную и пристыковочную защиты.

Встроенные механизмы защиты основываются на том, что система как самостоятельный программный модуль отсутствует. Эти механизмы защиты внедряет сам разработчик в исходный текст программы, используя, например набор готовых API-функций защиты.

Преимущества:

1. Простота. С помощью библиотек и функций, поставляется совместно с ПА средствами защиты, от ПА средства можно добиться максимальной эффективности

2. при реализации встроенной защиты, разработчик может запрограммировать любую ответную реакцию программы на несовпадение характеристик с эталонными, что в свою очередь позволяет более хорошо реализовать маркетинговые функции. Например, при отсутствии электронного ключа, может запускать программу в демонстрационном режиме.

3. защита производится не по детерминированному алгоритму. Разработчик сам определяет, когда и каким образом будут вызываться API-функции с ПА устройствами защиты, как будут обрабатываться возвращаемые ими результаты.

Недостаток: сложная реализация.

Модуль противодействия нейтрализации защитных механизмов затрудняет анализ злоумышленником защитного кода, противодействует вмешательству в его работу и выполняется по 2 направлениям:

1) статическое

2) динамическое

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

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

Пристыковочные механизмы защиты внедряются непосредственно в исполнительный код, реализуется непосредственно некого автоматического обработчика исполнительных файлов. Эти обработчики заключают исполнительный код программы в некую защитную оболочку, которой при старте программы передается управление. При старте программы запускается защитная оболочка, реализующая все защитные функции, проверки, по результатам которых принимается решение о запуске/незапуске программы. Они поставляются в виде неких wizad-ов. При использовании подобных wizard-ов от пользователя требуется минимум действий, например, указать программу, требующую защиту и способ защиты.

HASPEnvelopment

«+» 1. простота использования и простота внедрения

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

«-» 1. используется детерминированный алгоритм, который могут попытаться вскрыть

2. жесткая реакция защиты программы на несовпадение характеристик среды (отказ в запуске)

Блок сравнения характеристик среды

Злоумышленник, атакуя этот блок, либо пытается найти эталонные характеристики среды, которые ожидает увидеть блок защиты, либо пытается модифицировать алгоритм сравнения характеристик среды таким образом, чтобы он всегда запускался по одной из ветвей – ветви верной регистрации (лицензионного запуска). В отдельных ситуациях такая модификация сводится к изменению всего 1 байта программы.

Для того, чтобы затруднить злоумышленнику атаку на этот блок, данный блок должен отвечать ряду требований:

1. установка значений характеристик среды и их сравнение с эталонными должно производиться многократно и на протяжении всей работы программы

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

3. значения, получаемые от блока установки характеристик среды, желательно использовать в качестве ключа для дешифровки кода программы.

Блок установки характеристик среды.

Наиболее уязвимым местом данного блока является способ сбора характеристик среды и способ передачи их от ПА среды блока установки и от блока установки к блоку сравнения. Если характеристики среды по открытому каналу, хранятся в открытых объектах, то такой способ защиты не является стабильным.

Лекция № 7

Электронные ключи. Защита программ с помощью электронных ключей HASP

Минусом таких характеристик среды как серийный номер, конфигурация аппаратуры, ключевой файл, информация в секретном секторе диска, является то, что злоумышленник достаточно легко может их раскрыть и осуществить взлом посредством их имитации.

Для устранения подобных недостатков характеристики среды необходимо выносить во внешние максимально защищенные от НСД устройства, которые затрудняют свою эмуляцию и дублирование.

Данную возможность предоставляют электронные ключи. Они принудительно вводят ПА среду, характеристики среды, стойкие к эмуляции и дублированию.

Ключи являются разработкой израильской фирмы Aladdin и используются для ЗПО от НС использования: предотвращают запуск программ при отсутствии электронных ключей, ограничивают максимальное количество копии, одновременный запуск программ в сети, ограничивают время работы программы и ограничивают максимальное количество её запусков.

Типы электронных ключей HASP.

1. HASP4 Standart

2. HASP4 Memo

3. HASP4 Time

4. HASP4 Net

HASP Standard

Самая простая модификация электронных ключей HASP. Включает в себя только функцию шифрования и связанную с ней функцию отклика. Стоимость – 13$. Может реализовывать следующие функции по защите:

1. проверять наличие электронного ключа

2. подавать на вход функцию отклика различные значения и сравнивать ответ с эталонными значениями

3. использовать функцию шифрования для шифрования/дешифрования исполнительного кода программы или используемых данных.

Основные элементы защиты:

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

HASP Memo

Данные ключи включают в себя все функции HASPStandart. Кроме того, имеют уникальный идентификационный номер и энергонезависимую память определенного объёма.

2 типа по объёму энергонезависимой памяти:

· HASP4 М1 – 112 байт

· HASP4 М4 – 496 байт

Кроме тех функций, которые можно реализовать с помощью HASP4 Standart, эти ключи могут:

4. хранить в энергонезависимой памяти различную конфиденциальную информацию, используемую для защиты ПО (ключи, адреса переходов и т.д.)

5. возможно хранить в энергонезависимой памяти информацию об отключенных и подключенных модулях программы, доступных пользователю

6. возможно защищать программы по количеству запусков.

HASP Time

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

Включает в себя встроенный календарь с датой и временем. Используется для защиты ПО по срокам использования.

HASP Net

Используется для ограничения максимального количества одновременно запущенных копий программ в сети.

Способы защиты программного обеспечения с помощью электронных ключей HASP

Можно реализовывать с помощью встроенных и пристыковочных механизмов.

Встроенные – HASPAPI.

Пристыковочные HASPEnvelopment.

Электронные ключи HASPMemo, Time и Net включают в себя подсистему полного управления доступом (FAS), позволяющую защитить одновременно несколько программ одного производителя, и ограничить их в зависимости от типа ключей по количеству запусков, по сроку действия, по количеству одновременно запущенных копий.

Электронные ключи HASPMemo, Time и Net обладают возможностью их удаленного перепрограммирования с помощью подсистемы RUS.

Для реализации удаленного управления формируется 2 утилиты: продавца и покупателя. Они формируются под конкретный электронный ключ, привязывающийся к его идентификационному номеру.

Pattern Code Security (Механизм защиты структурного кода)

Механизм PCSоснован на внедрении в исходные тексты программ шаблонов, в которых определены некие функции доступа к электронному ключу. Данные функции, определенные в шаблонах, будут вызываться скрытым образом из исполняемого кода программы. Для них не будет явным образом вызываться процедура HASP. Когда разработчиком защиты для решения своих задач делается явный вызов HASP, программа автоматически выполняет последовательность скрытых вызовов функций, определенных в шаблонах PCS. Всего таких шаблонов можно определить до 25 штук. Внедрив через данные шаблоны вызовы скрытых процедур, разработчик защиты может значительно усложнить трассировку защитных механизмов, затруднить вмешательство извне в их работу.

Злоумышленник, отключая явный вызов HASP, в действительности отключает множество скрытых вызовов, результат исполнения которых отражается на функционировании программы, например, вызовы могли выполнять дешифровку кода, получать отклики от электронного ключа, которые будут проводится в ходе дальнейшей работы программы.

Лекция № 8

Защита программного обеспечения от исследования

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

В первом случае злоумышленник пытается получить листинг программы на каком-либо языке для возможности дальнейшего изучения и исследования логики защитных механизмов с использованием таких средств как IdaPro, Soucer.

Большая часть средств защиты от отладки основывается на обнаружении отладчиков в оперативной памяти с целью дальнейшего противодействия отладке, либо на включенных в исполняемый код механизмов, которые не могут быть корректно выполнены под отладкой в режиме трассировки. Работа отладчиков в реальном режиме процессора основана на прерываниях int1, int3, которые устанавливают точки прерывания, в защищенном режиме работа отладчиков основана на использовании регистра отладки dr0 – dr7.

Приемы защиты:

1) использование ловушек для отладчиков – трикинг, с помощью которого отладчик можно выявить в оперативной памяти и принудительно завершить работу программы.

Один из приемов основан на том, что по команде popss следующая команда не может быть выполнена в режиме трассировки и она выполняется на реальном процессоре. В эту команду можно заложить защитный механизм.

pushss

popss

push f

pop ax

test ax, 100h

je debugger detected

2) переопределение стека в 0. Вершина стека «растет» сверху вниз, поэтому после определения ее в ноль, любая попытка положить что-то в стек приведет к его переполению и аварийному завершению работы программы. В том числе не может быть вызвано ни одно прерывание.

3) Контроль исполняемого кода. Установка точки прерывания в реальном режиме процессора требует модификации кода программы для защиты от установки точек прерывания можно периодически контролировать исполняемый код на целостность.

4) В защищенном режиме можно воздействовать на регистры отладки dr0-dr7, например, периодически обнулять или использовать для своих нужд.

5) Обнаружение наличия отладчиков в оперативной среде путем использования преднамеренно оставленных в них «дыр»

6) Использование недокументированных возможностей процессора:

1. mov ax, cs:[100]=ds:es:cs:mov ax, [100]

2. cs:nop

7) Использование особенностей конвейеризации – можно написать исполняемый код, в котором инструкция модифицирует сама себя, становясь на байт короче. Если подобная инструкция используется на реальном процессоре (не под отладкой), то и сама инструкция и следующие за ней уже находятся в конвейере процессора и эта модификация никак не затронет. В режиме отладки будет использоваться модифицированный код.

Противодействие средствам статического анализа:

1. Шифрование исполняемого кода программы на хороших ключах. Универсальное и наиболее стойкое средство защиты.

2. Самомодифицирование кода программы. Замена одних участков кода программы на другие.

3. Внедрение между инструкциями некой области данных

mov ax, 0CEBh

jmp label

db 1,2,3,4,5,6,7,8,9

label: mov ax, 1234h

4. Скрытие команд передачи управления

mov word ptr cs:label[1], 1234h

……

label jmp 0000h

5. Использование косвенной передачи управления

mov bx, 1234h

……….

Jmp cs:[bx]

6. Использование нестандартных способов передачи управления

Для затруднения анализа исполняемого кода могут быть использованы попытки нестандартных приемов передачи управления. Могут быть сделаны моделирования одних инструкций через другие. Например, jmp, call, int через подобные инструкции.

Например:

7. Перемешивание кода программы

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

push ss

pop ss

push f

pop ax

test ax,100h

je Debugger detected

8. Обфускация – запутывание путем включения в код никому не нужных процедур, условных операторов перехода и других запутывающих преобразований. Например, эмуляция машины Тьюринга и команды под нее. Иногда в рамках данного подхода критичные защитные механизмы пишутся в рамках команд виртуального процессора, придуманного разработчиком, а в код программы вносятся обработчики данных команд.

Лекция № 9

Классификация средств атаки на средства защиты программного обеспечения

Программы-каталогизаторы – оболочки файловых систем, например, Far, TotalCommander. С помощью данных средств возможно:

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

Программы поиска файлов и текстовых последовательностей : HIEW, позволяющие искать в прикладных программах и файлах данных требуемые последовательности. Злоумышленник, таким образом, может локализовать участки кода, ответственные за выполнение функций по безопасности.

Мониторы файловых операций (FileMon, RegMon, PortMon). Данные средства позволяют злоумышленнику проанализировать активность программы, «общение» программы с файлами, реестром, устройствами через порты ввода/вывода.

Мониторы вызова подпрограмм и системных функций (Spy++). С помощью данных средств можно определить, какие API-функции используются разработчиком для вызова решения определенных задач.

Программы копирования областей оперативной памяти на внешние устройства (AdvancedMemoryDumper).

Средства декомпиляции (Cordonswf) представляют собой средства статического анализа исполняемого кода для изучения исходных текстов программ. Хорошо работают для Basic, Flash.

Средства редактирования ресурсов (Passolo, ResourceHacker).

Средства программы эмуляции аппаратных средств (VirtualCD).

Средства эмуляции ЦП и ОС (VMWave)

Защита от разрушающих программных воздействий (РПВ)

Важным моментом при использовании системы ЗИ является обеспечение потенциального невмешательства иных присутствующих в системе программ в процесс обработки информации компьютерной системой, работу системы ЗИ.

С помощью посторонних программ, присутствующих в компьютерной системе, злоумышленник может реализовать опосредованный несанкционированны доступ, то есть НСД, реализуемый злоумышленником не напрямую, а путем запуска в систему постороннего ПО – программных закладок, либо внедрения его на этапе проектирования АС. Можно выделить 3 вида разрушающих программных воздействий (программных воздействий, которые способны нарушить штатное функционирование АС).

Эти программы могут реализовать следующие функции:

1. скрывать признаки своего присутствия в оперативной среде

2. реализуют самодублирование и ассоциирование себя с другими программами. Самодублирование – процесс воспроизведения программой своего кода, который не обязательно совпадает с эталоном, но реализует те же самые функции. Под ассоциированием понимают внедрение программой своего кода в исполнительный код другой программы так, чтобы при неопределенных условиях управление передавалось этому РПВ.

3. способны разрушать код иных программ в оперативной памяти КС

4. способны переносить фрагменты информации из оперативной памяти в некие области внешней памяти, доступной злоумышленнику

5. имеют потенциальную возможность исказить либо подменить выводящуюся во внешнюю память информацию.

РПВ делятся на следующие классы:

1. Вирусы. Особенностью является направленность на самодублирование и деструктивные функции. Задача скрытия своего присутствия в ПА среде часто не ставится

2. Программные «черви» - РПВ, основной функцией которых является самодублирование путем распространения в сетях, используя уязвимости прикладных систем и сетевых сервисов.

3. «Троянские кони». Для этих программ не свойственно деструктивное воздействие. Данный класс РПВ часто относят к вирусам, однако, основной функцией РПВ данного класса, как правило, заключается в краже информации, например, номеров кредитных карт, либо в имитации сбоя ЭВМ, чтобы под видом ремонта злоумышленник мог получить к ней доступ. Основная особенность – ассоциирование либо выдача себя за часто используемое ПО либо сервисы.

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

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

Для того, чтобы РПВ получило управление, оно должно находится в оперативной памяти и активизироваться по некому общему для этого РПВ и прикладной программы, являющейся целью её воздействия, событию. Подобное событие называется активизирующим.

Если РПВ присутствует в ПА среде и загружено в оперативную память, то при отсутствии для него активизирующего события деструктивные особенности этого РПВ невозможны.

В качестве событий могут выступать прерывания, связанные с выполнением определенных действий, а часто действие, связанное с работой системы защиты, ввод с клавиатуры, прерывания по таймеру, операция с файлами и т.д.

Основные модели работы РПВ

1) Перехват. РПВ внедряется в оперативную среду и осуществляет перехват и дальнейшее копирование требуемой информации в некие скрытые области оперативной памяти. Например, клавиатурные шпионы.

2) «Троянский конь» - РПВ встраивается в постоянно используемое ПО, либо сервис и выполняет кражу информации. Либо сервис при активном событии моделирует сбойную ситуацию.

3) «Наблюдатель» - РПВ встраивается в постоянно используемое ПО или сервис и осуществляет контроль обработки информации, реализует контроль других РПВ. (Trojan Downloader)

4) Искажение либо инициатор ошибок.

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

Выделяют 3 основные группы деструктивных функций РПВ:

1. Сохранение фрагментов информации во внешнюю память.

2. Изменение алгоритмов функционирования прикладных программ.

3. Блокировка определенных режимов работы прикладных программ.

Лекция № 10

Компьютерные вирусы как класс РПВ

Вирусы как класс РПВ обладают следующими функциями:

1. способность к самодублированию

2. способность к ассоциированию с другими программами

3. способность скрывать признаки своего присутствия до определенного момента

4. направлены на деструктивные функции

Компьютерные вирусы делятся на:

· файловые

· загрузочные

· макровирусы

Жизненный цикл вирусов включает 2 фазы: латентную, когда вирус не проявляет своего присутствия, и фазу непосредственного функционирования.

Переход от латентной фазы к фазе исполнения выполняется по методу активизирующего события. Загрузка вируса в оперативную память выполняется одновременно с загрузкой инфицированного объекта. Основные способы загрузки зараженных объектов:

1) автоматическая загрузка при запуске операционной системы

2) внедрение в меню автозагрузки

3) через носители типа flash

Фаза исполнения вируса включает следующие этапы:

1) загрузка вируса в память

2) поиск «жертвы»

3) инфицирование

4) выполнение деструктивных функций

5) передача управления объекту-носителю вируса.

По способу поиска «жертвы» вирусы делятся на:

1. те, которые выполняют активный поиск объектов

2. те, которые ведут пассивный поиск, то есть устанавливают ловушки на заражаемые объекты

Инфицирование объектов может выполняться либо путем простого самокопирования кода вируса в исполнительный код, либо может использовать более сложный алгоритм, осуществляя мутацию исполнительного кода вируса при его самодублировании. Суть мутации сводится к изменению кода таким образом, чтобы вирус нельзя было обнаружить по фиксированным сигнатурам. Может использоваться шифрование кода на различных ключах.

Суть мутации кода может заключается в изменении порядка независимых инструкций, в замене одних регистров на другие, внедрение в исполнительный код мусорных конструкций, в замене одних инструкций другими.

Вирусы, мутирующие в процессе самокопирования называются полиморфными. Если неполиморфные вирусы могут быть идентифицированы в ПА среде путем их поиска по сигнатурам, то полиморфные вирусы не имеют сигнатуру, по которой бы они однозначно идентифицировались.

Для защиты от вирусов наиболее часто применяют антивирусные мониторы, сканнеры, ПА средства, не допускающие заражение вирусами объектов операционной среды, не допускающие проникновение в КС.

Наиболее часто используемые пути проникновения вируса в КС:

1. носитель информации с зараженным объектом;

2. электронная почта;

3. компьютерная сеть.

Методы борьбы с РПВ

1. Контроль целостности, системных событий, прикладных программ, используемых данных

2. Контроль цепочек прерываний и фильтрация вызовов, критических для безопасности систем прерываний

3. Создание изолированной программной среды

4. Предотвращение результатов воздействия РПВ, например, аппаратная блокировка записи на диск

5. Поиск РПВ по свойственным им или характерным последовательностям – сигнатурам

Сигнатура – уникальная последовательность кода, свойственная вирусу, её присутствие в исполняемом коде говорит об однозначном присутствии РПВ. Можно поступить по-другому: разрешить запускать системе только те модули, которые имеют известную сигнатуру.

6. Поиск критических участков кода, путем его синтаксического анализа, выявление синтаксических характерных конструкций с точки зрения РПВ, например, вирусов.

7. Тестирование программ и компьютерной техники на испытательных стендах, в испытательных лабораториях, идентификация условий, возникающих в ПА среде, при которых она начинает вести себя некорректно.

8. Метод Мельсона – тестирование всех путей переходов программе.

Первый и второй метод действенны, когда сами контрольные элементы не подвержены воздействию закладок. Если этого не обеспечить, закладка может модифицировать алгоритм контроля целостности, подменить контрольную сумму.

Изолированная программная среда

При отсутствии активизирующих событий для программной закладки, её деструктивное воздействие невозможно, даже если она присутствует в ПА среде. Поэтому одним из способов защиты от РПВ можно нейтрализацию всех активных событий ПЗ.

ИПС характеризуется выполнением следующих условий:

1. на ЭВМ с проверенным BIOS-ом установлена проверенная ОС;

2. достоверно установлена неизменность ОС и BIOSа для текущего сеанса работы пользователя;

Эта достоверность должна достигаться только путем использования аппаратных средств, процедура контроля целостности которых прошитая в их ПЗУ, контроль целостности должен выполняться на протяжении всего сеанса работы пользователя, начиная с самых разных этапов загрузки ЭВМ.

3. кроме проверенных программ в ПА среде не запускалась и не запускается никаких иных программ. Проверенная программа перед запуском контролируется на целостность;

4. исключен запуск проверенных программ вне проверенной среды;

5. все вышесказанные требования должны выполняться для всех пользователей, аутентифицированных защищаемыми механизмами.

Идентификацию и аутентификацию пользователя желательно также выполнять на аппаратном блоке.

ИПС при запуске программы пользователя одновременно выполняет проверку условий:

· их принадлежность к списку разрешенных для записи

· их целостность

Лекция № 11

Сертификация программного обеспечения по уровню контроля отсутствия НДВ

Программное обеспечение, системы защиты, которые работают с конфиденциальной информацией, либо с информацией, составляющей государственную тайну, должно пройти проверки на наличие в них НДВ.

Под НДВ понимается функциональная возможность ПО, не описанная в документации, либо не соответствующая описанным в документации., которая может привести к нарушению конфиденциальности, целостности, доступности информации.

Проверка ПО на наличие НДВ осуществляется согласно РД ФСТЭК 1998 г. «Защита от НСД. Часть 1. ПО средств защиты. Классификация по уровню контроля отсутствия НДВ». Согласно этому РД выделяется 4 уровня контроля, 1-высокий, 4 – низкий.

1 – системы, обрабатывающее информацию «Особой Важности»

2 - системы, обрабатывающее информацию «Совершенно Секретно»

3- системы, обрабатывающее информацию «Секретно»

4 - системы, обрабатывающее конфиденциальную информацию

Для программного обеспечения импортного производства состав документации может отличаться от требуемого, однако содержание должно соответствовать требованиям, указанных в ГОСТ.

Контроль состава документации проводится группой экспертов путем сравнения перечня представленных документов с требованиями руководящего документа для заявленного уровня контроля. При этом проверяется наличие обязательных (в соответствии с ГОСТ) разделов в представленных документах (полное соответствие ГОСТам не обязательно, однако, содержание должно им соответствовать. В частности, это имеет смысл для ПО импортного производства, где понятие ГОСТов не так осмысленно. Эти проверки не автоматизируются).

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

На основании проведенного контроля делается вывод о соответствии документации требованиям руководящего документа и о возможности ее использования в процессе эксплуатации программного обеспечения.

Контроль исходного состояния программного обеспечения.

Контроль заключается в фиксации исходного состояния ПО и сравнении полученных результатов с приведёнными в документации.

Результатами контроля исходного состояния ПО должны быть рассчитанные уникальные значения контрольных сумм загрузочных модулей и исходных текстов программ, входящих в состав ПО.

Контрольные суммы должны рассчитываться для каждого файла, входящего в состав ПО.

Проверенное программное обеспечение фиксируется – т.е. со всех модулей снимаются контрольные суммы.

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

Лекция № 12

Статический анализ исходных текстов программ

Статический анализ исходных текстов программ должен включать следующие технологические операции:

· контроль полноты и отсутствия избыточности исходных текстов ПО на уровне файлов;

· контроль соответствия исходных текстов ПО его объектному (загрузочному) коду.

1. Контроль полноты и отсутствия избыточности

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

Для проверки полноты специальных средств автоматизации не требуется – достаточно факта успешной компиляции.

Для контроля избыточности исходных текстов на уровне файлов, с помощью анализатора исходных текстов определить список файлов, составляющих ПО и на основе анализа полученных исходных данных определить избыточные файлы, проанализировать их назначение и обоснованность включения в состав программного обеспечения.

2. Контроль соответствия исходных текстов программного обеспечения

Контроль соответствия исходных текстов ПО его объектному (загрузочному) коду осуществляется методом создания загрузочных модулей из представленных исходных текстов ПО, и их сравнением полученных модулей с модулями, входящими в состав дистрибутива.

Берутся предоставленные исходные тексты (*) и производится их контрольная сборка – т.е. они компилируется и полученные модули сравниваются по контрольным суммам с модулями зафиксированного ПО (см. пункт 2)

В случае отсутствия исходных текстов используются два подхода:

1. С восстановлением исходных текстов:

· дизассемблирование;

· статический анализ;

· динамический анализ;

· с использованием отладчиков;

· с использованием датчиков (датчики встраиваются в исходный текст, из которого потом заново собирается программный продукт, который подвергается тестированию).

При использовании данного подхода, возможно, потребуется итеративное дизассемблирование – с постепенными уточнениями.

2. Без восстановления исходных текстов – использование эмуляторов

Для контрольной сборки, помимо собственно исходных файлов, желательно иметь и среду сборки (т.е. все компиляторы и компоновщики, которые использовал разработчик – иначе, при полностью самостоятельной сборке в лаборатории, расхождения по контрольным суммам почти гарантированно (т.е. собранные модули будут отличаться от модулей зафиксированного ПО). Наилучший вариант – когда контрольная сборка производится либо на стенде разработчика (один или несколько компьютеров необходимых для cборки ПО, предоставляемые разработчиком и полностью готовые к сборке ПО), либо непосредственно у разработчика.

Последовательность действий при выполнении трансляции исходных текстов, версия транслятора, а также исходные данные (директивы) для транслятора должны соответствовать приведённым в сопроводительной документации.

Автоматизация здесь подразумевается на уровне командных
файлов для сборки или автоматизации, предусмотренной в самих средствах
сборки.

3.2.4. Отчётность

По окончании испытаний оформляется отчёт (протокол), содержащий результаты:

· контроля исходного состояния программного обеспечения;

· контроля полноты и отсутствия избыточности исходных текстов контролируемого программного обеспечения на уровне файлов;

· контроля соответствия исходных текстов программного обеспечения его объектному (загрузочному) коду.

3.3. Требования к третьему уровню контроля

3.3.1. Контроль состава и содержания документации

Требования полностью включают в себя аналогичные требования к четвертому уровню контроля.

Кроме того, должна быть представлена «Пояснительная записка» (ГОСТ 19.404-79), содержащая основные сведения о назначении компонентов, входящих в состав программного обеспечения, параметрах обрабатываемых наборов данных (подсхемах баз данных), формируемых кодах возврата, описание используемых переменных, алгоритмов функционирования и т.п.

3.3.2. Контроль исходного состояния программного обеспечения

Требования полностью включают в себя аналогичные требования к четвёртому уровню контроля.

3.3.3. Статический анализ исходных текстов программ

Кроме аналогичных требований, предъявляемых к четвёртому уровню контроля, дополнительно предъявляются следующие требования:

· контроль полноты и отсутствия избыточности исходных текстов ПО на уровне функциональных объектов (процедур);

· контроль связей функциональных объектов (модулей, процедур, функций) по управлению;

· контроль связей функциональных объектов (модулей, процедур, функций) по информации;

· контроль информационных объектов различных типов (например, локальных переменных, глобальных переменных, внешних переменных и т.п.);

· формирование перечня маршрутов выполнения функциональных объектов (процедур, функций).

Лекция № 13

Перечень типовых дефектов программного обеспечения

Рассмотрим перечень типовых дефектов программного обеспечения.

1. Неполная проверка параметров и разброса переменных; нестрогий контроль границ их изменений.

2. Скрытое использование приоритетных данных.

3. Асинхронное изменение интервала между временем проверки и временем использования.

4. Неправильное преобразование в последовательную форму.

5. Неправильные идентификация, верификация, аутентификация и санкционирование задач.

6. Отказ предотвращения перехода за установленные в программе пределы доступа и полномочий.

7. Логические ошибки (например, больше логических выражений или результатов, чем операций перехода).

8. Незавершённые разработка и описание.

9. Недокументированные передачи управления.

10. Обход контроля или неправильные точки контроля.

11. Неправильное присвоение имен, использование псевдонимов.

12. Неполная инкапсуляция или неполное скрытие описания реализации объекта.

13. Подменяемые контрольные журналы.

14. Передача управления в середине процесса.

15. Скрытые и недокументированные вызовы из прикладных программ, команд ОС и аппаратных команд.

16. Не устранение остаточных данных или отсутствие их адекватной защиты.

17. Неправильное освобождение ресурсов.

18. Игнорирование отключения внешних приборов.

19. Неполное прерывание выполнения программ.

20. Использование параметров ОС в прикладном пространстве памяти.

21. Не удаление средств отладки до начала эксплуатации.

Формы проявления программных дефектов

(Вариант 1)

1. Выполнение арифметических операций и стандартных функций:

· деление на 0;

· переполнение разрядной сетки;

· отличие результатов арифметических операций от ожидаемых;

· обращение к стандартным функциям с недопустимыми значениями параметров.

2. Ошибки, связанные с затиранием команд и переменных.

3. Ошибки управления:

· зацикливание – бесконечное повторение одной и той же части программы;

· последовательность прохождения участков программы не соответствует ожидаемому;

· потеря управления, приводящая к ошибкам разного рода (обращение к запрещенной области памяти, попытка выполнить запрещенную программу или «не команду».

· 4. Ошибки ввода-вывода:

· «странный» вывод (на печать, на монитор и т.д.);

· сообщения об ошибках от системных программ ввода-вывода.

(Вариант 2)

1. Ошибки, приводящие к прекращению выполнения основных или части функций управляющей системы на длительное и или неопределенное время:

· зацикливание, то есть последовательная повторяющаяся реализация определенной группы команд, не прекращающаяся без внешнего вмешательства;

· останов и прекращение решения функциональных задач;

· значительное искажение или потеря накопленной информации о текущем состоянии управляемого процесса;

· прекращение или значительное снижение темпа решения некоторых задач вследствие перегрузки ЭВМ по пропускной способности;

· искажение процессов взаимного прерывания подпрограмм, приводящее к блокировке возможности некоторых типов прерываний.

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

· пропуск подпрограмм или их существенных частей;

· выход на подпрограммы или их части, резко искажающиеся результаты;

· обработка ложных или сильно искаженных сообщений.

3. Ошибки, мало и кратковременно влияющие на результаты, выдаваемые управляющим алгоритмом.

Этот тип ошибок характерен, в основном, для квазинепрерывных величин, в которых возможны небольшие отклонения результатов за счёт ошибок. Эти ошибки в среднем мало искажают общие результаты, однако отдельные выбросы могут сильно влиять на процесс управления и требуется достаточно эффективная защита от таких редких значительных выбросов.

Лекция № 14

Следует отметить, что круг вопросов, связанных с защитой информацией в операционных системах, является более широким, чем вопросы защиты, рассматриваемые ранее. Здесь появляются дополнительные возможности атак, дополнительные уязвимости и т.д. Здесь, например, необходимо защищать приложение от воздействия от него другого приложения, что может привести к краху системы.

Защищенность операционной системы во многом характеризует защищенность всей компьютерной системы в целом. В связи с этим, защите ОС необходимо уделять много внимания на практике.

Классификация угроз безопасности ОС

Классификация угроз по цели:

· Несанкционированное чтение информации.

· Несанкционированное изменение информации.

· Несанкционированное уничтожение.

· Полное или частичное разрушение операционной системы, полное или частичное ее завешивание, завешивание программных модулей, физическое стирание с диска системных файлов (вирусы, DoS).

Классификация по принципу воздействия на ОС:

· Использование легальных каналов получения информации, например угроза несанкционированного чтения при некорректном определения профиля пользователя администратором.

· Использование скрытых каналов получения информации – использование недокументированных возможностей ОС (переполнение буфера – запуск некоторого программного кода).

· Создание новых каналов получения информации с помощью программных закладок.

По характеру воздействия на ОС:

· Активное воздействие – несанкционированное действия злоумышленника в системе (подбор пароля, украли базу паролей).

· Пассивное воздействие – несанкционированное наблюдение злоумышленника за процессами, происходящими в системе (сниффер).

По типу слабости защиты:

· Неадекватная политика безопасности, в том числе, ошибки администратора системы.

· Ошибки и недокументированные возможности программного обеспечения ОС: люки – случайные или преднамеренные служебные входы.

· Ранее внедренная программная закладка.

По способу воздействия на объект атаки:

· Непосредственное воздействие.

· Превышение пользователем своих полномочий.

· Работа от имени другого пользователя.

· Использование результатов работы другого пользователя (перехват информационных потоков).

По способу действий злоумышленника:

· В интерактивном режиме.

· В пакетном режиме (с помощью специально написанной программы, скрипта, которая действует самостоятельно, без участия злоумышленника).

По объекту атаки:

· ОС в целом.

· Объекты ОС (файлы, устройства, и т.д.).

· Субъекты ОС (пользователи, системные процессы, и т.д.).

· Каналы передачи данных.

По используемым средствам атаки:

· Штатные средства ОС, без использования дополнительного ПО.

· ПО третьих фирм (вирусы, вредоносные программы, отладчики, сетевые мониторы, сканеры).

· Специально разработанное ПО.

По состоянию атакуемого объекта на момент атаки: хранение, передача, обработка.

Типичные атаки на ОС

1. Сканирование файловой системы

2. Кража ключевой информации.

Простейший случай – подсматривание паролей, набираемых пользователем.

3. Подбор пароля.

4. Сборка мусора . В данном случае восстанавливается информация, которая помечена как удаленная, но реально не удаленная с диска или из памяти.

Например, если в памяти обрабатывался конфиденциальный документ, то после закрытия текстового редактора, можно просканировать память и выделить его.

5. Превышение полномочий. Злоумышленник использует дырки в ПО или ОС и получает полномочия, превышающие те, которые были ему выданы в соответствии с политикой безопасности. Обычно это достигается путем запуска программы от имени другого пользователя или подмены динамически подгружаемой библиотеки (скрипт МЭЛТ запускался от имени администратора и копировал содержимое файлов в HTML, выдавая их другому пользователю).

6. Программные закладки.

7. Жадные программы. Так называются программы, преднамеренно захватывающие значительную часть ресурсов компьютера, в результате чего другие программы не могут выполняться или выполняются крайне медленно и неэффективно. Часто запуск жадной программы приводит к краху ОС.

Лекция № 15

Понятие защищенной операционной системы

Операционная система называется защищенной , если она обеспечивает защиту от основных классов угроз, рассмотренных ранее.

Данная система должна обязательно содержать следующие компоненты:

1. Средства разграничения доступа пользователей к ресурсам.

2. Средства проверки подлинности пользователя.

3. Средства противодействия случайному или преднамеренному выводу операционной системы из строя.

Подходы к построению защищенных ОС.

2 подхода – фрагментарный и комплексный.

При фрагментарном подходе вначале организуется защита от одной угрозы, затем от другой и т.д. Пример фрагментарного подхода – когда берется незащищенная ОС, на нее устанавливается антивирусный пакет, система шифрования, регистрации действий пользователей и т.д.

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

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

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

Административные меры защиты

Защиту ОС невозможно обеспечить только аппаратно-программными средствами. Нужна постоянная квалифицированная поддержка со стороны администратора. Без постоянной квалифицированной поддержки со стороны администратора, даже самая надежная ПАЗИ оборачивается фикцией. Основными административными мерами защиты являются следующие:

1. Постоянный контроль корректности функционирования ОС, особенно подсистемы ее защиты. Регистрация событий, ведение логов и контроль логов.

2. Постоянное исследование и корректирование политики безопасности. После установки программных продуктов, атак и т.д.

3. Инструктирование пользователей ОС о необходимости соблюдения мер безопасности при работе с ОС и контроль за соблюдением этих мер.

4. Регулярное создание и обновление резервных копий программ и данных ОС.

5. Постоянный контроль изменений в файлах конфигурации данных и политике безопасности ОС.

Адекватная политика безопасности

Задача обеспечения адекватной политики безопасности – одна из наиболее важных задач администратора. Это достаточно трудная задача.

Существует некоторое противоречие - чем лучше защищена ОС, тем труднее с ней работать пользователям и администраторам. Это обусловлено следующими факторами.

1. Неинтеллектуальная СЗИ не всегда способна определить, является ли некоторое действие пользователя злонамеренным. Поэтому зачастую она не пресекает некоторые виды НСД, либо запрещает легальные действия. Чем выше защищенность, тем шире класс легальных действий, которые система запрещает. Например, если некоторому пользователю запрещено создавать файлы на ЖД, то этот пользователь не сможет запустить ни одну программу, для которой необходимо создавать временные файлы. С точки зрения рассматриваемой политики без-ти, создание временного файла является НСД, и в том, что оно пресекается ошибки нет. Просто в данной ПБ класс НСД настолько широк, что это препятствует нормальной работе пользователя с ОС.

2. Чем больше в системе защитных функций, тем больше времени и средств нужно тратить на поддержание защиты. Некоторые пользователи установят UNIX и думают, что защищены. Однако, защищенность UNIX требует долгого и упорного труда администратора.

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

4. Поддержание слишком жесткой политики безопасности может негативно сказаться на надежности функционирования ОС. (WINNT – отказ от выполнения определенных программ). В некоторых случаях ошибки в организации политики трудно выявить. Пример – если запретить псевдопользователю SYSTEM, от имени которого выполняются системные процессы, доступ к исполняемым файлам системных процессов, ОС не сможет загрузиться. Таким образом, чрезмерная ПБ привела к краху ОС. В других случаях, подобная ПБ может приводить к трудно выявляемым ошибкам и сбоям в процессе функционирования.

Таким образом, при определении адекватной политики безопасности не следует путаться достигнуть максимально возможного уровня защищенности ОС. Необходимо стремиться к оптимуму – не слишком малой защищенности, но и не к чрезмерному ужесточению мер, чтобы это не влияло на работу в системе. При определении адекватной политики необходимо руководствоваться кругом решаемых задач. Не существует адекватной политики безопасности на все случаи жизни. Адекватность определятся кругом решаемых задач, архитектурой ОС, ее конфигурацией, прикладными программами, аппаратными возможностями.

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

Определение и поддержание адекватной политики безопасности ОС в общем случае можно разделить на ряд этапов.

1.Анализ угроз. Среди возможных угроз выделяются наиболее опасные, защите от которых нужно уделять максимум сил и средств.

2. Формирование требований к политике безопасности . В данном случае администратор определяет, какие средства и методы будут применяться для защиты от тех или иных угроз. Например, защиту от НСД можно решать либо криптографическими средствами, либо используя средства разграничения доступа, либо соответствующую аппаратуру. Одновременно – анализ побочных эффектов. Администратор должен выбрать оптимальный метод.

3. Формальное определение политики безопасности. Здесь администратор конкретно формулирует, как должны реализовываться требования к защите. Достаточно ли средств ОС, или необходима установка дополнительных пакетов защиты. В последнем случае выбирается требуемое ПО. Необходимо предусмотреть порядок внесения необходимых изменений в политику безопасности в чрезвычайных ситуациях, например, при попытке несанкционированного входа. Результатом данного этапа является развернутый перечень настроек конфигурации ОС и дополнительных пакетов защиты с указанием того, в каких ситуациях, какие настройки должны быть выставлены.

4. Претворение в жизнь политики безопасности.

5. Поддержание и коррекция политики безопасности. Например, изменение политики при установление нового продукта.

Лекция № 16

Аппаратное обеспечение средств защиты

Под аппаратным обеспечение средств защиты ОС понимается совокупность средств и методов, используемых для решения следующих задач:

· Управление оперативной и виртуальной памятью компьютера.

· Распределение процессорного времени между задачами в многозадачной ОС.

· Синхронизация выполнения параллельных задач в многозадачной ОС.

· Обеспечение корректности совместного доступа задач к ресурсам ОС.

· Исключение тупиковых ситуаций в процессе совместного доступа задач к ресурсам ОС.

Большая часть из этих задач в значительной степени решаются с помощью аппаратно-реализованных функций процессоров и других узлов компьютера.

Управление оперативной памятью

Основная угроза оперативной памяти заключается в том, что один процесс, выполняющийся в многозадачной системе, несанкционированно получает доступ к оперативной памяти другого процесса, выполняющегося параллельно. Данная угроза представляет опасность не только с точки зрения обеспечения надежности ОС, но и с точки зрения обеспечения ее безопасности.

Существуют 2 способа защиты ОЗУ процесса от несанкционированного доступа со стороны других процессов.

1. При каждом обращении процессора к ОЗУ осуществляется проверка корректности доступа. Теоретически, это позволяет создать абсолютно надежную защиту от НСД процесса к чужой памяти. Если выделить каждому процессу отдельную область памяти и блокировать все обращения за ее пределы, доступ процесса к чужой памяти становится невозможным. Однако, при этом становится практически невозможным и взаимодействие процессов. Это в значительной повышает требования к объему оперативной памяти и понижает эффективность функционирования процессов (нужно, чтобы они взаимодействовали). В применяемых на практике ОС, значительная часть ОЗУ, выделяемой процессу, является разделяемой, т.е. доступной другим процессам. Например, в Windows все копии выполняющейся программы имеют общий код. То есть различные процессы имеют доступ к одной и той же памяти.

2. Альтернативный подход к обеспечению защиты оперативной памяти заключается в выделении каждому процессу индивидуального адресного пространства, аппаратно изолированного от других процессов. При этом, по какому бы адресу ОЗУ не обратился процесс, он не сможет обратиться к памяти, выделенной другому процессу, поскольку одному и тому же адресу в разных адресных пространствах соответствуют разные физические адреса оперативной памяти. В данном случае процессор должен поддерживать виртуальный режим. Виртуальные адреса преобразуются в физические незаметно для процесса. Данный подход обеспечивает защиту от случайных обращений процессов к оперативной памяти других процессов, но если защита реализуется преднамеренно, то такого рода подход не всегда позволяет защитить память. В данном подходе значительная часть физической памяти является разделяемой, то есть проецируется сразу в несколько адресных пространств. При этом опять существует опасность преднамеренного несанкционированного воздействия одного процесса на другой.

Кроме этого, для предотвращения несанкционированного использования отладчиков, обычно выдвигается требование, согласно которому политика безопасности, принятая в защищенной ОС не должна позволять запуск отладчиков.

Управление планированием задач. Возможности атаки и защита.

Планирование задач в многозадачной ОС заключается в распределении ОС времени ЦП между параллельно выполняемыми задачами. Неэффективное планирование задач может негативно сказаться как на эффективности и надежности функционирования ОС, так и повлиять на ее защищенность.

Планирование задач может быть двух типов.

1. Вытесняющее.

2. Не вытесняющее.

Во втором случае, выполнение задачи может быть прервано только по инициативе самой задачи. Задача, выполнив необходимые действия, должна самостоятельно прервать свое выполнение (Win 3.1). Здесь пока задача не завершила обработку сообщения, другие задачи не могут получить управления. Если задача зациклилась, то другие задачи никогда не получат управления – ОС зависает. Вывести из строя такую ОС можно просто написав пустой цикл. Обычно ОС с не вытесняющим планированием содержат спец. средства аварийного завершения задач в экстренных случаях, но эти средства никогда не работают достаточно надежно.

При планировании задач с вытеснением, выполнение любой задачи может быть прервано в любой момент. Это реализуется, как правило, с помощью специальных функций процессора. На программном уровне это реализовано в OS/2 и данная реализация негативно сказывается на производительности ОС.

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

1. Поддерживается вытеснение задач.

2. Создание высокоприоритетных задач доступно только привилегированным пользователям.

3. Критичные для обеспечения безопасности системы задачи защищены от несанкционированного вмешательства в ход их выполнения (например, от несанкционированного снижения приоритета подсистем защиты).

4. Фатальный сбой в процессе функционирования одной из задач, критичных для обеспечения безопасности, должен вызывать крах ОС.

Обеспечение корректности совместного доступа к объектам

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

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

Предотвращение тупиковых ситуаций

Тупиковая ситуация может возникнуть тогда, когда несколько программ одновременно пытаются открыть несколько одних и тех же объектов в режиме монопольного доступа. Если одна программа открыла одну часть объектов, а другая – другую, то ни одна из программ сможет открыть остальные объекты до тех пор, пока другая программа их не закроет. Если функции закрытия объектов не предусмотрены ни в одной из программ, ситуация становится тупиковой – каждая программа ждет, пока другая закроет открытые ею объекты.

Один из методов борьбы с тупиковыми ситуациями состоит в следующем: если программа для выполнения некоторой операции должна открыть в монопольном режиме несколько объектов ОС, но не смогла этого сделать, так как некоторые из этих объектов уже открыты в монопольном режиме другой программой, то она должна закрыть все уже открытые объекты, подождать некоторое время и повторить операцию сначала. Наилучшие результаты – если время ожидания случайно.

Уровни привелигированности

Для реализации защитных механизмов на Intel могут использоваться уровни привилегированности. Уровень привилегированности - это числовой идентификатор, принимающий значения от 0 до 3, который определяет возможности задачи выполнять команды процессора, модифицировать регистры и области ОЗУ и т.д. Чем меньше идентификатор уровня, тем более полный доступ имеет задача к аппаратным возможностям процессора. Множество задач, обладающих некоторым конкретным уровнем привилегированности- кольцо защиты. Например, если программа имеет уровень 3, то третье кольцо. Обычно код программы – в третьем кольце, а код ОС – в нулевом. Первое и второе – редко (OS/2). RISC – 2 кольца.

Лекция № 17

Защищенные механизмы в NT

Ядро и драйверы устройств в NT – в нулевом кольце, весь остальной код ОС и программы – в третьем. 1 и 2 - не используются.

Планирование задач

Каждый поток может находиться в одном из трех состояний –

1. Выполняющемся.

2. Ожидающем – ожидает сигнала от внешнего устройства.

3. Прерванном – поток готов выполняться и ожидает своей очереди.

Многозадачность – вытесняющая. Для вытеснения – аппаратное прерывание от таймера.

Каждый поток имеет приоритет – от 1 до 31. Чем выше приоритет, тем больше шансы у процесса получить квант времени. Для присвоения потокам приоритетов в NT применяется двухступенчатая система – абсолютный приоритет потока вычисляется на основе

1. Класса приоритета процесса.

2. Относительного приоритета потока.

Каждый процесс имеет базовый приоритет, определяемый классом приоритета процесса. Базовые приоритеты имеют следующие значения:

· Фоновый (idle): 4

· Нормальный (normal): 9 если процесс обслуживает активное окно и 7 в противном случае.

· Высокий (high): 13.

· Реального времени (real-time): 24.

Обычно хранители экрана – фоновый класс приоритета, прикладные программы – нормальный класс и системные процессы – высокий. Реальное время – редко.

Относительные приоритеты могут быть следующими:

· Фоновый (idle): 16 если процесс имеет класс приоритета реального времени и 1 в противном случае.

· Низший (lowest): на 2 ниже базового приоритета процеса.

· Пониженный (belownormal): на 1 ниже базового приоритета процесса.

· Нормальный (normal): совпадает с базовым приоритетом процесса.

· Повышенный: на 1 выше базового приоритета процесса.

· Высший: на 2 выше базового приоритета процесса.

· Критичный: 31, если базовый - приоритет реального времени или 16 в ином случае.

В NT поддерживается временное повышение приоритета, для потоков, которые долгое время ожидают сигнала от медленнодействующих устройств (FD, Modem).

Обеспечение корректности совместного доступа к объектам.

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

Исключение составляют только объекты типа файл, которые можно открывать в режиме совместной записи. В режиме совместной записи файл должны открывать все процессы. Каждый процесс при записи/чтении должен заблокировать соответствующий участок файла.

Для обеспечения корректности совместного доступа к данным, не являющимся объектами ОС, в NT применяются мьютексы, критические секции и семафоры.

Мьютексы

Мьютекс представляет собой объект файловой системы, который может быть либо свободным, либо принадлежать одному из потоков ОС. Два потока не могут одновременно владеть одним и тем же мьютексом. NT поддерживает функции, которые позволяют создать мьютекс либо освободить его. Каждый поток, перед тем, как обратиться к совместно используемым данным, пытается завладеть мьютексом. Если мьютекс в настоящее время занят, поток ждет его освобождения. Если несколько запросов на захват - то в порядке очереди вне зависимости от приоритета. Мьютекссы могут эффективно использоваться для организации совместного доступа к оперативной памяти, разделяемым между несколькими процессами.

Аудит

Аудит - регистрация в специальном журнале безопасности потенциально опасных событий для ОС. Необходимость ведения данного журнала обусловлена следующими причинами:

1. Подсистема защиты ОС не обладая интеллектом, не способна отличить случайные ошибки пользователей от злонамеренных действий (неправильный ввод пароля - случайность или взлом).

2. Необходимо хранить предисторию.

3. Если произошла атака, то администратор должен выяснить, когда была начата атака и каким образом она осуществлялась.

Требования к аудиту

1. Только ОС может добавлять записи в журнал безопасности ОС.

2. Ни один субъект доступа, в том числе и ОС не имеет возможности редактировать или удалять отдельные записи в журнале аудита.

3. Только пользователи-аудиторы, обладающие соответстующей привелегией, могут просматривать журнал аудита.

4. Только пользователи-аудиторы могут очищать журнал аудита. Запись об этом событии вносится в журнал.

5. При переполнении журнала аудита ОС аварийно завершает работу. После перезагрузки работать с ОС могут только аудиторы.

Политика аудита - совокупность правил, то, какие события должны регистрироваться в журнале аудита. Для адекватной политики безопасности, в журнале аудита должны обязательно регестрироваться следующие события

1. Попытки входа-выхода пользователей из системы.

2. Попытки изменения списка пользователей.

3. Попытки изменения политики безопасности, в том числе, и политики аудита.

Выбор остальных событий определяется администратором. В некотрых ОС реализована возможность оповещения аудиторов о наиболее важных событиях, которые произошли в системе.

В ОС UNIX поддерживается регистракция следующих событий:

1. Загрузка-выгрузка системы.

2. Успешный вход и выход из системы.

3. Создание-уничтожение процесса.

4. Сделать объект доступным (открыть файл, сообщение, смонтировать файловую систему и т.д.).

5. Отобразить объект в субъект (выполнение программы).

6. Модификация объекта (запись в файл).

7. Сделать объект недоступным (закрыть файл, размонтировать файловую систему и т.д.).

8. Создание объекта (файла,...).

9. Удаление объекта.

10. Изменение разграничения доступа.

11. Отказ доступа.

12.Действия системных администраторов и операторов.

13. Процессы, которые пытаются превысить свои полномочия.

14. Отказы в рессурсах (отсутствие файла, переполнение памяти, и т.д.).

15. Посылка сигналов и сообщений процессам.

16. Модификация процесса.

17. События системы контроля.

18. События базы данных (изменение базы данных безопасности и ее целостности).

19. События подсистемы (использование защищенных подсистем).

20. Использование привилегий (контроль действий с использованием различных привилегий).

Разграничение доступа в NT

Операционная система NT поддерживает 22 метода доступа субъектов к объектам. Шесть из них представляют собой стандартные методы доступа и поддерживаются для объектов всех типов.

· Удаление объекта.

· Получение и изменение атрибутов защиты объекта

· Изменение владельца объекта.

· Получение и изменение параметров аудита в отношении объекта.

· Синхранизация – ожидание сообщения от объекта.

Для каждого типа объекта поддерживается до 16 специфичных методов доступа.

Следующие методы доступа в NT требуют наличия у субъектов доступа специальных превилегий.

· Создание нового сервиса.

· Блокирование списка сервисов.

· Запуск сервиса.

· Останов сервиса.

· Приостановка/возобновление сервиса.

· Назначение процессу маркера доступа.

· Получение или изменение параметров аудита в отношении объекта.

Привилегии субъектов в NT.

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

Существуют следующие привилегии:

· Привилегия завершать работу ОС и перезагружать компьютер.

· Привилегия устанавливать системное время.

· Привилегия анализировать производительность одного процесса.

· Привилегия анализировать производительность всей ОС.

· Привилегия создавать постоянные объекты в ОЗУ.

· Привилегия создавать резервные копии информации, хранящей на жестких дисках.

· Привилегия восстанавливать информацию из резервных копий.

· Привилегия назначать процессам и потокам высокие приоритеты.

· Привилегия изменять системные переменные среды.

· Привилегия отлаживать программы.

· Привилегия загружать и выгружать системные драйверы и сервисы.

· Привилегия аудита.

· Привилегия объявлять себя владельцем любого объекта.

· Привилегия добавлять записи в журнал аудита.

· Привилегия создавать маркеры доступа.

· Привилегия назначать процессам маркеры доступа.

· Привилегия выступать как часть ОС.

· Привилегия получать оповещения от файловых систем.

Назначать привилегии нужно очень осмотрительно. Некоторые из перечисленных привилегий позволяют обойти подсистемы защиты.

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

· Привилегия создавать резервные копии информации и восстанавливать ее позволяет пользователю игнорировать разграничение доступа по чтению/записи и т.д.

· Привилегия назначения процессам высокого уровня приоритета позволяет ему завесить ОС, создав процесс с высоким приоритетом и введя его в вечный цикл.

· Пользователь, обладающий привилегией изменять системные переменные среды, может изменив значения переменных path и windir добиться того, чтобы поиск ОС исполняемых модулей начинался с его директории и поместить туда программную закладку.

· Привилегия отлаживать программы позволяет пользователю обращаться к любому процессу по любому методу доступа, что присваивает ему неограниченные полномочия.

· Привилегия загружать и выгружать драйверы и сервисы позволяет пользователю выполнять произвольный код от имени и с правами ОС. Пользователь может внедрить программную закладку под видом драйвера или сервиса. Так как драйверы могут игнорировать большинства защитных функций NT, то эта возможность дает неограниченные полномочия.

· Привилегия аудитора дает пользователю возможность маскировать свои несанкционированные действия.

· Привилегия выступать как часть ОС позволяет пользователю выполнять потенциально опасные воздействия, брать на себя функции ОС, связанные с идентификацией, аутентификацией и авторизацией пользователя.

ВОПРОСЫ ДЛЯ КОНТРОЛЯ

ЛЕКЦИЯ 1

1. Почему аппаратная реализация защитных механизмов считается более стойкой по сравнению с программной?

2. Приведите примеры нарушения целостности программных механизмов защиты.

3. Что понимают под идентификацией и аутентификацией? В чем заключается различие данных этапов и как они связаны между собой?

4. Чем определяется стойкость к взлому подсистемы идентификации и аутентификации?

5. Перечислите основные недостатки парольных подсистем идентификации и аутентификации.

6. Перечислите основные угрозы парольным подсистемам идентификации и аутентификации.

7. Перечислите требования к выбору и использованию паролей?

8. Как количественно оценить стойкость к взлому парольных подсистем идентификации и аутентификации?

9. Как изменится стойкость к взлому подсистемы парольной аутентификации при увеличении характеристик A,L,V,T? При их уменьшении?

ЛЕКЦИЯ 2

1. Перечислите основные угрозы базам данных аутентификации в компьютерных системах.

2. Как реализуется защита от угрозы непосредственного доступа злоумышленника к БД аутентификации?

3. Опишите типовые схемы хранения ключевой информации в компьютерных системах и алгоритмы идентификации и аутентификации пользователей в рамках данных схем.

4. Сформулируйте и докажите утверждение о подмене эталона.

5. Как реализуется защита от угрозы несанкционированного изучения БД аутентификации.

6. Почему непосредственное шифрование БД аутентификации не является стойким ко взлому?

7. Опишите алгоритм хэширования LANMAN. Укажите на уязвимые места данного алгоритма.

8. Опишите алгоритм хэширования NTLM.

ЛЕКЦИЯ 3

1. Что понимают под атаками методом повторов при удаленной аутентификации?

2. В чем заключается механизм запрос-ответ при безопасной удаленной аутентификации?

3. В чем заключается механизм отметки времени при безопасной удаленной аутентификации?

4. Опишите схему протокола безопасной удаленной аутентификации CHAP.

5. Почему злоумышленник не может восстановить ответ клиента в протоколе CHAP?

6. Опишите протокол одноразовых ключей S/KEY.

7. Почему злоумышленник не может восстановить следующий пароль в последовательности в протоколе S/KEY?

8. Какой из паролей передается раньше в протоколе S/KEY – Y1 или Y2?

ЛЕКЦИЯ 4

1. Приведите примеры технических устройств, с помощью которых может решаться задача идентификации пользователя?

2. Приведите примеры технических устройств, с помощью которых может решаться задача идентификации и аутентификации пользователя?

3. В чем заключается различие между пассивными и активными пластиковыми картами?

4. Приведите примеры пассивных и активных карт.

5. Перечислите основные компоненты интеллектуальных карт.

6. Какова область применения интеллектуальных карт?

7. Каков размер идентификатора в iButton?

8. В каком компоненте смарт-карты хранится операционная система?

9. В какой компонент смарт-карты загружаются ключи при выполнении криптографических операций?

ЛЕКЦИЯ 5

1. Что понимается под биометрической аутентификацией пользователя? Приведите примеры биометрических характеристик.

2. Перечислите основные отличия методов биометрической аутентификации пользователя от других (например, парольных).

3. Что из себя представляет вектор биометрических признаков?

4. Что понимают под коэффициентом ошибочных отказов и коэффициентом ошибочных подтверждений биометрической системы?

5. Дайте геометрическую интерпретацию коэффициентов ошибочных отказов и ошибочных подтверждений.

6. Как в биометрических системах принимается решение о прохождении либо не прохождении пользователем аутентификации?

7. Какие функции выполняют СКД?

8. Какой компонент СКД принимает решения о допуске \ недопуске пользователя на охраняемый объект?

ЛЕКЦИЯ 6

1. Перечислите меры, используемые для защиты программных продуктов от несанкционированного использования.

2. В чуть заключается суть организационно-экономических мер защиты программных продуктов?

3. Перечислите модули системы технической защиты ПО от несанкционированного использования. Кратко охарактеризуйте функции каждого из них.

4. Приведите примеры характеристик среды, к которым можно осуществить привязку ПО для обнаружения факта несанкционированного использования.

5. В чем достоинства и недостатки встроенных и пристыковочных систем защиты ПО?

6. На какие из модулей системы защиты ПО от несанкционированного использования обычно осуществляет атаку злоумышленник?

7. Перечислите требования к блоку сравнения характеристик среды.

8. В чем особенности атак злоумышленника на блок установки характеристик среды и блок ответной реакции?

ЛЕКЦИЯ 7

1. Что собой представляют электронные ключи HASP?

2. Перечислите типы электронных ключей HASP. Кратко охарактеризуйте их.

3. Перечислите основные элементы электронных ключей HASP.

4. Перечислите основные функции HASP4 Standard, MemoHASP, TimeHASP, NetHASP.

5. Попарно сравните возможности ключей HASP4 Standard, MemoHASP, TimeHASP, NetHASP.

6. Словесно опишите несколько приемов защиты ПО, которыми Вы будете пользоваться при использовании HASP4 Standard, MemoHASP, TimeHASP, NetHASP.

7. В чем достоинства и недостатки пристыковочного механизма защиты ПО с помощью HASP и защиты, основанной на использовании API функций HASP.

8. Может ли электронный ключ HASP использоваться для решения задач идентификации пользователей. Если может, то какие типы?

9. Что представляет собой модель защиты структурным кодом PCS?

ЛЕКЦИЯ 8

1. Перечислите и охарактеризуйте базовые методы нейтрализации систем защиты ПО от несанкционированного использования.

2. Перечислите средства статического исследования ПО. Кратко охарактеризуйте их.

3. Перечислите средства динамического исследования ПО. Кратко охарактеризуйте их.

4. Перечислите и охарактеризуйте базовые методы противодействия отладке программного обеспечения.

5. Перечислите и охарактеризуйте несколько триков для отладчиков реального и защищенного режимов. В чем их недостатки?

6. Перечислите и охарактеризуйте базовые методы противодействия дизассемблированию программного обеспечения.

7. Охарактеризуйте способ защиты от отладки, основанный на особенностях конвейеризации процессора.

8. Охарактеризуйте возможности противодействия отладке и дизассемблированию, основанные на использовании недокументированных инструкций и недокументированных возможностей процессора. В чем недостатки данных методов?

9. Охарактеризуйте шифрование кода программы как наиболее универсальный метод противодействия отладке и дизассемблированию ПО.

ЛЕКЦИЯ 9

1. Охарактеризуйте средства анализа системы защиты ПО по данным. Как защититься от данных средств?

2. Охарактеризуйте средства анализа системы защиты ПО по алгоритмам. Как защититься от данных средств?

3. Охарактеризуйте средства преодоления систем защиты ПО. Как защититься от данных средств?

4. Охарактеризуйте средства обхода систем защиты ПО. Как защититься от данных средств?

5. Что понимают под опосредованным НСД?

6. Дайте определение программы с потенциально опасными последствиями. Какие функции свойственны данным программам?

7. Перечислите основные классы программ с потенциально опасными последствиями. Дайте их сравнительную характеристику.

8. Что понимают под активизирующим событием? Перечислите основные виды активизирующих событий для РПВ.

9. Перечислите и охарактеризуйте основные модели взаимодействия прикладной программы и РПВ.

ЛЕКЦИЯ 10

1. Опишите основные группы деструктивных функций, свойственных программным закладкам.

2. Охарактеризуйте компьютерные вирусы как один из классов РПВ. Перечислите основные свойства компьютерного вируса.

3. Какие стадии и этапы включает в себя жизненный цикл компьютерного вируса?

4. Какие вирусы называют полиморфными?

5. Опишите средства борьбы с компьютерными вирусами.

6. Перечислите общие и специализированные методы борьбы с РПВ.

7. Что понимают под изолированной программной средой?

8. Укажите основные элементы поддержки ИПС.

ЛЕКЦИЯ 11

1. Согласно какому РД выполняется тестирование ПО на наличие НДВ?

2. Сколько существует уровней контроля отсутствия НДВ?

3. Как осуществляется контроль исходного состояния программного обеспечения?

4. Какой уровень контроля необходим для ПО, обрабатывающего информацию «Особой Важности»?

5. Какой уровень контроля необходим для ПО, обрабатывающего информацию «Совершенно секретно»?

6. Какой уровень контроля необходим для ПО, обрабатывающего информацию «Секретно»?

7. Какой уровень контроля необходим для ПО, обрабатывающего конфиденциальную информацию?

8. На каком из уровней контроля осуществляется больше проверок – первом или четвертом?

ЛЕКЦИЯ 1 2

1. Что подразумевает статический анализ исходных текстов программ?

2. Что подразумевает динамический анализ исходных текстов программ?

3. Как осуществляется контроль полноты и отсутствия избыточности исходных текстов ПО на уровне файлов на различных уровнях контроля НДВ?

4. Что понимается под контролем полноты и отсутствия избыточности исходных текстов ПО на уровне функциональных объектов (процедур)?

5. Что понимается под контролем связей функциональных объектов (модулей, процедур, функций) по управлению?

6. Что понимается под контролем связей функциональных объектов (модулей, процедур, функций) по информации?

7. Что понимается под контролем информационных объектов различных типов?

8. Что понимается под формированием перечня маршрутов выполнения функциональных объектов (процедур, функций)?

ЛЕКЦИЯ 1 3

1. Перечислите перечень типовых дефектов ПО.

2. Перечислите формы проявления программных дефектов.

3. Перечислите ошибки управления в ПО.

4. Прокомментируйте ошибки, связанные с затиранием команд и переменных.

5. Прокомментируйте дефект ПО – «Обход контроля или неправильные точки контроля».

6. Прокомментируйте дефект ПО – «Скрытые и недокументированные вызовы из прикладных программ, команд ОС и аппаратных команд».

7. Прокомментируйте дефект ПО – «Неполное прерывание выполнения программ».

8. К чему может привести дефект ПО – «Не удаление средств отладки до начала эксплуатации».

ЛЕКЦИЯ 14

1. Перечислите классы угроз ОС по цели.

2. Перечислите классы угроз ОС по принципу воздействия на ОС.

3. Перечислите классы угроз ОС по характеру воздействия на ОС.

4. Перечислите классы угроз ОС по способу действий злоумышленника.

5. Перечислите классы угроз ОС по способу воздействия на объект атаки.

6. Перечислите классы угроз ОС по слабости защиты.

7. Охарактеризуйте типичные атаки на ОС.

8. Охарактеризуйте понятие «Жадные программы».

ЛЕКЦИЯ 15

1. Что такое «Защищенная ОС»?

2. Какие существуют подходы к построению защищенных ОС?

3. Какой из подходов к построению защищенных ОС более безопасен?

4. Перечислите примеры административных мер защиты ОС?

5. Почему политика безопасности должна быть адекватной условиям защиты?

6. Почему слишком жесткая политика безопасности может негативно сказаться на надежности функционирования ОС?

7. Перечислите этапы определения и поддержания адекватной политики безопасности.

8. Почему чем лучше защищена ОС, тем труднее работать с ней пользователям?

ЛЕКЦИЯ 1 6

1. Что понимается под аппаратным обеспечением средств защиты ПО?

2. Какие 2 способа используются для защиты ОЗУ процесса от несанкционированного доступа со стороны других процессов?

3. Что такое вытесняющее планирование задач?

4. Как защищаться от угрозы приостановки или прекращения выполнения задач, критичных для обеспечения безопасности, операционной системы?

5. Что такое тупиковая ситуация?

6. Как предотвратить тупиковую ситуацию в ОС?

7. Что такое уровень привилегированности процесса?

8. Что такое кольцо защиты?

ЛЕКЦИЯ 17

1. В каких состояниях может находиться поток?

2. Как вычисляется приоритет процесса?

3. Какие бывают базовые и относительные приоритеты?

4. Что такое мьютекс и какова технология его использования?

5. Какие требования к аудиту в ОС?

6. Как необходимо формировать политику аудита?

7. В чем заключается разница между правами доступа и привилегиями?

8. Какие привилегии субъектов существуют в WindowsNТ?

9. Почему привилегии субъектам необходимо раздавать осмотрительно?

10. Какие 6 стандартных методов доступа существует в ОС WindowsNT?