The Problem: Your "Air-Gapped" Systems Aren't
If you think your operational technology is safely isolated, you're likely mistaken. The UK's National Cyber Security Center issued three warnings about internet-exposed edge devices in just five months. When a national security agency repeats itself that often, the next step might be mandatory regulations.
Your programmable logic controllers, human machine interfaces, and SCADA endpoints might be accessible from the internet right now. This isn't due to sophisticated exploits but often because of forgotten vendor connections, misconfigured firewalls, or unmanaged devices missing from your asset register. Attackers don't need new malware when they can easily find exposed devices running default credentials.
This is critical because attacks on OT systems are rising globally across multiple sectors. Adversaries target the easiest entry points, and internet-exposed control devices fit the bill. For your team, an OT compromise doesn't just mean data loss, it means production halts, safety systems fail, or physical infrastructure goes offline.
What You Need Before Starting
Before securing OT systems, you need to know what you have and where it connects. Gather these resources:
Network documentation: Collect every network diagram, firewall rule set, and remote access configuration. Include vendor maintenance contracts specifying remote connectivity.
Stakeholder access: You'll need cooperation from operations teams managing physical processes, IT teams handling the network perimeter, and any third-party vendors with maintenance contracts.
Scanning tools for OT protocols: Standard IT vulnerability scanners can crash industrial devices. Use tools designed for protocols like Modbus, DNP3, and BACnet. If you lack an OT-specific scanner, start with passive network monitoring.
A test environment: Validate your approach on non-production systems first. A misconfigured scan can trigger safety shutdowns.
Recovery documentation: Know how to restore each control device to a known-good state. This includes firmware images, configuration backups, and vendor contact information.
Step-by-Step Implementation
Phase 1: Inventory What's Actually Connected
Begin with external attack surface scanning. Tools like Shodan and Censys index internet-facing devices, including yours. Search your organization's IP ranges and ASN blocks to see what an attacker sees. Look for exposed VNC sessions, web-based HMI portals, and control devices on standard industrial ports.
Document each finding with its IP address, protocol, device type, and current authentication method. According to Team82's analysis, 88% of cyber-physical systems fail to transmit exact product codes, and 76% use product names that don't match vendor records. Your inventory must go beyond automated discovery, cross-reference with procurement records and maintenance logs.
Next, map internal connectivity. Deploy passive monitoring on your OT network segments to capture actual traffic patterns. You're building a baseline of what communicates with what, which protocols are in use, and where data flows cross network boundaries. This reveals vendor connections and "temporary" remote access paths that nobody documented.
Phase 2: Eliminate Direct Internet Exposure
No programmable logic controller or human machine interface should accept connections directly from the internet.
For devices currently exposed, follow this hierarchy:
Remove unnecessary connectivity. If a device doesn't need remote access, physically disconnect it or block it at the firewall. Many exposed systems were configured for one-time vendor maintenance and never secured afterward.
Route required remote access through secure gateways. Use a jump server or VPN concentrator that enforces multi-factor authentication. Remote sessions should terminate at the gateway, not at the control device. Team82 found 82% of analyzed CPS attacks involved VNC clients accessing exposed assets, this architecture eliminates that vector.
Segment OT networks from IT and the internet. Use separate VLANs or physical network segments with firewall rules that default-deny. Allow only specific, documented connections between zones. Your firewall should log every attempt to cross zone boundaries.
Phase 3: Harden What Remains Accessible
For devices that must remain reachable:
Replace default credentials immediately. Use unique, complex passwords or certificate-based authentication. Store credentials in a privileged access management system, not in shared spreadsheets.
Disable insecure protocols. Replace Telnet with SSH, HTTP with HTTPS, and unencrypted VNC with encrypted alternatives. If legacy devices can't support modern protocols, isolate them behind protocol-translating gateways.
Prevent unauthorized programming. Configure PLCs to reject remote programming commands during production hours. Require physical presence or multi-person authorization for configuration changes.
Enable comprehensive logging. Capture authentication attempts, configuration changes, and network connections. Forward logs to a SIEM that operations and security teams both monitor.
Phase 4: Address the Legacy Problem
Devices running 30-year-old firmware won't support modern security controls. You have three options:
Replace them if budget and operations allow. This is the cleanest solution but often politically difficult.
Isolate them behind protocol gateways that translate between legacy industrial protocols and modern secure channels. The gateway handles authentication and encryption while the legacy device sees familiar traffic.
Compensate with network controls if replacement isn't feasible. Use network segmentation, strict firewall rules, and continuous monitoring to detect anomalous behavior around devices you can't directly harden.
Validation: How to Verify It Works
Run external scans monthly from outside your network perimeter. You should find zero exposed OT devices. If you discover new exposures, your change control process needs tightening.
Test your remote access paths quarterly. Attempt to connect to OT devices directly from the internet, you should hit a firewall block or authentication gateway, never the device itself.
Review firewall logs weekly for rejected connection attempts crossing OT zone boundaries. Investigate every unexpected attempt. Most will be misconfigurations, but some indicate reconnaissance.
Conduct tabletop exercises where you simulate an attacker gaining access to an exposed device. Can your monitoring detect it? Can operations continue if that device goes offline? Can you restore it without vendor support?
Maintenance: Ongoing Tasks
Monthly: Review external attack surface scans. Verify no new devices have appeared in public search engines.
Quarterly: Audit remote access logs. Confirm every connection came from authorized personnel through approved gateways.
Semi-annually: Reassess your OT inventory. New equipment gets added, vendor contracts change, and "temporary" connections become permanent. Update your network documentation and verify segmentation controls still work.
Annually: Test your recovery procedures for each critical device type. Firmware updates, configuration backups, and vendor contact lists go stale.
The NCSA's repeated warnings signal a shift from voluntary guidance to regulatory mandate. CISA's binding directive on end-of-support edge devices already demonstrates this pattern in the US. Your choice isn't whether to lock down internet-exposed OT, it's whether you do it on your timeline or a regulator's.
