RU92551U1 - SYSTEM OF TESTING AND CORRECTION OF TEST DATABASES OF ANTI-VIRUS APPLICATION - Google Patents

Abstract

1. The anti-virus database update system, which contains an anti-virus protection tool located on the user’s side, which is associated with a corresponding database intended for storing current and test records; means of processing false positives on the user side, which is designed to handle false positives when the anti-virus protection tool works with test records in the corresponding database of the anti-virus protection tool; means of correcting false positives on the server side, which is designed to correct test records received from the means of processing false positives on the user side, in the database of the anti-virus protection on the server side, which is designed to store current and test records; means for updating current and test entries in the server-side anti-virus protection database, which is designed to add new current and test entries to the anti-virus protection database; user-side anti-virus protection database update tool that is designed to update current and test user-side anti-virus protection database records by downloading an update for current and test server-side anti-virus protection database records. ! 2. The system according to claim 1, in which the means of correcting false alarms on the server side after the correction of test records in the database of the anti-virus protection on the server side is additionally designed to correct test records in the database

Description

Technical field

The utility model relates to systems for reducing the risk of false positives of anti-virus databases.

State of the art

Currently, one of the most urgent tasks of the antivirus industry is the problem of keeping the antivirus databases up to date. Indeed, even in that short time when the malware has not yet been detected by leading anti-virus experts and companies, it can be downloaded hundreds of thousands of times to various users and can infect a large number of computers. To combat unknown programs, modern anti-virus companies use heuristic detection methods, execute unknown programs in a secure environment like sandboxes (sandbox, honeypot) using virtualization, as well as various ways to limit the functionality of programs based on analysis of their activity (HIPS).

Nevertheless, one cannot fully rely on all of the above methods, since all of them have certain disadvantages associated with both the peculiarity of their work and their use in modern anti-virus applications, in which the user has the right to set settings that prevent them from using these technologies in full least, since they can take a noticeable amount of time, for example, when starting unknown programs. Until the end of the verification of unknown programs, the user can disable, for example, their execution in a protected environment like a sandbox or reduce the time that is allocated to emulation.

Therefore, antivirus companies continue to update malware signature databases, in addition to creating software databases of verified or reliable programs (or their executable files), the so-called whitelists, which are becoming more and more popular due to the constant increase in the number of malware programs. Such lists can be compiled on the basis of many factors: the availability of an electronic digital signature or other data of the manufacturer, data on the source (where the program was received from), data on the program's relationships (parent-child relationship), data on the program version (for example, the program can be considered verified based on the fact that the previous version was also in the list of checked programs), data on environment variables (operating system, startup parameters), etc. Before each release of signature updates for anti-virus databases, they should be checked for collisions, for example, with a “white list”. Testing can also take a long time, during which malware can do irreparable harm on many computers.

Accordingly, another important task is to reduce the testing time of antivirus databases that have not yet been released in order to deliver them to users as quickly as possible.

US Pat. No. 7,185,332 describes a system in which various updates can be downloaded to users, for example, those that have already been verified by the software developer, as well as the most recent ones that the developer has not yet had time to fully verify and test. But this patent does not describe the possibility of fixing those updates that came to users and contained undetected errors.

US Pat. No. 7,231,637 describes a system for testing antivirus signatures, during testing of which there may be a count of unsuccessful responses of antivirus signatures and their subsequent correction to release the final version of antivirus signatures. However, this patent does not say that users may be concerned about the frequent operation of the antivirus application during normal operation, which may be due to the imperfection of the test antivirus signatures.

The possibility of automatic rollback to previous versions of software is disclosed in the application US 20040060044, which proposes a system for testing updates to software components, upon detection of errors in which it rolls back to an earlier and stable version. However, this application also does not disclose the possibility of minimizing the consequences of errors after updating.

Another version of the software update testing system is proposed in US 7334005. First, the updates are sent to a narrow list of subscribers, then, if no problems were found, the list of subscribers is expanded. Thus, the problem of preliminary testing is solved. A randomly generated number acts as a sample, which can be generated in time depending on the user's settings (including settings for security risks). Also on the server side, you can decide to download only part of the updates to the user (subscriber) (as part of the risk reduction).

