Real-time detection of network threats using a graph-based model

Abstract

The present disclosure gives methods and systems to perform intrusion detection on a computing system using streaming embedding and detection alongside other improvements. Intrusion detection may be implemented by recording events occurring within a computing system in an audit log. From this audit log, a provenance graph representing the events and causal relationships of the events occurring within the computing system may be generated. The provenance graph may be supplemented, by a pseudo-graph that connects each event occurring in the computing system to one or more root causes. Then, a neural network may be trained to represent behavior of the computing system based on this pseudo-graph. The present disclosure also gives other systems and methods of intrusion detection and modeling computing system behavior.

Description

MBHB Docket No.24-0156-WO Real-Time Detection of Network Threats Using a Graph-Based Model GOVERNMENT LICENSE RIGHTS

[0001] This invention was made with government support under contract no. 2055127 awarded by the National Science Foundation. The government has certain rights in the invention. BACKGROUND

[0002] While endpoint detection and response (EDR) systems are able to efficiently monitor security threats by comparing static rules to an event stream, their inability to incorporate past system context leads to high rates of false alarms. Recent work has demonstrated provenance-based intrusion detection systems (Prov-IDSs) that can examine the causal relationships between abnormal behaviors to improve threat classification. However, employing these Prov-IDSs in practical settings remains difficult – state-of-the-art neural network based systems are only fast in a fully offline deployment model that increases attacker dwell time, while simultaneously using simplified and less accurate provenance graphs to reduce memory consumption. Thus, today’s Prov-IDSs cannot operate effectively in the real- time streaming setting required for practical EDR viability. SUMMARY

[0003] Various implementations disclosed herein include ORCHIDS, a Prov- IDS that performs anomaly detection over a real time event stream. ORCHIDS takes advantage of the unique properties of provenance graphs to model the entire graph using an autoregressive neural network – consuming little computational and memory resources. Thus, ORCHIDS can classify attack behavior while eliminating detection lag and reducing memory consumption.

[0004] A system of one or more computers can be configured to perform particular operations or actions by virtue of having software, firmware, hardware, or a combination of them installed on the system that in operation causes or cause the system to perform the actions. One or more computer programs can be configured to perform particular operations or actions by virtue of including instructions that, when executed by data processing apparatus, cause the apparatus to perform the actions.

[0005] One general aspect involves a computer-implemented method that includes receiving, by way of a logging system, a system call event representing a flow of data from a first system entity to a second system entity. The method also includes generating a vector embedding for the second system entity based on the system call event and previousMBHB Docket No.24-0156-WO vector embeddings for the first system entity or the second system entity, where the vector embedding is generated using an autoregressive neural network, and where the autoregressive neural network was trained on previous log files representing system call events of system entities. The method also includes comparing the vector embedding to a precomputed set of vector embeddings representing normal behavior of the system entities. The method also includes based on a distance between the vector embedding and the precomputed set of vector embeddings being greater than a threshold value, determining that the system call event includes anomalous behavior. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.

[0006] One general aspect involves a computer-implemented method that includes recording, by a logging system, system call events representing a flow of data from a first system entity to a second system entity. The method also includes generating, based on the system call events, a provenance graph, where a plurality of nodes of the provenance graph respectively correspond to the system call events and a plurality of edges are vector representations of causal relationships between the system call events. The method also includes generating, based on the provenance graph, a pseudo-graph, where the pseudo-graph connects a subset of nodes of the provenance graph to at least one node in the pseudo-graph representing a root cause of the events corresponding to the subset of nodes. The method also includes training a machine learning model to represent behavior of a computing system based on the pseudo-graph. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.

[0007] One general aspect involves a computer-implemented method that includes obtaining events involving a computing system; applying a machine learning model to the events, where the machine learning model was trained to represent behavior of the computing system based on a pseudo-graph of nodes, where the pseudo-graph connects a subset of nodes of a provenance graph to at least one node in the pseudo-graph representing a root cause of previous events corresponding to the subset of nodes, where a plurality of nodes of the provenance graph correspond to the previous events within the computing system and a plurality of edges are vector representations of causal relationships between the previous events. The method also includes detecting, by the machine learning model, a behavioral anomaly related to the computing system based on a comparison of the events involving the computing system to the behavior. Other embodiments of this aspect include corresponding computerMBHB Docket No.24-0156-WO systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods

[0008] These, as well as other embodiments, aspects, advantages, and alternatives, will become apparent to those of ordinary skill in the art by reading the following detailed description, with reference where appropriate to the accompanying drawings. Further, this summary and other descriptions and figures provided herein are intended to illustrate embodiments by way of example only and, as such, that numerous variations are possible. For instance, structural elements and process steps can be rearranged, combined, distributed, eliminated, or otherwise changed, while remaining within the scope of the embodiments as claimed. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 depicts an overview of an IDS system architecture as demonstrated on a provenance graph, in accordance with example embodiments.

[0010] Figure 2 depicts an overview of a node embedding procedure in an IDS system, in accordance with example embodiments.

[0011] Figure 3 depicts an overview of a pseudo root node hyperplane in an IDS system graph, in accordance with example embodiments.

[0012] Figure 4 depicts a table visualizing graphical representations for various intrusion events, in accordance with example embodiments.

[0013] Figures 5A, 5B, 5C, 5D, 5E, and 5F depict graphs illustrating hyperparameter tuning of an IDS system, in accordance with example embodiments.

[0014] Figures 6A, 6B, 6C, and 6D depict graphs illustrating the performance of an IDS system in comparison to graph neural network (GNN) systems, in accordance with example embodiments.

[0015] Figure 7 depicts the memory consumption of an IDS system architecture in comparison with GNN systems, in accordance with example embodiments.

[0016] Figure 8 is a table illustrating the runtime of an IDS system in comparison with a GNN system, in accordance with example embodiments.

[0017] Figure 9 depicts the detection lag of an IDS system in comparison to a GNN system, in accordance with example embodiments.

[0018] Figure 10 illustrates an example of an IDS system utilizing back tracing and forward tracing, in accordance with example embodiments.

[0019] Figure 11 depicts an overview of a hybrid IDS architecture, in accordance with example embodiments.MBHB Docket No.24-0156-WO

[0020] Figure 12 illustrates a schematic drawing of a computing device, in accordance with example embodiments.

[0021] Figure 13 illustrates a schematic drawing of a server device cluster, in accordance with example embodiments.

[0022] Figures 14, 15, and 16 are flow charts, in accordance with example embodiments.MBHB Docket No.24-0156-WO DETAILED DESCRIPTION

[0023] Example methods, devices, and systems are described herein. It should be understood that the words “example” and “exemplary” are used herein to mean “serving as an example, instance, or illustration.” Any embodiment or feature described herein as being an “example” or “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments or features unless stated as such. Thus, other embodiments can be utilized and other changes can be made without departing from the scope of the subject matter presented herein.

[0024] Accordingly, the example embodiments described herein are not meant to be limiting. It will be readily understood that the aspects of the present disclosure, as generally described herein, and illustrated in the figures, can be arranged, substituted, combined, separated, and designed in a wide variety of different configurations. For example, the separation of features into “client” and “server” components may occur in a number of ways.

[0025] Further, unless context suggests otherwise, the features illustrated in each of the figures may be used in combination with one another. Thus, the figures should be generally viewed as component aspects of one or more overall embodiments, with the understanding that not all illustrated features are necessary for each embodiment.

[0026] Additionally, any enumeration of elements, blocks, or steps in this specification or the claims is for purposes of clarity. Thus, such enumeration should not be interpreted to require or imply that these elements, blocks, or steps adhere to a particular arrangement or are carried out in a particular order.

[0027] Unless clearly indicated otherwise herein, the term “or” is to be interpreted as the inclusive disjunction. For example, the phrase “A, B, or C” is true if any one or more of the arguments A, B, C are true, and is only false if all of A, B, and C are false. I. Introduction

[0028] Effective logging plays a significant role in defending against malicious behavior. Most of today’s cyber-attacks can be forensically captured through a combination of one or more log streams. However, the sheer volume of logs generated poses a significant challenge, demanding substantial computational and memory resources for proper analysis and storage. For instance, even in a small data center, daily logs can quickly accumulate hundreds of gigabytes of data. Moreover, defense against modern cyber-attacks necessitates security tools to offer real-time detection capabilities without excessively burdening the underlying system’s computing resources (e.g., processor, memory, network, and / or power capacity).MBHB Docket No.24-0156-WO

[0029] Consequently, current security solutions meet these demands by adopting a strategy of lightweight analysis, using pattern matching based on pre-defined rules to analyze each system event in isolation. While this approach balances performance and system scrutiny, it exposes computing devices and networks to attack events for several reasons. Current systems use static rules that pattern-match on single events ignoring the important surrounding context during classification. Moreover, static rules fall potentially victim to the dynamic behavior of attackers whose activity may not match the exact pattern defined within the rule. Finding a reasonable compromise between tool efficiency while maintaining a thorough analysis of log data remains a challenge in cyber defense.

[0030] Data provenance has emerged as a potential contender to address some of these challenges, where the atomic events within a log are represented in a graphical format preserving their causal relations. Moreover, the graphical structure relates events regardless of their distance in the log. Much of the current Prov-IDS research has primarily focused on analyzing these graphical structures (with respect to host log data) to accurately identify the occurrence of anomalous substructures. Initial research focused on building lightweight systems that provided global classification over the entire graph. However, it has been shown that the loss of information when summarizing complex structures to make a global classification made these systems vulnerable to mimicry attacks allowing the attacker to evade detection. Some solutions have adapted to the mimicry problem by focusing on more sophisticated models that provide finer-grained classification (e.g., node-level, edge-level). Nonetheless, these solutions have occurred at the expense of creating memory and computationally intensive systems. For example, analyzing a typical versioned provenance graph capturing host behavior can require 143.7 GB of memory. Further, current Prov-IDSs assume static audit logs resulting in deployment at specific “checkpoints” to transform the input logs into an in-memory graphical format, which the Prov-IDSs then use to train, embed, and detect for abnormal activity.

[0031] The embodiments herein introduce ORCHIDS (Online Root Cause Intrusion Detection System), a stream-based, node-classifying Prov-IDS with a low memory footprint and accurate identification of attacker behavior. The foundation for ORCHIDS resides in using an autoregressive neural network (ANN) to model audit logs while maintaining causal relationships between log events. ORCHIDS does not store the provenance graph in memory, instead relying on the recursive nature of ANN to capture historical behavior. This significantly reduces memory usage while still providing more information than predecessor systems. ORCHIDS additionally considers the root causes (RCA) when modeling each event, allowingMBHB Docket No.24-0156-WO for more detailed representations.

[0032] In evaluating ORCHIDS, host logs are compared against graph neural network (GNN)-based architectures used in state-of-the-art Prov-IDS. A streaming-based GNN is also used to provide a fair comparison. Results show that ORCHIDS is nearly as effective at threat classification as a GNN in an offline static setting, but significantly more effective in an online streaming setting (e.g., 0.91 vs. 0.73 AUC on the DARPA TC3 trace). Further, ORCHIDS has a dramatically lower memory footprint than GNNs (2.7 GB vs. 143.7 GB on the DARPA TC3 trace) and can classify new events in nearly real time (0.002 seconds per event), while offline deployment of GNN models experience a detection lag of 18 to 42 hours.

