СИСТЕМА И СПОСОБ ФОРМИРОВАНИЯ СЦЕНАРИЕВ МОДЕЛИ ПОВЕДЕНИЯ ПРИЛОЖЕНИЙ Российский патент 2014 года по МПК G06F21/56 

Область техники

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

Уровень техники

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

Система, которая использует технологию, базирующуюся на изучении запускаемых исполняемых файлов и оценке поведения на основании системы правил, описана в патенте US7530106 и предназначена для обнаружения вредоносных приложений (исполняемых файлов), используя пороги опасности компьютерных процессов, рассчитанных по системе правил. Сами правила формируются на основании анализа изученных вредоносных приложений. Каждое правило имеет определенную структуру: идентификатор правила, имя вызываемой API-функции (Application Programming Interface, API - набор готовых классов, функций, структур и констант, предоставляемых операционной системой для использования во внешних приложениях), условия для аргументов, оценка опасности. То есть правило сработает в том случае, если процесс вызовет API-функцию с соответствующими параметрами, и в таком случае рейтинг опасности процесса будет увеличен в соответствии с оценкой опасности.

Однако данная система имеет ряд недостатков, связанных с особенностями постоянно совершенствующихся вредоносных приложений. С помощью подобных правил не получится отследить цепочку событий, таких как «загрузка файла» - «сохранение файла на диск» - «прописывание в автозапуск», так как каждое подобное событие может не обладать достаточно высоким рейтингом опасности или не иметь его вовсе. Это, в свою очередь, означает, что неизвестное вредоносное приложение, выполнившее такие действия, не будет своевременно заблокировано. Кроме того, в предложенной системе не ведется учет количества срабатываний определенных правил, отслеживание порядка срабатывания ряда правил и т.д. Также подобная система имеет недостаток, связанный с появлением ошибок первого (false positives) и второго рода (false negatives).

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

Раскрытие изобретения

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

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

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

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

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

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

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

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

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

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

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

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

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

Краткое описание чертежей

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

Фиг.1 иллюстрирует способ формирования сценария модели поведения при выделении проблемных правил.

Фиг.2 иллюстрирует систему, в рамках которой реализовано настоящее изобретение.

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

Описание вариантов осуществления изобретения

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

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

Пример правила:

Правило «Загрузка драйвера через низкоуровневое API ntdll.dll»:

Идентификатор правила: 83

API функция: Загрузка драйвера (NtLoadDriver)

Условие для аргумента 1: *

Условие для аргумента 2: *

Условие для аргументов 3…N: *

Оценка: единичная операция - 4 0%, 2-3 операции - 50%, >3 операций - 60%

На основании данного правила можно признать процесс вредоносным: Нет

Исходя из того, что подобные правила срабатывают независимо друг от друга, в предложенном в данном патенте подходе есть ряд недостатков, связанных с тем, что будет невозможно отследить цепочку связанных событий, не ведется учет количества срабатываний определенных правил, не учитывается порядок срабатывания ряда правил, а кроме того, не исключено появление ошибок первого (false positives) и второго рода (false negatives).

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

Таблица 1 (статистика работы правил при анализе вредоносных и безопасных файловых объектов): Tnn/MD5 ID Статистика Правило #51 Правило #127 Правило #214 Правило #278 Правило #305 Правило #346 Правило #401 Вредоносный MD5 ID1 5 + +   +   +   Вредоносный MD5 ID2 19 +     +   +   Вредоносный MD5 ID3 150 + +       +   Безопасный MD5 ID4 40 + + +         Безопасный MD5 ID5 90 + +     + + + Безопасный MD5 ID6 55 + + +   + + +

В Таблице 1 приведен пример статистики срабатывания правил для шести приложений (указан их тип и МБ5-сумма исполняемого файла). Графа «Статистика» показывает количество компьютеров, на которых зафиксировано присутствие данного образца исполняемого файла. В соответствующих правилам графах стоят отметки о срабатывании правила рейтинга опасности, причем каждый такой столбец может показывать количество срабатываний правила рейтинга опасности при проверке соответствующего исполняемого файла.