It can be noted that when analyzing the prior art and capabilities it is proposed to shift the task of testing new versions (or updates) of software to the shoulders of end users (or parts thereof), however, there remains a problem associated with the fact that there are users who have experienced an update , for example, antivirus software triggering software from the “white list” (ie, a collision) or the operating system simply crashed. In this case, users are unsatisfied with the service and may demand to disable such updates or may opt out of antivirus software altogether. Accordingly, it is required to propose a solution that would solve the problem of false positives in advance, without notifying users about this.

An analysis of the prior art and the possibilities that arise when combining them in one system allows you to get a new result, which is to reduce the risk of false positives of anti-virus databases, by using test anti-virus databases that will not notify the user in case of possible false positives.

Utility Model Essence

This useful model is intended for testing and fixing databases of anti-virus system tools.

The technical result of this utility model is to reduce the number of false positives of anti-virus databases by using test anti-virus databases that will not notify the user in case of possible false positives.

A system for updating anti-virus databases, which contains: an anti-virus protection tool located on the user’s side, which is associated with a corresponding database for storing current and test records; means of processing false positives on the user side, which is designed to handle false positives when the anti-virus protection tool works with test records in the corresponding database of the anti-virus protection tool; means of correcting false positives on the server side, which is designed to correct test records received from the means of processing false positives on the user side, in the database of the anti-virus protection on the server side, which is designed to store current and test records; means for updating current and test records in the server-side anti-virus protection database, which is designed to add new current and test entries to the anti-virus protection database; user-side anti-virus protection database update tool that is designed to update current and test user-side anti-virus protection database records by downloading an update for current and test server-side anti-virus protection database records.

In a particular embodiment, the server side error correction tool after correcting test records in the server-side anti-virus protection database is additionally designed to correct test records in the user-side anti-virus protection database.

In a particular embodiment, the antivirus protection means are: an emulator and a proactive defense module; signature verification module; application control module; parental control module.

In a particular embodiment, the user-side false positive processing tool further collects information from the user-side anti-virus protection tool event log, which is necessary for the server-side false positive correction tool.

In a particular embodiment, the means of updating current and test entries in the database of the anti-virus protection tool on the server side are malware detection tools in anti-virus laboratories, as well as expert people.

In a particular embodiment of the database with current and test records on the user and server side, the test records are rewritten to the current records after a specified period of time in the absence of false positives from the means of processing false positives on the user side.

Brief Description of the Drawings

Additional objectives, features and advantages of the present utility model will be apparent from reading the following description of the implementation of the utility model with reference to the accompanying drawings, in which:

Figure 1 illustrates a simplified representation of the PE file format.

Figure 2 illustrates a false positive detection scheme for file signatures.

Figure 3 illustrates a scheme for disabling a file signature for users in the presence of a false positive.

Figure 4 illustrates a false positive detection scheme for heuristics.

5 illustrates a scheme for working with unknown files.

6 illustrates a false positive detection scheme for parental control.

Fig. 7 illustrates a system diagram in accordance with one embodiment of the present utility model.

Description of Embodiments of a Utility Model

Next, preferred embodiments of the present utility model will be described, examples of which are shown in the accompanying drawings.

According to the utility model, a system is provided for reducing the number of false positives of anti-virus databases by using test anti-virus databases that will not notify the user in case of possible false positives.

All unknown unknown executable files under study are the so-called PE-files (Portable Executable) and have a PE-format (for the Windows operating system family, under which most malicious software is written). Figure 1 shows a simplified representation of this format, due to which we see that the PE file is presented in the form of a header 105, a certain number of sections 110 (which make up the image of the executable program) and overlay 115 (i.e., a program segment loaded if necessary during its execution). Here we intend to omit many details of the presentation, including a reference to the MZ header and a more detailed description of the sections.

Currently, in order to create a file signature, its hash is calculated (for example, using the MD5 algorithm). Since the calculation of the hash from large files takes a long time, to speed up its calculation, you can not use the entire file as a whole in the hashing algorithm, but only its parts, for example, heading 105, some of sections 110, as well as overlay (if there is one ) 115.

Accordingly, the fewer parts of the file are used for the hashing algorithm, the greater the likelihood that when the anti-virus system operates, the hash taken from the application from the “white list” (for example, the Notepad editor) may coincide with the hash of the malicious application that is in the database antivirus system.

Another common problem when replenishing anti-virus databases is the human factor, when an expert can mistakenly add an application from the "white list" to the list of malicious applications. As a result, users will be very unhappy that the antivirus system they began to identify as an application known as malware.

