Fuzzy network detection pattern matching

Abstract

A mechanism is provided for identifying patterns of computing resource activity of interest in activity data characterizing activity of a computer system element. A temporal graph of the activity data is generated, and a filter is applied to the temporal graph to generate one or more first vector representations, each vector representation characterizing nodes and edges within a moving window defined by the filter. The filter is applied to a pattern graph representing patterns of entities and events, the pattern graph indicating patterns of interest, to generate a second vector representation. The second vector representation is compared to the one or more first vector representations to identify one or more nearby vectors, and one or more corresponding subgraph instances are output as inexact matches of the temporal graph to an intelligence console computing system.

Description

Technical Field

[0001] The present invention generally relates to an improved data processing apparatus and method, and more particularly to a mechanism for fuzzy network detection pattern matching. Background Art

[0002] Emerging cyber attacks, such as advanced persistent threats (APTs), have become increasingly stealthy and complex, often involving the interoperation of multiple processes. To achieve their attack goals, such comprehensive attack campaigns often consist of long attack paths / vectors that exploit multiple processes on a single host or across multiple hosts. As such, understanding inter-process behavior is important for identifying attacks and reducing false alarms.

[0003] Attack / intrusion detection products, systems, and services are well known. Most host-based and network-based attack / intrusion detection products utilize static signature matching methods. For example, antivirus products, firewalls, intrusion detection systems (IDS), etc. rely on specific binary or network communication signatures to identify attacks. With these products, the detection process includes: (i) attack discovery, (ii) signature selection, (iii) signature distribution, and (iv) endpoint signature matching.

[0004] In-process behavior modeling and detection is also well known, as demonstrated by the program anomaly detection literature as well as most state-of-the-art commercial endpoint intrusion detection products. These mechanisms essentially monitor system events, such as system calls and / or Windows APIs for each process, and then decide whether the process is malicious based on its behavior model. This type of solution may be ineffective when stealing attacks are implemented across processes, or when an attacker exploits a benign process to achieve an attack goal. Although the above methods provide advantages, they generally fail to detect new or rapidly updated attacks in a timely manner, or provide sufficient attack surface coverage relative to attacks that exploit inter-process activity.

[0005] Some behavior-based endpoint detection products attempt to address these deficiencies by attempting to model direct inter-process activities, such as process spawning and malware downloading. While this type of inter-process activity modeling is useful, known solutions are based on ad hoc operations, and due to practical constraints in existing products, only a small amount of direct inter-process activities are modeled. Furthermore, these approaches do not address indirect inter-process activities. Thus, even in cases where some inter-process activity modeling is available, attackers can evade detection, for example, by constructing a theft attack with multiple processes and files in a large time window.

[0006] An example of this attack is the recent Stored data breaches, where breached data from a point-of-sale machine is encrypted to disk but read later during business hours by another process for aggregation. In this case, the indirect inter-process activity (between the processes that write and read the encrypted file) is not explicit and therefore not identified and mitigated. That is, existing work on network event reasoning focuses on either exact matching of signatures or on regular expression-based string matching. Summary of the invention

[0007] This Summary is provided to introduce a selection of concepts in a simplified form that are further described in the Detailed Description. This Summary is not intended to identify key factors or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0008] In one illustrative embodiment, a method is provided in a data processing system for identifying patterns of computing resource activity of interest in activity data representing the activity of computer system elements. The method includes receiving, by the data processing system, activity data representing the activity of computer system elements from one or more computing devices of a monitored computing environment, and generating, by the data processing system, a temporal graph of the activity data. The temporal graph includes nodes representing computer system elements and edges connecting the nodes, wherein each edge represents an event occurring between the computer system elements represented by the nodes connected by the edge.

[0009] The method also includes applying a filter to the time graph by a data processing system to generate one or more first vector representations, each vector representation characterizing nodes and edges within a moving window defined by the filter. The method also includes applying the filter to a pattern graph by the data processing system, the pattern graph representing patterns of entities and events between entities, the pattern graph indicating patterns of computing resource activities to be identified in the time graph. The application of the filter to the pattern graph creates a second vector representation. In addition, the method includes comparing the second vector representation with the one or more first vector representations by the data processing system to identify one or more nearby vectors in the one or more first vector representations, and outputting one or more subgraph instances corresponding to the identified one or more nearby vectors to the intelligence console computing system as an inexact match of the time graph by the data processing system.

[0010] In other illustrative embodiments, a computer program product is provided that includes a computer usable or readable medium having a computer readable program that, when executed on a computing device, causes the computing device to perform different operations and combinations of the operations outlined above with respect to the method illustrative embodiment.

[0011] In yet another illustrative embodiment, a system / apparatus is provided. The system / apparatus may include one or more processors and a memory coupled to the one or more processors. The memory may include instructions that, when executed by the one or more processors, cause the one or more processors to perform different operations and combinations of the operations outlined above with respect to the method illustrative embodiment.

[0012] These and other features and advantages of the present invention will be described in, or will become apparent to one of ordinary skill in the art in view of, the following detailed description of example embodiments of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The invention, together with the preferred mode of use, and further objects and advantages thereof, will be best understood by reference to the following detailed description of illustrative embodiments when read in conjunction with the accompanying drawings, in which:

[0014] Figure 1 depicts an exemplary block diagram of a distributed data processing environment in which exemplary aspects of the illustrative embodiments may be implemented;

[0015] Figure 2 is an exemplary block diagram of a data processing system in which exemplary aspects of the illustrative embodiments may be implemented;

[0016] Figure 3 A security intelligence platform is shown in which techniques of one or more illustrative embodiments may be practiced;

[0017] Figure 4 An advanced persistent threat (APT) platform is depicted in which techniques of one or more illustrative embodiments may be practiced;

[0018] Figure 5 An operating environment is shown in which a cognitive network security intelligence center is used to manage endpoints and in which the techniques of one or more illustrative embodiments may be implemented;

[0019] Figure 6 Depicting a representative malicious behavior graph image and several inter-process activity graphs abstractly matching the graph according to an illustrative embodiment;

[0020] Figure 7 depicts a representative inter-process graph constructed by monitoring activities between entities in an endpoint and how an endpoint protection system performs different matching techniques against the graph in accordance with one or more illustrative embodiments;

[0021] Figure 8 An implementation of an endpoint inter-process activity extraction and pattern matching system according to an illustrative embodiment is depicted;

[0022] Fig. 9 depicts how labeled subgraph matching is implemented in one illustrative embodiment;

[0023] Fig.10 The ingest functionality is depicted in greater detail according to one illustrative embodiment;

[0024] Fig.11 depicts how to use an aging function to evolve an activity graph according to one illustrative embodiment;

[0025] Fig.12 The aging function is depicted in more detail according to one illustrative embodiment;

[0026] Fig.13 depicts how an instrumentation system according to one illustrative embodiment provides indirect inter-process activity modeling for transient and persistent inter-process activities using on-disk storage;

[0027] Fig.14 depicts additional details regarding matching functionality and mitigation and resilience functionality according to one illustrative embodiment;

[0028] Fig.15 depicts a representative activity diagram of host-level activities according to one illustrative embodiment;

[0029] Fig.16 depicts a representative activity diagram of network-level activities according to one illustrative embodiment;

[0030] Fig.17 depicts a representative activity diagram of process-level activities according to one illustrative embodiment;

[0031] Fig.18 depicts an iterative constraint solving algorithm as a process flow according to one illustrative embodiment;

[0032] Fig.19 depicts a representative example of a representative pattern graph and a corresponding graph of constraints (GoC) derived therefrom according to an illustrative embodiment;

[0033] Figure 20-23 Describes about Fig.19 An illustrative embodiment of a schematic diagram of an iterative constraint solving process or algorithm for application;

[0034] Fig.24 depicts a representative graph computing platform in which techniques of one or more illustrative embodiments may be implemented;

[0035] Fig.25 An example of a pattern for defining a pattern representing an intrusion, attack, or threat and two fuzzy matched subgraphs are shown according to an illustrative embodiment;

[0036] Fig.26 is an example diagram showing a dynamically growing time graph according to one illustrative embodiment;

[0037] Fig. 27 is an example diagram schematically depicting a process for extracting information from a sub-graph (e.g., AG / CG) of a temporal graph using a moving convolutional filter;

[0038] Fig.28 is an example flow chart outlining an example generalized operation for performing fuzzy matching according to an example embodiment;

[0039] Fig.29 is a flowchart outlining an example fuzzy matching operation according to one illustrative embodiment, wherein a plurality of graph neural networks (GNNs) are implemented to perform embedding; and

[0040] Fig.30 An example system design and process flow for performing fuzzy network detection pattern matching is shown in accordance with one illustrative embodiment. DETAILED DESCRIPTION

[0041] The exemplary embodiments provide mechanisms for implementing fuzzy network detection pattern matching. As described above, known methods of attack / threat detection have various disadvantages. In addition to the above disadvantages, it should be noted that these known methods do not deal with abstract graph patterns, which are categories of high-level behavioral descriptions of malicious / interesting behavior. That is, the monitored computing activities of a computing device can be represented as a time graph, and the mechanisms of the illustrative embodiments can use this time graph as a basis for performing fuzzy pattern matching to detect network attacks. For example, a time graph can indicate, for example, time instances along an axis, specific computing components and their interactions that occur at that time instance.

[0042] Abstract graph pattern matching can be used for behavior-based threat detection and network hunting. That is, in the case of abstract graph pattern matching, given an abstract pattern (such as a process that creates a thread into another process), for example, a graph pattern matching algorithm can be used to search the time graph for matching activities against the monitored host. The matching activities can then be returned for further inspection, such as by a security analyst or threat hunter. In addition, high-level abstract patterns such as "a specific file flow to any network socket in n steps" can be evaluated and used to detect data leakage (exfilitration).

[0043] More generally, an abstract graph pattern can be thought of as elements with constraints (or predicate expressions) and connections between them. Pattern matching requires satisfying all constraints for all elements and how they are connected. This task is computationally trivial because patterns can reference other patterns via parameters and because graphs are typically stored on distributed external memory, making it expensive to check the data associated with each predicate.

[0044] In some illustrative embodiments described herein, abstract graph pattern matching involves exact subgraph matching. That is, given a computational graph (CG) or a temporal graph of computer states at different levels of execution (see below), Figure 15-17 ), such as the example in the abstract graph pattern matching described below, will attempt to accurately match the pattern graph (PG) for the attack or threat with a portion or subgraph in the CG. In this way, potential network attacks or threats can be identified based on abstract graph pattern matching. However, some network attacks or threats can be designed in which accurate pattern matching will not necessarily identify instances of such attacks or threats, for example, there is not enough information about the network attack / threat to generate a PG for the network attack / threat. For this case, the mechanism of the illustrative embodiment described below also provides a fuzzy or imprecise pattern matching computer mechanism that is able to utilize neural networks and machine learning to learn patterns for network attacks / threats and use them to identify potential attacks / threats present in a temporal graph of computing system activity (such as the computational graph (CG) mentioned previously).

[0045] Referring now to the drawings and in particular to Figure 1-Figure 2 , provides an exemplary diagram of a data processing environment in which an illustrative embodiment of the present invention may be implemented. It should be understood that Figure 1-Figure 2 They are merely exemplary, and they are not intended to assert or imply any limitations with respect to the environments in which aspects or embodiments of the disclosed subject matter may be implemented. Many modifications to the depicted environments may be made without departing from the scope of the invention.

[0046] Now referring to the accompanying drawings, Figure 1An exemplary distributed data processing system is depicted. Distributed data processing system 100 may include a computer network in which aspects of the illustrative embodiments may be implemented. Distributed data processing system 100 includes at least one network 102, which is a medium for providing communication links between different devices and computers connected together within distributed data processing system 100. Network 102 may include connections such as wired, wireless communication links, or fiber optic cables. In the depicted example, server 104 and server 106 are connected to network 102 along with storage unit 108. In addition, clients 110, 112, and 114 are also connected to network 102. These clients 110, 112, and 114 may be, for example, personal computers, network computers, etc. In the depicted example, server 104 provides data such as boot files, operating system images, and applications to clients 110, 112, and 114. In the depicted example, clients 110, 112, and 114 are clients of server 104. Distributed data processing system 100 may include additional servers, clients, and other devices not shown.

[0047] In the depicted example, distributed data processing system 100 is the Internet with network 102 representing a global collection of networks and gateways that use the Transmission Control Protocol / Internet Protocol (TCP / IP) suite of protocols to communicate with each other. At its core, the Internet is a backbone of high-speed data communications lines between major nodes or host computers, consisting of thousands of commercial, government, educational, and other computer systems that route data and messages. Of course, distributed data processing system 100 may also be implemented to include multiple different types of networks, such as, for example, an intranet, a local area network (LAN), a wide area network (WAN), etc. As described above, Figure 1 It is intended as an example and not as an architectural limitation to the various embodiments of the disclosed subject matter, and thus, Figure 1 The specific elements shown should not be construed as limiting the environments in which illustrative embodiments of the invention may be implemented.

