TECHNICAL FIELD

The invention relates to an anomaly detection system and method.

BACKGROUND

Organizational networks can include: (a) Operational Technology (OT) systems, including hardware and software dedicated to detecting or causing changes in physical processes through direct monitoring and/or control of physical devices such as valves, pumps, sensors, etc.; and (b) Information Technology (IT) systems, being data-centric systems for the collection, organization, storage and communication of information. The OT systems and the IT systems can be connected to the organizational network via a network infrastructure that can be wired, wireless, or a combination of wired and wireless network infrastructure.

In many cases, the content of some of the packets passing through the organizational network as part of the network traffic cannot be readily assessed by cyber-protection systems, as gaining knowledge of such content requires performing Deep Packet Inspection (DPI). This can require knowledge of the structure of the packets, and of structures of commands (included within the packets) transmitted between the IT systems and/or the OT systems.

Without having knowledge of the structure of the packets, and the structures of commands, it is not possible to identify various anomalies related to such information. There is thus a need in the art for a new anomaly detection system and method.

References considered to be relevant as background to the presently disclosed subject matter are listed below. Acknowledgement of the references herein is not to be inferred as meaning that these are in any way relevant to the patentability of the presently disclosed subject matter.

US Patent No. 9,386,034 (Cochenour) published on July 5, 2016, discloses a method of protecting a computing system or device against a malicious threat such as malware comprises generating a behavioral model configured to describe one or more interactions associated with a protected data accessible by way of a computing device. The method also comprises determining an attempt to access the protected is abnormal based, at least in part, on a comparison between the attempt to access the protected data and the behavioral model. The method further comprises determining the abnormal attempt to access the protected data is a malicious process based, at least in part, on a determined degree of variation from the behavioral model. The method additionally comprises causing, by a processor, the malicious process to be remediated with respect to the computing device.

US Patent Application No. 2017/0251012 (Stockdale et al.) published on August 31, 2017, discloses a method for use in detection of abnormal behavior of a group of a plurality of entities of a computer system. The method is arranged to be performed by a processing system and includes: creating a model of normal behavior of the group of entiti es; and determining, in accordance with the model of normal behavior of the group of entities, a parameter indicative of abnormal behavior of the group of entities. Also disclosed is an equivalent computer readable medium and anomalous behavior detection system.

US Patent Application No. 2016/0261482 (Mixer et al.) published on September 8, 2016, discloses an anomaly detection system installed in a plant communications network detects unexpected changes or anomalies in the traffic patterns over the communications network to detect infected or potentially infected nodes. The anomaly detection system includes various data collection modules at each of the nodes of the network which operate to view the message traffic into and out of the node and to generate metadata pertaining to the message traffic. The communication modules at the nodes send the traffic metadata to an anomaly analysis engine, which processes the metadata using a rules engine that analyzes the metadata using a set of logic rules and traffic pattern baseline data to determine if current traffic patterns at one or more network nodes are anomalous. If so, the analysis engine may generate an alert or message to a user informing the user of the potentially infected node, may automatically disconnect the node from the network, or may take some other action to minimize the effects of an infected node.

US Patent Application No. 2017/0126745 (Taylor) published on May 4, 2017, discloses a system for providing intrusion detection for industrial control systems, comprising serial data links to communicate with serial-based networks, Ethernet interfaces to communicate with industrial and enterprise networks, a protocol recognition engine to break down an incoming data packet by protocol and integrate the data into an Ethernet framework, an industrial control system recognition application to detect intrusions, a traffic analytics application to analyze traffic activity for abnormal traffic activity, a logfile creation application to poll industrial equipment and create a logfile of equipment statuses, a long term system deviation analysis application to monitor raw' data of the industrial equipment to create a profile of long term system activity, a rule set to allow data that matches the rule set and flag data that does not match the rule set, and an alerts engine to alert a system administrator of suspect activity.

US Patent Application No. 2016/0173511 (Bratspiess et al.) published on June 16, 2016, discloses a network security system for a network, the network comprising a plurality of networked appliances, the security system comprising one or more security devices, wherein each security device of the one or more security devices is associated with one or more networked security appliances of the plurality of networked security appliances, and wherein each security device comprises: a network interface comprising one or more ports, wherein each networked security appliance of the one or more networked security appliances associated with the security device is operatively coupled with the security device via a different port of the ports; at least one processor configured to: upon initial setup of said security device, create a baseline profile of an activity of the network, and following an activation of a protection mode, identify an irregular event by detecting a deviation of network traffic passing through a port of the ports from said baseline profile.

US Patent Application No. 2015/0301515 (Houmb) published on October 22, 2015, discloses a method is for monitoring an industrial control system. The method comprises collecting data from one or more sources external to the industrial control system; collecting data from one or more internal sources on the industrial control system; aggregating data collected from said internal sources or from said external sources; correlating said collected data by analyzing and interpreting said collected data in view' of previously collected data so as to monitor the security of the industrial control system. An apparatus is for performing the method.

US Patent Application No. 2017/0293757 (Rosenman et al.) published on October 12, 2017, discloses to enhance the security of an industrial control system, a data stream can be received from an input device via a communications network or an US Patent Application No. 2017/0293757 (Rosenman et al.) published on October 12, 2017, discloses to enhance the security of an industrial control system, a data stream can be received from an input device via a communications network or an I/O subsystem of a computer system. All or part of the data stream can be stored in computer memory. Stored elements of the data stream can be retrieved from the memory. A set of program instructions can be executed to ascertain descriptive characteristics of the stored elements. Using a comparison with a stored normative descriptive characteristic in a database or application of an algorithm, heuristic or rule, it can be determined whether any of the descriptive characteristics are anomalous. When the existence of an anomalous descriptive characteristic has been determined, an alarm can be created, data or an alarm can be communicated to a control system or an operator, and/or the data or alarm can be recorded in a database.

US Patent Application No. 2006/0242706 (Ross) published on October 26, 2006, discloses methods, systems, and processor readable medium for selecting an anomaly detector for a system, including: generating an anomaly detector (.AD) candidate population by characterizing AD candidates by one or more system parameters and system attributes (collectively herein,“system attributes”); training the AD candidate population using non-anomaly data associated with the system and the system attribute(s); evaluating the AD candidate population based on applying non anomaly and anomaly data associated with the system to the AD candidate population; and, based on at least one search criterion, performing at least one of (i) selecting an AD candidate from the AD population; and, (ii) modifying the AD candidate population and iteratively returning to training the AD candidate population.

US Patent Application No. 2013/0121161 (Szabo et al,) published on May 16, 2013, discloses an entity in a telecommunications network, for example a user equipment, determines a threshold value relating to a channel switching parameter that is being used by the telecommunications network to trigger a channel switching operation, and uses this threshold value and monitored traffic information to prevent a channel change from occurring, i.e. to maintain channel occupancy. A network node is adapted to remove additional traffic that has been generated by an entity in the telecommunications network to maintain channel occupancy. GENERAL DESCRIPTION

