Method and system for interpreting and filtering network security alerts

By applying mixed methods and ontology on the knowledge graph, generating and linguistic interpretation, the problems of flooding and lack of interpretability in existing intrusion detection systems are solved, and the interpretability and quality of alarms are improved.

CN119654637APending Publication Date: 2025-03-18SIEMENS AG
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
CN202380057313.8
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2022-07-28
Filing Date
2023-07-24
Publication Date
2025-03-18

AI Technical Summary

Technical Problem

Existing intrusion detection systems have problems with flooding of alarms and lack of interpretability when dealing with cybersecurity alerts, making it difficult to provide analysts with clear explanations and context.

Method used

By combining symbol and sub-symbol algorithms on the knowledge graph, using a hybrid approach, combining domain-specific data, generating interpretations using ontology and anomaly detection components, filtering false positive alerts, and linguistic interpretations to improve interpretability.

Benefits of technology

Improves the interpretability and quality of the alarms generated by IDS, reduces the workload and time of analyst evaluation, filters out most false positive alarms, and solves the alarm flooding problem.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119654637A_ABST
    Figure CN119654637A_ABST
Patent Text Reader

Abstract

An observed network communication event is represented as an edge in a knowledge graph (G) and processed by an anomaly detection component (AD), generating an alert for that event if its likelihood is below a threshold. An interpretation generation component (EG) generates an interpretation for some alerts. A filter component (FFP) removes an alert that no interpretation thereof is generated. A linguistizer (V) linguistizes an interpretation for the generation of the at least one remaining alert. Preferred embodiments employ a hybrid approach by combining symbolic and sub-symbolic algorithms on a knowledge graph in order to improve the interpretability and quality of IDS generated alarms in modern industrial systems, increasing their usefulness to analysts. An interpretable AI (XAI), i.e. The interpretability of the AI algorithm, enables analysts to understand how the system draws their conclusions and may allow them to interact therewith in a cooperative manner. In addition, most false positives can be filtered out through interpretation availability, and therefore the problem of alarm flooding is solved. Combining these two aspects, the reduction of checked cases along with expressive interpretation of remaining alarms, greatly reduces the total time and workload of analysts to assess the output of the intrusion detection system.
Need to check novelty before this filing date? Find Prior Art

Description

Background Art

[0001] The continued growth of cyberattacks has led to a growing demand for modern intrusion detection methods that leverage machine learning (ML) to detect both simple security risks as well as complex cyberattacks. These methods identify patterns in the data and highlight anomalies that correspond to attacks. This detection task is particularly conducive to the ability to automatically analyze and learn from large amounts of data. There are many relevant examples of applying deep learning and similar techniques to intrusion detection systems (IDS) based on anomaly detection algorithms that are able to find deviations from a previously learned baseline.

[0002] This is relevant not only to the defense of traditional IT systems, but also to modern operational technology (OT) systems, such as those used in factories and other industrial automation settings. While these industrial control systems used to be exclusively deterministic in their operations, modern Industry 4.0 automation settings are characterized by the convergence of IT and OT infrastructures. This convergence is accompanied by increasingly complex activity patterns and network topologies that make extensive use of autonomous systems and components, such as AI-enabled software applications. While this has the potential to greatly improve the flexibility, reliability, and efficiency of industrial systems and consumer-facing manufacturing, it also introduces new cybersecurity challenges and also requires a high degree of domain-specific knowledge from analysts when evaluating potential integrity issues or indicators of security compromise. Summary of the invention

[0003] An object of the present invention is to identify a problem in the prior art and to find a technical solution to this problem.

[0004] The objects of the invention are solved by the independent claims. Further advantageous arrangements and embodiments of the invention are set forth in the respective dependent claims.

[0005] According to a method for interpreting and filtering network security alerts, the following operations are performed by a component, wherein the component is a hardware component and / or a software component executed by one or more processors: -Store a knowledge graph in a database, including information about: - a technical system, in particular an industrial automation system, according to a first aspect, wherein at least some nodes of the knowledge graph represent entities of the technical system and the edges of the knowledge graph represent different types of relations between these entities, - observed network communication events between entities of the technical system according to the second aspect, represented as edges in a knowledge graph, - a likelihood of each event is calculated by an anomaly detection component by performing link prediction for the edges in the knowledge graph representing the event, and an alert is generated for the event if its likelihood is below a threshold, - generating explanations for some alerts by an explanation generation component processing the ontology and the inputs and outputs of the anomaly detection component by using the ontology to create explainer classes, wherein each explainer class indicates what input to the anomaly detection component may result in what output, wherein an explanation is generated for an alert if an OWL reasoner processing the ontology concludes that one of the explainer classes is applicable to the alert, - removing alerts for which no explanations have been generated by the filter component, and - verbalizing, by a verbalizer, the generated interpretation of at least one of the remaining alarms.

[0006] The system for interpreting and filtering network security alerts includes the following components: - A database that stores the knowledge graph, including information about: - a technical system, in particular an industrial automation system, according to the first aspect, wherein at least some nodes of the knowledge graph represent entities of the technical system and the edges of the knowledge graph represent different types of relations between these entities, and - observed network communication events between entities of a technical system, represented as edges in a knowledge graph, according to the second aspect, an anomaly detection component configured to compute the likelihood of each event by performing link prediction for edges in a knowledge graph representing the event, and generating an alert for the event if its likelihood is below a threshold, an explanation generation component configured to process the ontology and the inputs and outputs of the anomaly detection component and to generate explanations for some of the alerts by creating explainer classes using the ontology, wherein each explainer class indicates what input to the anomaly detection component may result in what output, wherein an explanation is generated for the alert if an OWL reasoner processing the ontology concludes that one of the explainer classes is applicable to the alert, - a filter component configured to remove alerts for which no explanation has been generated, and - a verbalizer configured to verbalize the generated interpretation of at least one of the remaining alarms.

