СИСТЕМА И СПОСОБ СОЗДАНИЯ ПРАВИЛ ФИЛЬТРАЦИИ НЕЗНАЧИТЕЛЬНЫХ СОБЫТИЙ ДЛЯ АНАЛИЗА ПРОТОКОЛОВ СОБЫТИЙ
SYSTEM AND METHOD OF CREATING RULES FOR FILTERING INSIGNIFICANT EVENTS FOR EVENT LOG ANALYSIS

Область техники
Данное изобретение относится к системам анализа протоколов событий при эмуляции приложений и, более конкретно, к системам предварительной фильтрации малозначимых событий с целью уменьшения ложных срабатываний при выявлении вредоносных объектов во время эмуляции и при формировании правил поведения.
Уровень техники
В настоящее время распространение вредоносного программного обеспечения (далее - ПО) увеличивается с каждым днем, а также увеличивается и вред, который данное ПО наносит персональным компьютерам (далее - ПК) пользователей. Существующие методы защиты персональных компьютеров, а также компьютеров в корпоративной сети, предназначены как для обнаружения уже известных угроз, так для обнаружения неизвестных угроз. Методы защиты от известных угроз (компьютерных вирусов), как правило, основаны на сигнатурном сканировании, которое использует шаблоны кода, полученные из известных вредоносных программ для последующей проверки объектов. Также методами защиты от известных вирусов являются: технология "белых списков", использующая шаблоны уже известных доверенных программ, технология "черных списков", системы проверки контрольных сумм, метаданных и т.д. Однако скорость появления нового вредоносного ПО в последнее время постоянно растет, что требует постоянного увеличения роли проактивной защиты для осуществления оперативной защиты пользователя. Проактивные методы, чаще всего используемые для этой цели, как правило, имеют в своем составе эмулятор кода. Эмулятор разбирает байтовый код программы на команды и каждую команду запускает в виртуальной копии компьютера. Это позволяет средству защиты наблюдать за поведением программы, не ставя под угрозу операционную систему ПК и данные пользователя.
В настоящее время эмулятор также может содержать в себе аналитический модуль, который собирает информацию об анализируемом объекте, проводит исследования, на их основе делает вывод о вредоносности того или иного объекта и формирует правила обнаружения. Как правило, эмулятор с аналитическим модулем проводит глубокий анализ, используя правила для обнаружения неизвестных угроз, которые были созданы в антивирусных лабораториях. Также эмулятор во время исследования приложений может использовать различные рейтинги (например, рейтинг опасности, описанный в патенте на полезную модель 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 удалит все данные, на основе которых была сформирована хеш-сумма. В том случае, если сформированная хеш-сумма не будет найдена в списке хеш-сумм, то сформированная хеш-сумма является новой и будет добавлена в указанный список хеш-сумм, а данные, на основе которых была сформирована хеш-сумма, будут переданы на этап 320.
На этапе 320 формируется программа-образец 125 на основе полученных данных с помощью средства 120. На этапе 325 средство 120 передает программу-образец 125 средству отслеживания выполнения ПО (далее - эмулятору) 130 для последующего анализа. После этого запускается эмулятор 130, и на этапе 330 проводится эмуляция (исполнение) программы-образца 125. Во время эмуляции формируется протокол событий 135, куда эмулятор 130 записывает все совершенные действия (случившиеся события) программы-образца 125. На этапе 335 сформированный протокол событий 135 передается анализатору 140, который проводит его проверку с целью выявления малозначимых событий. Проверка проводится с помощью сравнения событий из протокола событий с событиями из списков 250 и 260. В том случае, если события не будут найдены в указанных списках 250 и 260, то данные события являются малозначимыми событиями и будут добавлены в список 280, который после окончания проверки будет передан на этап 345. В том случае, если события будут найдены в указанных списках 250 и 260, то данные события будут удалены, т.к. не будут являться малозначимыми событиями.
На этапе 345 анализатор 140 формирует правила фильтрации на основе событий из полученного списка 280. Формирование правил фильтрации малозначимых событий происходит согласно описанию Фиг.1А. На этапе 350 сформированные правила добавляются в базу правил фильтрации  МС 160 для последующего хранения, предварительно сформированные в виде пакета правил 145. На этапе 355 принимается решение о продолжении формирования правил фильтрации малозначимых событий или об окончание работы. В том случае если все полученные данные из информационных баз 110А, 110Б, 110В, … , HON были проанализированы, то работа будет окончена. В том случае если не все данные из баз 110А, 110Б, 110В, … , 110N были проанализированы, то система 100 вернется к этапу 310.
На Фиг.4 изображен алгоритм создания правил фильтрации малозначимых событий.
На этапе 415 анализатор 140 получает, по крайней мере, один протокол событий BL 152 из базы 150А и, по крайней мере, один протокол событий WL 154 из базы 150Б. На этапе 430 анализатор 140 проводит сравнение всех полученных протоколов событий и выявляет события, которые встретились как в протоколах BL 152, так и протоколах WL 154. На следующем этапе 445 анализатор 140 формирует список событий из событий, которые находились в обоих типах протоколов. На основе данного списка событий анализатор 140 на этапе 460 создает правила фильтрации НС. После чего из созданных правил фильтрации  МС формирует пакет правил 145, который передает базе правила фильтрации  МС 160. На этапе 475 база 160 добавит правила фильтрации  МС из полученного пакета правил 145 в таблицу правил фильтрации малозначимых событий для последующего хранения.
На Фиг.6 показана компьютерная система, для которой может быть использовано описанное изобретение.
Фиг.6 представляет пример компьютерной системы общего назначения (может быть как персональным компьютер, так и сервером) 20, содержащий центральный процессор 21, системную память 22 и системную шину 23, которая содержит разные системные компоненты, в том числе память, связанную с центральным процессором 21. Системная шина 23 реализована как любая известная из уровня техники шинная структура, содержащая в свою очередь память шины или контроллер памяти шины, периферийную шину и локальную шину, которая способна взаимодействовать с любой другой шинной архитектурой. Системная память содержит постоянное запоминающее устройство (ПЗУ) 24, память с произвольным доступом (ОЗУ) 25. Основная система ввода/вывода (BIOS) 26 содержит основные процедуры, которые обеспечивают передачу информации между элементами персонального компьютера 20, например, в момент загрузки операционной системы с использованием ПЗУ 24.
Персональный компьютер 20 в свою очередь содержит жесткий диск 27 для чтения и записи данных, привод магнитных дисков 28 для чтения и записи на сменные магнитные диски 29 и оптический привод 30 для чтения и записи на сменные оптические диски 31, такие как CD-ROM, DVD-ROM и иные оптические носители информации. Жесткий диск 27, привод магнитных дисков 28, оптический привод 30 соединены с системной шиной 23 через интерфейс жесткого диска 32, интерфейс магнитных дисков 33 и интерфейс оптического привода 34 соответственно. Приводы и соответствующие компьютерные носители информации представляют собой энергонезависимые средства хранения компьютерных инструкций, структур данных, программных модулей и прочих данных персонального компьютера 20.
Настоящее описание раскрывает реализацию системы, которая использует жесткий диск 27, сменный магнитный диск 29 и сменный оптический диск 31, но следует понимать, что возможно применение иных типов компьютерных носителей информации 56, которые способны хранить данные в доступной для чтения компьютером форме (твердотельные накопители, флэш карты памяти, цифровые диски, память с произвольным доступом (ОЗУ) и т.п.), которые подключены к системной шине 23 через контроллер 55.
Компьютер 20 имеет файловую систему 36, где хранится записанная операционная система 35, а также дополнительные программные приложения 37, другие программные модули 38 и данные программ 39. Пользователь имеет возможность вводить команды и информацию в персональный компьютер 20 посредством устройств ввода (клавиатуры 40, манипулятора «мышь» 42). Могут использоваться другие устройства ввода (не отображены): микрофон, джойстик, игровая консоль, сканнер и т.п. Подобные устройства ввода по своему обычаю подключают к компьютерной системе 20 через последовательный порт 46, который в свою очередь подсоединен к системной шине, но могут быть подключены иным способом, например, при помощи параллельного порта, игрового порта или универсальной последовательной шины (USB). Монитор 47 или иной тип устройства отображения также подсоединен к системной шине 23 через интерфейс, такой как видеоадаптер 48. В дополнение к монитору 47 персональный компьютер может быть оснащен другими периферийными устройствами вывода (не отображены), например, колонками, принтером и т.п.
Персональный компьютер 20 способен работать в сетевом окружении, при этом используется сетевое соединение с другим или несколькими удаленными компьютерами 49. Удаленный компьютер (или компьютеры) 49 являются такими же персональными компьютерами или серверами, которые имеют большинство или все упомянутые элементы, отмеченные ранее при описании существа персонального компьютера 20, представленного на Фиг.6. В вычислительной сети могут присутствовать также и другие устройства, например маршрутизаторы, сетевые станции, пиринговые устройства или иные сетевые узлы.
Сетевые соединения могут образовывать локальную вычислительную сеть (LAN) 50 и глобальную вычислительную сеть (WAN). Такие сети применяются в корпоративных компьютерных сетях, внутренних сетях компаний и, как правило, имеют доступ к сети Интернет. В LAN- или WAN-сетях персональный компьютер 20 подключен к локальной сети 50 через сетевой адаптер или сетевой интерфейс 51. При использовании сетей персональный компьютер 20 может использовать модем 54 или иные средства обеспечения связи с глобальной вычислительной сетью, такой как Интернет. Модем 54, который является внутренним или внешним устройством, подключен к системной шине 23 посредством последовательного порта 46. Следует уточнить, что сетевые соединения являются лишь примерными и не обязаны отображать точную конфигурацию сети, т.е. в действительности существуют иные способы установления соединения техническими средствами связи одного компьютера с другим.
В заключение следует отметить, что приведенные в описании сведения являются только примерами, которые не ограничивают объем настоящего изобретения, определенного формулой.