Challenge 8: Implement jump host architecture¶

The problem: Administrative access comes from anywhere on the corporate network. Compromised workstation = compromised OT. No centralised access control or monitoring.

Your goal: Deploy jump host (bastion) architecture. All administrative OT access flows through one controlled point.

What you can do¶

Design the architecture:

Before:
Corporate Network ──→ Turbine PLC
                  ├─→ Reactor PLC
                  ├─→ SCADA
                  └─→ Safety PLC

After:
Corporate Network ──→ Jump Host ──→ Turbine PLC
                                 ├─→ Reactor PLC
                                 ├─→ SCADA
                                 └─→ Safety PLC

Direct access: BLOCKED by firewall

Deploy jump host:

• Hardened Linux server or Windows bastion

• Minimal software installed

• Strong authentication (certificates or MFA)

• Session recording enabled

• Logging all access

Configure firewall rules:

# Block direct access from corporate to OT
iptables -A FORWARD -s 192.168.1.0/24 -d 192.168.100.0/24 -j DROP

# Allow jump host to OT
iptables -A FORWARD -s 192.168.1.50 -d 192.168.100.0/24 -j ACCEPT

# Allow corporate to jump host
iptables -A FORWARD -s 192.168.1.0/24 -d 192.168.1.50 -j ACCEPT

Integrate authentication:

# Jump host authenticates using AuthenticationManager
# Records all sessions
# Enforces authorisation before allowing connections

Create break-glass procedure:

• What happens when jump host fails?

• Emergency bypass procedure

• Documented, audited, infrequent

• Temporary firewall rule modification

• Automatic revert after emergency

Test it¶

Access control testing:

# Try direct access to PLC - should be blocked
telnet 192.168.100.10 502

# Try via jump host - should succeed
ssh jump-host
telnet 192.168.100.10 502

Bypass testing:

• Can you bypass jump host?

• Spoof source IP?

• Use different protocol?

• Find misconfigured firewall rule?

Failure scenario testing:

• Stop jump host service

• Can you still access OT? (should not, except emergency)

• Activate break-glass procedure

• Verify emergency access works

• Verify automatic revert

Usability testing:

• How does this affect operator workflow?

• How long does it take to connect?

• Is it practical for frequent access?

• Do people try to work around it?

What you can learn¶

Single point of failure:

• Jump host down = no administrative access

• Need high availability (redundant jump hosts)

• Need emergency procedures

• But emergency procedures can be abused

Centralised control benefits:

• All access logged in one place

• Consistent authentication and authorisation

• Session recording for audit

• Easier to monitor for abuse

Usability impact:

• Extra hop for every connection

• More complex for users

• Resistance from operators

• Training required

Break-glass procedures:

• Need emergency access mechanism

• But emergency access can be abused

• Need monitoring and audit

• Difficult balance

Where to start¶

# This challenge requires architectural planning
# No single component to use - you're building infrastructure

# Consider jump host software options:
# - SSH bastion with session recording
# - RDP gateway
# - PAM solution (Privileged Access Management)

# Plan firewall rules
# Map current access patterns
# Design new access patterns through jump host
# Test in lab before production

# Read about jump host patterns
# Search: "bastion host OT" "jump server ICS"

Going deeper¶

Questions to explore:

• How do you make jump host highly available?

• What’s the monitoring strategy for jump host?

• How do you handle vendor remote access?

• What about third-party vendors who need temporary access?

Advanced options:

• Deploy redundant jump hosts for HA

• Implement PAM solution with full session recording

• Deploy jump host in DMZ for vendor access

• Implement just-in-time access (request approval, get temporary access)

• Deploy different jump hosts for different privilege levels

• Implement geofencing (only allow access from specific locations)