Create Alert Rules

IoT Security uses AI and machine-learning algorithms to automatically generate security alerts based on anomalous network behavior and to detect vulnerabilities when device attributes match those in published vulnerability databases such as those at nvd.nist.gov and www.cisa.gov as well as vulnerabilities added to the IoT Security database by its team of security experts. With these automatic detection mechanisms built into the system, IoT Security continuously monitors your network and can notify you of Security threats without any need for you to configure and enable rules or settings for it to do so. However, if you want to detect specific network events (like new device discoveries or a specific device using a specific application), you can define some conditions to identify these events and trigger security alerts and perform actions. To do this, you create custom rules and add them to the set of internal rules that are already in place.

A given rule defined in IoT Security can be triggered based on a single change event such as the discovery of a new device. It can also be triggered by a given traffic pattern such as a specific application command or an accumulation of traffic volume over a period of time. It can even be triggered by a combination of the two. A rule only triggers an action once per day per device to avoid generating excessive noise. To see how many times observed conditions matched a rule, view the Hit Counts column on the AlertsCustom Alert Rules page.

The following list shows several types of conditions you might define:

• One device communicates with another device
• A device appears on a specific VLAN or network segment, connects to a specific wireless access point or network switch, or shows up in a specific next-generation firewall zone
• The subnet or IP address of a device changes
• A risky device communicates with the Internet
• The risk level for a device changes
• A device transmits a certain volume of network traffic
• A device uses a particular application or uses something other than a particular application
• A device uses a particular application command or a specific value in a command

If detected, these conditions would trigger IoT Security to take one or more configured actions—generate an alert, notify users, quarantine the device involved.

Although the conditions above use the singular form “device” for simplicity, the rule conditions can also apply to multiple individual devices, one or more types of devices (device profiles), or one or more device groups (defined by user tags, Purdue level, or category).

The rules engine is at AlertsCustom Alert Rules and consists of three sections: Basic Information, Rules Details, and Rule Preview.

To help you get started using the rules engine, IoT Security provides a collection of example templates for common rules. Study these preconfigured rules to become familiar with rules engine capabilities, enable and use them as they are, or use them as models for building similar rules of your own.

Predefined rules are disabled by default so that they don’t trigger unwanted alarms.

To see the preconfigured example rules, select AlertsCustom Alert Rules.

The preconfigured templates differ somewhat based on the vertical theme that’s active on your IoT Security portal. Each vertical theme has two or three example rule templates. Here’s an example for each theme:

Enterprise IoT Security Plus

• Rule Name: [Example] Suspicious Printer Communication
• Description: Raise a critical alert any time a printer communicates with any other endpoint using applications that aren’t on the allow list.
• Rule: WHEN category = “Printer”, application =! Dhcp, dns, dns-base, ldap, netbios-ns, ntp-base, smtp-base, snmp-base, snmpv1, ssl, ws-discovery ; DO Publish “Critical” alert
• Action: Raise a critical severity alert

Industrial IoT Security

• Rule Name: [Example] Industrial Device Offline
• Description: Raise a high alert when an industrial controller or remote terminal unit (RTU) is offline during business hours.
• Rule: WHEN category IN (“Industrial Controller”, “Industrial RTU”), Offline Device; DO Publish “High” alert
• Action: Raise a high severity alert

Medical IoT Security

• Rule Name: [Example] New Camera Asset Discovered
• Description: Raise a critical alert any time a new IP camera is detected on the network.
• Rule: WHEN: category = “Camera”, New Device Discovery; DO Publish Alert
• Action: Raise a critical severity alert

If you want to try a rule, enable it by opening the Rule Engine Editor and toggling the Status from Disabled to Active. You can edit, clone, and delete the example templates using the options in the Actions column on the AlertsCustom Alert Rules page.

1. Identify your network concerns and what events you’d want IoT Security to watch for and notify you about.
2. Create a rule to address your concern beginning with some basic information.

   In the Basic Information section, enter a name and description for the rule and when you want it enforced.

   • Rule Name: Enter a unique name for the rule.
   • Description: (Optional) Enter a description of the rule, such as its overall intent, for future reference.
   • Apply rule during: When days and times of day when you want IoT Security to enforce the rule. By default, a rule is enforced all the time; that is, all day everyday.
   • Status: If you want IoT Security to monitor the rule conditions, toggle its status to Active. If you don’t want IoT Security to apply the rule, toggle its status to Disabled.

