CLOUD-BASED APPLICATION WHITELISTING

• US 20120072725A1
• Filed: 11/28/2011
• Published: 03/22/2012
• Est. Priority Date: 12/03/2004
• Status: Active Grant

• Current Assignee: Fortinet Inc.
• Original Assignee: Fortinet Inc.
• Inventors: Fanton, Andrew F., Gandee, John J., Lutton, William H., Harper, Edwin L., Godwin, Kurt E., Rozga, Anthony A.
• Granted Patent: US 8,195,938 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 verifying 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 verified with reference to a multi-level whitelist including a global whitelist, a local whitelist and the cache. The verification 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 executed if the code module is approved by the multi-level whitelist database architecture.

Claims

1. A computer-implemented method 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.

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 as being free of viruses or malicious code 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 the local whitelist database is associated with a local area network (LAN) and locally accessible by the computer system and one or more other computer systems within the LAN, wherein the local whitelist database is maintained by an information technology (IT) administrator, whereby the IT administrator has the ability to tailor the local whitelist to allow or disallow particular code modules from running on a plurality of computer systems within the LAN, including the computer system.

8. The method of claim 1, wherein said intercepting file system or operating system activity relating to a code module comprises a 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.

9. The method of claim 8, wherein the kernel mode driver is configured for operation within a Microsoft Windows operating system.

10. The method of claim 9, wherein the cryptographic hash value is computed using a Secure Hash Algorithm (SHA).

11. 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.

12. The cloud-based application whitelisting system of claim 11, 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.

13. The cloud-based application whitelisting system of claim 11, wherein the approved code modules are identified as being free of viruses or malicious code by multiple sources.

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

15. The cloud-based application whitelisting system of claim 11, 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.

16. 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.

17. The non-transitory program storage device of claim 16, 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.

18. The non-transitory program storage device of claim 16, wherein the approved code modules are identified as being free of viruses or malicious code by multiple sources.

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

20. The non-transitory program storage device of claim 16, wherein the local whitelist database is associated with a local area network (LAN) and locally accessible by the computer system and one or more other computer systems within the LAN, and wherein the local whitelist database is maintained by an information technology (IT) administrator, whereby the IT administrator has the ability to tailor the local whitelist to allow or disallow particular code modules from running on a plurality of computer systems within the LAN, including the computer system.

21. The non-transitory program storage device of claim 16, wherein said intercepting file system or operating system activity relating to a code module comprises a 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.

22. The non-transitory program storage device of claim 21, wherein the kernel mode driver is configured for operation within a Microsoft Windows operating system.

23. The non-transitory program storage device of claim 22, wherein the cryptographic hash value is computed using a Secure Hash Algorithm (SHA).

24. 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.

25. The method of claim 24, further comprising responsive to a kernel mode driver performing said steps of intercepting 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.

26. The method of claim 25, wherein the kernel mode driver is configured for operation within a Microsoft Windows operating system.

27. The method of claim 24, wherein the cryptographic hash value is computed using a Secure Hash Algorithm (SHA).

28. The method of claim 24, wherein the local whitelist database is associated with a local area network (LAN) and locally accessible by the computer system and one or more other computer systems within the LAN, wherein the local whitelist database is maintained by an information technology (IT) administrator, whereby the IT administrator has the ability to tailor the local whitelist to allow or disallow particular code modules from running on a plurality of computer systems within the LAN, including the computer system.

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

30. 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.

31. The non-transitory program storage device of claim 30, wherein the method further comprises responsive to a 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.

32. The non-transitory program storage device of claim 31, wherein the code module is a shared dynamically-linked library file that is used by multiple programs.

33. The non-transitory program storage device of claim 31, wherein the kernel mode driver is configured for operation within a Microsoft Windows operating system.

34. The non-transitory program storage device of claim 30, wherein the cryptographic hash value is computed using a Secure Hash Algorithm (SHA).

35. The non-transitory program storage device of claim 30, wherein the local whitelist database is associated with a local area network (LAN) and locally accessible by the computer system and one or more other computer systems within the LAN, wherein the local whitelist database is maintained by an information technology (IT) administrator, whereby the IT administrator has the ability to tailor the local whitelist to allow or disallow particular code modules from running on a plurality of computer systems within the LAN, including the computer system.