[0033] Regardless of how anomalies are detected, an IDS detecting such behavior can trigger a range of responses that fall into two broad categories: automatic mitigations and human-aided mitigations. For automatic responses, predefined rules and policies can initiate immediate actions without human intervention; these actions might include dynamically updating firewall rules to block suspicious IP addresses, isolating the affected node by segmenting it from the network, or initiating an automatic shutdown of compromised services to prevent lateral movement by attackers. Conversely, human-aided mitigations involve alerting security analysts or an incident response team who then perform a deeper investigation into the anomalous behavior. This process typically includes analyzing logs and network traffic, conducting forensic analysis to trace the origin and scope of the attack, and determining whether the anomaly is part of a larger, coordinated attack. Experts can also decide on tailored responses, such as patching vulnerabilities, applying targeted security updates, or engaging in threat hunting across the network. Both automatic and human-aided approaches can be combined into a layered security strategy, so that immediate threats are swiftly contained while a comprehensive investigation determines the underlying cause and long-term remedial measures. II. Example Scenario

[0034] To illustrate the challenges faced by Prov-IDS, a realistic example of an advanced persistent threat (APT) attack is used. The dataset features host logs containing system calls that occurred on an actual victim’s system. The attacks starts off by the attacker strategically placing a malicious ad server on a trusted website and waiting for a potential victim with a vulnerable web browser to visit.

[0035] Upon connection, the attacker installs a Drakon malware implant (e.g., a unit of executable program code containing an exploit) in the memory of the victim’s browser process. This results in the exploited browser establishing a connection back to the attacker’sMBHB Docket No.24-0156-WO server, which is ready to receive commands. With control of the process, the attacker escalates their privileges on the system by capitalizing on a previously installed driver named “BinFmt Elevate.” This driver allows the attacker to execute an Elevate process with elevated root access to the victim system. The attacker uses the higher privilege process to access sensitive data stored in the / etc / shadow directory and subsequently exfiltrate this data back to their server. During the attack, the victim performs benign activities, including updating the browser. A causal graph of the attack is depicted in Figure 1, with nodes 102a, 102b, 102c, 102d, 102e, 102f, and 102g indicating malicious behavior and the remaining nodes representing legitimate activity.

[0036] The World-Wide Web Consortium (W3C) definition of a provenance graph states a causal graph must be directed and acyclic. Graph versioning achieves this – one such method to version can be the creation of a new node for a system entity when it receives a new information flow locking the “old” node. This example uses a timestamp associated with each system call to define an order of events. New edges are appended only to unlocked nodes making locked portions of the graph immutable.

[0037] Effective Prov-IDS design requires operating on lossless provenance graphs while maintaining the memory and computational efficiency necessary for real-time analysis of the event stream. This involves rethinking the underlying architecture for Prov-IDS. ORCHIDS uses the immutable nature of versioned provenance graphs to its advantage. ORCHIDS uses an autoregressive neural network to model the provenance graph (Time 1 in Figure 1). ORCHIDS can process an event stream as new events occur, efficiently providing classification that considers the entire contextual history of the event. Therefore ORCHIDS reduces complexity compared to GNN architectures by maintaining state for only certain entities.

[0038] To better understand ORCHIDS, Figure 1 constructs a simple example where ORCHIDS embeds the history of each node using a sequence-to-sequence based model on host level logs. Consider, at Time 6, the introduction of the malicious Elevate 2 process(or 14) whose representation is defined as 14 = 14 + 13 , where 14 is an Elevate 2feature vector and 13 is a recursive embedding of event history including the vulnerableFirefox 4 process getting exploited by the attacker. So at Time 7, when Elevate 2 reads from / etc / shadow, the inherent abnormality of information flow between a highly sensitive datasource and a node whose history includes an outside IP address ( 6, 8) is represented in thesummation of 15 and 14 . As a result, the L-dimensional embedding 14 should appear asMBHB Docket No.24-0156-WO an outlier when compared against a model capturing normal behavior. This recurrent structureemployed by ORCHIDS allows for simple computation to create 14 which then fullycaptures Elevate 2’s history without requiring previous versions ( 14 , 14).

[0039] Embedding the history of each node may be implemented using various techniques. In an example embodiment, R-CAID, the Root-Cause Analysis Intrusion Detection system, is presented. The foundation of R-CAID is a traditional GNN that performs process- level classification. R-CAID then introduces a method to incorporate RCA. Rather than attempting to associate every node with its entire provenance history, which would be both ineffective and prohibitively costly, R-CAID precomputes every node’s root causes during graph construction and then directly connects each node to its root causes during embedding. This procedure may be optimized by skipping over highly connected root causes (e.g., the GNU C Library) that increase storage and analysis costs without adding any discriminative power.

[0040] The present disclosure will provide an example embodiment of R-CAID. First, it describes the foundation of R-CAID applying GNNs to provenance graphs. Next, the GNNs are extended to incorporate RCA capabilities through a “root node embedding” technique. Then, to adapt GNNs to anomaly detection, they are trained and tested. R-CAID may be optimized in a manner that exposes a performance / security trade-off continuum for root node embedding.

[0041] Let provenance graph be a set of vertices =and edges= Each vertex in maps to a system entity, such as a file, process, or networksocket, and each edge = ( , , ) connects two vertices by the system call eventsuch that for any two given edges. There exists a pathbetween any two nodes ( , ) if there occurs a set of edges such that ( ) ,· · ·, ( ) where each edge ( ) can be found within . A node ’s -hopneighborhood is the set of ancestors reachable from within hops; in other words. The goal for any GNN is to create a -dimensional vector thataccurately describes each node in in terms of and its -hop neighborhood . One possible way GNNs achieve this is by using a technique called message passing, where information flows according to the direction of the edge.

[0042] To start, let { } = { ,· · · ,be a set of feature vectorscorresponding to each node in where is the number of features. A GNN takes in as input ,{ } where initializes each node feature vector for the first layer of the GNN. ForMBHB Docket No.24-0156-WO each subsequent layer , a node ’s new representation is an update between its intermediate representation and an aggregation of all the intermediate representations ofnodes in such that =During model training, aggregation andupdate functions are optimized to represent the node accurately. An example of message passing on a provenance graph is visualized in Figure 2. Here, at block 200, the GNN updates process P2’s embedding to by first aggregating P2’s parent’s intermediate representationsfrom the previous layer ( , ) and then concatenating that with P2’s intermediaterepresentation of the prior layer ( ).

[0043] A GNN can be comprised of layers where each layer in the network aggregates features from nodes hops away. The final layer of the GNN outputs an embeddingmatrix representing every node in such that =where is the size of anindividual embedding. can be used in downstream tasks like node classification or outlier detection.

[0044] To solve the “curse of locality,” the present disclosure details methods to directly link each node to its root causes, regardless of the root cause’s distance from the node in the provenance graph. The “curse of locality” in graphs refers to the phenomenon where methods or algorithms that focus primarily on local, neighborhood-based information can miss – or even misrepresent – the broader, global structure of the graph.

[0045] Classically, a node is a root node if there exists no forwhich ( , )--that is, there are no inbound edges associated with. As such, a GNN shouldnever update a root node’s embedding under message passing, as no information flows into the node. In a true provenance graph, which is acyclic, it is straightforward to maintain this definition of root nodes. However, when applying provenance to operating systems in practice, cyclic behaviors between entities (e.g., socket I / O) are allowed, creating the risk of no root nodes existing within the final graph. One method to break cycles is to version the graph, wherein every system entity is associated with one-to-many nodes, and a new version is created each time information flows into the entity. While this prevents cycles, it also causes the graph to explode exponentially in size and is thus more costly to analyze. Alternatively, most provenance work in the security community tolerates cycles and resolves the issue by attributing timestamp values to edges.

[0046] Figure 3 depicts an overview of a pseudo root node hyperplane 300 associated with an original IDS system graph 302, in accordance with example embodiments. Given such a structure, a root cause is defined to be a node whose first event timestamp is onMBHB Docket No.24-0156-WO an outbound edge.

[0047] Pseudo-graph is an overlay graph on top of that retains the initial embeddings of all root nodes in . The construction of proceeds as follows: let be the set of nodes representing files or sockets in . For any node , if its first action withinis an outgoing flow = ( , , ), then is identified as a root cause. For example, inFigure 3, node F1’s first timestamped edge is outgoing and node F1 is therefore considered a root node. In contrast, node F2’s first timestamped edge is incoming and, as such, it is not a root node.

[0048] For each root , R-CAID first creates a new node known as ’s pseudo-root and then adds to the pseudo-graph assigning it the same initial feature vector associated with . After identifying a root cause, R-CAID keeps track of its descendantsdefined as any node such that a path ( , ) within exists. For each descendant node ,an outgoing edge is added from in directly connecting and .In Figure 3, within , F1’s pseudo-root connects to all of F1’s descendants nodes {P1, P2, F2}. Note, under this construction, it is impossible for an outbound edge from to to occur. In the end, information can only flow out of during message passing, but not into , thus assuring that pseudo-root node embeddings are not updated.

[0049] Given as additional input, R-CAID can update the embeddingfunction, = ( ( , ( ))) , as follows: = ( ( , ( ( ), ( )))) .Here represents a concatenation function that joins the aggregated representation of all nodes within and the aggregated representation over all pseudo-nodes in that directly connect into represented by . Figure 2 demonstrates how this new definition affects the embedding of P2 in block 202.

[0050] It is possible to generalize and extend root cause embedding to provideancestral paths of arbitrary depth ( -hop traversals). Given a root node , letbe ’s’ -hop neighborhood such that for every node in , there exists a path ( , ) where thelength of . To extend to root cause neighborhoods, pseudo-graph would be modified to host pseudo-root paths where each node in is a pseudo-node. Like pseudoroot nodes mirroring root nodes within the provenance graph , would emulate each path of length in the given root’s L-hop neighborhood. For a given node in a provenance graph , itsembedding utilizing a GNN would be = ( ( , ( ( ), ( )))) where are all thepseudo-root paths that indirectly connect with , i.e., there exists a path from the last node inMBHB Docket No.24-0156-WO to in the provenance graph. By enlarging the size of the overlay pseudo-graph to include pseudo-root paths , more information from the roots can be pulled down to each child node’s local neighborhood allowing for a more informed embedding. There is a balance in choosing how much of the root neighborhood to embed--larger values propagate more information andincrease the noise at each node’s neighborhood. R-CAID evaluation considers paths ( =0, = 1) or pseudo-roots and pseudo-root edges.

[0051] This disclosure, according to some example embodiments, considers an adversary that employs a sophisticated attack strategy, drawing from various techniques described in the MITRE ATT&CK framework. For example, the attacker may engage in mimicry attacks or other forms of masquerading, manipulating features of their own artifacts to appear legitimate to security tools. ORCHIDS will place the following restrictions on the adversary. The attacker cannot tamper with or turn off mechanisms in the trusted computing base of the system, which may comprise the operating system, any auditing subsystems, and the Prov-IDS. Beyond these assumptions, there are no further restrictions on the adversary.

[0052] This section will detail the framework of ORCHIDS. Notation and background information will be introduced. Next, the foundations of ORCHIDS will be detailed and an example implementation which uses a recurrent neural network (RNN) to analyze provenance graphs will be provided. Then, it will explain how any example implementation following ORCHIDS can provide meaningful representations, maintaining a low memory and computational overhead in real time. Lastly, some concrete strategies that utilize ORCHIDS framework to train models and classify anomalies will be identified.

[0053] Let the audit log A be a file that continuously records every interactionthat is captured by the auditing subsystem. Each line = ( , , , ) in A represents adirected edge ( ) between the source entity ( ) and the destination entity ( ) that occurs attime . The time does not need to be strictly defined using time, however, instead there may exist some kind of ordering between events in A. In an example embodiment, host level logs generally contain three different types of entities (process, file, and socket) and five different event types.

[0054] Table 400 of Figure 4 summarizes the system calls and provides a graphical representation of the event types. For host logs, each pair of system entities andsystem call is unique such that for any two system calls ( , , ), (, , ), it is alwaystrue that. The direction of each system call defines the flow of information within the system, and the same system call cannot represent two different flows. This may hold forMBHB Docket No.24-0156-WO all logs, and modifications to ORCHIDS framework to accommodate such changes may be implemented.

[0055] A provenance graph = < , > is a directed acyclic graphicalrepresentation of the audit log A adhering to a strict temporal property. This property ensuresthat for every node , all incoming edges ( , , , ), occur prior to any outgoing edges( , , , ), according to some defined ordering. For a given vertex , versioning insertsan identical (same initial feature vector) vertex whenever an incoming edge occurs after an outgoing edge.

[0056] This disclosure, according to some example embodiments, may comprise using autoregressive neural networks (ANN). ANNs are any model that learns on ordered data, inferring the relationship between different data points in a series. Sequential- based machine learning models are an example of ANNs, capturing order dynamics and dependencies between data points to generate accurate embeddings for time series. To illustrate,consider a sequential model operating on a data sequence = ( ,· · · , ) and itscorresponding sequence of feature vectors = ( ,· · · , ) where each token represents anumerical representation of its corresponding element . During prediction, the sequentialmodel takes the input sequence and produces an output sequence = ( ,· · · , )where each element captures the relationship between and the other elements in the sequence. A recurrent neural network (RNN) is one form of a sequential-based ANN.

[0057] The present disclosure, according to some example embodiments, leverages RNNs due to their use of loops within their architecture to capture temporal dependencies. RNNs use a numerical vector called a hidden state to pass context through sequences. At each time step, alongside the input sequence, the model is fed in the hidden state or the model’s “memory.” Consider to be an RNN, at each timestep within , takes in as inputs both the current feature vector and the hidden statefrom the previous timestep.At each timestep , = ( ,represents the embedding process where learns toaggregate the L-dimensional feature vector and the previous hidden state produce a new hidden state . The updated hidden state represents an embedding of the sequence up to timestep . The process recursively repeats, with each hidden state passed on to the nextstep + 1, until the entire sequence is processed.

[0058] Prior approaches to Prov-IDS that leverage neural networks have suffered from memory overhead, precision, and detection latency issues. Addressing these limitations requires analyzing lossless (i.e., versioned) provenance graphs in a computationallyMBHB Docket No.24-0156-WOand memory-efficient way. Consider a dynamic audit log A where at each timestep , an event= ( , , , ) between the entities and is added. Furthermore, let represent theversioned provenance graph representation for a snapshot of A at timestep .

[0059] ORCHIDS operates directly on audit log A to construct embeddings foreach entity, preserving its causal history with respect to . More specifically, as each event= , ) occurs, ORCHIDS uses a ANN to generate an embedding using:

[0060] where is an internal dictionary that maps each vertex to its most up- to-date embedding. This procedure is highly localized, where each event only updates a single dictionary entry, resulting in a constant time operation.

[0061] Further, given the immutable nature of versioned provenance graphs,Equation 1 allows for a system entity ’s entire provenance history ( , ) to be expressed asa single feature vector [ ], making it unnecessary to represent a graph structure explicitlywithin the state model. One possible implementation for , is using an RNN which has specific iterative update function that allows it to easily implement equation 1. For example, using anRNN, ORCHIDS requires only the sequence element [ ]the previous hidden state[] as input. Using only these elements, the RNN can output a new embedding thataccurately describes the causal sub-graph, ). However, there exist other ANN that maybe harder to implement, but may provide better embeddings making up for some of the limitations that occur within RNNs.

