RU2514139C1 - System and method of creating rules for filtering insignificant events for event log analysis - Google Patents

Abstract

FIELD: physics, computer engineering.

SUBSTANCE: invention relates to means of creating rules for filtering insignificant events for event log analysis. Data are obtained from at least one data base. A template program is formed based on the obtained data. The formed template program is run using a software execution monitoring means. All events are recorded in an event log for events occurring while the template program is running. At least one rule for filtering low-significance events is created based on events from the event log if said events are low-significance events, where a low-significance event is an event occurring when running or emulating both safe applications and malicious applications.

EFFECT: fewer malfunctions when detecting malicious objects.

21 cl, 8 dwg, 1 tbl

Description

Technical field

This invention relates to systems for analyzing event protocols during application emulation and, more specifically, to systems for preliminary filtering of insignificant events in order to reduce false positives when malicious objects are detected during emulation and when forming rules of behavior.

State of the art

Currently, the distribution of malicious software (hereinafter referred to as the software) is increasing every day, and the harm that this software does to personal computers (hereinafter referred to as the PC) of users is also increasing. Existing methods of protecting personal computers, as well as computers in the corporate network, are designed both to detect already known threats and to detect unknown threats. Methods of protection against known threats (computer viruses), as a rule, are based on signature scanning, which uses code templates obtained from known malicious programs for subsequent scanning of objects. Also, methods of protection against known viruses are: the technology of "white lists", which uses templates of already known trusted programs, the technology of "black lists", systems for checking checksums, metadata, etc. However, the speed of the emergence of new malware has been steadily increasing recently, which requires a constant increase in the role of proactive protection for real-time user protection. The proactive methods most often used for this purpose, as a rule, include a code emulator. The emulator parses the byte code of the program into commands and launches each command in a virtual copy of the computer. This allows the protection tool to monitor the behavior of the program without compromising the PC operating system and user data.

Currently, the emulator can also contain an analytical module that collects information about the analyzed object, conducts research, and based on it draws a conclusion about the harmfulness of a particular object and generates detection rules. Typically, an emulator with an analysis module performs in-depth analysis using rules to detect unknown threats that were created in antivirus laboratories. Also, the emulator may use various ratings during application research (for example, the hazard rating described in utility patent RU 101233). It should be noted that during the emulation of applications for subsequent analysis / research, a protocol of events has been formed that contains both ordinary (typical) events of safe (known) programs and suspicious events of other programs (unknown or malicious). Based on the analysis of this protocol of events, during which the rules for detecting events that have occurred and calculating the rating are used, the final verdict on the harmfulness of the application under investigation is issued.

Currently, there are various methods for filtering event protocols (logs). As a rule, filtering is used to obtain the necessary data (events) from the protocol, according to the requested criteria.

So, in patent US 7707189 B2 describes a method of managing entries in the logbook associated with events that occurred during application operation. The method includes analysis and filtering of records in the event log, and information related to these records using filtering rules.

US Pat. No. 7,024,694 B1 describes a method for detecting intrusions into a computer system using a monitoring system. The control system generates a log of perfect events and analyzes using the control list received in advance, containing the conditions and criteria for verification. The system also allows on the basis of identified events to dynamically adjust the control criteria or conditions for subsequent control.

However, the above inventions do not solve one of the main problems in the analysis of protocols - large time costs, because created logs of events during emulation reach enormous sizes, which can reach up to a million lines. Another drawback is that when analyzing such protocols, it is difficult to identify low-significant significant events among a large number of insignificant (insignificant) events. An insignificant event is an event that, from the point of view of analyzing the danger of behavior (perfect action), does not matter much, because This event can occur both during the execution of safe software and during the execution of malware. Therefore, with the help of insignificant events it is impossible to determine exactly whether the software is malicious or not. A typical example of insignificant events when executing any software written in the Delphi programming language may be events that occurred from the execution of additional code added during compilation of this software, for example, “startup code”.

Another problem of event filtering systems is that when performing their training, i.e. creating new or adjusting existing rules for detecting events that have occurred, there is a risk of creating a rule that is standard for some legitimate software. Thus, there will be a significant risk of false positives for legitimate software. An example of events for which a false rule can be created are events that occurred during application execution, which were previously compressed and / or encrypted using specialized protection programs. Examples of protection programs are research protection programs (for example, OSProtector), which can perform many different operations to protect a software application from unauthorized modification, but this is not an indicator of the legitimacy or harmfulness of this application - any application protected by such a program will have such behavior.

