Muokkaa

Jaa


Forward on-premises OT alert information

Microsoft Defender for IoT alerts enhance your network security and operations with real-time details about events logged in your network. OT alerts are triggered when OT network sensors detect changes or suspicious activity in network traffic that needs your attention.

This article describes how to configure your OT sensor or on-premises management console to forward alerts to partner services, syslog servers, email addresses, and more. Forwarded alert information includes details like:

  • Date and time of the alert
  • Engine that detected the event
  • Alert title and descriptive message
  • Alert severity
  • Source and destination name and IP address
  • Suspicious traffic detected
  • Disconnected sensors
  • Remote backup failures

Note

Forwarding alert rules run only on alerts triggered after the forwarding rule is created. Alerts already in the system from before the forwarding rule was created are not affected by the rule.

Prerequisites

Create forwarding rules on an OT sensor

  1. Sign into the OT sensor and select Forwarding on the left-hand menu > + Create new rule.

  2. In the Add forwarding rule pane, enter a meaningful rule name, and then define rule conditions and actions as follows:

    Name Description
    Minimal alert level Select the minimum alert severity level you want to forward.

    For example, if you select Minor, minor alerts and any alert above this severity level are forwarded.
    Any protocol detected Toggle on to forward alerts from all protocol traffic or toggle off and select the specific protocols you want to include.
    Traffic detected by any engine Toggle on to forward alerts from all analytics engines, or toggle off and select the specific engines you want to include.
    Actions Select the type of server you want to forward alerts to, and then define any other required information for that server type.

    To add multiple servers to the same rule, select + Add server and add more details.

    For more information, see Configure alert forwarding rule actions.
  3. When you're done configuring the rule, select Save. The rule is listed on the Forwarding page.

  4. Test the rule you've created:

    1. Select the options menu (...) for your rule > Send Test Message.
    2. Go to the target service to verify that the information sent by the sensor was received.

Edit or delete forwarding rules on an OT sensor

To edit or delete an existing rule:

  1. Sign into your OT sensor and select Forwarding on the left-hand menu.

  2. Select the options menu (...) for your rule, and then do one of the following:

Create forwarding rules on an on-premises management console

To create a forwarding rule on the management console:

  1. Sign in to the on-premises management console and select Forwarding on the left-hand menu.

  2. Select the + button at the top-right to create a new rule.

  3. In the Create Forwarding Rule window, enter a meaningful name for the rule, and then define rule conditions and actions as follows:

    Name Description
    Minimal alert level At the top-right of the dialog, use the dropdown list to select the minimum alert severity level that you want to forward.

    For example, if you select Minor, minor alerts and any alert above this severity level are forwarded.
    Protocols Select All to forward alerts from all protocol traffic, or select Specific to add specific protocols only.
    Engines Select All to forward alerts triggered by all sensor analytics engines, or select Specific to add specific engines only.
    System Notifications Select the Report System Notifications option to notify about disconnected sensors or remote backup failures.
    Alert Notifications Select the Report Alert Notifications option to notify about an alert's date and time, title, severity, source and destination name and IP address, suspicious traffic, and the engine that detected the event.
    Actions Select Add to add an action to apply and enter any parameters values needed for the selected action. Repeat as needed to add multiple actions.

    For more information, see Configure alert forwarding rule actions.
  4. When you're done configuring the rule, select SAVE. The rule is listed on the Forwarding page.

  5. Test the rule you've created:

    1. On the row for your rule, select the test this forwarding rule button. A success notification is shown if the message sent successfully.
    2. Go to your partner system to verify that the information sent by the sensor was received.

Edit or delete forwarding rules on an on-premises management console

To edit or delete an existing rule:

  1. Sign into your on-premises management console and select Forwarding on the left-hand menu.

  2. Find the row for your rule and then select either the Edit or Delete button.

    • If you're editing the rule, update the fields as needed and select SAVE.

    • If you're deleting the rule, select CONFIRM to confirm the deletion.

Configure alert forwarding rule actions

This section describes how to configure settings for supported forwarding rule actions, on either an OT sensor or the on-premises management console.

Email address action

Configure an Email action to forward alert data to the configured email address.

In the Actions area, enter the following details:

