Can an inevitable evil be conquered?

Scanning an object (a file or web resource) with an Internet security program essentially comes down to making a binary decision: dangerous or safe? An antivirus engine puts forward the hypothesis that an object is malicious and then checks whether this is true or not. Since there are, unfortunately, no perfect antivirus solutions, errors can occur. There are two types of error: the first kind is when safe objects are identified as dangerous; the second kind – when dangerous objects are identified as safe. Using the terminology inherited from mathematical statistics, errors of the first kind are called false positives.

Security system developers have varying attitudes towards false positives. Some regard the objective of combating infection as a higher priority. Kaspersky Lab’s position on this is absolutely clear: preventing false positives is as important as protecting against malware. Below, we look at the methods of fighting false positives, using our company as an example.

The negative positive

For the user, a false detection by the security solution means being unable to access a web resource or use a safe program. Regardless of how important a specific file or website is, a false detection is always an annoyance that can lead to a disruption of business processes.

If a program that has just been written by a user is falsely identified as dangerous, its author will send a complaint to the antivirus vendor, analysts will recognize the error and correct it next time the antivirus databases are updated. This usually takes several hours – provided, of course, that the program does not actually do anything beyond what is permissible for legitimate applications.

It is a completely different situation if an operating system component is identified as malicious. This could lead to much more dire consequences, sometimes as grave as system failure. And if this kind of false positive affects a large company, it will inevitably result in downtime and, as a consequence, lost profits. This is why we believe that companies that develop security systems should be very careful about errors of this type and should try to keep them to a minimum.

Reasons for false positives

First of all, it is essential to identify the reasons for such errors. These can vary.

The human factor is one possible reason for a false detection: an antivirus analyst is not immune to making mistakes. It is worth noting, however, that in today’s world instances of this are extremely rare, since nearly all threats (99%) are now detected automatically.

A false positive can occur when developers of legitimate applications use obfuscation (code entanglement) and packing (executable file compression). Cybercriminals often use these methods to make malware analysis more difficult, which is why security systems may suspect such applications of being malicious.

A false positive can be the result of using a generic signature that detects similar malicious objects. We have known for a long time that malicious objects are often variants of the same code. This means that by using more ‘intelligent’ classification methods we can identify a part that is common to all the similar malicious samples and create a single detection logic (i.e. a signature) that will provide detection of all the similar objects. Such generic signatures are created by different detection systems. The broader the criteria used by a system to identify the similar part of malicious objects, the greater the chances of the signature being triggered by a similar but innocuous object.

Finally, an object can be mistakenly identified as malicious by technologies that analyze program behavior. For example, if an unknown application begins to make suspicious changes to the system registry or to send the user’s private data over the network, the component that tracks operating system events should raise an alarm. The program doing this could be quite harmless, just not used very often.

Fighting false positives

Analysts have understood the potential consequences of false positives practically from the inception of the industry. However, both the number of users and the number of Internet threats was thousands of times smaller back then and antivirus databases were released at much longer intervals. This being the case, the methods used 18 years ago to check antivirus databases were fairly uncomplicated: developers had a collection of critical clean files (primarily system files) and the experts simply scanned the collection using the new database before releasing an update. If there was a false positive, the relevant detection was removed after the first complaints were received. That is, the analyst team manually corrected the databases, preventing the threat from reaching a large number of users.

With time, the stream of malware has grown thousands of times, both malicious programs and technologies used to detect malicious objects have become more sophisticated. Kaspersky Lab currently detects 325,000 new malicious objects every day. The range of methods used to combat Internet threats has also broadened: whereas in the nineties signature-based detection methods were quite equal to the task of protecting a computer, now Kaspersky Lab products include technologies that automatically prevent vulnerabilities from being exploited, tools for controlling application privileges, a component that tracks operating system events, and a range of other technologies. In addition, modern legitimate software databases take up terabytes of disk space.

Clearly, in such conditions it is no longer possible to use the archaic methods of fighting false positives. Today’s false positive prevention technologies are much more varied and effective. These methods are used both at the stage of detecting malicious objects and at that of testing and releasing databases. There is also a separate set of methods that help to minimize the chances of false positives appearing while a security product is operating.

Signature control

As Captain Obvious would put it, the easiest way to avoid false positives is to release error-free signatures. This is why special attention is given to the stages in which malicious object signatures are created. But even if an error manifests itself later, there is a way to correct the situation rapidly, even if the databases have already been installed on the user’s machine.

Detection stage (creating static signatures)

First, a dedicated automatic verification system analyzes the static signatures manually added to the databases by virus analysts. This is because a person, concentrating on closely analyzing code, may not see the complete picture. So, when somebody tries to add a signature to the database for an object that the system perceives as clean based on certain criteria, the automatic system reports the potential error to the analyst, together with the reasons for believing the object is clean.

Second, a collection of hashes (unique results of code transformation based on a specific algorithm) for objects known to be ‘clean’ is used to test new signatures for false positives. A signature created using a fragment of malicious code is matched against hashes from the collection. If the system detects that the new signature matches a legitimate object’s hash based on some criteria, a different code fragment is selected to create a signature for the threat.