These problems can be solved using pre-filtering, i.e. filtering at the stage of events and their recording in the emulation protocol.

Thus, it is required to create a solution that allows preliminary filtering of events using pre-formed rules for filtering insignificant events. The system for filtering insignificant events, which will be described later, allows us to solve the problem of reducing the size of the protocol of perfect events.

SUMMARY OF THE INVENTION

The present invention is intended for pre-filtering entries in the protocol of events created during the emulation of the application, in order to reduce its size by searching and deleting typical (unimportant) events.

The technical result of this invention is to enable filtering of insignificant events in the event protocol generated during tracking application execution, which is achieved by forming rules for filtering insignificant events.

The system of forming rules for filtering insignificant events, which includes:

a) at least one information base containing a data set for the formation of sample programs;

b) a means for generating a sample program for generating a sample program using data from at least one information base and transmitting said sample program to a software execution tracking means;

c) said software execution tracking tool, which is intended for:

- the formation of a protocol of events during the execution of the mentioned sample program and

- transmitting said protocol of events to the analysis tool.

d) said analysis tool, which is intended for:

- the formation of rules for filtering insignificant events on the basis of each event from the mentioned protocol of events in the event that the specified event is an insignificant event,

where as an insignificant event is an event that occurs during the execution of both safe applications and malicious applications,

- transmission of the formed rules for filtering insignificant events to the database of rules for filtering insignificant events;

d) the above-mentioned base of rules for filtering insignificant events, designed to store the resulting rules for filtering insignificant events.

In a particular embodiment of the system, at least one information base is at least a compiler base, a packer base, a protector base, an archiver database.

In a particular embodiment of the system, the data contained in the said information base, at least, are the applications themselves, parts of the application program code, application metadata, hash sums of applications, or a combination of these entities.

In a particular embodiment of the system, the application metadata, at least, are application names, application size, application version number, application type.

In a particular embodiment of the system, at least one of the following means is used as a means of monitoring software execution: an emulator, a disassembler, and a tracer.

In a particular embodiment of the system, an insignificant event is an event from the generated event protocol.

In a particular embodiment of the system, the system contains an update tool for transmitting filtering rules of minor events to personal computers of users.

In a particular embodiment of the system, the analysis tool is associated with a database of event protocols from malicious programs, which contains at least one event protocol that was generated during the execution of malicious applications, and with a database of event protocols from safe programs, which contains at least , one event log that is generated during the execution of secure applications.

In a particular embodiment of the system, an analysis tool based on the analysis of at least one event flow from the database of event protocols from malicious programs and one event protocol from the database of event protocols from safe programs generates three lists of events:

a) a list of safe events that contains events that were detected only in the event logs generated during the execution of safe applications,

b) a list of malicious events that contains events that were detected only in the event logs generated during the execution of malicious applications;

c) a list of insignificant events that contains events that were detected both in the event logs generated during the execution of malicious applications, and in the event logs generated during the execution of safe applications.

In a particular embodiment of the system, the analysis tool conducts a preliminary analysis of events from the event protocol, which is generated during the execution of the sample program using the generated event lists a) and b), and generates filtering rules for events of little significance based on each event from the list of events of little significance events.

In a particular embodiment of the system, the analyzed event is an insignificant event if the specified event is not in the mentioned lists of events a) and b).

A method of forming rules for filtering insignificant events, comprising stages in which:

a) receive data from at least one information base,

b) form a program - a sample based on the data received,

c) execute the generated program - sample using the software execution tracking tool,

d) register all events in the protocol of events that occur during the execution of the sample program,

e) form at least one rule for filtering insignificant events on the basis of events from the protocol of events, if these events are insignificant events,

where as an insignificant event is an event that occurs during the execution or emulation of both safe applications and malicious applications. In a particular embodiment of the method, three lists of events are generated that were identified by analyzing at least one event protocol created during the execution of malicious programs, and at least one event protocol created during the execution of safe programs, and event lists contain:

a) a list of safe events that contains events that were detected only in the event logs generated during the execution of safe applications,

b) a list of malicious events that contains events that were detected only in the event logs generated during the execution of malicious applications;

c) a list of insignificant events that contains events that were detected both in the event logs generated during the execution of malicious applications, and in the event logs generated during the execution of safe applications.

In a particular embodiment of the method, rules for filtering insignificant events are formed based on events from the list of insignificant events.

In a particular embodiment of the method, a preliminary check of events is carried out from the protocol of events created during execution of the sample program before the formation of rules for filtering insignificant events using the mentioned event lists a) and b) to determine insignificant events.

