How do you vulnerability-scan a segment of fragile operational-technology controllers and legacy hosts without causing an outage?
answer
- treat the scan as a change
- inventory before you probe
- rate, concurrency, ports, check set
- trial on a spare, then ramp
- passive where probing is refused
basics
~20 sTreat the scan as a change: agree a window, an owner on call and a stop condition; scan from inside with non-intrusive checks, low concurrency and a narrow port list; trial on a spare first; leave untouchable devices to passive observation.
solid answer
~50 sTreat the scan as a production change. Build the inventory first, passively if you can, and sort devices into those that tolerate active probing and those that do not. Agree a **window**, an **owner on call** and a **stop condition** with the operators. Configure conservatively: non-intrusive checks only, few simultaneous hosts and checks per host, longer timeouts, a restricted port list instead of a full sweep, and a scanner inside the enclave so no firewall in the path is stressed. Trial the exact configuration on a spare unit or test bench, then ramp: one device, a small group, the rest. Some scanners offer a setting that identifies controller-class devices and stops after discovery; where it exists, keep it on unless the owner signs off. For devices nobody will let you probe, rely on passive monitoring and firmware records, and record that as a known gap.
go deeper
Recall that active scanning can crash or reboot delicate devices, so fragile segments need a planned window, conservative settings and someone from operations watching.
Explain which settings reduce harm (non-intrusive checks, low host and per-host concurrency, longer timeouts, a narrow port list) and why the discovery and port-probing phase is itself a risk.
Walk through the change-managed plan: inventory and tolerance classes, window, owner on call, stop condition, bench trial and ramp, plus what you do when a device fails mid-scan.
Decide where active scanning's evidence is worth its operational risk and where passive monitoring and compensating controls carry the segment instead, and make that gap visible in programme reporting.
## Why fragile hosts fall over Operational-technology (OT) devices such as programmable controllers and remote terminal units, and many legacy hosts, were built for predictable traffic from a few known peers. An active vulnerability scan is the opposite: thousands of connections, unusual flags, malformed requests and protocol reads in quick succession. Typical failure modes are: - **small network stacks** that run out of connection slots and stop answering, or reboot; - **malformed-packet handling** that crashes the communication module; - **protocol-level interactions**, where an industrial protocol query has side effects on the process it controls; - **shared, low-bandwidth links** where scan traffic delays real-time control messages. Even a check marked non-intrusive can cause harm here, because the discovery and port-probing phase alone can be too much for some devices. ## Plan the scan as a change 1. **Inventory first.** Use passive observation of the segment's traffic, the engineering team's records and the asset register to list every device, its type and firmware. 2. **Classify tolerance.** Split devices into *probe-tolerant* (ordinary servers and workstations in the enclave), *probe-sensitive* (scan only with a minimal configuration in a window) and *do-not-probe* (passive only). 3. **Agree the window.** Pick a time when the process can tolerate an interruption, such as a planned maintenance period, with the operators present and a named owner on call. 4. **Define the stop condition.** For example: any device unresponsive for more than a few seconds, any alarm on the control system, or any operator request; the scan stops at once and nobody restarts it without a review. 5. **Trial first.** Run the exact configuration against a spare unit or test bench of the same model and firmware. 6. **Ramp.** Scan one production device, check it, then a small group, then the rest. ## Tuning the scan | Setting | Fragile-segment choice | Why | |---|---|---| | Check set | Non-intrusive checks only; no denial-of-service or exploit-style checks | Intrusive checks are designed to stress or exercise the flaw | | Simultaneous hosts | Very low, often one or two | Limits load on the shared link and the scanner's burst | | Checks per host | Very low | Limits concurrent connections against one small stack | | Network timeout | Longer than default | Slow devices otherwise look dead or trigger retries | | Port list | The device's known service ports only | A full sweep of tens of thousands of ports is the riskiest part | | Controller-class handling | Identify and stop after discovery, unless signed off | Some scanners offer exactly this behaviour as a setting | | Scanner position | Inside the enclave | Avoids stressing the boundary firewall and its state table | Some scanners also offer a setting that slows the scan when it detects network congestion; where it exists, turn it on for these links. ## Scan windows for the rest of the estate Scan windows are not only an OT concern. Any host whose owner cannot accept a slowdown, such as a busy database or a legacy line-of-business server, deserves an agreed window, a schedule the owner can see, and a way to pause the scan. A scan that runs into business hours because a window was too short should stop and resume later rather than finish at all costs. ## What to do for devices you cannot probe - **Passive monitoring** of the segment's traffic identifies device types, firmware versions and protocols without sending anything. - **Configuration and firmware records** from the engineering team can be compared with published advisories by hand or by tool. - **Compensating controls**, such as tighter segmentation and monitoring of the boundary, carry the risk the scan cannot measure. - **Record the gap** explicitly in coverage reporting, so passive-only devices are a known category and not silently missing. ## Signs to stop Stop and review if a device stops answering, an operator sees alarms or delays, or the scan's own timeouts climb sharply. Afterwards, keep the scan log that shows which probes hit which device and when; it is what lets you reproduce a failure on the bench and add a precise exclusion instead of excluding the whole segment.
- The plant owner asks for a guarantee that the scan will not trip anything. What do you offer?Not a guarantee, because none is honest. Offer the evidence instead: the bench trial on the same model and firmware, the conservative configuration, the agreed window, the stop condition, and the person watching it. For any device where that is still too much risk, offer passive observation and record it as a known gap.
- A controller rebooted during the window. What do you do next?Stop the scan at once and confirm with the owner that the process is safe. Pull the scan log to see which probes reached that device and when, reproduce it on the bench, and replace the broad setting with a precise exclusion. Until then, move that model to passive-only and tell its vendor if a standard probe crashes it.
- Why scan the enclave from a scanner inside it rather than across the boundary firewall?Scanning across the boundary pushes thousands of connections through the firewall's state table, which can hurt the control traffic it carries, and the firewall's policy distorts the results. An inside scanner keeps the load on the segment you have planned for and measures the devices rather than the boundary.
saying these in an interview costs you the question
- Enabling non-intrusive checks only makes a scan harmless to any device.
- Scanning at night is enough to make a scan of fragile devices safe.
- Fragile devices should simply be excluded from scanning and forgotten.
- A full port sweep is needed on every device or the scan is incomplete.
- The firewall in front of the enclave protects its devices from scan traffic.