[0007] The following advantages and explanations are not necessarily the result of the object of the independent claims. Instead, they may be advantages and explanations that apply only to certain embodiments or variants.

[0008] In conjunction with the present invention, unless otherwise specified in the specification, the terms "training", "generation", "computer-assisted", "computing", "determination", "inference", "retraining" and the like preferably relate to actions and / or processes and / or processing steps of changing and / or generating data and / or converting data into other data, wherein the data is particularly or can be represented as physical quantities, such as electrical pulses.

[0009] The term "computer" should be interpreted as broadly as possible and in particular covers all electronic devices with data processing properties. Thus, a computer may be, for example, a personal computer, a server, a client, a programmable logic controller (PLC), a handheld computer system, a palmtop PC device, a mobile radio device, a smartphone, a device capable of processing data with the support of a computer or any other communication device, a processor for data processing and other electronic devices. A computer may in particular comprise one or more processors and a memory unit.

[0010] In conjunction with the present invention, a "memory", "memory unit" or "memory module" etc. may refer to a volatile memory in the form of, for example, a random access memory (RAM) or a permanent memory such as a hard disk or magnetic disk.

[0011] One possible example of a cyberattack in an OT system is a security vulnerability. Such a security vulnerability could be a network host that should remain in a local network connected to the internet, or a developer host that directly accesses an edge device. In the latter case, for a binary output, a connection of the form "192.168.0.80 to 192.168.0.17" would be marked as suspicious by the machine learning model. This provides the analyst with very little information about what happened and requires further in-depth analysis. The explanation for the anomaly "the security vulnerability is something whose connection receives services via SSH" given by at least some embodiments shows that edge devices are not typically the source or destination of SSH connections, and why the connection is marked as suspicious.

[0012] The method and system, or at least some of their embodiments, adopt a hybrid approach by combining symbolic and sub-symbolic algorithms on a knowledge graph in order to improve the interpretability and quality of alerts generated by IDS in modern industrial systems and increase their usefulness to analysts. This is achieved by integrating domain-specific data, which enables the system to better contextualize and enrich cybersecurity-related observations while allowing sub-symbolic machine learning components (e.g., GNNs) to exploit this additional context, i.e., learn from these observations in a way that exploits the rich set of interconnections and relationships between different entities in the graph. Similar to other connectionist models, GNNs lack transparency in the decisions they make. Since such sub-symbolic models are built for AI researchers, they are often difficult to understand for non-experts. The method and system, or at least some of their embodiments, justify predictions that exploit background knowledge in a human-understandable way by adopting a hybrid approach.

[0013] The shortcomings of existing intrusion detection systems include the alarm flooding problem and the lack of explainability, for example, why certain network traffic is marked as abnormal by the IDS.

[0014] The methods and systems, or at least some embodiments thereof, provide explainable AI (XAI) - that is, the interpretability of AI algorithms - which enables analysts to understand how the system reaches its conclusions and potentially allows them to interact with it in a collaborative way. One of the biggest drivers for the successful adoption of machine learning models is the level of understanding and trust that human users have in their functionality. The benefits provided by explanations are only fully apparent when explanations are human-centric and users can understand and potentially interact with them. This is particularly important in the field of cybersecurity, where experts need much more information from a model than a simple binary output to analyze.

[0015] The method and system, or at least some of their embodiments, help overcome the above problems by improving the interpretability and quality of alerts generated by IDS in modern industrial systems, increasing their usefulness to analysts. In addition, through the availability of explanations, most false positives can be filtered out, thereby solving the alarm flooding problem.

[0016] The method and system, or at least some of their embodiments, supplement the alarms detected by the anomaly detection component with explicit explanations that help the system analyst understand why the alarm was reported. These explanations can provide context for the situation in which the alarm occurred by relating the alarm to other entities in the underlying knowledge representation, such as in terms of communication events and system states, saving the analyst time in looking up this context from the log data. Here, the ontology-based knowledge graph representation ensures that the explanations are expressed in a vocabulary familiar to the analyst.

[0017] The method and system, or at least some embodiments thereof, also provide a mechanism for filtering out false positive alarms, which significantly reduces the number of alarms that an analyst must examine and judge by manually looking up their details.

[0018] These two aspects combined, i.e., the reduction of cases reviewed together with the expressive explanation of the remaining alerts, significantly reduce the overall time and effort of the analyst in evaluating the output of the intrusion detection system.

[0019] In an embodiment of the method and system, each explanation provides context for the circumstances under which the corresponding alert occurred by relating it to other entities in the knowledge graph.

[0020] In another embodiment of the method and system, the anomaly detection component is implemented based on the RESCAL algorithm, the TransE algorithm, the DistMult algorithm or a graph neural network, in particular a graph convolutional neural network.

[0021] In one embodiment of the method, the anomaly detection component is a graph neural network. The generating operation includes generating, for each alert, a sub-symbol interpretation, in particular a sub-graph of a knowledge graph, which is used to calculate a fidelity score with respect to a corresponding interpreter class by determining an overlap of the sub-symbol interpretation and the interpreter class. If the fidelity score of the alert is below a threshold, the alert is removed.

[0022] In another embodiment of the method and system, according to the third aspect, the knowledge graph further comprises information about events observed at the application level (particularly data access events), which are represented as edges in the knowledge graph.

