JP2025504756A - SYSTEM AND METHOD FOR GENERATING TRUSTED BINARIES - Patent application - Google Patents

Abstract

Various implementations described herein include methods and devices for creating and using trusted binaries. In one aspect, the method includes obtaining executable code for a program, identifying a plurality of executable functions from the executable code, and for each executable function of the plurality of executable functions, generating a respective function digest based on one or more static components of the respective executable function. The method further includes building a respective trusted binary for each executable function of the plurality of executable functions that includes the respective digest, generating a trusted binary name by applying a hash function to a header of the executable code, and indexing the trusted binary in a trust database using the trusted binary name.
[Selected Figure] Figure 1

Description

CROSS-REFERENCE TO RELATED APPLICATIONS This application is (1) a continuation of U.S. patent application Ser. No. 17/684,363, filed March 1, 2022, entitled “SYSTEMS AND METHODS FOR GENERATING TRUST BINARIES,” (2) a continuation of U.S. patent application Ser. No. 17/688,878, filed March 7, 2022, entitled “SYSTEMS AND METHODS FOR IMPLEMENTING CYBERSECURITY USING TRUST BINARIES,” and (3) a continuation of U.S. patent application Ser. No. 17/688,878, filed March 7, 2022, entitled “ATA STRUCTURE FOR TRUST BINARIES.” No. 17/735,087, filed May 2, 2022, entitled "SYSTEMS AND METHODS FOR IMPLEMENTING CYBERSECURITY USING BLOCKCHAIN VALIDATION," each of which is incorporated herein by reference in its entirety.

The disclosed implementations relate generally to cybersecurity, and more specifically to systems and methods that use trusted binaries to implement cybersecurity.

Cybersecurity, the practice of protecting systems and networks from digital attacks, has become increasingly important in the digital age. Digital attacks are becoming increasingly sophisticated, rendering traditional endpoint detection and response (EDR) solutions less effective. Many traditional EDR solutions are designed to detect and stop known attacks. However, there can be a significant delay (e.g., days, weeks, or months) between the time a new attack is deployed and the time the EDR solution is updated to detect and stop the attack. Furthermore, malware is becoming increasingly diverse and continually changing its behavior patterns. This polymorphism further increases the response time of traditional EDR solutions.

The Zero Trust (ZT) system of the present disclosure protects a computer from unknown, malicious code. To execute code, it must first be loaded into memory. As an example, the ZT system has a trust agent (e.g., an OS-specific trust agent) that monitors each program as it is loaded into memory and validates the program's code. The validation procedure in this example uses a trust binary, which is a substitute digital version of the original code. To execute code in this example, the ZT system needs a corresponding trust binary for the code. If the trust binary is missing or uncorrelated, in this example, the code is not allowed to execute on the system.

According to some implementations, trusted binaries are used by the ZT system to verify that executable code has not been tampered with prior to its execution. For example, trusted binaries are created for executable files (e.g., executable programs) by first identifying the code segments of the file. The code segments are then scanned to identify executable functions within each. In this example, for each identified function, a function digest is created based on the start address of the function and its static components. The function digests of the identified functions are combined into a trusted binary for the file. In this example, a trusted binary name is generated by hashing the header of the file, and the trusted binary is added to a trust database (e.g., a trust store) indexed by the trusted binary name.

According to some implementations, a trusted binary is used to protect all executing code in memory on the protected device. For example, ZT protection is implemented as a kernel agent (e.g., a kernel-level device driver). In this example, the kernel agent runs in ring-0 on the protected device, and application code runs in ring-3. An exemplary ZT protection procedure includes loading the kernel agent, which loads its trusted binary from a trusted database and verifies that the code in memory matches the trusted binary (e.g., has not been tampered with). In this example, the agent performs spot validity verification during execution when the code attempts to perform certain system-level operations, such as file I/O operations, registry I/O operations, thread start and stop operations, image load and unload operations, etc. Additional countermeasures can also be employed to protect against a wide range of attacks, as described in more detail below. In this example, if the code does not match the trusted binary or if one of the countermeasures detects an attack, either the process is stopped and forensics are captured, or the process is allowed to continue but forensics are captured (e.g., based on device policy).

In various circumstances, the ZT system of the present disclosure has the following advantages over conventional cybersecurity systems. First, according to some implementations, the ZT system is effective against new and emerging threats because the system blocks all untrusted binary files and therefore there is no vulnerability period while the threat is identified. Second, according to some implementations, the ZT system has high efficacy when identifying untrusted binaries because it does not rely on past trends and has no false negatives. Third, according to some implementations, the ZT system monitors memory, thus protecting against attacks that are initiated in memory via legitimate processes and applications. Fourth, the ZT system can operate on off-network (e.g., air-gapped) systems because it can maintain and validate its trust store without requiring network access.

According to some implementations, a method is performed on a computing device having a memory and one or more processors. The method includes: (i) obtaining executable code of a program; (ii) identifying a plurality of executable functions from the executable code; (iii) generating, for each executable function of the plurality of executable functions, a respective function digest based on one or more static components of the respective executable function; (iv) constructing a respective trusted binary including the respective digest for each executable function of the plurality of executable functions; (v) generating a trusted binary name by applying a hash function to a header of the executable code; and (vi) indexing the trusted binary in a trust database using the trusted binary name.

According to some implementations, a method is performed on a computing device having a memory and one or more processors. The method includes: (i) executing a trust agent; (ii) detecting future execution of a program on the computing device via the trust agent; (iii) responsive to the detection, retrieving a trusted binary for the program from a trust store in memory; (iv) verifying authenticity of the program by comparing executable code of the program with the retrieved trusted binary for the program; (v) allowing execution of the program in accordance with the verified authenticity of the program; (vi) identifying future execution of an executable function in the program by monitoring the execution of the program; (vii) in response to identifying future execution of the executable function, retrieving a function digest corresponding to the executable function from the trusted binary; (viii) verifying authenticity of the executable function by comparing executable code of the executable function with the retrieved function digest; and (ix) allowing execution of the executable function in accordance with the verified authenticity of the executable function.

According to some implementations, a computer-readable storage medium includes a trust database that stores a plurality of trusted binaries, each trusted binary corresponding to a respective executable program. Each trusted binary of the plurality of trusted binaries includes (i) a respective trusted binary name generated by applying a hash function to a respective header of the respective executable program, and (ii) a respective function digest for each executable function identified within the respective executable program, the respective function digest being generated based on a respective starting address and one or more respective static components of the respective executable function. The plurality of trusted binaries are indexed into the trust database using their respective trusted binary names.

According to some implementations, a method is executed on a computing device having a memory and one or more processors. The method includes: (i) accessing a trust store for the computing device, including obtaining a blockchain for the trust store; (ii) identifying a first change to the trust store; (iii) in response to identifying the first change, generating a first block including a first encrypted digest for the first change and inserting the first block into the blockchain; (iv) identifying a second change to the trust store; and (v) in response to identifying the second change, generating a second block including a second encrypted digest for the second change and the first encrypted digest and inserting the second block into the blockchain.

In some implementations, a computing device includes one or more processors, a memory, a display, and one or more programs stored in the memory. The programs are configured for execution by the one or more processors. The one or more programs include instructions for performing any of the methods described herein.

In some implementations, a non-transitory computer-readable storage medium stores one or more programs configured for execution by a computing device having one or more processors, a memory, and a display. The one or more programs include instructions for performing any of the methods described herein.

Accordingly, methods and systems for creating and using trust binaries and blockchains for cybersecurity are disclosed. Such methods and systems may complement or replace conventional methods and systems of cybersecurity.

For a better understanding of the aforementioned systems, methods, and graphical user interfaces, as well as additional systems, methods, and graphical user interfaces providing data visualization analysis, reference is made to the following description of the embodiments, in which like reference numerals refer to corresponding parts throughout the drawings.

1 illustrates an example network architecture, according to some implementations. 1 illustrates an example executable file according to some implementations. 1 illustrates an example executable file according to some implementations. FIG. 1 is a block diagram of an exemplary computing device, according to some implementations. FIG. 2 is a block diagram of an example trust store, according to some implementations. FIG. 1 is a block diagram of an example blockchain, according to some implementations. 1 illustrates an example trusted binary use case, according to some implementations. 1 illustrates an example trusted binary use case, according to some implementations. 1 illustrates an example network architecture, according to some implementations. 1 provides a flowchart of an example process for creating a trusted binary, according to some implementations. 1 provides a flowchart of an example process for creating a trusted binary, according to some implementations. 1 provides a flowchart of an example process for using trusted binaries, according to some implementations. 1 provides a flowchart of an example process for using trusted binaries, according to some implementations. 1 provides a flowchart of an example process for using trusted binaries, according to some implementations. 1 provides a flowchart of an example process for using trusted binaries, according to some implementations. 1 provides a flowchart of an example process for using blockchain validity authentication, according to some implementations. 1 provides a flowchart of an example process for using blockchain validity authentication, according to some implementations.

Reference will now be made to embodiments, examples of which are illustrated in the accompanying drawings. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced without the need for these specific details.

The zero trust (ZT) system of the present disclosure allows known good operating systems and application processes to run in memory and prevents anything else from running. According to some implementations, the zero trust system includes a trust agent installed on a computing device (sometimes called an endpoint). The trust agent monitors and intercepts memory operations. The trust agent validates applications, processes, and functions before allowing them to run. Invalid applications, processes, and functions are blocked or monitored by the trust agent (e.g., depending on the security policy for the computing device). In some implementations, the ZT system utilizes a blockchain identity proof scheme to validate its storage of known good binaries and functions. The ZT system may complement or replace traditional endpoint detection and response (EDR) solutions that handle known bad operating systems and application processes.

FIG. 1 illustrates a network architecture 100 according to some implementations. The network architecture 100 includes an information technology (IT) portion 102 and an operational technology (OT) portion 110 communicatively coupled via a gateway device 108. The IT portion 102 includes user devices 104 (104-1, 104-2, and 104-3) and a hub device 106. In some implementations, each user device 104 includes a trust agent. In some implementations, the hub device 106 includes a trust store or trust center. In some implementations, the hub device 106 includes management software for managing trust binaries and/or trust policies of the user devices 104. The OT portion 110 includes an audit terminal 118, a user terminal 112, a server 114, and a device 116. In some implementations, the audit terminal 118, the user terminal 112, the server 114, and the device 116 each include a trust agent. In some implementations, the audit terminal 118 includes software for managing trust binaries and/or trust policies of the user terminal 112, the server 114, and the device 116. In some implementations, the gateway device 108 provides a demilitarized zone (DMZ) between the IT portion 102 and the OT portion 110. In some implementations, the gateway device 108 includes a trust center or trust store for the IT portion 102 and/or the OT portion 110. In some implementations, the gateway device 108 provides network access to an application store for the IT portion 102 and/or the OT portion 110. In some implementations, the network architecture 100 implements the Purdue Enterprise Reference Architecture (PERA) model. With respect to the PERA model, the IT portion 102 represents levels 4 and 5, the gateway device 108 represents level 3, and the OT portion 110 represents levels 0, 1, and 2.