Name Description
Server Select Email.
Email Enter the email address you want to forward the alerts to. Each rule supports a single email address.
Timezone Select the time zone you want to use for the alert detection in the target system.

Syslog server actions

Configure a Syslog server action to forward alert data to the selected type of Syslog server.

In the Actions area, enter the following details:

Name Description
Server Select one of the following types of syslog formats:

- SYSLOG Server (CEF format)
- SYSLOG Server (LEEF format)
- SYSLOG Server (Object)
- SYSLOG Server (Text Message)
Host / Port Enter the syslog server's host name and port
Timezone Select the time zone you want to use for the alert detection in the target system.
Protocol Supported for text messages only. Select TCP or UDP.
Enable encryption Supported for CEF format only. Toggle on to configure a TLS encryption certificate file, key file, and passphrase.

The following sections describe the syslog output syntax for each format.

Syslog text message output fields

Name Description
Priority User. Alert
Message CyberX platform name: The sensor name.
Microsoft Defender for IoT Alert: The title of the alert.
Type: The type of the alert. Can be Protocol Violation, Policy Violation, Malware, Anomaly, or Operational.
Severity: The severity of the alert. Can be Warning, Minor, Major, or Critical.
Source: The source device name.
Source IP: The source device IP address.
Protocol (Optional): The detected source protocol.
Address (Optional): Source protocol address.
Destination: The destination device name.
Destination IP: The IP address of the destination device.
Protocol (Optional): The detected destination protocol.
Address (Optional): The destination protocol address.
Message: The message of the alert.
Alert group: The alert group associated with the alert.
UUID (Optional): The UUID the alert.

Syslog object output fields

Name Description
Priority User.Alert
Date and Time Date and time that the syslog server machine received the information.
Hostname Sensor IP
Message Sensor name: The name of the appliance.
Alert time: The time that the alert was detected: Can vary from the time of the syslog server machine, and depends on the time-zone configuration of the forwarding rule.
Alert title: The title of the alert.
Alert message: The message of the alert.
Alert severity: The severity of the alert: Warning, Minor, Major, or Critical.
Alert type: Protocol Violation, Policy Violation, Malware, Anomaly, or Operational.
Protocol: The protocol of the alert.
Source_MAC: IP address, name, vendor, or OS of the source device.
Destination_MAC: IP address, name, vendor, or OS of the destination. If data is missing, the value is N/A.
alert_group: The alert group associated with the alert.

Syslog CEF output fields

Name Description
Priority User.Alert
Date and time Date and time that the sensor sent the information, in UTC format
Hostname Sensor hostname
Message CEF:0
Microsoft Defender for IoT/CyberX
Sensor name
Sensor version
Microsoft Defender for IoT Alert
Alert title
Integer indication of severity. 1=Warning, 4=Minor, 8=Major, or 10=Critical.
msg= The message of the alert.
protocol= The protocol of the alert.
severity= Warning, Minor, Major, or Critical.
type= Protocol Violation, Policy Violation, Malware, Anomaly, or Operational.
UUID= UUID of the alert (Optional)
start= The time that the alert was detected.
Might vary from the time of the syslog server machine, and depends on the time-zone configuration of the forwarding rule.
src_ip= IP address of the source device. (Optional)
src_mac= MAC address of the source device. (Optional)
dst_ip= IP address of the destination device. (Optional)
dst_mac= MAC address of the destination device. (Optional)
cat= The alert group associated with the alert.

Syslog LEEF output fields

Name Description
Priority User.Alert
Date and time Date and time that the sensor sent the information, in UTC format
Hostname Sensor IP
Message Sensor name: The name of the Microsoft Defender for IoT appliance.
LEEF:1.0
Microsoft Defender for IoT
Sensor
Sensor version
Microsoft Defender for IoT Alert
title: The title of the alert.
msg: The message of the alert.
protocol: The protocol of the alert.
severity: Warning, Minor, Major, or Critical.
type: The type of the alert: Protocol Violation, Policy Violation, Malware, Anomaly, or Operational.
start: The time of the alert. It might be different from the time of the syslog server machine, and depends on the time-zone configuration.
src_ip: IP address of the source device.
dst_ip: IP address of the destination device.
cat: The alert group associated with the alert.

