Patent Description:
A large number of malware attacks of a computer network today result from the ability of a malicious attacker to either inject malicious content into a file system, system registry, application process or thread, or OS kernel of a computer network endpoint, and later execute or extract data using the injected malicious content. These malicious activities can inflict the computer network unbeknownst to the information technology (IT) department of an organization. The process of injecting such malicious content often involves identifying and exploiting poorly designed code that performs inadequate input validation. Current cyber security technologies either attempt to observe malicious content in the network traffic, or screen the behavior of suspicious code in a sandbox before dispatching it to a server for execution. These current technologies do not have the capability to examine file systems, registries, application processes and threads, and OS kernels of a computer network in real-time at a low enough granularity to detect memory corruption in the file systems, registries, application processes and threads, and OS kernels.

Embodiments of the present disclosure apply a fully deterministic approach to detect malicious attacks in real-time on a computer network (customer endpoint). The embodiments monitor, in real-time, operations on compute subsystems including file systems, registries, application processes and threads, OS kernels, and such in the computer network, and attempt to establish trust in relation to these operations. The compute components affected by a monitored operation may be placed in a quarantine state while trust is being established on these compute components. For example, when an actor, such as an application, triggers a file download operation, the embodiments may put the downloaded files in a quarantine state, while establishing trust by examining the downloaded files to validate that the files include genuine data (rather than corrupted data). Embodiments may further put the executable files of the application processes/threads triggering the operation into a quarantine state, while establishing trust by examining the executable files to validate that the application processes/threads are performed by instructions of genuine application code (without malware). The examining of the operation may be performed by applying rule-based policies that establish trust in the files based on security technical implementation guides (STIGS). The rule-based policies may be constructed using a policy language syntax defined in some embodiments.

Another example of establishing trust is by examining a user associated with the monitored operation to determine if the user is logged into the computer network and authorized to perform the operation as indicated in the Directory Server of the computer network. If trust is not established, embodiments execute user-defined callback routines that mitigate results of the operation.

The scope of the invention is determined by the independent claims <NUM> and <NUM>. Embodiments of the present disclosure are directed to computer systems and methods that detect malicious attacks in real time on a computer network endpoint (compute endpoint or customer endpoint). The computer systems and methods monitor a compute endpoint at runtime for an operation being performed on the compute endpoint. In some computer system embodiments, the monitoring of the compute endpoint is performed by a detection engine <NUM>. In some embodiments, the computer systems and methods perform the operation on one of: a file system, a registry, one or more processes, one or more threads, a network card, one or more I/O devices (such as a mouse, keyboard, Bluetooth connected devices, and infrared (IR) connected devices), and memory of the compute endpoint. According to the appended claims, the operation is a create, read, write, update, or delete operation performed on the compute endpoint. In some on the embodiments, the operation is performed on the file system, the registry, a network interface, shared memory, one or more I/O devices, including at least one of: a Bluetooth connected device and an infrared (IR) connected device, the one or more processes, the one or more threads, or the memory of the compute endpoint. In example embodiments, the computer systems and methods perform the monitoring by: (i) scanning at least one of: the file system, hive and keys of the registry, private memory, and shared memory, and (ii) capturing and factoring operating system events and device I/O.

The computer systems and methods further maintain one or more compute components affected by the operation in a quarantine state. In some computer system embodiments, the maintaining of the one or more affected compute components is performed by a detection engine <NUM> or an application and network hardening subsystem. In some embodiments, the one or more affected compute components includes one or more of: an executable file, a script file, a configuration file, a process, a thread, a jump table, a registry hive, a registry key, network traffic, private memory, shared memory, and an operating system kernel. In example embodiments, the computer systems and methods maintaining the one or more affected compute components in a quarantine state includes removing access permissions from the one or more affected compute components.

The computer systems and methods establish trust of the one or more affected compute components. In some computer system embodiments, the establishing of trust is performed by a callback processing engine or an application and network hardening subsystem. In some embodiments, the computer systems and methods establish trust by writing identifying information for the one or more affected compute components to a database of trusted processes and threads. In some embodiments, the computer systems and methods establish trust by one or more actions of: scanning code sections of the one or more affected compute components for known malware, at least one of statically and dynamically analyzing code sections of the one or more affected compute components for cache operations, executing watcher processes that monitor and guard a range of shared memory accessed by the operation, validating the one or more affected compute components against a signature database containing file checksums for the one or more compute components, validating code sections of the one or more affected compute components periodically against a cache of code sections using memory checksums, validating the one or more affected compute components periodically against a cache of jump tables using memory checksums, and applying one or more rule-based policies associated with the operation. In example embodiments, the rule-based policies are configured based on one or more security technical implementation guides (STIGS).

The computer systems and methods remove the one or more affected compute components from the quarantine state, if trust of the one or more affected compute components is established. In some computer system embodiments, the removal from the quarantine state is performed by the application and network hardening subsystem or the callback processing engine. In some embodiments, the computer systems and methods remove the one or more affected components from the quarantine state by restoring the access permissions to the one or more affected compute components. The computer systems and methods execute at least one callback routine to mitigate results of the operation, if trust of the one or more affected compute components is not established. In some embodiments, execution of the at least one callback routine is performed by the callback processing engine or the application and network hardening subsystem. In some embodiments, the execution of the at least one callback routine further comprises: generating one or more events based on each of the one or more actions, correlating the one or more events, and executing the at least one callback routine based on the correlation of the one or more events. In some embodiments, the at least one callback routine is a user-defined callback routine.

In some embodiments, the at least one callback routine triggers one or more protection actions within the computer network (compute) endpoint. In some computer system embodiments, the protection actions within the compute endpoint are performed by a micro-protection engine. These protection actions including: terminating one or more processes associated with the operation, terminating one or more threads associated with the operation, removing injected libraries from memory, terminating or disabling a web session associated with the operation, deleting the one or more affected compute components from disk, moving one or more affected compute instances to a quarantine area, restoring a valid copy of the one or more affected compute components, loading one or more patches to remedy the one or more affected compute components, reporting the operation and the one or more affected compute components, and calling one or more arbitrary user provided custom callbacks. In some embodiments, the at least one callback routine triggers one or more protection actions at a system external to the compute endpoint. In some computer system embodiments, the protection actions at an external system are performed by a macro-protection engine. These protection actions including: shutting down virtual machines of the external system, reporting information related to the operation to the external system, invoking application program interfaces (APIs) to external entities, including at least one of: a router, firewall, packet capture machine, file back device, and such; and performing quarantine actions across the external system, including at least one of collecting logs of the virtual machines, migrating virtual machines to a honeypot subnet, and observing behavior of the virtual machines by collecting data from a computer network.

In some embodiments, the computer systems and methods further determine if a user associated with the operation is a trusted user. The computer systems and methods verify at least one of: (i) the user being logged into the computer network during the operation, and (ii) the user having appropriate permissions to perform the operation and use the compute component. In some of these embodiments, an authentication and authorization subsystem determines if a user is a trusted user.

The teachings of all patents, published applications and references cited herein are incorporated by reference in their entirety.

<FIG> is a diagram of an example trusted execution system <NUM> in embodiments of the present disclosure. The system <NUM> of <FIG> instruments probes into a computer application executed at a customer endpoint (platform) <NUM> by an associated user <NUM>. The probes are software instructions inserts into the computer application (e.g., by a dynamic binary analysis engine or byte code instrumentation engine) at load or runtime time in order to capture activities of the executed computer application at runtime. The system <NUM> instruments the probes (e.g., via an instrumentation engine) on every instance of the executed computer application at the customer endpoint <NUM>, including web servers <NUM>, application servers <NUM>, and database servers <NUM>. The computer application may be running as a compute instance located in a cloud or premise data center. The system <NUM> may instrument the probes on the servers <NUM>, <NUM>, <NUM> implemented in any OS platform, including Windows and Linux, and in any programming language, such as. Net, Java, and PHP. The instrumented probes monitor (in real-time) the network of the customer endpoint <NUM> at runtime, and report operations by applications on file systems, registries, processes/threads, OS kernels, and such, to an analysis engine <NUM>.

The instrumented probes generate events to establish trust of the components affected by the operation on file systems, registries, applications, OS kernels, a network interface card, I/O devices (e.g., mouse, keyboard, Bluetooth devices, and IR devices), memory, and the like, such as an executable file, a script file, a configuration file, a process, a thread, a jump table, a registry hive, a registry key, network traffic, private memory, and shared memory affected by the operations. The compute components may be placed in a quarantine state (e.g., removing access permissions from the compute components, excluding the compute components from a trusted process/thread database, and such) by an application and network hardening subsystem at the customer endpoint <NUM>. The application and network hardening subsystem may perform actions to establish trust with the compute components, including, at least one of: scanning code sections of the one or more affected compute components for known malware, statically and dynamically analyzing code sections of the one or more affected compute components for cache operations, executing watcher processes that monitor and guard a range of shared memory accessed by the operation, validating the one or more affected compute components periodically against a signature database containing file checksums for the one or more compute components, validating code sections of the one or more affected compute components against a cache of code sections using memory checksums, and validating the one or more affected compute components periodically against a cache of jump tables using memory checksums. The instrumented probes execute at the customer endpoint <NUM> with minimal performance impact on the functions of the customer endpoint <NUM>.

The instrumented probes communicate with the analysis engine appliance <NUM> to apply security policies to analyze the generated events to further establish trust in the affected compute components. The analysis engine <NUM> is coupled to an appmap database <NUM> that stores original, uncorrupted copies of some of the compute components. The security policies may be implemented by a customer administration at the user interface <NUM> to the management server <NUM> of the system <NUM> based on security technical implementation guides (STIGS) or other security standards. The security policies define callback routines that the analysis engine appliance <NUM> executes to mitigate results of the operation, if the applied security policies do not establish trust in the affected compute components. Based on the callback routines, the analysis engine appliance <NUM> may terminate one or more processes or threads associated with the operation, move the one or more affected compute components to a quarantine area, restore a valid copy of the one or more affected compute components (e.g., from the appmap database <NUM>), load one or more patches to remedy the one or more affected compute components, report the operation and the one or more affected compute components (e.g., via the user interface <NUM> to the management server <NUM>), and such.

