Invention for Systems and Methods for Multi-Event Correlation

Invented by John H. Lehmann, Digital Guardian LLC

The Digital Guardian LLC invention works as follows

Systems and methods are described herein for multi-event correlative. Each leaf rule engine can detect, when receiving a stream event, a number of events that match a characteristic of the leaf rule engines. From the stream of events, each leaf rule engine can identify a group that meets a condition of the leaf rule engine. The root conditions engine can receive a stream corresponding to each group of events that is identified by the leaf rule engines. The root condition engine can identify, from a stream of leaf events received and within a time window of the root, a group of events that satisfy a condition of the root conditions engines. “A trigger can execute an action based on the collection of events that are identified within the root window.

Background for Systems and Methods for Multi-Event Correlation

A computing device can execute a procedure.” While the process runs on the computing device one or more events can be invoked either synchronously, or asynchronously. One or more events can be triggered by a person or user. In a networked setting, different events can happen at different times. “Some of these events might be related.

The present invention describes systems and methods of multi-event correlative. A computing device can execute a process such as an application or routine, daemons, tasks, tasks, or any other executable module. While the process runs on the computing device one or more events can be invoked, and then handled according to the instructions of the process. Invocation of an event can be synchronous to the control flow of a process and occur in response to a request from another function. Invocation of an event can also be asynchronous. It may occur as a result from another action taken by another process on the computing system or user interaction with a device input/output. The field value of each event (also referred to as metadata) may include, for example, the event type, timestamp and/or identifiers of users of the computing device. The field values and events (e.g. by device(s), process(es), and/or users)) may be stored in memory (e.g. a log file).

A sequence of events (e.g. on a computer device) could be indicative of an incorrect performance, malicious behaviour, or other undesirable activities on a network or computing device in relation to the running of a particular process. A system administrator can manually review the log files and field values to identify the root cause. The problem with this approach is that it can take a lot of time to sift through all the log files and there may be human errors, which could lead to false positives or overlooking real negatives. In network environments that have a large number of users, computing devices and processes, it may be impossible to manually examine the events in the log files. In such environments, a set predicate logic rule may be used to process the log files. These rules could include a list of events or field values that indicate undesirable behavior. This approach, without any further specificity, may also be prone to false positives, and miss true negatives.

To address the technical challenges of correlating multiple event, an event correlater running on a computer or network environment that is communicatively linked to a server may tie together several events. The event correlator can have a number of rules to link multiple events together. The event correlator may receive a stream of events coming from computing devices. The set of rules components in the correlator can be hierarchical, layered and the stream of events may be processed sequentially through each rule component. Leaf rule components may refer to the rule components of an initial layer. One or more of the rule components that are part of a terminal layer, (or parent layer), may be called a root component. The leaf rule components can each receive the stream of events coming from the computing device and process them. They may then feed the processing results to the root rule component. The root rule component can receive the results of the leaf rule components and perform additional processing on the results in order to determine the occurrences of undesirable activities in the sequence of events of the process.

Each component of a leaf rule may include a time window and condition, as well as a filter. Each leaf rule component can specify a filter that will filter events based on one or more characteristics. Filter characteristics may include, for example, a specific user, an event’s type and the field values. The filter can pass events that match the specified characteristic, while filtering out any event that does not meet the specified characteristics. The time window for each leaf rule component can specify the duration in which events are selected by the filter. The condition of each rule leaf component can specify a collection or group of events that pass through the filter in the specified time window. These events may be related temporally, but not necessarily in a particular order or sequence. As an example, the condition for each leaf rule component could specify a series of events that pass through the filter within the time window. The leaf rule component can send a firing to indicate that the sequence of passed-through events meets the specification if the conditions are met. If the sequence of passed-through events does not meet the condition, then the leaf rule component will not send the firing, and continue processing the stream of events. The results of processing the stream of events can be fed into the root rule component by each leaf rule component independently.

The root rule component can receive the firings of one or more leaf rule components. The root rule component can include a time window and condition. The root rule component’s time window may specify the duration during which the firings of the leaf rule components will occur. The root rule component’s time window can differ from the time windows for one or more leaf rule components. The root rule component’s time window may, for example, be larger than any leaf rule component, and can span across all of its time windows. The root rule component’s condition may specify a collection or sequence of firings that must be received by the leaf rule component within the specified window. If the firing sequence or collection meets the condition in the time period specified, the root rule can generate a firing that indicates an error, anomaly or other undesirable activity on the computer device. The root rule component can also trigger an action on the basis of the firing in order to indicate undesirable activity on a computing device. If the sequence of fires does not meet the condition, then the root rule component will not send the firing and continue to monitor the leaf rule component or wait for the fires.

By processing the stream of event through separate rule components, in a bifurcated way, the Event Correlator can reduce the instances of false positives or overlooking true negativities. The event correlator can also be used to assess a large number events that occur across a network of computers. The processing of events can be improved to identify the source of erroneous behavior or unwanted activity in a network or computing environment. The undesirable activity can be reduced, if it is not eliminated from the computing environment or network.