2A-2B show an exemplary executable file according to some implementations. FIG. 2A shows a program executable (PE) file 200 according to some implementations. The PE file 200 includes a header portion 202 and a section portion 204. The header portion 202 includes a disk operating system (DOS) header 206 and a PE header 208. The header portion 202 also includes one or more optional headers 210, a data directory 212, and a section table 214. The data directory 212 includes pointers to additional structures (e.g., imports, exports, etc.) according to some implementations. The section table 214 defines how the file is loaded into memory according to some implementations. The section portion 204 includes code 216, imports 218, and data 220. The imports 218 include links between the PE file 200 and operating system (OS) libraries. The data 220 includes information used by the code 216 according to some implementations. FIG. 2B illustrates an executable and linkable format (ELF) file 250 according to some implementations. The ELF file 250 includes an ELF header 252, a program header table 254, sections 256, and a section header table 258.

3A is a block diagram of a computing device 300 according to some implementations. Various examples of computing devices 300 include desktop computers, laptop computers, tablet computers, and other computing devices (e.g., IT or OT devices) having a processor capable of executing a trusted agent 324. The computing device 300 typically includes one or more processing units/cores (CPUs) 302 for executing modules, programs, and/or instructions stored in memory 314 and thereby performing processing operations, one or more network or other communication interfaces 304, the memory 314, and one or more communication buses 312 for interconnecting these components. The communication bus 312 may include circuitry for interconnecting and controlling communication between the system components.

The computing device 300 optionally includes a user interface 306 including a display device 308 and one or more input devices or mechanisms 310. In some implementations, the input device/mechanism includes a keyboard. In some implementations, the input device/mechanism includes a "soft" keyboard that is optionally displayed on the display device 308, allowing a user to "press keys" that appear on the display 308. In some implementations, the display 308 and input device/mechanism 310 comprise a touch screen display (also referred to as a touch sensitive display).

In some implementations, memory 314 includes high-speed random access memory such as DRAM, SRAM, DDR RAM, or other random access solid-state memory devices. In some implementations, memory 314 includes non-volatile memory such as one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid-state storage devices. In some implementations, memory 314 includes one or more storage devices located remotely from CPU(s). Memory 314, or the non-volatile memory device(s) within memory 314, comprises a non-transitory computer-readable storage medium. In some implementations, memory 314, or the computer-readable storage medium of memory 314, stores the following programs, modules, and data structures, or a subset thereof:
an operating system 316 that handles various basic system services and contains procedures for performing hardware-dependent tasks;
one or more communications network interfaces 304 (wired or wireless) and a communications module 318 used to connect the computing device 300 to other computers and devices via one or more communications networks, such as the Internet, other wide area networks, local area networks, metropolitan area networks, etc.;
Applications 322 (e.g., running on Ring-3) that perform a particular task or set of tasks for a user (e.g., a word processor, a media player, a web browser, and a communications platform);
A trusted agent 324 that protects the computing device 300 by validating the code that executes and by monitoring system level operations such as file I/O, registry I/O, starting/stopping threads, loading/unloading images, etc. The trusted agent 324 includes one or more of the following:
o A kernel agent 326 (e.g., a kernel-level device driver running in ring-0) that monitors applications in memory and verifies application binaries and function digests;
o A driver agent 327 (e.g., a kernel thread) that monitors active device drivers and applies countermeasures. In some implementations, the driver agent 327 verifies drivers and driver functions using trusted binaries for the drivers and driver functions.
○ A communication service 328 (e.g., a user mode privileged process) that handles the trust agent's internal communication (e.g., between the kernel agent 326, the binary monitor 330, and the dashboard module 332) and communication between the trust agent 324 and the trust store 338 and/or the trust center. In some implementations, the communication service 328 sends alerts and forensic data to the trust center and receives updates from the trust center. In some implementations, the communication service 328 periodically (e.g., every 30 seconds, 30 minutes, or daily) checks for (e.g., requests) policy and/or software updates.
o A binary monitor 330 that provides static (e.g., non-runtime) file validation, including validating newly installed and modified/updated applications. In some implementations, the binary monitor 330 generates (provisionally) trusted binaries and requests binary validation checks from the trust center.
o A dashboard module 332, which provides a user interface for presenting alerts and allowing viewing/editing of policy and/or trust binary information; and o An installer 334, which identifies executable files, installs the trust agent components, and requests the trust binaries from the trust center(s). In some implementations, the installer 334 is obtainable only from the trust center. In some implementations, the installer 334 can be downloaded from the trust center via a web browser. In some implementations, the installer 334 customizes the installation of the trust agent components (e.g., based on device type, operating system, and administrator settings), and ● One or more databases 336 used by the applications 322 and/or the trust agent 324. The one or more databases 336 include a trust store 338, which is described in more detail below with reference to FIG. 3B.

Each of the above-identified executable modules, applications, or sets of procedures may be stored in one or more of the aforementioned memory devices and correspond to a set of instructions for performing the functions described above. The above-identified modules or programs (i.e., sets of instructions) need not be implemented as separate software programs, procedures, or modules, and thus various subsets of these modules may be combined or otherwise rearranged in various implementations. In some implementations, memory 314 stores a subset of the above-identified modules and data structures (e.g., trust agent 324 does not include dashboard module 332). Additionally, memory 314 may store additional modules or data structures not described above (e.g., trust agent 324 further includes a policy module).

Although FIG. 3A illustrates a computing device 300, FIG. 3A is intended more as a functional description of various features that may be present, rather than as a structural schematic of the implementations described herein. In practice, items shown separately may be combined and some items may be separated, as will be recognized by those skilled in the art.

3B is a block diagram of a trust store 338 according to some implementations. In some implementations, the trust store 338 is a relational database (e.g., a Structured Query Language (SQL) database). The trust store 338 includes multiple trusted binaries 340, including trusted binaries 340-1, 340-2, and 340-n. In the example of FIG. 3B, each trusted binary includes a respective trusted binary name and a respective multiple function digests. For example, trusted binary 340-1 includes trusted binary name 341 and includes function digests 343-1 through 343-m. In some implementations, each trusted binary corresponds to an executable file (e.g., application 322) on the computing device 300. For example, trusted binary 340-1 corresponds to a first application having "m" functions, and therefore trusted binary 340-1 has "m" function digests. In some implementations, at least one trusted binary 340 corresponds to a device driver. For example, trusted binary 340-2 corresponds to a first device driver having "p" driver functions, and therefore trusted binary 340-2 has "p" function digests. Trust store 338 further includes block list 342, blockchain information 344, policy information 346, and one or more forensic logs 348. In some implementations, block list 342 includes a list of blocked (corrupted, malicious) files and/or applications. Blockchain information 344 includes genesis block 345 and multiple transaction blocks 347 (e.g., transaction blocks 347-1, 347-2, and 347-p). In some implementations, blockchain information 344 includes a respective transaction block 347 for each change to trust store 338 (e.g., policy update, trusted binary addition, etc.). Further details of blockchain information 344 are described below with respect to FIG. 3C.

In some implementations, policy information 346 includes information about which features of trust agent 324 are active, such as policies about which countermeasures (and how) to apply, which notifications (and how) to present, which corrective actions to apply to untrusted binaries, etc. In some implementations, policy information 346 includes client certificates and encryption keys for trust store 338. In some implementations, programs without a corresponding trusted binary are considered untrusted. In some implementations, policy information 346 includes policies for responding to untrusted applications, scripts, programs, and functions. In some implementations, the policies include whether to block, notify, or ignore each instance of untrusted behavior. In some implementations, policy information 346 includes specific settings (e.g., exceptions) for special programs or applications (e.g., identified by program name or header).

In some implementations, the forensic log 348 includes information collected in response to a threat detected by the trust agent 324, such as the execution of an untrusted executable file and/or function. In some implementations, the information stored in the forensic log 348 is based on an active security policy for the trust agent 324. In some implementations, the forensic log 348 includes information regarding one or more of the following: read buffer contents, injected memory, untrusted functions, untrusted scripts, untrusted shell code, modified code, and the like. In some implementations, the forensic information regarding a detected untrusted execution depends on the type of execution. For example, forensic information regarding an instance of unknown read buffering may include a capture of the read buffer contents. As another example, forensic information regarding an instance of reflective injection may capture the injection information. In some implementations, the forensic log 348 includes information regarding the computing device (e.g., information regarding the operating system, version, patch level, hardware, and memory).

3C is a block diagram of a blockchain 350 according to some implementations. In some implementations, the blockchain information 344 includes a blockchain 350. The blockchain 350 includes a genesis block 345, a transaction block 347-1, and a transaction block 347-2. The genesis block 345 includes a previous block digest 352 (e.g., an empty or blank digest), a trust binary digest 353, a creation timestamp 354, a block type 355, a block digest 356, a signing certificate 357, and a digital signature 358. In some implementations, the trust binary digest 353 includes a digest for each trust binary 340 in the trust store 338. In some implementations, the trust binary digest 353 is a secure hash algorithm (SHA) digest (e.g., a SHA-256 digest). In some implementations, the block type 355 of the genesis block 345 is a trusted binary block type (e.g., because the genesis block includes a trusted binary digest 353). In some implementations, the block digest 356 is a SHA digest. In some implementations, the block digest 356 is generated by applying a SHA hash function multiple times (e.g., applying a SHA-256 hash function twice). In some implementations, the signing certificate 357 includes information about the block creator of the genesis block 345 (e.g., a trust center certificate). In some implementations, the digital signature 358 corresponds to a cryptographic key in a trust store.

In some implementations, transaction block 347-1 represents a first change to trust store 338. Transaction block 347-1 includes a previous block digest 360 (corresponding to block digest 356 of genesis block 345), a transaction digest 364 for the first change, a creation timestamp 366, a block type 368, a block digest 370, a signing certificate 372, and a digital signature 374. In some implementations, the first change is a trust binary change (e.g., adding a new trust binary), and block type 368 is a trust binary block type. In some implementations, the first change is a policy update, and block type 368 is a policy block type. In some implementations, signing certificate 372 is a client certificate for computing device 300. In some implementations, digital signature 374 corresponds to an encryption key for the client device.

