 |
Первый опыт построения системы обнаружения нарушителя.
|
|
|
|
В первой работе, посвященной проблеме обнаружения нарушителя, в 1986 году Дороти Деннинг описала СОН IDES структура которой показана на рисунке 1.
Рисунок 1. Типовая схема функционирования СОН.
Показанная на данном рисунке структура является в некотором роде “классической”, т.к. отражает общие принципы построения многих СОН.
Для описания процесса обнаружения нарушителя используются записи аудита, профили, аномальные записи и правила действия.
Субъекты и объекты.
Как и в большинстве моделей безопасности, представление множества субъектов и множества объектов должно быть первым шагом в построении модели. В модели IDES субъектами будут активные инициаторы операций в системе (процессы вычислительной системы). Объектами будут носители информации, на которых субъекты выполняют операции (файлы и директории операционной системы). Все предположения о субъектах и объектах для схем аудита и обнаружения нарушителя должны быть одними и теми же.
Записи аудита
Второй составляющей модели IDES является запись аудита. Предполагается, что интересующая нас вычислительная система включает в себя механизм аудита, хранящий записи аудита в защищенном журнале. Однако, для того, чтобы схема обнаружения нарушителя работала в практических приложениях, нужно заранее знать подробные характеристики каждой ревизионной записи. То есть, нужно распознавать различные типы информации, которая, будет помещена в каждую ревизионную запись, как и их взаимное расположение, с тем, чтобы информация правильно обрабатывалась механизмом обнаружения нарушителя.
Предполагается, что в модели IDES записи аудита представляют собой структуры из шести компонент (т.е. шестерки), расположенные следующим образом:
|
|
|
<субъект, объект, действие, ошибка, ресурс, время>.
В такой ревизионной записи IDES субъект является инициатором действия с объектом, упоминаемым в записи. Компонента ошибки описывает любые исключительные условия, которые могут возникнуть в результате действия. Компонента ресурса предоставляет статистику всех использований ресурса во время действия. Компонента времени показывает время действия.
Приведем пример: если пользователь joe успешно использует файл myfile в 2 часа ночи и затратит при этом 2 секунды процессорного времени, то ревизионная запись этого действия может выглядеть следующим образом:
<joe, myfile, execute, no, CPU (00:02), 2:00>
Аналогично, последовательные ревизионные записи могут быть полезны при изучении текущей работы системы. Например, может такая последовательность ревизионных записей:
<joe, important_file, read, no, CPU (00:01), 5:00>
<mik, important_file, read, no, CPU (00:01), 5:01>
<scr, important_file, read, no, CPU (00:01), 5:02>
<lee, important_file, read, no, CPU (00:01), 5:03>
Это, конечно, будет означать, что многие различные пользователи систем по какой-либо причине, заинтересованы в прочтении файла important_file.
Хотя эта модель определяет записи аудита только в терминах приведенных шести компонент, вычислительные системы, несомненно, могут выполнять особые ревизионные записи для конкретных приложений. Это должно быть сделано либо добавлением, либо удалением полей из записей аудита, в зависимости от ситуации.
Профили.
Профили в модели IDES используются для характеристики ожидаемой деятельности вычислительной системы. Параметры деятельности вычислительной системы, используемые для построения профиля, могут изменяться в зависимости от типа проверяемой деятельности. Однако в большинстве случаев, случаев обычными типами информации, присутствующими в профилях, являются следующие:
Входная деятельность. Для данного пользователя или системы профили могут характеризовать обычное число входов в данное время в течение дня, предполагаемое самое раннее время входа, предполагаемую максимальную длительность входа и т.д. Практика показала, что такие параметры наиболее типичны для большинства вычислительных операционных сред. Например, для некоторых операционных сред попытка пользователей зарегистрироваться в системе в 4 часа утра не является нормальной, тогда как в других она может считаться обычным действием.
|
|
|
Параметры выполнения. Профили также могут устанавливаться в зависимости от предполагаемого типа использования ресурсов, которые должна поддерживать данная вычислительная система. Среди таких профилей, как правило, должны быть статистики использования процессорного времени, памяти и других ресурсов. Это еще один параметр, который обычно регулярен и предсказуем. В среде выполнения канцелярских отчетов, например, вызываемая программа, занимающая больше 10 минут процессорного времени, должна рассматриваться как ненормальная, в то время как в научной операционной среде она может быть совершенно нормальной. Параметры выполнения в системе обнаружения нарушителя дают средства для возможного отражения этого типа злонамеренной деятельности.
Доступ к файлам. Можно создать профили частоты чтения и записи некоторых файлов, числа отказов на запросы чтения или записи некоторых файлов и профили других параметров доступа к файлам. Этот параметр может быть менее предсказуем, но некоторые файлы могут быть помечены как по всей вероятности недоступные для обычных пользователей. Например, если обычный пользователь пытается что-либо записать в файл пароля, это можно рассматривать как ненормальное поведение. В большинстве операционных сред копирование файла пароля должно считаться подозрительной деятельностью.
Как отмечалось выше, такое профилирование может быть разумным только в том случае, если можно предсказать, как будет вести себя вычислительная система. Это особенно трудно в ситуациях, когда нужно сделать профиль для нового пользователя. Основой параметров профилирования этого пользователя должно служить ранее наблюдавшиеся поведения, однако если такого поведения еще не было, то, в общем случае нужно опираться на приблизительное предсказание поведения. В экстремальных ситуациях можно представить, что нового пользователя попросят указать, каких типов поведения можно от него ожидать. Однако нужно признать уязвимость такого подхода для возможных нарушителей, которые могут искать свое предполагаемое поведение.
|
|
|
Типичный профиль, который может быть создан в рамках модели IDES, должен включать в себя следующие компоненты:
<субъект, объект, действие, е_образец, r_образец, t_образец>.
Для такого профиля в качестве особого условия оговаривается, что как только субъект инициирует действие некоторым объектом предполагается, что условиями ошибками является е_образец, для использования ресурсов служит r_образец, а для продолжительности времени - t_образец. Например, может иметь место создания следующего профиля:
<joe, myfile, execute, no, CPU (00:01-00:04), 2:00-22:00>
Это означает, что всякий раз, когда joe использует myfile, не ожидается никаких ошибок, можно использовать от 1 до 4 секунд процессорного времени, а время работы должно быть в пределах от двух часов ночи (т.е. 2:00) до 10 часов вечера (т.е. 22:00). Аналогичные профили можно создать и для других действий, касающихся безопасности, таких как входы в систему.
Как часть профилирующей деятельности, система обнаружения нарушителя может быть, вероятно установлена для автоматического сравнивания профилей с ревизионными записями. Это обычно делается с помощью программы (зачастую, логической), которая непрерывно сравнивает различные профили с записями аудита. Для более серьезных приложений эти сравнения делаются в реальном времени, а для менее серьезных их можно сделать только один раз в конце дня.
Аномальные записи
Аномальные записи служат сигналами тревоги, возникающими всякий раз, когда проверяемое поведение совпадает с профилями. Аномальные записи должны предоставить достаточно информации для определения того, в чем состоит проблема. В модели IDES аномальными записями служат следующие тройки:
|
|
|
<события, время, профиль>.
В структуре этой аномальной записи поле “событие” указывает на действие системы, которое вызвало сигнал тревоги, поле “время” указывает, когда проблема была замечена, а поле “профиль” указывает не совпавшую структуру (поскольку в системе, вероятно, много профилей).
Например, аномальная запись может делаться всякий раз, когда какой-либо пользователь пытается войти в систему после 2 часов ночи, или когда кому-то не удается получить разрешение на вход в систему несколько раз подряд, или когда имеют место какие-либо другие аналогичные подозрительные события. Нужно заметить, что аномальные записи создаются для двух особых типов поведения:
· Поведение, подозрительное по отношению к любому пользователю системы.
· Поведение, подозрительное по отношению к какому-то особому пользователю системы.
В первом случае для установления того, что кто-либо вызывает необычное поведение системы используются общие аномальные записи и профили. Во втором случае аномальные записи и профили показывают странные действия особо пользователя. Например, некто, безуспешно пытающийся войти в систему несколько раз подряд, должен вызвать подозрения. С другой стороны, определенные пользователи, получающие доступ к системному файлу, должны быть более или менее подозрительными, по сравнению с другими пользователями, получающими доступ к тем же самым файлам.
Правила действия.
И наконец, правила действия - это программы, описывающие какие действия должны предприниматься при данном сигнале тревоги. Типичные правила действия показывают, что будет слышен звуковой сигнал, экран терминала будет мигать, чей-то телефон будет звонить, администратору будет отправлена электронная почта и т.д. Общий чертой всех этих примеров является то, что в результате аномалии предпринимается какое-то действие.
Правила действия обычно кодируются в форме длинных условных выражений вида:
if тревога (0) then действие (0)
if тревога (1) then действие (1)
........
if тревога (n-1) then действие (n-1)
Применение рассмотренной модели дало хорошие результаты. Вместе с тем требуют исследований такие вопросы:
- насколько надежно предложенный метод выявляет нарушения безопасности;
- какова доля нарушений безопасности, для которых работает метод;
- выбор инструментов статистической обработки данных и моделей профилей требует обоснования;
- идеология самого быстрого обнаружения еще не ясна.
|
|
|
