System and method for detecting and determining network-originated malicious activity in an industrial control system

Abstract

The invention relates to a system for detecting network- originated malicious activity in an industrial control system ( ICS ), comprising : ( a) an unsupervised anomaly detector receiving sensor ' s data from the ICS, and outputting a labeled signal; (b) a supervised network classifier trained by network traffic and by the labeled signal outputted from the unsupervised anomaly detector, the supervised network classifier creating a supervised anomaly prediction model; ( c) the supervised anomaly prediction model receiving during runtime the network traffic and the labeled signal, and configured to determine a state of anomaly; and (d) a XAI-type explainer configured to inspect the anomaly prediction model during its operation, and output elements of the network traffic that contribute most to the anomaly state determined by the supervised anomaly prediction model.

Description

[0001] SYSTEM AND METHOD FOR DETECTING AND DETERMINING NETWORK- ORIGINATED MALICIOUS ACTIVITY IN AN INDUSTRIAL CONTROL SYSTEM

[0002] Field of the Invention

[0003] The field of the invention generally relates to security systems in industrial control systems, more specifically, to a system for detecting and determining network-originated malicious activity in an industrial control system.

[0004] Background of the Invention

[0005] Industrial Control Systems ( ICS) play a critical role in the operation of critical infrastructure across various sectors, such as energy production, water treatment, and manufacturing. ICS includes multiple layers (domains), including a physical layer, a network layer, and an application layer, each serving another aspect of management, operation, and security. The physical (OT) layer includes, for example, the control of sensors, actuators, and devices that directly interact with physical processes, such as regulating fluid flow or monitoring pressure in a manufacturing plant, regulating the temperature or pressure within a boiler, or controlling the operation of a transformer. In many cases, such ICSs include multiple controlled units, equipment, devices, components, and related sensors. The network ( IT) layer is responsible for communication between various ICS units or control components, such as programmable logic controllers (PLCs), human-machine interfaces (HMIs), and servers, which may be located remotely from the specific controlled component. For example, the network layer handles the conveyance of control commands and data between various control units and components. The applicationlayer primarily focuses on higher-level control and operational management, where software applications analyze data, monitor system performance, and implement decision-making logic. Industrial control systems are increasingly exposed to sophisticated cyber threats that can cause operational disruptions and safety hazards, primarily by exploiting network-layer vulnerabilities to inject malicious management and operational commands.

[0006] Intrusion Detection Systems ( IDSs) are commonly used in industrial control systems to detect such threats. Yet, the effectiveness of IDSs is often compromised by high rates of false positives (FPs) and by the complexity of interpreting alerts to determine whether they represent actual intrusions, especially malicious commands within massive traffic (network or other-domain commands). Currently, determining whether an intrusion caused an alert requires a complex manual analysis of the actual source of the intrusion, and even more so to identify the specific instructions and packets that initiated the alert. Various automated systems have been proposed to ease detection, but they are not satisfactory.

[0007] Knowledge-based detection techniques rely on databases of known attack patterns to identify threats, offering high accuracy for recognized attacks but struggling to detect new, unseen threats because they depend on existing signatures. Behavior-based detection establishes a baseline for typical operational behavior and flags deviations as potential security issues. It is effective at uncovering new threats through anomaly detection. Still, it struggles to accurately define "normal behavior" due to the dynamic nature of the ICS environment, resulting in a relatively high rate of false positives.In one aspect, the complexity of interpreting the alert leads to a high False Positive (FP) rate, burdening cybersecurity teams with a large volume of alerts that do not represent actual threats. The massive volume of alerts can lead to alert fatigue, in which legitimate threats are overlooked due to the overwhelming number of false alarms. Additionally, the complexity of interpreting alerts that may originate or span multiple domains, such as physical, network, and application domain alerts, each having different characteristics, goals, and data types, further complicates the decision-making process. Without clear, explainable insights into why an alert was triggered, security specialists struggle to prioritize responses to real threats, increasing the risk of operational failures and damage, while some cyberattacks may go undetected. Therefore, detecting real threats, reducing FPs, and improving alert interpretability are essential to enhancing ICS reliability and ensuring a timely, accurate response to security incidents.

[0008] Prior art techniques have primarily focused on correlating alerts across network and physical domains to reduce the number of alerts, without leveraging explainability to reveal the origins of alert generation. Some prior art works aimed to explain alerts; however, their explanations do not indicate which activities, e. g., across different layers, triggered the alerts, as both the alerts and the explanations were based on the same data layer. The absence of explanations limits decision-making capabilities, making it more challenging to detect complex multi-vector attacks that exploit vulnerabilities, including crosslayer vulnerabilities in ICSs. The challenge is especiallyhigh to obtain explanations across IT ( Information Technology) and OT (Operational Technology) layers.

[0009] It is an object of the invention to provide a security system for automatically detecting and explaining OT alerts in an industrial detection system, in a manner that points to the related IT activity.

[0010] It is another object of the invention to reduce falsepositive alerts, thereby increasing the attention given to true alerts.

[0011] It is still another object of the invention to increase the detection rate and reduce the time required to handle each alert, thereby eliminating or reducing damage to the ICS ' s units, components, and products.

[0012] Other objects and advantages of the invention become apparent as the description proceeds.

[0013] Summary of the Invention

[0014] The invention relates to a system for detecting network-originated malicious activity in an industrial control system ( ICS), comprising: (a) an unsupervised anomaly detector receiving sensor's data from the ICS, and outputting a labeled signal; (b) a supervised network classifier trained by network traffic and by the labeled signal outputted from the unsupervised anomaly detector, the supervised network classifier creating a supervised anomaly prediction model; (c) the supervised anomaly prediction model receiving during runtime the network traffic and the labeled signal, and configured to determine a state of anomaly; and (d) a XAI-type explainer configured to inspect the anomaly prediction model during itsoperation, and output elements of the network traffic that contribute most to the anomaly state determined by the supervised anomaly prediction model.

[0015] In an embodiment of the invention, the system further comprising a feature extraction unit, configured to extract traffic features used as (i) inputs for training the supervised network classifier and (ii) inputs to the supervised anomaly detection model.

[0016] In an embodiment of the invention, the elements of the network traffic determined to contribute most to the anomaly state are features selected from the extracted features inputted into the supervised anomaly prediction model.

[0017] In an embodiment of the invention, the supervised network classifier is deep-learning-trained by the network traffic, and wherein the elements of the network traffic determined to contribute most to the anomaly state are highlighted.

[0018] In an embodiment of the invention, the system further comprising a reverse engineering unit for determining specific packets or instructions that contribute most to the anomaly state, from among the features determined to contribute most to the anomaly state.