<FIG> is a diagram of an example platform architecture <NUM> of the trusted execution system <NUM> of <FIG> in embodiments of the present disclosure. The platform architecture <NUM> includes the management server <NUM> that has the user interface <NUM>, where customers <NUM> associated with the customer endpoint (platform) <NUM> and product administrators/developers <NUM> of the platform <NUM> may configure and monitor the platform <NUM> as a user. The management server <NUM> may be coupled to data center servers <NUM> for storing and processing configuration data for the platform <NUM>.

Using the user interface <NUM> of the management server <NUM>, the product administrators/developers <NUM> of the platform <NUM>, via an instrumentation engine <NUM>, instrument probes (via network <NUM>) into the customer endpoint (platform) <NUM> of network <NUM>. The instrumented probes may be configured as part of a detection engine <NUM> of the platform at the customer endpoint <NUM>. Using the user interface <NUM> of the management server <NUM>, the product administrators/developers <NUM> of the platform, via a policy platform manager <NUM>, provision probes (via network <NUM>) into the customer endpoint (platform) <NUM> of network <NUM>. The provisioned probes may be configured as part of a detection engine <NUM> of the platform at the customer endpoint <NUM>. Using the user interface <NUM> of the management server <NUM>, the product administrators/developers <NUM> of the platform, through policy database <NUM> and orchestration database <NUM>, orchestrate and provision the RPE (or RPE blade) <NUM> and CPE (or CPE blade) <NUM> via network <NUM> into the analysis engine <NUM> of network <NUM>. These policies are custom defined policies based on the STIGs and other security compliance references. The policies may be constructed using a policy language syntax defined in embodiments. The detection engine <NUM> monitors the customer endpoint <NUM> at runtime and detects in real-time operations to the file system, system registry, application processes and threads, shared memory, OS kernel, and such of the customer endpoint <NUM>. To monitor the customer endpoint <NUM>, the input/output (IO) system blade in detection engine <NUM> runs filesystem CRUD events engine <NUM> to detect CRUD (create, read, write update, and delete) operations to the file system and runs registry CRUD events engine <NUM> to detect CRUD operations to the system registry on the customer endpoint <NUM>. To monitor the customer endpoint <NUM>, the process integrity blade in the detection engine <NUM> runs the process CRUD events engine <NUM> to detect CRUD operations on process/thread memory on the customer endpoint <NUM>. To monitor the customer endpoint <NUM>, the detection engine <NUM> also reviews the OS event viewer <NUM> to detect operations to the OS kernel, application logs, install/uninstall logs.

The detection engine <NUM> runs the executable scanner <NUM> to perform scanning on the disk/secondary storage volume of the customer endpoint <NUM> at the file system level to detect files affected by file system CRUD operations. In some embodiments, the disk/secondary storage volume is primarily a disk partition (logical or physical), but if the customer endpoint <NUM> has multi-disk array configurations (physical or logical) or multiple partitions (physical or logical), the executable scanner <NUM> may also scan secondary partitions or any other storage extension to detect files affected by file system CRUD operations. The executable scanner <NUM> extracts the files in raw portable executable (PE) format or other such format and publishes the extracted files to a file system database <NUM> residing at the customer endpoint <NUM>. The detection engine <NUM> then applies a file system filter <NUM> to the file system database <NUM> to exclude files not of interest from the file system database <NUM>. The file system filter <NUM> may be defined by a user <NUM>, <NUM> via the user interface <NUM> of the management servicer <NUM>. From the file system database <NUM>, the file system CRUD events engine <NUM> generates file system CRUD events for processing the rule processing engine <NUM> (which may be a component of the analysis engine appliance <NUM> of <FIG>) to establish trust in the detected files.

From time to time, a process will attempt to create registry or perform CRUD operations on a filesystem. The filesystem CRUD events engine <NUM> may record all filesystem CRUD operations performed by the process (or owning process), along with context information, as filesystem CRUD events. Using the recorded filesystem CRUD events, the rule processing engine may establish the association of the generated filesystem CRUD events and the owning process performing these operations (e.g., using the process PID). Filesystem events of various classes may be reported to the rule processing engine for further processing. The rule processing engine will use the chain of events indicated by the filesystem CRUD events and associated to the owning process to quarantine and perform protection actions based on rule-based policies. The rule processing engine (via the rule-based policies) may use the context information for correlation and traceability with the process PID.

The detection engine <NUM> runs the registry hive & key scanner <NUM> to perform scanning on registry hives and keys at the customer endpoint <NUM> to detect registry hives, keys, and supporting files affected by registry CRUD operations. A registry hive is a logical group of keys, subkeys, and values in the system registry, and the registry hive has a set of supporting files containing backups of the registry hive's data. For example, the registry hive HKEY_CURRENT_CONFIG has supporting files "System", "System. alt", "System. log", and "System. Each time a new user <NUM> logs onto a device of the customer endpoint <NUM>, a new hive is created for that user <NUM>, along with a corresponding user hive profile file. The hive files are then updated each time a user logs onto a device of the customer endpoint <NUM>. A user's hive contains specific registry information pertaining to the user's application settings, desktop, environment, network connections, and printers. The user's hive profile file is located under the HKEY_USERS key. Most of the supporting files for the user's hive are located in the %SystemRoot%\System32\Config directory. The file name extensions (e.g., alt,. sav, and the like) of the supporting hive files in this directory, or lack of a file name extension, indicate the type of data these files contain.

In some embodiments, the registry hive & key scanner <NUM> detects the registry hives, keys, and supporting files affected by registry CRUD operations by employing API hooking using DLL injection, system call hooking, or a kernel driver (e.g., a ring <NUM> kernel driver). The registry hive and key scanner <NUM> publishes the detected registry hives, keys, and supporting files to a registry database <NUM> residing at the customer endpoint <NUM>. The detection engine <NUM> then applies a registry filter <NUM> to the registry database <NUM> to exclude hives, keys, and files not of interest from the registry database <NUM>. The registry filter <NUM> may be defined by a user <NUM>, <NUM> via the user interface <NUM> of the management servicer <NUM>. From the registry database <NUM>, the registry CRUD events engine <NUM> generates registry CRUD for processing by the rule processing engine <NUM> to establish trust in the detected registry hives, keys, and supporting files.

From time to time, a process will attempt to create registry or perform CRUD operations on registry hives. The registry CRUD events engine <NUM> may record all registry CRUD operations performed by the process (or owning process), along with context information, as registry CRUD events. Using the recorded registry CRUD events, the rule processing engine may establish the association of the generated registry CRUD events and the owning process performing these operations (e.g., using the process PID). Registry operations of various classes may be reported to the rule processing engine for further processing. The rule processing engine will use the chain of events indicated by the registry CRUD events and associated to the owning process to quarantine and perform protection actions based on rule-based policies. The rule processing engine (via the rule-based policies) may use the context information for correlation and traceability with the process PID.

The detection engine <NUM> runs the target process scanner <NUM> to perform scanning on the memory of the customer endpoint <NUM> and detect currently executing processes and threads performing CRUD operations. In some embodiments, the target process scanner <NUM> detects the processes and threads performing CRUD operations by employing API hooking using DLL injection, system calls hooking, or a kernel driver (e.g., a ring <NUM> kernel driver). In some embodiments, the shared memory events IO engine <NUM> also detects the processes and threads performing CRUD operations in shared memory (or other named memory regions), and guards this memory from access by these processes/threads in a shared memory guard blade. The target process scanner <NUM> publishes the processes and threads to a process database <NUM> residing at the customer endpoint <NUM>. The detection engine <NUM> then applies a process filter <NUM> to the processes database <NUM> to exclude processes/threads not of interest from the processes database <NUM>. The process filter <NUM> may be defined by a user <NUM>, <NUM> via the user interface <NUM> of the management servicer <NUM>. In some embodiments, the criteria of the process filter <NUM> may be defined based on import libraries of the customer endpoint <NUM>, including by networking, TCP/IP socket, and access control list functionality defined based on the import libraries. For example, based on the import libraries, the process filter <NUM> may exclude all processes from the process database <NUM> that import network DLLs to perform networking functionalities. From the process database <NUM>, the process CRUD events engine <NUM> generates process CRUD events for processing by the rule processing engine <NUM> to establish trust in the detected processes.

In some embodiments, the detection engine <NUM> profiles the process memory using a whitelisting approach, which determines if the caller of a function is in a whitelisted memory region of the associated process. For example, when a CRUD operation is detected (using API hooks, system call hooks, or such), the hook determines the source address of the caller of a function associated with the operation. The detection engine <NUM> may then profile the CRUD operation to validate that the caller source address and ensure that the intended CRUD operation is originating from pristine process memory in a whitelisted memory region of the process. This validation determines the root of trust of the caller which indicates that the function call is being made from a valid location, rather than some arbitrary or unknown code.

In some embodiments, the detection engine <NUM> may also include a mechanism to control the memory privilege changes performed by a calling process. The calling process may potentially retrieve a handle to any other process in the system by enabling the Debug Privileges using (various APIs) in the calling process. The calling process can then call a set of APIs for the Debug Privileges to obtain a handle using PROCESS_ALL_ACCESS or such. The detection engine <NUM> may ensure that the protection actions are enforced based on the policies of the rules processing engine <NUM> when such memory privilege changes are performed. Similarly, the detection engine <NUM> may also include a mechanism to control the memory access changes performed by a calling process. For example, the detection engine <NUM> may include instrumentation at APIs that may be accessed by the calling process to change access control list (ACL) behavior of a memory region, such as virtualprotectxx in windows and mprotectxx in Linux platforms. The detection engine <NUM> or other customer endpoint <NUM> component may ensure that the protection actions are enforced based on the policies of the rules processing engine <NUM> when such memory access changes are performed.