In some implementations, transaction block 347-2 represents a second change to trust store 338. Transaction block 347-2 includes a previous block digest 376 (corresponding to digest 370 of transaction block 347-1), a transaction digest 378 for the second change, a creation timestamp 380, a block type 382, a block digest 384, a signing certificate 386, and a digital signature 388.

In some implementations, the trust agent 324 utilizes the blockchain information 344 to validate the trust store 338. In some implementations, the blockchain 350 is validated using a proof-of-identity operation. Transaction block 347-1 includes a previous block digest 360 that should match the block digest 356 of the genesis block 345, and transaction block 347-2 includes a previous block digest 376 that should match the block digest 370 of transaction block 347-1. In this way, the validity of the blockchain 350 can be checked by comparing the block digest of each block with the previous block digest of the next block in the chain.

In some situations, blockchain 350 has advantages over traditional cybersecurity systems because it allows for validation of trust store 338 without requiring a network connection (e.g., operating on an air-gapped system). In some situations and implementations, using blockchain 350 for trust store validation allows the validation procedure to be distributed and secure. In some implementations, trust store 338 and blockchain 350 are verified at deployment time (e.g., when installed on a new computing system) and with each subsequent reload of trust agent 324.

4A-4B illustrate an exemplary trusted binary use case, according to some implementations. FIG. 4A illustrates an exemplary communication sequence between trust agent 324, trust store 338, and trust center 402. In the example of FIG. 4A, trust agent 324 monitors device memory (e.g., memory 314 of computing device 300) (404). Trust agent 324 detects a binary file (e.g., a binary file corresponding to application 322) launched in memory (406). In response, trust agent 324 requests a trusted binary for the binary file from trust store 338 (408). Trust store 338 is searched (e.g., by components of trust agent 324) for a corresponding trusted binary (410). In the example of FIG. 4A, a corresponding trusted binary is not found in trust store 338. Trust agent 324 is notified of the lack of a corresponding trusted binary (412). Thus, the trust agent 324 requests (414) the corresponding trusted binary from the trust center 402. The trust center 402 searches (416) for the corresponding trusted binary. In the example of FIG. 4A, the corresponding trusted binary is not found in the trust center 402. The trust center 402 sends (418) a notification to the trust agent 324 about the lack of a corresponding trusted binary. In response, the trust agent 324 applies countermeasures (414) (e.g., according to an active policy). In the example of FIG. 4A, the trust agent 324 generates (420) an interim trusted binary (sometimes also referred to as a local trusted binary). The interim trusted binary is stored (422) in the trust store 338. A block corresponding to the interim trusted binary is created and added (424) to the blockchain (e.g., the blockchain 350). The trust agent 324 sends (426) the binary file to the trust center 402 for validation. The trust center 402 analyzes (428) the binary file. In the example of FIG. 4A, the binary file is approved (430) by the trust center 402 and the trust agent 324 is notified (431). The provisionally trusted binary is stored (432) in the trust store 338 as a non-provisionally (standard) trusted binary. A block is added to the blockchain to convert the provisionally trusted binary to a non-provisionally trusted binary (434).

4B illustrates another exemplary communication sequence between the trust agent 324, the trust store 338, and the trust center 402. In the example of FIG. 4B, the trust center 402 generates a trust policy (450). In some implementations, the trust policy dictates how the trust agent responds to untrusted binaries and functions. In some implementations, the trust policy dictates which countermeasures should be active on the computing device. The trust policy is sent (452) to the trust store 338 (e.g., via the communication service 328). The trust policy is stored in the trust store 338 (454). The trust agent 324 loads the trust policy (456) (e.g., as part of a startup procedure). The trust agent 324 monitors (458) the device memory (e.g., the memory 314 of the computing device 300). The trust agent 324 detects (460) a function call (e.g., a function call executed by the application 322). In response to the function call, the trust agent compares the function to the function digest in the trusted binary (e.g., the corresponding function digest in the trusted binary for the application) (462). In the example of FIG. 4B, the comparison indicates that the function is untrusted (e.g., modified). In accordance with the trust policy, the trust agent 324 blocks the function from being executed (464) and generates a forensic log having information related to the function and the function call (466). The trust agent 324 sends the forensic log to the trust center 402 for analysis (468). The trust center 402 analyzes the forensic log (470) and generates a threat report (72). The trust center 402 sends a notification (e.g., having at least a portion of the threat report) to the trust agent 324 (474). The trust agent 324 displays the notification (476) to the user of the device (e.g., using the dashboard module 332 to display the notification).

5 illustrates a network architecture 500 according to some implementations. The network architecture 500 includes a device group 502-1 and a device group 502-2. In the example of FIG. 5, the device group 502-1 includes three devices (e.g., two user terminals 112 and one audit terminal 118), and the device group 502-2 includes two devices (e.g., two user devices 104). The group 502-1 has an associated security policy 504-1, and the group 502-2 has an associated security policy 504-2. Thus, in this example, the same security policy (e.g., security policy 504-1) is applied to each device in the device group 502-1. The network architecture 500 further includes a trust center 510, trust points 506-1 and 506-2, and trust stores 508-1 to 508-5. In some implementations, the trust center 510 is an instance of the trust center 402. The trust points 506 represent a logical grouping of trust stores according to some implementations. In some implementations, the trust points 506 include a search list (index) of the connected trust stores 508. For example, the trust point 506-1 includes a search list of the trust stores 508-1 and 508-2. As shown in FIG. 5, the devices in each device group utilize a shared trust store 508. Specifically, each of the device groups 502-1 and 502-2 is coupled to the trust store 508 via the trust point 506. In some implementations, the trust stores 508 are stored remotely from the device groups 502 (e.g., on a separate network device, network server, and/or separate network). In some implementations, each trust store 508 corresponds to a particular operating system, device type, or entity (e.g., includes only trusted binaries associated with that operating system, device type, or entity). In some implementations, the trust stores 508 include metadata about the trusted binaries stored therein (e.g., metadata temporary vendor, version, date, etc.).

In some implementations, each security policy 504 represents a policy group. In some implementations, policy settings not specified in the policy group do not apply to the device group 502. In some implementations, each security policy 504 includes a policy setting for each measure (e.g., enforce, notify, or off setting). In some implementations, measures not included in a policy setting are set to a default value (e.g., off). In some implementations, the security policy 504 includes one or more named exceptions (e.g., different settings for a particular application). In some implementations, the security policy 504 includes a dashboard setting to enable or disable use of the dashboard module 332 on the device. In some implementations, the security policy 504 includes one or more blacklists (e.g., specifying applications to prevent from running). In some implementations, the security policy 504 includes restrictions on one or more applications (e.g., to prevent one or more applications from running on the device or device group 502). In some implementations, security policy 504 includes one or more lists of blacklist IP addresses and/or one or more lists of restricted IP addresses. In some implementations, security policy 504 includes application update settings for whether to allow applications to be updated to new versions and whether to generate local trusted binaries for updated applications. In some implementations, security policy 504 includes application installation settings for whether to allow new applications to be installed and whether to generate local trusted binaries for new applications. In some implementations, security policy 504 includes device configuration settings (e.g., based on device type and/or operating system).

In some implementations, the trust center 510 includes one or more of a policy manager, an alert manager, a trust database, a trust manager, and a dashboard manager. In some implementations, the trust center 510 is in communication with one or more other trust centers. In some implementations, the trust center 510 shares information from its trust store with other trust centers (e.g., to accelerate deployment and provide global compliance). In some implementations, the trust center includes a web-based dashboard. In some implementations, the dashboard is a controlled access dashboard (e.g., using multi-factor authentication). In some implementations, the dashboard provides an interface for managing one or more of device groups, security policies, trust binaries, trust stores, and trust points. In some implementations, the dashboard provides an interface for an inventory of endpoints (e.g., computing devices with trust agents). In some implementations, the dashboard provides an interface for viewing and managing one or more of notifications (alerts), whitelists, risk assessments, authentication management, and communication configurations (e.g., peer-to-peer networking). In some implementations, the policy manager configures policy groups (e.g., to be attached to corresponding device groups 502) and individual policy settings.

In some implementations, the trust center 510 provides policies and updates to the endpoint devices (e.g., devices in the device group 502). In some implementations, the trust center 510 records alerts and forensic data received from the device group 502. In some implementations, the trust center 510 provides validity authentication of applications and programs and creates corresponding trusted binaries (e.g., to be distributed to the trust stores 508). In some implementations, the trust center 510 provides organizational management of trusted binaries (e.g., determining which trust stores 508 receive and store which trusted binaries). In some implementations, the trust center 510 operates on a network gateway or server system. In some implementations, the trust center 510 operates on a virtual machine on a server system or gateway device.

In some implementations, the trust center 510 validates the trusted binary by determining one or more of the following: (i) whether the application was obtained directly from the manufacturer; (ii) whether the application is signed, whether the signature is valid, whether the signing certificate is valid, and whether the chain of trust is valid; (iii) whether the application's digest has been cleared by a virus scanner and/or blacklist checker; (iv) whether the application (or an update to the application) was obtained from a trusted download site; (v) whether a site administrator has approved the application for use; and (vi) whether the user has approved the application for local use on the computing system.

In some implementations, the trust center 510 provides administrator functions for one or more trust stores and/or trust points. In some implementations, the administrator functions include functions to create, duplicate, or delete trust stores or trust points. In some implementations, the administrator functions include functions to move trust stores, trust points, and/or trust binaries between devices and the system.

FIGS. 6A-6B provide a flowchart of a method 600 for creating a trusted binary, according to some implementations. The method 600 is performed on a computing system (e.g., computing device 300) having one or more processors and memory. In some implementations, the memory stores one or more programs configured for execution by the one or more processors.

The computing system obtains executable code (e.g., for a program) (602). In some implementations, a trusted agent running on the computing system obtains the executable code. In some implementations, the executable code is obtained during an installation process for the program. In some implementations, the executable code is obtained during a download process for the program. In some implementations, the executable code is obtained as part of a scan of static (e.g., non-executable) applications on the computing system (e.g., performed by binary monitor 330). In some implementations, the computing system obtains executable code for a device driver.

In some implementations, the executable code is one of a program executable file (e.g., as shown in FIG. 2A) or an executable or linkable format file (e.g., as shown in FIG. 2B) (604). In some implementations, the executable code is a file in a special programming language (e.g., a .net file, a Java file, a Python file, or a Visual Basic file).

