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

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

Иллюстрации

Показать все

Реферат

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

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

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

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

В настоящее время эмулятор также может содержать в себе аналитический модуль, который собирает информацию об анализируемом объекте, проводит исследования, на их основе делает вывод о вредоносности того или иного объекта и формирует правила обнаружения. Как правило, эмулятор с аналитическим модулем проводит глубокий анализ, используя правила для обнаружения неизвестных угроз, которые были созданы в антивирусных лабораториях. Также эмулятор во время исследования приложений может использовать различные рейтинги (например, рейтинг опасности, описанный в патенте на полезную модель RU 101233). Следует отметить, что во время эмуляции приложений для последующего анализа/исследования формируется протокол произошедших событий, который содержит в себе как обычные (типичные) события безопасных (известных) программ, так и подозрительные события остальных программ (неизвестных или вредоносных). На основе анализа данного протокола событий, во время которого и используются правила обнаружения произошедших событий и расчета рейтинга, выносится окончательный вердикт о вредоносности исследуемого приложения.

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

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

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

Однако вышеперечисленные изобретения не решают одну из основных проблем при анализе протоколов - большие временные затраты, т.к. созданные протоколы событий во время эмуляции достигают огромных размеров, которые могут доходить до миллиона строк. Еще одним недостатком является то, что при анализе таких протоколов малораспространенные значимые события сложно выявить среди большого числа малозначимых (незначительных) событий. Малозначимым событием является такое событие, которое с точки зрения анализа опасности поведения (совершенного действия) не имеет большого значения, т.к. данное событие может происходить как во время выполнения безопасного ПО, так и во время выполнения вредоносного ПО. Следовательно, с помощью малозначимых событий нельзя точно определить, является ли ПО вредоносным или нет. Типичным примером малозначимых событий при выполнении какого-либо программного обеспечения, написанного на языке программирования Delphi, могут быть события, которые произошли от выполнения дополнительного кода, добавленного при компиляции данного ПО, например «startup кода».

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

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

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

Сущность изобретения

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

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

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

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

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

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

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

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

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

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

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

- передачи сформированных правил фильтрации малозначимых событий в базу правил фильтрации малозначимых событий;

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

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

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

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

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

В частном варианте исполнения системы в качестве события из сформированного протокола событий является малозначимое событие.

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

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

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

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

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

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

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

В частном варианте исполнения системы анализируемое событие является малозначимым событием, если указанное событие отсутствует в упомянутых списках событий а) и б).

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

а) получают данные, по крайней мере, из одной информационной базы,

б) формируют программу - образец на основе полученных данных,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Краткое описание прилагаемых чертежей

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

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

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

Фиг.2 иллюстрирует пример схемы работы анализатора при формировании правил фильтрации малозначимых событий.

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

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

Фиг.5 показывает границы разделения событий при анализе протоколов событий.

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

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

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

Одним из вариантов реализации данного изобретения является система создания правил фильтрации малозначимых событий (МС), представленная на Фиг.1А, Фиг.1Б и Фиг.1В. Представленная система является дополнительным компонентом для систем фильтрации при формировании и/или анализе протоколов событий, созданных во время эмуляции программного обеспечения (ПО, приложения). Эмулятор ПО, как правило, является частью антивирусного средства, которое во время проверки ПО проводит поиск неизвестных вредоносных объектов на ПК пользователя. В качестве объекта можно рассмотреть исполняемый файл, например, [имя].ехе, который перед запуском проверяется эмулятором приложений.

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

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

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

Примерами малозначимых событий являются:

1) вызов «GetVersion()» - запрос версии операционной системы. Любое приложение, написанное на языке программирования Delphi 7, будет совершать данный запрос, а такой запрос не говорит о том, вредоносное приложение или нет;

2) вызов «RegOpenKeyEx(0×80000001,"Software\Borland\Locales*^,„,);» - данное действие также будет совершаться при исполнении любого приложения, написанного на Delphi 7, и также по нему нельзя определить, какое это приложение;

3) вызов «GetModuleHandle("USER32.DLL");» - данное действие присуще 80% всех исполняемых файлов, следовательно, это действие будет совершено как при выполнении безопасных приложений, так и вредоносных.

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