3. Define criteria for the rule.

   In the Rule Details section, define the criteria necessary to trigger an action that IoT Security will take.

   • All(AND) or ANY(OR): Choose All(AND) when you want all conditions to be met for IoT Security to perform a defined action. Choose ANY(OR) when you want any one of the conditions to trigger it.
   • Add Condition: Choose Traffic Pattern to define a condition based on network traffic behavior. Choose Change Event to define a condition based on a change to a device, such as a device changing its IP address or going offline, or a new device coming onto the network.
     If you choose Traffic Pattern, IoT Security displays two fields for target devices and extra criteria options for traffic volume and app usage.
     • Add Target Devices: In the first target device field, identify the device or devices to which you want to apply the rule. You can do this by choosing up to 10 attributes. These can be the IP addresses and names of devices, the subnets and VLANs to which they belong, previously defined tags and custom attributes, device categories and profiles, the switches and wireless access points through which devices access the network, and traffic destinations (two-character codes for countries and territories defined in the ISO 3166-1 standard). You can specify if the target devices have a specific attribute (=) or not (!=) or if they have any one of a set of attributes (IN) or not (NOT IN). Building the target device criteria works in a manner similar to the query builder.
     • Target Devices (optional): If you want to define a traffic pattern between two specific devices or types of devices, use the second target device field to identify the other end of communications. If you don’t enter anything here, it’s treated as “any destination” (this can be an internal device or an external web address).
     • Show Extra Criteria: You can set extra conditions by selecting Traffic Volume and App Usage and setting parameters (one or both conditions can be selected).
       The configuration of these settings requires insight into traffic flow volumes and knowledge of application settings and their appropriate values.
       If you select Traffic Volume, then enter the volume of traffic and a time period in which it occurs as a condition to trigger a rule. You might want to use this option to watch for unexpected surges in traffic volume, especially to unusual destinations.
       If you select App Usage and choose Application: is, you can then choose a single OT or IoT/IT application and enter whatever commands, parameters, and values must be present in network traffic to trigger an action. If you choose Application:not, you can choose a single application that must not be present to trigger an action. If you want to create a condition that applies to multiple applications, choose Application:in or Application:not in.
       Additional selector fields for commands, parameters, and values are only available after choosing Application: is.
     If you choose Change Event, IoT Security displays the same Target Devices field it does for Traffic Pattern plus an Event drop-down list. You can choose the following events to trigger an action:
     • IP Change
     • New Device Discovery
     • New Vulnerability Discovery (includes both confirmed and potential instances)
     • Offline Device
     • Purdue Level Change (You must also select a Purdue level.)
     • Risk Level Change (You must select Any or a specific risk level.)
     • Subnet Change
     Add Condition Set: Adding a condition set lets you create a subgroup of conditions with its own All(AND) or ANY(OR) operator. It’s useful for chaining multiple conditions under the main set of conditions.
     For example, the following criteria has four conditions with the logic of Condition A AND Condition B AND { Condition C OR Condition D }. To apply an action, conditions A and B and either C or D must be met.

4. Set the action that IoT Security takes when the defined criteria are met.

   To avoid rules generating excessive noise, IoT Security only triggers the specified actions once per device per day. You can configure IoT Security to take up to three of the following actions:

   Generate alert + additional actions (Send to third-party systems and Assign to Users) – When rule conditions are met, IoT Security generates a Security alert and displays them on the Alerts > Security Alerts page. In addition, IoT Security can automatically push the alert to third-party systems triggering additional actions by the third-party system such as initiating a NAC quarantine or triggering a work order for example. It can also assign an alert to one or more users to investigate for remediation.

   Notify users – Set IoT Security to notify multiple users by email or to notify you yourself by SMS text. (To receive text notifications, you must enter your mobile phone number and enable text notifications in user-name > Preferences.)

   Restrict network access – Inform a Palo Alto Networks Next-Generation Firewall to restrict network access to the device whose behavior matches the conditions necessary to trigger the action.

5. Check settings in the Rule Preview.

   Review the rule displayed in a readable SQL-like format. This is a high-level snapshot of the Criteria and Action sections that lets you check the logical relationships of settings within the rule. Any later changes to settings in these sections will update the rule preview.