[0019] In an embodiment of the invention, the determined features, packets, or instructions are selected from within a time period T preceding the detection of the anomaly.

[0020] In an embodiment of the invention, at least some of the features are predefined.In an embodiment of the invention, the system further comprising a grouping unit, configured to eliminate repetitions in the features, packets, or instructions determined to contribute most to the anomaly.

[0021] In an embodiment of the invention, the supervised network classifier is trained offline, during runtime, or a combination thereof.

[0022] The invention also relates to a method for detecting network-originated malicious activity in an industrial control system ( ICS), comprising: (a) providing an unsupervised anomaly detector receiving sensor's data from the ICS, and outputting a labeled signal; (b) providing a supervised network classifier trained by network traffic and by the labeled signal outputted from the unsupervised anomaly detector, the supervised network classifier creating a supervised anomaly prediction model; (c) configuring the supervised anomaly prediction model to receive during runtime the network traffic and the labeled signal, and to determine a state of anomaly; and (d) configuring an XAI-type explainer to inspect the anomaly prediction model during its operation, and to output elements of the network traffic that contribute most to the anomaly state determined by the supervised anomaly prediction model.

[0023] In an embodiment of the invention, the method further comprising the providing of a feature extraction unit, configured to extract traffic features used as (i) inputs for training the supervised network classifier and (ii) inputs to the supervised anomaly detection model.In an embodiment of the invention, the elements of the network traffic determined to contribute most to the anomaly state are features selected from the extracted features inputted into the supervised anomaly prediction model.

[0024] In an embodiment of the invention, the supervised network classifier is deep-learning-trained by the network traffic, and wherein the elements of the network traffic determined to contribute most to the anomaly state are highlighted.

[0025] In an embodiment of the invention, the method further comprises providing a reverse engineering unit to determine specific packets or instructions that contribute most to the anomaly state, from among the features determined to contribute most to the anomaly state.

[0026] In an embodiment of the invention, the determined features, packets, or instructions are selected from within a time period T preceding the detection of the anomaly.

[0027] In an embodiment of the invention, the method further comprising predefining of at least some of the features.

[0028] In an embodiment of the invention, the method further comprising the providing of a grouping unit, configured to eliminate repetitions in the features, packets, or instructions determined to contribute most to the anomaly.

[0029] In an embodiment of the invention, the method further comprising the training of the supervised network classifier offline, during runtime, or a combination thereof.Brief Description of the Drawings

[0030] In the drawings:

[0031] Fig. 1 illustrates a general structure of a typical (prior art) system for detecting and handling intrusion anomalies (malicious activity) in an ICS;

[0032] Fig. 2a shows the general structure of an intrusion detection system according to an embodiment of the present invention;

[0033] Fig. 2b shows the system structure of Fig. 1 under the assumption that the anomaly prediction model has already been fully created and is not updated during runtime;

[0034] Fig. 3 shows the pipeline flow and system structure according to an embodiment of the invention;

[0035] Fig. 4 shows examples of point-adjusted and point-wise calculations, where each data point is binary classified as benign (black) or anomaly (red - brighter color);

[0036] Fig. 5 shows ICNL 2D SHAP values using PCA (colored by activity);

[0037] Fig. 6 shows ICNL 2D SHAP values using TSNE (colored by activity);

[0038] Fig. 7 shows an example of anomalies discovered in a temperature sensor measurements;

[0039] Fig. 8 illustrates an example of an output of the explainer, of the invention, in a manner known as a waterfall chart; and

[0040] Fig. 9 illustrates an example showing how the reverse engineering module of Figs. 2a and 2b is used to identify network packets associated with a selected feature.

[0041] Fig. 10 is a flow diagram showing the anomaly detection and analysis process, according to an embodiment of the invention.Detailed Description of Preferred Embodiments

[0042] Fig. 1 illustrates a general structure of a typical (prior art) system 100 for detecting and handling intrusion anomalies (malicious activity) in an ICS. The term "malicious activity" refers to any unauthorized activity meant to damage the integrity or the availability the industrial control system or any part thereof, and may involve (a) malicious instructions; (b) packets with the malicious instructions; (c) false data in a device or in a packet; (d) excessive packets or commands with legitimate content; (e) prevention of packet transmission, command execution, data transfer, etc.; and the like. Process behavior sensor data 160 is continuously conveyed to a physical unsupervised anomaly detector 110, which is trained to detect process anomalies (e. g., overtemperature, under-pressure, over-speed of a machine, or combinations thereof ) and to alert when such anomalies are detected (see output physical anomaly signal 112, which may be either in digital or analog form). Two such anomalies, 116a and 116b, are indicated as examples within the output signal 112. Prior art OT-level security may issue alerts when such anomalies are detected, resulting in multiple false positive alerts (anomalies that are not caused by malicious activity). Simultaneously, the network process-control traffic 180 (or a representation thereof ) for controlling the physical system is conveyed to the network unsupervised anomaly detector 120, which is trained to detect network-originated anomalies reflected by the network anomaly output signal 122. Prior art IT-level security systems may issue alerts when such anomalies are detected, resulting in multiple false positive alerts (anomalies that are not caused by a malicious activity). Correlator 130 correlates signals 112 and 122 and issues alert 150 when such a correlation exists, thereby reducingthe number of false-positive alerts. In the example shown in Fig. 1, no alert is issued by correlator 130, as there is no correlation between signals 112 and 122. The prior art system of Fig. 1 requires continuous, runtime correlation between traffic signals and sensor data to issue an alert 190. Moreover, once an alert 190 is issued, a complex manual analysis is required to identify the network's malicious activity (when it exists) responsible for the alert and the system malfunction. The structure of Fig. 1 and operating manner are not optimal. In addition, to ensure reliability and avoid missing true alerts, the system of Fig. 1 is compromised by the necessity to handle many false-positive alerts.

[0043] The present invention provides a system structure that overcomes the above deficiencies. Among other advantages of the proposed structure, the system of the invention assists a security manager in identifying the malicious activity (packets and / or network instructions) responsible for the alert, thereby simplifying the manual analysis and reducing the number of false-positive alerts that need to be handled.