In a particular embodiment of the method, an event is an insignificant event if the specified events from the protocol of events created during the execution of the sample program are not contained in the mentioned lists of events a) and b).

In a particular embodiment of the method, rules for filtering insignificant events are stored in the database of rules for filtering insignificant events.

In a particular embodiment of the method, rules for filtering insignificant events are transmitted to personal computers of users using the update tool.

In a particular embodiment of the method, data received from infobases is at least data about known compilers, packers, protectors, archivers.

In a particular embodiment of the method, the data received from the infobases at least are the applications themselves, application metadata, parts of the application program code, hash sums of the applications, or a combination of these entities.

In a particular embodiment of the method, at least one of the following means is used as a means of monitoring software execution: an emulator, a disassembler, and a tracer.

Brief description of the attached drawings

The accompanying drawings, which are included to provide an additional understanding of the invention and form part of this description, show embodiments of the invention and together with the description serve to explain the principles of the invention.

The claimed invention is illustrated by the following drawings, in which:

Figa, 1B, 1B illustrate examples of the implementation of the system for creating rules for filtering insignificant events.

Figure 2 illustrates an example of the analyzer operation when forming rules for filtering insignificant events.

Figure 3 illustrates a flowchart for a method by which you can implement a system for creating rules for filtering insignificant events.

Figure 4 illustrates an algorithm for creating filtering rules of minor events.

Figure 5 shows the boundaries of the separation of events in the analysis of event protocols.

6 shows an example of a general purpose computer system on which the present invention can be implemented.

Description of Embodiments

The objects and features of the present invention, methods for achieving these objects and features will become apparent by reference to exemplary embodiments. However, the present invention is not limited to the exemplary embodiments disclosed below, it can be embodied in various forms. The essence described in the description is nothing more than the specific details necessary to assist the specialist in the field of technology in a comprehensive understanding of the invention, and the present invention is defined in the scope of the attached claims.

One of the options for implementing this invention is a system for creating rules for filtering insignificant events (MS), presented in figa, figb and figv. The presented system is an additional component for filtration systems in the formation and / or analysis of event protocols created during emulation of software (software, applications). The software emulator, as a rule, is part of an anti-virus tool that, during the software scan, searches for unknown malicious objects on the user's PC. As an object, you can consider an executable file, for example, [name]. Exe, which is checked by the application emulator before starting.

The application emulator parses the byte code of the application into commands, and then runs each command in a virtual copy of the computer, which allows you to monitor the behavior of this application. When an application is tested during the execution of each command or a set of commands, events occur that, after preliminary analysis, will be recorded in the event protocol for subsequent analysis (to directly detect the harmfulness of the application). During the preliminary analysis, rules for filtering insignificant events on the side of the user's PC are used.

If a perfect event when emulating the application was identified by some rule for filtering insignificant events, then this event will be an insignificant event and will not be added to the event log. If the event was not identified by any rule, the event will be entered into the event protocol for further analysis by other means of the anti-virus device, for example, using the system described in the patent for utility model RU 101233. After that, the final decision will be made.

As previously determined, an insignificant event is an event that occurs during the execution of both safe software applications and malicious software applications. Therefore, by such an event or by the totality of such events it is impossible to determine exactly what the application is. In addition, such events are not only useless for the analysis of emulation protocols, but also harmful, since they increase the size of the emulation protocol by tens to hundreds of times, which makes it difficult (a significant increase in time) to detect malicious actions. It is also worth noting that insignificant events can affect the formation of rules for analyzing event protocols during emulation, because analysis rules can be created on the basis of insignificant events (i.e., false triggering is possible).

Examples of minor events are:

1) the call "GetVersion ()" - a request for the version of the operating system. Any application written in the Delphi 7 programming language will make this request, and such a request does not indicate whether the application is malicious or not;

2) a call “RegOpenKeyEx (0 × 80000001," Software \ Borland \ Locales * ^, „,);” - this action will also be performed when any application written in Delphi 7 is executed, and it is also impossible to determine which application is using it;

3) the call "GetModuleHandle (" USER32.DLL ");" - this action is inherent in 80% of all executable files, therefore, this action will be performed both while executing safe applications and malicious ones.

It is worth noting that the filtering system, when creating and subsequently analyzing event protocols for executing the analyzed software (software, applications) and creating an event protocol, instead of an emulator, can also use other means of tracking software execution. At least a disassembler and a tracer can be used as a means of tracking software execution. For the convenience of understanding the invention, when describing the drawings, an emulator is used as a means of tracking software execution.