In accordance of a first aspect of the presently disclosed subject matter, there is provided an anomaly detection system, the anomaly detection system comprising a processing resource configured to: obtain a baseline identifying authorized network traffic patterns within a network, each authorized network traffic pattern including information of a source entity, a destination entity, and a command; identify a plurality of network traffic patterns using Deep Packet Inspection (DPI) of raw network traffic data passing through the network, the raw network traffic data comprising a plurality of packets, wherein at least some of the packets originate from, or designate, an Operational Technology (OT) system, and wherein at least one of the network traffic patterns involves the OT system; compare the plurality of network traffic patterns to the baseline; and provide an alert upon one or more of the plurality of network traffic patterns not being within the baseline.

In some cases, the processing resource is further configured to generate the baseline by: identifying a plurality of baseline network traffic patterns by analyzing, over a given time period occurring before the obtain, a plurality of second network traffic patterns using DPI of second raw network traffic data passing through the network during the given time period, the second raw network traffic data comprising a plurality of second packets, wherein each baseline network traffic pattern includes second information of a second source entity, a second destination entity and a second command; and inserting the plurality of baseline network traffic patterns into the baseline.

In some cases, at least some of the second packets originate from, or designate, the OT system, and wherein at least one of the second network traffic patterns involves the OT system.

In some cases, the identifying of the plurality of baseline network traffic patterns is based on one or more baseline pattern identification rules.

In some cases, the at least one of the baseline pattern identification rales requires reoccurrence of the corresponding baseline network traffic patterns.

In some cases, the command includes indications of: (a) a service associated with the command, and (b) one or more values to be assigned to one or more respective registers controlled by the command. In some cases, the second command includes second indications of; (a) a second service associated with the second command, and (b) one or more second values to be assigned to one or more respective second registers controlled by the second command.

In some cases, the given time period depends on a topology of the network.

In some cases, the processing resource is further configured to update the baseline by adding new authorized network traffic patterns or by removing one of the authorized network traffic patterns.

In some cases, the analyzing includes analysis of a plurality of communication layers of the second raw network traffic data.

In some cases, the analyzing includes analysis of all of the communication layers of the second raw network traffic data.

In some cases, at least part of the packets are proprietary-format packets, sent in a proprietary format encapsulating an internal format, and wherein the identify includes decrypting the proprietary-format packets to obtain the internal format.

In some cases, the internal format is an Internet Protocol (IP) format.

In some cases, the baseline further identifies at least one sequence comprising at least a first authorized network traffic pattern of the authorized network traffic patterns and a second authorized network traffic pattern of the authorized network traffic patterns, and an allowed time-period allowed to pass between identification of the first authorized network traffic pattern and the second authorized network traffic pattern; and wherein the processing resource is further configured to perform the following to identify sequence anomalies: identify, within the raw ^? network traffic data, a first instance of the first authorized network traffic pattern, monitor the raw network traffic data to identify a second instance of the second authorized network traffic pattern; and provide a second alert upon the maximal allowed time-period lapsing before identification of the second instance or upon the second instance being identified before the minimal allowed time-period passed from identification of the first instance

In accordance of a second aspect of the presently disclosed subject matter, there is provided an anomaly detection method comprising: obtaining, by a processing resource, a baseline identifying authorized network traffic patterns within a network, each authorized network traffic pattern including information of a source entity, a destination entity, and a command; identifying, by the processing resource, a plurality of network traffic patterns using Deep Packet Inspection (DPI) of raw netwOrk traffic data passing through the network, the raw network traffic data comprising a plurality of packets, wherein at least some of the packets originate from, or designate, an Operational Technology (OT) system, and wherein at least one of the network traffic patterns involves the OT system; comparing, by the processing resource, the plurality of network traffic patterns to the baseline; and providing, by the processing resource, an alert upon one or more of the plurality of network traffic patterns not being within the baseline.

In some cases, the method further comprised generating the baseline by; identifying, by the processing resource, a plurality of baseline network traffic patterns by analyzing, over a given time period occurring before the obtain, a plurality of second network traffic patterns using DPI of second raw network traffic data passing through the network during the given time period, the second raw network traffic data comprising a plurality of second packets, wherein each baseline network traffic pattern includes second information of a second source entity, a second destination entity and a second command, and inserting, by the processing resource, the plurality of baseline network traffic patterns into the baseline.

In some cases, at least some of the second packets originate from, or designate, the OT system, and wherein at least one of the second network traffic patterns involves the OT system.

In some cases, the identifying of the plurality of baseline network traffic patterns is based on one or more baseline pattern identification rules.

In some cases, at least one of the baseline pattern identification rules requires reoccurrence of the corresponding baseline network traffic patterns.

In some cases, the command includes indications of: (a) a sendee associated with the command, and (b) one or more values to be assigned to one or more respective registers controlled by the command.

In some cases, the second command includes second indications of: (a) a second sendee associated with the second command, and (b) one or more second values to be assigned to one or more respective second registers controlled by the second command.

In some cases, the given time period depends on a topology of the network. In some cases, the method further comprises updating the baseline by adding new authorized network traffic patterns or by removing one of the authorized network traffic patterns.

In some cases, the analyzing includes analysis of a plurality of communication layers of the second raw network traffic data.

In some cases, the analyzing includes analysis of all of the communication layers of the second raw network traffic data.

In some cases, at least part of the packets are proprietary-format packets, sent in a proprietary format encapsulating an internal format, and wherein the identifying includes decrypting the proprietary-format packets to obtain the internal format.

In some cases, the internal format is an Internet Protocol (IP) format.

In some cases, the baseline further identifies at least one sequence comprising at least a first authorized network traffic pattern of the authorized network traffic patterns and a second authorized network traffic pattern of the authorized network traffic patterns, and an allowed time-period allowed to pass between identification of the first authorized network traffic pattern and the second authorized network traffic pattern; and the method further comprises performing the following for identifying sequence anomalies: identifying, by the processing resource, within the raw network traffic data, a first instance of the first authorized network traffic pattern; monitoring, by the processing resource, the raw network traffic data to identify a second instance of the second authorized network traffic pattern; and providing, by the processing resource, a second alert upon the maximal allowed time-period lapsing before identification of the second instance or upon the second instance being identified before the minimal allowed time-period passed from identification of the first instance.

In accordance of a third aspect of the presently disclosed subject matter, there is provided a non-transitory computer readable storage medium having computer readable program code embodied therewith, the computer readable program code, executable by at least one processor of a computer to perform a method comprising: obtaining, by a processing resource, a baseline identifying authorized network traffic patterns within a network, each authorized network traffic pattern including information of a source entity, a destination entity, and a command; identifying, by the processing resource, a pluraiity of network traffic paterns using Deep Packet Inspection (DPI) of raw network traffic data passing through the network, the raw network traffic data comprising a plurality of packets, wherein at least some of the packets originate from, or designate, an Operational Technology (OT) system, and wherein at least one of the network traffic patterns involves the OT system; comparing, by the processing resource, the plurality of network traffic patterns to the baseline; and providing, by the processing resource, an alert upon one or more of the plurality of network traffic patterns not being within the baseline.