[0044] Fig. 2a shows the general structure of an intrusion detection system according to the present invention. Process behavior sensor data 260 (such as, but not limited to temperature, pressure, rpm, or any other process sensing data) is continuously conveyed to the physical unsupervised anomaly detector 210, which is trained to detect physical anomalies (e. g., over-temperature, fluid under-pressure, or over-turning speed of a machine) and to alert when such anomalies are detected (see output physical anomaly signal 212 ). The physical unsupervised anomaly detector 210 and its function are substantially the sameas the unsupervised anomaly detector 110 of the prior art system of Fig. 1. For each input combination of sensor data 260, the unsupervised physical anomaly detector 210 outputs a label 222 indicating whether the given input sensor-data combination 260 represents an anomaly, possibly a non-dichotomic indication of the anomaly magnitude. The output labels 222 from the unsupervised anomaly detector 210 (i. e., physical anomaly signal 212 ) are conveyed to the supervised network classifier 225 for training it. During training, the supervised network classifier 225 simultaneously receives both the anomaly labels 222 generated by the unsupervised anomaly detector 210 and the traffic data (raw network traffic or traffic features, as discussed in more detail hereinafter). The training of the supervised network classifier 225 (performed either online during operational runtime or offline) creates the supervised anomaly prediction model 235. The supervised anomaly prediction model 235 is inspected by an explainable artificial intelligence (XAI ) unit 265, also referred to herein as the "explainer". Fig.

[0045] 2a shows the system' s structure during operational runtime, assuming that the supervised anomaly prediction model is also updated during the operation. Fig. 2b shows the system structure under the assumption that the supervised anomaly prediction model 235 has already been fully created and is not updated during runtime. The dashed lines in Fig. 2b indicate non-operational units (in this case, assuming that no training is operational during the runtime).

[0046] During runtime, the system detects malicious network activity in network traffic that causes OT (physical) anomalies. The traffic data (raw network traffic or traffic features, as discussed in more detail hereinafter) is directly conveyed to the supervised anomaly predictionmodel 235. Explainer 265, by continuously inspecting (watching) the activity of supervised anomaly prediction model 235, and given that the supervised anomaly prediction model 235 is a supervised-type classifier, outputs for each traffic element 226 (each instantaneous element within the flowing raw traffic or within the traffic features, as is the case), the dominance level 290 (see, for example, Figs. 8 and 9) of this element for the output 269 of the supervised anomaly prediction model 235. These dominance levels are of interest only when an anomaly is observed within the OT section 200b. The anomaly labels 222, provided at the input of the explainer 265, limit the capture of the dominance-level indications 290 to only times of anomaly 216a, 216b within the OT system. The dominance levels 290 are kept within storage 290a for further analysis. These dominance levels 290 guide a security analyst to the network element (s) 226 responsible for the anomaly 216 (e. g., 216a or 216b within labeled signal 212 ). While the dominance levels 290 are generally satisfactory for an analyst in determining the real cause of the anomaly, the optional reverse engineering unit 245, if used, can direct the analyst deeper to the specific traffic packets (or instructions) responsible for the anomaly 216. For example, the dominance levels 290 indicate the relative contribution of each traffic element to the anomaly. The fact that the manner in which each feature combination was defined can be used by the optional reverse engineering module 245 to determine the exact instruction ( s ) or packet (s) 245a responsible for the anomaly. Finally, a grouping unit 246 may be used to group the determined instruction ( s ) or packet (s) 245a based on their time, type of anomaly, component involved, etc., thereby to reduce repetitions.When the supervised network classifier 225 is a deep learning type classifier, the network data 226 at the input can be the raw traffic. When the supervised network classifier 225 is a regular machine learning classifier, traffic features must be fed into it. In that case, a preprocessing step of feature extraction 211 should be performed on the raw traffic before feeding the features into the supervised network classifier 225. Table 1 below provides an example of features that may be used (and, in fact, were used in the experiment described below). The features may include (a) a nominal indication of the protocols fed (e. g., tcp, udp, icmp, etc. ); (b) Source-to-destination instructions (e. g., PLC2_to_HMI, PLC2_to_HISTORIAN, where " HISTORIAN" stores history of traffic events, etc. ); and (c) Industrial Functions Source to destination (e. g., Read Variable_HMI to PLCI, Write Variable_unknown_to_PLCl, etc. ). As will be further discussed, the features may be evaluated by their rate of repetition over specific time periods (e. g., 3.0 minutes, 1 minute, etc. ). As noted, the selected features are user-defined and may be selected by the user and / or adapted based on the specific ICS used.

[0047] Table 1: Telemetry network features

[0048] Protocols

[0049] tcp, ndp, icmp,

[0050] s7comm. cip,

[0051] unknown.protocol, etc.

[0052] Source-to- Destination Communication

[0053] PLC2_to_HMI,

[0054] PLC2_to_HISTORIAN,

[0055] HISTORIAN_to_unknown,

[0056] unknown_to_PLC1, etc.

[0057] Industrial Functions Source-to-Destination

[0058] Read Variable_HMI_to_PLC1,

[0059] Read Variable_PLC1_to_HMI,

[0060] Write Variable_unknown_to_PLC1,

[0061] Write Variable_HMI_to_PLC2, etc.Fig. 8 illustrates an example of the explainer ' s 265 output 290, known as the waterfall chart. The features 292a-292n are indicated on the left. Each tag 291 indicates the contribution of the respective feature 292 to the classifier ' s decision that there is an anomaly.

[0062] Features indicated by right-directional tags (e. g., tags 291a-291n, excluding left directional tag 291n-i) contribute to the classifier ' s decision that it relates to an anomaly. Features indicated by left-directional tags (e. g., tag 291n-i) contribute to the classifier ' s decision that there is no anomaly. As is conventional in SHAP waterfall plots, the X-axis (a) starts at the baseline value - the model ' s average prediction over the training data; (b) Then each feature adds or subtracts its SHAP value; (c) It ends at the final prediction for that one data point. So, in brief, the x-axis indicates: baseline prediction cumulative model output final prediction.

[0063] The tag value (e. g., +1.94 for tag 291a, +1.49 for tag 291b) indicates how strongly (dominantly) the feature convinces the classifier that there is an anomaly. In the example of Fig. 8, the most significant feature that affected the anomaly is the "write variable_HMI_to PLC1_3.0min, namely, a feature that indicates how many times this type of instruction appeared within a period of 3. 0 minutes.

[0064] Fig. 9 illustrates how the reverse engineering module 245 is used to identify the exact network packets associated with the feature 292a, which was recognized as the most dominant cause of the anomaly. Clicking the 292a feature,found to be most relevant, reveals the specific packets associated with the detected anomaly.

[0065] The system of the invention is multi-layer in the sense that alerts are first triggered at the physical layer (OT). These physical alerts provide information limited to the physical layer (e. g., which sensor triggered the alert, when the trigger occurred, etc. ). The invention couples these physical alerts with related network-layer activity (e. g., by displaying relevant packets or commands associated with the alert).