The detection engine <NUM> also extracts the jump table region from each process and determines the process name, process identifier, and metadata (starting address, checksum, and size of the jump table region, and such), which are stored in an intermediate jump table database <NUM>. The detection engine <NUM> may periodically compute a jump table checksum for a monitored process, which is compared to the jump table checksums stored in the intermediate jump table database <NUM>. If the jump table of the monitored process is altered (i.e., does not match the stored checksums), the detection engine <NUM> generates jump table input/output events <NUM> for processing by the rule processing engine <NUM> to establish trust in the monitored process. Further, a jump table may typically have "read only" permission, if other operations (besides read operations) are being performed on the jump table regions, the detection engine <NUM> also may immediately move the jump table to a quarantine area.

The detection engine <NUM> further extracts code sections for each process and determines the process name, process identifier, and metadata (starting address, checksum, and size of the jump table region, and such), which are stored in an intermediate code integrity database <NUM>. The detection engine <NUM> may periodically compute a checksum for the code sections of a monitored process, which are compared to the checksums for the code sections stored in the intermediate code integrity database <NUM>. If a code segment is altered (i.e., does not match the stored checksums), the detection engine <NUM> generates a code integrity event <NUM> for processing by the rule processing engine <NUM> to establish trust in the monitored process.

The detection engine <NUM> may also extract networking operations for each process (including process name, process identifier, and metadata such as source IP, source port, destination port, and protocol), which are stored into a network database <NUM>. When monitored processes attempt to connect or be connected to by a remote user, the detection engine <NUM> compares the processes to the network database <NUM>. If the processes do not match data in the network database <NUM>, the detection engine <NUM> generates network CRUD events <NUM> for processing by the rule processing engine <NUM> to establish trust in the monitored process.

The detection engine <NUM> also collects (gathers) logs for a configured set of OS events from the OS event viewer <NUM>. The set of events and associated processing rules may be defined by a user <NUM>, <NUM> via the user interface <NUM> of the management servicer <NUM>. The event logs are stored in an intermediate events database <NUM>. The event extractor <NUM> reviews and harvests the event logs from the event database based on rules defined for the set of events, and may generate OS events for processing by the rule processing engine <NUM> to establish trust in the monitored process. For example, based on the rules, the event extractor may generate an OS event if the event logs indicate the sequence of: (<NUM>) a process starts and calls other processes, (<NUM>) a Windows installer activity occurs, (<NUM>) a Windows update agent activity occurs, (<NUM>) a Windows service synchronization activity occurs, and (<NUM>) the application crashes.

The platform <NUM> also includes the application and network hardening (ANH) subsystem (or blade) <NUM> configured at the customer endpoint <NUM>. By executing one or more malicious operations on the file system, system registry, application processes and threads, OS kernel, a remote malicious user can trick an application at the customer endpoint <NUM> into writing malicious files (executables, scripts, configuration files, data files, and such) to disk or maliciously altering such files (e.g., inserting malicious code sections or instructions, changing file permissions, and such), or deleting such files. Later the remote malicious user can use the malicious files affected by the malicious operations to initiate a process to conduct malicious activities, such as connecting to customer endpoint servers as part of an advance persistent threat (APT) attack, encrypting files on disk, discovering user passwords, and such.

The ANH subsystem <NUM> tracks a process, user, and remote endpoint associated with a file system, registry, or other memory operation that creates, reads, updates, or deletes a file at the customer endpoint <NUM>. For example, the file may be a downloaded executable file used to initiate an application process (e.g., for an interpreted application). If the operation is performed by a user <NUM> other than an authenticated administrator <NUM>, <NUM>, the file is viewed with suspicion until trust is explicitly established with the file. The ANH subsystem <NUM> may maintain the file in a quarantine state until trust can be established with the file. For example, the file operation may be written as a record in the ANH database <NUM> with a "trust level" field set to "unverified. " For further example, the access permissions for the file may be removed, such as by moving the file to an access group with no access permissions.

The ANH subsystem <NUM> may then establish trust with the file. The ANH subsystem <NUM> may establish trust by scanning the files using a third-party vendor scanner (e.g. Virus Total, Reversing Labs, and the like) for malware. The ANH subsystem <NUM> may further establish trust by checking signatures (e.g., checksums) of the file (or segments of the file) against one or more file integrity databases, such as the file signature repository maintained by the ANH subsystem <NUM>. The ANH subsystem <NUM> may also establish trust by statically analyzing code sections of the file for inappropriate cache instructions. The ANH subsystem <NUM> may also check the trust and revision history of the file as previously recorded in the ANH database <NUM>. If trust is established by the ANH subsystem <NUM>, in the file operation record of the ANH database <NUM>, the "trust level" field may be changed to "verified" and the access permissions for the file may be restored, e.g., moving to an access group associated with the user. If trust is not established, the ANH subsystem <NUM> generates an event indicating the untrusted state of the file, which is processed by the rule processing engine <NUM> to establish trust in the file and associated process.

The platform <NUM> also includes the authentication/authorization subsystem (blade) <NUM> configured at the customer endpoint <NUM>. The authentication/authorization subsystem <NUM> uses the process credentials of an operation performed on a file system, registry, or other memory operation of the customer endpoint <NUM> to determine the user performing the operation. The authentication/authorization subsystem <NUM> may determine the process credentials of the user by intercepting calls made to the Directory Server <NUM> coupled to the customer endpoint <NUM>. The authentication/authorization subsystem <NUM> then establishes if the user is a trusted user (e.g., administrator).

To establish trust, the authentication/authorization subsystem <NUM> may determine at the Directory Server <NUM> that the user is logged into the computer network during the operation. To establish trust, the authentication/authorization subsystem <NUM> may also determine at the Directory Server <NUM> the permissions or other credential(s) associated with the user, and whether the associated permissions are appropriate to perform the operation on the file system, registry, or other customer endpoint memory. This authentication/authorization subsystem <NUM> may maintain a record in the authentication/ authorization database <NUM> on the users actively logged into the customer endpoint <NUM>, the users' associated permissions, and other user credentials rather than repeatedly checking the Directory Server <NUM>. If the user performs an operation but the user is not logged into the computer network or does not have permissions/credentials to perform the operation, the authentication/authorization subsystem <NUM> generates an event indicating the untrusted state of the user, which is processed by the rule processing engine <NUM> to establish trust in the associated process (and may quarantine the components affected by the operation).

The platform architecture <NUM> also includes the Rule Processing Engine (RPE) <NUM>, which is communicatively coupled via network <NUM> to the customer endpoint <NUM>. A user <NUM>, <NUM> may configure rule-based policies at the user interface <NUM> of the management server <NUM>, and other standard rules may be provided as part of the platform <NUM>. The rule-based policies may be configured based on security technical implementation guides (STIGS) or other security standards for file systems, registries, applications, OS kernels, and the like. These rules can then be used to detect anomalies in runtime and prevent, isolate, and/or terminate misbehaving application instances. The event rule expressions of the configured rule-based policies are stored in the event policy database <NUM> of the RPE <NUM>. Such expressions specify: (<NUM>) a rule expression structure that defines a rule that corresponds with the rule expression structure, (<NUM>) conditions for evaluation with respect to occurrences of events received at the RPE <NUM> that correspond with the rule expression structure, and (<NUM>) actions for performance in response to the received events satisfying all the conditions. The list of different policy operands used in received events of different application instances associated with a policy is stored in the policy operands database <NUM>. For example, for a particular application, the policy operand may be directory path == "C:\Windows\System32", file extension == *.

Configuration parameters used to analyze received events of different application instances associated with a policy are stored in the config registry database <NUM> of the RPE <NUM>. The configuration parameters consist primarily of two parts, the schema that must be adhered to by the events of an application instance, and the list and order of rules that must be applied to the events of the application instance. The policy callbacks database <NUM> of the RPE <NUM> stores a callback that implements the checks of a given policy to determine the outcome of a security decision reflected in the given policy. An example of a policy callback may be to check if a runtime file system FILE_WRITE event is not outside of the web rot of the application. A check of the callback returning success indicates that no security violation has occurred, whereas returning a failure indicates a security policy violation. There may be embodiments where detecting an intrusion requires multiple events to occur within a certain period of time. In order to verify rules of a policy that span multiple events in time, the events need to be stored. The event temp store <NUM> of the RPE <NUM> stores these events, along with periodically monitoring for and purging stale stored events.

The policy selection and dispatch component <NUM> of the RPE <NUM> asynchronously processes (using a Node. js architecture with multi-threaded input/output queues) the events generated by the event engines <NUM>-<NUM> at the customer endpoint <NUM>. The policy selection and dispatch <NUM> selects the rule-based policies to process one or more of the events <NUM>-<NUM> based on the rules parameters stored in the associated rules databases (event policy <NUM>, policy operand <NUM>, config registry <NUM>, policy callback <NUM>, and event temp store <NUM>). The platform architecture <NUM> also includes the callback processing engine (or blade) <NUM>, which is communicatively coupled via network <NUM> to the customer endpoint <NUM>. The policy execution cluster <NUM> (using a Node. js architecture) of the callback processing engine (CPE) <NUM> executes the rule-based policies selected by the RPE <NUM> to process one or more of the events generated by events engines <NUM>-<NUM>. The policy execution cluster <NUM> is also responsible for selecting the correct execution nodes to execute one or more rule-based policies for a given event (or multiple related events). Using the user interface <NUM> of the management server <NUM>, the product administrators/developers <NUM> of the platform, through policy database <NUM>, publish and update execution callbacks <NUM> of the CPE <NUM> (via network <NUM>) into the analysis engine <NUM> of network <NUM>.