In accordance of a fourth aspect of the presently disclosed subject matter, there is provided an anomaly detection system, the anomaly detection system comprising a processing resource configured to: provide, for each Operational Technology (OT) entity of a plurality of OT entities, an inactivity rule-set comprising one or more rules defining a permissibl e inactivity pattern thereof being i ndi cati ve of time intervals during which inactivity of the OT entity is permissible, wherein the OT entities are connected to a network; monitor network traffic passing through the network to identify OT commands associated with the OT entities by performing Deep Packet Inspection (DPI) of the network traffic; and provide an alert upon the inactivity rale-set not being met.

In some cases, at least one of the rules defines a sliding window during which the respective OT entity is permitted to be inactive.

In some cases, the sliding window’s length dynamically changes according to one or more of: (a) a time of day; and (b) a date.

In some cases, at least one of the rules defines time slots during which the respective OT entity is permitted to be inactive.

In some cases, the processing resource is further configured to determine the rule-set comprising the rales defining the permissible inactivity pattern of each of the OT entities by: analyzing, over a given time period occurring before the provide, past network traffic passing through the network by performing DPI of the past network traffic to identify timestamps of past OT commands associated with the corresponding OT entity, determining the permissible inactivity pattern based on the timestamps; and determining the rule-set according to the permissible inactivity pattern. In some cases, the permissible inactivity pattern is determined by calculating an average time between the timestamps during the given time period.

In some cases, the permissible inactivity pattern is determined by calculating the maximal time between the timestamps during the given time period.

In some cases, each OT command has a corresponding OT command type and wherein the permissible inactivity pattern is determined by calculating an average time between the timestamps of the OT commands having a common OT command type during the given time period.

In some cases, each OT command has a corresponding OT command type and wherein the permissible inactivity pattern is determined by calculating a maximal time between the timestamps of the OT commands having a common OT command type during the given time period .

In accordance of a fifth aspect of the presently disclosed subject matter, there is provided an anomaly detection method, the anomaly detection method comprising: providing, by a processing resource, for each Operational Technology (OT) entity of a plurality of OT entities, an inactivity rule-set comprising one or more rules defining a permissible inactivity pattern thereof being indicative of time intervals during which inactivity of the OT entity is permissible, wherein the OT entities are connected to a network; monitoring, by the processing resource, network traffic passing through the network to identify OT commands associated with the OT entities by performing Deep Packet Inspection (DPI) of the network traffic; and providing, by the processing resource, an alert upon the inactivity rule-set not being met.

In some cases, at least one of the rules defines a sliding window during which the respective OT entity is permitted to be inactive.

In some cases, the sliding window’s length dynamically changes according to one or more of: (a) a time of day; and (b) a date.

In some cases, at least one of the rules defines time slots during which the respective OT entity is permitted to be inactive.

In some cases, the method further comprises determining the rule-set comprising the rules defining the permissible inactivity pattern of each of the OT entities by: analyzing, over a given time period occurring before the provide, past network traffic passing through the network by performing DPI of the past network traffic to identify timestamps of past OT commands associated with the corresponding OT entity; determining the permissible inactivity pattern based on the timestamps; and determining the rule-set according to the permissible inactivity pattern.

In some cases, the permissible inactivity pattern is determined by calculating an average time between the timestamps during the given time period.

In some cases, the permissible inactivity pattern is determined by calculating the maximal time between the timestamps during the given time period.

In some cases, each OT command has a corresponding OT command type and wherein the permissible inactivity pattern is determined by calculating an average time between the timestamps of the OT commands having a common OT command type during the given time period.

In some cases, each OT command has a corresponding OT command type and wherein the permissible inactivity pattern is determined by calculating a maximal time between the timestamps of the OT commands having a common OT command type during the given time period.

In accordance of a sixth aspect of the presently disclosed subject matter, there is provided a n on-transitory computer readable storage medium having computer readable program code embodied therewith, the computer readable program code, executable by at least one processor of a computer to perform a method comprising: providing, by a processing resource, for each Operational Technology (OT) entity of a plurality of OT entities, an inactivity rule-set comprising one or more rules defining a permissible inactivity pattern thereof being indicative of time intervals during which inactivity of the OT entity is permissible, wherein the OT entities are connected to a network; monitoring, by the processing resource, network traffic passing through the network to identify OT commands associated with the OT entities by performing Deep Packet Inspection (DPI) of the network traffic, and providing, by the processing resource, an alert upon the inactivity rule-set not being met.

BRIEF DESCRIPTION OF THE DRAWINGS In order to understand the presently disclosed subject matter and to see how it may be carried out in practice, the subject matter will now be described, by way of non- limiting examples only, with reference to the accompanying drawings, in which:

Fig. 1 is a schematic illustration of an exemplary organizational network, in accordance with the presently disclosed subject matter,

Fig. 2 is a block diagram schematically illustrating one example of an anomaly detection system, in accordance with the presently disclosed subject matter;

Fig. 3 is a flowchart illustrating one example of a sequence of operations carried out for detecting anomalies, in accordance with the presently disclosed subject matter;

Fig. 4 is a flowchart illustrating one example of a sequence of operations carried out for generating a baseline usable for identification of anomalies, in accordance with the presently disclosed subject matter; and

Fig. 5 is a flowchart illustrating one example of a sequence of operations carried out for detecting anomalies within sequences of network traffic patterns, in accordance with the presently disclosed subject matter.

DETAILED DESCRIPTION

In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the presently disclosed subject matter. However, it will be understood by those skilled in the art that the presently disclosed subject matter may be practiced without these specific details. In other instances, well- known methods, procedures, and components have not been described in detail so as not to obscure the presently disclosed subject matter.

In the drawings and descriptions set forth, identical reference numerals indicate those components that are common to different embodiments or configurations.

Unless specifically stated otherwise, as apparent from the following discussions, it is appreciated that throughout the specification discussions utilizing terms such as "identifying", "obtaining", "comparing", "providing", "inserting", “generating”, “updating”,“monitoring”, or the like, include action and/or processes of a computer that manipulate and/or transform data into other data, said data represented as physical quantities, e.g. such as electronic quantities, and/or said data representing the physical objects. The terms“computer”,“processor”, and“controller” should be expansively construed to cover any kind of electronic device with data processing capabilities, including, by way of non-limiting example, a personal desktop/laptop computer, a server, a computing system, a communication device, a smartphone, a tablet computer, a smart television, a processor (e.g. digital signal processor (DSP), a microcontroller, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc.), a group of multiple physical machines sharing performance of various tasks, virtual servers co-residing on a single physical machine, any other electronic computing device, and/or any combination thereof.

The operations in accordance with the teachings herein may be performed by a computer specially constructed for the desired purposes or by a general-purpose computer specially configured for the desired purpose by a computer program stored in a n on-transitory computer readable storage medium. The term "non-transitory" is used herein to exclude transitory, propagating signals, but to otherwise include any volatile or non-volatile computer memory technology suitable to the application.

As used herein, the phrase "for example," "such as", "for instance" and variants thereof describe non-limiting embodiments of the presently disclosed subject matter. Reference in the specification to "one case", "some cases", "other cases" or variants thereof means that a particular feature, structure or characteristic described in connection with the embodiment(s) is included in at least one embodiment of the presently disclosed subject matter. Thus, the appearance of the phrase "one case", "some cases", "other cases" or variants thereof does not necessarily refer to the same embodiment(s).