[0066] The system also relates to a method for identifying malicious activities within an ICS. Fig. 10 generally describes the method of the invention. Within the OT section, sensor data 402 trains an unsupervised classifier (step 404 ), forming the unsupervised classifier 406. When trained and during (operational ICS) runtime, the unsupervised classifier 406 continuously outputs a labeled signal (labels) in response to the sensor ' s data 402. The sensor data labels are conveyed to the IT section. Within the IT section, various features related to the network traffic 408 are defined in step 410. Then, given the feature definitions and the network data, feature extraction is performed on the network traffic. The extracted features, together with labels received from the unsupervised classifier 406, are used to train a supervised classifier (step 414 ). When trained, the supervised classifier 414 creates a supervised anomaly prediction model 416. During (operational ICS) runtime, features extracted from network traffic are inserted into the supervised anomaly prediction model 416, which also simultaneously receives labels from the unsupervised classifier 406. Explainer 418 continuously inspects themodel ' s behavior in response to the network traffic ' s labels and features, and (at least) when a fault label is observed, it outputs 420 the relative contribution of each input traffic element (e. g., feature) to the classifier ' s confidence in the anomaly label. These output features are then analyzed in step 424 to determine the cause of the anomaly. Optional reverse engineering step 422 may be used to further inspect the most probable features to determine the specific instructions responsible for the anomaly. The reverse engineering procedure is based on the fact that the manner in which the most probable features are created (defined features 410 and the feature extraction step 412 ) is known.

[0067] Example

[0068] An air conditioner is provided to cool a transformer. An intruder occasionally sends a command over the network, causing the air conditioner ' s fan to stop, e. g., for 10 seconds. In the OT section, the maintenance staff notices that the transformer ' s heat has increased, or, in other words, that the air conditioner ' s efficiency has decreased. The maintenance staff may try to fix the problem technically, e. g., by performing maintenance on the air conditioner, and the transformer ' s heat returns to normal. However, the next day the problem repeated several times. An investigation to identify the true cause of the heating anomaly is complicated. The use of the system of the invention will lead the user to the packets with the highest correlation with the problem, in this case, to the packets controlling the rotation of the air conditioner ' s fan. Alternatively, if the reverse engineering module is not used, the system of the invention may lead the user to the feature (s) most dominant in causing the problem, whichthen guide the user to the malicious packets causing the problem.

[0069] In some embodiments, features or packets detected as malicious may be clustered for convenience and ease of analysis.

[0070] Furthermore, as becomes apparent, some of the system' s definition are generic, while some others are specific to the ICS involved. For example, definitions such as traffic features related to ICS protocols, a pretrained model of OT anomaly detection, and the analytical pipeline may be generic, while definitions such as network features related to specific network addresses in the system and their role in ICS, fine-tuning the OT anomaly detector to the specific deployment, and specific OT measurements (a. k. a. sensor data, tags) may depend on and be tailored based on the specific ICS involved.

[0071] FURTHER DISCUSSION AND EXAMPLES

[0072] As noted, in prior art Industrial Control Systems ( ICS), alerts are generated by Intrusion Detection Systems ( IDS) across multiple layers. While recent works primarily address the correlation between physical and network alerts (as shown in Fig. 1 ), the present invention focuses mainly on grouping and explaining physical alerts. These grouped physical alerts can subsequently be correlated with network alerts.

[0073] As shown in Figs. 2a, 2b, the present approach involves multiple stages spanning both the physical and network layers of the ICS environment. Referring to Fig. 2a, initially, alerts are generated at the physical layer to detect anomalies in the physical data 210. Simultaneously,network data is pre-processed, and relevant features are extracted 211; a supervised network classifier 225 is trained and analyzed by an explainer algorithm 265-235, which provides network explanations for each OT (physical) alert. Anomalies are clustered into network explanation clusters (NECs) based on these XAI outputs, associating each physical alert with a corresponding NEC. Finally, the physical alerts are grouped based on their similarity.

[0074] The pipeline flow 300 of the invention is depicted in Fig.

[0075] 3, showing the data flow and analytical processes involved. Like References in Fig. 3, to those of Figs. 2a and 2b represent similar functionality (discussed above) and will not be repeated, for the sake of brevity. Only some differences will be discussed herein. The Pcap (Packet Capture) files 303 are conveyed to the feature extraction unit 311 and typically include packet headers ( IP, TCP / UDP, etc. ), payload data, timestamps, and interface metadata. The Zeek unit 311a, within the feature extractor, is a passive network traffic analyzer that observes network traffic and converts it into structured, high-level log files 311b (of types such as conn, s7comm, http, etc. ). Then, predefined features are extracted from the log files 311b in a manner as discussed above. The extracted features are used (a) to train the supervised classifier 325 to prepare model 335; and for operation with model 335 during runtime (the runtime and the training may be simultaneous). Within the physical section, the physical data is conveyed to the unsupervised anomaly detector 310 ( for training and operational functionalities, which may be simultaneous). The anomaly indications (anomaly labels) 322, when they occur, are conveyed (with their respective timestamps) to the supervised network classifier 325 ( for training it) and to the supervised prediction model 335 and explainer365 (during runtime). Explainer (XAI - Explainable Artificial Intelligence, e. g., SHAP) 365 outputs, particularly when an event occurs, the dominance levels 390 of network elements related to the respective anomaly, in a manner discussed above. The explainer may be, for example, SHAP or similar. Clustering unit 346a (e. g., DBSCAN) clusters the network explanations to obtain those specific network data 301 corresponding to the anomaly (generally within a time period T before the anomaly detection), resulting in grouped detected anomalies 346b, e. g., by time, component, network, explanation cluster, etc. More particularly, unit 346a creates network explanation clusters. Unit 346b uses the network explanation clusters, alongside time and other similarity indications, to further group alerts. The analyst is expected to investigate each group rather than each individual alert.

[0076] In a pre-processing stage, the inventors trained a univariate unsupervised anomaly models (within detector 210 of Fig. 2a) to obtain physical alerts. The user began with benign physical data. Specifically, for each sensor j, the inventors created overlapping windows for its readings, with a fixed window size of 10 seconds and a stride of 1. Each window W_jt was defined by its start time t and contained sensor j readings x_j defined as W_jt = {x_j(t),..,x_j(t + 9)}

[0077]

[0078] ( t + 9) }. For each sensor j, the inventors trained the unsupervised anomaly detector (model) 310 using a univariate autoencoder. The obtained model 310 then predicted anomalous windows in test data within their respective sensor data. The inventors aggregated windows that have the same start time t across all sensors into an aggregated window AggWt, which contained every sensor j that flagged Wjt asanomalous, defined as: AggWt {j | if Wjt flagged as anomalous }.