Based on execution of the rule-based policies, the policy execution cluster <NUM> may determine protective actions/outcomes to be performed related to the given event (or events). The protective actions/outcomes may be based on correlating the results of executing multiple rule-based policies for one or multiple different events generated by events engines <NUM>-<NUM>. These protective actions/outcomes may include actions at the customer endpoint, including: terminating one or more processes or threads associated with the event, terminating or disabling a web session associated with the event, deleting the one or more affected compute components from disk, moving the one or more affected compute components to a quarantine area, restoring a valid copy of the one or more affected compute components, loading one or more patches to remedy the one or more affected compute components, and reporting the operation and the one or more affected compute components. These protective actions/outcomes may include actions at a system external to the customer endpoint, including: shutting down virtual machines of the external system, reporting information related to the operation to the external system, and performing quarantine actions across the external system, including at least one of collecting logs of the virtual machines, migrating virtual machines to honeypot subnet, and observing behavior of the virtual machines by collecting data from computer network. If the execution of the rule-based policies indicates that the event is a valid operation to the customer endpoint <NUM>, the actions/outcome may include removing the files, processes/threads, memory, and such associated with the event from the quarantine state at the customer endpoint <NUM>.

The policy execution cluster <NUM> of CPE <NUM> queues the determined actions via the Outcome (ActiveMQ) queue <NUM>. If a determined protective action needs to operate on a file, process/thread, or memory within the customer endpoint <NUM>, the micro-protection engine <NUM> is called to execute such through the platform protection agent <NUM> at the customer endpoint <NUM>. If a determined protective action needs to operate on a subsystem external <NUM> from the customer endpoint <NUM> (such as cloud servers), the macro-protection engine <NUM> is called to execute such actions at the external subsystem <NUM>.

The platform architecture <NUM> may also include incident response and forensics (IRF) components that perform correlation on detected events based on a process identifier (e.g., PID). The platform <NUM> may maintain historical data in an historical database of the process events and this may be used by the IRF components to perform incident analysis on the detected event. This database of process events may be traversed based on a given PID for retrieving historical data associated with a process associated with the PID. For example, the detection engine <NUM> or process CRUD events engine <NUM> may capture all the process aware events or incidents (registry, files, memory accesses, and such) and store these events/incidents in the IRF historical database linked to the PIDs associated with these events/incidents. The IRF components may then access the IRF historical database to perform forensics on the events/incidents in regard to a particular process event and respond to the particular process event based on the performed forensics. For example, the detection engine <NUM> may capture all the process aware events for a user session in the IRF historical database, and the IRF components may perform incident analysis on a currently detected event based on the history of the captured process aware events ordered by PID.

The rule-based policies executed by the callback processing engine (CPE) <NUM> may be enforced at process or registry or filesystem granularity in embodiments of the platform <NUM>. In some embodiments, the CPE <NUM> may execute inclusion and execution policies in which INCLUSIONS and EXCLUSIONS criteria are applied to the customer endpoint <NUM>. External entities that govern (e.g., customers via the CMS UI <NUM>) exclusion criteria or inclusion criteria may override the policy-based actions to whitelist the platform resources. An example is the CPE <NUM> invoking the macro protection engine <NUM> or micro protection engine <NUM> to perform a protection action of disallowing terminating a process since the customer has provided an exclusion policy specifying a whitelisted set of processes to be excluded from any such policy actions enforcement. Another example is the CPE <NUM> invoking the macro protection engine <NUM> or micro protection engine <NUM> (via the platform protection agent <NUM>) to perform a protection action of disabling the permissions of a file which has just been downloaded by the process based on applying an inclusion policy to CRUD events generated in relation to operations on the file.

In some embodiments, the CPE <NUM> may execute process level policies based on process CRUD events or other process level actions on the customer endpoint <NUM>. For example, the process CRUD events engine <NUM> may detect a process CRUD event which is transported to the analysis engine <NUM> in user mode. The CPE <NUM> of the analysis engine <NUM> may process the detected event by performing certain checks and investigations based on one or more defined process level policies. Based on the one or more process level policies, the CPE <NUM> may identify and rank the process associated with the detected event to be an attack vector and communicate with the macro protection engine <NUM> or micro protection engine <NUM> (via the platform protection agent <NUM>) to perform protection actions, such as terminating the associated process. In some embodiments, the CPE <NUM> transfers the policy action to a kernel driver (e.g., a ring <NUM> kernel driver instrumented at the customer endpoint <NUM>) which performs the termination of the associated process.

In some embodiments, the CPE <NUM> may execute file level policies based on file CRUD events or other file level actions on the customer endpoint <NUM>. The CPE <NUM> may check the reputation of any file created or otherwise affected by a process before enabling the access control lists (ACLs) of the file. The detection engine <NUM> may place the file in a quarantine area on the customer endpoint <NUM> until the CPE <NUM> performs checks based on one or more defined file level policies to establish trust of the file. Once the CPE <NUM> establishes trust of the file then the ACLs for the file may be enabled, and/or the file may be allowed to execute. In some embodiments, the checks may include validating signatures, certificates, and ACLs, then based on the ranking of the file according to these checks, the CPE <NUM> invokes the macro protection engine <NUM> or micro protection engine <NUM> (via the platform protection agent <NUM>) to perform protection actions defined by one or more file level policies.

For example, the filesystem CRUD events engine <NUM> may detect a filesystem CRUD event which is transported to the analysis engine <NUM>. The CPE <NUM> of the analysis engine <NUM> may process the detected event by performing certain checks and investigations based on one or more defined file level policies. Based on the one or more file level policies, the CPE <NUM> may identify and rank the process and file associated with the detected event to be an attack vector and communicate with the macro protection engine <NUM> or micro protection engine <NUM> (via the platform protection agent <NUM>) to perform protection actions, such as terminating the associated process or deleting the associated file. In some embodiments, the CPE <NUM> transfers the policy action to a kernel driver (e.g., a ring <NUM> kernel driver instrumented at the customer endpoint <NUM>) which performs the termination of the associated process or deletion of the associated file.

In some embodiments, the CPE <NUM> may execute registry level policies based on registry CRUD events or other registry level actions on the customer endpoint <NUM>. For example, the registry CRUD events engine <NUM> may detect a registry CRUD event which is transported to the analysis engine <NUM>. The CPE <NUM> of the analysis engine <NUM> may process the detected event by performing certain checks and investigations based on one or more defined registry level policies. Based on the one or more registry level policies, the CPE <NUM> may identify and rank the process associated with the detected event or registry hive/key/file associated with the detected event to be an attack vector and communicate with the macro protection engine <NUM> or micro protection engine <NUM> (via the platform protection agent <NUM>) to perform protection actions, such as terminating the associated process or deleting the associated registry hive/key/file. In some embodiments, the CPE <NUM> transfers the policy action to a kernel driver (e.g., a ring <NUM> kernel driver instrumented at the customer endpoint <NUM>) which performs the termination of the associated process or deletion of the associated registry hive/key/file.

In some embodiments, vSTIG (Virsec Security Technical Implementation Guide) may be used to implement rule-based policies and publish the policies to the policy database <NUM>. These policies, when implemented, enhance security for software, provide architectures to further reduce vulnerabilities, and define protection actions performed to enforce activities on the platform <NUM>. These STIGs will determine various policies that include rules selected by the RPE <NUM> and executed by the CPE <NUM> of the platform <NUM>. The management server <NUM>, which may be implemented as a web interface, pushes the vSTIG Policies in to the analysis engine <NUM> (RPE <NUM> and CPE <NUM>). These policies provide protection fixes or actions based on the defined vSTIG. The CMS <NUM> of the management server <NUM> publishes the policy database for use by the RPE <NUM>/CPE <NUM> to bootstrap with the policies. In some embodiments, a policy language syntax for defining the vSTIGs (e.g., by user <NUM> and developers <NUM>) are employed in the platform <NUM>.

<FIG> are block diagrams of example methods 330a-d for detecting operations at a customer endpoint <NUM> in embodiments of the present disclosure. <FIG> and <FIG> depict API hooking methods 330a and 330b, respectively, for detecting operations at the customer endpoint <NUM>. As shown in <FIG>, the detection engine <NUM> installs a DLL launcher <NUM> at the customer endpoint <NUM>. The DLL launcher <NUM> attaches <NUM> the detection engine <NUM> to the customer endpoint <NUM> and allocates <NUM> memory for the DLL. The DLL launcher then copies <NUM> the DLL to the allocated memory at a determined address and executes <NUM> the DLL. The executing DLL implements/injects <NUM> hooking code, such as a hooking application program interface (API), into a monitored application <NUM>. The hooking code includes all routing mechanisms between the actual interface of the monitored application and the caller.

As shown in <FIG>, in the method 330b, a function call <NUM> of the monitored application <NUM> during runtime would normally execute a jump instruction <NUM> to the RegCreateKeyEx function of the import address table (IAT) <NUM>. The injected hooking <NUM> intercepts the instruction and redirects <NUM> the execution to the hooking code <NUM> to capture the content of the call and, based on the content, generate events for processing by the RPE <NUM>. The hooking code <NUM> then transfers control back to the normal RegCreateKeyEx function <NUM>.

In other embodiments, a system calls hooking method may be used for detecting operations at the customer endpoint <NUM>. In these embodiments, the detection engine <NUM> instruments system calls to intercept an instruction and extract the calling context information of the intercepted instruction.

