The 2% Problem: Why Air-Gapping OT Write Access Isn't Simple

The Hypothesis

We found 447,000 write-capable ICS devices exposed to the internet:

• Modbus TCP accepting FC 5/6/15/16 (write commands)
• S7COMM accepting logic uploads
• EtherNet/IP accepting CIP write operations

These protocols have zero authentication by design (1970s-1990s legacy).

Our hypothesis: If it accepts writes, air-gap it. Read-only from internet via unidirectional gateway. Simple universal fix.

Research question: Is this actually feasible? How many devices are ICS-port-only vs ICS + remote access?

The Scan

The Results

Overall Finding

By Protocol

What "Remote Access" Means

Devices classified as "ICS + remote" typically had multiple services running:

Port count distribution:

• ICS-only devices: 1 port (just the ICS protocol)
• ICS + remote devices: Typically 20-300+ open ports
• Most extreme example: 365 open ports on single Modbus device

Example device profile:

ICS protocol: Modbus TCP (port 502)
Additional services:
  - HTTP/HTTPS (80, 443) - web HMI
  - RDP (3389) - engineering workstation access
  - SSH (22) - device management
  - VPN (1194, 500) - remote operations
  - OPC UA (4840) - historian integration
  + 300+ other services
        

This isn't misconfiguration. This is operational architecture by design.

Why Our Hypothesis Failed

1. Remote Operations Are By Design

Web HMIs:

• Operators monitor from control rooms (not physically on-site)
• Managers view dashboards remotely
• Emergency response teams need 24/7 access

VPNs:

• Shift workers dial in from home
• On-call engineers troubleshoot remotely
• Contractors access during outages

RDP/SSH:

• Vendor support sessions
• Engineering workstation access
• Patch deployment and updates

Air-gapping would break operational workflows for 98% of deployments.

2. The 2% That Are Air-Gappable

The 3 devices with ICS port only (IPs sanitized):

• Device A: [502] - Modbus only
• Device B: [502] - Modbus only
• Device C: [102] - S7COMM only

These are exceptions, not the rule.

Likely scenarios:

• Recently commissioned (not fully configured yet)
• Firewall misconfiguration (should have VPN but doesn't)
• Legacy system with no remote access requirement

For these 2%, air-gapping is trivial. For the other 98%, it's operationally infeasible.

What Actually Works

For the 2% (ICS-Only Devices)

For the 98% (ICS + Remote Access)

Layered approach:

Internet → VPN (MFA required) → Authenticated session
                                     ↓
                            ICS network (still no protocol auth)
                                     ↓
                            Segmented by function:
                              - Read-only: Web HMI, monitoring
                              - Write access: Engineering (second factor required)
                                     ↓
                            Unidirectional data diode for monitoring OUT
        

Implementation Steps

Immediate (24 hours)

• Enable VPN for all remote access - Force authentication before reaching ICS network
• Disable direct internet access - Close ICS ports to public internet
• Route all remote through VPN gateway - Single authentication point

Short-term (1 week)

• Add MFA to VPN authentication - Second factor required
• Segment by function - Web HMI (read) separate from engineering (write)
• Deploy unidirectional gateway - Monitoring traffic OUT only (read-only dashboards)

Long-term (1 month)

• Require second factor for writes - Engineering changes need additional auth
• Session recording - All remote access logged
• Anomaly detection - Monitor VPN traffic patterns for suspicious activity

Cost Comparison

Monday-Morning Actions

# For each write-capable device, enumerate all ports
nmap -p- YOUR_DEVICE_IP

# If ONLY ICS port responds:
# → Air-gap immediately (easy win, no operational impact)

# If ICS + other ports:
# → Cannot air-gap without breaking workflows
# → Proceed to layered authentication approach
        

# Step 1: Force VPN for all remote access
iptables -A INPUT -p tcp --dport 502 -s ! VPN_SUBNET -j DROP  # Modbus
iptables -A INPUT -p tcp --dport 102 -s ! VPN_SUBNET -j DROP  # S7COMM
iptables -A INPUT -p tcp --dport 44818 -s ! VPN_SUBNET -j DROP  # EtherNet/IP

# Step 2: Segment read vs write access
# Create separate VLANs for HMI (read) and engineering (write)

# Step 3: Deploy unidirectional gateway for monitoring
# Data flows OUT only (read-only dashboards, historians)
        

Why This Research Matters

What Consultants Say

"Air-gap your OT network. Implement Purdue segmentation. $200K project."

What We Found

• 98% of sampled devices are designed for remote access
• Air-gapping would cost more in operational downtime than implementation
• Authentication layer is cheaper and actually feasible

Defender Value

Stop trying to retrofit 1970s protocols with air-gaps they weren't designed for.

Add authentication ABOVE the protocol layer instead.

Validation & Limitations

Statistical Significance Analysis

Confidence Interval (95%)

The true proportion of air-gappable devices in the population:

95% Confidence Interval Visualization:

0%        2%        4%        6%        8%        10%
|---------|---------|---------|---------|---------|
[=========]
  0% - 4.3%

With 95% confidence, the true proportion falls within this range.
        

Hypothesis Testing

Null Hypothesis (H₀): At least 50% of devices are air-gappable (p ≥ 0.5)

Alternative Hypothesis (Hₐ): Fewer than 50% are air-gappable (p < 0.5)

Z-Score Distribution:

                   |
                   |    Our finding
                   |    (z = -11.76)
                   |    ↓
  -12  -10  -8  -6  -4  -2   0   +2  +4
   |    |    |    |    |    |    |    |
   [====================================]
                   ↑
              Null hypothesis
              (50% air-gappable)

Extremely unlikely if null hypothesis were true.
        

Alternative Hypothesis Test

Null Hypothesis (H₀): At least 10% of devices are air-gappable (p ≥ 0.1)

Alternative Hypothesis (Hₐ): Fewer than 10% are air-gappable (p < 0.1)

What We Can Say With Statistical Confidence

Sample Size & Power Analysis

Is 150 devices enough?

Sample Size Adequacy:

Minimum needed: 80 devices
Our sample:     150 devices
                ███████████████████ (187% of minimum)

Power achieved: 99%+ (well above 80% standard)
        

Sample Coverage

• Modbus: 50/312,000 (0.016%)
• S7COMM: 50/387,000 (0.013%)
• EtherNet/IP: 50/370,000 (0.014%)

Confidence Assessment

• High confidence: 98% of SAMPLED devices have remote access services
• Medium confidence: Extrapolation to full population (sample-based, larger validation recommended)
• Low confidence: Determining which remote access is "necessary" vs "convenience" (requires operational context)

Limitations

• Sample-based finding (150 devices from 1M+ population)
• Shodan visibility limited to internet-accessible devices
• Cannot determine if remote access is REQUIRED vs just ENABLED from port scan alone
• Actual air-gap feasibility depends on site-specific operational requirements
• IPs sanitized in publication (no target attribution)

Conclusion: The Value of Negative Results

We hypothesized: "Air-gap the write path" would be the simple universal fix for 447K attack vectors.

We scanned: 150 devices across 3 protocols to validate feasibility.

We found: Only 2% are air-gappable. 98% have intentional remote access architecture.

We're publishing the negative result because it's MORE valuable for defenders than if we'd been right.

The real fix isn't simple. But it's feasible. And honest.

Research by Jeff Gray, Cyborama OT Intelligence
Published: July 13, 2026
Data: Sanitized, sample-based, negative result
For defensive use by OT security professionals.

← Back to Control Systems Security · Previous: Purdue Model Layer 2 Failure