Policy-based whitelisting with system change management based on trust framework
View Patent ↗Techniques allow runtime extensions to a whitelist that locks down a computational system. For example, executable code is not only subject to whitelist checks that allow (or deny) its execution, but is also subject to checks that determine whether a whitelisted executable is itself trusted to introduce further executable code into the computational system in which it is allowed to run. In general, deletion and/or modification of instances of code that are already covered by the whitelist are also disallowed in accordance with a security policy. Accordingly, an executable that is trusted may be allowed to delete and/or modify code instances covered by the whitelist. In general, trust may be coded for a given code instance that seeks to introduce, remove or modify code.
1. A method of managing a whitelist that at least partially governs operation of a computational system, the method comprising:
providing a computer readable encoding of the whitelist, wherein the whitelist identifies (i) instances of code that are allowed to execute on the computational system and (ii) trust attributes therefor, wherein at least one of the trust attributes indicates, for a trusted one of the code instances, that a further code instance introduced into the computational system based on execution of the trusted code instance is to be added to the whitelist and thereby allowed to execute;
responsive to execution of a first code instance that at least initiates introduction of an executable second code instance into the computational system, checking a whitelist entry that corresponds to the first code instance and, based thereon, extending the whitelist to allow execution of the second code instance only if the whitelist entry includes a trust attribute; and
executing on the computational system only those code instances allowed by the whitelist;
wherein relative to the first code instance and the second code instance, the extending the whitelist comprises adding an entry comprising:
a size of a file from which the second code instance may be loaded into memory and executed;
a name of the file or a path thereto; and
a hash, a digital signature, authentication code, checksum, fingerprint or other cryptographic digest usable to verify integrity of the file.
2. The method of claim 1 ,
wherein the whitelist identifies individual ones of the code instances and trust attributes therefor by correspondence with respective files in a file system.
3. The method of claim 1 , wherein relative to the first code instance, the whitelist encodes:
a size of a first file in a file-system from which the first code instance is loaded into memory and executed;
a name of the first file; and
a hash, a digital signature, authentication code, checksum, fingerprint or other cryptographic digest that verifies integrity of the first file.
4. The method of claim 3 , wherein relative to the first code instance, the whitelist further encodes:
a path to the first file, wherein the path is specified with or without wildcards.
5. The method of claim 1 , wherein relative to the first code instance, the whitelist comprises an entry including:
a full path to a first file, specified with or without wildcards.
6. The method of claim 3 , wherein the whitelist encodes one or more additional attributes selected from a set thereof that when individually set/cleared, direct a kernel resident security feature to:
allow/disallow read access to the first file;
allow/disallow overwriting of the first file;
allow/disallow loading of the first file into memory and execution thereof; and
allow/disallow deletion of the first file from the file-system.
7. The method of claim 3 ,
wherein existence of a whitelist entry corresponding to the first code instance constitutes an allow-type execution entry therefor.
8. The method of claim 3 ,
wherein attributes including the trust attribute are encoded independent of file-system permissions.
9. The method of claim 1 , further comprising:
interposing on file system operations and, as a condition precedent to execution of any particular code instance, determining that a corresponding allow-type entry appears in the whitelist.
10. The method of claim 9 , wherein the interposing on file system operations includes one or more of:
hooking file system calls;
hooking a function pointer table in an operating system kernel; and
interposing a file filter driver.
11. The method of claim 1 , further comprising:
maintaining in correspondence with call sequences of code executing on the computational system, a data structure that encodes for a given process, correspondence back to an operative entry of the whitelist.
12. The method of claim 11 , further comprising:
interposing on a write-type operation performed by either the first code instance or a third code instance executed based on a call sequence traceable to the first code instance; and
as a condition precedent to allowing the interposed upon write-type operation to introduce into the computational system an executable file loadable as the second code instance, checking to ensure that a corresponding trust attribute so allows.
13. The method of claim 11 ,
wherein the trust attribute conveys effective trust for changes to a third code instance executed based on a call sequence traceable to the first code instance if each code instance along the call sequence has a corresponding allow-type entry in the whitelist.
14. A system of selectively allowing and disallowing changes in a computational system, the system comprising:
memory;
a processor; and
a kernel-resident client, stored in the memory, that, responsive to code execution, by the processor, for a first code instance on an endpoint that seeks to modify a protected state of the endpoint, initiates a trusted change policy check of a whitelist for an allow-type entry that corresponds to the code execution, wherein the whitelist identifies trust attributes for instances of code that are allowed to execute on the computational system, and wherein at least one of the trust attributes indicates, for a trusted one of the code instances, that a further code instance introduced into the computational system based on execution of the trusted code instance is to be added to the whitelist and thereby allowed to execute,
wherein, if the allow-type entry includes a trust attribute, the kernel-resident client allows the code execution to proceed with the modification of the protected state and at least provisionally extending a current security policy that governs operation of the computational system to allow operation consistent with the modification, and wherein the kernel-resident client otherwise disallows the code execution by the processor and thereby blocks the modification,
wherein based on the allow-type entry including the trust attribute, the whitelist is extended to allow execution of a second code instance, wherein relative to the first code instance and the second code instance, the extending the whitelist comprises adding an entry comprising: (i) a size of a file from which the second code instance may be loaded into memory and executed, (ii) a name of the file or a path thereto, and (iii) a hash, a digital signature, authentication code, checksum, fingerprint or other cryptographic digest usable to verify integrity of the file.
15. The system of claim 14 , further comprising:
a security manager configured to receive an encoding of the at least provisionally-made extension for one or more of logging, review, approval and reversal.
16. The system of claim 14 ,
wherein the security manager is hosted on a secured computational system.
17. The system of claim 14 ,
wherein the security manager is configured as a network appliance, and
wherein the kernel-resident client is embodied as code installed to the endpoint from the network appliance.