IoT Security Integration Guide
    : Learn Device Attributes by Polling
    Focus
    Download PDF
    Focus
    1. Home
    2. IoT
    3. IoT Security Integration Guide
    4. Asset Discovery
    5. Learn Device Attributes by Polling
    Download PDF

    IoT Security Integration Guide

    Learn Device Attributes by Polling

    Table of Contents

    Learn Device Attributes by Polling

    Poll devices on the network to learn their attributes.
    To identify devices and detect vulnerabilities, IoT Security must first learn device attributes, such as the vendor, model, firmware, OS, and so on. It does this primarily by analyzing network traffic metadata in the logs it receives from next-generation firewalls or from Prisma Access and SD-WAN devices. IoT Security can optionally supplement this data with more learned from third-party integrations.
    However, in some cases, devices might generate traffic that doesn’t reach a firewall or Prisma device and there are no third-party systems with which to integrate and import information. In other cases, devices might generate so little traffic that there simply isn’t enough for a thorough analysis. In particular operational technology (OT) devices are not always discoverable, especially when firewalls are deployed on the network edge. For example, control devices and sensors communicate predominantly with the devices they manage or monitor. To provide IoT Security with the data it needs to identify OT devices and assess their risk level, integrate IoT Security with Cortex XSOAR to poll devices to learn their attributes. IoT Security and XSOAR support polling OT devices that use the following protocols: BACnet, CIP Ethernet/IP, CodeSysV3, IEC 61850 MMS, Modbus, Siemens-S7, Siemens-S7-Comm-Plus, SNMPv1, SNMPv2, SNMPv3, and WinRM. IoT Security displays the attributes it learns through polling on the following pages:
    • AssetsDevices
    • AssetsDevices device_name Device Details
    • AssetsDevicesIP Endpoints
    When XSOAR learns attributes for assets that are already in the IoT Security database, IoT Security adds whatever attributes it didn't yet have for them. When it learns attributes for assets that aren't yet in its database, it creates new entries for them. If IoT Security learns the IP address and MAC address of a new device, which it can when using SNMP to poll, it adds a new entry to the Devices page. If it learns only an IP address, it adds a new entry to the IP Endpoints page.
    When polling DHCP clients, ensure that IoT Security is getting metadata from DHCP traffic logs so that it can update the devices in its inventory with changing DHCP-assigned IP addresses. This way, the IP address-to-device mapping will be up to date and in sync with the attributes learned per IP address through asset attribute polling.
    For most device attributes, IoT Security uses the latest value it learns regardless of whether it’s discovered through network traffic or through an integration. However, there are ten attributes for which a value learned through network traffic has priority even if IoT Security later learns of a different value through integration:
    • Model
    • Vendor
    • OS group
    • OS version
    • Firmware
    • Serial number
    • Wired or wireless
    • VLAN
    • Hostname
    • Active Directory domain
    If IoT Security learns a conflicting value for one of these attributes, it prioritizes the value learned through network traffic first and then through an integration (including asset attribute polling) second. The basic logic is as follows:
    • Whatever new value is learned through network traffic replaces a value learned previously by any means.
    • A new value learned through integration will replace a previously learned value learned through the same type of integration. It won’t replace a value learned through network traffic or through another type of integration.
    When using a cohosted, limited-featured Cortex XSOAR instance, this integration requires an IoT Security Third-party Integrations Add-on license and an on-premises XSOAR engine. When using a full-featured Cortex XSOAR server on premises, no add-on license is required and an XSOAR engine is only needed if the network topology requires an engine to reach a part of the network that the XSOAR server cannot. When using a full-featured Cortex XSOAR server in the cloud, an add-on license is not required but an on-premises XSOAR engine is.

    Cortex XSOAR Engine Installation

    When using a cohosted XSOAR instance, a cloud-hosted XSOAR server, or an on-premises XSOAR server that cannot reach part of the network, XSOAR performs device polling through an on-premises XSOAR engine. Although it's possible to install an XSOAR engine on machines running Windows, macOS, and Linux operating systems, only an engine on a Linux machine supports IoT Security integrations. For more information about operating system and hardware requirements, see the Cortex XSOAR Administrator's Guide.
    We recommend downloading the XSOAR engine using the shell installer script and installing it on a Linux machine. This simplifies the deployment by automatically installing all required dependencies and also enables remote engine upgrades.
    When placing the XSOAR engine on your network, make sure it can reach the devices you want to poll using the relevant network services:
    • BACnet: UDP port 47808
    • CIP Ethernet/IP: TCP port 44818, UDP port 44818
    • CodeSysV3: UDP port 1740
    • IEC 61850 MMS: TCP port 102
    • Modbus: TCP port 502
    • Siemens-S7: TCP port 102
    • Siemens-S7-Comm-Plus: TCP port 102
    • SNMPv1, SNMPv2, SNMPv3: UDP port 161
    • WinRM: TCP port 5985
    When using the cohosted Cortex XSOAR instance, intervening firewalls must also allow the engine to form HTTPS connections on TCP port 443 to the Cortex cloud at https://<your-domain>.iot.demisto.live/. You can see the URL of your XSOAR instance when you log in to the IoT Security portal and click IntegrationsLaunch Cortex XSOAR. It’s visible in the address bar of the web page displaying the XSOAR interface. When using a cloud-hosted Cortex server or a server deployed on-premises with an engine, make sure the engine can reach an equivalent URL on your server.
    To create an XSOAR engine, access the Cortex XSOAR interface (from the IoT Security portal, click IntegrationsLaunch Cortex XSOAR). Click SettingsEngines+ Create New Engine. Choose Shell as the type.
    For installation instructions, see Install .
    For help troubleshooting Cortex XSOAR engines, including installations, upgrades, connectivity, and permissions, see Troubleshoot and Troubleshoot Integrations Running on Engines.

    Configure IoT Security and Cortex XSOAR

    1. Log in to IoT Security and from there access settings for device polling settings in Cortex XSOAR.
      1. Log in to IoT Security and then click Integrations.
      2. IoT Security uses Cortex XSOAR to poll devices, and the settings you must configure are in the XSOAR interface. To access these settings, click Launch Cortex XSOAR.
        The Cortex XSOAR interface opens in a new browser window.
      3. Click Settings in the left navigation menu, search for asset attribute polling to locate it among other instances.
    2. Configure the Asset Attribute Polling integration instance.
      Each Asset Attribute Polling instance is configured to poll devices using a specific protocol (or all protocols).
      1. Click Add instance to open the settings panel.
      2. Enter the following settings:
        Name: Use the default name of the instance or enter a new one.
        Remember the instance name because you are going to use it again when creating a job that Cortex XSOAR will run to gather device attributes.
        Protocol: Choose the protocol you want to use for device polling: BACnet, CIP Ethernet/IP, CodeSysV3, IEC 61850 MMS, Modbus, Siemens-S7, Siemens-S7-Comm-Plus, SNMPv1, SNMPv2, SNMPv3, or WinRM. If you choose All, XSOAR first performs a portscan using the default port numbers of each protocol to learn which devices have these ports open and are actively responding. It then uses whichever protocols elicited a response when polling.
        Port: Leave the field empty to use the default TCP or UDP port numbers or enter a custom port number.
        When you enter a custom port number, XSOAR polls devices on that port using the same TCP and UDP transports it uses to poll with the default port number.
        When polling with SNMPv1 or SNMPv2, enter an SNMP community string that matches the one on the devices to be polled. When polling with SNMPv3, enter a username, and choose a security level (noAuthNoPriv, AuthNoPriv, or authPriv). Then depending on the security level chosen, enter an authentication protocol (MD5 or SHA), authentication password, privacy protocol (DES or AES), and privacy password. When the security level is noAuthNoPriv, enter just an SNMP username; a password is unnecessary. For information about these settings, see Set up IoT Security and Cortex XSOAR for SNMP Discovery.
        When polling with WinRM, enter a WinRM username and password.
        Run on Single engine: Choose the XSOAR engine that you want to poll devices. When using an on-premises XSOAR server that doesn’t require an XSOAR engine, leave this field empty.
      3. When finished with the configuration, enter an IP address of a device within a subnet that you want to probe in the Connection Test IP field and then click Test.
        This tests connectivity between the cohosted XSOAR instance or XSOAR server and a device to be polled. It uses the selected protocol to contact the device at the specified IP address on the specified TCP or UDP port (or both TCP and UDP if the protocol supports both). For example, if you want to poll multiple devices for asset attributes in a subnet, pick the IP address of a device you know is in that subnet—and is responsive to the protocol on the port number specified—and XSOAR sends a probe request to that device. If this device responds, you can safely assume XSOAR will reach others in the same subnet.
        If you select All for connection testing, XSOAR uses each protocol sequentially to probe the target device. If it gets a response, it returns a Success message and stops probing. If it doesn't receive a response with one protocol, it times out after two seconds and tries the next protocol until it either gets a response from one of them or from none at all.
        If the test is successful, a Success message appears. If not, check that the settings were entered correctly and then test the configuration again.
      4. After the test succeeds, click Done to save your changes, close the settings panel, and activate the instance.
    3. To poll devices using other protocols or through other XSOAR engines, repeat the previous steps to add more integration instances.
    4. Create a job for XSOAR to poll devices and add returned attributes to IoT Security.
      The job configuration defines which IP addresses to poll and which playbook and integration instance to use. If the job is set to run on a recurring schedule, it also specifies the polling interval.
      1. Copy the name of the instance you just created, click Jobs near the bottom of the left navigation menu and then click New Job at the top of the page.
      2. In the New Job panel that appears, enter the following and leave the other settings at their default values:
        Recurring: Select this if you want to periodically poll devices. Clear it if you want to poll devices on demand.
        Every: If you select Recurring, enter a number and set the interval value (Minutes, Hours, Days, or Weeks) and select the days on which to run the job. (If you don’t select specific days, then the job will run everyday by default.) This determines how often XSOAR polls for device attributes. For example, every day at 11:00 AM.
        Name: Enter a name for the job.
        Playbook: Choose Bulk Import Device Attributes Using Device Polling - PANW IoT 3rd Party Integration.
        Device Polling IP/Subnet: Set the scope of the polling by entering one or more comma-separated device IP addresses (IP address example: 10.1.1.20) or one or more comma-separated subnet addresses (subnet example: 10.1.1.0/24). You can combine IP addresses and subnets. The number of IP addresses cannot be more than 1500, and a subnet cannot be larger than 255.255.255.0 or /24.
        Integration Instance Name: Paste the instance name you copied a few moments ago.
      3. Click Create new job.
        The job appears in the Jobs list.
    5. Enable the job and run it.
      1. Check the Job Status for the job you created. If it’s Disabled, select its check box and then click Enable.
      2. After you enable it, keep the check box selected and click Run now. The Run Status changes from Idle to Running.
        If you selected Recurring, XSOAR performs device polling at the defined interval and forwards the device attributes it learned to IoT Security.
        If you cleared Recurring, XSOAR immediately performs polling and forwards device attributes to IoT Security.
    6. If you created more integration instances for multiple XSOAR engines, add more jobs as necessary.
      Each XSOAR engine requires a separate job.
      Run the job for each integration instance you create. The first time you run a job that references an integration instance, it triggers XSOAR to report the instance to IoT Security, which then displays the integration instance on the Integrations page.
    7. When done, return to the IoT Security portal and check the status of the Device Polling integration.
      An integration instance can be in one of the following four states, which IoT Security displays in the Status column on the Integrations page:
      • Disabled means that either the integration was configured but intentionally disabled or it was never configured and a job that references it is enabled and running.
      • Error means that the integration was configured and enabled but is not functioning properly, possibly due to a configuration error or network condition.
      • Inactive means that the integration was configured and enabled but no job has run for at least the past 60 minutes.
      • Active means that the integration was configured and enabled and is functioning properly.
      When you see that its status is Active, the setup is complete.
      To view the results of a polling job, return to the Jobs page in the XSOAR interface and click Completed in the Run Status column for the asset attribute polling job you ran. Click Work Plan and then click the green box for "Fetch Asset Attribute Polling info and Send to PANW IoT Cloud". You can see how many IP addresses were polled, how many IP addresses XSOAR retrieved attributes from, and how many IP addresses were updated in IoT Security. When using SNMP, XSOAR polls either IP or MAC addresses and then updates devices in the IoT Security inventory accordingly. For more information about XSOAR playbooks, see XSOAR Playbooks.

    © 2024 Palo Alto Networks, Inc. All rights reserved.