Можно увидеть, что ряд правил будет работать как для вредоносных, так и для безопасных приложений. Например, правила 51, 127 и 346 сработают как на некоторых вредоносных, так и на ряде безопасных приложений. Однако ряд правил будет срабатывать только на безопасных приложениях (правила 214, 305, 401), а одно из них - только на вредоносных (правило 278). Следовательно, для устранения возможных ложных срабатываний, связанных с ошибочным определением безопасных приложений как вредоносных, следует уменьшить им рейтинг при срабатывании определенного набора правил - например, при срабатывании правил 51, 127, 214 следует уменьшить рейтинг опасности подобного приложения, так как известно, что оно является безопасным. Аналогично следует поступать и в обратном случае, когда вредоносное приложение выполняет ряд действий, суммарный рейтинг которых не позволит заблокировать приложение как потенциально опасное (например, при одновременном срабатывании правил 51, 127 и несрабатывании любого из правил 214, 305, 401).

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

Пример №1 (автоматически созданный сценарий модели поведения):

Begin

if (RuleStat(51)>0 and

(RuleStat(127)>0) or RuleStat (346)>0) then begin

If (RuleStat(214)>0) then

AddSR(-20);

If (RuleStat(214)>0 and RuleStat(305)>0 and RuleStat(401)>0) then

AddSR(-80);

If (RuleStat(214)=0 and RuleStat(305)=0 and RuleStat(401)=0) then

AddSR (+30);

end;