The computing system identifies (606) executable functions from the executable code. For example, the code 216 is scanned to identify all functions in a PE file. As another example, the section 256 is scanned to identify all functions in an ELF file. In some implementations, identifying the executable functions includes identifying functions in a shared library (e.g., from imports 218).

The computing system generates (608), for each executable function of the plurality of executable functions, a function digest for the executable function based on one or more static components of the executable function. In some implementations, each function digest is generated by applying a hash function to the executable function (e.g., a secure hash function such as SHA-256).

In some implementations, the one or more static components of the executable function include one or more instructions and one or more registers (614). In some implementations, the one or more static components of the executable function exclude one or more dynamic address fields (616). In some implementations, the one or more static components include all non-changing (e.g., non-dynamic) components of the function.

In some implementations, a respective function digest for each executable function of the plurality of executable functions is generated (618) using a secure hash algorithm. In some implementations, a respective function digest for each executable function is generated using a cryptographic hash function. In some implementations, a respective function digest for each executable function is generated by applying two or more cryptographic hash functions to the executable function. In some implementations, each function digest includes an indication of the length of the corresponding function. In some implementations, each function digest includes an indication of the start address or end address of the corresponding function.

The computing system builds (620) a trusted binary that includes a respective digest for each executable function of the plurality of executable functions. In some implementations, the trusted binary includes digests for all executable code in the corresponding file (e.g., a PE file or an ELF file). In some implementations, the trusted binary includes a digest for the entropy contained in the corresponding file.

In some implementations, to build the trusted binary, the computing system hashes (622) one or more of the program's data directory (e.g., data directory 212), the program's section table (e.g., section table 214), and the program table (e.g., program header table 254) of the program. In some implementations, building the trusted binary includes hashing each section of the program's executable code.

The computing system generates a trusted binary name by applying a hash function to the header of the executable code (624). In some implementations, the trusted binary name is a digest of the entropy contained in the header of the executable code.

In some implementations, the executable code is a program executable (PE) file, and generating the trusted binary name includes applying a hash function to (at least one of) the DOS header and the PE header of the PE file (625).

In some implementations, the executable code is an executable or linkable format (ELF) file, and generating the trusted binary name includes applying a hash function to an ELF header of the ELF file (626).

In some implementations, the hash function is a secure hash algorithm, such as the SHA-256 hash function (628). In some implementations, the hash function is a cryptographic hash function. In some implementations, the same hash function is used to generate the trusted binary name and to generate the executable function digest.

The computing system indexes (630) the trusted binary in a trust database (e.g., a trust store) using the trusted binary name. For example, trusted binary 340 is stored in trust store 338 (e.g., indexed by trusted binary name 341).

In some implementations, the trust database is stored (632) in memory of the computing system (e.g., trust store 338 stored in memory 314 of computing device 300). In some implementations, the trust database is stored remotely from the computing device. For example, FIG. 5 shows a trust store 508 remote from the devices in device group 502.

In some implementations, the computing system transmits the trust binary to a server system remote from the computing system (634). For example, the trust binary is generated on a device in device group 502-1 and transmitted to trust point 506-1 for indexing and storage (e.g., in one of trust stores 508-1 or 508-2).

Figures 7A-7D provide a flowchart of a method 700 for using trusted binaries, according to some implementations. The method 700 is performed on a computing system (e.g., computing device 300) having one or more processors and memory. In some implementations, the memory stores one or more programs configured for execution by the one or more processors.

The computing system executes a trust agent (702). For example, the computing device 300 executes the trust agent 324. In some implementations, the trust agent executes as a kernel-level device driver. In some implementations, the trust agent executes as a ring-0 process on the computing system.

In some implementations, the computing system (704) verifies the authenticity of the trust agent by (i) loading executable code of the trust agent into memory, (ii) obtaining a trusted binary for the trust agent, and (iii) comparing the loaded executable code with the obtained trusted binary. In some implementations, as part of the trust agent startup process, the trust agent validates its own trusted binary (e.g., to ensure that the trust agent code has not been tampered with). In some implementations, the trust agent uses operating system permissions to protect its associated files and data (e.g., trust store and trust agent component files) from tampering. In some implementations, the trust agent includes (runs) a kernel thread to monitor files and data associated with the trust agent. In some implementations, the kernel thread continuously verifies that files and data associated with the trust agent have not been disabled or tampered with. In some implementations, when the kernel thread detects a write access to the monitored files and data, the process that initiated the write access is stopped (disabled) by the kernel thread. In some implementations, forensic data is obtained following the detected write access, and the trusted agent uses the forensic data to generate a notification (e.g., to a user of the computing system and/or to a trusted center).

In some implementations, the trust agent executes at startup of the computing device (706). In some implementations, the trust agent is configured to execute as part of the boot (e.g., power-on) sequence of the computing system.

In some implementations, the computing system establishes (708) multiple kernel hooks for input/output (I/O) inspection. For example, multiple kernel hooks are utilized to inspect file I/O operations, registry I/O operations, thread start and stop operations, and image load and unload operations.

In some implementations, the trust agent includes a kernel-level driver (710). For example, the trust agent 324 includes a kernel agent 326 to verify application binaries and function digests. In some implementations, the kernel agent 326 ensures that applications running in memory are protected from attack and compromise by validating function calls and memory buffers associated with the application.

In some implementations, the trust agent includes a driver agent (e.g., driver agent 327) that monitors device drivers. In some implementations, the driver agent verifies the device driver by comparing a digest of the device driver to a trusted binary for the device driver. In some implementations, if a trusted binary for the device driver is not found or if the digest of the device driver does not match the trusted binary, the device driver is not allowed to load or is taken offline (disabled). In some implementations, the driver agent monitors functions and kernel threads that run in the device driver. In some implementations, the driver agent verifies driver functions by comparing a digest of the function to a function digest in a trusted binary for the device driver. In some implementations, if a kernel thread is detected attempting to execute a function in the device driver and the function does not have a matching function digest in the trusted binary, the driver agent stops the kernel thread and/or disables the device driver. In some implementations, the driver agent obtains (e.g., generates or captures) forensic data in accordance with detecting an unverified device driver or an unverified function running in the device driver. In some implementations, the driver agent generates a notification (e.g., to a user of the computing system and/or a trust center) in response to detecting an unverified device driver or an unverified function running in the device driver. In some implementations, the notification includes forensic data. In some implementations, the driver agent causes the operating system to power down (e.g., restart or reboot) in response to detecting an unverified device driver or an unverified function running in the device driver. In some implementations, the driver agent recommends to a user of the computing system that the operating system be powered down in response to detecting an unverified device driver or an unverified function running in the device driver.

In some implementations, the trust agent includes a communication service, a file monitor, an installer, and a dashboard manager (712). For example, the trust agent 324 includes the communication service 328, the binary monitor 330, the dashboard module 332, and the installer 334.

The computing system, via the trusted agent, detects (714) future execution of a program (e.g., application 322) on the computing system. For example, the trusted agent detects that a binary file is being launched in memory. In some implementations, in addition to detecting binary files being launched in memory, the trusted agent detects programs and/or binary files being downloaded.

In some implementations, the computing system identifies (716) a memory request corresponding to the program. For example, the trusted agent 324 identifies a file I/O operation or a registry I/O operation. In some implementations, the trusted agent 324 identifies an application thread attempting to start or detects script, javascript, or shell code in a memory buffer.

In response to the detection, the computing system retrieves (720) a trusted binary for the program from a trust store in memory. For example, the trust agent 324 retrieves the trusted binary 340 from the trust store 338.

The computing system verifies the authenticity of the program by comparing the executable code of the program with the trusted binary for the obtained program (722). For example, the trusted agent 324 generates a digest of the executable code and compares the generated digest with the trusted binary.

The computing system allows execution of the program according to the confirmed authenticity of the program (724). For example, the trusted agent 324 may intercept a binary file being loaded into memory and prevent the binary file from being loaded (e.g., suspend the process) until the authenticity of the binary file is confirmed (based on the trusted binary).

The computing system identifies future executions of executable functions of the program by monitoring the execution of the program (726). For example, the trusted agent 324 detects function calls associated with the program (e.g., to functions of the program or to functions in a shared library).

In some implementations, the computing system monitors (728) system-level operations of the program. For example, the trusted agent 324 monitors file I/O operations, registry I/O operations, thread start and stop operations, and image load and unload operations.

In some implementations, the computing system intercepts library function calls made by the program (730). For example, the kernel agent 326 monitors the program (application) throughout the program's lifetime in memory, including loading, execution, and termination. In some implementations, the kernel agent 326 validates the program against a trusted binary and verifies functions in any loaded shared libraries. In some implementations, the trust agent 324 obtains the trusted binary for the shared library and compares digests of the library functions to function digests in the trusted binary.

In response to identifying a future execution of the executable function, the computing system obtains from the trusted binary a function digest corresponding to the executable function (732). For example, the trusted agent 324 obtains the function digest 343-1 corresponding to the executable function.

The computing system verifies the authenticity of the executable function by comparing the executable code of the executable function with the obtained function digest (734). For example, the trusted agent 324 generates a digest by applying a hash to the static portion of the executable function and then compares the digest with the function digest from the trusted binary.

The computing system allows execution of the executable function according to the confirmed authenticity of the executable function (736). For example, the trusted agent 324 allows execution of the function according to a hash of the function that matches the function digest in the trusted binary.

In some implementations, the computing system detects (738) future execution of the second program via the trust agent. For example, the trust agent 324 detects a binary file for the second application 522 being loaded in memory.

In some implementations, the computing system determines (740) that the trust store does not include a corresponding second trusted binary for the second program. For example, the second program is a program for which no trusted binary was created, or the second program has been modified such that a hash of a header portion of the second program does not match a previously generated trusted binary name for the second program.

In some implementations, in response to the detection, the computing system retrieves (744) a second trusted binary for the second program from the trust store. For example, trusted binary 340-1 corresponds to the first program and trusted binary 340-2 corresponds to the second program.

In some implementations, the computing system identifies one or more modifications to the executable code of the second program based on the comparison to the second trusted binary (746). For example, the trusted binary name matches a hash of a header portion of the second program, but a hash of a code portion (e.g., code 216) does not match a digest of the trusted binary.

In some implementations, the computing system initiates a corrective action (742) (e.g., following the determination (740) or the identification (746)). In some implementations, the corrective action includes collecting forensic data for analysis by a trust center (e.g., trust center 402). In some implementations, the corrective action includes generating a notification (e.g., presented to a user of the computing system and/or sent to a trust center) about the untrusted second program.