On figa shows a structural diagram of a system for creating rules for filtering insignificant events. In one embodiment, the MS 100 filtering rule creation system interacts with the anti-virus server 101. An example of an anti-virus server 101 may be a server that provides the Kaspersky Security Network service. The anti-virus server 101 contains various information about the software that is developed by development companies, for example Microsoft, and then runs on users' PC 180A, ..., 180N. All information about various programs is stored in the corresponding information databases 110A, ..., 110N. Information databases 110A, 110N can be located separately (in the anti-virus server 101) from other means of the system 100, or together with them. The information contained in the information databases 110A, 110N can be either the application (file) itself or any information about applications, for example application metadata, parts of program code, hash sum of the application, etc. formation bases 110A, ..., 110N are formed by application types, for example, the base of compilers 110A, the base of packers 110B (applications for compressing the executable file), the database of protectors / cryptors 110B (applications for compressing and encrypting the executable file), etc.

The system for creating filtering rules MS 100 requests from the bases 110A, 110N information about the compilers, packers, protectors and other programs contained in them. The bases 110A, ..., 110N send the requested information to the means of creating the sample program 120. As described above, as information, for example, either the executable file of the compiler, packer, protector, etc., or the path to the executable file will be transferred. The tool for creating the sample program 120 uses, for example, the compiler to generate the sample program 125, which is sent to the tool for tracking the execution of software (hereinafter - the emulator) 130.

It is worth noting that the created sample program 125 is the simplest application that does not perform any actions and serves only to highlight fragments - dummies created when such an application was launched. For example, each compiler from base 110A has a standard list of events that will be executed during the execution of applications created (compiled) using the corresponding compiler. An example of a simple application created using a compiler for the Delphi programming language is the application:

Begin

End.

You can also connect various standard libraries to this application that will be called when the application runs. In this case, the sample program 125, written in the Delphi programming language, can be of the form:

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, type

TMain = class (TForm)

end;

var

Main: TMain;

implementation

begin

end.

In the event that the data was obtained from the databases 110B or 110B, the sample program 125 will be an application created (written) in any programming language, and at the same time it will be packaged by the appropriate packer or protector, information about which was provided to the tool 120.

The emulator 130 emulates the resulting sample program 125, during which it registers all the events that occur in the event log 135. Emulation of the sample program 125 means parsing its program code for instructions and simulating their execution. The emulator 130 then transmits the generated event log 135 to the analyzer 140.

It is worth noting that all events from the event log 135 will be insignificant events, since these events will be inherent in any application that will be created using the analyzed compiler or packaged using the analyzed protector or packer, regardless of whether the application is safe or malicious.

The analyzer 140, based on each event from the received event protocol 135, creates a filtering rule for events of little significance. The filtering rule is a Boolean attribute and contains the name of the API - a function and a mask for its arguments (the number of arguments is from 1 to N). Each mask argument can take values:

- NULL - - indicates that the function argument must be empty,

- * - any value of the argument,

- the specific value of the argument (in this case, the comparison of the value of the argument and the set value will be performed until complete coincidence).

An example of such an API function (filtering rules of an insignificant event) is the SysAllocString function with three arguments (*, - NULL -, - NULL-), where the first argument is any, and the rest are absent.

The analyzer 140, based on the created filtering rules of insignificant events, generates a packet of rules 145, which then passes to the filtering rule base MS 160.

The MS 160 filtering rule base adds the resulting rule package 145 to table 1 of the filtering rules of minor events for subsequent storage. After adding the rule package 145 to the database 160, the version of the specified database is changed and transferred to the update tool 165. An example of a table of rules for filtering insignificant events is table 1 of the following form:

Table 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 × 80,000,000 .key ... ,, RegSetValue 0 × 80,000,000 .key ... , ””, Createdirectory file: // C: / DOCUME ~ l / ADMINI ~ l / LOCALS ~ l / Temp / ~~~ -NULL- ... -NULL- ... ... ... ... ...

In table 1, the first column (API_FUNCT) contains the names of the API functions, and the subsequent columns (ARG1, ARG2, ..., ARGN) contain the arguments of the functions.

It is also worth noting that the MS 100 filtering rules creation system will provide MS filtering rules from the filtering rules database 160 to antivirus products located on users’s PC 180A, 180N, in case of receiving a request from these anti-virus tools. In this case, all interactions between the system for creating filtering rules MS 100 and user PCs 180A, 180N pass through the Internet 170.

