System Elements

Assets are the hardware components in your network such as controllers, engineering stations, servers etc. OT Security's automated asset discovery, classification and management provides an accurate asset inventory by continuously tracking all changes to devices. This simplifies sustaining of operational continuity, reliability and safety. It also plays a key role in planning maintenance projects, prioritizing upgrades, patch deployments, incident response and mitigation efforts.

OT Security applies sophisticated algorithms to assess the degree of risk posed to each asset on the network. A Risk Score (from 0 to 100) is given for each Asset in the network. The Risk score is based on the following factors:

• Events - that occurred in the network that affected the device (weighted based on Event severity and how recently the Event occurred).

Note: Events are weighted according to currency, so that more recent Events have a greater impact on the Risk score than older Events.

• Vulnerabilities –CVEs that affect assets in your network, as well as other threats identified in your network (e.g. obsolete operating systems, usage of vulnerable protocols, vulnerable open ports, etc.). In the OT Security, these are detected as plugin hits on your assets.

• Asset Criticality – a measure of the importance of the device to the proper functioning of the system.

  Note: For PLC’s that are connected to a backplane, the Risk score of other modules that share the backplane affect the PLC’s Risk score.

Policies are used to define specific types of events that are suspicious, unauthorized, anomalous or otherwise noteworthy that take place in the network. When an event occurs that meets all the Policy Definition conditions for a particular Policy, an Event is generated in the system. The Event is logged in the system and notifications are sent out in accordance with the Policy Actions configured for the Policy.

There are two types of policy events:

• Policy-based Detection – which triggers Events when the precise conditions of the Policy, as defined by a series of event descriptors, are met.

• Anomaly Detection –which trigger Events when anomalous or suspicious activity is identified in the network.

The system features a set of predefined policies (out-of-the-box). In addition, the system offers the ability to edit the predefined policies or define new custom policies.

Policy-Based Detection

For Policy-based detection, you configure the specific conditions for what events in the system trigger Event notifications. Policy-based Events are triggered only when the precise conditions of the policy are met. This ensures zero false positives, as the system alerts for actual events that take place in the ICS network, while providing meaningful detailed information about the ‘who’, ‘what’, ‘when’, ‘where’ and ‘how’. The policies can be based on various Event types and descriptors. The following, are some examples of possible policy configurations:

• Anomalous or unauthorized ICS control-plane activity (engineering): for example, an HMI should not query the firmware version of a controller (may indicate reconnaissance), and a controller should not be programmed during operational hours (may indicate unauthorized, potentially malicious activity).

• Change to controller’s code – a change to the controller logic was identified (“Snapshot mismatch”).

• Anomalous or unauthorized network communications: for example, an un-allowed communication protocol was used between two network assets or a communication took place between two assets that have never communicated before.

• Anomalous or unauthorized changes to the asset inventory: for example, a new asset was discovered or an asset stopped communicating in the network.

• Anomalous or unauthorized changes in asset properties: for example, the asset firmware or state has changed.

• Abnormal writes of set-points: Events are generated for changes made to specific parameters. The user can define the allowed ranges for a parameter and generate Events for deviations from that range.

Anomaly Detection

Anomaly Detection policies discover suspicious behavior in the network based on the system's built-in capabilities for detecting deviations from 'normal' activity. The following anomaly detection policies are available.

• Deviations from a network traffic baseline: the user defines a baseline of 'normal' network traffic based on the traffic map during a specified time range and generates alerts for deviations from the baseline. The baseline can be updated at any time.

• Spike in Network Traffic: a dramatic increase in the volume of network traffic or number of conversations is detected.

• Potential network reconnaissance/cyber-attack activity: Events are generated for activities indicative of reconnaissance or cyber-attack activity in the network, such as IP conflicts, TCP port scans and ARP scans.

Policy Categories

The Policies are organized by the following categories:

• Configuration Event Policies – these Policies relate to the activities that take place in the network. There are two sub-categories of Configuration Event Policies:

  • Controller Validation - these Policies relate to changes that take place in the controllers in the network. This can involve changes in the state of a controller as well as changes to the firmware, asset properties or code blocks. The Policies can be limited to specific schedules (e.g. firmware upgrade during a work day), and/or specific controller/s.

  • Controller Activities – these policies relate to specific engineering commands that impact controllers’ state and configuration. It is possible to define specific activities that always generate Events or to designate a set of criteria for generating Events. For example, if certain activities are performed at certain times and/or on certain controllers. Both black listing and white listing of assets, activities and schedules are supported.

• Network Events Policies – these Policies relate to the assets in the network and the communication streams between assets. This includes assets that were added to or removed from the network. It also includes traffic patterns that are anomalous for the network or that have been flagged as raising particular cause for concern. For example, if an engineering station communicates with a controller using a protocol that is not part of a pre-configured set of protocols (e.g. protocols that are used by controllers manufactured by a specific vendor), an Event is triggered. These policies can be limited to specific schedules and/or specific assets. Vendor specific protocols are organized by vendor for convenience, while any protocol can be used in a policy definition.

• SCADA Event Policies – these Policies detect changes in set-point values which can harm the industrial process. These changes may result from a cyber-attack or human error.

• Network Threats Policies – these Policies use signature-based OT and IT threat detection to identify network traffic that is indicative of intrusion threats. The detection is based on rules that have been catalogued in Suricata's Threats engine.

Groups

An essential component in the definition of Policies in OT Security is the use of Groups. When configuring a Policy each of the parameters is designated by a Group as opposed to individual entities. This greatly streamlines the Policy configuration process.

Events

When an event occurs that matches the conditions of a Policy, an Event is generated in the system. All Events are displayed on the Events screen and can also be accessed through the relevant Inventory and Policy screens. Each Event is marked with a severity level, indicating the degree of risk posed by the Event. Notifications can be automatically sent out to email recipients and SIEMs as specified in the Policy Actions of the Policy that generated the Event.

An Event can be marked as resolved by an authorized user and a comment can be added.