[0023] An embodiment of the method includes the following initial operations: creating and / or continuously updating a knowledge graph by ingesting information about: technical systems from engineering tools, particularly in an automated ML format, network communications observed from security monitoring tools, and behavior observed at the application level by processing server logs.

[0024] In one embodiment of the method, at least some of the information is ingested into a knowledge graph using an ontology expressed in the W3C OWL2 standard based on a description logic formalism.

[0025] An embodiment of the method comprises the following additional initial operations: creation and / or continuous updating of an ontology by an ontology creation component processing the knowledge graph, in particular by using a class hierarchy dividing the technical system into an automation part according to the first aspect, a network part according to the second aspect and an edge part according to the third aspect.

[0026] In another embodiment of the method, the automation part contains in particular classes for structures, elements and interfaces of technical systems. The network part contains in particular classes for IP, individual networks and network connections and their properties. The edge part contains in particular classes for initialization events and data events at the application level.

[0027] The computer program product comprises instructions which, when the program is executed by a computer, cause the computer to perform the method.

[0028] The supply device stores and / or provides the computer program product. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The foregoing and other aspects of the invention can be best understood from the following detailed description when read in conjunction with the accompanying drawings. For the purpose of illustrating the invention, presently preferred embodiments are shown in the accompanying drawings, however, it should be understood that the invention is not limited to the specific means disclosed. The embodiments may be combined with each other. In addition, the embodiments may be combined with any of the above-mentioned features. Unless otherwise specified, the same reference numerals between the drawings represent the same features or functionally the same elements. The following figures are included in the drawings: Figure 1A first embodiment is shown, Figure 2 Another embodiment is shown, Figure 3 shows a framework for interpreting and filtering network security alerts, Figure 4 shows an example of an industrial automation system, Figure 5 shows a knowledge graph G that integrates three main sources of knowledge about automation systems, Figure 6 shows an explanation subgraph for marking a data event as suspicious, and Figure 7 A flow chart of a possible exemplary embodiment of a method for interpreting and filtering network security alerts is shown. DETAILED DESCRIPTION

[0030] In the following description, various aspects of the present invention and its embodiments will be described. However, it will be appreciated by those skilled in the art that embodiments may be practiced with only some or all of them. For purposes of explanation, specific numbers and configurations are set forth to provide a thorough understanding. However, it will be apparent to those skilled in the art that embodiments may be implemented without these specific details.

[0031] The components described may all be hardware components or software components. For example, a software component may be a software module such as a software library; a separate procedure, subroutine or function; or, depending on the programming paradigm, any other portion of software code that implements the functionality of a software component. In particular, a combination of hardware components and software components may occur if some effects according to the invention are preferably implemented exclusively by dedicated hardware (e.g., a processor in the form of an ASIC or FPGA) and some other parts are implemented by software.

[0032] Figure 1 A sample structure of a computer implementation of the present invention is shown, comprising: (101) Computer system (102) Processor (103) Memory (104) Computer program (product) (105)User interface.

[0033] In this embodiment of the invention, the computer program 104 comprises program instructions for carrying out the invention. The computer program 104 is stored in the memory 103, which among other things makes the memory and / or its associated computer system 101 a supply device for the computer program 104. The system 101 can implement the invention by executing the program instructions of the computer program 104 by the processor 102. The results of the invention can be presented on the user interface 105. Alternatively, they can be stored in the memory 103 or on another suitable device for storing data.

[0034] Figure 2 Another sample structure of a computer implementation of the present invention is shown, comprising: (201)Supply of equipment (202) Computer program (product) (203) Computer Network / Internet (204) Computer system (205)Mobile device / smart phone.

[0035] In this embodiment, a supply device 201 stores a computer program 202, which includes program instructions for implementing the present invention. The supply device 201 provides the computer program 202 via a computer network / Internet 203. For example, a computer system 204 or a mobile device / smartphone 205 can load the computer program 202 and implement the present invention by executing the program instructions of the computer program 202.

[0036] In a variation of this embodiment, the supply device 201 is a computer-readable storage medium, such as an SD card, which stores the computer program 202 and is directly connected to the computer system 204 or the mobile device / smartphone 205 so that it loads the computer program and implements the present invention by executing the program instructions of the computer program 202.

[0037] Preferably, Figures 3 to 7 The embodiment shown can be used as Figure 1 or Figure 2 The structure shown is implemented.

[0038] Ying, R., Bourgeois, D., You, J., Zitnik, M., and Leskovec, J., Gnnexplainer: Generating explanations for Graph Neural Networks, Advances in neural information processing systems, 32, p. 9240, 2019, discloses GNNexplainer, a tool for generating explanations for graph neural networks. In order to take into account node feature information, the model-agnostic method GNNExplainer finds the subgraph of the input data that affects the GNN prediction in the most significant way by maximizing the mutual information between the subgraph and the model prediction. The entire content of this document is incorporated herein by reference.

[0039] GNNExplainer is a sub-symbolic explainer component because the discovered subgraphs are not in a high-level symbolic (human-readable) representation.

[0040] Lehmann, J., 2009, DL-Learner: learning concepts in description logics, The Journal of Machine Learning Research, 10, pp. 2639-2642, discloses DL-Learner, a tool for learning concepts in description logics. The entire content of this document is incorporated herein by reference.

