Щеглов А.Ю. Защита компьютерной информации от несанкционированного доступа

Подождите немного. Документ загружается.

Глава 18. Разработка и оптимизация механизма

уровневого

контроля

2. С целью более эффективного использования механизма целесооб-

разна реализация приоритетного обслуживания заявок на контроль

списков в реальном времени. Как видим из представленных графи-

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

сведены к минимуму.

3. Возможность более эффективного использования механизма также кроет-

ся

увеличении параметра

Данная возможность состоит в том, чтобы

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

в частности, если атака будет проводиться исполнением каких-либо дей-

ствий с клавиатуры (не автоматически из созданной и несанкциониро-

ванно запущенной им программы), то значение данного параметра увели-

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

реализации данного уровня защиты будут минимальными.

Анализ контролируемых списков санкционированных событий

Теперь в двух словах остановимся на анализе контролируемых списков

санкционированных событий с точки зрения задания ограничений

аг;

Очевидно, что можно выделить две группы атак на защищаемый объект -

автоматическая и автоматизированная. Автоматическая атака реализует-

ся разработкой и запуском на защищаемом объекте злоумышленником

деструктивной программы (процесса). Эта программа автоматически вы-

полняет все несанкционированные действия.

Очевидно, что значение ограничения

дг

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

программ (процессов) должно быть минимально. Контролю списков за-

пущенных процессов следует назначить максимальный приоритет. Дру-

гая группа атак, например, регистрация в системе несанкционированно-

го пользователя, изменение ключа реестра ОС и т.д., предполагает либо

выполнение ручных действий злоумышленника (в этом случае ограни-

чения

. должны устанавливаться на несколько порядков больше) либо

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

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

Сказанное в полной мере подтверждает сделанные ранее выводы, что ос-

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

действие запуску на защищаемом объекте несанкционированных пользо-

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

18.6. Практические рекомендации по

реализации механизма уровневого контроля

С учетом проведенного анализа сформулируем некоторые основные ре-

комендации по практической реализации механизма уровневого контро-

ля в системе добавочной защиты.

331

Часть V. Контроль корректности функционирования механизмов защиты

1. При реализации механизма уровневого контроля могут быть выде-

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

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

2. Для механизма контроля процессов должен устанавливаться макси-

мальный приоритет, т.к. данный контроль характеризуется жестки-

ми ограничениями

iatj

Ограничения

вг