[0079] An alert A was created for each AggWt that was flagged as anomalous by one or more models. Alert A was represented as a tuple, containing the anomalous window start time t as creation time (CT), the data layer id (LID), the detector id (DID), the sensor id (SID) and the mapping of sensors to equipment id (EID) that they monitored (e. g., water temperature sensor mapped to the equipment ' Wat-er Tank 1 '):

[0080] A = ( CT, LID, DID, SID, EID)

[0081] The physical alerts were then enriched by network explanation clusters.

[0082] The network traffic ( for example, in the form of Pcap files 303) was processed using Zeek (The Zeek Proj ect - https: / www. zeek. org / , 2022. Accessed: April 24, 2024. ) to extract log files 311b (e. g., conn. log, s7comm. log). The Zeek 311a is an open-source network security monitor ( formerly called Bro). Zeek generally (a) observes network traffic (not inline blocking); (b) Produces rich, structured logs about what happened on a network - connections, DNS, HTTP, SSL / TLS, files, anomalies, etc., and (c) Uses its own scripting language to define detection logic and policies.

[0083] A predefined dictionary was used to map IP addresses 313 to specific system component names, such as Programmable Logic Controllers (PLCs) or Human-Machine Interfaces (HMIs). The logs were aggregated into a telemetry dataset, capturing occurrences per second and during 0.5, 1.0, and 3.0 minutes prior to each occurrence of protocols, manufacturing functions, and IP addresses. Each instancein the telemetry network data was represented by a timestamp (per second), aggregated artifacts for the respective second, and the previous second. Table 1 (replicated here for convenience) shows examples of the telemetry network features.

[0084] Table 1: Telemetry network features

[0085] Protocols

[0086] tcp, udp, icmp,

[0087] s7comm, cip,

[0088] unknown.protocol, etc.

[0089] Source-to-Destination Communication

[0090] PLC2_to_HMI,

[0091] PLC2_to_HISTORIAN,

[0092] HISTORIAN_to_unknown,

[0093] unknown_to_PLC1, etc.

[0094] Industrial Functions Source-to-Destination Read Vuiable.. HMT.t<>.. P. LC 1,

[0095] Read Variable_PLC1_to_HMI,

[0096] Write Variable_unknown_to_PLC1,

[0097] Write Variable_HMI_to_PLC2, etc.

[0098] In the next step, the supervised machine learning binary classifier 325 (benign / malicious classification) was trained on network traffic 303, which was later chained to the XAI model (265 in Figs. 2a, 2b). For this purpose, the network instances were labeled. A network instance represents the network artifacts that occurred during and before each physical instance (within a time period T before). The network instances were labeled as related to anomaly if their timestamp matched the creation time of a physical alert (namely, within a time period T before the event). However, given the possibility of false alerts in the physical layer, there was a necessity to select network instances for the training set carefully:

[0099] Benign activity network instances were labeled as ' O '.• Network instances were labeled as ' 1 ', when their timestamp matched a physical alert

[0100] The above subset served as the training data for creating the network-supervised classifier 225-325, implemented using an XGBoost classifier. XGBoost (extreme Gradient Boosting) is a highly efficient, open-source machine learning library that implements gradient boosted decision trees for fast, accurate, and scalable regression and classification. It is an advanced form of ensemble learning that sequentially builds many weak decision trees, with each new tree correcting the errors of the last, incorporating regularization to prevent overfitting, and utilizing parallel processing for speed. XGBoost is known for its performance, handling of large datasets, and availability across multiple programming languages such as Python, R, and C++.

[0101] Following the formation of the network supervised classifier 225-325 (and also the supervised anomaly prediction model 235-335), the XGBoost-based model (equivalent to the supervised anomaly prediction model 235 was integrated with a Tree SHAP (SHapley Additive exPlanations) explainer model 265-365 to explain the network instances corresponding to the physical alerts timestamps. A network instance representing the network artifacts that occurred before a physical alert was observed by the explainer 265-365. The explainer 265-365 generated network explanations reflecting the contribution strength of each network artifact to the classification of the input as a malicious instance.

[0102] For example, a physical alert matched with a network instance [tcp=100, udp=100, unknown protocol=100] wasobserved by the explainer 265. The explainer 265 output was [top = 0.1, udp = 0.02, unknown protocol = 0.79], indicating that the first two features contributed less than the third, which played a greater role in the network classifier ' s decision.

[0103] In this manner, every physical alert was explained by the network activity preceding it. These explanations provided insights intended to assist in diagnosing and resolving the incident.

[0104] The SHAP explanations 290-390 of the physical alerts were clustered using DBSCAN (Density-Based Spatial Clustering of Applications with Noise) 346a. DBSCAN generally finds core samples of high density and expands clusters from them. Each physical alert was associated with a cluster of alerts that share similar network-explanation characteristics, forming a ' network-explanation cluster ' (NEC) attribute for alerts.

[0105] A = ( CT LID, DID, SID, EID, NEC) Where CT indicates a creation time, EID indicates an equipment ID, SID indicates a sensor ID, DID indicates a detector ID ( for example detector with id=l may be an anomaly detector that operates on sensor ' s 1, 2, 3 data with a certain algorithm), LID indicates Layer ID ( for example physical layer can have id 1 and network layer id 2 ), and NEC indicates a network-explanation cluster.

[0106] The physical alerts were fused as follows. At a final stage, the physical alerts were grouped based on similarity of one or more attributes such as creation time (CT), equipment id (EID), and network explanation cluster (NEC):• Time Similarity: A new alert Anewwas grouped with the previous alert Aprevif the time difference between their creation times, Δt = tnew- tprev, did not exceed a predefined threshold δ (e.g., δ=60 seconds). Here, tnewwas the creation time of Anew, and tprevwas the creation time of Aprev. Since each new alert was compared only to the previous alert, Anewcould eventually be grouped with alerts whose creation times differ by more than the threshold 5.

[0107] • Equipment Similarity: A new alert Anewwas grouped 246-346b with the previous alert Aprev, when both alerts were generated from sensor data related to the same equipment, for example, temperature and pressure of liquid in the same pipe in a water treatment system or the power on two links connected to the same bus in a power grid. Equipment similarity can be predetermined automatically or manually by engineers according to the system P& ID before the system deployment.

[0108] • NEC Similarity: Further enrichment of the physical alerts was achieved by incorporating network explanation clusters, which were derived from the network data. A new alert Anewwas defined to be grouped with the previous alert Aprev if both alerts belong to the same network explanation cluster. Let Nnewand Nprevrepresent the network explanation clusters to which Anewand Aprevbelong, respectively. If both alerts share the same network cluster, i.e., Nnewand Nprevare equal, the alerts are correlated. This correlation is based on the similarity of network behavior and characteristics.

[0109] To evaluate the methodology of the invention, the inventors looked for an ICS ( Industrial Control System) dataset thatmet several key criteria: detailed documentation of the testbed, recorded physical and raw network data over a sufficient period, a complex system architecture, and the inclusion of normal activity, operational failures, and cyberattacks.

[0110] Table 4 presents the characteristics of the datasets that were explored. Among these, the inventors identified only SWaT A6 2019 dataset as a suitable candidate for the evaluation.

[0111] Network Env Incidents Name Physical Duratio #

[0112] Data Data n Incidents Doc Doc. SWaT A1& A2 il2] V 11 d ays 41 V V SWaT A3 U2) V V 6 days 0 V SWaT A4& A5 fl 2] V ■1 1iOllVS 6 V V SWaT A 6 1'4 V V 3.75 hours 9 V V SWaT A 7 J 2 V I 1 hoars 0 V WADI Al [12 V 16 days 15 V V WADI A 2 [12 V 16 days 15 V V BATADAL I il2i V 1 year 0 V BATADAL 2