[0041] Himmelhuber, A., Grimm, S., Zillner, S., Joblin, M., Ringsquandl, M., and Runkier, T., Combining Sub-symbolic and Symbolic Methods for Explainability, in International Joint Conference on Rules and Reasoning, p. 172-187, Springer, Cham, 2021, discloses creating and verifying explanations for GNN decisions by using inductive logic learning, and calculating fidelity scores by adopting a hybrid approach that combines sub-symbolic and symbolic algorithm / AI components for interpretability. The entire content of this document is incorporated herein by reference and is named "hybrid approach" throughout the specification.

[0042] At least some of the following embodiments describe a framework, including: - ontology creation that follows the separation of industrial automation systems into three domains (e.g., static information about industrial automation systems, observed network communications, and observed behaviors at the application level) in accordance with a structured language for cyber threat intelligence, - adopting a hybrid approach to create and validate explanations for security alerts by using inductive logic learning, and - Explanations are verbalized using a state-of-the-art verbalization framework for increased user-friendliness.

[0043] With the availability of explanations, most of the false positives can be filtered out, thus alleviating the frequent alert flooding problem.

[0044] For the embodiments described below, it is assumed that there is a technical system, such as an industrial automation system such as a production plant, whose operation utilizes network communication with the outside world (e.g., outside the production plant) and may therefore be subject to security attacks. The technical system is accompanied by an anomaly detection component (e.g., a traditional intrusion detection system, IDS), which observes the network communication traffic and detects anomalies, which in principle can be evaluated by a system analyst (but are further processed and enriched by explanation in the following embodiments).

[0045] Figure 3 A high-level workflow of an interpretation and filtering framework for network security alerts is shown, which is the basis for the embodiments described below.

[0046] The industrial automation system IAS is reflected in a knowledge graph G, wherein at least some nodes of the knowledge graph G represent entities of the industrial automation system IAS, and the edges of the knowledge graph represent different types of relationships between these entities, and wherein observed network communication events are represented as edges in the knowledge graph G.

[0047] Based on the knowledge graph G, the anomaly detection component AD captures security issues and generates corresponding alerts. This is achieved by performing link prediction on the edges in the knowledge graph G representing events to calculate the likelihood of each event, and if its likelihood is lower than a threshold, an alert is generated for the event.

[0048] The ontology creation component OC creates and / or updates an ontology based on the knowledge graph G, in particular by using a class hierarchy that divides the industrial automation system into an automation part, a network part and an edge part. To this end, the ontology creation component OC may also directly access the industrial automation system IAS.

[0049] The explanation generation component EG processes the ontology and the input and output of the anomaly detection component AD, and uses the ontology to create interpreter classes to generate explanations for some alerts, where each interpreter class indicates what input to the anomaly detection component AD can lead to what output, and if the OWL reasoner processing the ontology concludes that one of the interpreter classes is applicable to the alert, an explanation for the alert is generated.

[0050] The filter component FFP removes at least some false positives in the generated alarms by discarding alarms without explanations, using the generated explanations as filtering criteria.

[0051] The verbalizer V verbalizes at least one generated explanation of the remaining alarms. In the interpreting the remaining alarms step ERA, the Figure 1 The user interface shown outputs the verbalized interpretation as text or speech.

[0052] At least some embodiments of the method and system are drawn from a hybrid approach, where the anomaly detection component AD is a graph neural network (GNN). The ontology creation component OC contributes to the explanation generation component EG with the help of a DL-Learner. The explanation generation component EG uses a GNNExplainer to process the results of the anomaly detection component AD.

[0053] However, other embodiments of the method and system operate without hybrid methods and / or without graph neural networks. In particular, the anomaly detection component AD can be implemented as any kind of learning component suitable for link prediction in a knowledge graph. EP 4030351 AI describes the implementation of such a learning component in detail and mentions in this regard direct push algorithms, such as RESCAL, TransE or DistMult, as well as inductive algorithms. The entire content of this document is incorporated herein by reference.

[0054] Those embodiments of methods and systems drawn from hybrid approaches couple a sub-symbolic interpreter component GNNExplainer with a symbolic DL-Learner component to explain GNN instance-level link predictions. First, a GNN acting as an anomaly detection component AD is trained and applied to training and test data, followed by the application of the sub-symbolic interpreter component GNNExplainer, which outputs an interpreter subgraph. Secondly, to create an interpreter class for the GNN decision process, a DL-Learner is applied to a specific prediction class, whose positive and negative examples are labeled accordingly. An interpreter class is a description that represents a set of individuals by formally specifying conditions on their properties. It captures the global behavior of a GNN by studying what input patterns can lead to specific predictions. Since DL-Learner can only process ontologies, background knowledge is mapped to ontologies.

[0055] Those embodiments of the methods and systems drawn from the hybrid approach use a pool of possible interpreter classes created by a DL-Learner to generate instance-level explanations through interpreter class entailment. Given an ontology and derivable by a standard OWL reasoner, an interpreter class entailment is given when the interpreter class is applicable to a certain alert. Or in other words, if the overall decision pattern of the learned GNN is applicable to a specific alert, an interpreter class is required. To increase credibility, the fidelity of each explanation is given. Fidelity is defined as a measure of the accuracy of the student model (DL-Learner) relative to the teacher model (GNN). Therefore, high fidelity is essential whenever a student model is claimed to provide a good explanation for the teacher model. In the absence of high fidelity, the apparently perfect explanation produced by the interpretable system is likely not an explanation of the underlying sub-symbolic system it is expected to explain.

[0056] The fidelity metric used to compute fidelity is defined as the overlap of the subsymbolic interpreter output with the implied interpreter class. The interpreter class is represented by axioms, e.g., "a sniff is something whose data event client is App4 and whose data event variable has a data type that is not real."