(

для остальных событий

на несколько порядков больше. Таким образом, как было показано

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

для приоритетного обслуживания (может быть достигнут макси-

мальный результат за счет реализации приоритетных расписаний).

3. Как следует из рис.

18.12...18.14,

при реализации приоритетной

дисциплины обслуживания с выделением максимального приори-

тета одному механизму контроля — контролю списков запущенных

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

числительного ресурса защищаемого объекта при реализации меха-

низма уровневого контроля на всем интервале загрузки системы (в

штатном режиме функционирования системы - - без перегрузок,

данные потери находятся в пределе единиц процентов).

Возвращаясь

к схеме реализации механизма уровневого контроля, пред-

ставленной на рис. 17.2, отметим, что в задачи блока управления 4

должна быть включена задача диспетчеризации заявок по приоритетно-

му расписанию, реализуемая в соответствии с рассмотренным выше

способом (реализуется схемой, представленной на рис. 18.7).

332

глава 19

Механизмы контроля

целостности файловых объектов

19.1.

Задачи и проблемы реализации

механизмов контроля целостности

Контроль целостности файловых объектов представляет собой самостоятель-

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

целостности файловых объектов представляет проверка соответствия контро-

лируемого объекта эталонному образцу. Для контроля могут использоваться

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

фикации объекта и т.д. При необходимости содержать контролируемый объект

в эталонном

срстоянии

данные механизмы могут осуществлять автоматичес-

кое либо автомтизированное (под управлением пользователя или админист-

ратора безопасности) восстановление несанкционированно измененного фай-

лового объекта из эталонной копии.

Основной проблемой реализации механизмов контроля целостности фай-

ловых

объектов

является их весьма сильное влияние на загрузку вычисли-

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

первых, может потребоваться контролировать большие объемы информации,

что связано с большой продолжительностью выполнения процедуры конт-

роля. Во-вторых, может потребоваться непрерывное поддержание файлового

объекта в эталонном состоянии. При этом возникает вопрос: с какой час-

тотой запускать продолжительную процедуру контроля? Если делать это

часто, то получим существенное снижение производительности системы, если

редко, то такой контроль, в частности, автоматическое восстановление

объектов из эталонной копии, вообще имеет мало смысла.

Таким образом, основным вопросом при реализации механизмов конт-

роля целостности файловых объектов является выбор принципов и ме-

ханизмов запуска процедуры контроля (очевидно, что синхронный за-

пуск — запуск контроля по расписанию, который без существенного

снижения производительности системы может производиться достаточ-

но редко, следует рассматривать в качестве дополнительного механизма).

333

Часть V. Контроль корректности функционирования механизмов защиты

Контролируемые файловые объекты могут быть классифицированы в

соответствии с функциональным назначением: исполняемые файлы (про-

граммы)

и файлы данных.

19.2.

Асинхронный запуск процедуры

контроля целостности и его реализация

Под асинхронным запуском понимаем запуск процедуры не периодичес-

ки во времени, а по причине возникновения какого-либо события. Реа-

лизация асинхронного запуска процедуры контроля, в предположении оп-

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

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

Рассмотрим возможные подходы к реализации асинхронного (причинно-

го) запуска процедуры контроля целостности.

Запуск контроля целостности исполняемого файла

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

запуска процедуры контроля интуитивно понятен — контроль следует за-

пускать перед запуском программы -- перед чтением соответствующего

исполняемого файла. Другими словами, система защиты должна перехва-

тывать функцию чтения исполняемого файла (соответствующую API

функцию — запрос от приложения к ядру ОС), запускать процедуру конт-

роля и затем (при необходимости, уже после восстановления файла из

эталонной копии) выдавать данную функцию на обработку в ядро ОС.

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

ти системы, так как контроль осуществляется только в необходимые мо-

менты — только при запуске программы. При этом предполагается, что

программа запускается — значительно реже, чем осуществляется обра-

щение к файлам данных.

Запуск контроля целостности как реакция механизма контроля

списков санкционированных событий

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

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

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

частыми. Поэтому механизм контроля перед чтением файла данных (по

аналогии с контролем исполняемых файлов)

-может

быть не всегда при-

меним (использование данного подхода может привести к существенно-

му влиянию механизма защиты на производительность системы).

334

Глава

19.

Механизмы контроля целостности файловых объектов

В качестве альтернативного подхода к асинхронному запуску процедуры

контроля целостности файлов данных может быть рассмотрен способ

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

уровневого контроля списков санкционированных событий (механизм

описан выше), что проиллюстрировано рис. 19.1.

Запуск процедур

контроля

Переход процедур контроля

Рис.

19.1.

Схема асинхронного запуска процедуры контроля целостности

Здесь механизм контроля событий N-ro уровня не что иное, как контроль

целостности файлов данных. Управление данному механизму передается ос-

тальными механизмами контроля событий (уровней 1, 2, ..., N~l) при обна-

ружении любым из этих уровней несанкционированного события в системе.

Таким образом, при данном способе контроля причиной запуска проце-

дуры контроля файлов данных (асинхронный запуск) является наличие

косвенных признаков несанкционированного доступа. При этом запуск

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

жении в системе потенциально опасной ситуации — угрозы НСД. Бла-

годаря этому минимизируются затраты вычислительного ресурса систе-

мы на выполнение процедуры контроля, т.к. в штатном режиме

функционирования системы (при отсутствии угрозы НСД) контроль це-

лостности не осуществляется.

Синхронный контроль (по расписанию) здесь может использоваться в допол-

нение к процедуре причинного запуска процедуры контроля. Запуск проце-

дуры по расписанию реализуется системой диспетчеризации,

335

Часть V. Контроль корректности функционирования механизмов защиты

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

шения задач очистки памяти. Кроме интуитивно понятных асинхрон-

ных

способов,

например, при запуске или завершении процесса, уда-

лении файла, авторизации пользователя и т.д. (различные подходы

применяются для гарантированной очистки оперативной и дисковой

памяти), принудительная очистка памяти (например, оперативной) мо-

жет осуществляться как реакция на факт обнаружения несанкциониро-

ванного события.

19.3. Проблема контроля целостности

самой контролирующей программы

Другая проблема реализации механизмов контроля целостности состоит

в следующем — если контроль целостности реализуется программно, то

возникает вопрос контроля целостности и корректности функциониро-

вания собственно контролирующей программы (можно же исполняемый

файл данной программы модифицировать первым). Естественно, что для

решения данной задачи в общем случае необходимо осуществление кон-

троля каким-либо внешним средством — аппаратной компонентой. Та-

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

аппаратной системы защиты «Электронный замок». Здесь платой конт-

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

стемы (как следствие, системы защиты) при этом разрешается только в

эталонном виде.

Однако это лишь частичное решение проблемы, т.к. остается задача кон-

троля в процессе функционирования системы, которая вновь возлагается

на программное средство. При этом опять же контролирующая програм-

ма может быть модифицирована, например, остановлено ее выполнение.

Для решения данной задачи может рассматриваться следующий альтерна-

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

поненту, аппаратная же компонента системы защиты обеспечивает коррек-

тное выполнение контролирующей программы. Данный подход позволяет

решать задачу контроля в течение всего времени функционирования систе-

мы, предотвращая при этом возможность некорректного функционирова-

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

Поскольку решение данной задачи напрямую связано с функциями ап-

паратной компоненты системы защиты, рассматриваемый подход будет

изложен в следующих главах (в части VI книги), посвященной примене-

нию аппаратных средств обеспечения компьютерной безопасности.

336

Применение

средств

аппаратной защиты

Часть VI

Необходимость и принципы

использования аппаратных

средств защиты

Технология программно-

аппаратной защиты

Метод контроля

вскрытия аппаратуры

глава 20

Необходимость и принципы

использования аппаратных

средств защиты

20.1.

Общие положения

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

списков и механизмы контроля целостности файловых объектов. Было

сказано, что эти механизмы призваны воспрепятствовать преодолению

системы защиты (контроль списков) или свести к минимуму последствия

такого преодоления (контроль целостности). При этом было отмечено,

что в общем случае невозможно осуществлять контроль активности од-

ной программы над другой программой, запущенной на том же компью-

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

поненту системы защиты -- плату, устанавливаемую в свободный слот

защищаемого компьютера.

В этом разделе книги будут рассмотрены методы и подходы по исполь-

зованию аппаратных средств защиты, а также способы их комплексиро-

вания с программными средствами.

Сразу же отметим, что в связи с использованием аппаратной компонен-

ты появляется новая угроза информационной безопасности — несанкци-

онированное удаление аппаратной компоненты системы защиты. Поэтому

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

уровня защиты -- уровня контроля (мониторинга) наличия оборудования

системы защиты.

ili.i!if.ra!hi;i!ta

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

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

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

темы защиты, например, посредством сброса BIOS в исходное состояние.

338

Глава 20. Необходимость и принципы использования аппаратных средств защиты

20.2. Угрозы перевода системы защиты

в пассивное состояние, их реализация

20.2.1. Классификация угроз перевода

системы защиты в пассивное состояние

В общем случае угрозы перевода ПО системы защиты в пассивное со-

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

» угроза загрузки системы без механизмов защиты (загрузки ОС без

полностью либо частично системы защиты);

» угроза перевода механизмов защиты (или системы защиты в целом) в

пассивное состояние в процессе функционирования защищаемого

объекта;

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

та (осуществляющая мониторинг активности ПО системы защиты),

то появляется дополнительная угроза — угроза удаления оборудова-

ния системы защиты (аппаратной компоненты) с целью последующе-

го перевода ПО системы защиты в пассивное состояние одним из

перечисленных выше способов.

Как и ранее, данные угрозы могут быть классифицированы как явные и

скрытые. Скрытые угрозы могут быть осуществлены с использованием соб-

ственных программ злоумышленника, а также с использованием ошибок и

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

защиты в пассивное состояние представлена на рис. 20.1.

Угрозы

перевода

ПО системы защиты

в пассивное состояние

Угрозы перевода ПО системы

защиты в

пассивное

состояние

функционирования

ого объекта

проц<

Угрозы удаления

оборудования

(аппаратной компоненты)

системы защиты

Несанкционированные

программы

пользователя

Ошибки

то

Закладки

Рис. 20.1. Классификация угроз перевода ПО

системы защиты в пассивное состояние

339

Часть VI. Применение средств аппаратной защиты

20.2.2. Анализ рассматриваемых угроз

применительно к современным ОС

Рассмотрим данные группы угроз, применительно к ОС семейства

Windows, Угроза загрузки системы без механизмов защиты (в предполо-

жении, что система защиты запускается как сервис при старте ОС) свя-

зана со следующими возможностями:

* загрузка системы с альтернативных носителей, например, с дискеты. В

этом случае, поскольку загрузка ОС, в качестве сервиса которой дол-

жна запускаться система защиты, осуществляется не с жесткого дис-

ка, система защиты не загружается;

загрузка системы в безопасном режиме (например, Safe Mode для ОС

Windows), либо в ином режиме, например, в DOS. При этом можно блоки-

ровать загрузку драйверов (основных механизмов защиты), т.е. загрузить

систему с урезанными функциями. Это не страшно для встроенный меха-

низмов ОС — встроенная система защиты не позволит их отключить, но

критично для механизмов добавочной защиты, т.к. для ОС драйверы и

прикладные средства добавочной защиты являются внешними средства-

ми. Поэтому она не обеспечивает противодействие возможному их от-

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

безопасном режиме для ОС UNIX и Windows (естественно, рассматрива-

ем технологию NT) будет то, что для ОС UNIX подобную загрузку может

осуществить только пользователь «root» после авторизации, в ОС

Windows — любой текущий пользователь после авторизации.

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

ства UNIX, т.е. рассматриваемая задача защиты характеризуется общно-

стью для альтернативных семейств ОС.

Данные угрозы могут быть как явными (например, загрузка в режиме Safe

Mode), так и скрытыми, например, инженерные пароли BIOS, возможность

программно сбросить настройки BIOS в исходное состояние (модифици-

ровав его контрольные суммы — для ОС Windows 9x/Me) и т.д.

Угроза перевода механизмов (или системы защиты) в пассивное состоя-

ние в процессе функционирования защищаемого объекта связана с явны-

ми и скрытыми возможностями по остановке выполнения процесса

системы защиты (либо вообще удаления данного процесса из системы).

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

ния процесса из списка обладают большинство системных мониторов и

множество оболочек, например, Far. Для систем Windows 95/98, где все

процессы запускаются как пользовательские (ОС не делит процессы на си-

стемные и пользовательские), из этой оболочки может быть остановлено

выполнение любого процесса, в том числе и процесса системы защиты.

Это очевидная явная угроза, основанная на архитектурных особенностях

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

скрытые угрозы. По крайней мере утверждать обратное невозможно.

340