In some implementations, the corrective action includes one or more of: preventing the second program from executing, storing information about the second program in a forensic log (e.g., forensic log 348), and generating a provisional trusted binary for the second program (748). In some implementations, preventing the second program from executing includes intercepting a binary file of the second program that is loaded into memory.

In some implementations, the corrective action includes generating a provisionally trusted binary, and the computing system sends the executable file of the second program to a trust center for validity authentication (750). In some implementations, following generating the provisionally trusted binary, the second program can be run on the computing system for a limited period of time (e.g., one day, two days, or one week). In some implementations, the second program can be run on the computing system until a response regarding the executable file of the second program is received from the trust center. In some implementations, forensic data is sent to the trust center along with the executable file of the second program, the forensic data including information regarding the state of the computing system and the conditions under which the second program was executed. In some implementations, the trust center analyzes the executable file of the second program, and optionally any forensic data received, to determine whether to trust the second program. In some implementations, validating the executable file of the second program includes one or more of: checking a digital signature, checking a signature certificate path, checking the executable file against one or more blacklists (e.g., local and external), and checking the executable file against one or more whitelists.

In some implementations, the corrective action includes applying one or more countermeasures (752). In some implementations, the countermeasures include detecting and preventing one or more of heap spray, reflective injection, unknown read buffering, blocked address communication, illegal functions, malicious scripts, privilege escalation, function tampering, unknown shell code, and trust tampering. In some implementations, each countermeasure is individually enabled via a policy setting (e.g., in policy information 346). In some implementations, policy information 346 includes a force parameter, a notify parameter, or an off parameter for each countermeasure.

In some implementations, detecting and preventing heap spray includes detecting that dynamic memory has been allocated for executable code insertion. In some implementations, the trust agent 324 blocks the executable code insertion and/or sends information about the executable code insertion to a trust center for analysis. In some implementations, a copy of the sprayed memory is stored in a forensic log of the event.

In some implementations, detecting and preventing reflective injection includes detecting that another process has injected an executable object into the process. In some implementations, the trust agent 324 blocks the injection of the executable object and/or sends information about the executable object to a trust center for analysis. In some implementations, a copy of the injected memory is stored in a forensic log of the event.

In some implementations, detecting and preventing unknown read buffering includes detecting that an executable file is loaded into memory and that the executable file does not have a corresponding trusted binary. In some implementations, the trust agent 324 prevents the executable file from being loaded into memory and/or sends information about the executable file to a trust center for analysis. In some implementations, a copy of the buffer contents is stored in a forensic log of the event.

In some implementations, detecting and preventing blocked address communication includes detecting when a process attempts to connect to a restricted or blocked Internet Protocol (IP) address. In some implementations, the trust agent 324 prevents communication with restricted or blocked IP addresses.

In some implementations, detecting and preventing unauthorized functions includes detecting that a thread is about to start and that the associated function does not have a corresponding trusted binary (or a corresponding function digest within the trusted binary). In some implementations, the trust agent 324 prevents the thread from starting or terminates the thread in response to a determination that a corresponding trusted binary does not exist, and/or sends information about the thread and associated function to a trust center for analysis. In some implementations, a copy of the unauthorized function is stored in a forensic log of the event.

In some implementations, detecting and preventing malicious scripts includes detecting a script (e.g., a batch file (BAT), a JavaScript file, or a PowerShell file) in a process buffer (e.g., during a file operation) and determining that the script includes one or more suspicious behaviors, such as an encrypted or compressed script section. In some implementations, the trust agent 324 prevents the script from being executed and/or sends information about the script to a trust center for analysis. In some implementations, a copy of the script is stored in a forensic log of the event.

In some implementations, detecting and preventing privilege escalation includes detecting that a process has attempted to elevate its privilege level in a computing system (e.g., elevating the privilege level to a system level). In some implementations, the trusted agent 324 prevents the process from elevating its privilege level and/or transmits information about the privilege escalation to a trusted center for analysis.

In some implementations, detecting and preventing function tampering includes detecting that a function in the program has been modified since being loaded into memory. In some implementations, the trust agent 324 blocks the modified function from being executed and/or sends information about the modified function to a trust center for analysis. In some implementations, information about the original function and the modified function is sent to a trust center for analysis. In some implementations, detecting and preventing unknown shellcode includes detecting shellcode in a memory buffer.

In some implementations, detecting and preventing unknown shellcode includes detecting that a buffer is allocated to a process and its page access permissions are set to read/write/execute without a corresponding image or trusted binary. In some implementations, the trust agent 324 blocks the shellcode from executing and/or sends information about the shellcode to a trust center for analysis. In some implementations, the shellcode memory image is stored in a forensic log of the event.

In some implementations, detecting and preventing trust tampering includes detecting that a process attempts to modify one or more files of a trust agent or trust store. In some implementations, the trust agent 324 blocks the process from modifying the one or more files and sends information about the trust tampering to a trust center for analysis.

In some implementations, the corrective action includes sending a query to the trust center for a trusted binary for the second program (754). For example, the trust agent 324 requests the trusted binary from the trust store 338, and upon notification that the trust store 338 does not contain the requested trusted binary, the trust agent 324 requests the trusted binary from the trust center.

In some implementations, the corrective action is based on a trust policy obtained for the computing device (756). For example, the corrective action is based on a trust policy (e.g., security policy 504-1) stored in policy information 346.

In some implementations, while monitoring the execution of the program, the computing system identifies (758) a future execution of a second executable function of the program. For example, the kernel agent 326 identifies a call to the second executable function.

In some implementations, in response to identifying a future execution of the second executable function, the computing system determines (760) that the trusted binary does not include a corresponding second function digest for the second program. For example, the second function may not have a corresponding function digest created or the second function may have been modified since the corresponding function digest was created.

In some implementations, the computing system initiates a corrective action in accordance with the determination (762). In some implementations, the corrective action includes collecting forensic data for analysis by a trust center (e.g., trust center 402). In some implementations, the corrective action includes generating a notification (e.g., presented to a user of the computing system and/or sent to a trust center) about the untrusted second executable function.

In some implementations, the corrective action includes one or more of preventing execution of the second executable function, stopping execution of the program, storing information about the second executable function in a forensic log, and generating a provisional function digest for the second executable function (764). In some implementations, generating the provisional function digest includes generating a provisional trusted binary for the program. In some implementations, the executable code of the program is sent to a trust center for validity authentication. In some implementations, following generation of the provisional function digest, the second function can be executed on the computing system for a limited period of time (e.g., one day, two days, or one week). In some implementations, the second program can be executed on the computing system until a validity authentication response is received from the trust center.

FIGS. 8A-8B provide a flowchart of a method 800 for using blockchain validity authentication, according to some implementations. The method 800 is performed on a computing system (e.g., computing device 300) having one or more processors and memory. In some implementations, the memory stores one or more programs configured for execution by the one or more processors.

The computing system obtains (802) a blockchain for a trust store. In some implementations, the computing system receives the trust store from a trust center, where the trust store includes a blockchain. For example, the computing device 300 receives the trust store 338 from the trust center as part of the installation process of the trust agent 324. In this example, the trust store 338 includes at least some blockchain information (e.g., the genesis block) when it is received.

In some implementations, the computing system obtains (804) a genesis block of the blockchain. In some implementations, a trust store having a genesis block (e.g., genesis block 345) is received from a trust center.

In some implementations, the genesis block includes an encrypted digest of the trusted binary (e.g., trusted binary digest 353), a block type (e.g., block type 355), a signing certificate (e.g., signing certificate 357), a digital signature (e.g., digital signature 358), and an encrypted block digest (e.g., block digest 356) (806). In some implementations, the genesis block has a trusted binary block type. In some implementations, the genesis block has a signing certificate from a trust center. In some implementations, the genesis block further includes a creation timestamp (e.g., creation timestamp 354).

In some implementations, the blockchain is stored in a table in the trust store, with each row in the table corresponding to a block of the blockchain (808). For example, blockchain information 344 includes a table having a row corresponding to transaction block 347.

In some implementations, each block in the blockchain includes a respective signing certificate and a respective digital signature (810). For example, the genesis block includes signing certificate 357 (e.g., from a trust center) and digital signature 358, and transaction block 347-1 includes signing certificate 372 (e.g., from computing device 300) and digital signature 374.

The computing system identifies (812) a first change to the trust store. In some implementations, the trust agent 324 monitors the trust store for changes. In some implementations, the trust agent 324 modifies (e.g., updates) the trust store. In some implementations, the first change to the trust store is one of a policy update, a trusted binary update, a block list update, and an interim trusted binary update.

The computing system generates a first block and inserts the first block into the blockchain, the first block including a first encrypted digest for the first change (e.g., transaction digest 364) and a first block digest (e.g., block digest 370) (814). For example, the computing device 300 generates transaction block 347-1 in response to the first transaction, the transaction block 347-1 including transaction digest 364.

In some implementations, the first block further includes an encrypted block digest of the genesis block (816). For example, transaction block 347-1 includes a previous block digest 360 that corresponds to block digest 356 of genesis block 345.

In some implementations, the first block has a block type selected from the group consisting of a trust binary type, a block list type, a policy type, and a local trust binary type (818). In some implementations, each type of change to the trust store has a corresponding block type. In some implementations, the block types further include a forensic type that corresponds to a forensic change to the trust store (e.g., an update to the forensic log 348).

In some implementations, the first change to the trust store is a change to a trust binary in the trust store, and the first block has a trust binary block type (820). For example, a new trust binary is obtained (e.g., from a trust center) and, in response, transaction block 347-1 is generated with a trust binary block type.

In some implementations, the first change to the trust store is a change to a policy of the trust store, and the first block has a policy block type (822). For example, a new policy is obtained (e.g., from a trust center or from a user of the computing system) and in response, a transaction block 347-1 is generated with a policy block type.

In some implementations, the first change to the trust store is a change to a block list of the trust store, and the first block has a block list block type (824). For example, a block list update is obtained (e.g., from a trust center), and in response, transaction block 347-1 is generated with a block list block type.

In some implementations, the first change to the trust store is the addition of a local trusted binary to the trust store, and the first block has a local trusted binary block type (826). For example, a new provisional trusted binary is generated at the computing system, and in response, transaction block 347-1 is generated with a local trusted binary block type.

In some implementations, the first block digest is generated using two or more secure hash algorithms (828). For example, the first block digest is generated by applying two or more secure hash algorithms (e.g., a SHA-256 hash function) to the contents of the first block.