[0057] The denominator is equal to the count of edge or node feature sets that must be part of the subgraph contained by the implications of the interpreter class. For the numerator, the current embodiment counts the overlap of the identified set of individuals with individuals in the subgraph identified by the subsymbolic interpreter component GNNExplainer.

[0058] In other words, the hybrid approach ensures the credibility of the explanation by including sub-symbolic explanation elements. Therefore, a fidelity measure can be given, which shows how close the explanation is to the actual decision process of the machine learning algorithm (GNN).

[0059] The following is a more detailed explanation of the Figure 3 Various embodiments of portions of the workflow are shown.

[0060] Industrial Automation Systems Figure 4 An industrial automation system (more specifically, a demonstrator for testing) consisting of an automation part, a development environment, and an industrial edge is shown. The industrial automation system can be used to measure the height of an object for quality control among other capabilities, following the design of modern industrial systems that integrate IT and OT elements. The automation side is equipped with a programmable logic controller (PLC) that is connected to peripheral devices via an industrial network. These include a drive subsystem that controls the movement of a conveyor belt, an industrial camera, a human-machine interface, and a distributed I / O subsystem with modules that interface with various sensors for object positioning and other measurements ( Figure 4 , left). The PLC exposes the values ​​reported by these sensors and information about the system status through an OPC-UA server. The variables exposed by the server are hosted on an edge computing server ( Figure 4 , lower right), edge computing servers are computing infrastructure located directly on the factory floor, which are usually dedicated to data-driven tasks that require tight integration with automation systems and short response times, such as real-time system monitoring, fault prediction, or production optimization. Industrial edge applications have a dynamic life cycle, and this is achieved by recreating the development environment ( Figure 4 , top right) captured in the prototype. The cycle starts with the development host consuming potentially large amounts of data from a historian, a database that continuously stores process data from the automation system. Finally, the edge computing host periodically fetches application updates. To make the behavior more realistic, the development host occasionally accesses the internet with low traffic.

[0061] The environment of the industrial automation system is fully virtualized and these activities are performed in an autonomous manner, with the option to manually induce different types of abnormal behavior in order to test the response of the IDS system according to the current embodiment.

[0062] Knowledge Graph Figure 5 A multi-relation graph is shown, which is a knowledge graph G. The knowledge graph G is constructed by integrating three main sources of knowledge: Figure 4 Information about industrial automation systems, network-level observations (e.g., connections between hosts), and application-level observations (e.g., data access events) are shown. A significant portion of the information is related to industrial automation systems, which is extracted from engineering tools in an automated ML format and ingested into the knowledge graph G using ontologies. Information about application activity is obtained from server logs, including session information, i.e., which variables are accessed and in what way. Finally, all network traffic passes through a security monitoring tool, which produces a flow of observed connections, which is ingested into the knowledge graph G using a simple custom data model.

[0063] A knowledge graph G is a specific type of knowledge base in which information is encoded in the form of a directed labeled graph, with nodes representing entities and edges representing different types of possible relationships between entities. Knowledge graphs are particularly useful structures for integrating data from multiple knowledge domains, typically using domain-specific vocabularies and ontologies that model different categories, relationships, rules, and constraints in a specific knowledge area. In order to incorporate explicit domain knowledge into the knowledge graph G on the symbolic representation side, an ontology expressed in the W3C OWL 2 standard based on a description logic form can be used. The basic elements for representing knowledge in OWL are individuals, classes, and properties. They are used to form axioms, i.e., statements within the target domain, and an ontology is a set of axioms that describe what holds true in that domain. The most relevant axioms for the current embodiment are the class assertion c(a) that assigns individual a to class c, the property assertion r(a1, a2) that connects two individuals a1 and a2 through property r, and the subclass axiom that indicates that class c1 is a subclass of class c2 Classes can be atomic class names, such as "Appl", or they can consist of complex class expressions. An example of a complex class expression mentioned in Manchester syntax is "UAVariable and hasDataType byte", which refers to all UA variables with data type byte.

[0064] Anomaly Detection Component As mentioned above, there are various alternatives and embodiments for implementing the anomaly detection component, such as those described in EP4030351 A1.

[0065] This use of machine learning methods is possible on knowledge graphs, typically through so-called graph embeddings: vector representations of graph entities that are more suitable for processing by neural networks and similar algorithms than their raw symbolic representations. This kind of relational learning on knowledge graphs is applied to security monitoring and intrusion detection by mapping events in industrial automation systems to links in knowledge graphs. In this way, the anomaly detection task can be reformulated as a link prediction task in the knowledge graph representation of the modeled industrial automation system. The collective learning nature of graph embedding algorithms allows the resulting models to generalize beyond a single observation, benefiting from the context provided by a rich set of entity and relation types.

[0066] In those embodiments of the methods and systems drawn from the hybrid approach, anomaly detection is performed by a graph neural network (GNN), in other words, the GNN is used to detect unexpected activities in industrial automation systems. These embodiments adopt a two-step process: (1) learning a baseline of normal behavior by training the GNN on a knowledge graph built from a training dataset, and (2) applying the GNN in a link prediction setting to rank the likelihood of triple statements generated by events observed at test time and determine whether they represent anomalies. Triple statements are also discussed in detail in EP 4030351 A1.

[0067] GNNs usually consist of a graph convolution layer that extracts local substructure features of individual nodes and a graph aggregation layer that aggregates node-level features into a graph-level feature vector.

