Software & Systems

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

Вместо статического анализа кода программы предлагается отслеживать динамику ее работы и создавать статистический портрет программы (СПП), выявляя некорректность выполнения программы. Достоинство такого способа – обнаружение вредоносного поведения прежде, чем оно окажет на систему какое-либо губительное воздействие, а также устранение этого воздействия (см.: В.В. Макаров, С.А. Носков. Прототип монитора безопасности для исследования новых принципов защиты систем. // Третья междунар. конф. по проблемам управления. М. 2006).

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

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

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

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

Получение СПП на основе анализа системных вызовов

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

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

Использование данных журнала. Вначале предлагается разбить все системные функции ОС на группы. Внутри каждой группы эти функции связаны по назначению. Например, функции создания и прекращения работы процессов объединяются в одну группу (fork, wait, exit).

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

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

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

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

Виды СПП

Предлагаются два способа представления СПП: временной и темповый ряды.

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

После получения данных журнала строим график на плоскости в рамках правой декартовой системы координат OXY, назовем его временным рядом (см.: Ю.Н. Тюрин, А.А. Макаров. Анализ данных на компьютере. М. 2003). По оси OX откладываем время с выбранным интервалом (масштабом), а по оси OY – номера вызываемых системных функций ОС.

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

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

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

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

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

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

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

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

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

Строим темповый ряд как пространственный график на базе правой декартовой системы координат ОXYZ. Для этого по оси OX откладываем время в соответствии с выбранным большим интервалом времени (масштабом), по оси OY – номера вызываемых системных функций; нулевую ординату исключим из нумерации функций, пусть она соответствует итоговым данным для всех функций.

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

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

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

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

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

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

Достоинства темпового ряда: простота генерации, большая сжатость информации по сравнению с временным рядом, демонстрация темпа поступления вызовов.

Недостатки темпового ряда: потеря зависимости между отдельными вызовами, уменьшение возможности выделения переходного этапа.

ОС как объект

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

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

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

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

ОС как объект управления

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

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

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