На Фиг.1А изображена структурная схема системы создания правил фильтрации малозначимых событий. В одном из вариантов реализации система создания правил фильтрации МС 100 взаимодействует с антивирусным сервером 101. Примером антивирусного сервера 101 может являться сервер, предоставляющий сервис Kaspersky Security Network. Антивирусный сервер 101 содержит различную информацию о ПО, которая разрабатывается компаниями-разработчиками, например Microsoft, а затем работает на ПК пользователей 180А, …, 180N. Вся информация о различных программах хранится в соответствующих информационных базах 110A, …, 110N. Информационные базы 110А, 110N могут находиться как отдельно (в антивирусном сервере 101) от других средств системы 100, так и совместно с ними. В качестве информации, которая содержится в информационных базах 110А, 110N, может быть как само приложение (файл), так и любая информация о приложениях, например метаданные приложения, части программного кода, хеш-сумма приложения и т.д. формационные базы 110А, …, 110N формируются по типам приложений, например, база компиляторов 110А, база упаковщиков 110Б (приложения для сжатия исполняемого файла), база протекторов/крипторов 110В (приложения для сжатия и шифрования исполняемого файла) и т.д.

Система создания правил фильтрации МС 100 запрашивает из баз 110А, 110N информацию о содержащихся в них компиляторах, упаковщиках, протекторах и других программах. Базы 110А, …, 110N направляют запрашиваемую информацию средству создания программы-образца 120. Как было написано выше, в качестве информации, например, будет передаваться либо исполняемый файл компилятора, упаковщика, протектора и т.д., либо путь к исполняемому файлу. Средство создания программы-образца 120 использует, например, полученный компилятор для формирования программы-образца 125, которую направляет средству отслеживания выполнения ПО (далее - эмулятор) 130.

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

Begin

End.

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

unit Unitl;

interface

uses

Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, DB, OracleData, Oracle, StdCtrls, urlmon, ExtCtrls, Spin,

IdBaseComponent, IdComponent, IdTCPConnection, IdTCP Client, IdHTTP, IdMultipartFormData, AbUnZper, AbUtils, AbArcTyp, INIFiles, RxVerlnf, IdUDPBase, IdUDPClient, IdDNSResolver, ComObj, Math; type

TMain=class(TForm)

end;

var

Main: TMain;

implementation

begin

end.

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

Эмулятор 130 проводит эмуляцию полученной программы-образца 125, во время которой регистрирует все происходящие события в протоколе событий 135. Эмуляция программы-образца 125 означает разбор его программного кода на инструкции и имитацию их исполнения. Затем эмулятор 130 передает сформированный протокол событий 135 в анализатор 140.

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

Анализатор 140 на основе каждого события из полученного протокола событий 135 создает правило фильтрации малозначимых событий. Правило фильтрации является булевым признаком и содержит имя API - функции и маски для ее аргументов (количество аргументов от 1 до N). Каждый аргумент маски может принимать значения:

- NULL - - говорит о том, что аргумент функции должен быть пустым,

- * - любое значение аргумента,

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

Примером такой API - функции (правила фильтрации малозначимого события) является функция SysAllocString с тремя аргументами (*,-NULL-,-NULL-), где первый аргумент любой, а остальные - отсутствуют.

Анализатор 140 на основе созданных правил фильтрации малозначимых событий формирует пакет правил 145, которые затем передает в базу правил фильтрации МС 160.

База правил фильтрации МС 160 добавляет полученный пакет правил 145 в таблицу 1 правил фильтрации малозначимых событий для последующего хранения. После добавления пакета правил 145 в базу 160 версия указанной базы изменяется и передается средству обновления 165. Примером таблицы правил фильтрации малозначимых событий является таблица 1 следующего вида:

Таблица 1
Apl_FUNCT	ARG1	ARG2	…	ARGN
Colnitialize	-NULL-	-NULL-	…	-NULL-
CoCreatelnstance	-NULL-	-NULL-	…	*
GetStringType	-IMULL-	-NULL-	…	””,,
SysAllocString	*	-NULL-	…	-NULL-
WideCharToMultiByte	-NULL-	-NULL-	…	*
LCMapString	-NULL-	-NULL-	…	””,””,
GetModuleFileName	-NULL-	-NULL-	…	-NULL-
GetFileType	*	-NULL-	…	-NULL-
LoadLibrary	shell32.dll	-NULL-	…	-NULL-
LoadLibrary	kernel32.dll	-NULL-	…	-NULL-
LoadLibrary	ole32.dll	-NULL-	…	-NULL-
RegSetValueEx	\Registry\Machine\Software\Classes\.key	-NULL-	…	,,”regfile”,
RegOpenKeyEx	0×80000000	.key	…	,,
RegSetValue	0×80000000	.key	…	,””,
CreateDirectory	file://C:/DOCUME~l/ADMINI~l/LOCALS~l/Temp/~~~	-NULL-	…	-NULL-
…	…	…	…	…