[0068] Initially, a baseline is captured with an industrial automation system under normal operating conditions, and the collected data is used to train a link prediction algorithm in an unsupervised manner (GNN or any other appropriate learning component, see EP 4030351 A1, performed as an anomaly detection component). Thereafter, in order to qualitatively evaluate the predictions, a set of actions can be triggered that result in events that are not observed during normal operation but to which a wide range of severity levels will be assigned by human experts after a detailed analysis of the available contextual information. According to the baseline definition, suspicious behavior is novel behavior. The scenarios are defined according to the ATT and CK framework for industrial control systems, i.e., a standardized set of cyber attack patterns, to ensure a high degree of authenticity. The scenarios adopted are listed below:

[0069] Scenario description App Activities 1.1 The app changed the way it accessed some variables (e.g., writing instead of reading).

[0070] 1.2 The application accesses variables that are completely unrelated to those normally accessed.

[0071] Network activity (HTTPS) 2.1 The local address that does not correspond to the dev. host (e.g., edge server) accesses the history database.

[0072] 2.2 Access to public IP addresses that do not correspond to local addresses of dev. hosts (e.g., edge servers).

[0073] 2.3 A large number of HTTP accesses to public IP addresses (a large number comes only from the historical database in the baseline).

[0074] Network activity (SSH) 3.1 The history database host (not the dev. host, but on the same network) accesses the application repository via SSH.

[0075] 3.2dev. The host accesses the edge server via SSH, but during training, no edge server receives SSH connections.

[0076] 3.3 SSH connection between two edge servers. Usually no edge server initiates or receives SSH connections.

[0077] Certificate Usage 4.1 Access the OPC-UA server from the IP address corresponding to the development host.

[0078] Network Scanning 5.1 connection, which does not match any of the source-destination pairs that are normally observed.

[0079] 5.2 Try to connect to an IP that is not assigned to any host.

[0080] One example is sniffing, where the application accesses data variables that are completely unrelated to those normally accessed (scenario 1.2), e.g. not served by the PLC, or have a different data type, such as a string instead of a numeric data type like integer, real, etc. This could be an event to extract system information such as a device serial number or firmware version, which is information useful for discovering backdoors and vulnerabilities in a system.

[0081] Ontology creation component The analysis of security events often requires the consideration of multiple data sources, some of which are frequently exchanged between organizations. To facilitate this, common schemas and data representation formats have been introduced that enable organizations to exchange threat intelligence in a consistent manner. Recently, these have evolved into fully fledged ontologies capable of inference and reasoning. These ontologies model a wide range of cybersecurity-related knowledge, such as product information, known vulnerabilities and attack patterns, and can additionally be linked to domain-specific knowledge, such as knowledge from industrial automation systems. Once constructed, these knowledge graphs find a wide range of applications, such as intrusion and threat detection.

[0082] Building a high-quality knowledge graph is a challenging task, especially when it requires extracting information from unstructured text or heterogeneous data.

[0083] Those embodiments of methods and systems drawn from the hybrid approach use DL-Learner as input to the explanation generation component. However, the use of DL-Learner requires those embodiments to first convert the knowledge graph into an ontology, which is performed by the ontology creation component. Here, a class hierarchy that follows the division of industrial automation systems into three domains is adopted:

[0084] - Automation section: summarizes the engineering design of industrial automation systems. It is further divided into internal structure (Internal structure), including internal elements (Internal Elements), external interfaces (External Interfaces), attributes (Attributes) and internal links (Internal Links) as subclasses, and UA variables, including PLC tags (PLC tags) and attributes as subclasses.

[0085] - Network section: contains network connections and their properties as subclasses, and IPs and their subdomains with local and global as well as automation, development, and edge networks as subclasses.

[0086] -Edge part: includes application initialization events, data events and applications.

[0087] For relations, domain and scope are provided. In order for DL-Learner to be able to use properties (such as network connection properties), these properties must be promoted to classes, for example, each possible instance of a network volume is its own class. This embodiment also applies to applications, internal components and external interfaces, network types (Dev Network, etc.) and attributes.

[0088] Explanation Generation Tools specifically designed to handle tasks related to malicious behavior detection generally tend to focus more on events or observations that are considered unexpected or abnormal. Similarly, in the current embodiment of identifying anomaly types, detected unexpected events are used as triggers for interpretation. For testing, events for specific devices (e.g., activity of a specific application, or a network connection between two specific IPs) are compared to each other based on severity classes. For example, suspicious classes against a baseline. The current embodiment achieves this by using model predictions, based on an ordered list with suspiciousness scores. Thus, for example, the top entries can be compared to compatible baseline events. This is how positive and negative examples are generated for the DL-Learner, which generates class expressions such as

[0089] To increase user-friendliness, the class expression is further linguisticated, for example using the state-of-the-art LD2NL framework. Through the linguistic step, the above example of the class expression of the class sniff is transformed into "sniff is something whose data event client is App4 and whose data event variable has a data type that is not data type real".

[0090] The following list shows a selection of interpretations, along with their verbalization and correspondence to sub-scenarios: Interpreter Class (dataevent_client some App5)and(dataevent_operation some WriteOp) →Attack Scenario 1.1 Language The sniff is something whose data event client is App5 and whose data event action is a write action. Interpreter Class (dataevent_client some App4)and(dataevent_variable some(hasDataTypesome(not(DataType_REAL)))) →Attack Scenario 1.2 Language The sniff is something whose data event client is App4 and whose data event variable has a data type which is not data type real. Interpreter Class Network_CL and(service some service_ssh) →Attack Scenario 3.2 Language The security hole is something whose service is SSH. Interpreter Class (id.resp_p some id.resp_p_22.0)and(orig_bytes some orig_bytes_log_10to2) →Attack Scenario 3.3 Language A security hole is something whose port is 22 and whose raw volume is 10 to 2. Interpreter Class (init_client some App3)and(init_server some(isPartof someDevNetwork)) →Attack Scenario 4.1 Language The certificate usage is something whose initial client is App3 and whose initial server is part of a development network. Interpreter Class id.resp_p some id.resp_p_22.0 →Attack Scenario 5.1 Language Network scanning is something whose port is 22.