<FIG> illustrates a method 330c for detecting operations at a customer endpoint <NUM> in an embodiment. <FIG> depicts a ring <NUM> kernel driver <NUM> that may be installed at the customer endpoint <NUM> to detect registry and application process/thread operations. The ring <NUM> kernel driver <NUM> registers callbacks provided by the OS (e.g., Windows) subsystem, and receives notifications from the OS subsystem whenever a registry CRUD operation occurs. The ring <NUM> kernel driver <NUM> communicates with a ring3 listening agent <NUM> via IOCTL system calls 372a-b. The ring <NUM> kernel driver <NUM> synchronously transports the notifications to the ring3 listening agent <NUM>, which listens to the notifications to detect the registry CRUD operations and generate events for processing by the RPE <NUM>.

<FIG> depicts a method 330d of detecting and guarding access by processes and threads to shared memory (or other named memory) regions. An application (such as a rogue application <NUM> or authentic application <NUM>) may read/write to shared memory <NUM>. An access driver <NUM> configures memory watchers that monitor a configured range of shared memory regions <NUM> for operations by untrusted processes. A hardware/ software signal <NUM> of a watcher notifies the driver <NUM> when one or more pre-specified regions of memory <NUM> are accessed (read and/ or write). For example, the watcher may set a bit in an associated hardware register to put the application in single step mode, and mark a monitored share memory region with read only permission, which causes a signal or exception to be generated when an application process/thread attempts to perform an operation on the shared memory region. Once generated, the watchers may then re-mark the memory region to return write permissions and continued execution of the application process/thread. An access monitor process <NUM> may record the operation on the shared memory region and validate the operation (memory access). If the operation is not validated, the access monitor may generate reports and alerts <NUM> on the operation to a user interface. Otherwise, the access monitor <NUM> may write the application process/thread in a monitored database <NUM>, along with information on the process/thread for the process/thread launcher <NUM>, as a trusted process.

<FIG> is a block diagram of an example event indexing framework <NUM> for a rule processing engine, e.g., the RPE <NUM>, in embodiments of the present disclosure. The event indexing of <FIG> is a multi-level indexing approach where each node represents <key,value> pair and when the traversal of the indexing reaches a leaf node, the traversal indicates a stack of rules along with policy operands and a callback executable. This is a flexible method of adding events, sub-events, sub-sub-events, and such into the rule processing engine (or blade) <NUM>. These events, sub-events, and such of the rule processing engine (RPE) <NUM> are configured based on the definition of components for the customer endpoint <NUM>. For example, for a file system of a customer endpoint <NUM>, the rule processing engine <NUM> may have FILE_CREATE (event) and FILE_MODIFY (sub-event).

In <FIG>, each event (e.g., MAP <NUM><NUM>) can be defined into different classes of event (file system, registry, process, and the like) and sub-event (e.g., MAP <NUM><NUM>) can be defined in a class based on the CRUD operations. The event classes and subclasses determine the traversal through the multi-level index tables and the resulting leaf node of the traversal indicates a stack of rules expressions <NUM> to process for the event (<NUM>/<NUM>) classes/subclasses. The stack of rule expressions <NUM> are processed by event class callbacks at the callback processing engine <NUM> to determine outcome/actions to be performed based on the event (<NUM>/<NUM>) classes/subclasses.

<FIG> is a block diagram of an example rule processing framework <NUM> in embodiments of the present disclosure. In this framework <NUM>, the RPE <NUM> is the orchestrator/master controller. The RPE <NUM> asynchronously pushes selected rule-based policies for received events to a CPE cluster of the CPE <NUM> (as async callbacks <NUM> and <NUM>). The RPE <NUM> asynchronously pushes selected rule-based policies to the CPE cluster of the CPE <NUM> with node graphs embedded. In some embodiments, the RPE <NUM> performs for the state management of events processed through application of the rules in the pushed rule-based policies. In other embodiments, the CPE <NUM> performs such state management. In the former embodiments, CPE <NUM> communicates the newest state of the events processed back to RPE <NUM> through callbacks <NUM> and/or <NUM> so that RPE <NUM> can maintain the overall tracking and state management of the events. The CPE <NUM> processes a given event based on the pushed rule-based policies in a cluster at a node according to the embedded node graph, such that each node cluster executes an individual agent to perform the rule processing (e.g., applying R1, R2, through, RN) for the given event. CPE rule graph processing uses an execution pattern defined by the node graph by which events are processed in a distributed and scalable manner. <FIG> depicts a CPE cluster instance <NUM> that processes an event (via the rules of a rule-based policy) according to a load balanced and scalable implementation.

<FIG> is a block diagram of a distributed, load balancing implementation <NUM> of the platform architecture of <FIG>. In <FIG>, multiple customer endpoints <NUM> are grouped by the type of service performed by the customer endpoints <NUM>. Each service 661a, 661b, 661n is comprised of one or more service instances. The detected and generated events (e.g., CRUD events) generated for each service 661a, 661b, 661n are pushed onto a first message broker <NUM>, which is a highly scalable and distributed event handler that asynchronously processes high volumes of events of a service in real-time. From a first message broker <NUM>, the events of a service are consumed by an instance, e.g., 238a-n, of the RPE <NUM>. The RPE <NUM> is bootstrapped with a set of rules (e.g., rule-based policies) which are applicable to one or more types of service. As an event of a service is received, an RPE instance 238a-n checks if any of the policies configured at the RPE <NUM> are applicable. If none of the configured policies apply, the RPE instance, e.g. 238a-n, ignores the service event.

If one or more policies apply, an RPE instance (238a-n) pushes the service event onto a second message broker <NUM>, which is also a highly scalable and distributed event handler (pipeline) that asynchronously processes high volumes of events of a service in real-time. The RPE instance pushes the service event, along with the application policies and computed cluster node graphs to execute the policy rules. From a second message broker <NUM>, the service event (along with policies and cluster node graph) is consumed by the CPE <NUM>. The CPE <NUM> queues and processes the consumed service events using a job collector <NUM>, job scheduler <NUM>, and resource manager <NUM> architecture. Based on the cluster node graphs, the CPE <NUM> can select the correct execution node and cluster agent to be used to execute the policy rules for the policy event (e.g., file system <NUM>, registry <NUM>, network <NUM>, and such). When all the rules for a policy are executed and correlated, the result is published to a micro-protection engine <NUM> for taking further protection actions at the appropriate customer endpoint or to a macro-protection engine <NUM> for taking further protection actions at an external system. The protection actions taken by the micro-protection engine include: terminating one or more processes associated with the operation, terminating one or more threads associated with the operation, removing injected libraries from memory, terminating or disabling a web session associated with the operation, deleting the one or more affected compute components from disk, moving one or more affected compute instances to a quarantine area, restoring a valid copy of the one or more affected compute components, loading one or more patches to remedy the one or more affected compute components, reporting the operation and the one or more affected compute components, and calling one or more arbitrary user provided custom callbacks. The protection actions taken by the macro-protection engine include: shutting down virtual machines of the external system, reporting information related to the operation to the external system, invoking application program interfaces (APIs) to external entities, including at least one of: a router, firewall, packet capture machine, file back device, and such; and performing quarantine actions across the external system, including at least one of collecting logs of the virtual machines, migrating virtual machines to honeypot subnet, and observing behavior of the virtual machines by collecting data from computer network.

Herein below, in relation to <FIG>, functionality and implementation details are provided for a database, e.g., a Virsec Infrastructure Hardening Database (VIHDB), that is implemented and employed in embodiments. In an example embodiment, the IHDB is used for storing the policies which are built at either by a security platform provider, e.g., Virsec central policy management system, or at user's central policy management system as depicted in <FIG>. These IHDBs are used for setting up and provisioning the policies on the user's servers. Further details regarding embodiments of the IHDB are described herein below.

In relation to <FIG>, condition refers to a conditional statement (such as a conditional statement of STIGs) which results in an outcome. According to an embodiment, each condition has its own set of parameters and an action to be performed on them. Moreover, according to an embodiment, rules are statements presented by a user, e.g., customer which are the conditional statements explained in English language (English language representation of the conditional statements). Rules specify a protection action to take place depending on the outcomes of specified conditions. In an embodiment, action is a task that is performed (by checking the conditions) to obtain an outcome, i.e., finding. Findings are the outcome of an action. A finding is the result set of a condition evaluation specified by a user. According to an embodiment, region is the location where an action is performed. Regions can be a file for a file system event, a registry hive for a registry event, or operations on any process for a process event. According to an embodiment, the region depends on the actions that need to take place.

<FIG> is a block diagram illustrating stages 770a-e involved in an infrastructure hardening database (IHDB) according to an embodiment. The design stage 770a is generally handled by developers, e.g., an engineering team providing the IHDB. In the design stage 770a, benchmarks are turned into actionable STIGs, developer recommendations are turned into actionable STIGs, and policies are extracted from the STIG DB <NUM> and custom STIG DB <NUM>. Further, in the design stage 770a, policies are added into the Virsec Infrastructure Hardening Database (VIHDB) <NUM> and policies are broken into sets of rules and rules are broken into conditions. Further still, in the design stage 770a, final actions for each rule are set-up. In the design stage 770a, STIGs are defined and stored as PDFs in a Standard STIG Document Database (STDDB) <NUM>. The design phase 770a creates an XML/JSON format of the STIGs and stores the XML/JSON format of the STIGS in the VIHDB <NUM>, i.e., policy database. The design phase 770a may also process custom STIGs, which are customer specific STIG documents <NUM> provided by customers and stored in the customer specific STIGs database <NUM>. The design stage 770a may also configure the custom IHDB <NUM> which is an IHDB with added custom STIG policies.

In the pre-deployment stage, a provider of the IHDB, e.g., a sales engineer <NUM>, interacts with a customer and collects STIGS <NUM> if there are any more STIGs <NUM> that are required to be added specifically by the customer.

The deployment stage 770c is the stage where a security platform according to an embodiment, e.g., the platform <NUM>, is deployed on a customer's application and a local repository of an infrastructure hardening database and a local infrastructure hardening database <NUM> are created.