[0012] V 6 mouths V V BATADAL 3

[0012] V 3 months V Koucham ICS [15: V 62 hours 26 V

[0113]

[0114] ICNL

[0011] V V 42 hours 14 V V Table 4: Summary of ICS datasets

[0115] Additionally, the inventors adopted a custom dataset centered on energy production provided by ICNL ( ICS Cybersecurity National Lab). The ICNL dataset captured seven days of data from a gas-based energy production testbed, comprising both network traffic (PCAP files) and physical sensor readings (in CSV format).

[0116] ICNL provides specialized services and assemblies in the ICS cybersecurity domain. The inventors collaborated with the lab to create an energy production dataset as part of a pilot proj ect. The energy assembly was a power plant that generates electricity using a combined-cycle of steam and natural gas turbines. For safety reasons, the steam systemwas replaced with a water system, and the natural gas was replaced by compressed air to drive the turbines.

[0117] During the pilot, the inventors collected physical and network data over 7 days, with 6 hours of recordings per day:

[0118] • Days 1 -2: Normal Operation.

[0119] • Days 3-4: Normal Operation + Operational Failures. • Days 5-7: Normal Operation + Operational Failures + Cyber Attacks.

[0120] Cyber attacks and operational failures manifested in the pilot are described in Table 5:

[0121] Table 5: ICNL - incidents description

[0122] Day Time Type Event

[0123] 3 10:37 - 10:42 Operational Failure

[0124] 3 12:15 - 12:28 Operational Failure

[0125] 3 13:52 - 13:57 Operational Failure

[0126] 4 11:03 - 11:12 Operational Failure

[0127] 4 14:38 - 14:40 Operational Failure

[0128] 4 15:15 - 16:00 Operational Failure

[0129] 5 13:58 - 14:16 Cyber Attack Supply chain attack

[0130] 5 15:09 - 16:00 Operational Failure

[0131] Rogue master

[0132] 6 12:15 - 13:21 Cyber Attack + sensors port scan

[0133] 4- change tag value

[0134] 6 13:26 - 13:27 Cyber Attack Continue change tag value

[0135] 6 14:38 - 14:42 Operational Failure

[0136] 7 13:00 - 13:12 Cyber Attack Physhing + man-in-the-middle 7 14:36 - 14:38 Operational Failure

[0137] Rogue master

[0138] + sensors port scan

[0139] 7 14:53 - 15:45 Cyber Attack

[0140] + fool operator by changing presented tag value

[0141] The primary industrial network protocol used in the testbed is S7comm, with key devices including PLCs, an Engineering Workstation, HMI, and a Historian server. The physicallayer consisted of readings from 1,262 sensor values or states.

[0142] However, without initial sensor values stored at the beginning of the pilot, and because sensor data is logged only when updated, many sensors did not log their first update until later in the pilot. As a result, only 532 sensors that logged updates within the first 10 minutes of the first day could be used for training on benign days. Despite this challenge, the data from the 532 sensors was sufficient for example purposes. The inventors successfully trained physical anomaly detectors using the data from benign days 1 and 2, and predicted anomalies for days 3-7. Days 3-7 formed a test set with 14 incidents (5 cyberattacks and 9 operational failures) across 10,243 data points (10-second windows) out of 69,146 windows in test days.

[0143] The SWaT (Secure Water Treatment) dataset is a widely recognized benchmark in ICS security research, capturing data from a scaled-down water-treatment testbed. SWaT A6 2019 includes detailed records of both physical sensor readings and raw network traffic across various operational states, including normal operations and cyberattacks. The dataset records events starting at 10: 05 and lasting until 13: 45, with the following two manifested cyberattacks.

[0144] • First Attack (10:30-11:30): Infiltration of the Engineering Workstation via a USB thumb drive, delivering the first malware to exfiltrate Historian Data. This attack cycle consisted of 5 minutes of activity followed by 10 minutes of inactivity, repeated 4 times.

[0145] • Second Attack (12:30-13:30): A second malware infiltration, this time via download from a Commandand Control (C2 ) server, which disrupted sensor readings and interfered with the physical processes. This attack cycle consisted of 3 minutes of activity followed by 10 minutes of inactivity, repeated 5 times.

[0146] Due to the relatively short recording duration (3 hours and 40 minutes) and the regular operation of the physical data during the data exfiltration attack, the inventors manually selected physical data spanning 10: 05-12: 00 for the training set of the physical anomaly detector. The detection and correlation of physical alerts was then evaluated based only on the second Attack ( 12: 30-13: 30), resulting in a test set containing 5 incidents across 951 data points ( 10-second windows) out of 6, 297 tested windows ( 12: 00-13: 45).

[0147] The physical dataset included 81 sensor readings monitoring components across 6 key processes. The primary industrial network protocol used in the system is CIP, with key devices including PLCs, an Engineering Workstation, HMI, and a Historian server. The SWaT A6 dataset is publicly available through" iTrust, Centre for Research in Cyber Security, Singapore University of Technology and Design". The testbed environment is further described in SWaT A1& A2 2015 and is applicable to SWaT A6 2019.

[0148] The evaluation pipeline was implemented on an Intel(R) Core(TM) i7-8750H @ 2.20 GHz, Linux-based machine with 32 GB RAM. Parsing network data from PCAP files into log files was performed using Zeek. The data pre-processing, anomaly detectors, network classifier, explainer, clustering model, alert correlator, and analysis were implemented in Python.Two confusion matrices were calculated: one using the point-adjusted metric and the other using the point-wise metric shown in Fig. 4. Fig. 4 shows examples of point-adjusted and point-wise calculations, where each data point is binary classified as benign (black) or anomaly (red -brighter color). In point-wise assessment 430, each data point is treated separately. Only the anomalous data points that happen during the true event 410 are considered True Positive. If the event spans 4 data points 411 point-wise detection of two of them 421 will result in two true positives 431, and two false negatives 432. In contrast, for point-adjusted assessment 440 even a single anomaly detected during the even period 411 is sufficient to mark all event data points as true positives 441.

[0149] To evaluate incident detection, the inventors opted for the point-adjusted (pa) metric over the point-wise (pw) metric. ICS cyberattacks may last for a long time, with only certain windows including clear indications of the Attack. Thus, a single window marked as anomalous during an incident period is sufficient to identify all windows within that period as correctly detected.

[0150] On the other hand, to evaluate the actual number of alerts a cybersecurity specialist will investigate, the inventors opted for the point-wise (pw) metric.

[0151] In a practical context, a group of fused alerts can save a cybersecurity specialist significant time, as they can focus on investigating one or a few alerts within the group that share similar characteristics. Thus, for evaluation, a group of fused alerts was represented by the creation time of the first alert in the group, allowing for measuringwhether TP alerts were misgrouped with FP alerts outside of an incident period, which could lead to the cybersecurity specialist to investigate false alerts within the group, and potentially miss the incident. To assess the performance of this correlation methodology, the inventors employed several key metrics used in prior art works. First, the inventors differentiated between the overall / false alert reduction. The inventors also measured the false positive rate. Furthermore, the inventors measured the incident detection reduction:

[0152] • Reduction (Rede. ): This value defines the relative reduction of alerts when using correlation compared to no correlation. The inventors used point-wise calculation, allowing for the comparison of the actual number of alerts a cybersecurity specialist will receive. It is calculated as:

[0153] Rede.

[0154]

[0155] • False Positive Reduction (FP Rede. ): The relative reduction in false positives when using correlation compared to no correlation. It is calculated as:

[0156] FP Rede.

[0157]

[0158] • False Positive Rate (FP Rate): The rate at which normal events are incorrectly identified as anomalies. It is calculated as:FP

[0159] FP Rate

[0160]

[0161] FP+ TN

[0162] • Incident Detection Reduction ( IDR): The relative reduction in the number of incidents detected when using correlation compared to no correlation. Note that point-adjusted calculation was used, to allow consideration of an incident as detected if at least one alert was triggered during the incident period. It is calculated as:

[0163]

[0164] The rationale behind these metrics was to balance the reduction in false alerts and redundancies against the risk of missing actual cyber threats.

[0165] The experimental setup is now further described. The invention' s approach introduces a new alert-correlation technique at the physical layer, leveraging explanations from the network layer. To evaluate its performance, because related work mainly correlates network with physical alerts, the inventors compared the present approach with similarity-based correlation methods applied exclusively in the physical layer. These similarity-based methods used either hard constraints, requiring a full match between alert ' s attributes, like a small creation time delta, while monitoring the same sensor and equipment, or weaker thresholds, allowing partial matches for grouping. The inventors evaluated various threshold settings for grouping physical alerts on ICNL and SWaT A6 datasets and assessed their effectiveness, both with andwithout integrating the network explanation clusters (NEC) approach.

[0166] Given the critical nature of ICS environments, it is essential to prioritize detecting more incidents over minimizing false alerts, as missed incidents can lead to severe consequences. Thus, the baseline was defined as the combination of attributes and settings that yielded the lowest incident detection reduction ( IDR) while achieving an alert reduction rate (Rede. ) greater than 90%. The present approach incorporates NEC attributes alongside the baseline attributes and aims to achieve the same IDR & Reduction trade-off.

[0167] The results of the experiment performed on the ICNL dataset are shown in Table 2 ):