[0048] See now Figure 2 , shows a block diagram of a data processing system that can implement the illustrative embodiments. Data processing system 200 is a computer (such as Figure 1104 or client 110 in the example of a computer, in which there may be computer-usable program code or instructions for the implementation process of the illustrative implementation. In this illustrative example, data processing system 200 includes communication structure 202, which provides communication between processor unit 204, memory 206, permanent storage device 208, communication unit 210, input / output (I / O) unit 212 and display 214. Processor unit 204 is used to execute instructions of software that can be loaded into memory 206. Processor unit 204 can be a collection of one or more processors, or can be a multi-processor core, depending on the specific implementation. Further, processor unit 204 can be implemented using one or more heterogeneous processor systems, in which the main processor and the secondary processor are present on a single chip. As another illustrative example, processor unit 204 can be a symmetric multiprocessor (SMP) system containing multiple processors of the same type. Memory 206 and permanent storage device 208 are examples of storage devices. A storage device is any hardware that can store information temporarily and / or permanently. Memory 206 , in these examples, may be, for example, a random access memory or any other suitable volatile or non-volatile storage device.

[0049] Permanent storage 208 can take various forms, depending on the particular implementation. For example, permanent storage 208 can include one or more components or devices. For example, permanent storage 208 can be a hard drive, a flash memory, a rewritable optical disk, a rewritable tape, or some combination of the above. The media used by permanent storage 208 can also be removable. For example, a removable hard drive can be used for permanent storage 208. In these examples, communication unit 210 provides communication with other data processing systems or devices. In these examples, communication unit 210 is a network interface card. Communication unit 210 can provide communication by using either or both of physical and wireless communication links.

[0050] Input / output unit 212 allows for input and output of data with other devices that may be connected to data processing system 200. For example, input / output unit 212 may provide a connection for user input through a keyboard and mouse. In addition, input / output unit 212 may send output to a printer. Display 214 provides a mechanism for displaying information to a user.

[0051] Instructions for the operating system and applications or programs are located on permanent storage 208. These instructions can be loaded into memory 206 for execution by processor unit 204. Processor unit 204 can use computer-implemented instructions to perform the processes of different embodiments, which can be located in memory (e.g., memory 206). These instructions are referred to as program code, computer-usable program code, or computer-readable program code that can be read and executed by a processor in processor unit 204. The program code in different embodiments can be implemented on different physical or tangible computer-readable media, such as memory 206 or permanent storage 208. Program code 216 is located on selectively removable computer-readable media 218 in a functional form and can be loaded or transferred to data processing system 200 for execution by processor unit 204. In these examples, program code 216 and computer-readable media 218 form computer program product 220. In one example, computer readable media 218 may be in a tangible form, such as an optical or magnetic disk inserted or placed in a drive or other device as part of permanent storage 208 for transfer to a storage device, such as a hard drive as part of permanent storage 208. In a tangible form, computer readable media 218 may also take the form of a permanent storage device, such as a hard drive, thumb drive, or flash memory connected to data processing system 200. Tangible forms of computer readable media 218 are also referred to as computer recordable storage media. In some instances, computer recordable media 218 may not be removable.

[0052] Alternatively, program code 216 may be transferred from computer readable medium 218 to data processing system 200 via a communication link to communication unit 210 and / or via a connection to input / output unit 212. In the illustrative examples, the communication link and / or connection may be physical or wireless. Computer readable media may also take the form of non-tangible media, such as a communication link or wireless transmission containing program code. The different components shown for data processing system 200 are not meant to provide architectural limitations on the manner in which different embodiments may be implemented. Different illustrative embodiments may be implemented in a data processing system that includes components in addition to or in lieu of those components shown for data processing system 200. Figure 2Other components shown in the data processing system 200 may be different from the illustrative examples shown. As an example, a storage device in data processing system 200 is any hardware device that can store data. Memory 206, permanent storage device 208, and computer readable medium 218 are examples of storage devices in tangible form. In another example, a bus system can be used to implement communication structure 202 and may include one or more buses, such as a system bus or an input / output bus. Of course, the bus system can be implemented using any suitable type of architecture that provides data transfer between different components or devices attached to the bus system.

[0053] Additionally, the communication unit may include one or more devices for sending and receiving data, such as a modem or a network adapter. Additionally, a memory may be, for example, memory 206 or a cache such as found in an interface and memory controller hub that may be present in communication fabric 202. Computer program code for carrying out operations of the present invention may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java. TM , Smalltalk, C++, etc., and also include conventional procedural programming languages, such as "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer and partially on the remote computer, or entirely on the remote computer or server. In the latter case, the remote computer can be connected to the user's computer through any type of network (including a local area network (LAN) or a wide area network (WAN)), or can be connected to an external computer (for example, using an Internet service provider through the Internet).

[0054] One of ordinary skill in the art will recognize that Figure 1-Figure 2 The hardware in may vary depending on the implementation. Figure 1-Figure 2 In addition to or in place of the hardware depicted Figure 1-Figure 2 , other internal hardware or peripheral devices may be used, such as flash memory, equivalent non-volatile memory, or optical disk drives, etc. In addition, the processes of the illustrative embodiments may be applied to multiprocessor data processing systems other than the aforementioned SMP systems without departing from the scope of the disclosed subject matter. As will be seen, the techniques described herein may be applied in systems such as Figure 1 The illustrated embodiments operate in concert within a standard client-server paradigm, wherein a client communicates with an Internet-accessible web-based portal executed on a collection of one or more machines. An end user operates an Internet-connectable device (e.g., a desktop computer, a laptop computer, an Internet-enabled mobile device, etc.) capable of accessing and interacting with the portal.

[0055] Typically, each client or server machine is such as Figure 2 The data processing system shown includes hardware and software, and these entities communicate with each other through a network (such as the Internet, an intranet, an extranet, a dedicated network, or any other communication medium or link). The data processing system typically includes one or more processors, an operating system, one or more applications, and one or more utilities. The application on the data processing system provides local support for Web services, including but not limited to support for HTTP, SOAP, XML, WSDL, UDDI, and WSFL. Information about SOAP, WSDL, UDDI, and WSFL can be obtained from the World Wide Web Consortium (W3C), which is responsible for developing and maintaining these standards; further information about HTTP and XML can be obtained from the Internet Engineering Task Force (IETF). Familiarity with these standards is assumed.

[0056] Safety intelligence platform with accident forensics

[0057] Figure 3 A representative security intelligence platform in which the techniques of one or more illustrative embodiments may be practiced is shown. In general, the platform provides search-driven data exploration, session reconstruction, and forensic intelligence to aid in security incident investigations. In relevant part, platform 300 includes a set of packet capture devices 302, incident forensics module devices 304, a distributed database 306, and a security intelligence console 308. Packet capture devices 302 and incident forensics module devices 304 are configured as network devices, but may also be configured as virtual devices. Packet capture device 302 is used to obtain information from a network (e.g., a packet capture device) using a known or later developed packet capture (pcap) application programming interface (API) or other known / later developed technology. Figure 1 The packet capture device 302 also provides such data (e.g., real-time log events and network flows) to a distributed database 306 where the data is stored and made available for analysis by the forensics module 304 and the security intelligence console 308. The packet capture device 302 operates in a session-oriented manner, capturing all packets in a flow, and indexing metadata and payloads to enable rapid search-driven data exploration.

[0058] The database 306 provides a forensic repository with distributed and heterogeneous data sets including information collected by the packet capture device 302. The console 308 provides a web or cloud accessible user interface (UI) that displays a "forensic identification" dashboard tab to facilitate the investigator's incident investigation workflow. Using the dashboard, the investigator selects a security incident. The incident forensics module 304 retrieves all packets (including metadata, payload, etc.) of the selected security incident and reconstructs the session for analysis.

[0059] Representative commercial products that implement this type of incident investigation workflow are Security Incident Forensics V7.2.3 (or higher). Using the platform, investigators search across distributed and heterogeneous data sets stored in databases and receive a unified list of search results. Search results can be merged in a grid, and they can be visualized in a "digital impression" tool, allowing users to explore relationships between identities.

[0060] Typically, the devices used in the above-mentioned systems are implemented as network-connected non-display devices. For example, devices that are purposely built to perform traditional middleware service-oriented architecture (SOA) functions are common in certain computer environments. SOA middleware devices can simplify, help secure or accelerate XML and Web service deployments while extending existing SOA infrastructure across enterprises. The use of hardware and lightweight middleware stacks for middleware purposes can solve the performance burden experienced by traditional software solutions. In addition, the device form factor provides a secure, consumable package for implementing middleware SOA functions. A specific advantage provided by these types of devices is to offload processing from back-end systems. This type of network device is typically a rack-mounted device. The device includes physical security that enables the device to be used as a safe for sensitive information. Typically, the device is manufactured, preloaded with software, and then deployed within or associated with an enterprise or other network operating environment; alternatively, the box can be located locally and then equipped with standard or customized middleware virtual images that can be securely deployed and managed, for example, within a private or on-site cloud computing environment. The device may include hardware and firmware encryption support that may be used to encrypt data on the hard disk.

[0061] This type of device can facilitate Security Information Event Management (SIEM). For example, Security SIEM is an enterprise solution that includes a packet data capture device that can be configured as this type of device. Such a device is used, for example, to capture real-time layer 4 network flow data, and then layer 7 application payloads can be analyzed from the real-time layer 4 network flow data, for example, using deep packet inspection and other techniques. Security SIEM uses a combination of flow-based network knowledge, security event correlation, and asset-based vulnerability assessment to provide situational awareness and compliance support. Security In SIEM installation, such as Figure 4 The system shown is configured to collect event and flow data and generate reports. A user (e.g., a SOC analyst) can then investigate the violation to determine the root cause of the network problem.

[0062] In summary, security information and event management (SIEM) tools provide a series of services for analyzing, managing, monitoring and reporting IT security events and vulnerabilities. Such services typically include collecting monitored access and unexpected events across data networks, and analyzing them in relevant contexts to determine their contribution to the higher-order security events analyzed. SIEM tools may also include analysis of firewall configurations, network topology and connection visualization tools for viewing current and potential network traffic patterns, correlation of asset weaknesses with network configurations and traffic to identify active attack paths and high-risk assets, and support for monitoring network traffic, topology and vulnerability exposure policy compliance. Some SIEM tools have the ability to build topologies of managed network devices such as routers, firewalls and switches based on conversion analysis of device configurations processed by a public network information model. The result is a location organization that can be used for simulation of security threats, operational analysis of firewall filters, and other applications. However, the main device criteria are completely based on networks and network configurations. While there are many ways to enable discovery capabilities for managed assets / systems, and while inclusion in the user interface is semi-automatic management (i.e., an approach through the user interface that allows semi-automatic, human input-based topology layout and its display and formatting, data-driven based on initial configuration and discovery of changes / deletions in the underlying network), nothing is provided in terms of generating fully automated placement analysis and recommended placement analysis.

[0063] Advanced Persistent Threat (APT) Prevention

[0064] APT mitigation and prevention techniques are well known. For example, Trusteer An automated solution that prevents exploits and malware from compromising enterprise endpoints and extracting information. This type of solution typically provides several layers of security, namely, vulnerability prevention, data leakage prevention, and credential protection.

[0065] Figure 4A typical embodiment is depicted, in which the APT solution is typically architected as an agent code 400 executed in an enterprise endpoint 402, and a web-based console 404 that enables IT security to manage deployment (both managed and unmanaged endpoints) from a central control location. The agent code 400 operates by monitoring the application state when the application 406 performs sensitive operations (e.g., writing a file to the file system). Typically, the agent 400 uses a whitelist of legitimate application states to verify that sensitive operations are performed (or not performed) in a known, legitimate state. An exploit will attempt to perform sensitive operations in an unknown (not whitelisted) state, so it will be stopped. This method enables the APT agent to accurately detect and block both known and zero-day vulnerabilities without knowing anything about the threat or the exploited weakness. An "agent" can be any code-based module, program, process, component, thread, etc.

[0066] Figure 4 Depicts how an APT attack typically unfolds and the point at which an APT solution can operate to stop the intrusion. For example, here, an attacker 408 uses a spear phishing email 410 to send a user a weaponized document, i.e., an exploit code containing hidden exploit code 412. When the user exploits a viewer such as or When the document is opened in Word (Microsoft Office 2003), the exploit code runs and attaches to the application vulnerability to silently download malware on the employee's computer 402. The user is unaware of the download. Another option is to send the user to a link 414 to a malicious website 416, which contains the exploit code or a legitimate website that has been compromised (for example, through a watering hole attack). When the user clicks the link and the browser renders the HTML content, the exploit code runs and locks onto the browser (or browser plug-in) vulnerability to silently download malware on the user's computer. The link can also lead the user to a phishing site (such as a fake web app login page) 418 to convince the user to submit company credentials. After infecting the computer 402 with advanced malware or compromising the company's credentials, the attacker 408 has established a foothold in the company network and can then push the attack.

[0067] As depicted, agent 400 protects the enterprise from such threats at several intersections: (1) vulnerability prevention 420, which prevents exploits from attempting to compromise user computers; (2) leak prevention 422, which prevents malware from communicating with attackers and sending information if the machine has been infected with malware; and (3) credential protection 424, which prevents users from using corporate credentials on unapproved corporate sites (including, for example, phishing or public sites such as social networks or e-commerce). In one known approach, agent 400 performs these and related operations by monitoring applications and their operations using a whitelist of legitimate application states.

[0068] Information stealing malware can be installed directly on the endpoint by the user without the need for a vulnerability. In order to exfiltrate data, malware must usually communicate with the Internet directly or through a compromised application. Advanced malware uses several evasion techniques to bypass detection. For example, information stealing malware can compromise another legitimate application and may be able to gain access to legitimate websites (like Forums and Docs) to communicate with the attacker. Agent 400 is also operable to stop the execution of untrusted code that exhibits a data exit state. To this end, preferably, agent 400 verifies that only trusted programs are allowed to communicate with external networks using data leakage techniques. Agent 400 preferably uses several techniques to identify unauthorized leakage states and malicious communication channels and block them. Because agent 400 monitors activity on the host itself, it has good visibility and can accurately detect and block these leakage states.

[0069] References herein to identified commercial products are not intended to be limiting, as the methods herein may be implemented with any APT solution or functionality (even if embedded in other systems).

[0070] Endpoint inter-process activity extraction and pattern matching

[0071] Considering the above, Figure 5 A basic operating environment is depicted including a cognitive cybersecurity intelligence center 500 and an endpoint 502. An endpoint 502 is a networked data processing system or device, such as Figure 2 The data processing system shown in FIG. 1 runs a system management code (software) that implements the management and monitoring of endpoints by the intelligence center 500. The intelligence center 500 can be implemented as a security management platform (such as Figure 3 ), and APT solutions such as Figure 4 Thus, for example, known commercial products and systems that provide endpoint management include It provides remote control, patch management, software distribution, operating system deployment, network access protection, and hardware and software inventory functionality for system administrators. This type of commercial system can be expanded to include the endpoint inter-process activity extraction and pattern matching technology described in one or more of the illustrative embodiments herein, including the fuzzy network detection pattern matching mechanism described below, or such technology can be implemented in a product or system dedicated to this purpose.

[0072] In some demonstrative embodiments, endpoint 502 is a device that connects a Mac OS Vmware Operating systems such as Windows Apple and The cognitive cybersecurity intelligence center 500 operates as a network-accessible security management platform that includes multiple machines and application software. The cognitive cybersecurity intelligence center 500 supports cybersecurity analysis using, for example, machine learning. The cognitive cybersecurity intelligence center 500 can operate in a dedicated manner to support multiple endpoints or "as a service" on behalf of multiple enterprises, each with its own endpoint 502. Typically, the endpoint machines communicate with the intelligence center in a client-server paradigm, such as Figure 1 The intelligence center may be located in and accessed in a cloud-based operating environment.

[0073] As will be described, according to one or more illustrative embodiments, inter-process events are sent from an endpoint (such as endpoint 502) to a detection server executing cognitive cybersecurity intelligence center 500, where such events are analyzed. Attack or threat detection occurs in the detection server. As will be seen, the method according to one or more illustrative embodiments as described herein provides an efficient, systematic (as opposed to merely ad hoc) mechanism to record endpoint activity via inter-process events, to describe malicious or suspicious behavior of interest (network graph) with abstractions, and to match specific activities (as represented in the recorded events) with abstract patterns. In addition, according to some illustrative embodiments, the method according to some illustrative embodiments may include fuzzy network detection pattern matching functionality. The pattern matching of the illustrative embodiments enables cognitive cybersecurity intelligence center 500 to take action on malicious / suspicious behavior (e.g., by stopping the process involved, alerting, abandoning ongoing network sessions, stopping ongoing disk operations, etc.), as well as helping security analysts locate activities of interest (e.g., threat hunting) or determine the next step that can be implemented in a workflow to resolve suspicious or malicious activities.

[0074] According to a technique herein, both direct inter-process activities and indirect inter-process activities are extracted at an endpoint and compared to predefined malicious behavior patterns for detection. Direct inter-process activities and indirect inter-process activities may include control flow (such as process derivation) and information exchange via channels (such as files, sockets, messages, shared memory, etc.). Inter-process activities reveal the target of a process and its specific execution path. In a method herein, inter-process activities are matched with malicious inter-process behaviors for detecting attack instances. In some illustrative embodiments, malicious behavior patterns are predefined with abstractions to characterize key steps in a network attack. These malicious behavior patterns may be stored in an endpoint and may be updated as needed.

[0075] Figure 6 Depicted is how graphs can be used to facilitate behavior-based detection / reasoning, according to the techniques of one or more illustrative embodiments described herein. In this approach, an individual (e.g., a software developer, security analyst, etc.) describes malicious or interesting behavior in an abstract graph pattern 600 (also referred to as a pattern graph (PG)). In the depicted example of malicious behavior, a DLL injection attack is modeled by a process 602 executing an event (type:: create thread) 604, which then derives another process 606. In summary, the graph pattern 600 includes nodes (in this example, processes 602 and 606) and edges (in this example, events 604 linking these two nodes). In operation, a pattern matching algorithm can then return specific activities on a host endpoint that match the patterns defined in the graph pattern 600 (or PG). Specific activities on the endpoint are also modeled by graphs to facilitate pattern matching. Depicted are two such example activity graphs 608 and 610 derived from endpoint inter-process activities and matched to the abstract graph behavior 600. In the first example activity diagram 608, the process rundll.exe executes the event Syscall 10 to derive the process Isasss.exe; in the second example activity diagram 610, the process Firefox.exe executes the event Syscall 11 to derive the process explorer.exe. This is an example of topology matching.

[0076] Figure 7A more complex example is depicted, where a graph 700 is generated as a result of inter-process activity monitoring. As depicted in legend 702, the graph typically includes a set of entities, namely processes 704, files 706, network resources 708, and events 710. Preferably, each entity in the endpoint system is associated with a label (or "tag") that describes its category and properties, for example, an installation of Firefox (a process entity) is a "browser", an installation of Firefox is "64-bit", and so on. Labels can be assigned manually, such as "browser" is automatically generated if the label is a 64-bit executable, or calculated via a function, such as "trusted" is assigned if the process meets certain requirements. Labels can replace entity names to create behavioral patterns for a class of processes. Figure 7 The diagram 700 in depicts and includes a set of entities, each of which may have an associated label (tag) defined in an offline manner. Inter-process activity is monitored on an endpoint, where the activity between entities is recorded, for example, via system call monitoring, kernel hooks, system monitoring services, etc. In some illustrative embodiments, a relatively constrained set of system calls or events need to be monitored to obtain the information needed to construct the graph. An example (given Linux as the operating system) would be system calls that associate one entity with another entity, such as sys_open and stub_execve. A graph can be constructed (and updated if necessary) by connecting entities and monitored activities, an example of which is diagram 700. In some illustrative embodiments, the graph is stored on disk and cached in memory.

[0077] In general, an activity diagram represents a real-time abstraction of inter-process activities occurring at an endpoint. Figure 7 As shown, the extraction then uses one or more matching techniques to facilitate behavioral matching (which may occur in a detection server executing in an intelligence center). These matching techniques may include one or more matching techniques such as topology matching 712, label matching 714, and optional specific signature matching 716. As described above, the inter-process activities (and their associated tags) shown in the figure reveal the goals of one or more processes and their specific execution paths. Matching the generated (one or more) graphs with malicious inter-process behaviors (also defined in the form of graphs) enables the system to detect and address attack instances. As noted, malicious behavior patterns are predefined with a certain degree of abstraction to characterize key steps in a network attack.

[0078] More formally, and as used herein, an abstract pattern graph (such as Figure 6600 in the diagram) is sometimes referred to herein as a pattern graph (PG). The PG may include one or more constraints, where the constraints may be, for example, Boolean functions on elements of the graph or relationships of elements. In some illustrative embodiments, there are two types of constraints, namely, single element constraints (e.g., properties / classes / concepts of vertices / edges in the pattern graph (PG)) and one or more element relationship constraints (i.e., how one element is related to another element, e.g., directly connected, later than, "n" steps, etc.). The monitored activities of the hosts (endpoints) are instantiated in a graph (sometimes referred to herein as an activity graph (AG) or a computation graph (CG)). In Figure 6 , diagrams 608 and 610 represent AG or CG. As will be described, the goal of pattern matching is to search for all subgraphs of AG that satisfy PG. As further described herein, assuming that it is practical to query the database to verify a single element constraint or an element relationship constraint, the remaining task is to provide a multi-constraint graph solution, that is, how to coordinate database query generation to efficiently satisfy all constraints. The technology associated with the illustrative embodiments solves this problem, as described herein.

[0079] Figure 8 A representative embodiment of a detection system is depicted in which the endpoint inter-process activity extraction and pattern matching techniques of one illustrative embodiment are implemented. As depicted, certain functionality is located in the intelligence center 800 (e.g., a security management platform, an APT solution, an endpoint management solution, etc.), while certain functionality is located in the endpoint 802. This arrangement of functionality is presented for one illustrative embodiment, but is not intended to limit possible implementations of embodiments of the invention. As described above, the intelligence center 800 can be dedicated to a network of endpoints (e.g., located within an enterprise), or it can operate as a service provider (or, more generally, a "service") on behalf of multiple enterprises, each of which has its own set of endpoints. In one illustrative implementation, the network security intelligence center 800 is network accessible and deployed in a cloud-based operating environment, although this is not a limitation. Further, in Figure 8 Each functional block identified in is typically implemented in software, i.e., as a set of computer program instructions executed in a processor. It should be understood that Figure 8 The functions identified in are provided for purposes of explanation only, and certain of these functions may be combined or otherwise re-arranged as desired.

[0080] As depicted, intelligence center 800 performs several functions, namely, label generation 804 (step 1) and malicious behavior discovery and coding 806 (step (4)). As depicted, generally, these activities are informed by and based on existing attack information available in intelligence center 800 (e.g., threat reports 808, expert knowledge 810, and information derived from sandboxing and assessing threats 812). This set of information is available to or obtained by security analysts. As described above with respect to Figure 7 As described, in label generation 804, each entity in endpoint system 802 is associated with one or more labels that describe its category and attributes. These labels are applied manually, automatically, programmatically, etc., or by some combination. Label generation 804 can be performed periodically or at a given occurrence. Malicious behavior discovery and encoding 806 derives malicious (or otherwise suspicious) graph patterns from existing attacks. As described above, in some illustrative embodiments, these patterns are determined by human analysts, other security detection mechanisms, machine learning systems, or a combination thereof. As also depicted, a set of malicious patterns generated from a knowledge base (808, 810, 812) of attack sources are stored in a malicious pattern database 814.

[0081] Turning to the endpoint functionality 802, functional block 816 (step 2) represents inter-process activity extraction, which involves monitoring 818 (step 2.1) and tagging 820 (step 2.2). The monitoring function 818 records activities between entities, for example, via system call monitoring, kernel hooks, system monitoring services, etc. Therefore, the monitoring function 818 can leverage existing endpoint service functionality. As noted, it is not required that monitoring 818 monitor all system calls or events, and the calls and events to be monitored are configurable as needed. In step 2.2, the tagging function 820 takes the behavioral signature created by the tagging function (step 1) and builds an abstract / tagged behavioral signature. This abstraction is desirable because the abstract / tagged behavioral signature expresses the attack logic in a more general way and thus covers one or more attack variants for a particular attack, and it enables efficient matching of labels or specific vertices / edges during subsequent matching operations (described below).

[0082] Function block 822 (step 3) provides activity graph construction. As will be described, this process generally involves ingestion 824 (step 3.1) and aging 826 (step 3.2), wherein ingestion 824 (step 3.1) expands the graph as new activity occurs and is monitored, and aging 826 (step 3.2) discards (deletes) vertices / edges of the graph when they are older than a configurable threshold or their distance to the newly expanded graph is greater than a configurable threshold. The inter-process activity graphs generated by these activity graph construction functions 822 are stored in a database 828. The inter-process activity graphs evolve as the monitoring, ingestion, and aging functions preferably operate on a continuous basis.

[0083] As also depicted, the endpoint supports an attack subgraph matching function 830 (step 5). Using this function, the endpoint protection system continuously performs graph pattern matching between the evolving inter-process activity graph and malicious behavior graph patterns. These patterns are provided by the malicious pattern database 814 in the intelligence center 800 and are stored in the local malicious pattern cache 832. As described above, the attack subgraph matching function searches for graph substructures that match the (one or more) malicious behavior graph patterns stored in the local cache 832. Therefore, in this method, the endpoint detection system function compares the evolving activity graph to the malicious inter-process graph pattern. Based on the match, the mitigation and resilience function 834 can then be called (step 6). Function 834 includes a reporting function 836 (step 6.1) and a reaction function 838 (step 6.2). Function 834 thus provides post-detection operations, which include stopping the involved process, alerting, moving the involved process to a sandbox for further evaluation, dropping ongoing network sessions, stopping ongoing disk operations, handing the matched subgraph to the user to decide on the next steps, submitting the matched subgraph to a security analyst for further study, training a machine learning classifier, etc. These are merely representative post-detection operations.

[0084] like Figure 8 As shown, mitigation and resilience function 834 interacts with intelligence center 800 in an on-demand manner, while the flow of information within endpoint functions is continuous. While this is a preferred approach, it is not intended to be limiting, as one or more functions in endpoint 802 may be executed periodically in response to occurrence or on demand.

[0085] Thus, the techniques of one or more illustrative embodiments provide a robust method for monitoring and protecting endpoints by recording inter-process events, creating an inter-process activity graph based on the recorded inter-process events, matching the inter-process activities (as represented in the activity graph) with known malicious or suspicious behaviors (as embodied in a set of pattern graphs), and performing post-detection operations in response to matches between the inter-process activities and the known malicious or suspicious behavior patterns. Preferably, the matching involves matching subgraphs in the activity graph (AG) with known malicious or suspicious behavior patterns as represented in the pattern graph (PG). During this process, direct and indirect inter-process activities at the endpoint (or across a set of endpoints) are preferably compared to known behavior patterns. Additional details regarding the different operations (functions) of the above-described detection system are provided below.

[0086] Fig. 9 Depicted is how labeled subgraph matching may be implemented according to an illustrative embodiment. As described above, and as depicted, label generation (step 1) typically occurs at an intelligence center, and labeling functionality is performed at breakpoints (step 2.2). In this method, preferably, concrete signatures (e.g., which are available to the system, e.g., with the aid of previous attack data, or otherwise) are converted into behavioral signatures (concrete) (in step 1), which are then converted into abstract / labeled behavioral signatures (in step 2.2). This technique facilitates labeled subgraph matching because the abstract / labeled behavioral signatures express general attack logic (as opposed to just some specific attack flows). In particular, abstract / labeled behavioral signatures are matched during attack subgraph matching (e.g., by their labels or by concrete vertices / edges). By expressing attack logic, graph-based behavioral signatures cover more attack variants than ad hoc approaches that use simple concrete inter-process behavioral signatures.

[0087] Fig.10 The ingestion function (step 3.1) is depicted in more detail. As depicted, the ingestion function begins by filtering the noise (step 3.1.1), after which the events are inserted into the event queue, sorted by time (step 3.1.2). Then, to facilitate evolving the activity graph, the new entity is preferably inserted into the entity-event mapping as a new key (step 3.1.3). As additional events are received, these events are then attached to the value (list) of the associated entity in the entity-event mapping (step 3.1.4).

[0088] Fig.11 and Fig.12 Describe and describe how to use the aging function to evolve activity diagrams. Fig.11An entity-event mapping is shown at two (2) different times (initially, and then after the aging function is applied). As depicted, when events are discovered (received), they are queued to the event queue and represented in the entity. The resulting entity-event mapping is shown on the left side of the figure. When given events age, they are deleted (dequeued) from the event queue, and the affected entities are also updated. The updated entity-event mapping is shown on the right side of the figure. Fig.12 These operations in the process flow are depicted. Thus, at step 3.2.1, obsolete events are dequeued. At step 3.1.2, and for each dequeued event, its associated entity identifier (id) is read, and the event is removed from the value of that entity in the entity-event mapping. At step 3.2.3, all entities with zero events are removed in the entity-event mapping.

[0089] Fig.13 Depicted is how the detection system provides indirect inter-process activity modeling, preferably using on-disk storage for both transient and persistent inter-process activities. As shown, the ingestion function (step 3.1) and the aging function (step 3.2) facilitate the construction of an inter-process activity graph to facilitate attack subgraph modeling (step 5). During these operations, on-disk storage for transient and persistent inter-process activity graph construction ensures that all known inter-process channels are systematically covered. This approach further ensures that multi-stage attacks or sneaky attacks with delayed actions do not escape detection.

[0090] Fig.14 Describe the matching function ( Figure 8 Step 5) and the mitigation and resilience functions ( Figure 8 6). Step 5.1 represents a high confidence malicious behavior match, typically based on specific signatures and tags. When this type of malicious behavior match occurs, one or more of the operations identified in the reaction function (step 6.2) are typically performed. Step 5.2 represents a suspicious behavior match, typically based on the use of an abstract pattern with tags and topology. When this type of suspicious behavior match occurs, user-assisted tagging (step 6.1.1) can be performed, followed by one or more reporting operations (step 6.1.2). User-assisted tagging operations are optional.

[0091] There is no need to implement any specific algorithm for behavior discovery or for behavior signature matching. Rather, the system approach described above provides a system approach for detecting complex and / or long-term network attacks that occur based on direct and indirect inter-process activities.

[0092] Pattern diagram (PG) (such as Figure 6The diagram 600 in FIG. 600 may be specified visually (ie, by drawing a diagram), but this is not required. The pattern diagram (or pattern diagram) may also be specified in other ways, such as by a programming language.

[0093] The following provides other details about the above-mentioned active graph (AG) construction.Activity graphs usually express the calculation on one or more computing devices (which may include endpoints) as a time graph.Therefore, activity graphs are sometimes also referred to as calculation graphs (CG) in this article because they represent the abstraction of calculation.The concepts of "activity graph" and "computation graph" are used synonymously in this article.As mentioned above, the basic elements of AG / CG are entities (e.g., processes, files, network sockets, registry keys, GPS sensors, accelerometers, etc.) and events (e.g., file reading, process forks, etc.).An entity is any system element that can send or receive information.An event is any information / control flow connecting two or more entities.An event is an information flow between entities in a pair of entities at a specific time.An event can be captured in the form of a system call, etc.An event has a unique timestamp (when it occurs) and an information flow direction (direction, bidirectional, non-direction).The indegree entity of an event can be one or two entities of an event based on the direction of the event.The outdegree entity of an event can be one or two entities of an event based on the direction of the event. A timestamp is an integer or real number that records the time of an event, and a joinpoint (or checkpoint) is a tuple of <entity, timestamp>.

[0094] Therefore, an AG / CG reference includes the computational history of any entity or event associated with an attack or threat. Security-related data (such as alerts, indicators of compromise (IOCs), and intermediate threat analysis results) are subgraphs, which can be labeled as labels on elements of the AG / CG, where an element is an alias for the referenced entity or event. As a result, threat detection is a graph computation problem whose solution is to iteratively infer threat-inducing subgraphs in the AG / CG.

[0095] More generally, and as used herein, an activity diagram is a labeled semi-directed time diagram that objectively records intrusive and non-intrusive computations on a computing device and any security knowledge associated with the computations. A specific label on the diagram typically represents one of several categories, such as labels: element attributes, element relationships, and security knowledge. Element attribute labels are objective information derived from computation records (as described above). Element attribute labels are label types that identify a set of elements with specific attributes (e.g., event type READ). Element relationship labels are objective information derived from computation records. Element relationship labels are label types that represent a certain relationship between a set of elements, such as the origin link between the READ and WRITE events of a process, which connects a large number of READ / WRITE events. Element relationship labels embed more fine-grained origin information into the inter-process level pattern diagram (PG). Security knowledge labels (when used) are subjective information about security and privacy goals and reasoning processes. Security knowledge labels are label types that mark a set of elements with some security knowledge. Security knowledge labels may be generated as, for example, intermediate / final results of threat deductions, organizational policies, IOCs, or anomaly scores input from external detection systems (e.g., a set of confidential files or IP addresses flagged as command and control servers).

[0096] Enterprises and organizations can examine multiple levels of computations for threat discovery. AG / CG describes computations at the selected monitoring level (e.g., network, host, or process level). Given a monitoring level (e.g., network), activities within an entity (e.g., process communications within a host) are typically outside the monitoring scope and not expressed in the CG. Finer-grained computation information can be expressed in a lower-level CG (e.g., host-level CG) or embedded in the CG as tags (e.g., origin tags).

[0097] Fig.15 Representative host-level AGs / CGs, such as processes and files, are depicted. Fig.15 (and the subsequent Figure 16-Figure 17 ) represents the computational history as a time grid, where horizontal lines represent entities and where vertical lines represent events. Fig.15 In this example, system activities are recorded, for example, via syscall monitoring and program instrumentation logging. Entities (en) in this CG consist of subjects (e.g., processes and threads) and objects (e.g., files, pipes, and network sockets). In this example, secure data is embedded in the tags: lb1:sensitive indicates that enf2 contains sensitive information, and lb2:untrusted indicates that enp3 is not authenticated by the company. In this example, data leakage occurs when enp3 can be traversed from enf2, as shown in Fig.15 shown.

[0098] Fig.16Depicted is a representative AG / CG at the network level. In this example, metadata of link layer communications of a small network is logged for threat intelligence computation. As depicted, lb1 is a provenance label linking four events between entities enσ2, enσ3, and enσ4. Link lb1 helps identify the causal chain between enσ3 and enσ4, avoiding impossible paths. Attack steps such as port scanning and lateral movement across hosts can be identified and reasoned on this computational graph.

[0099] Fig.17 Depicts AG / CG at the process level, where activities with the process are monitored, for example, via dynamic program analysis. In the figure, entities are memory addresses of code and data; events are instructions (e.g., calls) or syscalls (nmap). The infinity of θ (the space of entities that can be monitored or traced) supports the representation of recursive calls, for example, instances of foo() are described as enfoo, en'foo, ... Software vulnerability exploration activities (such as return-to-libc and return-oriented programming (ROP)) can be captured and examined on this computational graph.

[0100] Given an activity / computation graph that records the target computation history for both intrusive and non-intrusive data, threat recovery reduces to a graph query problem that iteratively computes closures on subsets of security-relevant subgraphs in the AG / CG, and ultimately produces subgraphs that describe threats or intrusions. Graph queries can be programmed into intrusion detection systems or behavioral anomaly detection systems, or they can be implemented through on-demand agile reasoning development. Threat hunting constitutes a sequence of graph queries to iteratively and interactively build, verify, revise, and confirm threat hypotheses.

[0101] The process of composing and executing graph queries in an activity / computation graph is graph computation. During computation, any variable that references a subgraph is also a label for a collection of entities and events of that subgraph, and the variable can be stored as a label on the AG / CG. Because the result of each iterative graph computation step is a subgraph or label, each step can be implemented natively in a graph computation language or in an external module as a black box that outputs a set of events and entities as a subgraph. Therefore, when a threat is discovered, threat intelligence is generated in a graph query. Queries, especially pattern graphs (PGs), describe threats and can be executed to search other activity / computation graphs for specific threats.

[0102] Graph pattern matching is at the heart of graph querying. In general, a graph pattern is essentially a set of constraints that describe a subgraph to be matched, where constraints on graph elements describe either (1) individual graph elements (e.g., labels / attributes of entities) or (2) element relationships (e.g., entities connected to events). Pattern composition allows human domain knowledge to be embedded into the inference process. Examples of simple patterns that can be expressed by most graph languages ​​include: typical DLL injection behavior (e.g., two entities with a PROCESS label are connected through an event with a label CREATE_THREAD), untrusted execution behavior (e.g., an entity with a FILE label but not a TRUSTED_EXE label is connected to an event with an EXECUTE label, which is then connected to an entity with a PROCESS label), and data exfiltration behavior (e.g., an entity labeled SENSITIVE is connected to an entity with a NETFLOW label within a given number of hops). These are representative but non-limiting examples.

[0103] To manage activity graphs / computation graphs and pattern graph computations on top of them, the above-mentioned system includes a graph database designed and implemented to provide efficient data storage and retrieval for field and forensic threat investigations. In some illustrative embodiments, a distributed key-value store is supported with a graph database for optimization of low-level PG operations targeting unique computation graph properties (such as data location and immutability). A representative database of this type is described in "FCCE: Highly scalable distributed Feature Collection and Correlation Engine for low latency large data analysis" by Schales et al. (hereinafter, "FCCE"). In general, a suitable database is one that employs distributed key-value storage for long-term monitoring data storage with data location optimization and concurrent multi-source streaming data ingestion.

[0104] The above-described techniques provide significant advantages. As explained, the method enables systematic inter-process activity extraction and behavior matching. The technique addresses deficiencies in existing schemes that rely on signature matching, single process detection schemes (within process detection schemes), and self-organizing inter-process behavior modeling. As noted, the methods herein also enable modeling of direct and indirect inter-process activities, as well as efficient matching of specific activities with abstract patterns that indicate malicious or suspicious behavior. The result is more robust and more accurate protection of endpoints from attack. Further, the technique enables more effective post-detection operations that can be carefully tuned to the detected activities.

[0105] Compared to existing specific attack signature schemes, using inter-process behavior patterns as described as abstract attack signatures provides significant benefits. Inter-process activity monitored according to the technology of this article records attacks with long attack vectors, or attacks that use multiple processes to achieve attack goals. Existing signature-based methods do not discover such attacks. Using abstract / tagged behavior signatures (as opposed to more specific signatures) to express attack logic, more attack variants can be covered during the detection process. In fact, existing technologies that often operate on fine-grained attack descriptions require significantly more computing power for modeling and reasoning, making these technologies impractical or expensive. In addition, attack descriptions that are finer-grained than the abstract / tagged behavior signatures in this article generally cannot help detect intrusions in the endpoint itself. In addition, inter-process behavior according to exemplary embodiments has clear semantic meaning for end users to understand and take action if necessary.

[0106] In general, the above methods provide improved endpoint detection-based network security. The present subject matter further provides a new method for systematically modeling inter-process behavior for characterizing malicious or suspicious behavior patterns between or within processes. This modeling provides a basis for advanced detection, particularly inter-process malicious / suspicious behavior discovery and inter-process behavior signature matching.

[0107] The described method provides enhanced processing of security event data (e.g., network security events) and enables the system to respond to the event more effectively. The method is automatic, efficient, and greatly alleviates the workflow requirements of SOC analysts to facilitate post-detection operations (such as threat hunting).

[0108] Iterative Constraint Solving in Graph Matching for Network Event Reasoning

[0109] As described above, AG / CG is a graph of elements with constraints and connections between them. Pattern matching of such a graph needs to satisfy all constraints of all elements and how they are connected. However, typically, a query from a graph database can only process one constraint or connection relationship. To address this limitation, the following described aspects of the illustrative embodiments provide a novel constraint solving algorithm to calculate and arrange queries and process query results, thereby ensuring the correctness and efficiency of abstract graph pattern matching.

[0110] The following describes a constraint solving technique for pattern matching (e.g., matching an activity graph (e.g., a graph constructed from endpoints) to a graph pattern). This operation is used, for example, to attack subgraph matching functions (e.g., Figure 8830, step (5)). As described above, pattern matching evaluation involves solving a set of constraints or predicate expressions defined by a pattern. This task is computationally trivial because patterns can reference other patterns via parameters, and because pattern graphs are typically stored on distributed external storage, making it expensive to check the data associated with each predicate.

[0111] To cope with the parametric expressiveness of patterns, the following techniques are implemented. Specifically, the constraint solving process effectively determines when and how many times a pattern application needs to be performed for a single pattern reference. For example, if a pattern reference is associated with a variable that is involved in a particular predicate (e.g., reaches), the referenced pattern can be repeatedly applied during the traversal process to minimize on-disk data requests in subsequent traversal steps.

[0112] Because on-disk data queries only support solving one constraint at a time, the constraint solving process (or algorithm) of the illustrative embodiments works by iteratively solving constraints and propagating the most recently solved constraint to all variables associated with previously satisfied constraints. In particular, when, for example, a pattern graph (PG) defining an attack / threat is parsed and an abstract syntax tree (AST) is created, the interpreter determines how to connect the constraints and stores the constraint relationships as a graph of constraints (GoC) in a supplementary data structure in the AST. To evaluate a pattern, the constraint solver sorts the constraints (e.g., by heuristics, user guidance, etc.) and iteratively satisfies all constraints, including single-element constraints (e.g., x has<type:READ> ) and multi-element constraints (e.g., xconn y). After each iterative constraint-solving step, the variables associated with the pattern may undergo a state change. According to an illustrative embodiment, the state change is propagated to all previously stored variables (as used herein, a variable refers to a set of matching results for an element in an abstract pattern graph) by a graph traversal of the GoC from the changed variable to all previously solved variables.

[0113] Thus, a constraint graph (GoC) is derived from the PG as a complementary data structure used by the constraint solving algorithm. Once the constraints in the PG are satisfied, the algorithm checks whether all previously satisfied constraints still hold. This operation is designed to remove some subgraph instances in the AG / CG that satisfy previous constraints but not necessarily the latest constraints. This operation is implemented as a graph traversal from the latest constraint node in the GoC to all other existing nodes (previously solved constraints).

[0114] Thus, in accordance with this aspect of the illustrative embodiments, the abstract graph pattern matching system serializes simple database queries for single graph element constraint solving, and then performs iterative constraint propagation to ensure correctness of matching of the entire abstract graph pattern. The basic concept is to evaluate a single element constraint at a time, and then propagate the constraint solution results to all relevant pattern elements, for example by traversing the pattern (as a connected graph, i.e., GoC). As will be described, in some illustrative embodiments, the second half of an element constraint solving step only evaluates connectivity constraints, and not single element constraints. The steps of single element constraint solving are repeated, and single element constraints are evaluated and then propagated. This process continues until all single element constraints have been evaluated and all propagations have been performed.

[0115] Fig.18 An iterative constraint solving process according to one illustrative embodiment is depicted as a process flow. An iterative constraint solving process (sometimes referred to as an "iterative constraint solver") provides significant computational and memory efficiency by iteratively solving constraints and propagating the newly solved constraints to all variables associated with previously satisfied constraints. Fig.18 , the process begins at step 1800, establishing a relationship graph between PG elements, which is the GoC described above. At step 1802, all elements in the GoC are marked as unsolved. At step 1804, a test is performed to determine whether all elements in the GoC are marked as solved. If not, the routine continues at step 1806 to solve one element constraint and then mark it as solved. As described above, preferably, the iterative constraint solver solves one constraint at a time. At step 1808, and with respect to the one element constraint, the result (of solving the one element) is propagated to all connected elements in the GoC that have been solved. The process then returns to step 1804 and iterates until all elements in the GoC are marked as solved. When the test result at step 1804 is positive (i.e., all elements in the GoC are marked as solved), the process continues at step 1810 to output (one or more) matching subgraphs. The process is thus completed.

[0116] Thus, the iterative solver of the illustrative embodiment begins with an empty set of touched variables and initializes each untouched variable (step 1802). The process then performs a new constraint evaluation by evaluating a single constraint per iteration, setting its associated variable as touched (step 1806). In the same iteration, the process then propagates the constraints, particularly by updating the associated touched variables to reflect the changes (step 1808). The process then repeats new constraint evaluations (for other constraints that have not yet been marked), and continues until all constraints have been evaluated.

[0117] When evaluating single element constraints, each constraint works like a filter on the graph element. For example, "elementx{type:event_read}" filters out elements in "x" that are not of type event_read. When evaluating connectivity constraints, each constraint acts like a filter on two or more graph elements. For example, "element x connects to y" filters out elements stored in variable "x" that are not connected to "y", and vice versa for "y". If the variable has been touched in a previous iteration, the above filtering occurs in memory. Otherwise, the variable holds a reference to the entire activity graph (stored in the database). A database query is then generated to filter the entire activity graph.

[0118] In one embodiment, the propagation operation (step 1808) uses a customized breath-first search (BFS) function that uses a queue that takes into account the connectivity of the GoC. The function takes into account whether the element has been solved (because only solved elements are pushed to the queue) and whether any changes have been made to the constraints (if no changes have occurred, the vertex is dropped from the queue). In an illustrative embodiment, the propagation applies element relationship constraints based on the newly solved elements to affect other elements in the relationship constraints.

[0119] Fig.19 A representative example of a schema diagram 1900 and a corresponding GoC 1902 is depicted. Thus, Fig.19 Corresponds to Fig.18 Step 1800 in the process flow in . It should be noted that GoC can be different from a schema diagram because some element relationships may not be explicitly written in the schema diagram. Using these examples, Figure 20-23 Describes the application of an iterative constraint solving process using GoC and with respect to a pattern graph. Specifically, Fig. 20 This corresponds to step 1806 in the process flow. Here, the first element is matched (solved) by matching all vertices as processes, the vertices having the attribute "cmdline", wherein the value of the attribute includes the substring "firefox". Fig.21 (which corresponds to steps 1806 and 1808) depicts how the process then performs a propagation from element 2 to element 1 (in GoC) and eliminates all vertices in element 1 that do not have a match to element 2 to connect to. This is the concept of removing subgraph instances that satisfied the previous constraints but not necessarily the latest constraints. Fig. 22 Also corresponding to steps 1806 and 1808, a further propagation operation is depicted, namely propagating from element 3 back to element 2 (in GoC) and eliminating all matching edges connected to the pseudo-element 3 that are not processes (single element constraints on attribute "type"). Fig.23(Also corresponding to steps 1806 and 1808) depicts a further propagation operation, namely propagating back from element 4 to all related elements (in this case, elements 3, 2, and 1) to eliminate vertices and edges due to the single element constraint (type read) of element 4.

[0120] In general, according to the method, the GoC is extracted and stored as a complementary data structure to the schema. During constraint propagation in an iteration, the GoC is traversed to propagate the effects of filtering from the variables of the evaluated predicate to all other connected touched variables. There is no requirement that the activity graphs on which the iterative constraint solver works be limited to inter-process activity graphs. The above-described iterative constraint solving techniques can be used for any type of activity graph, for example, an activity graph representing activity data captured in association with a process, a host, a network of machines (e.g., where each entity is a host), etc.

[0121] Furthermore, there is no requirement that the iterative constraint solving process be used only for cybersecurity reasoning, as the technique may also have applicability in other use cases that utilize graph pattern matching. Thus, the described approach (i.e., serializing simple database queries for single graph element constraint solving and then performing iterative constraint propagation using a complementary graph of constraints) may be implemented in any abstract graph pattern matching system.

[0122] Fig.24 2400 in which techniques according to one or more illustrative embodiments may be provided. The platform may be implemented as a standalone functionality or application, as a network or cloud accessible service, or otherwise in Figure 8 The intelligence center depicted in Figure 3 Security intelligence platform in Figure 4 2404, and a graph database 2404. As described, the platform 2400 includes a language interpreter 2402, a graph database 2404, and a user interface component 2406. The user interface component 2406 includes an interactive console 2408 and a computational graph visualization tool (browser) 2410. The user interface component provides an interactive programming and data inspection environment for threat reasoning. The graph database 2404 preferably includes a graph query interface 2412, a memory graph cache 2414, an element cache 2416, a label cache 2418, one or more graph construction routines 2420, an on-disk element query function 2422, a key-value storage conversion table 2424, and a FCCE client 2426. The FCCE client 2426 interacts with one or more FCCE data nodes 2428 across the network, which typically store graphs in a distributed manner. As previously described, the graph database 2404 uses distributed key-value storage on the FCCE data node 2428 for long-term monitoring data storage with data location optimization and concurrent multi-source stream data ingestion.

[0123] The interpreter 2402 includes multiple functional elements including a code generation module 2439 that works with a constraint solver 2430, other built-in algorithms 2432, and a universal disk format (UDF) linker 2433. The interpreter 2402 also includes a lexical analyzer / parser 2434, a type checking and inference module 2436, and an AST optimizer 2438.

[0124] The user interface also includes a batch processor 2440. The graph database 2404 stores the pattern graph portions in memory and on disk, and it provides a graph query API (2412) to the interpreter 2402. The main function of the graph database is to bridge the semantics of the pattern graph and the low-level data storage, and preferably uses multiple layers of cache (2414, 2416, 2418) and data arrangement based on PG attributes (such as the temporal locality of events) to optimize graph retrieval throughput. As described above, one such graph database solution that provides these features is FCCE. Specifically, FCCE supports concurrent multi-source asynchronous ingestion, distributed data storage, and data locality management. In order to optimize graph queries based on pattern graph attributes, the FCCE scheme is used. The scheme represents the pattern graph in key-value pairs, and preferably replicates certain values ​​in one or more schemes for data local retention and fast retrieval from different perspectives. Thus, for example, one copy of an event can handle temporal locality, where events are indexed by time, and events occurring within a time window are managed on one memory page and stored at consecutive file system boxes. Other event copies can handle tags and shared entities.

[0125] To process a graph query, the graph database first checks whether any part of the data has been loaded into memory by a previous query. If not, the database splits the graph query into one or more on-disk element queries, each of which will be converted into a key-value query that the graph database (e.g., FCCE) can process. Tags are expressed as dictionary items to express complex element attributes. In an example operation, a simple element query that searches for file entities whose paths contain the substring "firefox" is converted into two graph database queries: the first searches for all satisfied tags, and the second searches the raw data to construct elements associated with these tags. When retrieving raw data from disk, preferably, buckets of key-value pairs are first cached in the graph database client, where the data in the bucket preferably has strict data locality and is queried with a high probability in the same high-level graph query or subsequent queries. Then, different components of the element are constructed, and some components are cached for frequent references, for example, the primary tag for a process containing multiple pieces of information (including username, uid, group, etc.), and it is cached as a reference. Next, the element is constructed and cached. Finally, the requested graph is assembled and returned.

[0126] Fuzzy network detection pattern matching

[0127] As described above, an activity graph (AG) typically represents a computation on one or more computing devices (which may include endpoints) as a time graph, also referred to herein as a computation graph (CG) because it represents an abstraction of computation. As previously described, the basic elements of an AG / CG are entities (e.g., processes, files, network sockets, registry keys, GPS sensors, accelerometers, etc.) and events (e.g., file reading, process forking, etc.), where an entity is any system element that can send or receive information, and an event is any information / control flow that connects two or more entities. An event is an information flow between entities in a pair of entities at a specific time, and can be captured in the form of a system call, etc. An event has a unique timestamp (when it occurs) and an information flow direction (directional, bidirectional, non-directional). The above-mentioned mechanism according to one or more illustrative embodiments uses an iterative constraint solver to perform pattern matching in an AG / CG based on a pattern graph (PG) and / or a constraint graph (GoC), and thereby identifies or detects potential intrusions, identifies or detects network attacks or network threats, performs information forensics, and performs network reasoning.

[0128] Utilize graph pattern matching, multiple human knowledge about the pattern of activity is encoded into different patterns, and this different pattern is the graph of the target subgraph in AG / CG.Although it is beneficial practice to have complete record of computing activity in AG / CG, and it is good practice to use pattern to accurately describe what security developers and analysts are looking for about intrusion, attack, threat, etc., but AG / CG represents complete record and security developers and analysts have accurate knowledge to intrusion, attack, or threat so that their knowledge can be represented in pattern graph (PG) and the assumption is not always realistic.For example, AG / CG may be incomplete in fact in many real world instances.In addition, the developer or analyst may only remember the skeleton of the pattern instead of the accurate pattern of the potential instruction, attack or threat that needs to be identified in AG / CG representation.In addition, it would be beneficial to be able to detect the variant of intrusion, attack or threat defined by a given pattern graph.In each of these cases, requiring the accurate matching of the subgraph in the pattern graph and AG / CG is a restriction that makes pattern matching less effective or less friendly to the analyst / developer.

[0129] In further aspects of the illustrative embodiments, rather than requiring an exact pattern match of a pattern graph (PG) to a subgraph of an AG / CG, the illustrative embodiments provide a mechanism for performing fuzzy or imprecise graph pattern matching given a temporal graph (such as an AG / CG that extends over time) and a given pattern graph (PG), the pattern graph (PG) can generally define a target subgraph to be returned, such as a pattern representing a cyber attack / cyber threat or unauthorized intrusion, sometimes collectively referred to as a cyber incident. With respect to these further aspects of the illustrative embodiments, a training module and a matching module are provided, wherein the training module continuously (within a given time period) checks a growing AG / CG at specified time intervals and decomposes the streaming AG / CG into incremental graph portions. Each graph portion is considered a separate training sample. A filter with parameters to be learned is then applied to each training sample by a convolution calculation, sliding the filter through the training sample to learn at different locations. In this way, the filter represents a graph embedding technique that does not require processing of the special properties of the temporal graph and can utilize graph embedding algorithms such as node2Vec or a graph neural network (GNN).

[0130] The filter captures the topological features of the graph as well as the attribute features of the vertices (nodes) / edges (activities or events). The goal is to learn the parameters of the filter, which builds a good embedding for the subgraph. In some illustrative embodiments, the filter can slide over the entity and cover a time span. In this way, the subgraph covered by the filter can be represented by the neighborhood of the entity in time. The filter learns a good embedding of the node / entity instead of a complex subgraph.

[0131] The matching module runs only in response to a pattern graph (PG) being provided (e.g., by a user via a user interface or other source (such as an automated computing component)), and similar subgraphs matching the given pattern graph (PG) are identified in the AG / CG. The matching module selects an appropriate filter, applies the selected filter to the pattern to obtain its embedding, and searches for similar subgraphs in the embedding space. The matching module then maps the retrieved embedding back to the graph space and outputs the fuzzy matching subgraphs.

[0132] As described above, the output of these mechanisms according to another aspect of the illustrative embodiments is a collection of subgraphs that are similar to a pattern graph (PG), but need not be identical to a given pattern, nor isomorphic to a given pattern. Fig.25An example of a pattern 2510 is shown, and two fuzzy matched subgraphs 2520 and 2530 or AG / CG (not shown), the example of pattern 2510 is used to define a pattern representing an intrusion, attack, or threat, and subgraphs 2520 and 2530 can be matched to pattern 2510 by the fuzzy matching mechanism of the exemplary embodiment. It should be understood that in these figures, horizontal lines represent entities, arrows between the horizontal lines represent events, and the direction of the arrows represents the direction of system calls corresponding to those events, etc. The horizontal lines representing entities in the figures are for convenience, so that events can be displayed as arrows connecting two horizontal lines, which indicate events between connected entities.

[0133] like Fig.25 As shown, the fuzzy matched subgraphs 2520 and 2530 do not exactly match the original pattern graph 2510, at least with respect to specific entities and / or events between entities. For example, the fuzzy matched subgraph 2520 differs from the original pattern graph 2510 in that the "python" entity exists instead of the "sh" entity, and the entity " / etc / passwd" exists instead of the entity " / etc / shadow". Similarly, the fuzzy matched subgraph 2530 differs from the original pattern graph 2510 in that the entity "IMG2019.jpg" exists instead of the entity " / etc / shadow", and the entity "IMG2019.jpg.ransome" exists instead of the bottom entity (unnamed in the pattern graph 2510).

[0134] In previous pattern matching methods, since there is no exact match between the pattern graph 2510 and the subgraphs 2520, 2530, this difference in the pattern and the subgraph will cause the subgraph to not be returned as a potential intrusion, attack, or threat. However, as will be described in more detail below, according to another aspect, an illustrative embodiment provides a mechanism for performing such fuzzy matching in the pattern graph and AG / CG so that such similar subgraphs can be identified. This allows incomplete pattern graphs (for example, when an analyst or developer does not have access to some knowledge) to be used as a basis for matching, pattern graphs with erroneous information to be utilized, or similar pattern graphs for known attack activities to be used to identify similar attack subgraphs in the AG / CG, even when there is no exact match.

[0135] It should be understood that exact temporal graph pattern matching such as previously described above operates in the original graph space and the pattern graph (PG) of the AG / CG using, for example, the tools and mechanisms previously described, e.g., graph databases, multifaceted local caches, dynamic programming for pattern matching, constraint graphs (CoGs), iterative constraint solvers, etc. On the other hand, fuzzy temporal graph pattern matching of other aspects of the illustrative embodiments operates by converting the matching space from the original graph space to a vector space using convolutions (operations on space that indicate how the shape of one is modified by another) on the temporal graph, using subgraph embeddings of trained neural networks, and continuous learning on the evolving graph.

[0136] Fuzzy temporal graph pattern matching operates on dynamically growing temporal graphs (eg, AG / CG), where new parts of the graph are added over time. Fig.26 is an example diagram showing such a dynamically growing time graph, where horizontal lines represent entities in the AG / CG and vertical arrows or edges represent events. Fig.26 As shown in , during a first time point t0, the time graph (e.g., AG / CG) is as shown in element 2610. At a later time t1, the time graph will look as shown in element 2620, with additional nodes and events 2621-2625 due to the additional activities between entities occurring from time t0 to time t1. The same applies to Fig.26 2630 and 2640. At each time point, the portion of the time graph represented by the dashed box represents a new portion of the time graph that will be processed to determine whether it alone or in combination with previously processed graph portions includes a subgraph that matches a pattern graph indicative of an intrusion, attack, or threat.

[0137] Fig. 27 is an example diagram that diagrammatically depicts a process for extracting information from a sub-graph (e.g., AG / CG) of a temporal graph using a moving convolutional filter. Fig. 27 The process shown can be performed at predetermined time points (e.g., t0, t1, t2, etc.), where nodes and events that have occurred since the previous time point at which the process was performed are evaluated to generate vector representations of nodes and events that occurred between those time points, e.g., Fig.26 The process collects vector representations within this window so that they can be compared to vector representations of patterns indicative of intrusions, attacks, or threats, or simply to activities that an analyst, developer, or automated computing component wishes to search for in the time graph.

[0138] like Fig. 27 As shown in FIG, the convolution filter 2710 (in Fig. 27A moving filter window 2710 (shown in FIG. 27A ) is defined and centered on the entity (horizontal line) of the time graph. The subgraph within the moving filter window is calculated as a vector, i.e., a graph embedding. For example, graph embedding is a well-known technique for converting nodes, edges, and their features into a vector space while retaining properties (e.g., graph structure) to the greatest extent possible. Machine learning algorithms can operate on this vector space representation generated by graph embedding. This embedding can be performed at various levels, such as a node level, a subgraph level, etc.

[0139] exist Fig. 27 In the example shown in , the filter 2710 is moving with its center on the selected entity 2712, and the subgraph of the filter window is summarized around the center entity 2712. When the filter 2710 moves along the selected entity 2712 in the time graph from the previous time point where the embedding is performed to the second time point where the current embedding is performed, a vector representation of the filter window is generated and stored for the range of time points of the filter window corresponding to the filter 2712. That is, the graph embedding is implemented as a convolution filter 2710 with time boundaries, for example, how many time points (horizontal axis) are included in the filter window, and reachability restrictions (e.g., how many direct / indirect events to / from the selected entity 2712 are within the filter window (vertical axis)). Different filters of different sizes can be defined for performing embedding of the time graph, for example, the size of 1-hop, 2-hop, 3-hop, smaller / larger time intervals, etc. around the entity selected as the center. Thus, the horizontal boundaries of the filter window 2710 are defined by the range of time points desired to achieve, and the vertical boundaries of the filter window 2710 are defined by the reachability limits (e.g., distance from the central entity (e.g., Fig. 27 2712 or 2714) for which the event will be considered for embedding purposes.

[0140] By restricting the problem to node embeddings with temporal bounds and reachability constraints, the embedding of the information within the filter window can be performed using non-temporal graph node embedding mechanisms. For example, the actual embedding of the information contained within the filter window can be performed using node2vec embeddings (distance embeddings), graph convolutional network (GCN) embeddings (where the graph is represented as a normalized graph Laplacian matrix), graph neural networks (where the neighborhood of a vertex is summarized based on a summary of the vertices to which it is connected (in layers)), etc.

[0141] In an embodiment of embedding a graph into a vector using a GCN or graph neural network (GNN), values ​​are first assigned to a weight matrix (parameters of neurons) in the GCN / GNN. It is important to train these values ​​so that they are good enough to keep the generated embeddings similar between similar graphs (parts of CG / AG or PG). The process of finding these good neuron value parameters or weights is called "training", and thus, the GCN / GNN is trained to generate these weight matrices. Once trained, the GCN / GNN can be used to perform the embedding of the moving filter window 2710. The training can be unsupervised training, where the training data is previously seen as, for example, CG / AG and PG, and the training uses a defined loss function, which can be defined by the user, and then minimized over the maximum number of training epochs of the training process. An example of a loss function is a loss function that encourages nearby nodes to have similar embeddings, as described in Hamilton et al., "InductiveRepresentation Learning on Large Graphs," Advances in Neural InformationProcessing Systems, pp. 1024-1034, 2017. This is merely one example of a loss function and is not intended to limit the present invention. Any type of loss function required for a particular desired embodiment may be used without departing from the scope of the present invention.

[0142] like Fig. 27 As shown, the entity 2712 selected as the center can then be iterated a specified number of entities in the time graph according to the size of the filter (e.g., the number of "hops" of the filter). For example, the depiction of moving the filter window in time points (1)-(3) is about the selected entity 2712 from a first time point (shown as (1)) to a second time point (shown as (2)) and a third time point (shown as (3)). Once the movement of the filter window reaches a time boundary, the filter window is re-centered with the new selected entity (e.g., selected entity 2714) as the center, and as shown with respect to Fig. 27 The process is repeated as shown at time points (4)-(6) in FIG.

[0143] The process generates a vector representation of the temporal graph based on a distance embedding technique (such as node2vec) or an embedding performed by a trained neural network mechanism (such as a GNN or a multi-layer CNN). For example, in one illustrative embodiment, different convolution filters with different sizes are defined, and multiple GNNs, each with one filter, are trained continuously. Assuming that the process generates vector representations of portions of the temporal graph, a fuzzy match of the vector representation of the mobile filter 2710 on the CG / AG with the vector representation of the given pattern graph (PG) is performed to determine if there is a sufficient match, i.e., a search for nearby vectors in the vector space is performed.

[0144] That is, the search for "nearby" vectors is to find vectors of a portion of a pattern graph (PG) (i.e., a "graph patch") under the moving filter 2710 in the current CG / AG, which portion of the pattern graph looks similar to a portion of the graph (e.g., similar morphology, similar node / edge attributes, etc.). Similar graph patches can be close or far apart in the CG / AG, but they are similar in properties to those represented by the vector embedding. The "nearby vector" technique for comparing vector representations or embeddings of graph patches is used to determine for each vector slot of the vector representation how close or far the vector representations are from each other, i.e., the distance between the values ​​in the vector slot of the vector representation, and thereby generate a measure of the similarity of the two vector representations. The measure of similarity can be compared to a threshold measure of similarity to determine whether two vectors are identical to each other within a given tolerance, and therefore determine whether they are similar, i.e., are "nearby" vectors or are not "nearby" vectors. The "nearby vector" method allows for a less computationally intensive method of operating in vector space, rather than a more computationally intensive method of determining how similar or different graphs are in graph space. Therefore, with the nearby vector method, a graph is embedded into the vector to search for nearby vectors using fuzzy or imprecise graph pattern matching. Any currently known or later developed method for calculating distances between vectors in a high-dimensional vector space can be used to actually calculate the distances between vectors, and thus identify which vectors are "nearby". In one illustrative embodiment, a Euclidean distance measure or a cosine similarity measure can be used to identify the distance, which can then be used with a defined threshold level of distance to identify similar or "nearby" vectors.

[0145] For nearby vectors discovered by this fuzzy or imprecise matching process, the nearby vectors are mapped from the vector space back to the graph space, and specifically mapped back to the subgraph instance. For example, in one illustrative embodiment, a mapping / lookup table (e.g., Vec2Graph mapping 3220 in FIG. 31 below) that maps vector slot values ​​or combinations of vector slot values ​​to corresponding nodes / edges can be maintained while the embedding is being processed, and the vector values ​​can thus be looked up in this table and used to recreate the corresponding nodes and edges of the subgraph. The subgraph instance generated by this mapping back to the graph space is then stored for identifying potential attacks or threats, such as by presenting the subgraph to an analyst or developer via an interface of a cybersecurity intelligence center to determine whether the subgraph instance is an actual attack, threat, or unwanted intrusion.

[0146] As described above, the actual fuzzy or inexact matching process can be implemented using node2vec, multiple GNNs, each of which has a specific filter among multiple defined filters, etc. Fig.28 is an example flow chart outlining exemplary generalized operations for performing fuzzy matching in accordance with one illustrative embodiment. Fig.28 It is assumed that the embedding is performed using a trained graph neural network model rather than a simpler distance-based neural network model embedding (such as node2vec). However, it should be understood that the illustrative embodiments may be implemented using a distance-based neural network model embedding as opposed to a mechanism based on a trained graph neural network model without departing from the scope of the invention. That is, while in some illustrative embodiments, the trained GNN approach is preferred because it is more accurate and capable of embedding a more complex set of attributes relative to the node2vec embodiment (which is relatively simpler but limited to providing information about topology, such as node / edge attributes), in other illustrative embodiments, the node2vec embodiment may also be utilized.

[0147] Fig.28 The operations outlined in can be done, for example, by Figure 8 and Fig.14 This is achieved by attack subgraph matching 830 in, for example, where a malicious pattern corresponds to a given pattern graph (PG) for intrusion, attack, or threat, which matches a pattern in an inter-process activity graph (AG) or a computation graph (CG). Fig.14 The process shown in steps 5.1 and 5.2 can be used according to Fig.28 Replace it with a new fuzzy matching process (or algorithm).

[0148] like Fig.28As shown, the process begins with defining filters of different sizes (step 2810). Multiple filters of different sizes are used to perform embedding at different graph patch sizes. Because the mechanism of the illustrative embodiment may not know how large the PG is when providing the PG as the basis for a fuzzy or inexact match, filters of different sizes allow for adaptation to PGs of various sizes, i.e., PGs of different sizes require filters of different sizes, which correspond to different graph patch sizes on the CG / AG for vector encoding. For example, filters based on 1-hop, 2-hop, 3-hop, and different time ranges can be defined for performing graph embedding of windowed portions and / or pattern graphs of AG / CG as vector representations. However, it should be recognized that in some illustrative embodiments where a single graph patch size is required and known in advance, a filter of a single size may be utilized. Without departing from the scope of the present invention, the illustrative embodiments of the present invention may utilize a filter of a single size or multiple filters of different sizes.

[0149] One or more neural network models are trained to perform graph embedding based on the defined filters and generate vector representations (step 2820). The training involves initial training of a neural network based on a training data set, which can be based on known CG / AG and PG. That is, for example, in a particular embodiment, an initial set of one or more CG / AGs can be obtained from monitoring of computer resources, and one or more existing PGs (knowledge to be searched) can be defined by an analyst to train the GCN / GNN with one or more filters. For example, the GCN / GNN can operate on the CG / AG and PG to determine whether there is a matching subgraph to the PG within the CG / AG and the corresponding output generation. Thereafter, it is determined whether the GCN / GNN generates the correct output based on the loss function, and if not, the operating parameters (e.g., weights) of the GCN / GNN are adjusted by the maximum number of training times or iterations to minimize the loss function until a predetermined threshold level of loss or error of the GCN / GNN is obtained. Once trained, the GCN / GNN can be executed substantially simultaneously with the operation of the monitored computer system, so that the trained GCN / GNN can embed newly arrived CG / AG and PG and return a similar graph portion of the CG / AG based on the PG.

[0150] That is, given an input AG / CG, as previously described, the AG / CG is processed by a trained neural network using the defined filters to generate one or more first embedding vectors (step 2830). For example, in one illustrative embodiment, multiple graph convolutional networks (GNNs) can be trained, each GNN implementing one of the defined filters, and a selected one of the GNNs can be applied to the AG / CG based on the size of the filter and the size of a given graph pattern. In another illustrative embodiment, a single multi-layer convolutional neural network can be used with layers corresponding to filters of different sizes, and the fuzzy pattern matching task performs convolutions similar to AG / CG on the pattern graph until a layer of filters covers the entire pattern in the pattern graph.

[0151] The selected filter size is used to generate an embedding vector for the pattern in the pattern graph, thereby generating a second embedding vector (step 2840). The second embedding vector is used to search for nearby vectors in the vector space of the AG / CG generated by the corresponding trained neural network (step 2850). Any nearby vectors found in the vector space are then mapped back to the corresponding subgraph instance of the AG / CG (step 2860). The subgraph instance is then returned for reaction and reporting operations (step 2870). For example, Fig.14 As shown in steps 6.2 and 6.1.2 in , different reactions and reports can be implemented, such as generating an alarm, terminating the process involved, delaying the process request, limiting resources (e.g., disk / network access), submitting the suspicious subgraph for further evaluation by an analyst, etc. The operation then terminates. Although the process shows termination, it should be understood that the process can be repeated, for example, in a seemingly continuous manner, at additional time points or at specific predefined time intervals, in response to user or automatic computing component requests, upon the occurrence of predefined events, etc. In addition, the processing can be performed for each of a plurality of different pattern pattern graphs, i.e., different defined intrusions, attacks, or threats for which pattern matching is to be performed.

[0152] As discussed herein, additional mechanisms of illustrative embodiments based on fuzzy or inexact matching identify similar portions or patches of a CG / AG compared to one or more PGs representing potential cyber attacks, cyber threats, etc., or even pattern graphs that are of particular interest to only system analysts, administrators, or other authorized personnel, or other computing system resources (e.g., other computing algorithms that can operate based on the identification of similar portions of patches of CG / AG). It should be understood that when similar portions or patches of a CG / AG are found, depending on the desired embodiment, a single vector output corresponding to the vector closest to the vector representing the PG may be returned or the top k nearest vectors may be returned. In these cases, the nearest or top k nearest vectors can be mapped back to similar subgraphs in the CG / AG, as previously described. In addition, in some illustrative embodiments, a user can specify a distance threshold and all vectors within this threshold, i.e., all vectors similar to the PG vector within this threshold distance can be returned as results and mapped back to the subgraph portion or patch of the CG / AG.

[0153] Fig.29 is a flow chart outlining an example fuzzy matching operation according to an illustrative embodiment, wherein multiple graph neural networks (GNNs) are implemented to perform embedding. Fig.29 As shown, the process again starts with defining filters of different sizes (step 2910). Multiple GNNs are trained using each GNN that implements a single filter from the filters defined in step 2910 (step 2920). In response to the triggering of a process to perform a network threat assessment of an activity graph representing events occurring with respect to an entity of a computing system (step 2930), a given pattern graph (PG) is provided (step 2940). A filter having a filter size corresponding to the size of the pattern graph is selected, for example, a filter that is not too small or too large than a pattern in the pattern graph in terms of hop count or time range (step 2950). For example, the size of the selected filter may be selected as a minimum size filter that contains the size of the pattern graph.

[0154] The selected filter is used to generate a vector representation of the pattern graph, i.e., an embedding vector of the pattern is calculated (step 2960), which is then used to search for nearby vectors in the AG / CG in the vector space (step 2970). The identified nearby vectors are then mapped back to subgraph instances in the AG / CG (step 2980), and the subgraph instances are returned for further reaction and reporting (step 2990). The operation then terminates.

[0155] Fig.30 An example system design and process flow for performing fuzzy network detection pattern matching according to an illustrative embodiment is shown. Fig.30As shown, endpoints in a monitored network 3010 are monitored by a monitoring process 3020 of a SIEM system 3030 to perform inter-process activity extraction, e.g. Figure 8 31 ) to generate an inter-process activity graph 828 (referred to as a streaming time graph 3040 in FIG. 31 ). The monitoring 3020 and generation of the time graph 3040 may be performed continuously so that the time graph 3040 grows dynamically, and the process of the illustrative embodiment for performing fuzzy network detection pattern matching may be performed at specified intervals based on the state of the time graph 3040 at a specific time point relative to a previous time point at which the fuzzy network detection pattern matching was performed.

[0156] A temporal convolution operation 3050 using one or more filters and a moving filter window method previously described is performed on the temporal graph 3040 to learn the parameters of the filter 3070 and generate a subgraph embedding 3060. The term "temporal convolution" refers to convolution over time. The illustrative embodiments provide a mechanism for performing convolution to account for a graph that changes over time by structuring the temporal graph as a two-dimensional grid (one axis is time and the other axis is space), rather than performing convolution on the temporal graph for a specific moment (a snapshot of the graph at that moment). Therefore, operations 3040-3060 can be performed continuously as the temporal graph grows dynamically. In addition, the learning performed by the neural network used to implement the temporal convolution operation 3050 can be continuously trained in an unsupervised manner using an unsupervised machine learning process.

[0157] The subgraph embedding 3060 is used to generate vectors in a vector space 3080, which can be used to identify nearby vectors of a given pattern graph 3090. That is, a filter 3070 corresponding to the size of a given pattern graph 3090 is applied to the pattern graph to generate a subgraph embedding 3100 of the pattern graph 3090, which is also used to generate a vector representation in the vector space 3080. Based on the vector representation in the vector space 3080, nearby vectors 3110 near the subgraph embedding 3100 of the pattern graph 3090 are identified. The nearby vectors 3110 are mapped back to the corresponding subgraph using a vector to graph mapping operation 3120. The resulting subgraph instance 3130 is then output for further reaction and reporting operations.

[0158] In some illustrative embodiments, the methods described herein are designed to be implemented in an automated manner within or in association with a security system, such as a SIEM, APT solution, endpoint management solution, etc. The functionality described above may be implemented as a standalone method, such as a software-based function executed by a processor, or it may be available as a management service (including as a web service via a SOAP / XML interface). The specific hardware and software implementation details described herein are for illustrative purposes only and are not intended to limit the scope of the subject matter described.

[0159] More generally, a computing device in the context of the disclosed subject matter is a data processing system including hardware and software (such as, for example, Figure 2 The data processing system may be a data processing system that provides native support for Web and other known services and protocols, including but not limited to HTTP, FTP, SMTP, SOAP, XML, WSDL, UDDI, and WSFL. Information about SOAP, WSDL, UDDI, and WSFL may be obtained from the World Wide Web Consortium (W3C), which is responsible for developing and maintaining these standards; further information about HTTP, FTP, SMTP, and XML may be obtained from the Internet Engineering Task Force (IETF). Familiarity with these known standards and protocols is assumed.

[0160] The mechanisms described herein may be implemented in or in conjunction with different server-side architectures including simple n-tier architectures, web portals, federated systems, etc. The techniques herein may be practiced in loosely coupled server (including "cloud" based) environments.

[0161] More generally, the subject matter described herein can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment containing both hardware and software elements, wherein it is understood that an embodiment using a software component has a software component executed on hardware, so that the software component specifically configures the hardware component as a dedicated hardware component specifically configured to perform operations corresponding to the software component. In a preferred embodiment, the function is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc. In addition, as described above, the access control function based on the identification context can take the form of a computer program product accessible from a computer-available or computer-readable medium, which provides a program code for use by a computer or any instruction execution system or in combination with a computer or any instruction execution system. For the purpose of this description, a computer-available or computer-readable medium can be any device that can contain or store a program for use by an instruction execution system, device or equipment or in combination with an instruction execution system, device or equipment. The medium can be an electronic, magnetic, optical, electromagnetic, infrared or semiconductor system (or device or equipment). Examples of computer-readable media include semiconductor or solid-state memory, magnetic tape, removable computer disk, random access memory (RAM), read-only memory (ROM), rigid disk and optical disk. Current examples of optical disks include compact disk - read only memory (CD-ROM), compact disk - read / write (CD-R / W) and DVD.A computer readable medium is a tangible article.

[0162] A computer program product may be a product having program instructions (or program codes) for implementing one or more of the described functions. Those instructions or codes may be stored in a computer-readable storage medium in a data processing system after being downloaded from a remote data processing system via a network. In some embodiments, instructions or codes may be stored in a computer-readable storage medium in a server data processing system, and are suitable for downloading to a remote data processing system via a network for use in a computer-readable storage medium in a remote system. In a representative embodiment, the graph generation technology is implemented in a special-purpose computer, preferably in software executed by one or more processors. The software is maintained in one or more data stores or memories associated with one or more processors, and the software may be implemented as one or more computer programs. In general, the dedicated hardware and software include the above-mentioned functions.

[0163] Further, any authentication or authorization functionality required herein may be implemented as an addition or extension to an existing access manager or policy management solution. Although a particular order of operations performed by certain embodiments of the present invention is described above, it should be understood that such an order is exemplary, as alternative embodiments may perform operations in a different order, combine certain operations, overlap certain operations, etc. References in the specification to a given embodiment indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic.

[0164] Finally, while given components of the system have been described separately, those of ordinary skill in the art will understand that some functionality may be combined or shared in given instructions, program sequences, code portions, and the like.

[0165] The technology herein provides improvements to another technology or technology field (among others): endpoint management systems, advanced persistent threat (APT) solutions, security incident and event management (SIEM) systems, and improvements to knowledge graph-based network analysis (including threat hunting). Network threat hunting is a process of actively and iteratively formulating and verifying threat hypotheses based on security-related observations and domain knowledge. The method herein facilitates this activity by modeling threat discovery as a graph computation problem. In fact, given a process graph that records the target computation history of both intrusive and non-intrusive data, threat discovery reduces the graph query problem of iteratively computing closures on a subset of security-related subgraphs in the process graph and then ultimately generating a subgraph describing the intrusion threat. Graph queries can be preprogrammed into an intrusion detection system or a behavioral anomaly detection system, etc. Threat hunting constitutes a sequence of graph queries to iteratively and interactively conceive, verify, revise, and confirm threat hypotheses. The graph construction and matching techniques herein can be used to discover and act on inter-process activities outside of enterprise endpoint machines. The technology herein can also be used based on in-process.

[0166] The description of the present invention has been presented for the purpose of illustration and description, and is not intended to be exhaustive or limited to the invention in the disclosed form. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope of the described embodiments. The embodiments are selected and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the various embodiments of the invention with various modifications suitable for the intended specific use. The terms used herein are selected to best explain the principles of the embodiments, the practical application, or the technical improvements to the technology found in the marketplace, or to enable those of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A method in a data processing system for identifying patterns of computing resource activity of interest in activity data characterizing activity of a computer system element, the method comprising: receiving, by the data processing system, the activity data characterizing activity of a computer system element from one or more computing devices of a monitored computing environment; generating, by the data processing system, a temporal graph of the activity data, wherein the temporal graph includes nodes representing elements of the computer system and edges connecting the nodes, wherein each edge represents an event occurring between the computer system elements represented by the nodes connected by the edge; applying, by the data processing system, a filter to the time graph to generate one or more first vector representations, each vector representation characterizing nodes and edges within a moving window defined by the filter; applying, by the data processing system, the filter to a pattern graph representing patterns of entities and events between entities, the pattern graph indicating patterns of computing resource activities to be identified in the time graph, wherein application of the filter to the pattern graph creates a second vector representation; comparing, by the data processing system, the second vector representation to the one or more first vector representations to identify one or more nearby vectors in the one or more first vector representations; as well as outputting, by the data processing system, one or more subgraph instances corresponding to the identified one or more nearby vectors to an intelligence console computing system as an inexact match of the time graph, Wherein, applying the filter to the time graph to generate one or more first vector representations includes: when the filter is moved along the selected entity in the time graph from a previous time point for performing embedding to a second time point for performing current embedding, generating the one or more first vector representations of the moving window for the range of time points of the moving window corresponding to the filter.

2. The method of claim 1, wherein the intelligence console computing system is a cybersecurity intelligence center, and wherein the one or more proximity vectors represent potential computer attacks on the one or more computing devices.

3. The method according to claim 1 further includes training at least one graph neural network (GNN) based on a training data set to perform vector embedding of the attributes of the nodes and edges of the input graph to generate a vector output corresponding to the attributes of the nodes and edges of the input graph, and wherein applying the filter to the time graph includes executing at least one trained GNN on the time graph as the input graph, and wherein applying the filter to the pattern graph includes executing at least one trained GNN on the pattern graph as the input graph.

4. A method according to claim 3, wherein the training data set includes one or more known activity graphs corresponding to activities performed by a set of known computing elements, at least one known pattern graph corresponding to at least one known activity pattern of interest, and an indication of a correct vector output or classification generated by the at least one GNN based on the one or more known activity graphs and the at least one known pattern graph as input to the at least one GNN.

5. The method of claim 3 , wherein the at least one GNN comprises a plurality of GNNs, each GNN having a corresponding filter of a different size, and wherein applying the filter to the temporal graph and applying the filter to the pattern graph comprises executing a GNN selected from the plurality of GNNs having a corresponding filter whose size corresponds to the size of the pattern graph.

6. A method according to claim 1, wherein the filter has a first dimension and a second dimension, the first dimension corresponding to a reachability limit indicating the distance of a node within the moving window away from a first node within the moving window, and the second dimension corresponding to a time range of events within the moving window starting from a time point corresponding to a center time point of the moving window.

7. A method according to claim 1, wherein applying the filter to the time graph also includes storing a mapping of the portions represented by the one or more first vectors to attributes of the nodes and edges in the moving window, and wherein outputting the one or more subgraph instances corresponding to the identified one or more nearby vectors includes converting the one or more nearby vectors to corresponding subgraph instances in the one or more subgraph instances based on the stored mapping.

8. A method according to claim 1, wherein comparing the second vector representation with the one or more first vector representations to identify one or more nearby vectors in the one or more first vector representations includes identifying the one or more nearby vectors based on an inexact match of the second vector representation with a portion of the one or more first vector representations, thereby identifying the one or more nearby vectors.

9. The method of claim 1 , wherein comparing the second vector representation to the one or more first vector representations to identify the one or more nearby vectors in the one or more first vector representations comprises: For each first vector representation of the one or more first vector representations: performing a vector distance-based comparison of the second vector representation with the first vector representation to generate a similarity measure corresponding to the first vector representation; comparing the similarity measure to a threshold similarity measure to determine whether the first vector representation represents a nearby vector; as well as In response to the similarity measure having a predetermined relationship relative to the threshold similarity measure, the first vector representation is returned as a nearby vector.

10. The method according to claim 1, wherein: When the time map changes dynamically over time, the method is performed dynamically.

11. A computer program product comprising a computer-readable storage medium having a computer-readable program stored therein, wherein: When the computer readable program is executed on a data processing system, it causes the data processing system to: receiving activity data characterizing activity of a computer system element from one or more computing devices of a monitored computing environment; generating a temporal graph of the activity data, wherein the temporal graph includes nodes representing the computer system elements and edges connecting the nodes, wherein each edge represents an event occurring between the computer system elements represented by the nodes connected by the edge; applying a filter to the temporal graph to generate one or more first vector representations, each vector representation characterizing nodes and edges within a moving window defined by the filter; applying the filter to a pattern graph, the pattern graph representing patterns of entities and events between entities, the pattern graph indicating patterns of computing resource activities to be identified in the time graph, wherein application of the filter to the pattern graph creates a second vector representation; comparing the second vector representation to the one or more first vector representations to identify one or more nearby vectors in the one or more first vector representations; as well as outputting, by the data processing system, one or more subgraph instances corresponding to the identified one or more nearby vectors to an intelligence console computing system as an inexact match of the temporal graph, Wherein, applying the filter to the time graph to generate one or more first vector representations includes: when the filter is moved along the selected entity in the time graph from a previous time point for performing embedding to a second time point for performing current embedding, generating the one or more first vector representations of the moving window for the range of time points of the moving window corresponding to the filter.

12. The computer program product of claim 11, wherein the intelligence console computing system is a cybersecurity intelligence center, and wherein the one or more vicinity vectors represent potential computer attacks on the one or more computing devices.

13. A computer program product according to claim 11, wherein the computer-readable program further causes the data processing system to train at least one graph neural network (GNN) based on a training data set to perform vector embedding of attributes of the nodes and edges of the input graph to generate vector outputs corresponding to the attributes of the nodes and edges of the input graph, and wherein applying the filter to the temporal graph comprises executing at least one trained GNN on the temporal graph as the input graph, and wherein applying the filter to the pattern graph comprises executing at least one trained GNN on the pattern graph as the input graph.

14. A computer program product according to claim 13, wherein the training data set includes one or more known activity graphs corresponding to activities performed by a set of known computing elements, at least one known pattern graph corresponding to at least one known activity pattern of interest, and an indication of a correct vector output or classification generated by the at least one GNN based on the one or more known activity graphs and the at least one known pattern graph as input to the at least one GNN.

15. The computer program product of claim 13, wherein the at least one GNN comprises a plurality of GNNs, each GNN having a corresponding filter of a different size, and applying the filter to the temporal graph and applying the filter to the pattern graph comprises executing a GNN selected from the plurality of GNNs having a corresponding filter whose size corresponds to a size of the pattern graph.

16. A computer program product according to claim 11, wherein the filter has a first dimension and a second dimension, the first dimension corresponding to a reachability limit indicating the distance of a node within the moving window away from a first node within the moving window, and the second dimension corresponding to a time range of events within the moving window starting from a time point corresponding to a center time point of the moving window.

17. A computer program product according to claim 11, wherein the computer-readable program further causes the data processing system to apply the filter to the time graph at least by storing a mapping of the portions represented by the one or more first vectors to the attributes of the nodes and edges in the moving window, and wherein the computer-readable program further causes the data processing system to output the one or more subgraph instances corresponding to the identified one or more nearby vectors at least by converting the one or more nearby vectors to corresponding subgraph instances in the one or more subgraph instances based on the stored mapping.

18. A computer program product according to claim 11, wherein the computer readable program further causes the data processing system to compare the second vector representation with the one or more first vector representations to identify one or more nearby vectors in the one or more first vector representations, thereby identifying the one or more nearby vectors by at least identifying the one or more nearby vectors based on an inexact match of the second vector representation with a portion of the one or more first vector representations.

19. The computer program product of claim 11, wherein the computer readable program further causes the data processing system to compare the second vector representation with the one or more first vector representations to identify the one or more nearby vectors in the one or more first vector representations by at least performing the following operations for each of the one or more first vector representations: performing a vector distance-based comparison of the second vector representation with the first vector representation to generate a similarity measure corresponding to the first vector representation; comparing the similarity measure to a threshold similarity measure to determine whether the first vector representation represents a nearby vector; and In response to the similarity measure having a predetermined relationship relative to the threshold similarity measure, the first vector representation is returned as a nearby vector.

20. A device comprising: processor; as well as A memory coupled to the processor, wherein the memory includes instructions that, when executed by the processor, specifically configure the processor to implement an inexact graph pattern matching mechanism, wherein the inexact graph pattern matching mechanism operates to execute the method of any one of claims 1 to 10.

Images