In embodiments, there can be policies which are to be executed before runtime events are triggered. For example, checking and changing basic settings in a httpd. conf file before any of the events access the file. In the static stage 770d, such policies (policies that should be executed before runtime) are executed.

During the runtime stage 770e, the customer's application with installed security platform, e.g., the platform <NUM>, starts running with a customer's data. In the run time stage 770e, triggered OS events are matched against the created policies and a final action is carried out on all satisfied events.

<FIG> is a block diagram depicting a policy schema implemented in embodiments. The infrastructure hardening database <NUM> comprises multiple policies 881a-n. Each policy 881a-n can be considered as a STIG. A single policy, e.g., policy 881a, can have multiple rules, e.g., the rules 882a-n, and a single rule, e.g., 882a, can have one or more conditions, e.g., 883a-n. Each condition is associated with a set of parameters, an action, and a region. In an embodiment, a region can be either a file, process, or any registry hive, on which the action is to be performed. The parameters can be event operands (provided during runtime) as well as policy operands (provided by the policy) or a combination of both event operands and policy operands. The outcome of the actions are findings and a decision is to be made depending on the outcome. A final finding is a finding which decides whether a customer specified final action is to be performed or not.

<FIG> is diagram of a state machine illustrating a workflow <NUM> of a Trusted Execution Security Policy Platform (TESPP) according to an embodiment. The design, i.e., policy set-up, state <NUM> is responsible for creating policies from all available STIG STDs. The STIGs can be from benchmarks like CIS (Center for Internet Security) or custom STIGs from a provider of the security platform. Once the policies are created, they are stored into an infrastructure hardening database, e.g., the VIH DB <NUM>.

During the design state <NUM>, there is also a requirement to setup the graph <NUM> for each rule <NUM> within a policy. In the graph <NUM>, each circle 1011a-f signifies a single event that is required to be triggered, before applying the policy associated with the event. In embodiments, some events involve order, and some do not. This is depicted in the graph <NUM> as serial events <NUM> and parallel events <NUM>.

The parallel events axis <NUM> indicates that the events are required to occur, but may occur out of order before applying the policy. The serial events <NUM> are the exact opposite. The serial events <NUM> must be triggered in the same order (from left to right or vice versa, however defined) and when the events occur out of order, during runtime, the chain has to be dropped, and the execution waits for the same chain to start all over again. Once, all the events are triggered, the policy execution takes place. In the setup state <NUM>, the graph <NUM> is setup and the runtime state <NUM> is involved in checking the order of events triggered.

Returning to <FIG>, in the pre-deployment state <NUM>, a provider of the security platform, e.g., a sales engineer, interacts with a user of the security platform, e.g., a customer, to gather any customer specific STIGs. These customer specific STIGs are sent back to the design state <NUM> where policies are generated out of the customer specific STIGs. These policies are added into the VIH DB. This cycle continues until all customer specified STIGs are added to an infrastructure hardening database, e.g., the VIH DB <NUM>.

During the deployment state <NUM>, the policies are deployed on to the customer application server instance and a local repository of an infrastructure database, e.g., the LIH DB <NUM>, is created. The initialization state <NUM> represents the initialization or bootstrapping of various components of embodiments of the security platform, such as the application server instance (ASI), central policy manager (CPM), and RPE/CPE. Further details of the initialization state <NUM> are described hereinbelow in relation to <FIG>, <FIG>, and <FIG>. Once the policies are deployed, next, in the static execution state <NUM>, policies that are to be executed before entering the runtime state <NUM> are executed. In the run time state <NUM>, the security platform, according to an embodiment, is implemented for a user's application and events are matched against created policies and actions to be taken in response to events are determined and carried out. Further details regarding the runtime state <NUM> are described hereinbelow in relation to <FIG>.

<FIG> is a diagram of a state machine illustrating runtime functionality <NUM> of an embodiment. The state machine of <FIG> illustrates the states that are involved when an event is triggered during runtime <NUM>.

In <FIG>, the customer host <NUM> represents the platform which is responsible for the occurrence of the event. When an event is triggered, it reaches the idle state <NUM> (Start State) where the new event is directly forwarded to a policy lookup state <NUM>. At the policy lookup state <NUM>, the forwarded event is now looked up against the policy datastore (LIH) <NUM> for a match. If an entry is found, the event data is sent to a policy extraction state <NUM>. If no entry is found in the policy lookup sate <NUM>, then the event is not an interested event and the clean-up and log state <NUM> is entered whereby a log is sent to the central management server (CMS) which will terminate the thread. The policy extraction state <NUM> is responsible for extracting all associated policies and sending the extracted policies to the event evaluation state <NUM>. In embodiments, a single event may be involved with multiple policies and, thus, at the policy extraction state <NUM>, all of the associated policies are extracted.

At the event evaluation state <NUM>, a check is conducted to ensure all associated events with the policies have occurred or if there are any events that are yet to be triggered to execute the policy. If there are no such waiting events, the event operands along with policy operands are passed on to the policy execution state <NUM>. If there is an event that is yet to be triggered, the "waiting" event is sent to wait state <NUM> and an entry for the "waited for" event is created in a runtime event datastore <NUM>. The datastore <NUM> is cleared once all the events in the datastore <NUM> are triggered. Whenever a new event is triggered after passing the policy extraction state <NUM>, the event is matched with the events in the runtime event datastore <NUM>.

According to an embodiment, the runtime event datastore <NUM> can be considered as a cache memory for processing policies. When a current event is being processed to execute a policy and there are other events that are interdependent from the current event, an entry is created in the datastore <NUM> containing a policy ID with an associated bitmask to indicate all the dependent events. Whenever a new event is triggered and reaches the event evaluation state <NUM>, the new event is matched against the runtime event datastore <NUM>, if an entry is found for the current event and the associated bitmask is set. Once, all the bits in the bitmask are set, it indicates that all the events have occurred, and the policy can be executed.

During the wait state <NUM>, unless all the required events for the policy are triggered, the policy execution is halted in the wait state <NUM>. In a timely manner, the current execution thread is passed through a retirement state <NUM> and a timeout state <NUM>. In an embodiment, there is a timer associated with the retirement state <NUM> by which the RPE expects the events to arrive and this information is embedded into the policy design stage. Whenever a new event is triggered, it is matched against the runtime event datastore <NUM> and if all the events have occurred, the current execution thread reaches the policy execution state <NUM> from the wait state <NUM>.

In embodiments, there can be situations wherein the order of execution of events is to be maintained. The retirement state <NUM> is responsible for checking whether the events that have occurred, occurred in accordance with the specified order of execution. The process of determining whether events have occurred in a specified order takes place on a timer. Whenever events are triggered out of order, the events are sent to the clean-up and log state <NUM> where respective entries for the events are removed from the runtime event datastore <NUM>. No such action takes place when all the events have occurred in the correct order. The wait time involved with each event is verified in the timeout state <NUM>. When a predefined time comes to an end for an event, and all the required events have not occurred, then, the current thread is sent to the clean-up and log state <NUM>.

There is a possibility of the following outcomes when execution is in the retirement state <NUM> or timeout state <NUM>: (i) all events occurred in the order as specified in the design state within the timeout period and, then, the policy is executed in the policy execution state <NUM>, (ii) all events occurred out of the order as specified in the design state within the timeout period and, then, the series of events which occurred out of order are sent to the clean-up and log state <NUM>, (iii) only partial events occurred in the order as specified in the design state within the timeout period and, then, the execution is still in the wait state <NUM> waiting for all other events to occur, (iv) only partial events occurred out of order as specified in the design state within the timeout period and, then, the chain of serial events that occurred out of order are sent to the clean-up and log state <NUM>, or (v) any of the above cases occur after timeout and, then, the parallel/serial events are sent to the clean-up and log state <NUM>.

The policy execution state <NUM> is responsible for executing the protection actions associated with the rules. Protection actions executed in the policy execution state <NUM> act on policy operands and event operands. Below is an example STIG that may be employed in embodiments.

Sample STIG <NUM> (RunTime Policy Process Verification):.

This rule is on a process runtime event.

Rule: Any newly launched scripts should have the verification done in the system.

The clean-up and log state <NUM> is responsible for deallocating any memory that is allocated for findings, runtime event datastore, terminating the thread, and logging the current execution details to the central management server.

<FIG> is a block diagram of a set-up phase of a security platform <NUM> according to an embodiment. According to an embodiment, the setup phase includes setting the VIH (Virsec Infrastructure Hardening) database <NUM> and LIH (Local Infrastructure Hardening) database <NUM> at a user's location. In the set-up, XML structures of the standard policies <NUM> are generated from benchmarks like CIS or any provider recommended STIGs <NUM>.

According to an embodiment, copies, e.g., PDF copies, of the policies are inputted to the policy generation engine <NUM> using a policy creation user interface <NUM>. These policies are saved into a standard database <NUM> which holds the copies of the policies. Similarly, there is a user interface <NUM> to input any protection actions that can be handled from a data center and these protection actions can be stored in the database <NUM>. The protection files <NUM>, policy XML files <NUM>, and RPE configuration files <NUM> are generated from the policy generation engine <NUM> and these files are stored in the VIH <NUM>. When, there are new entries into the VIH <NUM>, the entries are pushed through the cloud <NUM> to the LIH <NUM> at the user's local data center.