In the particular case of the implementation, the interaction of the filtering rule base MS 160 and the users’ PC 180A, ..., 180N occurs through the update tool 165. In this case, the update tool 165 contains the current version of the database 160. Then, upon receipt of a request from anti-virus tools located on the users’s PC 180A, 180N or other devices, the updater 165 will compare the received database version with its version of the database 160. If the versions match, then the anti-virus tools on the 180A, ..., 180N users' PCs already contain the current database of filtering rules NA. In the event that the versions are different, then a packet of rules for filtering insignificant events 175 will be generated. Package 175 will contain all the filtering rules created after the presented version of the rule base from users PC 180A, 180N. Then this package 175 will be sent to the appropriate antivirus tools on the PC users 180A, ..., 180N.

On Figb shows another example implementation of a system for creating rules for filtering insignificant events. In this example implementation, the filtering rule creation system 100 contains only the analyzer 140, the MS 160 filtering rule base and the update tool 165, and interacts with the anti-virus server 101. In this implementation, the anti-virus server 101 contains two databases 150A and 150B. Database 150A contains the BL 152 event logs that were generated by emulating only malicious applications. Database 150B contains WL 154 event logs that were generated only when emulating secure applications.

The analyzer 140 requests from the bases 150A and 150B all event logs BL 152 and WL 154, which are in the specified databases at the time of the request. Next, the analyzer 140 analyzes all the obtained protocols of events 152 and 154, at the end of which it forms a list of unimportant events 270 (the operation of the analyzer 140 will be discussed in more detail in FIG. 2). The list of unimportant events 270 contains events that occurred both in the event logs of BL 152 and in the event logs of WL 154. All events that appear in the specified list of 270 are insignificant events.

Next, the analyzer 140, based on each event from the generated list of unimportant events 270, creates an NS filtering rule. Then, all created MS filtering rules are transferred to the MS 160 filtering rule base in the form of a rule package 145. The MS 160 filtering rule base is received by adding the received rule package 145 to the filtering rules table of insignificant events for subsequent storage and transfer of the PC to users 180, if they receive a request . All interactions between the system for creating filtering rules MS 100 and the user PC 180 occur through the update tool 165, which in turn interacts with the user PC 180 through the Internet 170.

Another example implementation of a system for creating rules for filtering insignificant events is presented in Figure 1 B.

Presented in FIG. 1, an embodiment of a system for creating filtering rules MS combines the approaches presented in FIGS. 1A and 1B. Also in this implementation, the analyzer 140 checks each event from the received event protocol 135 from the emulator 130 for their compliance with the criterion of an insignificant event. The check will occur using the list of safe events 260 and the list of malicious events 250 (Figure 2). These lists will be generated by the analyzer 140 during the analysis of event protocols 152 and 154 from the bases 150A and 150B together with the list of events 270, as described in Fig.1B.

Next, the analyzer 140 will compare each event from the event log 135 with the generated event lists 250 and 260.

In the event that an event from event protocol 135 received from emulator 130 was found in event lists 250 and 260, then this event is not an insignificant event and will be deleted.

If the event from the event protocol 135 received from the emulator 130 was not found in the event lists 250 and 260, then this event is an insignificant event, and the analyzer 140 generates a filtering rule based on this event. After the formation of rules based on events that have passed verification, the analyzer 140 generates a packet of rules 145, which transmits to the filtering rule base MS 160.

Figure 2 illustrates an example of the operation of the analyzer 140 in the formation of filtering rules of minor events. In one embodiment, the analyzer 140 consists of an event protocol analysis module 210 (hereinafter referred to as module 210), an event protocol analysis module and event list generation 230 (hereinafter referred to as module 230) and a module for generating filtering rules of minor events 290 (hereinafter referred to as module 290) .

Module 210 is designed to analyze the event protocol 135 received from the emulator (software execution tracking tool) 130 and provide all minor events to module 290 in the form of a list of minor events 280. Also, module 210 conducts preliminary verification (as described in Figure 1 B) of all events from protocol 135 using a list of malicious events 250 and a list of safe events 260 received from module 230.

Module 230 is designed to analyze BL 152 event protocols and WL 154 event protocols received from databases 150A and 150B stored on anti-virus server 101. Based on the analysis, module 230 generates three lists of events: a list of malicious events 250, a list of safe events 260, and a list unimportant events 270. Then module 230 provides lists 250 and 260 to module 210, and list 270 provides to module 290.

Module 290 is designed for:

