antimalware
As it’s most popularly understood, malware protection relies upon signature detection. However, detecting malicious software is only one side of the antivirus coin. In fact, some would say detection based on signatures – essentially a form of denylist – is the less significant side of that coin. On the other side there is the allowlist technique, or the pre-approval of harmless software as opposed to the blocking of harmful software.
What is a denylist?
Allow me to explain this through the prism of specific Kaspersky technology: the Kaspersky Security Network (KSN). When users install certain Kaspersky Lab products, they are offered the opportunity to willingly join the KSN. Should they decide to opt-in, they become part of a distributed infrastructure dedicated to processing cybersecurity-related information. If an opted-in user in India becomes infected with a new type of malware, Kaspersky Lab creates a signature to detect that malware, and then adds that signature to its database so that no other Kaspersky user will become infected with that malware.
Simply put, this is how denylists work. We make lists of things that are hurtful, and we keep those things off of your computer. Denylists work great when it’s 99.9 percent effective and there were only 10,000 new malicious families of software emerging each year, but it’s not quite good enough at 99.9 percent effective when there are 10,000,000 new families of malware emerging each year.
What is an allowlist?
Again, I’ll use Kaspersky technology and industry terminology to explain how allowlists work. In this case, we are talking about a process called “Default Deny.” Under this principle, a security product would block all applications and software by default unless they were explicitly allowed. Thus, you have an allowlist of pre-approved applications.
Problematically, this sort of default deny allowlists are primarily used in corporate environments where a central authority can exhibit more control over what users need. It’s relatively easy to say that certain apps are needed for work and all others can be ignored. Furthermore, in a business environment, the list of approved apps is likely to be fairly static over time. On the consumer level, there are some obvious pitfalls, which is to say, it’s hard to know exactly what the consumer will need or want at any given time.
Default Deny Via Trusted Applications
Of course, our researcher friends here at Kaspersky Lab managed to come up with a way to apply the principles of default deny to the consumer crowd with a technology called “Trusted Applications.” In essence, trusted applications represent a dynamically updated allowlist of applications based on a set of trust criteria tested against various data points acquired from the KSN.
#Whitelisting and smooth workflow: do they contradict each other? https://t.co/CzVUzrWSFf
— Eugene Kaspersky (@e_kaspersky) October 10, 2014
In other words, our consumer-ready, dynamic allowlist is an extensive and constantly updated knowledge base of existing applications. The database contains information on about one billion unique files, covering the overwhelming majority of popular applications, such as office packages, browsers, image viewers and nearly everything else you or I could imagine.
Utilizing the input of nearly 450 partners, predominately organizations that develop software, the database minimizes the occurrence of false-positives by knowing about the contents of vendor-implemented updates before they happen.
The Trust Chain
What about the apps we don’t know about? Certain apps and processes spawn new apps and it would be impossible for our allowlist to have a working knowledge of all of these programs. For example, in order to download an update, a program may have to launch a specialized module, which will connect to the software vendor’s server and download a new version of the program. In effect, the update module is a new application created by the original program and there may be no data on it in the database. However, since this application was created and launched by a trusted program, it is regarded as trusted. This mechanism is called the “Trust Chain.”
Similarly, if a new update is downloaded automatically and it is different from the old app in ways the allowlist does not recognize, it can be approved by secondary means, such as verifying its digital signature or certificate. A third failsafe method kicks in if an app unexpectedly changes and is also unsigned. In this case, the trust chain can run the download domain against a list of trusted domains, which generally belong to well-known software vendors. If a domain is trusted, so too is the new app. If a domain is used to distribute malware at any time, it is removed from the trust chain.
Last But Not Least
As you well know, attackers are hip to nearly everything we do on the protection end. In part because of this, they often like to find vulnerabilities in popular programs and exploit them in order to circumvent the very protections described above by having malicious acts originate from trusted programs.
To combat that, our researchers have developed a system known as the “Security Corridor.” The security corridor supplements our dynamic allowlist by making sure that approved software and applications perform only the actions that they are supposed to perform.
“For instance, a browser’s working logic is to display webpages and download files,” explained Andrey Ladikov of Kaspersky Lab’s allowlists and cloud infrastructure research team. “Actions such as changing system files or disk sectors are inherently alien to the browser. A text editor is designed to open and save text documents on a disk, but not to save new applications onto the disk and launch them.” In this way, if your favorite paint application starts using your microphone, the application will be flagged.
Whose Computers are Fortified?
This technology of dynamic allowlists isn’t available for everyone. Only users of Kaspersky Plus and Kaspersky Premium enjoy this level of protection.
Additional Reading
Our researcher friends here have written not one, not two but three more technical articles on the science of allowlists. Follow those links if you’re interested in digging deeper.
