Policies

OT Security includes policies that define specific types of events that are suspicious, unauthorized, anomalous, or otherwise noteworthy that occur in the network. When an event occurs that meets all of the Policy Definition conditions for a particular policy, the system generates an event. The system logs the event and sends notifications in accordance with the Policy Actions configured for the policy.

  • Policy-based Detection — Triggers an event when the precise conditions of the policy, as defined by a series of event descriptors, are met.

  • Anomaly Detection — Triggers an event when OT Security detects anomalous or suspicious activity in the network.

OT Security features a set of predefined policies (out-of-the-box). In addition, you can edit the predefined policies or define new custom policies.

Note: By default, most policies are turned on. To turn Policies on/off, see Enable or Disable 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 triggers 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 policy parameter belongs to a group as opposed to individual entities. This 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 (for example, 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.

Policy configuration uses the following types of groups:

  • 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, and so on.

  • 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 having similar communication patterns.

  • Email Groups — Group multiple email accounts that receive email notifications for specific events. For example, grouping by role, department, and so on.

  • Port Groups — Group ports used in a similar manner. For example, ports that are open on Rockwell controllers.

  • Protocol Groups — Group communication protocols by the type of protocol (for example, Modbus), the manufacturer (for example, Rockwell allowed protocols), and so on.

  • Schedule Groups — Group several time ranges as a schedule group that has a certain common characteristic. For example, work hours, weekends, and so on.

  • Tag Groups — Group tags that contain similar operational data in various controllers. For example, tags that control furnace temperature.

  • Rule Groups — Group-related rules 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 configured in your system. The system comes with a set of predefined groups. You can edit these groups and add your own groups, see Groups

Note: Policy parameters can only be set using groups, even if you want a policy to apply to an individual entity, you must configure a group that includes only that entity.

Severity Levels

Each policy has a specific severity level assigned to it that indicates the degree of risk posed by the situation that triggered the event. The following table describes the various severity levels:

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. The Events section shows All Events. The Policy page lists the event under the policy that triggered the event and the Inventory page lists the event under the affected Asset. In addition, you can configure policies to send notification of events to an external SIEM using the Syslog protocol and/or to designated email recipients.

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

  • Email Notifications — Email messages include details about the event that generated the notification and the steps to mitigate the threat.

Policy Categories and Sub-Categories

OT Security organizes the policies by the following categories:

  • Configuration Events — These policies relate to the activities that occur in the network. There are two sub-categories:

    • 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 (for example, firmware upgrade during a work day), and/or specific controllers.

    • 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 block lists and allowlists of assets, activities, and schedules are supported.

  • Network Events — These policies relate to the assets in the network and the communication streams between assets. This includes assets added to or removed from the network. It also includes traffic patterns that are anomalous for the network or 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 (for example, protocols used by controllers manufactured by a specific vendor), the policy triggers an event. You can limit these policies to specific schedules and/or specific assets. Vendors organize vendor-specific protocols 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 cataloged in Suricata's Threats engine.

Policy Types

Within each category and sub-category, there are a series of different types of policies. OT Security includes the 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.