В представленной таблице 1 первый столбец (API_FUNCT) содержит имена API - функций, а последующие столбцы (ARG1, ARG2, … , ARGN) содержат аргументы функций.

Также стоит отметить, что система создания правил фильтрации МС 100 предоставит правила фильтрации МС из базы правил фильтрации 160 антивирусным средствам, находящимся на ПК пользователей 180А, 180N, в случае получения запроса от данных антивирусных средств. При этом все взаимодействия между системой создания правил фильтрации МС 100 и ПК пользователей 180А, 180N проходят через сеть Интернет 170.

В частном случае реализации взаимодействие базы правил фильтрации МС 160 и ПК пользователей 180А, …, 180N происходит через средство обновления 165. В этом случае средство обновления 165 содержит актуальную версию базы 160. Тогда при получении запроса от антивирусных средств, находящихся на ПК пользователей 180А, 180N или других устройствах, средство обновления 165 сверит полученную версию базы со своей версией базы 160. В том случае если версии совпадут, то антивирусные средства на ПК пользователей 180А, …, 180N уже содержат актуальную базу правил фильтрации НС. В том случае если версии различны, то будет сформирован пакет правил фильтрации малозначимых событий 175. Пакет 175 будет содержать все правила фильтрации, созданные после представленной версии базы правил от ПК пользователей 180А, 180N. Затем данный пакет 175 будет направлен соответствующим антивирусным средствам на ПК пользователей 180А, … ,180N.

На Фиг.1Б изображен еще один пример реализации системы создания правил фильтрации малозначимых событий. В данном примере реализации система создания правил фильтрации 100 содержит в себе только анализатор 140, базу правил фильтрации МС 160 и средство обновления 165 и взаимодействует с антивирусным сервером 101. В данной реализации антивирусный сервер 101 содержит две базы данных 150А и 150Б. База данных 150А содержит протоколы событий BL 152, которые были сформированы при эмуляции только вредоносных приложений. База данных 150Б содержит протоколы событий WL 154, которые были сформированы только при эмуляции безопасных приложений.

Анализатор 140 запрашивает у баз 150А и 150Б все протоколы событий BL 152 и WL 154, которые находятся в указанных базах на момент запроса. Далее анализатор 140 проводит анализ всех полученных протоколов событий 152 и 154, по окончании которого формирует список малозначимых событий 270 (более подробно работа анализатора 140 будет рассмотрена на Фиг.2). Список малозначимых событий 270 содержит события, встретившиеся как в протоколах событий BL 152, так и в протоколах событий WL 154. Все события, попавшие в указанный список 270, являются малозначимыми событиями.

Далее анализатор 140 на основе каждого события из сформированного списка малозначимых событий 270 создает правило фильтрации НС. Затем все созданные правила фильтрации МС передаются в базу правил фильтрации МС 160 в виде пакета правил 145. База правил фильтрации МС 160 полученный пакет правил 145 добавляет в таблицу правил фильтрации малозначимых событий для последующего хранения и передачи ПК пользователям 180, в случае получения от них запроса. Все взаимодействия между системой создания правил фильтрации МС 100 и ПК пользователей 180 происходят через средство обновления 165, которое в свою очередь взаимодействует с ПК пользователей 180 через сеть Интернет 170.

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

Представленный на Фиг.1 В вариант реализации системы создания правил фильтрации МС объединяет в себе подходы, представленные на Фиг.1А и Фиг.1Б. Также в данной реализации анализатор 140 проводит проверку каждого события из полученного протокола событий 135 от эмулятора 130 на их соответствие критерию малозначимого события. Проверка будет происходить с помощью списка безопасных событий 260 и списка вредоносных событий 250 (Фиг.2). Указанные списки будут формироваться анализатором 140 во время анализа протоколов событий 152 и 154 из баз 150А и 150Б совместно со списком событий 270, как описано на Фиг.1Б.

Далее анализатор 140 будет сравнивать каждое событие из протокола событий 135 со сформированными списками событий 250 и 260.

В том случае, если событие из полученного от эмулятора 130 протокола событий 135 было найдено в списках событий 250 и 260, то данное событие не является малозначимым событием и будет удалено.

В том случае если событие из полученного от эмулятора 130 протокола событий 135 не было найдено в списках событий 250 и 260, то данное событие является малозначимым событием, и анализатор 140 формирует правило фильтрации на основе данного события. После формирования правил на основе событий, которые прошли верификацию, анализатор 140 формирует пакет правил 145, который передает в базу правил фильтрации МС 160.