The computing system identifies (830) a second change to the trust store. In some implementations, the second change is a different type of change than the first change. For example, the first change is a trusted binary update and the second change is a policy update. In some implementations, the second change is the same type of change as the first change. For example, the first change is a first trusted binary update and the second change is a second trusted binary update.

The computing system generates a second block and inserts the second block into the blockchain, the second block including a second encrypted digest for the second change (e.g., transaction digest 378), a second block digest (e.g., block digest 384), and the first block digest (e.g., previous block digest 376) (832).

In some implementations, the computing system verifies the integrity of the trust store (834), including using the blockchain to validate the contents of the trust store. For example, the computing system compares a digest of the trust binary 340 to a digest of one or more trust binary blocks in the blockchain 350 and validates the trust store according to a match. As another example, the computing system compares a digest of the policy information 346 to a digest of one or more policy blocks in the blockchain 350 and validates the trust store according to a match.

In some implementations, the computing system validates the blockchain using a proof-of-identity operation that includes comparing a previous block digest in the second block to a first block digest in the first block (836). In some implementations, verifying the integrity of the trust store includes validating the blockchain. In some implementations, the proof-of-identity operation includes, for each transaction block 347, comparing a previous block digest of the transaction block 347 to a block digest of a previous block in the blockchain 350. For example, comparing a previous block digest 360 in transaction block 347-1 to a block digest 356 of genesis block 345.

Next, we will explain some example implementations.

(A1) In one aspect, some implementations include a method (e.g., method 600) for creating a trusted binary. The method is executed on a computing system (e.g., computing device 300) having a memory (e.g., memory 314) and one or more processors (e.g., CPU 302(s)). The method includes (i) obtaining executable code of a program (e.g., application 322); (ii) identifying a plurality of executable functions from the executable code; (iii) generating a respective function digest for each executable function of the plurality of executable functions based on one or more static components of the respective executable function; (iv) constructing a respective trusted binary for each executable function of the plurality of executable functions including the respective digest; (v) generating a trusted binary name by applying a hash function to a header of the executable code; and (vi) indexing the trusted binary in a trust database (e.g., trust store 338) using the trusted binary name.

(A2) The method of A1, wherein generating a respective function digest for each function is further based on a respective start address of each executable function. In some implementations, an end address is obtained and used instead of or in addition to the start address. In some implementations, the digest is generated using an end address or an offset address rather than a start address. In some implementations, the trusted binary name is based on a determined entropy of a header of the executable code.

(A3) The method of A1 or A2, wherein the executable code is one of a program executable file or an Executable and Linkable Format (ELF) file. In some implementations, the executable code is a programming language file, such as a .NET file, a Java file, a Python file, a Visual Basic file, etc.

(A4) The method of A3, wherein the executable code is a program executable (PE) file, and generating the trusted binary name includes applying a hash function to a DOS header (e.g., DOS header 206) and a PE header (e.g., PE header 208) of the PE file. In some implementations, the hash function is a cryptographic hash function (e.g., a SHA-256 hash function).

(A5) The method of A3, wherein the executable code is an executable and linkable format (ELF) file, and generating the trusted binary name includes applying a hash function to an ELF header (e.g., ELF header 252) of the ELF file. In some implementations, the hash function is a cryptographic hash function (e.g., a SHA-256 hash function).

(A6) A method according to any of A1 to A5, wherein one or more static components of each executable function include one or more instructions and/or one or more portions representing static data. In some implementations, the one or more static components include all static components of the executable function.

(A7) A method according to any of A1 to A6, wherein one or more static components of each executable function exclude dynamic address fields. In some implementations, the one or more static components of the executable function include all components of the executable function except any dynamic address fields.

(A8) A method according to any of A1 to A7, wherein constructing the trusted binary includes hashing one or more of the program's data directory, the program's section table, and the program table of the program. In some implementations, constructing the trusted binary includes hashing the code, data, and import sections of the executable code (e.g., sections 216, 218, and 220).

(A9) A method according to any of A1-A8, wherein the hash function is or includes a secure hash algorithm (e.g., a SHA-256 hash function). In some implementations, the same hash function is used to construct the trusted binary and generate the trusted binary name. In some implementations, different hash functions are used to construct the trusted binary and generate the trusted binary name (e.g., using different levels of encryption).

(A10) A method according to any one of A1 to A9, wherein the respective function digest for each executable function of the plurality of executable functions is generated using a secure hash algorithm. In some implementations, generating the function digest for the executable function includes applying the secure hash algorithm to all static components of the executable function.

(A11) The method of any of A1-A10, wherein the trust database is stored in memory of the computing device (e.g., as part of the trust store 338). In some implementations, the trust database is a relational database (e.g., a Structured Query Language (SQL) database). In some implementations, the trust store includes trust binaries (e.g., trust binaries 340), a block list (e.g., block list 342), a blockchain for validity authentication (e.g., blockchain information 344), and one or more security policies (e.g., policy information 346). In some implementations, the trust store runs on a virtual machine (e.g., a virtual machine in memory of the computing device 300).

(A12) The method of any of A1-A11, further comprising transmitting the trusted binary to a server system (e.g., trust center 402) remote from the computing device. In some implementations, the server system adds the trusted binary to a whitelist of trusted binaries. In some implementations, the server system transmits the trusted binary to one or more other trust stores.

(A13) The method according to any one of A1 to A12, further comprising transmitting the executable code to a server system separate from the computing device. In some implementations, the trusted binary is a provisionally trusted binary, and the computing system transmits the executable code to the server system for validating the executable code. In some implementations, validating the executable code includes one or more of checking a digital signature, checking a signature certificate path, checking the executable file against one or more blacklists (e.g., local and external), and checking the executable file against one or more whitelists. In some implementations, the computing system receives a notification from the server system in response to transmitting the executable code. In some implementations, in accordance with the notification validating the executable code, the computing system changes the provisionally trusted binary to a (non-provisional) trusted binary. In some implementations, in accordance with the notification validating the executable code, the computing system deletes the program or prevents the program from being executed in the future. In some implementations, in accordance with the notification validating the executable code, the program (or executable code) is added to the block list 342. In some implementations, following notification that the executable code is invalid, the provisionally trusted binary is removed from the trust store and/or added to the block list information.

(A14) A method according to any one of A1 to A13, further comprising: (i) obtaining executable code of a device driver program; (ii) identifying a plurality of executable functions from the executable code; (iii) for each executable function of the plurality of executable functions, generating a respective function digest based on one or more static components of the respective executable function; (iv) constructing a respective trusted binary for each executable function of the plurality of executable functions, the respective digest included therein; (v) generating a trusted binary name by applying a hash function to a header of the executable code; and (vi) indexing the trusted binary in a trust database (e.g., trust store 338) using the trusted binary name.

(B1) In another aspect, some implementations include a method (e.g., method 700) for using a trusted binary. The method is performed on a computing system (e.g., computing device 300) having a memory (e.g., memory 314) and one or more processors (e.g., CPU 302(s)). The method includes (i) executing a trust agent (e.g., trust agent 324); (ii) detecting, via the trust agent, a future execution of a program (e.g., application 322); (iii) in response to the detection, retrieving a trusted binary (e.g., trusted binary 340) for the program from a trust store in memory (e.g., trust store 338); (iv) verifying authenticity of the program by comparing executable code of the program with the retrieved trusted binary for the program; and (v) in accordance with the verified authenticity of the program, The method includes: allowing the program to run; (vi) identifying future executions of executable functions in the program by monitoring the execution of the program; (vii) in response to identifying future executions of the executable function, obtaining a function digest (e.g., function digest 343) corresponding to the executable function from the trusted binary; (viii) verifying the authenticity of the executable function by comparing the executable code of the executable function with the obtained function digest; and (ix) allowing execution of the executable function according to the verified authenticity of the executable function. In some implementations, verifying the authenticity of the program includes verifying the authenticity of one or more shared libraries used by the program (e.g., by comparing with a corresponding trusted binary). In some implementations, obtaining the trusted binary includes generating a binary name for the program and using the generated binary name to look up the trusted binary in a trust store. In some implementations, comparing the executable code of the program with the obtained trusted binary for the program includes generating a digest of the executable code and comparing the generated digest to the obtained trusted binary. In some implementations, comparing the executable code of the executable function with the obtained function digest includes generating a digest of the executable code of the executable function and comparing the generated digest with the obtained function digest.

(B2) The method of B1, wherein executing the trusted agent includes establishing multiple kernel hooks for input/output (I/O) inspection. For example, kernel agent 326 of trusted agent 324 establishes multiple kernel hooks as part of a startup procedure.

(B3) The method of B1 or B2, wherein detecting future execution of the program includes identifying a memory request corresponding to the program. For example, the kernel agent 326 detects a binary file for the program loaded into a memory buffer.

(B4) A method according to any of B1-B3, wherein identifying future executions of executable functions of the program includes intercepting a library function call made by the program. For example, a call to a function in a shared library. In some implementations, in response to detecting a call to a function in the shared library, the trust agent obtains a trusted binary for the shared library and compares a digest of the called function to a corresponding function digest in the trusted binary for the shared library.

(B5) A method according to any one of B1 to B4, wherein monitoring the execution of the program includes monitoring system level operations of the program. In some implementations, the system level operations include one or more of file I/O operations, registry I/O operations, thread start and stop operations, and image load and unload operations.

(B6) A method according to any of B1 to B5, in which the trust agent is executed at startup of the computing system. In some implementations, the trust agent is specific to the operating system of the computing system. For example, a first type of trust agent is used for Windows operating systems, a second type of trust agent is used for Android operating systems, a third type of trust agent is used for iPhone operating systems (iOS), and a fourth type of trust agent is used for Linux operating systems.

(B7) A method according to any one of B1 to B6, in which the trusted agent includes a kernel-level driver (e.g., kernel agent 326). In some implementations, the kernel-level driver is a device driver that operates in ring-0 on the computing system.

(B8) A method according to any of B1 to B7, wherein the trust agent includes a communication service (e.g., communication service 328), a file monitor (e.g., binary monitor 330), an installer (e.g., installer 334), and a dashboard manager (e.g., dashboard module 332). In some implementations, the communication service includes a user mode privileged process that handles communication between the kernel driver, the file monitor, the dashboard manager, and the trust center. In some implementations, the communication service communicates (e.g., periodically) with the trust center to receive policy updates, trusted binary updates, and/or software updates. In some implementations, the file monitor creates, stores, and validates trusted binaries. In some implementations, the file monitor monitors the memory of the computing device to validate programs and functions (and generate corresponding alerts). In some implementations, the file monitor runs as a privileged service with low priority (e.g., uses spare kernel cycles). In some implementations, the dashboard manager allows viewing and exporting alerts, creating new (provisional) trusted binaries, and modifying trust agent configuration and/or policies. In some implementations, the installer probes the computing system, discovers executable files and code, requests trusted binaries (e.g., from the trust center 402), and installs other components of the trust agent (e.g., the kernel agent 326).

