Safe ICS/OT Security Scanning: How HailBytes ASM Protects Your Industrial Network

Active vulnerability scanning against IT infrastructure is routine. You schedule a scan, review findings, and close tickets. The blast radius of a misconfigured scanner is bounded — at worst, a web server returns a 500 for a few seconds. Industrial control systems (ICS) and operational technology (OT) networks operate under different physics. A malformed Modbus request to a PLC on an active production line can change an output state. An unsolicited probe to an HMI during a critical process window can trip an operator alarm. In the worst case, an aggressive scan contributes to unplanned downtime.

HailBytes ASM supports ICS/OT scanning for customers who need to assess the security posture of their industrial networks. This release hardens that capability with three changes designed to make ICS/OT scanning safer, more transparent, and more useful: an explicit authorization gate, a rate limiter in the Modbus scanner, and a customer-facing PDF assessment report.

Why active ICS/OT scans require explicit authorization

The protocols that govern industrial equipment — Modbus, S7, DNP3, BACnet, EtherNet/IP, IEC 60870-5-104, OPC UA, CODESYS — were designed for reliability and determinism, not security. They generally lack authentication, use predictable port assignments, and respond to any well-formed request from any source. That is exactly what makes them useful for assessment: you can probe a Modbus device with a read-holding-registers request and immediately learn whether it accepts unauthenticated commands. It is also what makes active scanning risky in live environments.

HailBytes ASM now requires a per-scan acknowledgement (ics_ot_acknowledged=true) before any scan engine that includes active ICS/OT tasks is launched. The gate is enforced server-side — in both the UI submission flow and the REST API — so it cannot be bypassed by client-side manipulation, and it cannot be pre-accepted in a saved scan configuration. It must be checked at submission time. An operator who clicks through the authorization modal has made a deliberate choice; an API client that sends ics_ot_acknowledged=true was explicitly configured to do so. Neither happens by accident.

What the Modbus scanner actually checks

The Modbus assessment evaluates three checks, each scoped to the minimum interaction needed to confirm an exposure:

• OT-001 — Unauthenticated Modbus register read. A single holding-register read (function code 3, address 0, count 1) with no writes. If the device answers, it accepts unauthenticated commands.
• OT-002 — Cleartext Modbus TCP transmission. Confirms the device speaks Modbus over plain TCP with no TLS, exposing process data and commands to anyone on-path.
• OT-003 — Default credentials on a co-located PLC HMI. A single credential pair (admin:admin) against the device’s web interface — no brute-force iteration.

The conservative footprint is intentional: the information value of confirming an unauthenticated Modbus exposure is identical whether you read one register or sixteen; the risk profile is not.

Rate limiting: protecting time-sensitive devices

Even in authorized OT scanning, the rate of probes matters. A PLC or HMI that handles ten Modbus requests per second as part of normal process control can behave unpredictably under two hundred per second from a scanner. The Modbus scanner accepts a rate_limit option (probes per second) and uses a monotonic-clock throttle to enforce it across multi-host sweeps.

The default safe-mode configuration issues the minimum probe per device. Deeper fingerprinting (reading a wider register block) is gated behind an explicit safe_mode=False option. The broader scada-scanner phase defaults --safe-mode ON for the same reason.

Assessment scope tables: coverage vs. findings

A report that lists only findings has an ambiguity problem: a blank findings section could mean “no vulnerabilities found” or “nothing was checked.” That ambiguity matters more in OT, where security programs are often less mature and stakeholders may not know what was evaluated.

ICS/OT reports now include a full assessment scope table alongside findings. For each check the scanner evaluates — OT-001, OT-002, OT-003 — the report shows whether it confirmed an exposure or found none. That turns “no findings” into a positive assertion (“we checked, nothing was detected”) rather than an absence of information. The summary statistics now lead with “checks evaluated” rather than a severity count, reinforcing the distinction between assessment breadth and finding severity.

Customer-facing PDF reports

OT assessments frequently need documentation for audiences beyond the security team: plant managers, compliance auditors, insurance underwriters, and executive sponsors. HailBytes ASM generates a branded PDF assessment report for ICS/OT scan runs — a professional summary, severity-badged findings with CVSS scores and CWE reference links, the assessment scope table, and an optional Markdown summary suitable for CI artifact publishing. This maps directly onto IEC 62443 and NERC CIP documentation needs.

What this means for MSSP customers

If you operate HailBytes ASM on behalf of customers in manufacturing, utilities, healthcare, or other sectors with OT infrastructure, these changes affect your delivery workflow. The authorization gate means active ICS/OT engines must be explicitly acknowledged at submission — document that step in your engagement runbooks. The rate limiter and safe-mode defaults give you a defensible baseline configuration to use in customer environments, and the PDF output is a deliverable you can hand to stakeholders without post-processing.