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 scanning 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 scan not based on IP address but on the abilities of a device to accept and respond to a scan 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 Scanning Outside of Traditional IT Devices?

First, find an asset discovery tool that can catalog the pedigree of devices, from their make and model to their OS and build. Grab a device and a wide variety of other types of devices in your environment, and power them up in a protected environment like a lab.

Second, build a policy to scan ONLY those devices with a specific OS, say a Windows OS running on an HMI. Mark device types never to be scanned as prohibited.

Third, 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.