[0062] The ORCHIDS framework establishes a number of properties. First, ORCHIDS does not maintain explicit graph representation in its state model, thereby reducing its computation and memory cost. Second, because representing the graph is no longer a concern, ORCHIDS can maintain an accurate embedding for each system entity for a lossless, temporally versioned provenance graph. Third, because graph construction is implicit, ORCHIDS is ambivalent to the underlying event stream in terms of whether it is a whole- system provenance graph or multiple disjoint graphs. As a result, ORCHIDS can operate across multiple different log types at the same time if causality between all logs can be established.

[0063] In some example embodiments, ANNs require their inputs to be numerical vectors. Therefore, generating a representative feature vector for each entity within the audit log may be helpful. These numerical feature vectors may accurately describe the entities grouping similar entities. For each way to accomplish this, the present disclosure demonstrates the technique using system entities within host level logs. However, theseMBHB Docket No.24-0156-WO techniques could be extended to various other log types.

[0064] Each system entity may be represented in terms of its full system path, which denotes the entity’s location on disk. Files may be represented by their file paths, processes by the path to their binary executable, and sockets by their connecting IP addresses. To promote similarity and improve training, ORCHIDS may mask the most specific information tuple for each path type – in file paths, the file name gets masked, for processes, the binary executable name is masked, and for sockets, the last subnet is masked. In an example embodiment, ORCHIDS uses Doc2Vec to generate one or more L-dimensional embeddings for each system entity, although other unsupervised embedding schemes could be utilized interchangeably. ORCHIDS inputs the paths into Doc2Vec, dividing each path into distinct “words” — folder names for processes and files and subnets for IP addresses.

[0065] Figure 1 illustrates how an initial Doc2Vec embedding is expressed asthe non-provenance portion of each node’s embedding. For example, node 14 (Elevate 2) isdefined by its parent s embedding 13 , generated by a previous RNN operation, and theinitial feature vector 14, which was generated with Doc2Vec. Nodes that do not possess any provenance, e.g., 0 (FluxBox), are represented only by their Doc2Vec embedding. Another way to embed each entity is to gather all possible attributes associated with the given entity— for host logs these are recorded values about the given system entity. For example, for files / processes these attributes could be represented by certain permissions associated with the file / process or the malware score of the file / binary of the process. Using an autoencoder, the attributes could be embedded into a high dimensional space. To generate signal, similar attribute sets could be labeled together such that their embeddings appear close to each other in a high-dimensional space.

[0066] The goal of the training process is to produce the ANN such that it is able to model benign behavior. One possible way to ascertain this is to measure if the model embeds the past sequence of events such that the model can correctly predict at the given timestamp. At each timestep , the model’s output is fed into a linear layer to generate a probability distribution over all possible correct values. A loss function calculates gradients by measuring the difference between the probability distribution and correct value. The gradient is then back-propagated through the model to optimize its internal weights. Applying this training procedure leads ORCHIDS to learn based on past system activity. What the ANN predicts at the given timestamp is open to implementation details. The present disclosure provides example training schemes in terms of host logs.MBHB Docket No.24-0156-WO

[0067] The first training procedure tries to predict the process class at each timestep , where a processes’ class is equivalent to the common name of the program.Specifically, when encountering an edge = ( , , ) within the audit log and is aprocess, the output is passed through a linear layer to generate a probability distribution over all programs that exist within the training dataset. This training process example allows ORCHIDS to model program behavior within the host system, generalizing to hidden process behavior seen at inference. Another possible training strategy is to incorporate link prediction.At a given time , using the previous set of events 0,· · · , 1 , the model can predict theprobability of the given node (process) connecting to other nodes in the log. This probability distribution can be compared against the actual probability distribution (how many times doesthe future node + 1,· · · connect to every other node in the log). This allows the model tolearn what actions a given node may take based on its past activity. This results in nodes with similar past and future activity to be placed together.

[0068] The ORCHIDS framework assumes that training occurs offline where the training data is pre-defined, allowing for ORCHIDS to establish its internal weights over successive epochs through the training dataset. In Figure 1, a model under the ORCHIDS framework is trained based on the activity occurring before time 1. The model is optimized over all the activity that occurs within that period.

[0069] In some example embodiments, ORCHIDS may be used to identify anomalies in a computing device or network environment. There are numerous ways to identify anomalies given a trained model. An example method of identifying anomalies is detailed on host logs in the following section. Once trained, the ANN can effectively model normal activity on the host system. To detect and identify abnormal behavior, a set of benign embeddings representing normal behavior is created. One way to achieve this is by processing the entire training dataset and generating an L-dimensional embedding for each entity.

[0070] With a set of “normal” embeddings, ORCHIDS can detect anomalies inunseen data. For each new edge = ( , , ) streamed in, ORCHIDS generates an L-dimensional embedding for using Equation 1 that is then compared against the set of “normal” embeddings. The distance between ’s embedding and its closest neighbor determines its anomaly score. If this distance exceeds a pre-defined threshold , the ORCHIDS flags as anomalous.

[0071] Under extreme event loads, it may still be possible that a model trained using ORCHIDS does not keep up with the instantaneous event rate of the underlying system.MBHB Docket No.24-0156-WO There are several strategies to ensure to increase throughput. One possible strategy is to include parameter within the framework to determine the detection frequency. After collecting edges, ORCHIDS can batch non-dependent edges together, increasing throughput and reducing the number of calculations to measure abnormality. Nodes with embeddings having a distance greater than can then be flagged for subsequent investigation by a system analyst. This approach enables the ORCHIDS framework to balance real-time detection with computational efficiency, effectively identifying anomalous activities while efficiently utilizing resources.

[0072] In some example embodiments, ANNs may have difficulties capturing long-term dependencies. For example, consider an RNN. At each timestep , the RNN takes in the previous hidden stateand the feature vector and computes a new hidden statemathematically represented as = ( ) + ( ), where and are two matricesoptimized during model training using gradient descent. Gradients are propagated backward through time to capture temporal relationships, multiplied by a factor at each timestep. Thetraining strategy clips gradients between 0 1 to encourage small changes, leading to smallernumbers as gradients propagate further back in time. This problem is referred to as vanishing gradients. In practice, this may permit evasion opportunities for an attacker that strategically disperses their attack over a prolonged duration of time.

