Cloud-based application whitelisting

A cloud-based application whitelisting system comprising

• a kernel mode driver of a computer system implemented in one or more computer processors of the computer system and one or more computer-readable storage media associated with the computer system, the one or more computer-readable storage media having instructions tangibly embodied therein representing the kernel mode driver that are executable by the one or more computer processors, the kernel mode driver operable to perform a method of verifying code modules prior to allowing the code modules to be executed by the computer system;
• and
• a multi-level whitelist database architecture including a global whitelist database, a local whitelist database and an in-memory cache, the global whitelist database stored remote from the computer system, maintained by a trusted third party service provider and containing cryptographic hash values of approved code modules, which are presumed not to contain viruses or malicious code, the local whitelist database created based on the global whitelist, stored local to the computer system and containing at least a subset of the cryptographic hash values contained in the global whitelist database;
• and
• wherein said method comprises:
• creating and maintaining the in-memory cache, the in-memory cache including a plurality of entries each of which contain execution authorization information regarding one of a plurality of code modules that have been most recently used by the computer system, said maintaining including adding execution authorization information regarding a newly identified authorized code module or a newly identified unauthorized code module to an entry of the plurality of entries;
• intercepting file system or operating system activity relating to a code module;
• generating a cryptographic hash value of the code module;
• determining if the code module is authorized for execution by the computer system by causing the cryptographic hash value or the code module to be verified with reference to the multi-level whitelist database architecture by first consulting the in-memory cache and if execution authorization information for the code module is not present within the in-memory cache, then looking up the cryptographic hash value in the local whitelist database and if the cryptographic hash value is not found within the local whitelist database, then looking up the cryptographic hash value in the global whitelist database;
• and
• causing the code module to be executed by the computer system by allowing processing relating to the file system or operating system activity relating to the code module to proceed if:
• the execution authorization information is present within the in-memory cache and indicates the code module is approved for execution;
• the cryptographic hash value matches one of the cryptographic hash values of approved code modules within the local whitelist database;
• or
• the cryptographic hash value matches one of the cryptographic hash values of approved code modules within the global whitelist database.

A non-transitory program storage device readable by a computer system, tangibly embodying a program of instructions executable by one or more computer processors of the computer system to perform method steps for verifying code modules prior to allowing the code modules to be executed by the computer system comprising:

• creating and maintaining an in-memory cache including a plurality of entries each of which contain execution authorization information regarding one of a plurality of code modules that have been most recently used by the computer system, said maintaining including adding execution authorization information regarding a newly identified authorized code module or a newly identified unauthorized code module to an entry of the plurality of entries;
• intercepting file system or operating system activity relating to a code module;
• generating a cryptographic hash value of the code module;
• determining if the code module is authorized for execution by the computer system by causing the cryptographic hash value or the code module to be checked against a multi-level whitelist database architecture, the multi-level whitelist database architecture including a global whitelist database, a local whitelist database and the in-memory cache;
• wherein the global whitelist database is stored remote from the computer system, maintained by a trusted third party service provider and contains cryptographic hash values of approved code modules, which are presumed not to contain viruses or malicious code;
• wherein the local whitelist database is created based on the global whitelist, stored local to the computer system and contains at least a subset of the cryptographic hash values contained in the global whitelist database;
• wherein said causing the cryptographic hash value or the code module to be checked includes first consulting the in-memory cache and if execution authorization information associated the code module is not present within the in-memory cache, then looking up the cryptographic hash value in the local whitelist database and if the cryptographic hash value is not found within the local whitelist database, then looking up the cryptographic hash value in the global whitelist database;
• and
• causing the code module to be executed by the computer system by allowing processing relating to the file system or operating system activity relating to the code module to proceed if:
• the execution authorization information is present within the in-memory cache and indicates the code module is approved for execution;
• the cryptographic hash value matches one of the cryptographic hash values of approved code modules within the local whitelist database;
• or
• the cryptographic hash value matches one of the cryptographic hash values of approved code modules within the global whitelist database.

A computer-implemented method comprising:

• intercepting a first file system or operating system activity relating to a code module;
• responsive to determining the code module is not represented within an in-memory cache, which includes a plurality of entries each of which contain execution authorization information regarding one of a plurality of code modules that have been previously verified,
• calculating a cryptographic hash value of the code module;
• and
• determining if the code module is authorized to be executed by the computer system by causing the code module to be verified with reference to one or both of a global whitelist database and a local whitelist database based on the cryptographic hash value, wherein the global whitelist database is stored remote from the computer system, maintained by a trusted third party service provider and contains cryptographic hash values of approved code modules, which are presumed not to contain viruses or malicious code and wherein the local whitelist database is created based on the global whitelist, stored local to the computer system and contains at least a subset of the cryptographic hash values contained in the global whitelist database;
• if said determining if the code module is authorized results in an affirmative determination, then allowing the code module to be executed by the computer system by causing processing relating to the file system or operating system activity relating to the code module to proceed;
• if said determining if the code module is authorized results in a negative determination, then preventing the code module from being loaded and executed within the computer system by causing further processing relating to the file system or operating system activity relating to the code module to stop;
• adding appropriate execution authorization information regarding the code module to an entry of the plurality of entries of the in-memory cache;
• intercepting a second file system or operating system activity relating to the code module;
• and
• responsive to locating the entry of the in-memory cache containing execution authorization information regarding the code module,
• foregoing re-calculation of the cryptographic hash value of the code module;
• and
• determining whether the code module is authorized to be executed by the computer system based upon the execution authorization information regarding the code module stored in the in-memory cache responsive to intercepting the first file system or operating system activity relating to the code module.

A non-transitory program storage device readable by a computer system, tangibly embodying a program of instructions executable by one or more computer processors of the computer system to perform a method of authenticating code modules prior to allowing the code modules to be executed by the computer system, the method comprising:

• intercepting a first file system or operating system activity relating to a code module;
• responsive to determining the code module is not represented within an in-memory cache, which includes a plurality of entries each of which contain execution authorization information regarding one of a plurality of code modules that have been previously verified,
• calculating a cryptographic hash value of the code module;
• and
• determining if the code module is authorized to be executed by the computer system by causing the code module to be verified with reference to one or both of a global whitelist database and a local whitelist database based on the cryptographic hash value, wherein the global whitelist database is stored remote from the computer system, maintained by a trusted third party service provider and contains cryptographic hash values of approved code modules, which are presumed not to contain viruses or malicious code and wherein the local whitelist database is created based on the global whitelist, stored local to the computer system and contains at least a subset of the cryptographic hash values contained in the global whitelist database;
• if said determining if the code module is authorized results in an affirmative determination, then allowing the code module to be executed by the computer system by causing processing relating to the file system or operating system activity relating to the code module to proceed;
• if said determining if the code module is authorized results in a negative determination, then preventing the code module from being loaded and executed within the computer system by causing further processing relating to the file system or operating system activity relating to the code module to stop;
• adding appropriate execution authorization information regarding the code module to an entry of the plurality of entries of the in-memory cache;
• intercepting a second file system or operating system activity relating to the code module;
• and
• responsive to locating the entry of the in-memory cache containing execution authorization information regarding the code module,
• foregoing re-calculation of the cryptographic hash value of the code module;
• and
• determining whether the code module is authorized to be executed by the computer system based upon the execution authorization information regarding the code module stored in the in-memory cache responsive to intercepting the first file system or operating system activity relating to the code module.