It is appreciated that, unless specifically stated otherwise, certain features of the presently disclosed subject matter, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the presently disclosed subject matter, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable sub-combination.

In embodiments of the presently disclosed subject matter, fewer, more and/or different stages than those shown in Fig. 3-7 may be executed. In embodiments of the presently disclosed subject matter one or more stages illustrated in Fig. 3-7 may be executed in a different order and/or one or more groups of stages may be executed simultaneously. Figs. 1-2 illustrate a general schematic of the system architecture in accordance with an embodiment of the presently disclosed subject matter. Each module in Figs. 1-2 can be made up of any combination of software, hardware and/or firmware that performs the functions as defined and explained herein. The modules in Figs. 1-2 may be centralized in one location or dispersed over more than one location. In other embodiments of the presently disclosed subject matter, the system may comprise fewer, more, and/or different modules than those shown in Figs. 1-2.

Any reference in the specification to a method should be applied mutatis mutandis to a system capable of executing the method and should be applied mutatis mutandis to a non-transitory computer readable medium that stores instructions that once executed by a computer result in the execution of the method.

Any reference in the specification to a system should be applied mutatis mutandis to a method that may be executed by the system and should be applied mutatis mutandis to a non-transitory computer readable medium that stores instructions that may be executed by the system.

Any reference in the specification to a non-transitory computer readable medium should be applied mutatis mutandis to a system capable of executing the instructions stored in the non-transitory computer readable medium and should be applied mutatis mutandis to method that may be executed by a computer that reads the instructions stored in the non-transitory computer readable medium.

Bearing this in mind, attention is drawn to Fig. 1, a schematic illustration of an exemplary organizational network, in accordance with the presently disclosed subject matter.

According to some examples of the presently disclosed subject matter, a network 105 (also referred to herein as:“organizational network”) can be provided. The network 105 can be comprised of one or more interconnected computerized networks, that can optionally be distributed over a plurality of geographical locations. The network 105 can include Information Technology (IT) systems 110, such as IT devices 120-a, 120-b, ... 120-n (n being an integer), and Operational Technology systems 130, such as controllers 140-a, 140-b, ... , 140-m (m being an integer, equal to n or not). Each controller (e.g. 140-a, ..., 140-m) can optionally be connected to one or more physical OT devices, such as valve/s 152, thermometer/s 154, sensor/s 156, etc., or to one or more other controllers. It is to be noted that in some cases, a single controller (e.g 140- a) can be connected to a plurality of physical OT devices (e.g. valve 152 and thermometer 154) and/or to a plurality of other controllers. Each of the OT systems 130 and IT systems 110 can be connected to the network 105 via a computerized network infrastructure that can be wired, wireless, or a combination of wired and wireless network infrastructure. It is to be noted that throughout the description the terms OT system/s 130 and OT entity/ies are used interchangeably.

The organizational network 105 further comprises, or otherwise associated with, an anomaly detection system 100. The anomaly detection system 100 can be configured to identify anomalies within network traffic patterns, inter alia by analyzing raw network traffic data passing through the network 105, as further detailed herein inter alia with reference to Fig. 3. The raw network traffic data includes packets originating from the IT systems 110 and from the OT systems 130.

The anomaly detection system 100 can be additionally, or alternatively, configured to monitor compliance of OT entities (e.g. controllers (e.g. 140-a, ... , 140- m) and other physical OT devices, such as valve/s 152, thermometer/s 154, sensor/s 156, etc.) with respective inactivity rule-sets that define a permissible inactivity pattern thereof, as further detailed herein, inter alia with reference to Fig. 6.

Fig. 2 is a block diagram schematically illustrating one example of an anomaly detection system, in accordance with the presently disclosed subject matter.

According to certain examples of the presently disclosed subject matter, anomaly detection system 100 can comprise a network interface 220 enabling connecting the anomaly detection system 100 to the network 105 and enabling it to send and receive data sent thereto via the network 105, including receiving raw network traffic data that includes packets originating from the IT systems 110 and from the OT systems 130.

Anomaly detection system 100 can further comprise or be otherwise associated with a data repository 220 (e.g. a database, a storage system, a memory' including Read Only Memory - ROM, Random Access Memory - RAM, or any other type of memory , etc.) configured to store data, including, inter alia, a baseline identifying authorized network traffic patterns within the network 105, each authorized network traffic pattern including information of a source entity, a destination entity, and a command, as further detailed herein, inter alia with reference to Figs. 3 and 4. The baseline can be used by the anomaly detection system 100 to identify anomalies in network traffic patterns that are identified from raw network traffic data passing through the network 105. The data repository 220 can additionally, or alternatively, store inactivity rule-sets associated with respective OT entities (e.g. controllers (e.g. 140-a, 140-m) and other physical

OT devices, such as valve/s 152, thermometer/s 154, sensor/s 156, etc ), each rule-set comprising one or more rules defining a permissible inactivity pattern of the respective OT entity being indicative of time intervals during which inactivity of the respective OT entity is permissible, as further detailed herein, inter alia with reference to Figs. 6 and 7.

Anomaly detection system 100 further comprises a processing resource 230. Processing resource 230 can be one or more processing units (e.g. central processing units), microprocessors, microcontrollers (e.g. microcontroller units (MCUs)) or any other computing devices or modules, including multiple and/or parallel and/or distributed processing units, which are adapted to independently or cooperatively process data for controlling relevant anomaly detection system 100 resources and for enabling operations related to anomaly detection system 100 resources.

The processing resource 230 can one or more of the following modules: baseline module 240, anomaly detection module 250, DPI module 260, sequence anomaly detection module 270 and inactivity rule-set determination module 280.

Baseline module 240 can be configured to perform a baseline generation process, for creating a baseline identifying authorized network traffic patterns within the network 105, each authorized network traffic pattern including information of a source entity, a destination entity, and a command, as further detailed herein, inter alia with reference to Fig. 4.

Anomaly detection module 250 can be configured to detect anomalies from the baseline in network traffic patterns that are identified from raw network traffic data passing through the network 105, as further detailed herein, inter alia with reference to Fig. 3. Additionally, or alternatively, anomaly detection module 250 can be configured to monitor compliance of OT entities with respective inactivity rule-sets indicative of a permissible inactivity pattern of the respective OT entity being indicative of time intervals during which inactivity of the respective OT entity is permissible, as further detailed herein, inter alia with reference to Fig. 6. DPI module 260 can be configured to perform deep packet inspection using various methods and/or techniques, either known or proprietary.

Sequence anomaly detection module 270 can be configured to identify anomalies in sequences of network traffic patterns, as further detailed herein, inter alia with reference to Fig. 5.

Inactivity rule-set determination module 280 can be configured to perform an inactivity rule-sets determination process, for determining rule-sets identifying permissible inactivity patterns of respective OT entities, being indicative of time intervals during which inactivity of the respective OT entity is permissible, as further detailed herein, inter alia with reference to Fig. 7.