[0091] In the example above, the verbalized explanation "the certificate usage is something whose initial client is App3 and whose initial server is part of the development network" corresponds to scenario 4.1. The explanation "the OPC-UA server was accessed from an IP address corresponding to the development host" captures the anomaly and is even more specific to the concrete data example, as it also gives information about the initial client. This explanation of the certificate usage anomaly is, for example, embodied in the triple "App3 initiatedFrom192.168.0.80".

[0092] Explaining that “a network scan is something with port 22”, which implies connecting “192.168.0.18 to 192.168.0.60”, might require some additional information for the layman, but should give enough information for the domain expert. Here, the IP address is doing a network scan, of course, and the IP address it normally connects to, but using the wrong port — SSH (22) instead of HTTPS (443). Overall, we can see that explanations capture general scenarios while tending to be more specific in describing specific anomalies in the data.

[0093] Figure 6 An explanation subgraph generated by GNNExplainer for marking a data event "app4 read UA variable - hardware revision" as suspicious is shown.

[0094] In those embodiments of the methods and systems that draw from the hybrid approach, the sub-symbolic interpretations in the form of sub-graphs are generated by GNNExplainer, such as Figure 6 As shown, a suspicious labeled data event “app4 read UA variable hardware revision” is shown. In contrast to the rest of the subgraph, the nodes and edges drawn with dashed lines are considered to have no influence on the GNN’s labeling. This information is then used to compute a fidelity score for the underlying interpreter class for each labeled event. Figure 6 As can be seen in , the implied explanation is part of the identified subgraph, where the data event client is “App4” and “UA variable hardware revision” has the data type string. Therefore, the explanation generated by the DL-Learner shows fidelity relative to the GNN.

[0095] Filtering false positives Explanations cover 100% of all true positive alerts. This provides the domain expert with the advantage of focusing on the triggered alerts that have been created based on the availability of explanations, thereby reducing the need to investigate false positives by a large percentage. According to this embodiment, all alerts for which the framework does not provide explanations are filtered out because they are false positives. The use of these filtering techniques significantly reduces the time and resources required by the domain expert. In addition, more time will be saved in analyzing the remaining alerts because explanations for these alerts are provided as described above.

[0096] In a further step, the fidelity of the explanation for each alert may be considered. This additional filtering step will lead to a further reduction in false positives. However, some true positives may also be missed. Therefore, depending on the preferences of the domain expert, it may be preferred to use the fidelity score as a method for prioritizing the alerts. The use of these filtering and prioritization techniques significantly reduces the time and resources required by the domain expert. In addition, more time will be saved in analyzing the remaining alerts because the explanations for these alerts are available.

[0097] Figure 7 A flow chart of a possible exemplary embodiment of a method for interpreting and filtering network security alerts is shown.

[0098] In a first operation OP1, a knowledge graph is created and / or continuously updated by ingesting information about technical systems from engineering tools, in particular in automated ML format, network communications observed from security monitoring tools, and behaviors observed at the application level by processing server logs.

[0099] In a second operation OP2, an ontology creation component processing the knowledge graph creates and / or continuously updates an ontology, in particular by using a class hierarchy dividing the technical system into an automation part according to the first aspect, a network part according to the second aspect and an edge part according to the third aspect.

[0100] In a third operation OP3, the database stores a knowledge graph comprising information about: technical systems, in particular industrial automation systems, wherein, according to a first aspect, at least some nodes of the knowledge graph represent entities of the technical system and the edges of the knowledge graph represent different types of relationships between these entities, and, according to a second aspect, observed network communication events, which are represented as edges in the knowledge graph.

[0101] In a fourth operation OP4, the anomaly detection component, in particular the graph neural network, calculates the likelihood of each event by performing link prediction on the edges in the knowledge graph representing the event, and generates an alert for the event if its likelihood is below a threshold.

[0102] In a fifth operation OP5, the explanation generation component processes the ontology and the input and output of the anomaly detection component, and uses the ontology to create interpreter classes to generate explanations for some alerts, wherein each interpreter class indicates what input to the anomaly detection component can result in what output, wherein if the OWL reasoner processing the ontology concludes that one of the interpreter classes is applicable to the alert, an explanation is generated for the alert.

[0103] In a sixth operation OP6, the filter component removes alerts for which no explanations are generated.

[0104] In a seventh operation OP7, the verbalizer verbalizes the generated explanation for at least one of the remaining alarms. Figure 1 The user interface shown in outputs the verbalized interpretation as text or speech.

[0105] For example, the method may be performed by one or more processors. Examples of processors include a microcontroller or microprocessor, an application specific integrated circuit (ASIC), or a neuromorphic microchip, in particular a neuromorphic processor unit. The processor may be part of any kind of computer, including a mobile computing device such as a tablet, smartphone, or laptop, or part of a server in a control room or in the cloud.

[0106] The above method can be implemented by a computer program product, which includes one or more computer-readable storage media on which instructions executable by one or more processors of a computing system are stored. The execution of the instructions causes the computing system to perform operations corresponding to the actions of the above method.