[0073] To harden models trained using the ORCHIDS framework and allow them to capture long-term dependencies, “root-node” embeddings are introduced. Root causes may be a source of information indicating the attacker’s origin. Moreover, unlike later attack steps, the attacker cannot manipulate root causes without directly tampering with the log. Looking back at Figure 1, consider the attack sequence to access and export sensitive information off the victim’s system. This attack chain’s root cause is the attacker’s server’sexternal IP address ( 8). Enforcing the external IP address as a root of the elevated process14 (Elevate 2) that is reading from sensitive information ( / etc / shadow v15) causes theresulting embedding to stand out as an outlier. ORCHIDS incorporates root causes by introducing an additional component called “root embedding.” ORCHIDS reflects thiscomponent in a modification to the RNN’s update function such that:

[0074] where { } is the set of root nodes associated with element in thesequence, and is a learnable model weight-optimized to balance the information introduced by root embedding. Root embedding maintains significant relationships over extended distances, invisible to the RNN, thereby enhancing the models resilience against an activeMBHB Docket No.24-0156-WO attacker. While Figure 1 does not visualize root embedding, some details are provided on what root embedding would look like for 14 (Elevate 2) at time 7. In Figure 1, Elevate 2 isrepresented as 14 = 14 + 15 + 13 . To incorporate root embedding, Elevate 2’s newrepresentation would be reflected as 14 = 14 + 15 + 13 + ( 8 + 0) whereis some number within the range [0, 1]. Root embedding allows 8 (an external IP address) to have direct influence over Elevate 2’s representation regardless of how far 8 is from Elevate 2 in the graph.

[0075] The performance of ORCHIDS was evaluated over 4 different datasets: StreamSpot, DARPA Transparent Computing Engagement 3 Theia and Trace, and ATLASv2.

[0076] StreamSpot is a multi-graph dataset describing five benign web browsing behaviors (CNN, YouTube, video game, Gmail, file download) and one attack behavior (Firefox drive-by download exploit). Each behavior is automated and repeated 100 times, resulting in 600 total graphs, each of which is relatively small (50K edges to 700K edges). ORCHIDS’s design intrinsically supports multiple disconnected graphs without issue, so some example embodiments combined all of the graphs together into a single audit log with unique entity identifiers for each graph. The five benign behaviors were interleaved in the log, with all attack behaviors appended at the end. For the preliminary training period, some example embodiments permit ORCHIDS to train on just a single instance of each of the benign behaviors. As a result, the ORCHIDS training, validation, and testing split is 1%, 1%, 98% respectively.

[0077] DARPA Transparent Computing Engagement 3 datasets comprises system graphs collected from various hosts over a 10-day period, with both benign activity on each host and red team attacks against each host. Theia (Ubuntu Linux 12.04), comprised of 21M edges, and Trace (Ubuntu Linux 14.04), comprised of 260M edges, system graphs were used. The majority of attacks performed involved exploiting Firefox to run drakon on the victim host. Most attacks were performed towards the end of the 10-day period, but some attacks happened earlier.

[0078] ATLASv2 replicates attack engagements the evaluation of the ATLAS threat investigation system. It comprises 10 attack chains, including both single-host and two- host attacks, although many of the steps in the chains partially overlap between attacks. A notable limitation of the original ATLAS dataset was the lack of meaningful benign activity; while limited benign activity was included, it does not follow a realistic usage profile and is insufficient to train one class anomaly detection models. ATLASv2 addresses these limitationsMBHB Docket No.24-0156-WO through the introduction of a four day period of benign naturalistic activity generated by human users, followed by a final day in which background activity continues as the attacks occur. Some example embodiments make use of the Microsoft Windows Security Auditing logs from this dataset, with the first day used for preliminary training.

[0079] The absence of a standardized ground truth labeling methodology for intrusion detection datasets presents a notable challenge to research in the field. Existing datasets employ disparate labeling approaches. Streamspot labels entire logs / graphs as either malicious or benign, the original ATLAS dataset labels only a small minority (2-3) of system entities as malicious in each attack chain, while DARPA TC datasets provide qualitative ground truth descriptions but no explicit labeling at all. This lack of uniformity in ground truth labeling raises concerns of both reproducibility and bias in IDS evaluations. To avoid these issues, ORCHIDS may make use of the Recover Every Attack Process (REAPr) label set. REAPr contains process-level ground truth labels for all of the datasets above using a standardized provenance-based labeling methodology. By marking every process on the path between an attack’s root causes and terminal impacts as malicious, REAPr provides a more comprehensive set of attacker-influenced processes while avoiding the potential for experimenter bias.

[0080] The present disclosure will now explore the relative contributions of different components of the ORCHIDS framework. Of note are six facets of ORCHIDS: selection of RNN model, number of model layers, amount of training data, inclusion of root node adaptation, size of feature vector, and the classification task. To facilitate faster testing of various model parameters, some example embodiments use the StreamSpot dataset (except where otherwise noted) due to its smaller size. The outcomes of the hyperparameter search are illustrated in Figures 5A, 5B, 5C, 5D, 5E, and 5F , wherein each plot presents the Receiver Operating Characteristic (ROC) curve that compares ORCHIDS’ true and false positive rates under variable classification thresholds.

[0081] As previously stated, an autoregressive sequence to sequence model may be adapted to ORCHIDS because it can effectively model causal paths given limited information about the underlying sequence. However, the RNN suffers from a memory loss issue, which may impede its ability to effectively model longer sequences of attack behaviors. A Gated Recurrent Units (GRUs) mechanism may address this limitation of RNNs through a gating mechanism that selectively updates and resets information. When comparing the RNN and GRU architectures with all other model parameters constant in Figure 5A, the GRU clearly outperforms the RNN even on the relatively short-lived Streamspot dataset (0.59 vs.0.42 AUC). Thus, GRU is employed as the model backbone for ORCHIDS, although it should be notedMBHB Docket No.24-0156-WO that their higher computational demand may extend training and testing times where computational resources are limited.

[0082] Previous research has highlighted the impact of model size on performance. Continuing with the GRU, the number of model layers (1, 5, 10, 20) are varied in Figure 5B. As anticipated, increasing the number of layers improved classification performance, but concomitantly increases the computational resources required. While the 1- layer GRU performs markedly worse (0.37 AUC), diminishing returns are observed on increased model size between the 5-, 10-, and 20-layer models. In an example embodiment, a 10-layer GRU for the subsequent experiments was utilized.

[0083] In order to mitigate RNNs’ difficulty modeling longer-term dependencies, ORCHIDS includes an optimization that directly embeds every entity’s root causes alongside its local context. Experimentation conducted with an example embodiment compared the performance of ORCHIDS with and without this optimization in Figure 5C. Inclusion of this optimization improves ORCHIDS’ classification overall (0.59 vs.0.54 AUC), and this improvement is most pronounced at low FPR values. These findings demonstrate that the additional context provided by root causes can help to detect additional attack entities that were otherwise overlooked.

[0084] In some example embodiments of ORCHIDS, the feature vector that serves as a numerical representation of each system entity may be important. While richer feature vectors may better capture underlying data distributions, the inclusion of additional information could also introduce noise. Comparing different vector sizes in Figure 5D, a vector of size 64 achieves the most favorable ROC curve (0.59 AUC). In some example embodiments, this size was used for subsequent experiments.

[0085] While the size of ORCHIDS’ preliminary training dataset could play an important role in the performance of some embodiments, it may be desired in some other example embodiments to move into the streaming phase quicker. To determine an appropriate training dataset size, some example embodiments make use of the larger Theia dataset. Starting with a training dataset of 10K edges, the size was gradually increased to 1M edges, where the 1M edges correspond to a single day of logging on the host system. As illustrated in Figure 5E, there is a general trend of improved classification performance as the amount of training data increases. Some example embodiments trained ORCHIDS on 1M events (0.91 AUC) in subsequent experiments; this amount is roughly proportional to a full day of activity and is likely to generalize better to other datasets.

[0086] While ORCHIDS is able to classify any system entity present in theMBHB Docket No.24-0156-WO provenance graph, it could be that performance varies between agentive process entities as compared to data entities like files or sockets. ORCHIDS performs one class anomaly detection in testing, but was trained to predict process labels, meaning that its test time performance could align better with process classification. Continuing with the Theia dataset, some example embodiments compared process-only to all-entity embedding performance in Figure 5F. There was no significant difference between the two tasks, with “All Nodes” classification negligibly outperforming “Process Only” (0.91 vs 0.90 AUC). Despite the marginal difference in performance, for the remainder of the experiments, some example embodiments opted to embed all nodes within the graph when evaluating ORCHIDS’ performance.

[0087] Figure 6 illustrates evaluations of the classification performance of ORCHIDS. Every process on the attack path is marked as malicious, meaning ORCHIDS is being evaluated on its ability to identify every attacker-influenced process in each dataset.

[0088] Benchmarking ORCHIDS’s performance on entity-level classification excludes most prior work, majority of which does whole-graph classification and are particularly vulnerable to mimicry attacks. Even sub-graph systems like SIGL and Prographer still fundamentally perform graph-level classification, but on smaller time slices.

[0089] ORCHIDS was evaluated against two variants of a GNN architecture. The first model, Full-GNN, represents a traditional offline deployment model in which the full graph (training and test data) is constructed before training begins. This model performs nearly- identically to ShadeWatcher on the same dataset (Trace) that appeared in its evaluation. The second model, Stream-GNN, attempts to adapt the Full-GNN to a streaming setting. The Stream-GNN model is restricted to the same training data given to ORCHIDS in each experiment, and is also unable to pre-populate its adjacency matrix and node matrix to reflect events and entities that only appear during the test period. Stream-GNN is thus an approximation to the discriminatory power of a GNN under ORCHIDS’ deployment model.

[0090] Recall that another limitation of GNN architectures is their inability to efficiently represent lossless (e.g., versioned) provenance graphs. Unsurprisingly, attempting to train a PyTorch GNN on a versioned provenance graph quickly results in an out-of-memory error even on a well-provisioned GPU server. Provenance graphs, even those that describe a single system, are simply much larger than the graphs used to evaluate other graph learning systems, and current architectures cannot scale. As a workaround, the ORCHIDS baseline models use a simplified provenance representation that fails to capture the temporal ordering between events and results in false provenance For example, if a process reads from file A, writes to file B, then reads from file C, a GNN will incorrectly include file C in file B’sMBHB Docket No.24-0156-WO embedding. For both GNNs, a hyperparameter search revealed that 2 layers and 8 heads delivered the optimal performance. Each GNN trained for a maximum of 1000 epochs with early stopping, using Cross-Entropy loss and the Adam optimizer to tune the model weights.

