Policies

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 of 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.

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

• Anomaly Detection –which triggers an Event 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.

Note: By default, most policies are turned on. To turn Policies on/off see Policies.

Policy Configuration

Each Policy consists of a series of conditions that define a specific type of behavior in the network. This includes considerations such as the activity, the assets involved and the timing of the event. Only an event that conforms to all the parameters set in the Policy will trigger an Event for that Policy. Each Policy has a designated Policy Actions configuration which defines the severity, notification methods, and logging of the Event.

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. For example, if the Activity Firmware update is considered a suspicious activity when it is performed on a controller during certain hours of the day (e.g. during work hours), instead of creating a separate Policy for each controller in your network you can create a single Policy that applies to the Asset Group Controllers.

The following types of Groups are used as part of the Policy configuration:

• Asset Groups –the system comes with predefined Asset Groups based on asset type. You can add custom groups based on other factors such as location, department, criticality etc.

• Network Segments – the system creates auto-generated Network Segments based on asset type and IP range. You can create custom Network Segments defining any group of assets that should have similar communication patterns.

• Email Groups - you can group multiple email accounts that will receive email notifications for specific Events. For example, grouping by role, department, etc.

• Port Groups – ports that are used in a similar manner can be grouped together. For example, ports that are generally open on Rockwell controllers.

• Protocol Groups – communication protocols can be grouped by the type of protocol (e.g. Modbus), the manufacturer (e.g. Rockwell allowed protocols), etc.

• Schedule Groups – several time ranges can be grouped as a schedule group that has a certain common characteristic. For example, work hours, weekend etc.

• Tag Groups – you can group tags that contain similar operational data in various controllers. For example, tags that control furnace temperature.

• Rule Groups - Rule Groups are comprised of a group of related rules, which are identified by their Suricata Signature IDs (SIDs). These groups are used as a Policy condition for defining Intrusion Detection Policies.

Policies can only be defined using Groups that have been configured in your system. The system comes with a set of predefined Groups. You can edit these Groups and add your own Groups, see Chapter GROUPS.

Severity Levels

Each Policy has a specific Severity level assigned to it which indicates the degree of risk posed by the situation that triggered the Event. The meaning of the different Event levels is described in the following table.

Severity	Description
None	The Event is not cause for concern.
Low	No immediate reason for concern. Should be checked out when convenient.
Medium	Moderate concern that potentially harmful activity has occurred. Should be dealt with when convenient.
High	Severe concern that potentially harmful activity has occurred. Should be dealt with immediately.

Event Notifications

When an event occurs that matches the conditions of the policy, an Event is triggered. All Events are displayed in the Events. (Each Event is also listed under the Policy that triggered the Event in the Policies screen and under the Asset that was affected by the Event in the Inventory screen.) In addition, Policies can be configured to send notification of Events to an external SIEM using Syslog protocol and/or to designated email recipients.

• Syslog Notification – Syslog messages use CEF protocol with both Standard Keys and Custom Keys (which are configured for use with OT Security). For an explanation of how to interpret Syslog notifications see OT Security Syslog Integration Guide.

• Email Notifications – Email messages include details about the Event that generated the notification as well as suggestions of steps that should be taken to mitigate the threat.

Policy Categories and Sub-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 lists and white lists 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 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.

 

Policy Types

Within each Category and Sub-Category there are a series of different Types of Policies. The system comes with predefined Policies of each Type. You can also create your own custom Policies of each Type. The following tables explain the various Policy Types, grouped by Category.

Configuration Event – Controller Activities Event Types

Controller Activities relate to the Activities that occur in the network (i.e. the “commands” implemented between assets in the network). There are many different types of Controller Activity Events. Each Type is defined by the type of controller on which the Activity is done and the specific Activity that is identified (i.e. Rockwell PLC stop, SIMATIC code download, Modicon online session etc.).

The Policy Definition parameters (i.e. policy conditions) that apply to Controller Activity Events are Source Asset, Destination Asset and Schedule.

Configuration Event - Controller Validation Event Types

The following table describes the various types of Controller Validation Events.

Note: Policy conditions relating to Affected Assets, Sources or Destinations can be specified by selecting either an Asset Group or a Network Segment.

Event Type	Policy Conditions	Description
Change in key switch	Affected Asset, Schedule	A change was made to the controller state by adjusting the physical key position. (Currently supported for Rockwell controllers only.)
Change in state	Affected Asset, Schedule	The controller changed from one operational state (e.g. running, stopped, test etc.) to another.
Change in firmware version	Affected Asset, Schedule	A change was made to the firmware running on the controller.
Module not seen	Affected Asset, Schedule	Detects a previously identified module that was removed from a backplane.
New module discovered	Affected Asset, Schedule	Detects a new module that is added to an existing backplane.
Snapshot mismatch	Affected Asset, Schedule	The most recent Snapshot (which captures the current state of the program deployed on a controller) of a controller was not identical to the previous Snapshot of that controller.

Network Event Types

The following table describes the various types of Network Events.