Turning to Fig. 3, there is shown a flowchart illustrating one example of a sequence of operations carried out for detecting anomalies, in accordance with the presently disclosed subject matter.

According to certain examples of the presently disclosed subject matter, anomaly detection system 100 can be configured to perform an anomaly detection process 300, e.g. utilizing the anomaly detection module 250.

For this purpose, anomaly detection system 100 is configured to obtain a baseline identifying authorized network traffic patterns within the network 105, each authorized network traffic pattern including information of a source entity, a destination entity, and a command (block 310). The process of generating the baseline is explained herein, with reference to Fig. 4 It is to be noted that in some cases there may be more than one baseline, e.g. one baseline for routine operation and another baseline for training puiposes, etc.

Anomaly detection system 100 is further configured to identify a plurality of network traffic patterns using DPI (e.g. utilizing DPI module 260) of raw network traffic data passing through the network 105, the raw network traffic data comprising a plurality of packets (block 320). At least some of the packets comprising the raw network traffic data originate from, or designate, at least one of the OT systems 130, and at least one of the network traffic patterns involves such OT system 130.

As indicated above, a network traffic pattern includes information of s source entity (being the entity from which the network traffic pattern originates), a destination entity (being the entity designated by the network traffic pattern), and a command (being an instruction sent from the source entity to the destination entity, instructing the destination entity perform a certain action). The command can include indications of: (a) a sendee associated with the command, (b) one or more values to be assigned to one or more sections in the memory of the destination entity (e.g. respective registers thereof that are controlled by the command).

Looking at the illustration shown at Fig 1 , a command can be sent from one of the IT systems 110 or one of the OT system (e.g. another controller) to one of the controllers (e.g. 140-a, , 140-m) providing certain services, such as to open a valve, e.g. valve 152, to close a valve (e.g. valve 152), to direct a sensor (e.g. sensor 156) to a certain location, to obtain a certain type of reading from a sensor (e.g sensor 156), to obtain a reading from a thermometer (e.g. thermometer 154), to reset the thermometer (e.g. thermometer 154), etc. The command can include an indication of the requested service, and an indication of one or more values to be assigned to one or more respective sections in the memory of the destination entity (e.g. respective registers thereof that are controlled by the command) associated with, or controlled by, the command. For example, looking at a service related of opening of a valve (e.g. valve 152), the command may include a value to be assigned to a register of the controller (controller 140-a) controlling the valve (e.g. valve 152), the value indicating of how much should the valve (e.g valve 152) be opened (e.g. by a given percentage, e.g. 30 percent). As another example, looking at a service related to directing a sensor (e.g. sensor 156) to a certain location, the command may include a value to be assigned to a register of the controller (e.g. controller 140-m) controlling the sensor (e.g. sensor 156), the value indicating of how much should the sensor (e.g. sensor 156) be rotated (e.g. by a given angle, e.g. thirty degrees) and another value to be assigned to another register, indicating to which direction should the sensor (e.g. sensor 156) be rotated (e.g. to the left-hand side).

In some cases, the baseline obtained at block 310 identifies authorized network traffic patterns, which identify one or more of the following: (a) which source entity is allowed to communicate with which destination entity, (b) which commands such source entity can send to such destination entity, (c) which services of the destination entity is the source entity allowed to access, (d) which sections in the memory of the destination entity (e.g respective registers thereof) is it allowed to manipulate as part of the command, and (e) which values it is allowed to provide to such sections in the memory of the destination entity (e.g. respective registers thereof)as part of the command.

It is to be noted, and emphasized, that in order for the anomaly detection system 100 to identify the network traffic patterns at block 320, it is required to perform DPI (e.g. utilizing DPI module 260) to one or more packets passing through the network 105, in order to identify the required information, including the source entity, the destination entity and the command (along with its parameters).

The information of one or more of the source entity, the destination entity and the command may be comprised within a plurality of fields within the packets, whether within a single packet, or within a group of packets related to the command sent from the source entity to the destination entity. In some cases, the destination entity is not an IT entity, and in such cases, the destination entity cannot be identified by merely identifying an Internet Protocol (IP) address designated by the packet, and DPI is required in order to understand the identity of the actual destination entity. As a specific example, the destination entity can be a non-IP sensor (e.g. sensor 156) connected to a controller having an IP address (e.g. controller 140-m). In such case, the packet can be designated to the IP address of the controller (e.g. controller 140-m), however, the destination entity, being the entity on which the command is required to execute, is the sensor (e.g. sensor 156). Mere analysis of the packet to obtain the IP address of the packet does not, therefore, enable determining the identity of the destination entity associated with the command.

In some cases, at least part of the packets are proprietary-format packets, sent in a proprietary format encapsulating an internal format. In such cases, the anomaly detection system 100 can be configured to decode the proprietary-format packets to obtain the internal format. In some cases, the internal format can be an Internet Protocol (IP) format.

Since the anomaly detection system 100 is required to identify anomalies within network traffic patterns, that include a source entity, a destination entity and a command, DPI is required.

Having the baseline, and an indication of one or more network traffic patterns identified at block 320, the anomaly detection system 100 can compare such network traffic patterns to the baseline (block 330) and provide an alert upon one or more of the plurality of network traffic patterns not being within the baseline (block 340).

It is to be noted that operating based on the presently disclosed subject matter enables identifying anomalies and providing an alert thereof within a matter of seconds/milliseconds (e.g. less than 30 seconds/milliseconds, or even less than 10 seconds/milliseconds or less).

It is to be noted that in some cases, the anomaly detection system 100 can be configured to update the baseline by adding new authorized network traffic patterns or by removing one of the authorized network traffic patterns. For example, after providing the alert, a user may provide an indication that the alert is a false alert and the network traffic pattern due to which the alert was provided may be introduced into the baseline. As another example, a user can have access to the baseline to manually change it, by updating or removing network traffic patterns therefrom, or by adding new network traffic patterns into the baseline. It is to be noted that these are mere examples and the baseline can be additionally or alternatively updated in other manners, manual and/or automatic.

In some cases, although not shown in the illustration, the baseline can define allowed time-windows for all, or part, of the authorized network traffic patterns. The allowed time-windows can define times at which respective authorized network traffic patterns are allowed to pass through the network 105. For example, during the creation of the baseline, a certain authorized network traffic pattern was only sent from its source entity to its destination entity during a six-hours timeslot of midnight and 6:00 (6 AM). Upon identification of the same authorized network traffic pattern being sent outside such time-window - an alert can be provided.

It is to be noted that, with reference to Fig 3, some of the blocks can be integrated into a consolidated block or can be broken down to a few blocks and/or other blocks may be added. It should be also noted that whilst the flow diagram is described also with reference to the system elements that realizes them, this is by no means binding, and the blocks can be performed by elements other than those described herein.

Attention is now drawn to Fig. 4, a flowchart illustrating one example of a sequence of operations carried out for generating a baseline usable for identification of anomalies, in accordance with the presently disclosed subject matter. According to certain examples of the presently disclosed subject matter, anomaly detection system 100 can be configured to perform a baseline creation process 400, e.g. utilizing the baseline module 240. It is to be noted that in some cases more than one baseline can be created, e.g. one baseline for routine operation and another baseline for training purposes, etc.