At the very least, one aspect of this disclosure is directed at a system that allows for multiple event correlation. The system may include a plurality leaf rule engines that are executable on one server or more. The leaf rule engines can receive a stream containing events corresponding to the activities of at least one user, device or application. From the stream of events, each leaf rule engines can detect a number of events that match a characteristic defined for its respective leaf rule engine. From the plurality events, each leaf rule engine can identify a grouping of events within a time window that satisfy at least one condition of the leaf rule engine. The system can include a root condition engine that is executable on one or more servers. The root conditions engines may receive from the leaf rule engines a stream corresponding to a group of identified events. The root conditions engines may identify from the stream of leaf events received and within the root time window a group of events that satisfy at least one predefined condition for the root conditions engine. The system can include a trigger that is executable on one or more servers. The trigger can execute an action based on the events that are identified in the root time window.

In some embodiments, the events of a stream may be described with a timestamp as well as at least one field. In certain embodiments, the leaf rule engines may store the detected multiple events in the time window. In some embodiments the time window for each leaf engine can be different than the parent window. In some embodiments a predefined characteristic for a leaf rule engine may include an event identified as a potential anomaly or risk.

In some embodiments, the condition of a leaf rule engine may be related to: at least one of the following: a total of events, files, or bytes that have been accumulated in a particular time window. In some embodiments the total number may be the number of distinct devices, events, files, or bytes that have been accumulated in the time window. In some embodiments the time window can be adjusted forward or backwards in time. In some embodiments, the first of the leaf rule engines of the plurality is configured to update the condition of the first rule engine. In some embodiments the trigger is configured for an alarm to be triggered if a potential anomaly or risk has been identified in the parent time frame.

At the very least, one aspect of this disclosure is a method to correlate multiple events. A plurality leaf rule engines may receive a stream event and each leaf rule engine can detect from that stream a number of events which match a characteristic defined for its leaf rule engine. A group of events within a time window can be identified by each leaf rule engine from a plurality. The root conditions engine can receive a stream corresponding to each group of events that was identified by the leaf rule engines of the plurality. The root conditions engines can identify from the stream of leaf events received and within the root time window a group of events that satisfy at least one predefined condition for the root conditions engines. “A trigger can execute an action based on the collection of events that are identified within the root window.

In some embodiments, the events of a stream may be described with a timestamp as well as at least one field. In certain embodiments, the leaf rule engines may store the detected multiple events in the time window. In some embodiments the time window for each leaf engine can be different than the parent window. In some embodiments a predefined characteristic for a leaf rule engine may include an event identified as a potential anomaly or risk.

In some embodiments, the condition of a leaf rule engine may be related to: at least one of the following: a total of events, files, or bytes that have been accumulated in a particular time window. In some embodiments the total number may be the number of distinct devices, events, files, or bytes that have been accumulated in the time window. In some embodiments the time window can be adjusted forward or backwards in time. In some embodiments, the first of the leaf rule engines of the plurality is configured to update the condition of the first rule engine. In some embodiments the trigger is configured for an alarm to be triggered if a potential anomaly or risk has been identified in the parent time frame.

It should be understood that any combination of the above concepts and the additional concepts discussed below in greater detail (provided they are not mutually contradictory) is contemplated to be part of the inventive matter disclosed herein. All combinations of claimed matter appearing at this disclosure’s end are considered to be part of the inventive matter disclosed herein.

Below are detailed descriptions and examples of inventive systems and techniques for classifying data to prevent exfiltration or breach of information. As the concepts disclosed are not restricted to a particular implementation, it is important to note that all of the concepts discussed above and in more detail below can be implemented in a variety of ways. “Examples of specific applications and implementations are provided for illustration purposes only.

Section A explains a computing and network environment that may be helpful for implementing the various embodiments of computing described in this document.

Section B describes methods and systems for multi-event correlative analysis.

It should be understood that the concepts disclosed above, and in more detail discussed below, can be implemented in a variety of ways. The concepts are not restricted to a particular implementation. “Examples of specific applications and implementations are presented primarily as illustrations.

A. Computing and Network Environment.

It may be useful to describe the operating environment and associated system components (e.g. hardware elements) with respect to the methods described herein.

Referring to FIG. In Figure 1A, a particular embodiment of a networking environment is shown. The illustrated exploring network environment comprises one or multiple clients 102 (also referred as local machine(s), client(s), client node (s), client computer(s), client device(s), or endpoint (s) node (s), 102) that are in communication with one of more servers 106 (also referred as server(s), node (s), or remote machine (s) 106) through one or several networks 104. “In some embodiments, the client 102 can function both as a client seeking to access resources hosted by a remote server and as a host providing access to those resources for other clients.

Click here to view the patent on Google Patents.