- the formation of rules for filtering insignificant events (MS) based on the received lists of insignificant events 270 and 280 from modules 210 and 230 (as described when considering Figa);

- the formation of a package of rules 145 from the generated filtering rules of the MS and

- the subsequent transfer of the generated packet of rules 145 to the filtering rule base MS 160.

In the particular case of implementation, module 290 checks the generated MS filtering rules for their presence in the MS 160 filtering rules database. In the event that the generated MS filtering rules are found in the database 160, the rules will not be added to the database 160, but will be deleted.

It is worthwhile to dwell in more detail on the boundary of the selection of insignificant events when analyzing events from the event protocols 152 and 154, which is explained using Figure 5. First, all events that were detected in both protocols (152 and 154) will be highlighted. Then each event will be analyzed, while the set of protocols in which the analyzed event was detected will be 100% of the protocols.

Further, three situations are possible:

1. The event detection ratio was 30% / 70% or less towards the WL 152 event protocols, i.e. this event was detected in the event logs WL 152 from 0% to 30% and from 70% to 100% in the event logs BL 154. In this case, the event is a suspicious event and will be added to the list of malicious events 250.

2. The event detection ratio was 30% / 70% or more towards the WL 152 event protocols, but not more than 70%, ie this event was detected in the event logs WL 152 from 30% to 70% and from 70% to 30% in the event logs BL 154. In this case, the event is an insignificant event and will be added to the list of insignificant events 270.

3. The event detection ratio was 70% / 30% or more towards the WL 152 event protocols, i.e. This event was detected in the event logs WL 152 from 70% to 100% and from 30% to 0% in the event logs BL 154. In this case, the event is a trusted (potentially safe) event and will be added to the list of safe events 260.

It is also worth noting that the most accurate result in the formation of event lists 250, 260 and 270 is achieved when analyzing several hundred event protocols or more.

Figure 3 shows a block diagram for a method by which it is possible to implement a system for creating rules for filtering insignificant events. To create filtering rules for MS at step 310, the system for creating filtering rules for MS 100 sends a request for new data to the databases from the list of bases 110A, 110N. The request can be transmitted to all bases 110A, 110N immediately, or in turn. After receiving the request, the bases 110A, 110N are transferred to the system for creating filtering rules MS 100, namely, to the means for creating the sample program 120 all data (information) stored on them about objects (compilers, protectors, packers, etc.). The data (information) contained in the databases 110 can be either the application (file) itself or any data (information) about them, for example, application metadata, parts of program code, hash sum of the application, etc. At step 315, the means for creating the sample program 120 checks the received data for their novelty.

In one implementation option, checking the data for novelty may consist in generating a hash amount for each set of data about each received object. The generated hash sum is compared with the list of previously created hash sums that is stored in the tool for creating the sample program 120. If the generated hash sum is found in the list of hash sums, the generated hash sum is not new, and means 120 will delete all the data on the basis of which the hash amount has been generated. In the event that the generated hash amount is not found in the list of hash amounts, then the generated hash amount is new and will be added to the specified list of hash amounts, and the data on the basis of which the hash amount was generated will be transmitted to step 320.

At step 320, a sample program 125 is generated based on the received data using the tool 120. At step 325, the tool 120 transmits the sample program 125 to the software execution tracking tool (hereinafter, the emulator) 130 for further analysis. After that, the emulator 130 is started, and at step 330 the emulation (execution) of the sample program 125 is carried out. During the emulation, an event protocol 135 is generated, where the emulator 130 records all the committed actions (happened events) of the sample program 125. At step 335, the generated event protocol 135 is passed to an analyzer 140, which checks it to identify events of little significance. Verification is carried out by comparing events from the event protocol with events from lists 250 and 260. In the event that events are not found in the indicated lists 250 and 260, then these events are insignificant events and will be added to list 280, which after the end of the check will be passed to step 345. In the event that events are found in the indicated lists 250 and 260, then these events will be deleted, because will not be insignificant events.

At step 345, the analyzer 140 generates filtering rules based on the events from the list 280. The formation of filtering rules of minor events occurs as described in FIG. 1A. At step 350, the generated rules are added to the MS 160 filtering rule base for subsequent storage, pre-generated as a packet of rules 145. At step 355, a decision is made whether to continue to generate filtering rules for insignificant events or to terminate the work. In the event that all the data obtained from the information databases 110A, 110B, 110B, ..., HON were analyzed, then the work will be completed. In the event that not all data from the bases 110A, 110B, 110B, ..., 110N has been analyzed, then the system 100 will return to step 310.

