The Purdue Model's Dirty Secret: Protocol Isolation Fails Where It Matters Most

The Purdue Model Gospel

If you've taken an OT security course, you've seen this diagram:

Level 4: Enterprise Network
Level 3: Site Operations
Level 2: Supervisory Control
Level 1: Basic Control
Level 0: Process Control
        

The Purdue model promises clean protocol isolation. Level 0 runs one protocol. Level 1 runs another. They never mix.

Every consultant's assessment:

• "Implement network segmentation per Purdue model"
• "Prevent cross-protocol lateral movement"
• "Isolate Modbus from S7COMM traffic"

Cost: $50,000+ for the assessment. $200,000+ for implementation.

But nobody asks: Is protocol mixing actually happening? At what layer? And where should defenders focus?

What We Measured

We scanned 2.57 million ICS devices across 7 industrial protocols:

Research questions:

1. Do individual IPs run multiple ICS protocols? (Host-level isolation)
2. Do different protocols cluster in the same subnets? (Network-level isolation)
3. Where does the Purdue model actually break down?

What We Found

Finding #1: Host-Level Isolation Works Perfectly

Zero IPs run multiple protocols.

We checked every combination:

• Modbus + S7COMM: 0 overlaps
• Modbus + DNP3: 0 overlaps
• S7COMM + EtherNet/IP: 0 overlaps
• DNP3 + IEC-104: 0 overlaps
• All 21 protocol pairs: 0 convergence points

What this means: The Purdue model is correct at the application layer. Individual PLCs, RTUs, and SCADA servers don't run multiple protocols. A Modbus PLC doesn't also speak S7COMM. A DNP3 RTU doesn't also run EtherNet/IP.

Consultant assessment result: PASS. Your devices are properly isolated at Layer 7.

Finding #2: Network-Level Isolation Is Broken

16 out of 679 subnets (2.4%) mix multiple protocols.

What this means: Same subnet = same switches = same VLANs = same Layer 2/3 attack surface.

Your Modbus PLCs and S7COMM PLCs are on different hosts (good). But they're on the same fucking network infrastructure (bad).

The Real Attack Surface

Consultants focus on preventing host-level protocol mixing:

Theoretical threat:
Attacker compromises Modbus PLC → pivots to S7COMM on same device

Reality: DOESN'T HAPPEN (0 multi-protocol hosts found)
        

The real threat is network-level protocol mixing:

Actual threat:
Attacker compromises Modbus PLC → ARP spoofs within subnet
→ intercepts/manipulates S7COMM traffic on same switch
→ pivots to S7 PLCs via Layer 2 attack (VLAN hopping, ARP poisoning)

Reality: HAPPENS (2.4% of sampled subnets mix protocols at Layer 2/3)
        

Why This Matters

Layer 2 Attack Vectors Nobody Talks About

1. ARP Spoofing Between Protocol Segments

# Attacker on Modbus PLC sends malicious ARP
arp -s [S7_PLC_IP] [ATTACKER_MAC]

# Now all S7COMM traffic routes through attacker
# Man-in-the-middle every PLC write command
        

Defense required: Dynamic ARP inspection, port security

Typical implementation: None (focus is on Layer 7 firewalls)

2. VLAN Hopping

# If Modbus and S7 are on "separate" VLANs but same switch:
# Double-tagging attack allows cross-VLAN traffic

# Attacker crafts packet with two VLAN tags
# Outer tag stripped by first switch, inner tag routes to S7 VLAN
        

Defense required: Proper VLAN pruning, separate physical switches

Typical implementation: "Separate VLANs" on same switch (vulnerable)

3. MAC Flooding

# Flood switch with fake MAC addresses
# Switch fails open, broadcasts all traffic

# Now attacker sees all protocols on subnet
        

Defense required: Port security, MAC address limiting

Typical implementation: None (assumed switches "just work")

What $50K Assessments Miss

Standard OT security assessment checklist:

Result: You paid $50K to prevent a threat that doesn't exist while ignoring the one that does.

The "Scan It and Fix It" Approach