(B9) A method according to any one of B1 to B8, wherein executing the trust agent includes (i) loading executable code of the trust agent into memory, (ii) obtaining a trusted binary for the trust agent, and (iii) verifying authenticity of the trust agent by comparing the loaded executable code with the obtained trusted binary. In some implementations, verifying authenticity includes checking for unauthorized access to files, folders, registry settings, and configuration settings of the trust agent (e.g., by performing a proof of identity operation on a blockchain of a trust store). In some implementations, comparing the loaded executable code with the obtained trusted binary includes generating a digest of the loaded executable code and comparing the generated digest with the obtained trusted binary.

(B10) A method according to any one of B1 to B9, further comprising: (i) detecting, via a trusted agent, a future execution of the second program; (ii) determining that the trust store does not contain a trusted binary corresponding to the second program; and (iii) initiating a corrective action in accordance with the determination (e.g., acts 738, 740, and 742 described above with reference to FIG. 7C).

(B11) The method of B10, wherein the corrective action includes one or more of: (i) preventing the second program from executing on the computing system; (ii) storing information about the second program in a forensic log; and (iii) generating a provisional (local) trusted binary for the second program. In some implementations, the forensic log and the corresponding notification are sent to a trust center. In some implementations, a copy of the second program is sent to the trust center for analysis and verification. In some implementations, the verification includes one or more of a virus scan, a block list check, a signature verification, a certificate chain verification, and a vulnerability analysis. In some implementations, the trust center sends a response to the computing system based on the results of the verification. In some implementations, in accordance with the notification validating the second program, the computing system changes the provisionally trusted binary to a (non-provisionally) trusted binary. In some implementations, in response to the notification validating the second program, the computing system removes the second program or prevents the second program from being executed in the future. In some implementations, in response to the notification validating the second program, the second program is added to a block list. In some implementations, in response to the notification validating the second program, the provisionally trusted binary is removed from the trust store and/or added to the block list information.

(B12) The method of B10 or B11, wherein the corrective action includes generating an interim trusted binary, and the method further includes sending executable code of the second program to a trust center (e.g., trust center 510) for validity authentication. In some implementations, in response to sending the executable code to the trust center, the trust agent receives a validity authentication response indicating whether the interim trusted binary should be converted to a trusted binary.

(B13) A method according to any of B10-B12, wherein the corrective action includes applying one or more countermeasures (e.g., the countermeasures described above with respect to operation 752 of method 700). In some implementations, the countermeasures include monitoring for heap spray, reflective injection, read buffering, access to blocked IP addresses, illegal function calls, malicious script (Javascript) execution, privilege tampering, shellcode buffering, and trusted agent tampering.

(B14) A method according to any of B10-B13, wherein the corrective action includes sending a query to a trust center (e.g., trust center 510) for a trusted binary for the second program. In some implementations, in response to the query, the trust center either sends the trusted binary for the second program or sends an indication that the trust center does not include a trusted binary for the second program.

(B15) The method of any of B10 to B14, further comprising obtaining a trust policy for the computing device, and the initiated corrective action is selected according to the trust policy. For example, the computing device is an OT device, and the trust policy dictates that any untrusted execution is prevented. As another example, the computing device is an IT device, and the trust policy dictates that untrusted execution is permitted, but that countermeasures and/or conditions (e.g., monitoring and logging) are applied. In some implementations, the trust policy includes corrective action settings, update settings, and deployment settings.

(B16) A method according to any one of B1 to B15, further comprising: (i) detecting, via a trust agent, a future execution of a second program (e.g., application 322); (ii) responsive to the detection, retrieving a second trusted binary (e.g., trusted binary 340-2) for the second program from a trust store; (iii) identifying one or more modifications to the executable code of the second program based on a comparison with the second trusted binary (e.g., a comparison of a hash of the executable code with a digest of the second trusted binary); and (iv) initiating a corrective action in accordance with the identification of the one or more modifications.

(B17) A method according to any one of B1 to B16, further comprising: (i) identifying a future execution of a second executable function of the program while monitoring the execution of the program; (ii) in response to identifying a future execution of the second executable function, determining that the trusted binary does not include a function digest for the second executable function; and (iii) initiating a corrective action in accordance with the determination.

(B18) The method of B17, wherein the corrective action includes one or more of: (i) preventing execution of the second executable function; (ii) stopping execution of the program; (iii) storing information about the second executable function in a forensic log; and (iv) generating a tentative function digest for the second executable function.

(B19) A method according to any one of B1 to B18, further comprising: (i) identifying a future execution of a second executable function of the program; (ii) obtaining a second function digest corresponding to the second executable function from the trusted binary in response to identifying the future execution of the second executable function; (iii) identifying one or more modifications of the second executable function based on a comparison with the second function digest; and (iv) initiating a corrective action in accordance with the identification of the one or more modifications of the second executable function.

(B20) A method according to any one of B1 to B19, further comprising: (i) detecting, via a trust agent, a future execution of a device driver; (ii) in response to the detection, retrieving a trusted binary for the device driver from a trust store in memory; (iii) verifying authenticity of the device driver by comparing executable code of the device driver with the retrieved trusted binary for the device driver; (iv) allowing execution in the device driver according to the verified authenticity of the device driver; (v) identifying future execution of an executable function in the device driver by monitoring the execution of the device driver; (vi) in response to identifying future execution of the executable function, comparing a function digest of the executable function with one or more function digests in the trusted binary; and (vii) preventing execution of the executable function based on a result of the comparison (e.g., in accordance with not identifying a match between the function digest of the executable function and one or more function digests in the trusted binary).

(C1) In another aspect, some implementations include a method (e.g., method 800) for using blockchain validity authentication. The method is executed on a computing system (e.g., computing device 300) having a memory (e.g., memory 314) and one or more processors (e.g., CPU 302(s)). The method includes (i) accessing a trust store for the computing system, including obtaining a blockchain (e.g., blockchain 350) for the trust store (e.g., trust store 338); (ii) identifying a first change (e.g., a first transaction) to the trust store; and (iii) in response to identifying the first change, obtaining a first block (e.g., transaction block 347-1) including a first encrypted digest (e.g., transaction digest 364) and a first block digest (e.g., block digest 370) for the first change. (iv) identifying a second change (e.g., a second transaction) to the trust store; and (v) in response to identifying the second change, generating a second block (e.g., transaction block 347-2), the second block including a second encrypted digest (e.g., transaction digest 378) for the second change, a second block digest (e.g., block digest 384), and the first block digest (e.g., previous block digest 376), and inserting the second block into the blockchain. In some implementations, each block includes a block digest for the block and a previous block digest for the previous block in the chain (e.g., as shown in FIG. 3C).

(C2) The method of C1, wherein obtaining the blockchain includes obtaining a genesis block of the blockchain (e.g., genesis block 345). In some implementations, the trust store and genesis block are obtained from a trust center (e.g., as part of a trust agent installation process).

(C3) The method of C2, wherein the genesis block includes an encrypted digest of a trusted binary (e.g., a trusted binary pre-installed by a trust center), a block type, a signing certificate, a digital signature, and an encrypted block digest. In some implementations, the genesis block further includes a creation timestamp. In some implementations, the genesis block further includes an empty previous block digest. In some implementations, the signing certificate includes an identity of the block creator (e.g., the trust center 510).

(C4) The method of C3, wherein the first block further includes an encrypted block digest of the genesis block. For example, transaction block 347-1 includes a previous block digest 360 that corresponds to block digest 356 of genesis block 345.

(C5) A method according to any one of C1 to C4, wherein the first block has a block type selected from the group consisting of a trusted binary type, a block list type, a policy type, and a local trusted binary type.

(C6) A method according to any one of C1 to C5, wherein the first change to the trust store includes a change to a trusted binary in the trust store, and the first block has a trusted binary block type. In some implementations, the first change is an addition of a trusted binary to the trust store. In some implementations, the first change is a removal of a trusted binary (or a provisionally trusted binary) from the trust store.

(C7) A method according to any one of C1 to C5, in which the first change to the trust store includes a change to a policy of the trust store (e.g., a change to policy information 346), and the first block has a policy block type.

(C8) A method according to any one of C1 to C5, wherein the first change to the trust store includes a change to a block list of the trust store, and the first block has a block type of the block list. For example, the first change is the addition of a program, application, script, or function to the block list 342.

(C9) A method according to any one of C1 to C5, in which the first modification to the trust store includes adding a local (provisional) trusted binary to the trust store, and the first block has a local (provisional) trusted binary block type.

(C10) The method of any of C1 to C9, further comprising verifying the integrity of the trust store, including using the blockchain to validate the contents of the trust store after generating the second block. In some implementations, the verification occurs according to a trust agent startup procedure.

(C11) The method of C10, wherein verifying the integrity of the trust store further includes validating the blockchain using a proof of identity operation, including comparing a first block digest in the second block (e.g., previous block digest 376) to a first block digest in the first block (e.g., block digest 370).

(C12) A method according to any one of C1 to C11, in which the first encrypted digest is generated using two or more secure hash algorithms (e.g., successive SHA-256 operations).

(C13) A method according to any one of C1 to C12, in which the blockchain is stored in a table in a trust store, with each row in the table corresponding to a block of the blockchain. For example, the blockchain 350 is stored in a table in the trust store 338.

(C14) A method according to any of C1 to C13, wherein each block in the blockchain includes a respective signing certificate and a respective digital signature. In some implementations, the signing certificate of the first block (e.g., signing certificate 372) corresponds to a client certificate stored in a policy table of the trust store. In some implementations, the digital signature of the first block (e.g., digital signature 374) corresponds to an encryption key stored in a policy table of the trust store.

In another aspect, some implementations include a computing system including one or more processors and a memory coupled to the one or more processors, the memory storing one or more programs configured to be executed by the one or more processors, the one or more programs including instructions for performing any of the methods described herein (e.g., A1-A14, B1-B20, and C1-C14 above, and E1-E11 below).

In yet another aspect, some embodiments include a non-transitory computer-readable storage medium storing one or more programs for execution by one or more processors of a computing system, the one or more programs including instructions for performing any of the methods described herein (e.g., A1-A14, B1-B20, and C1-C14 above, and E1-E11 below).