Kaspersky Lab also keeps a separate database that contains the ‘personal record’ of each malicious object ever analyzed with protection technologies. When creating a detection, the past of a detected object is taken into account: if the object did not raise any suspicion in the past, it undergoes an additional check.

Additionally, a collection of files that have triggered false detections in the past is used for protection against errors. It helps to prevent incidents from occurring again if an object has been slightly modified (e.g. when a new version of a program is released).

Generic signatures are periodically added to static signature databases: if the automatic detection system registers lots of similar malware samples, a single detection logic is created to combat them.

Database testing and release stage

To ensure that signatures (static or generic) will not be triggered by ‘clean’ software, newly created databases are verified using the Dynamic Allowlist knowledge base. It is an enormous, continually expanding collection of legitimate software that also contains additional data on each object (developer, product name, the latest update version and much more). More detailed information on Dynamic Allowlist operation can be found here.

A special department at Kaspersky Lab is in charge of maintaining this collection and providing timely updates. Thanks to agreements signed with more than six hundred software development companies, most popular applications are included in the collection before they become commercially available to a broad user audience.

The system that performs the scanning deserves a separate mention. Since the legitimate software database is enormous and antivirus databases are updated once an hour, using a regular server to do the scanning is not an option. A distributed data processing system was developed specifically for this purpose. It uses dozens of servers and data storage facilities for load balancing.

All signatures that have raised even minor suspicions are entered into a separate register that can be called ‘potentially dangerous verdicts’. Such signatures undergo additional verification, often involving malware analysts.

Rapid response (fighting false positives at the operation stage)

When antivirus databases have passed all the necessary checks, they are distributed to users. The Kaspersky Security Network distributed cloud infrastructure receives statistics on any detections on user machines and tracks how many times each signature has been triggered.

Analysts responsible for releasing signature databases continue to carefully track how products respond to updates. If an anomaly is detected (a threat has been detected on too many user machines within a short time period), this could mean there is a false positive. In that case, an analyst receives an alert and begins to perform additional analysis of the detected object.

If analysis indicates that the object was identified as malicious by mistake, the Record Management System technology is triggered. It can recall a record in a matter of seconds, also using the Kaspersky Security Network. The incorrect signature is removed from databases, as well. If it turns out that a generic signature mistakenly detects ‘clean’ objects among others, analysts change the detection logic and correct the databases. In any case, by the next database update, the error will have been corrected.

Tracking proactive technology errors

At the development stage it is not so easy to check technologies that detect anomalous program behavior on user machines for false positives. Foreseeing all possible actions by the user on the machine and all the possible variants of ‘clean’ software that might be used in the process is virtually impossible. That is why it is primarily cloud technologies that protect users from false detections caused by proactive technologies.

When a product detects an unknown object – i.e. there is no information about it in local antivirus databases – the object’s hash is immediately sent to the cloud infrastructure, which responds with any available information in a split second. If the object is on the allowlist of trusted software, the object is recognized as safe.

In addition, cloud technologies can verify a suspicious file’s digital signature and the reputation of the company that issued the digital signature certificate. If the reputation is faultless and the certificate is genuine, this also indicates that the object is legitimate. It is worth noting that company reputation and signature data is not static. If incidents are reported, this may result in the loss of trust, leading to a change in the security solution’s response to the same files.

Proactive detection tools require particularly close attention when product functionality is being upgraded. When newly upgraded technologies start working in the field for the first time after lab testing, unforeseen errors may arise. This is why a phased approach is used instead of activating new protection mechanisms in all products at once. First, upgrades are supplied to a limited test group. If this does not result in false positives, the new features are made available to a broader user group. As a result, even if a new technology proves faulty, most users will never be aware of the fault.

Fighting false positives when scanning web resources

It is worth adding a few words about technologies that protect against false positives when scanning web resources. Kaspersky Security Network can track a resource’s reputation history. If malicious content is detected on one of the site’s pages, whether the site will be blocked completely or partially depends on its reputation. If the site has an impeccable reputation, Kaspersky Lab solutions will only block the page that poses a threat to users rather than the entire website.

Kaspersky Security Network also tracks the history of web resource hits. If a site that is popular with users is identified as dangerous, the automatic system will alert analysts, who will do an additional check. This helps to prevent false detections of popular resources.

Conclusion

False detections by security products are unavoidable – there are no ideal solutions. However, it is the objective of vendors to reduce them to a minimum. This is a feasible task.

Kaspersky Lab experts carefully monitor the operation of protection technologies to prevent them from making errors. For each type of object in which a threat can potentially be found (web pages, files, banners, boot sectors, traffic streams, etc.), there are special mechanisms designed to prevent false positives and separate collections of objects known to be clean.

Kaspersky Lab has a dedicated group responsible for improving existing methods of fighting false positives and developing new ones. It investigates each case, analyzes why a false detection occurred and creates tools that help to prevent similar errors in the future.

It is largely thanks to the efforts of this group that virtually no false positives have come up lately in tests of Kaspersky Lab products carried out by independent researchers.