Figure 4 shows the algorithm for creating rules for filtering insignificant events.

At step 415, the analyzer 140 receives at least one BL 152 event log from base 150A and at least one WL 154 event log from base 150B. At step 430, the analyzer 140 compares all received event protocols and identifies events that are encountered in both the BL 152 and WL 154 protocols. At the next step 445, the analyzer 140 generates a list of events from the events that were in both types of protocols. Based on this list of events, the analyzer 140, in step 460, creates NS filtering rules. Then, from the created filtering rules, the MS generates a packet of rules 145, which transmits the filtering rule MS 160 to the base. At step 475, the base 160 will add the MS filtering rules from the received packet of rules 145 to the table of filtering rules of minor events for subsequent storage.

Figure 6 shows a computer system for which the described invention can be used.

6 represents an example of a general-purpose computer system (it can be either a personal computer or a server) 20, comprising a central processor 21, a system memory 22 and a system bus 23 that contains various system components, including memory associated with the central processor 21. The system bus 23 is implemented as any bus structure known in the art, which in turn contains a bus memory or a bus memory controller, a peripheral bus and a local bus that is capable of interacting with any other bus Noah architecture. The system memory contains read-only memory (ROM) 24, random access memory (RAM) 25. The main input / output system (BIOS) 26 contains the basic procedures that ensure the transfer of information between the elements of the personal computer 20, for example, at the time of loading the operating system using ROM 24.

The personal computer 20 in turn contains a hard disk 27 for reading and writing data, a magnetic disk drive 28 for reading and writing to removable magnetic disks 29, and an optical drive 30 for reading and writing to removable optical disks 31, such as a CD-ROM, DVD -ROM and other optical information carriers. The hard disk 27, the magnetic disk drive 28, the optical drive 30 are connected to the system bus 23 through the interface of the hard disk 32, the interface of the magnetic disks 33 and the interface of the optical drive 34, respectively. Drives and associated computer storage media are non-volatile means of storing computer instructions, data structures, software modules and other data of a personal computer 20.

The present description discloses an implementation of a system that uses a hard disk 27, a removable magnetic disk 29, and a removable optical disk 31, but it should be understood that other types of computer storage media 56 that can store data in a form readable by a computer (solid state drives, flash memory cards, digital disks, random access memory (RAM), etc.) that are connected to the system bus 23 through the controller 55.