(D1) In yet another aspect, some implementations include a non-transitory computer-readable storage medium including a trust database (e.g., trust store 338) that stores a plurality of trusted binaries (e.g., trusted binaries 340), each trusted binary corresponding to a respective executable program, each trusted binary of the plurality of trusted binaries including (a) a respective trusted binary name (e.g., trusted binary name 341) generated by applying a hash function to a respective header (e.g., ELF header 252) of the respective executable program, and (b) a respective function digest (e.g., function digest 343) for each executable function identified in the respective executable program, each function digest generated based on a respective start address and one or more respective static components of the respective executable function, and the plurality of trusted binaries are indexed into the trust database using their respective trusted binary names. In some implementations, memory 314 includes a non-transitory computer-readable storage medium.

(D2) The non-transitory computer-readable storage medium of D1, wherein the trust database further stores policy information. In some implementations, the policy information includes one or more security policies (e.g., security policy 504-2). In some implementations, the policy information includes a policy table (e.g., including client certificates and encryption keys for computing devices).

(D3) The non-transitory computer-readable storage medium of D1 or D2, wherein the trust database further stores one or more forensic logs (e.g., forensic log 348). For example, the forensic logs include memory buffer information, state information, and process information when untrusted applications and functions are detected.

(D4) A non-transitory computer-readable storage medium according to any of D1 to D3, wherein each respective function digest represents a hashed version of the corresponding executable function. In some implementations, each function digest is generated by applying a secure hash algorithm to a static portion of the corresponding executable function.

(D5) The non-transitory computer-readable storage medium of any of D1 to D4, wherein the trust database further stores blockchain information for authenticating the trust database. In some implementations, the blockchain information includes a blockchain (e.g., blockchain 350) having a block for each change to the trust database.

(D6) The non-transitory computer-readable storage medium described in D5, wherein the blockchain information includes a plurality of blocks (e.g., transaction block 347), each of the plurality of blocks including a block type (e.g., block type 368), a signing certificate (e.g., signing certificate 372), a digital signature (e.g., digital signature 374), and a digest (e.g., transaction digest 364).

(D7) A non-transitory computer-readable storage medium as described in D6, in which the plurality of blocks includes a genesis block (e.g., genesis block 345) and blocks corresponding to each respective change that occurred within the trust store (e.g., transaction block 347).

(D8) A non-transitory computer-readable storage medium according to D6 or D7, in which each block of the plurality of blocks has a block type selected from the group consisting of a trusted binary type, a block list type, a policy type, and a local binary type.

(D9) The non-transitory computer-readable storage medium of any of D6 to D8, wherein for each block of the plurality of blocks, the respective digest is encrypted using at least two secure hash algorithms. In some implementations, the respective digest is encrypted by applying successive secure hash algorithms. In some implementations, the respective digest is encrypted by applying the secure hash algorithm two successive times.

(D10) The non-transitory computer-readable storage medium according to any one of D6 to D9, wherein each block of the plurality of blocks further includes a respective block digest of a previous block in the blockchain. For example, transaction block 347-2 includes a previous block digest 376 that corresponds to block digest 370 of transaction block 347-1.

(D11) A non-transitory computer-readable storage medium according to any one of D1 to D10, wherein the trust database further stores a second plurality of trusted binaries, each trusted binary of the second plurality of trusted binaries corresponding to a respective device driver, and each trusted binary of the plurality of trusted binaries includes: (a) a respective trusted binary name (e.g., trusted binary name 341) generated by applying a hash function to a respective header of the respective device driver; and (b) a respective function digest (e.g., function digest 343) for each executable function identified in the respective device driver, each function digest being generated based on a respective start address and one or more respective static components of the respective executable function, and the second plurality of trusted binaries are indexed in the trust database using their respective trusted binary names.

(E1) In another aspect, some implementations include a method for monitoring network traffic. The method is performed on a computing device (e.g., gateway device 108) having a memory and one or more processors. In some implementations, the method is performed on a computing system (e.g., computing device 300) having a memory (e.g., memory 314) and one or more processors (e.g., CPU 302(s)). The method includes (i) monitoring network packets, (ii) identifying an executable file (e.g., executable file 200) in the network packets, (iii) determining whether a trust store (e.g., trust store 338) includes a trusted binary (e.g., trusted binary 340) corresponding to the executable file, and (iv) performing a remedial action in accordance with a determination that the trust store does not include a trusted binary corresponding to the executable file.

(E2) The method of E1, wherein the corrective action includes one or more of quarantining the executable file, rejecting the executable file, dropping the packet(s) containing the executable file, and redirecting the packet(s) containing the executable file. In some implementations, the corrective action is performed according to an active policy (e.g., policy information 346).

(E3) The method of E1 or E2, further comprising performing a malware check on the network packet, identifying malware in the network packet, and performing a corrective action. In some implementations, the corrective action comprises one or more of quarantining the malware, rejecting the malware, dropping the packet(s) containing the malware, and redirecting the packet(s) containing the malware.

(E4) A method according to any of E1-E3, further comprising identifying restricted information in one or more of the network packets and rejecting the network packets that include the restricted information. In some implementations, the restricted information includes personally identifiable information (PII), confidential information, financial information, etc.

(E5) A method according to any of E1-E4, further comprising profiling the network packets and taking an action on the network packets based on the profiling, including one or more of prioritizing, filtering, and redirecting. In some implementations, taking the action includes filtering the attack and/or reducing the priority of the video data. In some implementations, the action is taken according to an active policy (e.g., policy information 346).

(E6) The method of E5, further comprising presenting a dashboard to the user having information about the profiling and corresponding actions. In some implementations, the dashboard is a user interface. In some implementations, the dashboard allows the user to set or adjust policy rules (e.g., for corrective actions and/or filtering, prioritization, and redirection of network packets).

(E7) A method according to any one of E1 to E6, further comprising identifying a subset of the network packets as corresponding to a particular application, and performing a policy action on the subset of the network packets according to a policy for the particular application.

(E8) A method according to any one of E1 to E7, in which the computing device is a gateway device (e.g., gateway device 108).

(E9) The method of E8, wherein the gateway device includes a network-on-chip (NIC) component. For example, the gateway device includes a smart NIC. In some implementations, the NIC component is a secure intelligent adapter (SIA) network card.

(E10) The method of E8 or E9, wherein the gateway device includes instructions on an x86 appliance or virtual machine.

(E11) A method according to any of E1-E10, wherein the network packets are monitored using one or more machine learning algorithms. For example, Appendix A describes using machine learning to identify unknown attacks in network data.

The terms used in the description of the invention herein are merely for the purpose of describing particular implementations and are not intended to limit the invention. When used in the description of the invention and the appended claims, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. It will also be understood that the term "and/or" as used herein refers to and includes any and all possible combinations of one or more of the associated listed items. It will be further understood that the terms "comprises" and/or "comprising" as used herein specify the presence of stated features, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, steps, operations, elements, components, and/or groups thereof.

For purposes of explanation, the foregoing description has been set forth with reference to specific implementations. However, the above illustrative discussion is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in light of the above teachings. The implementations have been chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling those skilled in the art to best utilize the invention and various implementations with various modifications suited to the particular use contemplated.

Claims (20)

1. A method executed on a computing device having a memory and one or more processors, the method comprising:
Obtaining executable code for a program;
identifying a plurality of executable functions from the executable code;
generating, for each executable function of the plurality of executable functions, a respective function digest based on one or more static components of the respective executable function;
building a trusted binary for the program,
combining the respective digests of each executable function of the plurality of executable functions; and generating a trusted binary name by applying a hash function to a header of the executable code;
and indexing the trusted binary in a trust database using the trusted binary name. The method of claim 1, wherein generating the respective function digest for each function is further based on a respective start address of the respective executable function. The method of claim 1, wherein the executable code is one of a program executable file or an Executable and Linkable Format (ELF) file. The method of claim 1, wherein the one or more static components of each executable function include one or more instructions and/or one or more portions that represent static data. The method of claim 1, wherein the one or more static components of each executable function exclude dynamic address fields. The method of claim 1, wherein constructing the trusted binary further comprises hashing one or more of the program's data directory, the program's section table, and the program's program table. The method of claim 1, wherein the respective function digest for each executable function of the plurality of executable functions is generated using a secure hash algorithm. The method of claim 1, wherein the trust database is stored in the memory of the computing device. The method of claim 1, further comprising transmitting the trusted binary to a server system remote from the computing device. 1. A computing device comprising:
one or more processors;
Memory,
A display and
one or more programs stored in the memory and configured for execution by the one or more processors, the one or more programs comprising:
Obtaining executable code for a program;
identifying a plurality of executable functions from the executable code;
generating, for each executable function of the plurality of executable functions, a respective function digest based on one or more static components of the respective executable function;
building a trusted binary for the program,
combining the respective digests of each executable function of the plurality of executable functions; and generating a trusted binary name by applying a hash function to a header of the executable code;
and indexing the trusted binary in a trust database using the trusted binary name. 11. The computing device of claim 10, wherein generating the respective function digest for each function is further based on a respective start address of the respective executable function. The computing device of claim 10, wherein the one or more static components of each executable function include one or more instructions and/or one or more portions representing static data. The computing device of claim 10, wherein the one or more static components of each executable function exclude dynamic address fields. The computing device of claim 10, wherein constructing the trusted binary further comprises hashing one or more of the program's data directory, the program's section table, and the program's program table. The computing device of claim 10, wherein the respective function digest for each executable function of the plurality of executable functions is generated using a secure hash algorithm. The computing device of claim 10, wherein the trust database is stored in the memory of the computing device. The computing device of claim 10, wherein the one or more programs further include instructions for transmitting the trusted binary to a server system remote from the computing device. A non-transitory computer-readable storage medium storing one or more programs configured for execution by a computing device having one or more processors, a memory, and a display, the one or more programs comprising:
Obtaining executable code for a program;
identifying a plurality of executable functions from the executable code;
generating, for each executable function of the plurality of executable functions, a respective function digest based on one or more static components of the respective executable function;
building a trusted binary for the program,
combining the respective digests of each executable function of the plurality of executable functions; and generating a trusted binary name by applying a hash function to a header of the executable code;
and indexing the trusted binary in a trust database using the trusted binary name. The non-transitory computer-readable storage medium of claim 18, wherein the respective function digest for each executable function of the plurality of executable functions is generated using a secure hash algorithm. The non-transitory computer-readable storage medium of claim 18, wherein the one or more static components of each executable function exclude dynamic address fields.

Images