if (RuleStat(51)>0 and RuleStat(346)>0 then

if (RuleStat(214)=0 and RuleStat(305)=0 and RuleStat(401)=0 then

AddSR(+25);

end.

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

Раскроем более подробно алгоритм формирования сценария, подобного показанному в примере №1. На Фиг.1 приведен способ формирования сценария модели поведения при выделении проблемных правил. На этапе 110 определяется, существуют ли проблемные правила, которые срабатывают одновременно как на вредоносных, так и на безопасных приложениях. В примере №1 подобным правилом может быть, например, правило 51. Далее на этапе 115 также определяется, было ли найденное проблемное правило устранено на прошлой итерации алгоритма или нет. Если для данного правила не удалось создать сценарий модели поведения, то способ переходит на этап 170, который более подробно раскрыт далее в описании. В ином случае, а также при первой итерации устранения проблемного правила на этапе 120 выделяется группа приложений (как вредоносных, так и безопасных), для которых это правило срабатывает. Далее на этапе 130 начинается процесс дифференциации приложений, который заключается в том, что ищется любое другое правило (или правила), которое позволяет выделить из исходной группы приложений только вредоносные либо только безопасные приложения. При этом процесс дифференциации идет по мере усложнения, например, следующим образом:

if (RuleStat(X)>0 and/or RuleStat(Y)>0) then

if (RuleStat(X)>0 and/or RuleStat(Y)>0 and/or RuleStat(Z)>0) then

if (RuleStat(X)>0 and/or RuleStat(Y)>0 and/or RuleStat(Z)>0 and/or RuleStat(K)>0) then

…,

где X, Y, Z, K - номера правил. Таким образом, если не удается выделить группу только вредоносных либо только безопасных приложений с помощью анализа срабатывания хотя бы двух правил, то условие усложняется, добавляя третье правило и т.д. При этом условия могут иметь характер как логических «И» («AND»), так и «ИЛИ» («OR»). Процесс дифференциации может идти до тех пор, пока не будут перебраны все правила и имеющиеся логические условия. В ходе процесса дифференциации может также автоматически формироваться порог, например условие может выглядеть как RuleStat(Y)>3, что позволяет учитывать не только факт срабатывания правила Y, но и количество срабатываний.

После того как условия дифференциации были выделены на этапе 130, на этапе 140 происходит учет статистики срабатывания. Логика вычисления рейтинга основана на простом условии - требуется избежать ложных срабатываний на безопасных приложениях, а также добиться обнаружения вредоносных приложений. Например, если вредоносное приложение набирает с помощью системы правил рейтинг опасности всего 57% с условием, что порог вредоносности равен 80%, то функция добавления рейтинга должна будет добавить как минимум 24% (т.е. будет выглядеть как AddSR(+24)). Аналогично происходит и с безопасными приложениями - если, например, безопасное приложение набирает 91% рейтинга опасности, то его следует снизить как минимум на 11%. В зависимости от статистики срабатывания правил подобные значения могут увеличиваться или уменьшаться. Статистика также влияет на пороги, по которым определяется вредоносность приложения. Например, если статистика показывает, что большое количество безопасных приложений ошибочно обнаруживаются как вредоносные из-за низкого порога, то данный порог может быть увеличен при условии, что это не повлияет на качество обнаружения уже известных вредоносных приложений.

После учета статистики срабатывания, на этапе 150, формируется сценарий модели поведения, аналогичный тому, что приведен в примере №1. После этого происходит возврат к этапу 110, на котором происходит определение других проблемных правил. Следует также отметить, что по мере того, как для проблемных правил составляются сценарии модели поведения, из анализа исключаются те приложения, которые были однозначно идентифицированы (т.е. для вредоносных приложений уже был добавлен повышающий рейтинг опасности, а для безопасных - понижающий рейтинг) ранее созданными сценариями модели поведения. Подобным образом происходит проверка на этапе 120 по определению как безопасных, так и вредоносных приложений, на которых срабатывает проблемное правило.

Стоит отметить, что не во всех случаях для проблемных правил возможно автоматически создать сценарий модели поведения. На Фиг.1 это отражено в виде этапа 170, на котором происходит выделение дополнительных признаков, когда не удается устранить проблемное правило с помощью создания сценария модели поведения на этапе 115. Рассмотрим ряд примеров, которые иллюстрируют необходимость добавления дополнительных признаков в сценарий модели поведения.

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

Пример №2 (пример сценария модели поведения с выявленной характерной особенностью поведения):

Begin

if (RuleStat(51)>0 and RuleStat(127)>0 and RuleStat(278)>0) then

if IMUL_ FileCreated(`c:file:///Program file://Files/GoodEXE/settings.ini')

then

AddSR(-100);

end.

В данном примере IMUL_FileCreated - функция, которая выполняет проверку выполненных операций, исполняемых приложением при эмуляции. Создание файла с именем «settings.ini» в каталоге Files\GoodEXE\ позволяет распознать поведение приложения в качестве легитимного и снизить рейтинг опасности до нуля.

Ниже рассмотрен еще один пример.

Таблица 2 (статистика работы правил при анализе вредоносных и безопасных файловых объектов): THn/MD5 ID Статистика Правило # 51 Правило #127 Правило #214 Правило #278 Вредоносный MD5 ID1 5 + +   + Вредоносный MD5 ID2 19 + +   + Вредоносный MD5 ID3 150 + +   + Безопасный MD5 ID4 140 + +   + Безопасный MD5 ID5 90 + +   + Безопасный MD5 ID6 55 + +   +

Как несложно заметить, в данном случае на вредоносных и на безопасных приложениях работают одинаковые правила, и создать сценарий модели поведения, позволяющий их разделить по совокупному поведению (т.е. по ряду правил), не получится. С этой целью можно проверить ряд дополнительных признаков (событий), которые происходят при выполнении либо вредоносного, либо безопасного приложения. Примеры подобных признаков: создание файла; скачивание файла; запись в файл; обнаружение вредоносного поведения; сетевой обмен данными. Допустим, безопасные приложения, приведенные в таблице 2, создают на диске файл «install_log.txt», в то время как вредоносные приложения этого не делают. В этом случае сценарий модели поведения будет дописан следующим образом:

Begin

if (RuleStat(51)>0 and RuleStat(127)>0 and RuleStat(278)>0) then

if IMUL_FileCreated (`nstall_log.txt') then

AddSR(-100);

end.

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

Thit/MD5 ID Статистика Правило # 51 Правило #127 Правило #214 Правило #278 Вредоносный MD5 ID1 5 7 7   6 Вредоносный MD5 ID2 19 9 7   7 Вредоносный MD5 ID3 150 8 3   7 Безопасный MD5 ID4 140 2 5   6 Безопасный MD5 ID5 90 1 7   7 Безопасный MD5 ID6 55 3 3   6

Цифры в столбцах правил показывают количество срабатывания правила в ходе анализа образца. Как несложно заметить, статистика правил 127 и 278 не отличается у безопасных и вредоносных приложений, тогда как для правила 51 видна ярко выраженная закономерность - на вредоносных приложениях правило срабатывает 7-9 раз, на безопасных - 1-3 раза. В таком случае может быть автоматически сгенерирован следующий сценарий:

Begin

if (RuleStat(51)>=7 and RuleStat(127)>0 and RuleStat(278)>0) then

AddSR(-100);

end.

В одном из вариантов реализации события, которые были зарегистрированы в эмуляторе (или во время исполнения в реальной компьютерной системе), могут быть описаны в виде дополнительного правила, например:

Тип/М05 ID Статистика Правило #51 Правило #127 Правило #214 Правило #278 Правило #2102 Вредоносный MD5 ID1 5 + +   +   Вредоносный MD5 ID2 19 + +   +   Вредоносный MD5 ID3 150 + +   +   Безопасный MD5 ID4 140 + +   + + Безопасный MD5 ID5 90 + +   + + Безопасный MD5 ID6 55 + +   + +

Можно видеть, что было введено еще одно правило - правило №2102, которое регистрирует создание файла «install_log.txt» и понижает рейтинг опасности при его создании, что позволяет избежать ложных срабатываний.

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

Пример использования уточняющих признаков:

begin

if copy(ExtractFilePath(APIArg[1]), 2, 100)=':\' then begin

AddSR(20);

if (ExtractFileExt(APIArg[1])='.exe' then AddSR(40);

if (ExtractFileExt(APIArg[1])='.com' then AddSR(50);

if (ExtractFileExt(APIArg[1])='.pif then AddSR(60);

end;

end

В данном случае уточняющий признак - операция создания файла. Делается проверка того, что файл создается в корне диска, и за это начисляется 20 единиц рейтинга опасности. Далее делается уточнение - в зависимости от расширения файла производится начисление дополнительного рейтинга. Функция APIArg позволяет сценарию обращаться к аргументам оцениваемого вызова (в данном случае - операции создания файла), AddSR позволяет добавить к рейтингу опасности определенное значение.

Фиг.2 иллюстрирует систему, в рамках которой реализовано настоящее изобретение. Генератор сценариев модели поведения 230 использует базу данных безопасных приложений 240 и базу данных вредоносных приложений 250 с целью выделения проблемных правил из базы данных правил рейтинга опасности 280 и создания сценариев модели поведения, как это описано на Фиг.1. В том случае если проблемное правило невозможно устранить без использования уточняющих признаков, генератор сценариев модели поведения 230 подключает генератор правил с уточняющими признаками 260, который использует базу данных уточняющих признаков 270. В рамках одного из вариантов реализации генератор правил с уточняющими признаками 260 не только дополняет сценарий модели поведения, но также формирует новое правило рейтинга опасности в базе данных правил рейтинга опасности 280. Данное правило вместе с созданными сценариями модели поведения передается на сторону антивирусного приложения 210, которое установлено на компьютере пользователя 200. При работе сценариев модели поведения формируется обратная связь, например вручную, если пользователь обнаруживает ложное срабатывание при работе сценариев модели поведения, или автоматически, если один из сценариев модели поведения выдает ошибочную информацию при обнаружении известных вредоносных или безопасных приложений (подобный случай возможен, когда после создания сценария модели поведения проходит некоторое время, за которое успевают обновиться базы данных безопасных приложений 240 и вредоносных приложений 250). Обратная связь учитывается с помощью анализатора обратной связи 220, который регистрирует все случаи ложных срабатываний (т.е. ошибок как первого, так и второго рода) и передает эту информацию на генератор сценариев модели поведения 230. Пример исправления ложных срабатываний приведен в патенте US7640589. В ряде случаев может привлекаться человек-эксперт для внесения изменения в создаваемые сценарии модели поведения.

Фиг.3 представляет пример компьютерной системы общего назначения, персональный компьютер или сервер 20, содержащий центральный процессор 21, системную память 22 и системную шину 23, которая содержит разные системные компоненты, в том числе память, связанную с центральным процессором 21. Системная шина 23 реализована, как любая известная из уровня техники шинная структура, содержащая, в свою очередь, память шины или контроллер памяти шины, периферийную шину и локальную шину, которая способна взаимодействовать с любой другой шинной архитектурой. Системная память содержит постоянное запоминающее устройство (ПЗУ) 24, память с произвольным доступом (ОЗУ) 25. Основная система ввода/вывода (BIOS) содержит основные процедуры, которые обеспечивают передачу информации между элементами персонального компьютера 20, например, в момент загрузки операционной системы с использованием ПЗУ 24.

Персональный компьютер 20, в свою очередь, содержит жесткий диск 27 для чтения и записи данных, привод магнитных дисков 28 для чтения и записи на сменные магнитные диски 29 и оптический привод 30 для чтения и записи на сменные оптические диски 31, такие как CD-ROM, DVD-ROM и иные оптические носители информации. Жесткий диск 27, привод магнитных дисков 28, оптический привод 30 соединены с системной шиной 23 через интерфейс жесткого диска 32, интерфейс привода магнитных дисков 33 и интерфейс оптического привода 34 соответственно. Приводы и соответствующие компьютерные носители информации представляют собой энергонезависимые средства хранения компьютерных инструкций, структур данных, программных модулей и прочих данных персонального компьютера 20.

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

Компьютер 20 имеет файловую систему 36, где хранится записанная операционная система 35 и дополнительные программные приложения 37, другие программные модули 38 и программные данные 39. Пользователь имеет возможность вводить команды и информацию в персональный компьютер 20 посредством устройств ввода (клавиатуры 40, манипулятора «мышь» 42). Могут использоваться другие устройства ввода (не отображены): микрофон, джойстик, игровая консоль, сканнер и т.п. Подобные устройства ввода по своему обычаю подключают к компьютерной системе 20 через последовательный порт 46, который, в свою очередь, подсоединен к системной шине, но могут быть подключены иным способом, например при помощи параллельного порта, игрового порта или универсальной последовательной шины (USB). Монитор 47 или иной тип устройства отображения также подсоединен к системной шине 23 через интерфейс, такой как видеоадаптер 48. В дополнение к монитору 47, персональный компьютер может быть оснащен другими периферийными устройствами вывода (не отображены), например колонки, принтер и т.п.

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

Сетевые соединения могут образовывать локальную вычислительную сеть (LAN) 51 и глобальную вычислительную сеть (WAN) 52. Такие сети применяются в корпоративных компьютерных сетях, внутренних сетях компаний и, как правило, имеют доступ к сети Интернет. В LAN- или WAN-сетях персональный компьютер 20 подключен к локальной сети 51 через сетевой адаптер или сетевой интерфейс 53. При использовании сетей персональный компьютер 20 может использовать модем 54 или иные средства обеспечения связи с глобальной вычислительной сетью 52, такой как Интернет. Модем 54, который является внутренним или внешним устройством, подключен к системной шине 23 посредством последовательного порта 46. Следует уточнить, что сетевые соединения являются лишь примерными, и не обязаны отображать точную конфигурацию сети, т.е. в действительности существуют иные способы установления соединения техническими средствами связи одного компьютера с другим.

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

Изобретение относится к области систем обнаружения вредоносного программного обеспечения. Техническим результатом является создание сценариев модели поведения на основании правил рейтинга опасности. Cпособ создания сценариев модели поведения на основе правил рейтинга безопасности состоит из этапов, на которых: определяют проблемные правила, которые срабатывают одновременно как на вредоносных, так и на безопасных приложениях; для проблемного правила выделяют группу приложений, для которых это правило срабатывает; находят, по крайней мере, одно отличное от проблемного правило, срабатывание которого вместе со срабатыванием проблемного правила позволяет выделить из выделенной группы приложений только вредоносные либо только безопасные приложения; формируют сценарий модели поведения на основе проблемного правила и, по крайней мере, одного найденного правила, отличного от проблемного правила, срабатывание которого вместе со срабатыванием проблемного правила позволяет выделить из выделенной группы приложений только вредоносные либо только безопасные приложения, при этом сценарий модели поведения используется для корректировки рейтинга опасности выделенной группы приложений. 2 н. и 9 з.п. ф-лы, 3 ил., 4 табл.

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

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

3. Способ по п.2, в котором уточняющие признаки включают частоту срабатывания правил.

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

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

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

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

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

9. Система по п.8, в котором уточняющие признаки включают частоту срабатывания правил.

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

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