By Daniel Pare and Dan Behrens
Identifying risks and vulnerabilities, and defining and deploying the appropriate security policies requires organizations to have an understanding of what assets are deployed in their environments. However, in industrial environments, equipment availability is critical to maintain safety and operations and any interruption can be costly. Traditional asset identification technologies do not work with industrial devices and as a result, many organizations have limited or no visibility into the current environment along with very little security controls in place.
Historically, when traditional IT scanning techniques, such as Nmap scanning or vulnerability scanning, have been used in industrial environments, industrial devices such as PLCs and I/O have been impacted causing production outages. This has led to many organizations to be rightfully skeptical of active asset detection methods in industrial environments.
Passive identification techniques have the benefit of being non-intrusive and thus are considered to be less likely to impact production. However, there are cases such as ghost devices or devices that communicate key attributes (e.g. firmware, serial number) infrequently where passive techniques can fall short of providing the asset and attribute visibility users need to support their security objectives. Active detection techniques, when done correctly and safely, can provide users with the ability to identify these ghost or quiet devices, shortening time to detection of assets and discovering assets from whom passively collecting the device traffic is not feasible due to sensor placement or other factors.
Palo Alto’s IoT/OT Security products have an active discovery mechanism called Device Attribute Polling. The key point of this functionality is it is not a network wide scan or device scan that checks for open ports, but it leverages the protocols the devices support and makes requests that are defined by the protocols over the port specified by the user (or default port for the protocol). This approach should not have a negative impact on industrial devices when it is configured and used correctly. Additionally, users have the ability to define specific devices or subnets that will be polled, and the ability to define exactly what protocols will be leveraged.
Furthermore, users have the ability to manually trigger the request, or schedule the request on a recurring basis for times and days that are best for the environment.
Q: How does Palo Alto’s IoT/OT Security Device Attribute Polling functionality work?
A: Device Attribute polling leverages either a PAN-OS plugin (PAN-OS 11.1 or greater) to make requests directly from the firewall or the on-prem XSOAR engine which can be deployed as a container on any modern operating system. In either method, the user defines what ports and protocols should be leveraged and what endpoints should be polled. Endpoints can be defined either by individual IPs or subnets. The user can then trigger the process manually or schedule the time of day and day of week when the discovery should be done. Once triggered, the request to end devices is done via the configured protocols.
Q: What protocols are supported by Device Attribute Polling?
A: The list of supported protocols can be found at the documents below:
PAN-OS Plugin: https://docs.paloaltonetworks.com/iot/iot-security-admin/get-started-with-iot-security/firewall-depl...
Q: Is Palo Alto’s IoT/OT Security Device Attribute Polling safe for industrial environments?
A: Yes, when properly configured. The common issue with scanning industrial assets is that many do not have extra resources for error handling, can be easily overwhelmed by excessive traffic, and can be disrupted when unexpected traffic is received. By limiting what protocols are used and defining over which ports communication is sent, risk of overwhelming devices and causing outages is mitigated.
Q: How is this different from traditional IT Scanning methodologies
A: Device Attribute Polling is not a network scan of the environment or an attempt to probe a device to see what ports are open or what protocols it supports. Users define the protocols and ports to leverage, which devices to communicate with, and when to do the communication.The system then uses native protocol methods to obtain asset data directly from devices. This method reduces the additional traffic on the network and reduces the likelihood of impacting the devices in the environment.
Q: When will Device Attribute Polling occur?
A: Users have full control of exactly when the requests will be generated. Users can either manually trigger the discovery or they can schedule for the discovery to trigger only during times when the concern of any possible impact is lower.
Q: Does Device Attribute Polling eliminate the need for passive detection?
A: While Device Attribute Polling enables gathering more in depth information about assets and in a much shorter amount of time, it does not provide the details on device behaviors. While understanding asset details is a critical step in identifying appropriate security policies for an environment, understanding actual device behaviors allows for security policies to be much better tailored to move to a zero trust approach to industrial security.
Q: When and where should I use Device Attribute Polling?
A: Device Attribute Polling should be used in cases where passive network traffic analysis is not yielding the desired level of device visibility. This is typically observed in environments where firewalls do not observe critical behaviors (e.g. ICS protocols) because the firewall is either not inline with the necessary traffic or the network infrastructure is not configured to (or does not allow) mirror traffic to the NGFW. Device Attribute Polling can obtain the necessary key device attributes for complete asset identification.
We recommend that polling be limited to subnets or specific IP addresses that are known to contain industrial devices using protocols supported by Device Attribute Polling. Users can configure specific IPs or Subnets to be polled using specific protocols (e.g. Subnet A polled using S7, while Subnet B is polled using CIP-IP) instead of polling end points with all protocols. This reduces the amount of additional traffic introduced to the network, as well as reduces the risk of polling a device with an unsupported protocol and potentially causing an issue. Finally, polling should be done, when possible, outside of production hours to limit the amount of traffic flowing through the network at any given time and to reduce the potential consequence of an issue in the unlikely case that an issue arises.
Q: Where is Device Attribute Polling performed?
A: Palo Alto provides flexibility with how and where device attribute polling can be performed. On firewalls running PANOS 11.1.0 or greater, the Network Discovery Plugin can be leveraged to perform device attribute polling. This enables the ability to perform polling directly from the firewall(s) in the environment without any additional licenses. For additional details please see the PAN-OS Plug-in administrators guide: https://docs.paloaltonetworks.com/iot/iot-security-admin/get-started-with-iot-security/firewall-depl...
Alternatively, polling can be performed by an XSOAR engine deployed within the target environment (https://docs.paloaltonetworks.com/iot/iot-security-integration/asset-discovery/learn-device-attribut...). Attribute Polling via XSOAR requires either a full-feature XSOAR license or an IoT Security Third-Party Integration license.
Q: When should organizations leverage the XSOAR engine versus the Network Discovery Plugin?
A: While either method can be leveraged to obtain key device attributes for complete asset identification, there are several factors that may lead to one method being preferred over another. In environments such as those with where third party devices such as firewalls have rules that prevent the Palo Alto firewalls to reach the end devices, control networks are not connected back into the network where the firewalls are located, or other network architectures that do not provide the ability for the firewall to have reachability to all the devices that an organization is attempting to discover, the XSOAR engine may be a better fit because engines can be strategic deployed to provide the required observability. Additionally, organizations may prefer to leverage the XSOAR engine in environments where the firewalls are not able to support the Network Discovery Plugin due to the PAN-OS version, or an XSOAR engine has already been deployed for other features beyond Device Attribute Polling.
Environments without these scenarios or for customers who do not have XSOAR/IoT Add-on License, the Network Discovery Plugin on the firewall may be the preferred deployment mode. This allows all OT discovery related functionality managed and running on the same firewall without requiring additional resources in the environment or needing to purchase additional licenses. Palo Alto will continue to develop additional protocol support and strives to maintain parity between the XSOAR engine and Network Discovery Plugin supported protocols, but there may be instances where a new protocol is introduced that may only be supported by one or the other. In this instance, needed protocols may be another factor that determines which method would work best for your environment.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
| Subject | Likes |
|---|---|
| 3 Likes | |
| 2 Likes | |
| 1 Like | |
| 1 Like | |
| 1 Like |