[0091] Some example embodiments of ORCHIDS were compared against Karios, a Prov-IDS that uses the temporal information within provenance graph to identify abnormal behavior. Karios adapts a temporal graph network (TGN) to a provenance setting, utilizing an encoder / decoder network to model the underlying data. Karios intentionally includes temporal information during model classification as a cornerstone of its design, allowing it to be adapted in a streaming setting. There are a few differentiators that separate ORCHIDS from Karios. First, given Karios uses TGN as its backbone, Karios exhibits properties that are relevant to general dynamic graph learning (such as node deletion) but are present in provenance graphs. As a result, Karios’s update function utilizes the edge information when updating the node state as every event within the audit log. Karios embeds each edge using a GNN, using all the nodes within in edge neighborhood to make an embedding. The edges are encoded and decoded using an autoencoder, where the decoding tries to guess the edge’s type. For edges with large reconstruction errors, the source and destination nodes are flagged as abnormal. This differs from ORCHIDS which propagates the node information using the DAG of versioned graphs. Additionally, ORCHIDS does not require a representation of the provenance graph to be kept in memory (albeit reduced to only an adjacency matrix) and use a GNN to embed edges. This allows ORCHIDS to remain more effective and flexible than Karios. Second, Karios uses the edge reconstruction loss to identify abnormal edges. However, modeling system behavior using the course grain edge labels is not be specific enough to provide a good embedding. The use of training the system using process labels allows for ORCHIDS to be more specific than Kairos. The performance of ORCHIDS was measured against Kairos and show that it is able to provide better memory and computational overhead while maintaining accuracy.

[0092] Part a of Figure 6 illustrates results for Streamspot in ORCHIDS versus various other IDS models. In the critical range of detection thresholds with low FPR values, ORCHIDS offers a number of effective performance rates. ORCHIDS is able to detect 23% of all malicious entities, representing at least one detection for each attack behavior, with 0% FPR, and nearly reaches the Full-GNN’s 0% FPR detection rate while admitting just 9% FPR. On the other hand, given comparable training data (Stream-GNN), the GNN’s performance hovers around chance (0.51 AUC).

[0093] Part b of Figure 6 also illustrates results for Theia in ORCHIDS versusMBHB Docket No.24-0156-WO various other IDS models. There is a similar trend to Streamspot where Full-GNN outperforms ORCHIDS (1.00 vs. 0.91 AUC) while ORCHIDS outperforms Stream-GNN (0.91 AUC vs. 0.73 AUC). Furthermore, ORCHIDS achieves 97% detection with 15% FPR indicating that the majority of the attack within Theia is able to be separated from benign behavior. However, certain attack entities are harder to separate out as they may only be tangentially related to the attack.

[0094] Part c of Figure 6 also illustrates results for ORCHIDS against the much- larger Trace dataset, ORCHIDS outperforms the Full-GNN (0.88 vs 0.63 AUC). In the region of low FPR detection thresholds, Full-GNN offers a higher detection rate of 35% at 0% FPR, while ORCHIDS is able to offer a 60% TPR with a manageable 12% FPR. Stream-GNN actually outperforms Full-GNN across the entire continuum (0.8 vs. 0.63 AUC), although its gains come at high FPR values.

[0095] Part d of Figure 6 deviates from the previous pattern. Here, ORCHIDS unambiguously outperforms the Full-GNN, offering superior TPR rate at 0% FPR and approaching 89% TPR at near-zero FPR. Stream-GNN’s performance again hovers at 0.51 AUC.

[0096] For three out of the four datasets, ORCHIDS was surpassed in classification performance by Full-GNN. This was expected, given that the GNN had the advantage of learning its embedding function in a static graph that represented the entire dataset providing more information to the model during training time. This allowed the Full-GNN to overcome distribution shifts present between the training and testing dataset, enabling it to more accurately model benign activity. ORCHIDS exhibited better performance on the ATLASv2 dataset than the Full-GNN. One potential reason for this outcome is that certain attack nodes in ATLAS were spaced out from each other, making them unable to be directly correlated within the limited K-hop neighborhood view of the Full-GNN. Conversely, ORCHIDS, could capture longer-term dependencies allowing it to discern patterns that may be missed by the full GNN’s local viewpoint. Regardless performance variance by dataset, both systems were able to detect one or more malicious entities in each attack at a low-FPR threshold.

[0097] ORCHIDS operates with significantly reduced memory consumption compared to previous approaches. By processing events in the graph in a streaming fashion and tracking embeddings for each system entity, ORCHIDS reduces the terms in its memoryconsumption from | | + | | to | | . The memory reduction acquired by removing the edgeterm | | compounds over time as the number of system entities grows at a slower pace thanthe number of system events. Intuitively, activity predominately consists of existing systemMBHB Docket No.24-0156-WO entities interacting with other existing system entities rather than the generation of new system entities.

[0098] Figure 7 depicts the memory consumption of an IDS system architecture, in comparison with GNN systems, in accordance with example embodiments. ORCHIDS’s memory consumption is shown in Figure 7 on an increasingly larger portions of the Trace dataset. To provide context, Figure 7 also plots the memory consumption of Stream- and Versioned-GNN. Stream-GNN represents the memory consumption of the GNN on an unversioned graph where the temporal attributes of the provenance graph are ignored. The memory consumption of Full-GNN is represented by the memory consumption of Stream- GNN at the end of the dataset. Versioned-GNN represents the memory consumption of GNN on the more precise versioned graph that ORCHIDS utilizes, requiring 143.7GB to store in memory. The difference in memory consumption between Full-GNN and Versioned-GNN underscores the reality that GNNs are utilizing less precise graph representations. Even with a less precise graph representation, Stream and Full-GNN maintain a higher memory footprint (10.4 GB) than ORCHIDS whose footprint does not exceed 2.7 GB while modeling the entirety of the 270 GB dataset.

[0099] The raw processing speed of each model is demonstrated in the runtime of three model tasks: preprocessing, training, and embedding and detection. Preprocessing indicates the time required to map the log into memory and process it into a provenance graph. Training is an upfront cost for ORCHIDS and Stream-GNN, but a backend cost for the Full- GNN that immediately precedes embedding and detection; therefore, these runtime costs do not yet reflect detection latency for ORCHIDS and Stream-GNN. A performance distinction between the RNN architecture and the GNNs is the opportunity for parallelization; while ORCHIDS operates on sequential edges at a constant cost, the GNN is able to parallelize across portions of the static graph. To reflect this advantage for the Stream-GNN, embedding and detection for different checkpoint intervals of data is reported. The total time for the Stream- GNN to embed and classify 1 edge at a time, 1K edges, etc., with EOF indicating the full test batch is also provided.

[0100] Figure 8 is a table illustrating the runtime of an IDS system in comparison with a GNN system, in accordance with example embodiments. ORCHIDS has an advantage in the pre-processing stage because it does not actually need to generate a provenance graph, instead mapping the edges into memory. When comparing the offline training time between ORCHIDS and Stream-GNN, Stream-GNN is able to batch over the static provenance graph, allowing for greater parallelization. In ORCHIDS, it is possible toMBHB Docket No.24-0156-WO batch together nondependent events together allowing for faster training time. In comparing the embedding and detection (ED) time for ORCHIDS and Stream-GNN, Stream-GNN outperforms ORCHIDS when operating on batches of 1M edges or greater due to the GNN’s ability to parallelize computation over a known static graph. In contrast, ORCHIDS must operate on one large stream of sequential data.

[0101] Without parallelization, the GNN requires 160 billion seconds to complete, a 360K times increase over ORCHIDS. For the same reasons, ORCHIDS test time costs are independent of checkpoint intervals, processing edges at a constant rate that equates to 300 edges per second.

[0102] The true cost of the GNN deployment model is exposed when considering the lag between an events occurrence and its classification. Based on the time required to train and test the Full-GNN model on the Trace dataset (67.4K seconds, or 18 hours), consider a practical deployment model where a GNN classifier is trained on the previous 14 days’ worth of data at midnight each night, then immediately attempts to classify the observed events from the previous day. Instead of re-training and detecting Full-GNN, on each of the 14 days of Trace, estimating the average time it would take Full-GNN to train and test every night was calculated by the average time Full-GNN took to run over the different datasets.

[0103] Figure 9 depicts the detection lag of an IDS system in comparison to a GNN system, in accordance with example embodiments. The x-axis depicts the time series of Trace, while the y-axis depicts the expected detection lag for an event that occurs at that time point. Depending on the time of day, ORCHIDS reduces detection lag by a minimum of 10 million times up to a maximum of 43 million times by eschewing the GNN’s offline deployment model. The minimum time detection lag for Full-GNN for an event that occurred directly right before analysis would still be 18 hours while the maximum time for an event that occurred right after analysis occurred would be 42 hours. ORCHIDS, on the other hand, could process each event after it occurred providing a detection lag time of 0.002 seconds. By streaming, ORCHIDS is able to considerably reduce the attacker’s “dwell” time on the system. III. Alternative Embodiments

[0104] A first alternative embodiment of the present disclosure adds forward- trace embedding to R-CAID. In some embodiments, R-CAID uses a back-trace to create node embeddings. A back-trace is a process of following the links from a node to its parent nodes. In some embodiments, R-CAID may only consider the root node of a particular node in the graph when creating node embeddings. This means that the node embeddings only capture the information about the root node. However, the effects of a particular node can be spread outMBHB Docket No.24-0156-WO over many nodes in the graph. For example, if a node is used to create a malicious file, the effects of that node will be spread out over all of the nodes that access the malicious file.

[0105] Forward-trace embedding helps to address this by providing the IDS with more information and context, enabling it to make predictions that are more accurate. To achieve this, some alternative embodiments may reverse the embedding creation process used in the R-CAID system and replace the existing back-trace with a forward-trace. The modified R-CAID of some alternative embodiments considers all of the impact nodes in the graph when creating node embeddings. This means that the node embeddings capture the information about all of the nodes that are affected by a particular node. This allows the modified R-CAID to detect anomalies more accurately than in some other embodiments.

[0106] Forward-tracing is a promising technique for improving the accuracy and completeness of Prov-IDSs. It can also be used to better detect malicious activity and reduce false positives. Forward-trace embedding provides the IDS with more information about the attack, including the sequence of events that led up to the attack and the impact of the attack on the network. This additional information can help the IDS to make more accurate predictions about future attacks. Forward-trace embedding can also improve the accuracy of an IDS by providing it with more context about the attack. This context can help the IDS to distinguish between malicious and benign activity. Forward-trace embedding can further help to improve the coverage of an IDS by allowing it to detect attacks that would otherwise be missed by a back-trace system. This is because a forward-trace system can track the attack from its source to its impact, while a back-trace system can only track the attack from its impact to its source.

[0107] Some alternative embodiments may utilize a GNN that includes forwardtrace embedding. Given a graph = ( , ), let =be the set of nodefeatures where is the number of features associated with each node. Furthermore, let be anadjacency matrix that describes such that [ , ] = 1. GNN is aneural network made up of layers where each layer in the network aggregates features fromnodes hops away. Passing adjacency matrix and node features through the GNN ( , )results in an (| | × ) embedding matrix .

[0108] Message passing flows information according to the direction of the edge. As a result, each node is updated strictly by its -hop neighborhood . Messagepassing at each layer is an update between the previous layer’s intermediate representation, and such that)) . For the first layer, , is the set of nodefeatures .MBHB Docket No.24-0156-WO

[0109] Recursively using node ’s representation through each layer of allows messages to propagate from all nodes within ’s -hop neighborhood. The learned embedding matrix is then simply the representation outputted from the final th layer in . Once the embedding matrix has been defined, it can then be used in node classification.

