CLOUD-BASED APPLICATION WHITELISTING

• US 20110029772A1
• Filed: 10/15/2010
• Published: 02/03/2011
• Est. Priority Date: 12/03/2004
• Status: Active Grant

• Current Assignee: Fortinet Inc.
• Original Assignee: WhiteCell Software Incorporated
• Inventors: Harper, Edwin L., Godwin, Kurt E., Rozga, Anthony A., Fanton, Andrew F., Gandee, John J., Lutton, William H.
• Granted Patent: US 8,069,487 B2
• Time in Patent Office: Days
• US Class Current: 713/165
• CPC Class Codes: G06F 21/10 Protecting distributed programs or content, e.g. vending or licensing of copyrighted material protection in video systems or pay television H04N7/16 ; Digital rights management [DRM]
• CPC Class Codes: G06F 21/44 Program or device authentication
• CPC Class Codes: G06F 21/51 at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
• CPC Class Codes: G06F 21/52 during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
• CPC Class Codes: G06F 21/53 by executing in a restricted environment, e.g. sandbox or secure virtual machine
• CPC Class Codes: G06F 21/602 Providing cryptographic facilities or services
• CPC Class Codes: G06F 2221/033 Test or assess software
• CPC Class Codes: G06F 2221/2141 Access rights, e.g. capability lists, access control lists, access tables, access matrices
• CPC Class Codes: G06F 9/445 Program loading or initiating bootstrapping G06F9/4401; security arrangements for program loading or initiating G06F21/57
• CPC Class Codes: H04L 63/08 for authentication of entities cryptographic mechanisms or cryptographic arrangements for entity authentication H04L9/32
• CPC Class Codes: H04L 63/0884 by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
• CPC Class Codes: H04L 63/10 for controlling access to devices or network resources
• CPC Class Codes: H04L 63/145 the attack involving the propagation of malware through the network, e.g. viruses, trojans or worms
• CPC Class Codes: H04L 9/0643 Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
• CPC Class Codes: H04L 9/32 including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
• CPC Class Codes: H04L 9/3239 involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
• CPC Class Codes: Y10S 707/99934 Query formulation, input preparation, or translation
• CPC Class Codes: Y10S 707/99943 Generating database or data structure, e.g. via user interface
• CPC Class Codes: Y10S 707/99944 Object-oriented database structure

Abstract

Systems and methods for allowing authorized code to execute on a computer system are provided. According to one embodiment, an in-memory cache is maintained having entries containing execution authorization information regarding recently used modules. After authenticating a module, its execution authorization information is added to the cache. Activity relating to a module is intercepted. A hash value of the module is generated. The module is authenticated with reference to a multi-level whitelist including a global whitelist, a local whitelist and the cache. The authentication includes first consulting the cache and if the module is not found, then looking up its hash value in the local whitelist and if it is not found, then looking it up in the global whitelist. Finally, the module is allowed to be loaded and executed if its hash value matches a hash value of an approved code modules within the global whitelist.

Claims

1. A computer-implemented method comprising:

creating and maintaining, by a kernel mode driver executing on a computer system, 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 unauthorized code module to an entry of the plurality of entries;

intercepting, by the kernel mode driver, file system or operating system activity relating to a code module;

generating, by the kernel mode driver, a cryptographic hash value of the code module;

determining, by the kernel mode driver, if the code module is authorized to be loaded and executed within the computer system by causing the code module to be authenticated with reference to 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 known 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 code module to be authenticated includes 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 generated cryptographic hash value in the local whitelist database and if the generated cryptographic hash value is not found within the local whitelist database, then looking up the generated cryptographic hash value in the global whitelist database;

allowing the code module to be loaded and executed within the computer system if the cryptographic hash value matches one of the cryptographic hash values of approved code modules within the global whitelist database by causing processing relating to the file system or operating system activity relating to the code module to proceed; and

wherein the kernel mode driver is implemented in one or more processors 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 processors.

2. The method of claim 1, wherein the approved code modules include code modules associated with common operating system software, operating system services, and common utilities, including word processors and internet browsers.

