SG-2: Defense in Depth Measures Expected in the Environment
Scope & Architectural Intent
1.1 Purpose and Boundary Control
Industrial edge gateways operate within complex, multi-zoned operational environments. To preserve system security integrity, the device must not function as an unrestricted bridge between sensitive control networks and upper-level corporate or cloud infrastructure. This technical reference defines the implementation rules for utilizing multiple independent physical network interfaces (LAN ports) to map secure boundaries aligned with the Purdue Reference Model.
1.2 Residual Risk and Boundaries of Component Responsibility
While this gateway provides physical and logical network interface isolation (conduits), it does not natively inspect application-layer payloads for malicious command anomalies (e.g., deep-packet inspection of industrial protocols). The asset owner and system integrator must ensure that malicious actors cannot compromise the Level 1/2 network via secondary, unmonitored pathways, as this gateway assumes all traffic ingressing on its designated control interface originates from a verified, trusted local zone.
Environmental & Physical Security Assumptions
Network Segment Architecture (Zones and Conduits)
The gateway acts as an application-layer data proxy (Conduit), strictly dropping raw routed packets between interfaces while facilitating secure data transition between boundaries.
[ Level 4: Corporate Network / Cloud ]
│
▼ (WAN/Outbound Traffic Only)
┌──────────────────────┐
│ LAN 2 (eth1 / enp3s0)
│ │
│ OnLogic Gateway │ ◄─── IP Forwarding: DISABLED
│ │ Local Firewall: ENABLED
│ LAN 1 (eth0 / enp2s0)
└──────────────────────┘
▲ (Ingress Data / Local Access Only)
│
[ Level 2: Industrial Control Network ]
(PLCs, HMIs, SCADA)
2.2 Physical Security Environmental Assumptions
Target Security Levels (SL) cannot be achieved solely via network-layer software constraints. This deployment guidance assumes the following physical defense-in-depth controls are enforced by the asset owner at the installation site:
Enclosure Restrictions: The gateway must be permanently housed inside a physically locked cabinet, panel, or server rack accessible exclusively to authorized Level 2/3 engineering and maintenance personnel.
Hardware Port Protection: All unused network ports and USB interfaces must be physically blocked using specialized port locks, or explicitly deactivated within the system BIOS to mitigate unauthorized local intrusion into the network conduits.
Host Hardening & Logical Configuration
3.1 Disabling Kernel Packet Forwarding
Operating systems may natively attempt to route traffic between active network interfaces. For compliance with SG-2 baseline requirements, packet forwarding must be explicitly and permanently disabled to ensure the gateway cannot act as an unauthorized router.
For Linux Subsystems (Ubuntu / Debian / Rocky Linux):
Query the current runtime status of IP forwarding via sysctl. Bash:
If the output returns 1, immediately inject a persistent configuration override block to disable it. Bash:
For Windows IoT Enterprise Environments:
Enforce complete deactivation of the default Routing and Remote Access Service (RRAS) via an administrative PowerShell terminal. PowerShell:
3.2 IP Addressing and Gateway Paradigms
Improper default gateway allocation on internal control networks exposes local asset topologies during upstream network discovery routines. Engineers must enforce the following strict interface properties:
LAN 1 (OT Interface): Statically configured network address. Do not define a default gateway on this interface configuration. Omitting an external gateway restricts outbound data transmission strictly to the local physical subnet segment.
LAN 2 (IT/Cloud Interface): Configured via Static IP or trusted enterprise DHCP, pointing explicitly to the designated corporate perimeter security firewall or IDMZ gateway.
Host-Based Firewall Enforcement
4.1 Stateful Access Control Lists (ACLs)
A local stateful packet inspection firewall must restrict traffic explicitly to the allowed operational boundaries of the conduit interfaces. Below is an administrative shell script utilizing ufw (Uncomplicated Firewall) to implement an SG-2 compliant posture. Bash:
4.2 Local Service Binding
Software services operating on the gateway (e.g., Ignition Edge, Node-RED, local MQTT brokers) must be explicitly bound to their designated interface targets. Industrial drivers pulling data must target specific control IPs reachable only via LAN 1. Administrative web panels or local management consoles must bind directly to 127.0.0.1 (loopback) or the internal engineering interface—never allow management daemons to listen globally on 0.0.0.0.
4.3 Policy for Remote Maintenance & Support Access
Temporary remote maintenance access to the Level 1/2 automation layer through the gateway is disabled by default. If a remote support session is required under IEC 62443-2-4 guidelines:
Connections must use an on-demand, encrypted VPN tunnel initiated outbound from inside the plant floor, rather than accepting unsolicited inbound requests from the corporate WAN.
Inbound firewall management rules must be programmatically or manually revoked immediately upon the formal conclusion of the authorized maintenance window.
Commissioning Verification Matrix
The field deployment engineer or certified system integration provider must validate this security baseline utilizing the verification checklist below before formal site handover.
Validation Audit Step
Expected Verification Standard
Status Verification
Boundary Isolation Test
ICMP echo requests (pings) dispatched from the IT network targeting the LAN 1 (OT IP) interface must timeout completely.
[ Pass / Fail ]
Hop / Trace Verification
Traceroute routines initiated from Level 4 toward Level 1 assets through the gateway must terminate entirely at the external LAN 2 interface.
[ Pass / Fail ]
Interface Inbound Auditing
External network vulnerability scans (e.g., Nmap) executed against LAN 2 must report all inbound ingress ports closed or stealth-filtered.
[ Pass / Fail ]
Application Binding Validation
Inspect active system sockets (ss -tlnp) to verify running middleware daemons bind exclusively to localized loopback or the specific LAN 1 interface IP.
[ Pass / Fail ]
Last updated