[0110] The GNNs are typically trained on datasets with different classes, and learn to distinguish one class from another by clustering them and / or assigning scores. In some IDS systems, all the processes are considered to belong to one class, therefore preventing the data set from being divided into different classes. Hence, according in some embodiments, if the model is trained on both attack and benign data, it will create biases in the results and would not accurately classify attack and benign data.

[0111] In some embodiments of RCAID, during the training process, the system trains only on benign data and learns to classify this data into groups. By doing so, all similar activities of a given process are clustered together and have a low distance from one another. Take the example of Figure 10, without the attack activity, which is shown in dotted boxes. The boxes highlighting the legitimate activity, with hashmarks, would be clustered together with the activity of the Firefox node connecting to the given website, in this case, www.nhra.com. This is because connecting to different websites and library files is Firefox’s usual activity. Therefore, these usual activities will have a smaller distance from one another. Then during the testing phase, the model is tested on benign and attack data. Benign activity is clustered close to the activity it has seen before during the training phase. However, when attack activity, in dotted boxes, is introduced, the nodes representing the attack activity are clustered away from the previous benign behavior. Taking the same example as Figure 10, the attack activity nodes shown in dotted boxes would be clustered away from those shown with hashmarks and will have a higher distance. Firefox connecting to the SSD log is unusual, and therefore determined to be attack activity that is clustered farther from normal activity nodes.

[0112] Some embodiments may only create embeddings for impact nodes rather than R-CAID’s embedding for root cause nodes. In further alternative embodiments, both the forward- and backward-trace systems can be combined to create a new system that incorporates context from both types of traces. This may result in a more powerful and effective IDS that can detect and prevent a wider range of cyber-attacks.

[0113] In another alternative embodiment, a hybrid IDS system that incorporates EDR-generated rule-based alerts within the graph embedding process of a GNN- based anomaly detection system is provided. Incorporating these alerts within the graphMBHB Docket No.24-0156-WO embedding process allows the hybrid IDS to provide additional useful context, and in turn improve the performance of the underlying GNN-based anomaly-detection system. The alternative embodiments may include adapting the ATLASv2 dataset, generating alert embeddings, and designing a node-based anomaly detection system.

[0114] Both EDR systems and anomaly-based detection systems have their own respective strengths and limitations. Anomaly-based approaches are suited for detecting zero- day attacks that are not included in heuristic knowledge bases, while heuristic-based approaches can accurately detect known attack patterns. However, both approaches have been historically prone to high rates of false positives, resulting in threat alert fatigue problems for analysts. Despite the unique value proposition of each approach, their combined potential remains largely unexplored. The alternative embodiments provided consider the insights gained from root cause analysis and the traceability offered by data provenance for combining these two approaches for a comprehensive understanding of system vulnerabilities and enhanced threat detection capabilities.

[0115] Provenance-based systems transform audit logs into dependency graphs illustrating the causal links between events. This graph-based approach simplifies attack investigation by establishing a clear link between an attack behavior and its underlying cause, providing insights to the vulnerabilities that were exploited and potential areas of mitigation. The alternative embodiments propose a hybrid IDS that leverages the strengths of both anomaly-based and heuristic-based systems by intelligently incorporating additional context from EDR-generated rule-based alerts and establishing causal links between them. This hybrid IDS improves the reliability of intrusion detection systems by leveraging recent advancements in node-level classification, which holds promise in defending against mimicry attacks and preserving root causes during the embedding process.

[0116] The hybrid IDS works on top of a GNN-based node-level classification model. It pre-computes every nodes’ associated alerts during graph construction and then directly connects each local node to its associated alerts (if any) during graph embedding. The hybrid IDS may use different embedding models for the EDR generated rule-based alerts. The EDR alerts in ATLASv2 consist of a description, tags, indicators of compromise, and a severity score. The present disclosure gives four different approaches to determine which combinations of these alert elements produce the most meaningful embeddings. The generated alerts are then used as input for training two different embedding models: Doc2Vec, and RoBERTa. With the resulting embeddings, the present disclosure compares the cosine similarity between alerts of a specific severity and all other known alerts of the same severity.MBHB Docket No.24-0156-WO

[0117] The alternative embodiments may utilize a GNN for node-based anomaly detection. The GNN takes in as input the provenance graph along with a set of feature vectors corresponding to each node within the graph. The GNN may be configured to create a -dimensional vector that accurately describes each node in the provenance graph in terms of the node and its -hop neighborhood. During the graph construction, the system may precompute the associated alerts for each node and connect each process node to its corresponding alert node(s), if any. The feature vectors are then processed by the GNN to produce an embedding matrix for each node, which is used for anomaly / outlier detection. The system uses self-supervised learning and process tags for training and generates an anomaly score for each process node in the test set.

[0118] Figure 11 provides an overview of a hybrid IDS architecture. During the graph construction, the hybrid IDS precomputes the associated alerts for each node and connects each process node to its corresponding alert node(s), if any. The provenance graph, along with the alert nodes, is fed to an embedding engine that generates a set of feature vectors corresponding to each node and the adjacency matrix. A GNN then processes the feature vectors to produce an embedding matrix for each node. The embedding matrix is utilized for anomaly / outlier detection.

[0119] The GNN is designed to create a -dimensional vector that accurately describes each node in the provenance graph in terms of the node and its -hop neighborhood. The alternative embodiments may achieve this by using a message passing technique where information flows according to the direction of the edge.

[0120] The GNN takes in as input the provenance graph along with a set of feature vectors corresponding to each node within the graph. For each layer within the GNN, a node’s new representation is an update between its existing intermediate representation and an aggregation of all the intermediate representations of nodes in its -hop neighborhood. During model training, aggregation and update functions are optimized to represent the node accurately.

[0121] The GNN consists of layers, where each layer L in the network aggregates features from nodes L hops away. The final layer of the GNN outputs an embedding matrix E for each node, which can be used in downstream tasks like node classification or outlier detection.

[0122] Alert embeddings are generated by combining various alert features from the ATLASv2 dataset. Four combinations and full examples are given in in Table 1:MBHB Docket No.24-0156-WOTable 1: Alert styles used to generate embeddings.

[0123] E-Plain uses the alert description alone. Alert descriptions are strings providing a brief explanation of the possible threat. These range from around 10 to 500 words in length.

[0124] E-Int incorporates each alert’s severity score as “Severity=*” by adding it to the beginning of each description.

[0125] E-Rating modifies the severity score by generating a short statement about the rating (e.g. “this is a very high severity alert”), and combines this rating with the description.

[0126] E-Zipper takes the severity score as it appears in E-Int and distributes it between each word of the alert description.

[0127] The generated alerts are used to train two models for embeddings: Doc2Vec, and RoBERTa.

[0128] Doc2Vec is an algorithm used for generating fixed-length numerical representations of documents (e.g., embeddings). It is an extension of Word2Vec, a common tool for generating word embeddings. Word2Vec utilizes a neural network and attempts to predict a word based on the text surrounding it. Doc2Vec adds to this, analyzing an entire document and learning over a larger window. This allows the model to capture meaningful relationships between words in a document within in a continuous vector space.

[0129] RoBERTa leverages the transformer architecture known for the ability to capture contextual relationships by using attention mechanisms. During training, tokens are given as input with a number of randomly selected tokens masked. The model then analyzes the remaining tokens for context and predicts the masked tokens. This process enables the model to capture the relationship between words.MBHB Docket No.24-0156-WO

[0130] Assessing the results of the embedding methods involved calculating the mean cosine similarity of each alert when compared to all other alerts of the same severity. The results show that the “embedding zipper” method consistently produced embeddings where alerts of a specific severity displayed the highest similarity to alerts of the same severity. Notably, the zipper incorporates the severity score at a much higher frequency, suggesting that both models effectively generate embeddings representative of the provided descriptions. This finding underscores the models’ proficiency in capturing the essential characteristics of EDR alerts.

[0131] The provenance graph , associated alerts, and the embedding scheme are fed to the embedding engine. The embedding engine trains a model that considers traditional node features such as file paths, process names, and IP addresses, along with alert descriptions, to output feature vectors and an updated adjacency matrix. The process nodes are connected to their associated alert nodes, if any, in the adjacency matrix

[0132] To adapt the GNN for one-class setting, hybrid IDS uses self-supervised learning and process tags. During training, each process node is labeled by the type of process it represents, generated from the associated file path to its binary executable.

[0133] For testing, the hybrid IDS generates an anomaly score for each process node in the test set. First, the GNN produces an embedding matrix for each node. Then, K- Means clusters the node embeddings in the training dataset to identify the optimal K for intra- and inter-cluster variation. Finally, for each node in the test set, the median absolute deviation (MAD) generates an anomaly score by calculating the Euclidean distance between the node and the median of its nearest cluster. Any node whose Euclidean distance is greater than a specific variation is considered abnormal. IV. Example Computing Devices and Cloud-Based Computing Environments

[0134] Figure 12 is a simplified block diagram exemplifying a computing device 1200, illustrating some of the components that could be included in a computing device arranged to operate in accordance with the embodiments herein. Computing device 1200 could be a client device (e.g., a device actively operated by a user), a server device (e.g., a device that provides computational services to client devices), or some other type of computational platform. Some server devices may operate as client devices from time to time in order to perform particular operations, and some client devices may incorporate server features.

[0135] In this example, computing device 1200 includes processor 1202, memory 1204, network interface 1206, and input / output unit 1208, all of which may be coupled by system bus 1210 or a similar mechanism. In some embodiments, computing device 1200MBHB Docket No.24-0156-WO may include other components and / or peripheral devices (e.g., detachable storage, printers, and so on).

[0136] Processor 1202 may be one or more of any type of computer processing element, such as a central processing unit (CPU), a graphical processing unit (GPU), another form of co-processor (e.g., a mathematics or encryption co-processor), a digital signal processor (DSP), a network processor, and / or a form of integrated circuit or controller that performs processor operations. In some cases, processor 1202 may be one or more single-core processors. In other cases, processor 1202 may be one or more multi-core processors with multiple independent processing units. Processor 1202 may also include register memory for temporarily storing instructions being executed and related data, as well as cache memory for temporarily storing recently-used instructions and data.

[0137] Memory 1204 may be any form of computer-usable memory, including but not limited to random access memory (RAM), read-only memory (ROM), and non-volatile memory (e.g., flash memory, hard disk drives, solid state drives, compact discs (CDs), digital video discs (DVDs), and / or tape storage). Thus, memory 1204 represents both main memory units, as well as long-term storage.

[0138] Memory 1204 may store program instructions and / or data on which program instructions may operate. By way of example, memory 1204 may store these program instructions on a non-transitory, computer-readable medium, such that the instructions are executable by processor 1202 to carry out any of the methods, processes, or operations disclosed in this specification or the accompanying drawings.