One embodiment of the present utility model is described in FIG. 7. The anti-virus company has the means of replenishing 770 databases (signatures, heuristics, parental controls, etc.), which it can release in the form of two types of databases - both already tested updates 725a and test records 725b, which can be checked on users' computers in test mode. These entries are transferred to the 720 updater, which is present on every user’s anti-virus system. The anti-virus system has its own databases 715, respectively - both the current 715a and the database with test records 715b. These databases can be used by one of the tools of the anti-virus system 710 — it can be a signature verification tool, an emulator, a heuristic scan tool, etc. If the tool 710 works, then before taking action and notifying the user, it is specified at step 730, whether the entries (or the settings of the anti-virus system tool) that worked on the tool 710 are test ones. If the records were current records 715b, then in this case the tool will work (for example, a signature check will warn that a malicious program has been detected) and the user will be notified 740. If the records were test, then the user will not be notified, and the means of processing false positives 750 checks the event for false positives (for example, an application from the “white list” was erroneously detected as a malicious program). In this case, the means for processing false alarms 750 will register a false positive and send to the means for correcting false alarms 760 all the necessary information that is necessary to fix the database 725b. Also, this information will fall into the database replenishment tool 770, which can be accessed by expert people to correct inaccuracies and errors that occurred during the creation of test records 725b.

It is also necessary to note the change mechanism, which can be used to update the current database 715a for users. In order to save traffic that will be used to download new 725 databases from the antivirus company’s website, test records 715b can also be used for updating, which can be rewritten to replace current records 715a after a certain time if there were no false positives during the work of test records.

Figure 2 illustrates a false positive detection scheme for file signatures. In accordance with one implementation option, at step 210, a test signature for the file is released using the database replenishment tools 770. It should be noted that the utility model with one test record in the database is described hereinafter, but it should be understood that an antivirus company may release them as part of service packs, thus testing a lot of test signatures for various anti-virus system 710 tools. Next, at step 220, data is collected on the response of the test signature. In the event that a large number of false positives are immediately accumulated that were detected using the false positive processing tool 750 (for example, programs from the “white list” are detected instead of malicious ones) and their number exceeds a certain threshold at step 230, then the signature is disabled for all users at step 240 in order to eliminate similar errors in the future. Such cases may occur when, instead of a malicious file, the program from the “white list” was incorrectly defined in the anti-virus company.

If the number of false positives is small, then after some time the data received from users is analyzed at step 250 and the number of false positives is determined at step 260. In the event that no false positives were found, the test signature is translated into the valid one at step 270. However, if false positives were found, then the signature is sent for further analysis at step 280 using the 760 false positive fixer and the anti-virus company will have to fix its own database with Ignatur (or “white lists”) before releasing an update to users.

Figure 3 illustrates a scheme for disabling a file signature for users in the presence of a false positive. This figure depicts another method for processing false positives for file signatures in which the test signature is disabled immediately upon the first false positive. At step 310, a test signature is released using the database replenishment means 770, and then its response statistics are maintained at step 320. In the event that a false response was detected at step 330, which was detected using the false positive processing tool 750, then the signature is immediately turned off at step 350, and the data obtained in case of a false positive can be sent to the antivirus company at 360 for further editing with the help of the correction tool for false positives 760. If the false positive Since the process didn’t happen during the time allotted for testing the test signature, then it is transferred to the current one at step 340.

It is worth noting that during the operation of the system as shown in FIGS. 2 and 3, the user is not notified, since the signature is a test one and could very well be mistakenly added to the databases of the anti-virus system. Thus, two problems can be solved - to reduce the number of false positives for the user and to optimize the testing process for the antivirus company. It can also be noted that the circuit shown in Fig. 2 is well suited for testing the data that the antivirus company has received recently and requires additional analysis time, but at the same time, the company wants to provide protection for its users now. The diagram shown in Fig. 3 is well suited for testing the data that has been carefully processed and ready for users to use, but in order to exclude possible errors, you can release them as test ones with the ability to immediately disable the signatures that issue false positives for users.