Similarly, during the set-up phase of the security platform, a user, e.g., customer, may suggest custom STIGs which pertain to the customer application service instance <NUM> and the customer is not willing to share the STIGs with the provider of the platform <NUM>. Hence, a similar architecture is present on the customers' data center <NUM> which produces custom policy XMLs <NUM>. A representative from the user inputs all the custom policies <NUM> and protection actions into the policy generation engine <NUM> via the policy creation UI <NUM> and protection creation engine UI <NUM> which produces the protection action files <NUM>, custom policy XML files <NUM>, and RPE config files <NUM>. The files <NUM>, <NUM>, and <NUM> are stored in the LIH <NUM>. If the customer is willing to share the files with the provider of the platform <NUM>, the files are pushed through the cloud <NUM> into the VIH <NUM>. If the user does not want to share the files <NUM>, <NUM>, and <NUM>, only the LIH <NUM> holds both the standard and custom policies. According to an embodiment, these policies are encrypted before writing to the disks (<NUM> and <NUM>) to make sure the policies are protected from any internal/external attacks. Once the VIH <NUM> and LIH <NUM> are updated with required policies and protection actions, the system <NUM> is now ready to start provisioning.

<FIG> is a block diagram illustrating the set-up and policy provisioning stage of a platform <NUM> according to an embodiment. <FIG> shows the setup and provisioning of the platform <NUM> in a user's data center. The yellow flow shows the setup functionality, whereas the green flow shows the provisioning functionality.

By the time system reaches provisioning, it is assumed that the platform has completed the set-up phase, e.g., the phase discussed hereinabove in relation to <FIG>, and now, the VIH <NUM> and LIH <NUM> are set-up and up to date.

The first step in the provisioning phase is configuring of the LIH in the rule/callback processing engine <NUM>. The second step is configuring the macro protection agent (IDS, WAF) <NUM>. The third step is configuring the policy proxy on the application server instance <NUM>.

The policy XML <NUM>, RPE configs <NUM>, and protection action files <NUM> from LIH <NUM> are transmitted to the local LIH <NUM> of rule/callback processing engine <NUM> through RPE NC <NUM> and RPE WSC channel <NUM>. The protection actions <NUM> are transmitted to the protection action database in the macro protection agent <NUM>.

The provisioning also helps in setting up the ASI-LIH <NUM> and platform protection agent <NUM> micro protection agent database <NUM>. In an embodiment, setting up a proxy RPE and protection agent facilitates taking immediate action when a scenario requires a faster execution of the policy. Provisioning is complete once the ASI-LIH <NUM>, RPE LIH <NUM>, micro protection agent <NUM> and macro protection agent <NUM> are setup. In embodiments, depending on the number of application server instances present in the user location, multiple RPEs and macro protection agents are initialized to address scalability.

<FIG> is a simplified diagram illustrating pre-runtime execution <NUM> of a platform according to an embodiment. During the pre-runtime execution <NUM> (i.e., static execution) policies are executed before event detection takes place in an application server instance. Once the server comes up, the server will start executing the static policies to enforce the pre-runtime hardening. According to an embodiment, upon system start start-up <NUM>, after the application server instance (ASI) components are initialized, the security proxy <NUM> will be signaled (step <NUM>). Next, the security proxy <NUM> will signal (step <NUM>) the local RPE/CPE <NUM> running on the ASI. The RPE/CPE <NUM> will extract the applicable policies from the ASI LIH <NUM>, which will be executed thereafter. Policy execution will determine the course of action (CoA) and the RPE/CPE <NUM> will send (step <NUM>) the CoA to the platform protection agent <NUM>. In turn, the platform protection agent <NUM> will extract the associated protection action (step <NUM>) from the protection action database (in memory) <NUM> and, thereafter, the protection agent <NUM> will execute the protection action (step <NUM>). Logs are then generated and stored (step <NUM>) in the central log repository <NUM>.

<FIG> is a block diagram illustrating the run time stage of a platform <NUM> according to an embodiment. During runtime, events are continuously generated from the event generator <NUM> on the application server instance (ASI) <NUM>. The numbered flow shows the sequence of flow through the platform <NUM> components. In <FIG>, a "s" with a number indicates "slow" and a "f" with a number indicates "fast. " This indicates that in the platform <NUM>, there are two options, one being faster than the other. In an embodiment, whenever a faster policy execution is needed, the processing proceeds through the "f" labeled steps and when slower policy execution is sufficient, the processing proceeds through "s" labeled steps. According to an embodiment, security policy proxy <NUM> determines whether the event is to be processed in the fast path or slow path. In an embodiment, the speed determination is based on multiple factors, such as severity of event and class of event, amongst others. For example, in an embodiment, all memory-based events are processed in the fast path to mitigate and minimize the impact of an attack in microseconds.

To begin, in the platform <NUM>, an event is generated from the event generator <NUM> on the ASI <NUM> which is passed (step <NUM>) to the security policy proxy <NUM>.

For faster execution of the policy, the event is sent (step 2f) to the proxy RPE-CPE <NUM>, where the policy is applied and the finding, along with the policy information, is sent (step 3f) to the platform protection agent <NUM> which is responsible for applying the protection action which is obtained (step 4f) from the database <NUM>. In turn, the protection action (step 5f) is employed on the target.

For slower execution of the policy, the event is sent (step <NUM>) to rule/callback processing engine <NUM> where the policy rules are matched against the event (step <NUM>). In turn, the findings along with any event and policy operands are passed (step <NUM>) to the CPM engine <NUM> which determines whether the macro <NUM> or micro protection agent <NUM> employs the protection action. When the micro protection agent <NUM> is selected, the flow is through step <NUM> and when the macro protection agent <NUM> is selected the flow is through step <NUM>. To continue, the selected agent, either, micro protection agent <NUM> (steps <NUM>, <NUM>, <NUM>) or macro protection agent <NUM> (steps <NUM>, <NUM>, <NUM>), execute the protection action on the target. Micro protection agent <NUM> and macro protection agent <NUM> execution stages include receiving the protection message (step <NUM> (micro) / step <NUM> (macro)), extraction of the protection action by using the in-memory micro protection database <NUM> or macro protection database <NUM> (step <NUM> (micro) / step <NUM> (macro)), and executing the actions at either the micro level (step <NUM>) or macro level (step <NUM>).

<FIG> is a sequence diagram depicting an initialization phase <NUM> for an application server instance (ASI) (customer endpoint) <NUM> according to an embodiment. There are multiple components initialized during this phase <NUM>. According to an embodiment, the client daemon <NUM> is responsible for initializing all the components on the customer endpoints, e.g., ASIs. In the initialization phase <NUM>, once client daemon <NUM> is initialized and running, the client daemon <NUM> will bootstrap and initialize other components in sequence. Client daemon <NUM> will send signals to ASI logger <NUM>, ASI RPE/CPE <NUM>, and protection agent. In response to receiving a signal, ASI RPE/CPE <NUM> will build the ASI LIH in-memory database <NUM> if required. In response to receiving a signal, the protection agent <NUM> will build the micro protection action database <NUM> if required. Client daemon <NUM> will signal the security policy engine communication (SPE comm) <NUM> and RPE/CPE proxy <NUM>. Once the SPE comm <NUM> and RPE/CPE proxy <NUM> components acknowledge their state, then, client daemon <NUM> will start the detection agent <NUM>. During this initialization phase, logs are captured and written to in-memory local databases and synced up with a central log repository <NUM>.

<FIG> is sequence diagram showing the sequence <NUM> during an initialization phase of central policy manager (CPM) <NUM>. There are multiple components initialized during this phase <NUM>. In an embodiment, the client daemon <NUM> is responsible for initializing all the components on the CPM <NUM>. During the initialization, once client daemon <NUM> is initialized and running, the client daemon <NUM> will bootstrap and initialize other components in sequence. Client daemon <NUM> will send signals to a logger <NUM>, databases <NUM>, and web services <NUM>. On receiving the signal, a databases <NUM> thread will initialize various databases, e.g., the compliance database <NUM>, and a web services <NUM> thread will load the web services of CPM <NUM>. Client daemon <NUM> will signal policy generation UI <NUM> and macro protection agent (MPA) <NUM> and the client daemon <NUM> will signal the SPE comm <NUM>. Once all the components acknowledge their state, the initialization phase <NUM> will be complete. During the initialization phase <NUM>, logs are captured and written to in-memory local databases and synced up with a central log repository <NUM>.

<FIG> shows the sequence during the rule processing engine (RPE) <NUM> initialization phase <NUM> according to an embodiment. There are multiple components initialized during the phase <NUM>. According to an embodiment, the client daemon <NUM> is responsible for initializing all the components on the RPE <NUM>. Once client daemon <NUM> is initialized and running, the client daemon <NUM> bootstraps and initializes other components in sequence. Client daemon <NUM> sends signals to logger <NUM> and RPE/CPE <NUM>. On receiving the signal, RPE/CPE <NUM> builds central in-memory local infrastructure hardening database <NUM> using the policy XMLs <NUM> which have been deployed during the deployment phase. Client daemon <NUM> signals the SPE comm <NUM>. Once all the components acknowledge their state, the initialization phase <NUM> will complete. During this initialization phase <NUM>, logs are captured and written to in-memory local databases and synced up with a central log repository <NUM>.

<FIG> shows the policy set up phase <NUM> according to an embodiment. In this phase <NUM>, policies either by a provider of a security platform <NUM> or customer central policy manager <NUM> are built and set-up. The policies, once defined and built, are in the form of XMLs which are defined by the provider <NUM> and the policies are stored in a provider's hardened infrastructure database <NUM> and/or a user's infrastructure hardened database <NUM>. Policies are defined and built using CIS, customer, or security provider defined STIGS in the central policy manager <NUM> and customer central policy manager <NUM>. The central policy manager <NUM>, uses various components including the policy creation UI <NUM> and PA creation UI <NUM> to create policies in the form of XMLs. Similarly, the customer central policy manager <NUM>, may also use a policy creation UI <NUM> and PA creation UI <NUM> in the environment <NUM> to create customer defined policies. Once policies and protection actions are built, they are stored in the VIH <NUM> and LIH <NUM>, respectively. VIH <NUM> and LIH <NUM> are synced through cloud <NUM> to have golden copies of policies which can be deployed at customer ASIs. During the set-up phase <NUM>, logs are captured and written to in-memory local databases and sync'd up with a central log repository.