[0139] As shown in Figure 12, memory 1204 may include firmware 1204A, kernel 1204B, and / or applications 1204C. Firmware 1204A may be program code used to boot or otherwise initiate some or all of computing device 1200. Kernel 1204B may be an operating system, including modules for memory management, scheduling and management of processes, input / output, and communication. Kernel 1204B may also include device drivers that allow the operating system to communicate with the hardware modules (e.g., memory units, networking interfaces, ports, and buses) of computing device 1200. Applications 1204C may be one or more user-space software programs, such as web browsers or email clients, as well as any software libraries used by these programs. Memory 1204 may also store data used by these and other programs and applications.

[0140] Network interface 1206 may take the form of one or more wireline interfaces, such as Ethernet (e.g., Fast Ethernet, Gigabit Ethernet, 10 Gigabit Ethernet, Ethernet over fiber, and so on). Network interface 1206 may also support communication over one orMBHB Docket No.24-0156-WO more non-Ethernet media, such as coaxial cables or power lines, or over wide-area media, such as Synchronous Optical Networking (SONET), Data Over Cable Service Interface Specification (DOCSIS), or digital subscriber line (DSL) technologies. Network interface 1206 may additionally take the form of one or more wireless interfaces, such as IEEE 802.11 (Wifi), BLUETOOTH®, global positioning system (GPS), or a wide-area wireless interface. However, other forms of physical layer interfaces and other types of standard or proprietary communication protocols may be used over network interface 1206. Furthermore, network interface 1206 may comprise multiple physical interfaces. For instance, some embodiments of computing device 1200 may include Ethernet, BLUETOOTH®, and Wifi interfaces.

[0141] Input / output unit 1208 may facilitate user and peripheral device interaction with computing device 1200. Input / output unit 1208 may include one or more types of input devices, such as a keyboard, a mouse, a touch screen, and so on. Similarly, input / output unit 1208 may include one or more types of output devices, such as a screen, monitor, printer, and / or one or more light emitting diodes (LEDs). Additionally or alternatively, computing device 1200 may communicate with other devices using a universal serial bus (USB) or high- definition multimedia interface (HDMI) port interface, for example.

[0142] In some embodiments, one or more computing devices like computing device 1200 may be deployed. The exact physical location, connectivity, and configuration of these computing devices may be unknown and / or unimportant to client devices. Accordingly, the computing devices may be referred to as “cloud-based” devices that may be housed at various remote data center locations.

[0143] Figure 13 depicts a cloud-based server cluster 1300 in accordance with example embodiments. In Figure 13, operations of a computing device (e.g., computing device 1200) may be distributed between server devices 1302, data storage 1304, and routers 1306, all of which may be connected by local cluster network 1308. The number of server devices 1302, data storages 1304, and routers 1306 in server cluster 1300 may depend on the computing task(s) and / or applications assigned to server cluster 1300.

[0144] For example, server devices 1302 can be configured to perform various computing tasks of computing device 1200. Thus, computing tasks can be distributed among one or more of server devices 1302. To the extent that these computing tasks can be performed in parallel, such a distribution of tasks may reduce the total time to complete these tasks and return a result. For purposes of simplicity, both server cluster 1300 and individual server devices 1302 may be referred to as a “server device.” This nomenclature should be understood to imply that one or more distinct server devices, data storage devices, and cluster routers mayMBHB Docket No.24-0156-WO be involved in server device operations.

[0145] Data storage 1304 may be data storage arrays that include drive array controllers configured to manage read and write access to groups of hard disk drives and / or solid state drives. The drive array controllers, alone or in conjunction with server devices 1302, may also be configured to manage backup or redundant copies of the data stored in data storage 1304 to protect against drive failures or other types of failures that prevent one or more of server devices 1302 from accessing units of data storage 1304. Other types of memory aside from drives may be used.

[0146] Routers 1306 may include networking equipment configured to provide internal and external communications for server cluster 1300. For example, routers 1306 may include one or more packet-switching and / or routing devices (including switches and / or gateways) configured to provide (i) network communications between server devices 1302 and data storage 1304 via local cluster network 1308, and / or (ii) network communications between server cluster 1300 and other devices via communication link 1310 to network 1312.

[0147] Additionally, the configuration of routers 1306 can be based at least in part on the data communication requirements of server devices 1302 and data storage 1304, the latency and throughput of the local cluster network 1308, the latency, throughput, and cost of communication link 1310, and / or other factors that may contribute to the cost, speed, fault- tolerance, resiliency, efficiency, and / or other design goals of the system architecture.

[0148] As a possible example, data storage 1304 may include any form of database, such as a structured query language (SQL) database or a No-SQL database (e.g., MongoDB). Various types of data structures may store the information in such a database, including but not limited to files, tables, arrays, lists, trees, and tuples. Furthermore, any databases in data storage 1304 may be monolithic or distributed across multiple physical devices.

[0149] Server devices 1302 may be configured to transmit data to and receive data from data storage 1304. This transmission and retrieval may take the form of SQL queries or other types of database queries, and the output of such queries, respectively. Additional text, images, video, and / or audio may be included as well. Furthermore, server devices 1302 may organize the received data into web page or web application representations. Such a representation may take the form of a markup language, such as HTML, XML, JSON, or some other standardized or proprietary format. Moreover, server devices 1302 may have the capability of executing various types of computerized scripting languages, such as but not limited to Perl, Python, PHP Hypertext Preprocessor (PHP), Active Server Pages (ASP),MBHB Docket No.24-0156-WO JAVASCRIPT®, and so on. Computer program code written in these languages may facilitate the providing of web pages to client devices, as well as client device interaction with the web pages. Alternatively or additionally, JAVA® may be used to facilitate generation of web pages and / or to provide web application functionality. V. Example Technical Improvements

[0150] Current implementations of provenance-graph-based IDS methods suffer from being computationally expensive and having high memory consumption. Furthermore, GNN based IDS methods may require long periods of training before they are able to effectively detect intrusions on a computing system, allowing attackers to “dwell” for long periods while evading detection. While accurate, these limitations lead prior IDS methods to be impractical to deploy in real-world environments.

[0151] ORCHIDS utilizes streaming embedding and detection to reduce the memory consumption and training time necessary to deploy a provenance-graph-based IDS. Streaming embedding and detection may associate the graph representing a computing system to a pseudo-graph that connects each event in the system to one or more root causes. This may allow ORCHIDS to greatly reduce the memory needed to implement an IDS. Furthermore, it improves the accuracy of intrusion detection by ORCHIDS. Connecting each event to its root cause improves ORCHIDS overall classification accuracy rate.

[0152] These embodiments provide a technical solution to a technical problem. One technical problem being solved is the high detection latency in GNN based IDS methods. In practice, this is problematic because an attacker may “dwell” on a system for extended periods of time before an anomaly is detected.

[0153] In the prior art, GNN-based IDS methods must train and test a full GNN method prior to intrusion detection. In a practical context, a GNN classifier may be trained on the previous 14 days’ worth of system data each day, a process which takes about 18 hours total to allow for accurate detection. However, these techniques do not allow for the timely detection of intrusions. Moreover, the prior art relies on subjective decisions and experiences with the time and resources to engage in computationally-expensive GNN training, which leads to wildly varying outcomes from instance to instance. Thus, prior art techniques did little if anything to address detection latency.

[0154] The embodiments herein overcome these limitations by utilizing streaming embedding and detection. In this manner, intrusion detection can be accomplished in a more accurate, timely and robust fashion. This results in several advantages. First, the detection latency between a GNN based IDS and ORCHIDS is reduced by a minimum factorMBHB Docket No.24-0156-WO of 10 million. Second, ORCHIDS can be deployed in real-world computing systems to quickly detect intrusions. Third, ORCHIDS does not regularly require hours of computationally- expensive training, as a GNN based IDS would.

[0155] Another technical problem in IDS design is high memory consumption. In practice, this is problematic because high memory consumption may take resources away from other components of a computing system, and may be very expensive for the owner of a computing system to account for.

[0156] In the prior art, the memory consumption of different IDS methods was very high. Previous approaches used versioned graphs or computationally-expensive GNNs to facilitate intrusion detection, both of which stored large amounts of redundant data in memory. Moreover, the prior art relies on subjective decisions and experiences of organizations and implementers with the time and resources to account for this high memory consumption. Thus, prior art techniques did little if anything to address high memory consumption.

[0157] The embodiments herein overcome these limitations by processing events in the graph in a streaming fashion and tracking embeddings for each system entity.Prior art methods consumed an amount of memory scaled to a factor of | | + | |. ORCHIDSonly consumes an amount of memory scaled to a factor of | | . This results in severaladvantages. First, ORCHIDS only consumes a maximum of 2.7 GB of memory when tested on a 270 GB dataset. Conversely, the prior art Versioned-GNN IDS used 143.7 GB of memory. Second, ORCHIDS is able to achieve this reduction in memory usage while maintaining the accuracy of GNN based IDS.

[0158] Other technical improvements may also flow from these embodiments, and other technical problems may be solved. Thus, this statement of technical improvements is not limiting and instead constitutes examples of advantages that can be realized from the embodiments. VI. Example Operations

[0159] Figure 14 is a flow chart illustrating an example embodiment. The process illustrated by Figure 14 may be carried out by a computing device, such as computing device 1200, and / or a cluster of computing devices, such as server cluster 1300. However, the process can be carried out by other types of devices or device subsystems. The embodiments of Figure 14 may be simplified by the removal of any one or more of the features shown therein. Further, these embodiments may be combined with features, aspects, and / or implementations of any of the previous figures or otherwise described herein.

[0160] Block 1402 may involve receiving, by way of a logging system, a systemMBHB Docket No.24-0156-WO call event representing a flow of data from a first system entity to a second system entity.

[0161] Block 1404 may involve generating a vector embedding for the second system entity based on the system call event and previous vector embeddings for the first system entity or the second system entity, wherein the vector embedding is generated using an autoregressive neural network, and wherein the autoregressive neural network was trained on previous log files representing system call events of system entities.

[0162] Block 1406 may involve comparing the vector embedding to a precomputed set of vector embeddings representing normal behavior of the system entities.

[0163] Block 1408 may involve, based on a distance between the vector embedding and the precomputed set of vector embeddings being greater than a threshold value, determining that the system call event includes anomalous behavior.

[0164] In some embodiments, the system call event involves creation or execution of a new process on a computing system, writing of the data to a file of the computing system, reading of the data from a file of a computing system, sending of the data from a process through a socket of the computing system, or receiving of data through a socket by a process of the computing system.

[0165] In some embodiments, the first system entity and the second system entity are each one of a file, a process, or a socket of a computing system.

[0166] In some embodiments, the autoregressive neural network does not maintain an explicit graph representation of its state model.

[0167] In some embodiments, comparing the vector embedding to the precomputed set of vector embeddings comprises: determining, from the precomputed set of vector embeddings, a closest vector embedding to the vector embedding; and determining the distance as between the vector embedding and the closest vector embedding.

[0168] In some embodiments, the precomputed set of vector embeddings were generated by applying the autoregressive neural network to the system call events of the previous log files.