[0168] Table 2: ICNL - results (%)

[0169] FP FP

[0170] Criteria Rede. __,. IDR *

[0171] Rede. Rate

[0172] Uncorrelated - - 13.24 7 Baseline 99.88 99.95 00.01 14.29 6 Our Approach 99.74 99.87 00.02 00.00 7

[0173]

[0174] (*) refers to the amount of incidents detected.

[0175] The results indicate that the present invention' s approach of incorporating NEC (network explanation clusters), when grouping physical alerts, reduced 99.74% of total alerts and specifically reduced false alerts by 99.87%, resulting in only 10 false alerts and an FP rate of 0.02%, with no reduction in incident detection capabilities. Groupingalerts based on similarity using baseline attributes (i. e., creation time, equipment id, etc. ) achieved a slightly higher FP reduction of 99.88%, resulting in only 4 false alerts and FP rate of 0.01% (as shown in Table 6 below), but at the cost of missing 1 incident out of 7 detected incidents before correlation, leading to incident detection reduction of 14.29%. This is shown in col. of Table 2 above, showing the number of incidents detected, out of 7 incidents overall.

[0176] Table 6: ICNL - confusion matrix

[0177] „... TP FN TP FN Criteria,.,. FP TN,.,.

[0178] (pa) (pa) (pw) (pw) Uncorrelated 7450 2793 7797 51106 1510 8733 TD 7140 3103 4 >8899 7 10236 PC 6520 3723 3 58900 5 10238 NEC 6350 3893 5 58898 5 10238 TD+PC 7140 3103 6 58897 8 10235 TD+NEC 7450 2793 10 58893 14 10229 PC+NEC 7140 3103 8 58895 10 10233

[0179]

[0180] TD+PC+NEC 7450 2793 13 58890 15 10228

[0181] The explainability of alerts was also analyzed. Explanations of alerts caused by operational failures or cyberattacks were reduced to 2 dimensions using PCA and TSNE, and the results were plotted. Fig. 5 shows ICNL 2D SHAP values using PCA (colored by activity). The figure shows the PCA SHAP values with activity coloring (excluding normal). Fig. 6 shows ICNL 2D SHAP values using TSNE (colored by activity). The figure shows the 2D TSNE SHAP values with activity coloring (excluding normal).

[0182] The results of the experiment performed on the SWaT A6 dataset are shown in Table 3):Table 3: SWaT A6 - results (%)

[0183] Criter ■ia R T,ed ie. FP FP,T

[0184]

[0185] IDR * *

[0186] Rede. Rate

[0187] Uncorrelated - - 41.30 - 5

[0188] Baseline 99.83 99.91 00.04 40.00 3

[0189] Our Approach 99.46 99.87 00.22 00.00 5