3. The method of claim 1, wherein the approved code modules are identified by multiple sources.

4. The method of claim 1, wherein the code module comprises an executable object.

5. The method of claim 1, wherein the code module comprises a file system object.

6. The method of claim 1, wherein the code module comprises a script file.

7. The method of claim 1, wherein said intercepting, by the kernel mode driver, file system or operating system activity relating to a code module comprises the kernel mode driver hooking low-level operating system application programming interfaces (APIs) to intercept one or more operating system or file system operations of interest including one or more of process creation, module loading, and file system input/output activity.

8. 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 authenticating 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 known 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 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 to be loaded and executed within the computer system by causing the code module to be authenticated 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 generated cryptographic hash value in the local whitelist database and if the generated cryptographic hash value is not found within the local whitelist database, then looking up the generated cryptographic hash value in the global whitelist database; and

allowing the code module to be loaded and executed within the computer system if the cryptographic hash value matches one of the cryptographic hash values of approved code modules within the global whitelist database by causing processing relating to the file system or operating system activity relating to the code module to proceed.

9. The cloud-based application whitelisting system of claim 8, wherein the approved code modules include code modules associated with common operating system software, operating system services, and common utilities, including word processors and internet browsers.

10. The cloud-based application whitelisting system of claim 8, wherein the approved code modules are identified by multiple sources.

11. The cloud-based application whitelisting system of claim 8, wherein the code module comprises an executable object, a file system object or a script file.

12. The cloud-based application whitelisting system of claim 8, wherein said intercepting file system or operating system activity relating to a code module comprises the kernel mode driver hooking low-level operating system application programming interfaces (APIs) to intercept one or more operating system or file system operations of interest including one or more of process creation, module loading, and file system input/output activity.

13. A 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 authenticating 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 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 to be loaded and executed within the computer system by causing the code module to be authenticated with reference to 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 known 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 code module to be authenticated includes 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 generated cryptographic hash value in the local whitelist database and if the generated cryptographic hash value is not found within the local whitelist database, then looking up the generated cryptographic hash value in the global whitelist database; and

allowing the code module to be loaded and executed within the computer system if the cryptographic hash value matches one of the cryptographic hash values of approved code modules within the global whitelist database by causing processing relating to the file system or operating system activity relating to the code module to proceed; and

14. The program storage device of claim 13, wherein the approved code modules include code modules associated with common operating system software, operating system services, and common utilities, including word processors and internet browsers.

15. The program storage device of claim 13, wherein the approved code modules are identified by multiple sources.

16. The program storage device of claim 13, wherein the code module comprises an executable object, a file system object or a script file.

17. The program storage device of claim 13, wherein said intercepting file system or operating system activity relating to a code module comprises the kernel mode driver hooking low-level operating system application programming interfaces (APIs) to intercept one or more operating system or file system operations of interest including one or more of process creation, module loading, and file system input/output activity.

18. A computer-implemented method comprising:

intercepting, by a kernel mode driver of the computer system, a first file system or operating system activity relating to a code module;

responsive to determining, by the kernel mode driver, 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 authenticated by the kernel mode driver,

calculating, by the kernel mode driver, a cryptographic hash value of the code module; and

determining if the code module is authorized to be loaded and executed within the computer system by causing the code module to be authenticated with reference to one or both of a global whitelist database and a local whitelist database based on the calculated 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 known 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 causing the code module to be loaded and executed within the computer system by allowing 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; and

intercepting, by the kernel mode driver, 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, by the kernel mode driver, of the cryptographic hash value of the code module; and

determining whether the code module is authorized to be loaded and executed within 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; and

wherein the kernel mode driver is implemented in one or more processors 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 processors.

19. The method of claim 18 further comprising responsive to the kernel mode driver observing a potential modification of the code module, causing subsequent process creation requests relating to the code module to require re-authentication of the code module with reference to the global whitelist or the local whitelist by removing or invalidating the entry of the in-memory cache containing execution authorization information regarding the code module.

20. The method of claim 19, wherein the code module is a shared dynamically-linked library file that is used by multiple programs.