Computer 20 has a file system 36 where the recorded operating system 35 is stored, as well as additional software applications 37, other program modules 38, and program data 39. The user is able to enter commands and information into personal computer 20 via input devices (keyboard 40, keypad “ the mouse "42). Other input devices (not displayed) can be used: microphone, joystick, game console, scanner, etc. Such input devices are, as usual, connected to the computer system 20 via a serial port 46, which in turn is connected to the system bus, but can be connected in another way, for example, using a parallel port, a game port, or a universal serial bus (USB). A monitor 47 or other type of display device is also connected to the system bus 23 via an interface such as a video adapter 48. In addition to the monitor 47, the personal computer may be equipped with other peripheral output devices (not displayed), for example, speakers, a printer, and the like.

The personal computer 20 is capable of operating in a networked environment, using a network connection with another or more remote computers 49. The remote computer (or computers) 49 are the same personal computers or servers that have most or all of the elements mentioned earlier in the description of the creature personal computer 20 shown in Fig.6. Other devices, such as routers, network stations, peer-to-peer devices, or other network nodes may also be present on the computer network.

Network connections can form a local area network (LAN) 50 and a wide area network (WAN). Such networks are used in corporate computer networks, internal networks of companies and, as a rule, have access to the Internet. In LAN or WAN networks, the personal computer 20 is connected to the local area network 50 via a network adapter or network interface 51. When using the networks, the personal computer 20 may use a modem 54 or other means of providing communication with a global computer network such as the Internet. The modem 54, which is an internal or external device, is connected to the system bus 23 via the serial port 46. It should be clarified that the network connections are only exemplary and are not required to display the exact network configuration, i.e. in reality, there are other ways to establish a technical connection between one computer and another.

In conclusion, it should be noted that the information provided in the description are only examples that do not limit the scope of the present invention defined by the claims.

Claims (21)

1. The system of forming rules for filtering insignificant events, which includes:
e) at least one information base containing a data set for generating sample programs;
g) a means for generating a sample program for generating a sample program using data from at least one information base and transmitting said sample program to a software execution tracking means;
h) said software execution tracking tool, which is intended to:
- the formation of a protocol of events during the execution of the mentioned sample program and
- transmitting said protocol of events to the analysis tool.
i) said analysis tool, which is intended for:
- the formation of rules for filtering insignificant events on the basis of each event from the mentioned protocol of events in the event that the specified event is an insignificant event,
where as an insignificant event is an event that occurs during the execution of both safe applications and malicious applications,
- transmission of the formed rules for filtering insignificant events to the database of rules for filtering insignificant events;
j) the mentioned base of rules for filtering insignificant events, intended to store the obtained rules for filtering insignificant events. 2. The system according to claim 1, where at least one information base is at least a compiler database, a packer database, a database of protectors, an archiver database. 3. The system according to claim 1, where at least the data contained in the said information base are the applications themselves, parts of the application program code, application metadata, hash sums of applications, or a combination of these entities. 4. The system according to claim 3, where the application metadata, at least, are application names, application size, application version number, application type. 5. The system according to claim 1, where as a means of monitoring the execution of software is at least one of the following tools: emulator, disassembler and tracer. 6. The system according to claim 1, where as an event from the generated protocol of events is an insignificant event. 7. The system according to claim 1, which also contains an update tool designed to transmit filtering rules of minor events to personal computers of users. 8. The system according to claim 1, in which the analysis tool is associated with:
- a database of events protocols from malicious programs, which contains at least one event protocol, which is formed during the execution of malicious applications, and
- a base of event protocols from safe programs, which contains at least one event protocol, which is generated during the execution of safe applications 9. The system of claim 8, in which the analysis tool based on the analysis of at least one event flow from the database of event protocols from malicious programs and one event protocol from the database of event protocols from safe programs generates three lists of events:
a) a list of safe events that contains events that were detected only in the event logs generated during the execution of safe applications,
b) a list of malicious events that contains events that were detected only in the event logs generated during the execution of malicious applications;
c) a list of insignificant events that contains events that were detected both in the event logs generated during the execution of malicious applications, and in the event logs generated during the execution of safe applications. 10. The system according to claim 9, in which the analysis tool performs a preliminary analysis of events from the event protocol, which is generated during the execution of the mentioned sample program using the generated event lists a) and b), and generates filtering rules for events of little significance based on each events from the mentioned list of insignificant events. 11. The system of claim 10, in which the analyzed event is an insignificant event, if the specified event is not in the mentioned lists of events a) and b). 12. A method of forming rules for filtering insignificant events, comprising stages in which:
f) receive data from at least one information base,
g) form a sample program on the basis of the data obtained,
h) execute the generated sample program using the software execution tracking tool,
i) register all events in the protocol of events that occur during execution of the sample program,
j) form at least one rule for filtering insignificant events on the basis of events from the protocol of events, if these events are insignificant events,
where as an insignificant event is an event that occurs during the execution or emulation of both safe applications and malicious applications. 13. The method according to item 12, which generates three lists of events that were identified by analyzing at least one event protocol created during the execution of malicious programs, and at least one event protocol created during executing secure programs, and event lists contain:
a) a list of safe events that contains events that were detected only in the event logs generated during the execution of safe applications,
b) a list of malicious events that contains events that were detected only in the event logs generated during the execution of malicious applications;
c) a list of insignificant events that contains events that were detected both in the event logs generated during the execution of malicious applications, and in the event logs generated during the execution of safe applications. 14. The method according to item 13, in which the rules for filtering insignificant events are formed based on the events from the list of insignificant events. 15. The method according to item 13, in which a preliminary check of events is carried out from the protocol of events created during the execution of the sample program, before forming the rules for filtering insignificant events using the mentioned event lists a) and b) to determine insignificant events. 16. The method according to clause 15, in which the event is an insignificant event, if the specified events from the protocol of events created during the execution of the sample program are not contained in the mentioned lists of events a) and b). 17. The method according to item 12, which store the filtering rules of minor events in the database of filtering rules of minor events. 18. The method according to claims 12 and 17, in which the rules for filtering insignificant events are transmitted to the personal computers of users using the update tool. 19. The method of claim 12, wherein the data received from the infobases is at least data about known compilers, packers, protectors, archivers. 20. The method according to claim 19, in which the data received from the infobases is at least the applications themselves, application metadata, parts of the application software code, a hash - the sum of applications or a combination of these entities. 21. The method according to item 12, in which as a means of monitoring the execution of software is at least one of the following means: an emulator, a disassembler and a tracer.

Images