[0190] (*) refers to the amount of incidents detected.

[0191] The results of Table 3 indicate that the present invention' s approach of incorporating NEC, when grouping physical alerts, reduces the total alerts by 99.46% and specifically reduces false alerts by 99.87% (at least in the experiment performed), resulting in only 12 false alerts and an FP rate of 0.22%, with no reduction in incident detection capabilities. Grouping alerts based on similarity using baseline attributes (i. e., creation time, equipment id, etc. ), achieved a slightly higher FP reduction of 99.91%, resulting in only 2 false alerts and FP rate of 0.04%, but at the cost of missing 2 incidents out of 5 detected incidents before correlation, leading to an incident detection reduction of 40%.

[0192] The evaluation' s results on both the ICNL and SWaT A6 datasets highlight several important findings. First, the integration of Network Explanation Clusters (NEC) consistently demonstrated a significant reduction in false positives (FP) across both datasets, without compromising incident detection. This shows that incorporating network explanations can significantly improve the efficiency of physical alert correlation. Moreover, relying solely on baseline alert attributes for grouping can lead to overgrouping alerts, which may result in fewer but misleading alert groups. This increases the risk of missing critical incidents, as cybersecurity specialists may overlookimportant threats hidden within these overly broad alert groups. The NEC-based approach strikes a balance between reducing false alerts and preserving correct detections, making it an effective solution for alert correlation in complex environments. By ensuring that grouped alerts exhibit similar network behaviors, NEC not only reduces physical false alerts but also provides deeper context, helping specialists prioritize their investigations. Each physical alert is accompanied by a plot that visualizes the network features that contribute most to its classification as an alert. For example, Fig. 7 shows anomalies discovered in temperature sensor measurements. Specifically, it shows the sensor ' s data with spikes during an attack interval. Fig. 8 shows a network explanation of a physical alert generated during an attack, in which the attacker gained access to the Human-Machine Interface (HMI ) and issued a write command to a temperature sensor connected to PLC1. Specifically, Fig. 8 shows for the mentioned spike (triggered alert) of Fig. 7, the network features that are most closely related to the physical alert triggering.

[0193] An explanation feature can be expanded to reveal related packets using simple filters (e. g., using Wireshark as was done in Fig. 9). The figure shows for a selected network feature the relevant packets. The text that mentions this step is achieved by filtering for packets that share attributes with one of the network features, like a write command written in s7comm protocol in a specific time with the source IP of the HMI and the destination IP of the PLC. Expanding" Write Variable HMI to PLC1 3.0min" 292a presents all packets 295 3 minutes before the anomaly creation time that match the source / destination IPs of HMI or PLC1, and uses the S7comm protocol with the write variable function.As shown, the invention provides a structure for accurately detecting and accurately directing to malicious actions that result in faults within the ICS. Moreover, the inventors ' analysis suggests that while traditional similarity-based methods can reduce false positives, the inclusion of network-based explanations through NEC provides a more robust and explainable approach. The invention ensures that fewer critical alerts are missed and reduces the investigation workload for cybersecurity specialists, without sacrificing the detection of key incidents.

Claims

Claims1. A system for detecting network-originated malicious activity in an industrial control system ( ICS), comprising:an unsupervised anomaly detector receiving sensor ' s data from the ICS, and outputting a labeled signal; a supervised network classifier trained by network traffic and by said labeled signal outputted from said unsupervised anomaly detector, said supervised network classifier creating a supervised anomaly prediction model;said supervised anomaly prediction model receiving during runtime said network traffic and said labeled signal, and configured to determine a state of anomaly; anda XAI-type explainer configured to inspect said anomaly prediction model during its operation, and output elements of the network traffic that contribute most to said anomaly state determined by said supervised anomaly prediction model.

2. The system of claim 1, further comprising a feature extraction unit, configured to extract traffic features used as (i) inputs for training said supervised network classifier and (ii) inputs to said supervised anomaly detection model.

3. The system of claim 2, wherein said elements of the network traffic determined to contribute most to the anomaly state are features selected from said extracted features inputted into said supervised anomaly prediction model.

4. The system of claim 1, wherein said supervised network classifier is deep-learning-trained by the network traffic, and wherein said elements of the networktraffic determined to contribute most to the anomaly state are highlighted.

5. The system of claim 3, further comprising a reverse engineering unit for determining specific packets or instructions that contribute most to the anomaly state, from among said features determined to contribute most to the anomaly state.

6. The system of claim 4 or claim 5, wherein said determined features, packets, or instructions are selected from within a time period T preceding the detection of the anomaly.

7. The system of claim 2, wherein at least some of said features are predefined.

8. The system of claim 6, further comprising a grouping unit, configured to eliminate repetitions in said features, packets, or instructions determined to contribute most to the anomaly.

9. The system of claim 1, wherein said supervised network classifier is trained offline, during runtime, or a combination thereof.

10. A method for detecting network-originated malicious activity in an industrial control system ( ICS), comprising:providing an unsupervised anomaly detector receiving sensor ' s data from the ICS, and outputting a labeled signal;providing a supervised network classifier trained by network traffic and by said labeled signal outputted from said unsupervised anomaly detector, said supervised network classifier creating a supervised anomaly prediction model; configuring said supervised anomaly prediction model to receive during runtime said network traffic andsaid labeled signal, and to determine a state of anomaly; andconfiguring an XAI-type explainer to inspect said anomaly prediction model during its operation, and to output elements of the network traffic that contribute most to said anomaly state determined by said supervised anomaly prediction model.

11. The method of claim 10, further providing a feature extraction unit, configured to extract traffic features used as (i) inputs for training said supervised network classifier and (ii) inputs to said supervised anomaly detection model.

12. The method of claim 11, wherein said elements of the network traffic determined to contribute most to the anomaly state are features selected from said extracted features inputted into said supervised anomaly prediction model.

13. The method of claim 10, wherein said supervised network classifier is deep-learning-trained by the network traffic, and wherein said elements of the network traffic determined to contribute most to the anomaly state are highlighted.

14. The method of claim 12, providing a reverse engineering unit for determining specific packets or instructions that contribute most to the anomaly state, from among said features determined to contribute most to the anomaly state.

15. The method of claim 13 or claim 14, wherein said determined features, packets, or instructions are selected from within a time period T preceding the detection of the anomaly.

16. The method of claim 11, further comprising predefining of at least some of said features.

17. The method of claim 15, further providing a grouping unit, configured to eliminate repetitions in said features, packets, or instructions determined to contribute most to the anomaly.

18. The method of claim 10, further training said supervised network classifier offline, during runtime, or a combination thereof.

Images