Event Type	Policy Conditions	Description
Asset not seen	Not seen for, Affected Asset, Schedule	Detects previously identified assets in the Affected Asset Group that are removed from the network for the specified duration of time during the specified time range.
Change in USB configuration	Affected Assets, Schedule	Detects when a USB device is connected to or removed from a Windows based workstation. The Policy applies to changes to an asset in the Affected Asset Group during the specified time range.
IP conflict	Schedule	Detects multiple assets in the network using the same IP Address. This may indicate a cyber-attack or it may result from poor network management. The Policy applies to IP Conflicts discovered during the specified time range.
Network Baseline Deviation	Source, Destination, Protocol, Schedule	Detects new connections between assets that did not communicate with each other during the Network Baseline sampling. This option is only available once a Network Baseline has been set up in the system. To set the initial Network Baseline or to update the Network Baseline follow the procedures described in section SETTING A NETWORK BASELINE. The Policy applies to communication from an asset in the Source Asset Group to an asset in the Destination Asset Group using a Protocol from the Protocol Group during the specified time range.
New asset discovered	Affected Asset, Schedule	Detects new assets of the type specified in the Source Asset Group that appear in your network during the specified time range.
Open port	Affected Asset, Port	Detects new open ports in your network. Unused open ports can pose a security risk. The Policy applies to assets in the Affected Asset Group and to ports that are in the Port Group.
Spike in network traffic	Time window, Sensitivity level, Schedule	Detects anomalous spikes in the network traffic volume. The Policy applies to spikes relative to the specified time window and based on the specified sensitivity level. It is also limited to the specified time range.
Spike in conversation	Time window, Sensitivity level, Schedule	Detects anomalous spikes in the number of conversations in the network. The Policy applies to spikes relative to the specified time window and based on the specified sensitivity level. It is also limited to the specified time range.
RDP connection (authenticated)	Source, Destination, Schedule	An RDP (Remote Desktop Connection) was made in the network using authentication credentials. The Policy applies to asset in the Source Asset Group connecting to an asset in the Destination Asset Group during the specified time range.
RDP connection (not authenticated)	Source, Destination, Schedule	An RDP (Remote Desktop Connection) was made in the network without using authentication credentials. The Policy applies to asset in the Source Asset Group connecting to an asset in the Destination Asset Group during the specified time range.
Unauthorized conversation	Source, Destination, Protocol, Schedule	Detects communication sent between assets in the network. The Policy applies to communication sent from an asset in the Source Asset Group to an asset in the Destination Asset Group using a Protocol from the Protocol Group during the specified time range.
Successful unsecured FTP login	Source, Destination, Schedule	FTP is considered to be an unsecure protocol. This Policy detects successful logins using FTP.
Failed unsecured FTP login	Source, Destination, Schedule	FTP is considered to be an unsecure protocol. This Policy detects failed login attempts using FTP.
Successful unsecured Telnet login	Source, Destination, Schedule	Telnet is considered to be an unsecure protocol. This Policy detects successful logins using Telnet.
Failed unsecured Telnet login	Source, Destination, Schedule	Telnet is considered to be an unsecure protocol. This Policy detects failed login attempts using Telnet.
Unsecured Telnet login attempt	Source, Destination, Schedule	Telnet is considered to be an unsecure protocol. This Policy detects login attempts using Telnet (for which the result status was not detected).

Network Threat Event Types

The following table describes the various types of Network Threat Events.

Note: Policy conditions relating to Affected Assets, Sources or Destinations can be specified by selecting either an Asset Group or a Network Segment.

Event Type	Policy Conditions	Description
Intrusion Detection	Source, Affected Asset, Rule Group, Schedule	Intrusion Detection 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. The rules are grouped into categories (e.g. ICS Attacks, Denial of Service, Malware etc.) and sub-categories (e.g. ICS Attacks - Stuxnet, ICS Attacks – Black Energy etc.). The system comes with a series of Predefined groups of related rules. You can also configure your own custom groupings of various rules.
ARP scan	Affected Asset, Schedule	Detects ARP scans (network reconnaissance activity) that are run in the network. The Policy applies to scans that are broadcasted affect an in the Affected Asset Group during the specified time range.
Port scan	Source Asset, Destination Asset, Schedule	Detects SYN scans (network reconnaissance activity) that are run in the network to detect open (vulnerable) ports. The Policy applies to communication from an asset in the Source Asset Group to an asset in the Destination Asset Group during the specified time range.

SCADA Event Types

The following table describes the various types of SCADA Event types.

Note: Policy conditions relating to Affected Assets, Sources or Destinations can be specified by selecting either an Asset Group or a Network Segment.

Event Type	Policy Conditions	Description
Modbus illegal data address	Source Asset, Destination Asset, Schedule	Detects "illegal data address" error code in Modbus protocol. The Policy applies to communication from an asset in the Source Asset Group to an asset in the Destination Asset Group during the specified time range.
Modbus illegal data value	Source Asset, Destination Asset, Schedule	Detects "illegal data value" error code in Modbus protocol. The Policy applies to communication from an asset in the Source Asset Group to an asset in the Destination Asset Group during the specified time range.
Modbus illegal function	Source Asset, Destination Asset, Schedule	Detects "illegal function" error code in Modbus protocol. The Policy applies to communication from an asset in the Source Asset Group to an asset in the Destination Asset Group during the specified time range.
Unauthorized write	Source Asset, Tag Group, Tag value, Schedule	Detects unauthorized tag writes to the specified tag/s on a controller (currently supported for Rockwell and S7 controllers) in the specified Source Asset Group. The Policy can be configured to detect any new write, a change from a specified value or a value outside of a specified range. The Policy only applies during the specified time range.
ABB - Unauthorized write	Source Asset, Destination Asset, Schedule	Detects write commands sent over MMS to ABB 800xA controllers that are out of the allowed range.
IEC 60870-5-104 Commands (Start/Stop Data Transfer, Interrogation Command, Counter Interrogation Command, Clock Synchronization Command, Reset Process Command, Test Command with Time Tag)	Source Asset, Destination Asset, Schedule	Detects specific commands sent to IEC-104 master or slave units that are considered to be risky.
DNP3 Commands	Source Asset, Destination Asset, Schedule	Detects all main commands sent using DNP3 protocol, e.g. Select, Operate, Warm/Cold Restart etc. Also detects errors originating from internal indicators such as unsupported function codes and parameter errors.