In addition to using test signatures, it is possible to use test heuristics as well, i.e. heuristic scanning methods. Figure 4 shows a test scheme for new heuristics, which begins with the fact that at step 410 the antivirus company releases a test heuristic that was developed using database replenishment tools 770 in order to verify its operation in real conditions. At 420, data is collected on its responses. Since the heuristic scanning methods themselves can cause false positives if there are fragments of code in the program that performs actions and / or sequences, including those characteristic of some viruses, the use of the test heuristic will not be displayed to the user. After collecting data at step 420, you can check the number of false positives at step 430, which can be detected using the false positive processing tool 750. In the event that the test heuristic shows good detection results for unknown malicious programs, then it is transferred to the active one at step 440 However, if the test heuristic detects a large number of applications from the “white list”, then it is required to disconnect it from users at step 450 and further refinement at step 460 using the false positives 760. After the heuristic has been finalized, you can transfer it to users again to step 410. In addition to the records, you can also issue test settings for the software emulator in order to select their optimal combination, for example, during virus outbreaks.

There may be cases where neither signature verification nor heuristic analysis can give an exact answer to the question of whether an unknown application (executable file) is malicious software. In this case, you can use various methods of proactive defense, for example, HIPS (a way to limit the functionality of programs based on the analysis of their activity). Another factor will be the number of starts of an unknown application by users, i.e. with a large number of launches, we can assume the onset of the so-called viral epidemic. In this case, the antivirus company will need to obtain a copy of the malware as early as possible. Figure 5 shows the algorithm of the utility model when working with unknown files. At step 510, the user tries to run an unknown executable file, and at step 520, the anti-virus system checks this file with all available methods. If the file contains malicious functionality, or vice versa, is in the “white list”, then at step 530, the anti-virus system can enable or disable the launch of the file. If the anti-virus system cannot accurately determine the type of file (whether it is malicious or not), then various proactive protection methods are used, and statistics on the launch of this file by users at step 540 are kept. If the number of launches grows rapidly, this can serve as a signal for the anti-virus company that there is a new malicious program or application (executable file) from the “white list” that should be downloaded at step 550, sent for further analysis at step 560 and make new changes to the antivirus databases system at step 570 using the means of replenishment of databases 770.

Figure 6 shows a scheme for detecting false positives for parental control. At step 610, parental control is triggered (the policy for which was originally developed using the database replenishment tools 770), for example, an attempt was made to go to a site where the words “rifle” and “weapon” were found. However, this may be a situation when a child tried to access the site of children's toys, and there among the goods the words “plastic rifle” and “toy weapon” can be found. If this site is in the list of blocked (verification at step 620), then in this case it will be blocked at step 630. If the site is not in such a list, the child will be allowed to enter the site at step 640, and the data for this site will be sent for analysis at step 650 (i.e., it was a false positive that was detected using the false positive processing tool 750). As a result of the analysis, changes will be made to the parental control policy (for example, the rule to block the words “rifle” and “weapon” has been updated) at step 660 using the 760 false positive correction tool.

In conclusion, it should be noted that the information provided in the description are only examples that do not limit the scope of this utility model defined by the formula. The person skilled in the art will understand that there may be other options for implementing this utility model, consistent with the nature and scope of this utility model.

Claims (6)

1. The anti-virus database update system, which contains an anti-virus protection tool located on the user’s side, which is associated with a corresponding database intended for storing current and test records; means of processing false positives on the user side, which is designed to handle false positives when the anti-virus protection tool works with test records in the corresponding database of the anti-virus protection tool; means of correcting false positives on the server side, which is designed to correct test records received from the means of processing false positives on the user side, in the database of the anti-virus protection on the server side, which is designed to store current and test records; means for updating current and test records in the server-side anti-virus protection database, which is designed to add new current and test entries to the anti-virus protection database; user-side anti-virus protection database update tool that is designed to update current and test user-side anti-virus protection database records by downloading an update for current and test server-side anti-virus protection database records. 2. The system according to claim 1, in which the means of correcting false alarms on the server side after the correction of test records in the database of the anti-virus protection on the server is additionally intended to correct the test records in the database of the anti-virus protection on the user side. 3. The system according to claim 1, in which the antivirus protection is an emulator and a proactive defense module; signature verification module; application control module; parental control module. 4. The system of claim 1, wherein the user-side false positive processing tool further collects information from the user-side anti-virus protection tool event log, which is necessary for the server-side false positive correction tool. 5. The system according to claim 1, in which the means of updating current and test entries in the database of the anti-virus protection tool on the server side are malware detection tools in anti-virus laboratories, as well as human experts. 6. The system according to claim 1, in which databases with current and test records on the user and server side rewrite test records to the current ones, after a specified period of time in the absence of false positives from the means of processing false positives on the user side.