What is Operational Technology (OT) Scanning?

Vulnerability scanning is a process whereby computing endpoints of interest are virtually probed for vulnerabilities, security weaknesses, and security gaps. Scanning is a methodology built to probe for weakness, whether known CVE’s, system flaws, open ports, or misconfigurations.

Although commonly found within the IT side of the house, scanning for weaknesses on the IoT and OT side has long been debated, with endless stories of frozen sensors, stalled elevators, and locked doors. When originally constructed, these ‘non-IT’ devices were not built to accept scanning. As a whole, sensors, controllers, meters, and the like often arrive underpowered, with little memory and a specific static function in mind. Scan for open ports on a motion sensor, and you might get a locked door or a frozen elevator. Scan for an OS build on a PLC, and you might get a tripped controller.

We have all heard these horror stories of active scanning on non-IT-based devices. But what if our system inherently knew of the pedigree of the device and software on the other end of the IP address? Wouldn’t it be nice to intelligently discover not based on IP address but on the abilities of a device to accept and respond properly? Knowing the difference between a SCADA server running Windows 7, an HMI running Windows CE6.0, an engineering Workstation running Windows 10, and a PLC running VxWorks, all rife with their own vulnerabilities, would be a valuable set of information when deciding to bring OT and ICS devices into the fold of active scanning.

A Best Practice in Implementing Device Discovery Outside of Traditional IT Devices?

To reiterate, scanning an OT network is something to stay away from, however there are methods that will enable organizations to gain information from assets that are dormant or do not communicate over the network.

Active querying in OT (Operational Technology) environments involves the use of specialized technology to interact with and retrieve information directly from industrial devices, such as Programmable Logic Controllers (PLCs), Remote Terminal Units (RTUs), and other components. Unlike passive monitoring, which observes network traffic, active querying initiates communication with devices in their native language to gather specific information.

Armis Smart Active Querying starts with the identification of target devices, IP ranges, VLANs etc. within the OT network. This can involve discovering devices based on known protocols, IP addresses, or other device characteristics. Active querying is conducted using the native industrial device communication protocols. This ensures compatibility and minimizes the risk of disruption. The queries are formulated in the specific device’s native device language, and emulates the queries made by an Human Machine Interface (HMI) to the device. The queries retrieve specific device information, including details such as device type, firmware version, configuration settings, logged-in users, and other relevant metadata. Security including encryption and authentication protects the process and the data being retrieved.

To ensure the safety and stability of the queried devices, active querying is typically read-only. Active querying is often performed during periods of low network utilization to minimize any potential impact on operational processes. Optimally timing polling intervals helps ensure that the querying process does not interfere with the real-time demands of industrial systems.Armis Smart Active Querying solutions empowers administrators with customization options, allowing organizations to define query frequencies, policies, and specific IP ranges. This flexibility ensures that the active querying process aligns with the unique requirements of each specific OT environment.

Let your discovery tool go to work to identify and scan those devices that fall into the bucket of desirable devices to scan.

Lastly, review for the outcome. Did your discovery tool accurately identify all assets? Did your policy run as intended? Did any devices respond to a probing scan unexpectedly?

A best practice would be to repeat step 3 under varying degrees of load on the devices in question. Just because a device responded well to a scan while idle does not mean it will respond similarly under load.