[0107] Instructions for implementing the processes or methods described herein may be provided on non-temporary computer-readable storage media or memory, such as cache, buffer, RAM, FLASH, removable media, hard drive or other computer-readable storage media. Computer-readable storage media include various types of volatile and non-volatile storage media. Functions, actions or tasks shown in the figure or described herein may be performed in response to one or more instruction sets stored in or on a computer-readable storage medium. Functions, actions or tasks may be independent of a particular type of instruction set, storage medium, processor or processing strategy, and may be performed by software, hardware, integrated circuits, firmware, microcode, etc. operating alone or in combination. Similarly, processing strategies may include multi-processing, multi-tasking, parallel processing, etc.

[0108] The present invention has been described in detail with reference to the embodiments and examples of the present invention. However, within the scope of the present invention covered by the claims, changes and modifications may be made. The phrase "at least one of A, B and C" as an alternative expression may specify that one or more of A, B and C may be used.

Claims

1. A computer-implemented method for interpreting and filtering network security alerts, wherein the following operations are performed by a component, and wherein the component is a software component executed by a hardware component and / or one or more processors: -Store (OP3) a knowledge graph (G) in a database, including information about: - according to a first aspect, a technical system, in particular an Industrial Automation System (IAS), wherein at least some nodes of a knowledge graph (G) represent entities of the technical system and edges of the knowledge graph (G) represent different types of relations between these entities, and - according to a second aspect, observed network communication events between entities of the technical system, represented as edges in the knowledge graph (G), - the likelihood of each event is calculated (OP4) by an anomaly detection component (AD) by performing link prediction on the edges in the knowledge graph (G) representing the event, and an alert is generated for the event if its likelihood is below a threshold, - generating (OP5) explanations for some alerts by an explanation generation component (EG) processing the ontology and the inputs and outputs of the anomaly detection component (AD) by creating interpreter classes using the ontology, wherein each interpreter class indicates what input to the anomaly detection component (AD) may lead to what output, wherein an explanation is generated for an alert if an OWL reasoner processing the ontology concludes that one of the interpreter classes is applicable to the alert, - removed by the filter component (FFP) (OP6) without generating an alarm for its explanation, and - verbalizing (OP7) by a verbalizer (V) the generated explanation for at least one of the remaining alarms.

2. The method according to claim 1, -Wherein, each explanation provides context for the situation in which the corresponding alert occurred by relating it to other entities in the knowledge graph (G).

3. The method according to any one of the preceding claims, -in, The anomaly detection component (AD) is implemented based on the RESCAL algorithm, the TransE algorithm, the DistMult algorithm or a graph neural network, in particular a graph convolutional neural network.

4. The method according to any one of the preceding claims, - wherein the anomaly detection component (AD) is a graph neural network, - wherein the generating operation (OP5) comprises generating, for each alert, a sub-symbolic interpretation, in particular a sub-graph of the knowledge graph (G), for computing a fidelity score with respect to the corresponding interpreter class by determining an overlap of the sub-symbolic interpretation and the interpreter class, and - wherein an alert is removed if its fidelity score is below a threshold.

5. The method according to any one of the preceding claims, -in, According to a third aspect, the knowledge graph (G) further comprises information about observed events at the application level, in particular data access events, which are represented as edges in the knowledge graph (G).

6. The method according to claim 5, With the following initial operations: - Create (OP1) and / or continuously update a knowledge graph (G) by ingesting information about: - technical systems from engineering tools, in particular in automated ML formats, - Network communications observed from security monitoring tools, and -Behavior observed at the application level by processing server logs.

7. The method according to claim 6, - wherein at least some of the information is ingested into a knowledge graph (G) using an ontology expressed in the W3C OWL 2 standard based on a Description Logic formalism.

8. The method according to claim 6 or 7, With the following additional initial operations: - Creation (OP2) and / or continuous updating of an ontology by an ontology creation component (OC) processing the knowledge graph (G), in particular by using a class hierarchy dividing the technical system into an automation part according to a first aspect, a network part according to a second aspect and an edge part according to a third aspect.

9. The method according to claim 8, - wherein the automation part comprises in particular classes for structures, components and interfaces of the technical system, -in, The network part contains in particular classes for IPs, individual networks and network connections and their properties, and - wherein the edge part contains in particular classes for initialization events and data events at the application level.

10. A system for interpreting and filtering network security alerts, comprising the following components: - A database storing a knowledge graph (G) including information about: - According to a first aspect, a technical system, in particular an industrial automation system (IAS), wherein At least some of the nodes of the knowledge graph (G) represent entities of the technical system, and the edges of the knowledge graph (G) represent different types of relationships between these entities, and - according to the second aspect, observed network communication events between entities of the technical system, which are represented as edges in the knowledge graph (G), an anomaly detection component (AD) configured to compute the likelihood of each event by performing link prediction on edges in a knowledge graph (G) representing the events, and to generate an alert for the event if its likelihood is below a threshold, an explanation generation component (EG) configured for processing the ontology and the input and output of the anomaly detection component (AD), and for generating explanations for some alerts by creating explainer classes using the ontology, wherein each explainer class indicates what input to the anomaly detection component (AD) may lead to what output, wherein an explanation is generated for the alert if an OWL reasoner processing the ontology concludes that one of the explainer classes is applicable to the alert, - a filter component (FFP) configured to remove alerts for which no explanation has been generated, and - a verbalizer (V) configured for verbalizing the generated explanation for at least one of the remaining alarms.

11. Computer program product comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method according to one of the method claims.

12. Supply device for a computer program product according to the preceding claim, wherein the supply device stores and / or provides the computer program product.

Citation Information

Patent Citations

  • Industrial device and method for building and / or processing a knowledge graph

    EP4030351A1