For this purpose, anomaly detection system 100 is configured to identify a plurality of baseline network traffic patterns by analyzing, over a given time period occurring before execution of the anomaly detection process 300, a plurality of network traffic patterns using DPI (e.g. utilizing DPI module 260) of raw' network traffic data passing through the network 105 during the given time period, the raw network traffic data comprising a plurality of packets, wherein each baseline network traffic pattern includes information of a source entity, a destination entity and a command (block 410)

In some cases, at least some of the packets analyzed at block 410 originate from, or designate, an OT system 130, and at least one of the network traffic patterns identified at block 410 involves such OT system 130. The OT system 130 can be designated directly (e.g by the network traffic pattern being sent to the OT system 130 directly, e.g. in case the OT entity has an IP address), or indirectly (e.g by the network traffic pattern being sent to an intermediary' entity that controls the OT entity, that optionally cannot be directly designated by the network traffic pattern, e.g when the OT entity does not have an IP address and the intermediary having an IP address, and having the capabilities of causing the OT entity to perform the command comprised within the network traffic pattern).

In some cases, each and every network traffic pattern that is identified during the given time period is inserted into the baseline. In other cases, the identifying of the plurality of baseline network traffic patterns is based on one or more baseline pattern identification rules. One exemplary baseline pattern identification rule can require reoccurrence of the corresponding baseline network traffic patterns during the given time period, so that only reoccurring network traffic patterns are inserted into the baseline, whereas network traffic patterns that only take place once during the given time period --- do not.

As indicated above, with reference to Fig 3, a network traffic pattern includes information of s source entity (being the entity from which the network traffic pattern originates), a destination entity (being the entity designated by the network traffic pattern), and a command (being an instruction sent from the source entity to the destination entity, instructing the destination entity perform a certain action). The command can include indications of: (a) a service associated with the command, (b) one or more values to be assigned to one or more respective sections in the memory of the destination entity (e.g. respective registers therein that are controlled by the command). It is to be further noted that the network traffic patterns are identified at block 410 in a similar manner to their identification at block 320.

In some cases, the given time period, during which the anomaly detection system 100 identifies the plurality of baseline network traffic patterns depends on a topology of the network 105, so that the more complex the topology of the network 105 is, the longer the given time period is. For example, if the network 105 topology is simple (e.g. the network 105 includes a single controller controlling a single power generator that has only two situations - provide power or do not provide power, and the generator is expected not to provide power when no power outage occurs), the given time period can be short, and in some cases shorter than one day (24 hours). If, however, the network 105 topology is more complicated (e.g it includes a plurality of controllers having a plurality of sections in its memory (e.g. respective registers therein)that can receive a plurality of different values over time), the given time period can be a week or even longer.

the analysis performed by the anomaly detection system 100 at block 410 can include analysis of a plurality of communication layers of the raw netwOrk traffic data, and in some cases, it can include analysis of all of the communication layers (e.g. layers one through seven of the Open Systems Interconnection (OSI) model) of the raw ⁷ network traffic data.

Anomaly detection system 100 is further configured to insert the plurality of baseline network traffic patterns identified at block 410 into the baseline (block 420).

In some cases, the anomaly detection system 100 can be further configured to automatically check if any of the baseline netwOrk traffic patterns are associated with, or indicative of exploitation of, a known vulnerability. For this purpose, the anomaly- detection system 100 can utilize a database comprising information of known vulnerabilities as known in the art. This will reduce the risk of having malicious activities that exploit the known vulnerabilities within the baseline network traffic patterns. Additionally, or alternatively, the anomaly detection system 100 can enable a human user to view the baseline network traffic patterns identified at block 410, in a human readable format, and filter out any suspicious baseline network traffic pattern therefrom, so that such suspicious baseline network traffic pattern will not enter the baseline network traffic patterns. For this purpose, the anomaly detection system 100 can present the identified network traffic patterns in a human readable format to the human user.

It is to be noted that in some cases, the baseline creation process 400 can be repeated for updating the baseline. The repetition can be periodical, and/or upon manual instruction of a user, and/or according to one or more re-baselining rules.

It is to be noted that, with reference to Fig 4, some of the blocks can be integrated into a consolidated block or can be broken down to a few blocks and/or other blocks may be added. It should be also noted that whilst the flow diagram is described also with reference to the system elements that realizes them, this is by no means binding, and the blocks can be performed by elements other than those described herein.

Turning to Fig, 5, there is shown a flowchart illustrating one example of a sequence of operations carried out for detecting anomalies within sequences of network traffic patterns, in accordance with the presently disclosed subject matter.

According to certain examples of the presently disclosed subject matter, anomaly detection system 100 can be configured to perform a sequence anomaly- detection process 500, e.g. utilizing the sequence anomaly detection module 270.

For this purpose, anomaly detection syste 100 is configured to obtain a baseline identifying: (A) authorized network traffic patterns within the network 105, each authorized network traffic pattern including information of a source entity, a destination entity, and a command; and (B) at least one sequence comprising at least a first authorized network traffic pattern of the authorized network traffic patterns and a second authorized network traffic pattern of the authorized network traffic patterns, and an maximal and/or minimal allowed time-period allowed to pass between identification of the first authorized network traffic pattern and the second authorized network traffic pattern (block 510). It is to be noted that in some cases there may be more than one baselines, e.g. one baseline for routine operation and another baseline for training purposes, etc.

The baseline can be generated in a process similar to the baseline creation process 400, with the addition of identifying inter-related network traffic patterns forming a sequence, using rules. The rules can define a sequence to comprise, for example, any network traffic pattern that originates from a common source entity, and/or that designates a common destination entity.

The maximal and/or minimal allowed time-period allowed to pass between identification of each network traffic patern within the sequence, and the subsequent network traffic pattern within the sequence can also be determined based on rules. For example, the rale can set the maximal allowed time period to be the maximal time period that passed between identification of a first instance of each network traffic pattern within the sequence and the subsequent network traffic pattern within the sequence. As another example, the rule can set the maximal allowed time period to be the maximal time period that passed between identification of a first instance of each network traffic pattern within the sequence and the subsequent network traffic patern within the sequence with an addition of a certain value (e.g. an additional number of milliseconds/seconds/minutes/hours/etc.). In a similar manner, the rale can set the minimal allowed time period to be the minimal time period that passed between identification of a first instance of each network traffic patern within the sequence and the subsequent network traffic pattern within the sequence. As another example, the rule can set the minimal allowed time period to be the minimal time period that passed between identification of a first instance of each network traffic pattern within the sequence and the subsequent network traffic pattern within the sequence with an addition of a certain positive or negative value (e.g. adding or subtracting number of a number of milliseconds/seconds/minutes/hours/etc.).

It is to be noted that having such a minimal time period that must pass between identification of a first instance of each network traffic pattern within the sequence and the subsequent network traffic pattern within the sequence can enable dealing with situations in which a certain controller gets commands that may cause damage to physical elements that the controller controls. For example, if a controller controls a valve, and the controller gets a sequence of commands to open and close the valve in a rhythm that the valve cannot accommodate, the valve can malfunction as a result. Thus, having rules that define such minimal time period that must pass between subsequent instances of a network traffic pattern, can enable preventing such malfunctions.

Having the baseline obtained at block 510, the anomaly detection system 100 can be further configured to identify an instance of the first authorized network traffic pattern within the raw network traffic data (block 520). The identification can be performed as detailed herein with reference to block 320.

Having identified the instance of the first authorized network traffic pattern within the raw network traffic data, the anomaly detection system 100 monitors the raw' network traffic data to identify an instance of the second authorized network traffic pattern (block 530). If an instance of the second authorized network traffic pattern is not identified within the maximal allowed time-period, or if an instance of the second authorized network traffic pattern is identified within less than the minimal allowed time-period, the anomaly detection system 100 can be configured to provide an alert (block 540).

It is to be noted that, with reference to Fig. 5, some of the blocks can be integrated into a consolidated block or can be broken down to a few blocks and/or other blocks may be added. It should be also noted that whilst the flow diagram is described also with reference to the system elements that realizes them, this is by no means binding, and the blocks can be performed by elements other than those described herein.

Attention is now drawn to Fig, 6, showing a flowchart illustrating one example of a sequence of operations carried out for detecting suspicious inactivity, in accordance with the presently disclosed subject matter.

According to certain examples of the presently disclosed subject matter, anomaly detection system 100 can be configured to perform an inactivity rule-sets compliance process 600, e.g. utilizing the anomaly detection module 250.

For this purpose, anomaly detection system 100 is configured to provide, for each OT entity of a plurality of OT entities connected to the network 105 (e.g OT servers, controllers (e.g. 140-a, ..., 140-m) and other physical OT devices, such as valve/s 152, therm ometer/s 154, sensor/s 156, etc.), an inactivity rule-set comprising one or more rules defining a permissible inactivity pattern thereof (block 610). Each inactivity pattern is indicative of time intervals during which inactivity of the respective OT entity is permissible. The OT entities can be connected to the network 105 directly (e.g. via a wired or wireless connection), or indirectly (e.g. the some of the OT entities that are not directly connected to the network 105 can be connected to intermediary devices that in turn are connected to the network 105). The process of determining the rules-set is explained herein, with reference to Fig. 7

Having such a rule-set, for each OT entity, can enable identifying situations in which the OT entity is under attack, or malfunctioning from some other reason, in a way that prevents it from operating as expected.

For example, if a certain OT server is expected issue a certain OT command to another entity (e.g. to a controller (e.g controller 140-a, , 140-rn) every pre determined time interval (e.g. every thirty milliseconds, every' thirty seconds, every thirty minutes, every hour, every day, every week), a determination that such OT server did not transmit such OT command to such other entity when expected - may be indicative of an attack thereon, or on a malfunction thereof from another reason.

As another example, if a certain sensor (e.g. sensor 156) is expected to transmit a reading obtained thereby to another entity (e.g. to an OT server or to an IT system 110, either directly, or through an intermediary device, such as controller 140-m) every pre-determined time interval (e.g. every _' thirty milliseconds, every' thirty seconds, every thirty minutes, every' hour, every day, every' week), a determination that such sensor did not transmit such reading to such other entity when expected - may be indicative of an attack thereon, or on a malfunction thereof from another reason.

As yet another example, if a certain sensor is expected to transmit at least a first number of packets every' weekday (e.g. Monday to Friday), and at least a second number of packets every' day during the weekend (e.g. Saturday to Sunday), a determination that such sensor did not transmit packets according to such pattern, whether during a weekday or during a weekend day, may be indicative of an attack thereon, or on a malfunction thereof from another reason.

Anomaly detection system 100 is further configured to monitor network traffic passing through the network 105 to identify OT commands associated with the OT entities by performing DPI (e.g. utilizing DPI module 260) of the network traffic (block 620). As indicated herein, in some cases, in order to determine the source entity from which each packet originates, DPI is requires. When monitoring inactivity patterns of an OT entity, having the ability to determine the origin of packets flowing through the network 105 is a prerequisite. In order to check if a certain OT entity meets the requirements of its respective inactivity rule-set, one must be able to first identify activities made thereby.

It is to be noted that in some cases, the inactivity rule-sets can also include rules that refer to certain types of activities. For example, a rule can define a permissible inactivity pattern between pairs of entities (e.g. a given OT entity and a given IT entity or another OT entity), so that if a first entity of the pair does not communicate with a second entity of the pair for over a given time period - it may be indicative of an attack on the first entity, or on a malfunction thereof from another reason.

A rule can also define a permissible inactivity pattern during which a first entity of a pair of entities is required to send a certain type of information (e.g. a certain command, a certain parameter value, etc.) to a second entity of the pair, so that if the first entity does not send the certain type of information to the second entity for over a given time period - it may be indicative of an attack on the first entity, or on a malfunction thereof from another reason.

Anomaly detection system 100 can be further configured to provide an alert upon the inactivity rale-set not being met (i.e. upon one or more of the rules within the rule-set not being met) (block 630).

In some cases, at least one of the rales within at least one of the rule-sets, or optionally within each of the rule-sets, defines a sliding window during which the respective OT entity is permitted to be inactive. For example, a given rule can define that the maximal inactivity period for a given OT entity is thirty minutes, so the sliding window can be set to be thirty minutes, and the thirty minutes are reset to be counted each time an activity of the given OT entity is identified (e.g each time the anomaly detection system 100 identifies, by performing DPI of packets passing through the network 105, that the given OT sends information to another entity).

In some cases, the sliding window’s length can dynamically change according to one or more of: (a) a time of day; and (b) a date. For example, the sliding time window can be set to thirty minutes during work hours (e.g. 9:00 to 17:00), and two hours during non-work hours (e.g. 17:00 to 9:00). As another example, the sliding time window can be set to thirty minutes during work days, and five hours during holydays. Additionally, or alternatively, at least one of the rules within at least one of the rule-sets, or optionally within each of the rule-sets, defines time slots during which the respective OT entity is permitted to be inactive. For example, the rule can define that the anomaly detection system 100 is required to identify (by performing DPI of packets passing through the network 105, that the given OT sends information to another entity) activity of the given OT entity during pre-determined time slots, such as during each hour of each day (00:00-1 :00, 1 :00-2:00, 2:00-3:00, 3:00-4:00, ..., 21 :00-22:00, 22:00- 23:00, 23:00-00:00). In case the given OT entity does not make any activity during any ^¬ one of the time slots, an alert can be provided.

It is to be noted that with reference to Fig. 6, some of the blocks can be integrated into a consolidated block or can be broken down to a few blocks and/or other blocks may be added. It should be also noted that whilst the flow diagram is described also with reference to the system elements that realizes them, this is by no means binding, and the blocks can be performed by elements other than those described herein.

Fig. 7 is a flowchart illustrating one example of a sequence of operations carried out for generating inactivity rule-sets, in accordance with the presently disclosed subject matter.

According to certain examples of the presently disclosed subject matter, anomaly detection system 100 can be configured to perform an inactivity rule-sets determination process 700, e.g. utilizing the inactivity rule-sets determination module 280.

For this purpose, anomaly detection system 100 is configured to analyze, over a given time period occurring before execution of the inactivity rule-sets compliance process 600, past network traffic passing through the network 105 by performing DPI of the past network traffic to identify timestamps of past OT commands associated with corresponding OT entities (block 710).

In some cases, one or more of the OT entities are not directly connected to the network 105. In such cases, the OT commands can be sent from the OT entity (e.g. sensor 156) to an intermediary entity (e.g. controller 140-m) over a first connection connecting the OT each to the intermediary entity, that is optionally external to the network 105. In such cases, the intermediary entity can then transfer the OT command to its destination (e.g an IT system 1 10 connected to the network 105) over the network 105. In such cases, in order to determine the origin of the command, DPI thereof is required.

In some cases, the given time period, during which the anomaly detection system 100 analyzes the past network traffic passing through the network depends on a topology of the network 105, so that the more complex the topology of the network 105 is, the longer the given time period is. For example, if the network 105 topology is simple (e.g. the network 105 includes a single controller controlling a single power generator that has only two situations - provide power or do not provide pow-er, and the generator is expected not to provide power when no power outage occurs; another example is having a sensor that checks if a certain closet is open/closed and the closet is supposed to remain closed), the given time period can be short, and in some cases shorter than one day. If, however, the network 105 topology is more complicated (e.g. it includes a plurality of controllers having a plurality of sections in its memory (e.g. respective registers therein) that can receive a plurality of different values over time), the given time period can be a week or even longer.

The analysis performed by the anomaly detection system 100 at block 410 can include analysis of a plurality of communication layers of the past network traffic, and in some cases, it can include analysis of all of the communication layers (e.g. layers one through seven of the Open Systems Interconnection (OSI) model) of the past network traffic.

The anomaly detection system 100 is further configured to determine, based on the timestamps obtained at block 710, the permissible inactivity patterns for each QT entity (block 720). As indicated herein, the permissible inactivity pattern can relate to a general inactivity of the corresponding OT entity, or it can refer to a specific type of inactivity (e.g. lack of communication between the OT entity and another specific entity, or lack of a certain type of communication between the OT entity and another specific entity, or lack of a certain type of communication between the OT entity and any other entity, etc ).

In some cases, the permissible inactivity pattern can be determined by- calculating an average time between pairs of subsequent timestamps of the past OT commands associated with the corresponding OT entity during the given time period, or by calculating the maximal time between pairs of subsequent timestamps of the past OT commands associated with the corresponding OT entity during the given time period.

For example, assuming that on average a given OT entity sends a command to another entity every thirty milliseconds/seconds/minutes/hours/etc. - the permissible inactivity pattern can indicate that such given OT entity can be inactive for up to thirty milli seconds/seconds/minutes/hours/etc.. Alternatively, assuming that the maximal time between subsequent commands sent by a given OT entity is one hour - the permissible inactivity pattern can indicate that such given OT entity can be inactive for up to one hour.

In some cases, the permissible inactivity pattern can be determined by calculating an average time between pairs of subsequent timestamps of the past OT commands associated with the corresponding OT entity and designating a specific destination entity during the given time period, or by calculating the maximal time between pairs of subsequent timestamps of the past OT commands associated with the corresponding OT entity and designating a specific destination entity during the given time period.

For example, assuming that on average a given OT entity sends a command to another specific entity every thirty milliseconds/seconds/minutes/hours/etc. - the permissible inactivity pattern can indicate that such given OT entity can be allowed not to send a command to the other specific entity for up to thirty milliseconds/seconds/minutes/hours/etc. Alternatively, assuming that the maximal time that passed between commands being sent from the given OT entity to the other specific entity is one hour - the permissible inactivity pattern can indicate that such given OT entity allowed not to send a command to the other specific entity for up to one hour.

In some cases, the permissible inactivity pattern can be determined by calculating an average time between pairs of subsequent timestamps of a certain command type of past OT commands associated with the corresponding OT entity, during the given time period, or by calculating the maximal time between pairs of subsequent timestamps of a certain command type of past OT commands associated with the corresponding OT entity, during the given time period.

For example, assuming that on average a given OT entity sends a certain type of command to other entities every thirty miliiseconds/seconds/minutes/hours/etc.--- the permissible inactivity pattern can indicate that such given OT entity can be allowed not to send such type of a command to other entities for up to thirty milliseconds/seconds/minutes/hours/etc. Alternatively, assuming that the maximal time that passed between commands of a certain type being sent from the given OT entity to other entities is one hour - the permissible inactivity pattern can indicate that such given OT entity allowed not to send such certain type of command to other entities for up to one hour.

In some cases, the permissible inactivity pattern can be determined by calculating an average time between pairs of subsequent timestamps of a certain command type of past OT commands associated with the corresponding OT entity and designating a specific destination entity, during the given time period, or by calculating the maximal time between pairs of subsequent timestamps of a certain command type of past OT commands associated with the corresponding OT entity and designating a specific destination entity during the given time period.

For example, assuming that on average a given OT entity sends a certain type of command to a specific destination entity every thirty milliseconds/seconds/minutes/hours/etc.- the permissible inactivity pattern can indicate that such given OT entity can be allowed not to send such type of a command to such specific destination entity for up to thirty milliseconds/seconds/minutes/hours/etc. Alternatively, assuming that the maximal time that passed between commands of a certain type being sent from the given OT entity to a specific destination entity is one hour - the permissible inactivity pattern can indicate that such given OT entity allowed not to send such certain type of command to such specific destination entity for up to one hour.

It is to be noted that in some cases, a plurality of permissible inactivity patterns can be determined for one or more of the OT entities.

Having determined the permissible inactivity patterns for each OT entity, the anomaly detection system 100 can be configured to determine the rule-set, for each corresponding OT entity, accordingly (block 730).

It is to be noted that, with reference to Fig 7, some of the blocks can be integrated into a consolidated block or can be broken down to a few blocks and/or other blocks may be added. It should be also noted that whilst the flow diagram is described also with reference to the system elements that realizes them, this is by no means binding, and the blocks can be performed by elements other than those described herein.

It is to be understood that the presently disclosed subject matter is not limited in its application to the details set forth in the description contained herein or illustrated in the drawings. The presently disclosed subject matter is capable of other embodiments and of being practiced and carried out in various ways. Hence, it is to be understood that the phraseology and terminology employed herein are for the purpose of description and should not be regarded as limiting. As such, those skilled in the art will appreciate that the conception upon which this disclosure is based may readily be utilized as a basis for designing other structures, methods, and systems for carrying out the several purposes of the present presently disclosed subject matter.

It will also be understood that the system according to the presently disclosed subject matter can be implemented, at least partly, as a suitably programmed computer. Likewise, the presently disclosed subject matter contemplates a computer program being readable by a computer for executing the disclosed method. The presently disclosed subject matter further contemplates a machine-readable memory tangibly embodying a program of instructions executable by the machine for executing the disclosed method.