<FIG> is a sequence diagram of a policy provisioning phase <NUM> according to an embodiment. In this phase <NUM>, policies are provisioned by the CPM <NUM> into the ASI (customer endpoints) <NUM> and/or into a central RPE <NUM>. The policies are transported and stored in various databases in the ASI <NUM> or RPE <NUM> once provisioned based on the provisioning protocol as depicted in <FIG>. In the provisioning phase <NUM>, the CPM <NUM> once initialized, makes a policy provision decision <NUM>, which determines whether to provision the policy on the customer ASI <NUM> or central RPE/CPE <NUM>. Once decided, the CPM <NUM> downloads all the required files (policy XMLs, PA files, RPE config) through a handshake protocol via REST APIs and socket servers to ASI <NUM> or Central RPE/CPE <NUM>. ASI comm <NUM> of ASI <NUM> signals RPE/CPE proxy <NUM> and protection agent <NUM> to build the in-memory LIH database <NUM> and protection action database <NUM>. Central RPE/CPE <NUM> builds the central LIH <NUM> and bootstraps the RPE using the config file. CPM <NUM> also signals the macro protection agent <NUM> to build the in-memory protection action database <NUM>. During the provisioning phase <NUM>, logs are captured and written to in-memory local databases and synced up with a central log repository <NUM>.

<FIG> is a sequence diagram illustrating the policy updates or CRUD phase <NUM> according to an embodiment. In this phase <NUM>, policies are updated by a CPM <NUM> into a ASI <NUM> (customer endpoints) or into a central RPE <NUM>. The policies are transported and stored in various databases in the ASI <NUM> and/or RPE <NUM> once the policies are updated based on the policy update protocol depicted in <FIG>. In this phase <NUM>, CPM <NUM>, once initialized and provisioned, makes a policy provision decision <NUM> to update policies on the customer ASI <NUM> or central RPE/CPE <NUM>. Once decided, the CPM <NUM> downloads all the required files (policy XMLs, PA files, RPE config) through a handshake protocol via REST APIs and socket servers to ASI <NUM> or central RPE/CPE <NUM>. ASI comm <NUM> of ASI <NUM> signals RPE/CPE proxy <NUM> and protection agent <NUM> to update the in-memory LIH database <NUM> and protection action database <NUM>. These updates are done by ASI sync worker <NUM> which is signaled by RPE/CPE proxy <NUM>. During the update and resync downtime, the RPE proxy <NUM> keeps enqueuing the received events in the temporary event store <NUM>. Once the updates are done, then ASI sync worker <NUM> signals the RPE/CPE proxy <NUM> to process the events from the temporary store <NUM>. Central RPE/CPE <NUM> updates the central LIH <NUM> using a RPE sync worker <NUM> thread and macro protection database <NUM> is updated by macro protection agent <NUM>. Macro protection agent <NUM> enqueues the event in the temporary event store <NUM> during the policy sync and update downtime and once the sync is complete then, macro protection agent <NUM> starts processing the events from the temporary event store <NUM>. During this update phase <NUM>, logs are captured and written to in-memory local databases and synced up with a central log repository <NUM>.

<FIG> is a sequence diagram depicting event processing at a pre-runtime or runtime phase <NUM>. In this phase <NUM>, events generated from ASI <NUM> are processed either locally by ASI RPE <NUM> or by central RPE <NUM>. During the events processing phase <NUM>, the associated polices are determined and executed by the ASI RPE <NUM> or central RPE <NUM> based on the event processing pipeline protocol as depicted in <FIG>. Further, protection actions (micro <NUM> or macro <NUM>) are executed during the policy execution phase <NUM> to enforce the final set of actions by policies on the ASI <NUM>. Once ASI <NUM> is initialized, setup and provisioned, it will enter into the pre-runtime and/or runtime stage. In the event processing stage <NUM>, an event generator agent <NUM> detects various events (file events, process events, registry events, memory events, etc.) of ASI <NUM> and the CPM <NUM> publishes these detected events to SPE proxy <NUM>. SPE proxy <NUM> determines <NUM> whether to process the detected events via the fast or slow path based on the policy and sends the events to ASI RPE/CPE <NUM> if the fast path is selected or the ASI comm <NUM> if the slow path is selected. For the fast path, the ASI RPE/CPE <NUM> executes the extracted policies from the in-memory LIH and determines the course of action (CoA) events. The determined CoA events are sent to protection agent <NUM> for executing the protection actions. The protection agent <NUM> extracts and executes the protection actions from the in-memory micro protection database <NUM>. For the slow path, the ASI comm <NUM> dispatches the events to the central RPE/CPE system <NUM>. The central RPE/CPE <NUM> extracts policies from the in-memory event temp store <NUM> and LIH <NUM> and the central RPE/CPE <NUM> determines the CoA events. The CoA events determined by the central RPE/CPE <NUM> can be micro or macro actions. Thus, based on an action's class, a CoA is sent to either ASI <NUM> through the CPM <NUM> interface if the CoA is at the micro level and the CoA is sent to the macro protection agent <NUM> if the CoA is at the macro level. Macro protection agent <NUM> extracts and executes the protection actions from the in-memory macro protection database <NUM>. During this event processing phase <NUM>, logs are captured and written to in-memory local databases and synced up with a central log repository <NUM>.

<FIG> illustrates a computer network or similar digital processing environment in which embodiments of the present disclosure may be implemented.

Client computer(s)/devices <NUM> and server computer(s) <NUM> provide processing, storage, and input/output devices executing application programs and the like. The client computer(s)/devices <NUM> can also be linked through communications network <NUM> to other computing devices, including other client devices/processes <NUM> and server computer(s) <NUM>. The communications network <NUM> can be part of a remote access network, a global network (e.g., the Internet), a worldwide collection of computers, local area or wide area networks, and gateways that currently use respective protocols (TCP/IP, Bluetooth®, etc.) to communicate with one another. Other electronic device/computer network architectures are suitable.

Client computers/devices <NUM> may be configured as detection engine <NUM>. Client computers/devices <NUM> may detect CRUD operations on the file system, registry, application processes and threads, and OS kernel of a customer endpoint that may be indicative of a security attack, such as a memory corruption attack. In some embodiments, the client <NUM> may include client applications, components, or probes executing on the client (i.e., detection engine <NUM>) <NUM> for capturing and detecting the CRUD operations, and the client <NUM> may communicate this information to the server <NUM>. Server computers <NUM> may be configured as an analysis engine, rule processing engine, and callback processing engine, or instrumentation engine <NUM> which communicates with client devices (i.e., detection engine <NUM>) <NUM> for receiving the detected CRUD operations as events. The server computers <NUM> may not be separate server computers but part of cloud network <NUM>. In some embodiments, the server computer (e.g., rule processing engine or callback processing engine) may analyze the events to select rule-based policies, which are applied to take action on the events.

<FIG> is a diagram of an example internal structure of a computer (e.g., client processor/device <NUM> or server computers <NUM>) in the computer system of <FIG>. Each computer <NUM>, <NUM> contains a system bus <NUM>, where a bus is a set of hardware lines used for data transfer among the components of a computer or processing system. The system bus <NUM> is essentially a shared conduit that connects different elements of a computer system (e.g., processor, disk storage, memory, input/output ports, network ports, etc.) that enables the transfer of information between the elements. Attached to the system bus <NUM> is an input/output (I/O) device interface <NUM> for connecting various input and output devices (e.g., keyboard, mouse, displays, printers, speakers, etc.) to the computer <NUM>, <NUM>. A network interface <NUM> allows the computer to connect to various other devices attached to a network (e.g., network <NUM> of <FIG>). Memory <NUM> provides volatile storage for computer software instructions <NUM> and data <NUM> used to implement an embodiment of the present disclosure (e.g., detection engine <NUM>, instrumentation engine <NUM>, rule processing engine, and callback processing engine elements described herein). Disk storage <NUM> provides non-volatile storage for computer software instructions <NUM> and data <NUM> used to implement an embodiment of the present disclosure. A central processor unit <NUM> is also attached to the system bus <NUM> and provides for the execution of computer instructions.

Embodiments or aspects thereof may be implemented in the form of hardware including but not limited to hardware circuitry, firmware, or software. If implemented in software, the software may be stored on any non-transient computer readable medium that is configured to enable a processor to load the software or subsets of instructions thereof. The processor then executes the instructions and is configured to operate or cause an apparatus to operate in a manner as described herein.

Further, hardware, firmware, software, routines, or instructions may be described herein as performing certain actions and/or functions of the data processors. However, it should be appreciated that such descriptions contained herein are merely for convenience and that such actions in fact result from computing devices, processors, controllers, or other devices executing the firmware, software, routines, instructions, etc..

It should be understood that the flow diagrams, block diagrams, and network diagrams may include more or fewer elements, be arranged differently, or be represented differently. But it further should be understood that certain implementations may dictate the block and network diagrams and the number of block and network diagrams illustrating the execution of the embodiments be implemented in a particular way.

Accordingly, further embodiments may also be implemented in a variety of computer architectures, physical, virtual, cloud computers, and/or some combination thereof, and, thus, the data processors described herein are intended for purposes of illustration only and not as a limitation of the embodiments.

Claim 1:
A computer-implemented method comprising:
using one or more instrumented probes, monitoring a compute endpoint at runtime for create, read, write, update, and delete, CRUD, operations being performed on the compute endpoint;
based on content of the CRUD operations, generating an event to analyze a given CRUD operation;
responsive to the generated event, maintaining one or more compute components affected by the given CRUD operation in a quarantine state;
attempting to establish trust of the one or more affected compute components; and
removing the one or more affected compute components from the quarantine state, if trust of the one or more affected compute components is established by the attempting, or
executing at least one callback routine to mitigate results of the given CRUD operation, if trust of the one or more affected compute components is not established by the attempting.