Step 1: Scan Your Network (5 minutes)

# Use nmap to find all ICS protocols in your environment
nmap -p 102,502,20000,2404,44818,47808 YOUR_NETWORK/24

# Group results by subnet
# Do multiple protocols appear in same /24?
        

Step 2: Check Physical Topology (10 minutes)

# Ask your network team:
"Are Modbus and S7COMM on the same physical switch?"

If YES → Layer 2 attack surface exists
If NO → Verify with traceroute/MAC address tables
        

Step 3: Implement Actual Segmentation (varies)

If protocols share switches:

• Option A: Separate physical switches (gold standard)
• Option B: VLAN isolation + port security + ARP inspection (cheaper)
• Option C: Unidirectional gateways for monitoring-only traffic

Don't bother with:

• Application-layer protocol firewalls (solving problem that doesn't exist)
• "Advanced" DPI for protocol mixing detection (0% hit rate)
• $200K consultant-recommended "Purdue compliance" projects

Step 4: Validate (1 hour)

# From compromised Modbus PLC, attempt Layer 2 attacks:
arpspoof -i eth0 -t [S7_PLC] [DEFAULT_GATEWAY]

# If attack succeeds → segmentation failed
# If attack blocked → segmentation works
        

Immediate Actions (Monday Morning)

1. Audit Subnet-Level Protocol Mixing

# Create inventory of all ICS devices by protocol
# Group by /24 subnet
# Flag any subnet with >1 protocol type

# Expected finding: 2-3% of your subnets mix protocols
        

2. Check Switch Topology

• Do Modbus and S7COMM devices plug into the same switch?
• Are "separate VLANs" actually on separate physical infrastructure?
• Can you trace packets from Modbus segment to S7 segment via Layer 2?

3. Enable Basic Layer 2 Security

# On Cisco switches:
switchport port-security
switchport port-security maximum 2
switchport port-security violation restrict
switchport port-security mac-address sticky

# Prevents MAC flooding, limits ARP spoofing
        

4. Test VLAN Isolation

# From device on Modbus VLAN, attempt to reach S7 VLAN:
ping [S7_PLC_IP]

# If ping succeeds → VLAN isolation broken
# If ping fails → check if routing/firewall or true isolation
        

Long-Term Strategy: Reality-Based Defense

Stop Doing:

• Preventing host-level protocol mixing (doesn't happen)
• Layer 7 firewalls for protocol isolation (wrong layer)
• $200K "Purdue compliance" projects (solving theoretical problem)
• Trusting consultant assessments without data validation

Start Doing:

• Measuring actual protocol distribution across subnets
• Layer 2 security (port security, ARP inspection, VLAN pruning)
• Physical switch separation where protocols must not mix
• Reality-based threat modeling (what actually happens, not theory)

Methodology & Validation

Data source: Shodan API passive queries, July 2026

Protocols scanned: Modbus TCP (502), S7COMM (102), DNP3 (20000), IEC 60870-5-104 (2404), EtherNet/IP (44818), BACnet (47808), Profinet (34962)

Sample size: 700 unique IPs (100 per protocol), 679 /24 subnets

Total device population: 2,569,256 ICS devices

Validation:

• Host-level isolation: 21 protocol pair combinations checked, 0 overlaps found
• Network-level mixing: 16 subnets (2.4%) showed multi-protocol presence
• Consistent with previous 500-IP sample (0% host mixing, ~2% subnet mixing)

Limitations: Shodan Dev tier returns page 1 results only. Subnet analysis based on sample, not exhaustive. Actual facility risk depends on physical topology not visible in passive scans.

The Bottom Line

The Purdue model is half right:

Your next security assessment should measure reality, not theoretical frameworks.

Scan your network. Find where protocols actually mix. Fix the real problem.

And stop paying consultants to prevent threats that don't exist.

Disclaimer: All analysis defensive. No attribution. No specific targets identified. Pattern analysis based on publicly accessible data sources. For defensive use by OT security professionals.

← Back to Control Systems Security · Previous Dispatch: World War OT