Фиг.2 иллюстрирует пример схемы работы анализатора 140 при формировании правил фильтрации малозначимых событий. В одном из вариантов реализации анализатор 140 состоит из модуля анализа протоколов событий 210 (далее - модуль 210), модуля анализа протоколов событий и формирования списков событий 230 (далее - модуль 230) и модуля формирования правил фильтрации малозначимых событий 290 (далее - модуль 290).

Модуль 210 предназначен для анализа протокола событий 135, получаемого от эмулятора (средства отслеживания исполнения ПО) 130 и предоставления всех малозначимых событий модулю 290 в виде списка малозначимых событий 280. Также модуль 210 проводит предварительную верификацию (как описано при рассмотрении Фиг.1 В) всех событий из протокола 135 с помощью списка вредоносных событий 250 и списка безопасных событий 260, полученных от модуля 230.

Модуль 230 предназначен для анализа протоколов событий BL 152 и протоколов событий WL 154, полученных от баз 150А и 150Б, хранящихся на антивирусном сервере 101. На основе проведенного анализа модуль 230 формирует три списка событий: список вредоносных событий 250, список безопасных событий 260 и список малозначимых событий 270. Затем модуль 230 предоставляет списки 250 и 260 модулю 210, а список 270 - модулю 290.

Модуль 290 предназначен для:

- формирования правил фильтрации малозначимых событий (МС) на основе полученных списков малозначимых событий 270 и 280 от модулей 210 и 230 (как описано при рассмотрении Фиг.1А),

- формирования пакета правил 145 из сформированных правил фильтрации МС и

- последующей передачи сформированного пакета правил 145 в базу правил фильтрации МС 160.

В частном случае реализации модуль 290 проверяет сформированные правила фильтрации МС на их наличие в базе правил фильтрации МС 160. В том случае, если сформированные правила фильтрации МС будут найдены в базе 160, то правила не будут добавлены в базу 160, а будут удалены.

Стоит более подробно остановиться на границе отбора малозначимых событий при анализе событий из протоколов событий 152 и 154, который поясняется с помощью Фиг.5. Сначала будут выделены все события, которые были обнаружены в обоих протоколах (152 и 154). Затем будет проанализировано каждое событие, при этом совокупность протоколов, в которых было обнаружено анализируемое событие, будет составлять 100% протоколов.

Далее возможны три ситуации:

1. Отношение обнаружения события составило 30%/70% и менее в сторону протоколов событий WL 152, т.е. данное событие было обнаружено в протоколах событий WL 152 от 0% до 30% и от 70% до 100% в протоколах событий BL 154. В этом случае событие является подозрительным событием и будет добавлено в список вредоносных событий 250.

2. Отношение обнаружения события составило 30%/70% и более в сторону протоколов событий WL 152, но не более 70%, т.е. данное событие было обнаружено в протоколах событий WL 152 от 30% до 70% и от 70% до 30% в протоколах событий BL 154. В этом случае событие является малозначимым событием и будет добавлено в список малозначимых событий 270.

3. Отношение обнаружения события составило 70%/30% и более в сторону протоколов событий WL 152, т.е. данное событие было обнаружено в протоколах событий WL 152 от 70% до 100% и от 30% до 0% в протоколах событий BL 154. В этом случае событие является доверенным (потенциально безопасным) событием и будет добавлено в список безопасных событий 260.

Также стоит отметить, что наиболее точный результат при формировании списков событий 250, 260 и 270 достигается при анализе нескольких сотен протоколов событий и более.

На Фиг.3 изображена блок схема для способа, с помощью которого можно реализовать систему создания правил фильтрации малозначимых событий. Для создания правил фильтрации МС на этапе 310 система создания правил фильтрации МС 100 отправляет запрос о наличии новых данных к базам из списка баз 110А, 110N. Запрос может быть передан как ко всем базам 110А, 110N сразу, так и поочередно. После получения запроса базы 110А, 110N передают системе создания правил фильтрации МС 100, а именно средству создания программы-образца 120 все хранящиеся у них данные (информацию) об объектах (компиляторах, протекторах, упаковщиках и т.д.). В качестве данных (информации), которые содержатся в базах 110, может быть как само приложение (файл), так и любые данные (информация) о них, например метаданные приложения, части программного кода, хеш-сумма приложения и т.д. На этапе 315 средство создания программы-образца 120 проверяет полученные данные на их новизну.

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