Webhook server action

Supported from the on-premises management console only

Configure a Webhook action to configure an integration that subscribes to Defender for IoT alert events. For example, send alert data to a webhook server to update an external SIEM system, SOAR system, or incident management system.

When you've configured alerts to be forwarded to a webhook server and an alert event is triggered, the on-premises management console sends an HTTP POST payload to the configured webhook URL.

In the Actions area, enter the following details:

Name Description
Server Select Webhook.
URL Enter the webhook server URL.
Key / Value Enter key/value pairs to customize the HTTP header as needed. Supported characters include:
- Keys can contain only letters, numbers, dashes, and underscores.
- Values can contain only one leading and/or trailing space.

Webhook extended

Supported from the on-premises management console only

Configure a Webhook extended action to send the following extra data to your webhook server:

  • sensorID
  • sensorName
  • zoneID
  • zoneName
  • siteID
  • siteName
  • sourceDeviceAddress
  • destinationDeviceAddress
  • remediationSteps
  • handled
  • additionalInformation

In the Actions area, enter the following details:

Name Description
Server Select Webhook extended.
URL Enter the endpoint data URL.
Key / Value Enter key/value pairs to customize the HTTP header as needed. Supported characters include:
- Keys can contain only letters, numbers, dashes, and underscores.
- Values can contain only one leading and/or trailing space.

NetWitness action

Configure a NetWitness action to send alert information to a NetWitness server.

In the Actions area, enter the following details:

Name Description
Server Select NetWitness.
Hostname / Port Enter the NetWitness server's hostname and port.
Time zone Enter the time zone you want to use in the time stamp for the alert detection at the SIEM.

Configure forwarding rules for partner integrations

You might be integrating Defender for IoT with a partner service to send alert or device inventory information to another security or device management system, or to communicate with partner-side firewalls.

Partner integrations can help to bridge previously siloed security solutions, enhance device visibility, and accelerate system-wide response to more rapidly mitigate risks.

In such cases, use supported Actions to enter credentials and other information required to communicate with integrated partner services.

For more information, see:

Configure alert groups in partner services

When you configure forwarding rules to send alert data to Syslog servers, QRadar, and ArcSight, alert groups are automatically applied and are available in those partner servers.

Alert groups help SOC teams using those partner solutions to manage alerts based on enterprise security policies and business priorities. For example, alerts about new detections are organized into a discovery group, which includes any alerts about new devices, VLANs, user accounts, MAC addresses, and more.

Alert groups appear in partner services with the following prefixes:

Prefix Partner service
cat QRadar, ArcSight, Syslog CEF, Syslog LEEF
Alert Group Syslog text messages
alert_group Syslog objects

To use alert groups in your integration, make sure to configure your partner services to display the alert group name.

By default, alerts are grouped as follows:

  • Abnormal communication behavior
  • Custom alerts
  • Remote access
  • Abnormal HTTP communication behavior
  • Discovery
  • Restart and stop commands
  • Authentication
  • Firmware change
  • Scan
  • Unauthorized communication behavior
  • Illegal commands
  • Sensor traffic
  • Bandwidth anomalies
  • Internet access
  • Suspicion of malware
  • Buffer overflow
  • Operation failures
  • Suspicion of malicious activity
  • Command failures
  • Operational issues
  • Configuration changes
  • Programming

For more information and to create custom alert groups, contact Microsoft Support.

Troubleshoot forwarding rules

If your forwarding alert rules aren't working as expected, check the following details:

  • Certificate validation. Forwarding rules for Syslog CEF, Microsoft Sentinel, and QRadar support encryption and certificate validation.

    If your OT sensors or on-premises management console are configured to validate certificates and the certificate can't be verified, the alerts aren't forwarded.

    In these cases, the sensor or on-premises management console is the session's client and initiator. Certificates are typically received from the server or use asymmetric encryption, where a specific certificate is provided to set up the integration.

  • Alert exclusion rules. If you have exclusion rules configured on your on-premises management console, your sensors might be ignoring the alerts you're trying to forward. For more information, see Create alert exclusion rules on an on-premises management console.

Next steps