[0169] Some embodiments may further involve, in response to determining that the system call event includes anomalous behavior, dynamically updating one or more firewall rules to block further activity by one or more of the first system entity or the second system entity, isolating one or more of the first system entity or the second system entity by way of network segmenting, or initiating an automatic shutdown of services associated with one or more of the first system entity or the second system entity.

[0170] Some embodiments may further involve, in response to determining thatMBHB Docket No.24-0156-WO the system call event includes anomalous behavior, notifying an incident response group about the system call event and the anomalous behavior.

[0171] In some embodiments, the autoregressive neural network models an underlying graph neural network representation of the system call events, wherein the system call events are respectively traceable to root cause nodes, wherein a first system call event for each of the root cause nodes is an outgoing flow of data, and wherein the vector embedding is further based on a root cause vector embedding of a root cause node relating to the system call event.

[0172] In some embodiments, the vector embedding is further based on the root cause vector embedding and a further vector embedding of at least one intermediate node on a path between the root cause node and a node representing the system call event.

[0173] Figure 15 is a flow chart illustrating an example embodiment. The process illustrated by Figure 15 may be carried out by a computing device, such as computing device 1200, and / or a cluster of computing devices, such as server cluster 1300. However, the process can be carried out by other types of devices or device subsystems. The embodiments of Figure 15 may be simplified by the removal of any one or more of the features shown therein. Further, these embodiments may be combined with features, aspects, and / or implementations of any of the previous figures or otherwise described herein.

[0174] Block 1502 may involve recording, by a logging system, system call events representing a flow of data from a first system entity to a second system entity.

[0175] Block 1504 may involve generating, based on the system call events, a provenance graph, wherein a plurality of nodes of the provenance graph respectively correspond to the system call events and a plurality of edges are vector representations of causal relationships between the system call events.

[0176] Block 1506 may involve generating, based on the provenance graph, a pseudo-graph, wherein the pseudo-graph connects a subset of nodes of the provenance graph to at least one node in the pseudo-graph representing a root cause of the events corresponding to the subset of nodes.

[0177] Block 1508 may involve training a machine learning model to represent behavior of a computing system based on the pseudo-graph.

[0178] Some embodiments may further involve detecting, by the machine learning model, a behavioral anomaly related to a computing system based on a comparison between further events involving the computing system and the behavior.

[0179] In some embodiments, the causal relationships are between pairs ofMBHB Docket No.24-0156-WO items including files stored on a computing system, processes executing on the computing system, and network sockets used by the computing system.

[0180] Figure 16 is a flow chart illustrating an example embodiment. The process illustrated by Figure 16 may be carried out by a computing device, such as computing device 1200, and / or a cluster of computing devices, such as server cluster 1300. However, the process can be carried out by other types of devices or device subsystems. The embodiments of Figure 16 may be simplified by the removal of any one or more of the features shown therein. Further, these embodiments may be combined with features, aspects, and / or implementations of any of the previous figures or otherwise described herein.

[0181] Block 1602 may involve obtaining events involving a computing system.

[0182] Block 1604 may involve applying a machine learning model to the events, wherein the machine learning model was trained to represent behavior of the computing system based on a pseudo-graph of nodes, wherein the pseudo-graph connects a subset of nodes of a provenance graph to at least one node in the pseudo-graph representing a root cause of previous events corresponding to the subset of nodes, wherein a plurality of nodes of the provenance graph correspond to the previous events within the computing system and a plurality of edges are vector representations of causal relationships between the previous events.

[0183] Block 1606 may involve detecting, by the machine learning model, a behavioral anomaly related to the computing system based on a comparison of the events involving the computing system to the behavior. VII. Closing

[0184] The present disclosure is not to be limited in terms of the particular embodiments described in this application, which are intended as illustrations of various aspects. Many modifications and variations can be made without departing from its scope, as will be apparent to those skilled in the art. Functionally equivalent methods and apparatuses within the scope of the disclosure, in addition to those described herein, will be apparent to those skilled in the art from the foregoing descriptions. Such modifications and variations are intended to fall within the scope of the appended claims.

[0185] The above detailed description describes various features and operations of the disclosed systems, devices, and methods with reference to the accompanying figures. The example embodiments described herein and in the figures are not meant to be limiting. Other embodiments can be utilized, and other changes can be made, without departing from the scope of the subject matter presented herein. It will be readily understood that the aspects of the present disclosure, as generally described herein, and illustrated in the figures, can beMBHB Docket No.24-0156-WO arranged, substituted, combined, separated, and designed in a wide variety of different configurations.

[0186] With respect to any or all of the message flow diagrams, scenarios, and flow charts in the figures and as discussed herein, each step, block, and / or communication can represent a processing of information and / or a transmission of information in accordance with example embodiments. Alternative embodiments are included within the scope of these example embodiments. In these alternative embodiments, for example, operations described as steps, blocks, transmissions, communications, requests, responses, and / or messages can be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved. Further, more or fewer blocks and / or operations can be used with any of the message flow diagrams, scenarios, and flow charts discussed herein, and these message flow diagrams, scenarios, and flow charts can be combined with one another, in part or in whole.

[0187] A step or block that represents a processing of information can correspond to circuitry that can be configured to perform the specific logical functions of a herein-described method or technique. Alternatively or additionally, a step or block that represents a processing of information can correspond to a module, a segment, or a portion of program code (including related data). The program code can include one or more instructions executable by a processor for implementing specific logical operations or actions in the method or technique. The program code and / or related data can be stored on any type of computer readable medium such as a storage device including RAM, a disk drive, a solid-state drive, or another storage medium.

[0188] The computer readable medium can also include non-transitory computer readable media such as non-transitory computer readable media that store data for short periods of time like register memory and processor cache. The non-transitory computer readable media can further include non-transitory computer readable media that store program code and / or data for longer periods of time. Thus, the non-transitory computer readable media may include secondary or persistent long-term storage, like ROM, optical or magnetic disks, solid-state drives, or compact disc read only memory (CD-ROM), for example. The non- transitory computer readable media can also be any other volatile or non-volatile storage systems. A non-transitory computer readable medium can be considered a computer readable storage medium, for example, or a tangible storage device.

[0189] Moreover, a step or block that represents one or more information transmissions can correspond to information transmissions between software and / or hardwareMBHB Docket No.24-0156-WO modules in the same physical device. However, other information transmissions can be between software modules and / or hardware modules in different physical devices.

[0190] The particular arrangements shown in the figures should not be viewed as limiting. It should be understood that other embodiments could include more or less of each element shown in a given figure. Further, some of the illustrated elements can be combined or omitted. Yet further, an example embodiment can include elements that are not illustrated in the figures.

[0191] While various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for purpose of illustration and are not intended to be limiting, with the true scope being indicated by the following claims.

Claims

MBHB Docket No.24-0156-WO CLAIMS What is claimed is:

1. A computer-implemented method comprising: receiving, by way of a logging system, a system call event representing a flow of data from a first system entity to a second system entity; generating a vector embedding for the second system entity based on the system call event and previous vector embeddings for the first system entity or the second system entity, wherein the vector embedding is generated using an autoregressive neural network, and wherein the autoregressive neural network was trained on previous log files representing system call events of system entities; comparing the vector embedding to a precomputed set of vector embeddings representing normal behavior of the system entities; and based on a distance between the vector embedding and the precomputed set of vector embeddings being greater than a threshold value, determining that the system call event includes anomalous behavior. The computer-implemented method of claim 1, wherein the system call event involves creation or execution of a new process on a computing system, writing of the data to a file of the computing system, reading of the data from a file of a computing system, sending of the data from a process through a socket of the computing system, or receiving of data through a socket by a process of the computing system.

3. The computer-implemented method of claim 1, wherein the first system entity and the second system entity are each one of a file, a process, or a socket of a computing system.

4. The computer-implemented method of claim 1, wherein the autoregressive neural network does not maintain an explicit graph representation of its state model.

5. The computer-implemented method of claim 1, wherein comparing the vector embedding to the precomputed set of vector embeddings comprises: determining, from the precomputed set of vector embeddings, a closest vector embedding to the vector embedding; andMBHB Docket No.24-0156-WO determining the distance as between the vector embedding and the closest vector embedding.

6. The computer-implemented method of claim 1, wherein the precomputed set of vector embeddings were generated by applying the autoregressive neural network to the system call events of the previous log files.

7. The computer-implemented method of claim 1, further comprising: in response to determining that the system call event includes anomalous behavior, dynamically updating one or more firewall rules to block further activity by one or more of the first system entity or the second system entity, isolating one or more of the first system entity or the second system entity by way of network segmenting, or initiating an automatic shutdown of services associated with one or more of the first system entity or the second system entity.

8. The computer-implemented method of claim 1, further comprising: in response to determining that the system call event includes anomalous behavior, notifying an incident response group about the system call event and the anomalous behavior.

9. The computer-implemented method of claim 1, wherein the autoregressive neural network models an underlying graph neural network representation of the system call events, wherein the system call events are respectively traceable to root cause nodes, wherein a first system call event for each of the root cause nodes is an outgoing flow of data, and wherein the vector embedding is further based on a root cause vector embedding of a root cause node relating to the system call event.

10. The computer-implemented method of claim 9, wherein the vector embedding is further based on the root cause vector embedding and a further vector embedding of at least one intermediate node on a path between the root cause node and a node representing the system call event.

11. A computer-implemented method comprising: recording, by a logging system, system call events representing a flow of data from a first system entity to a second system entity;MBHB Docket No.24-0156-WO generating, based on the system call events, a provenance graph, wherein a plurality of nodes of the provenance graph respectively correspond to the system call events and a plurality of edges are vector representations of causal relationships between the system call events; generating, based on the provenance graph, a pseudo-graph, wherein the pseudo-graph connects a subset of nodes of the provenance graph to at least one node in the pseudo-graph representing a root cause of the events corresponding to the subset of nodes; and training a machine learning model to represent behavior of a computing system based on the pseudo-graph.

12. The computer-implemented method of claim 11, further comprising: detecting, by the machine learning model, a behavioral anomaly related to a computing system based on a comparison between further events involving the computing system and the behavior.

13. The computer-implemented method of claim 11, wherein the causal relationships are between pairs of items including files stored on a computing system, processes executing on the computing system, and network sockets used by the computing system.

14. A computer-implemented method comprising: obtaining events involving a computing system; applying a machine learning model to the events, wherein the machine learning model was trained to represent behavior of the computing system based on a pseudo-graph of nodes, wherein the pseudo-graph connects a subset of nodes of a provenance graph to at least one node in the pseudo-graph representing a root cause of previous events corresponding to the subset of nodes, wherein a plurality of nodes of the provenance graph correspond to the previous events within the computing system and a plurality of edges are vector representations of causal relationships between the previous events; and detecting, by the machine learning model, a behavioral anomaly related to the computing system based on a comparison of the events involving the computing system to the behavior.

15. A system comprising: one or more processors; andMBHB Docket No.24-0156-WO memory, containing program instructions that, upon execution by the one or more processors, cause the system to perform operations of any of claims 1-14.

16. A non-transitory computer-readable medium, having stored thereon program instructions that, upon execution by a system, cause the system to perform operations of any of claims 1-14.

Images