> For the complete documentation index, see [llms.txt](https://support.onlogic.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://support.onlogic.com/support-articles/security-guidelines-iec-62443-4-1/sg-2-defense-in-depth-measures-expected-in-the-environment.md). # 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): 1. Query the current runtime status of IP forwarding via sysctl. Bash: ``` sysctl net.ipv4.ip_forward ``` 3. If the output returns 1, immediately inject a persistent configuration override block to disable it. Bash: ``` echo "net.ipv4.ip_forward = 0" | sudo tee -a /etc/sysctl.d/99-sg2-hardening.conf sudo sysctl -p /etc/sysctl.d/99-sg2-hardening.conf ``` For Windows IoT Enterprise Environments: 1. Enforce complete deactivation of the default Routing and Remote Access Service (RRAS) via an administrative PowerShell terminal. PowerShell: ``` Get-Service -Name RemoteAccess | Stop-Service -PassThru | Set-Service -StartupType Disabled ``` 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: ``` # Establish global default drop postures sudo ufw default deny incoming sudo ufw default deny forwarding # Enforce rules on LAN 1 (OT - eth0) sudo ufw allow in on eth0 to any port 22 proto tcp comment 'Engineering Access Only' sudo ufw allow in on eth0 to any port 4840 proto tcp comment 'OPC UA Local Polling' # Enforce rules on LAN 2 (IT/Cloud - eth1) sudo ufw allow out on eth1 to any port 8883 proto tcp comment 'Outbound TLS MQTT' sudo ufw allow out on eth1 to any port 443 proto tcp comment 'Outbound HTTPS Telemetry' # Instantiate security posture sudo ufw enable ``` 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: 1. 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. 2. 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 StepExpected Verification StandardStatus Verification
Boundary Isolation TestICMP echo requests (pings) dispatched from the IT network targeting the LAN 1 (OT IP) interface must timeout completely.[ Pass / Fail ]
Hop / Trace VerificationTraceroute 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 AuditingExternal network vulnerability scans (e.g., Nmap) executed against LAN 2 must report all inbound ingress ports closed or stealth-filtered.[ Pass / Fail ]
Application Binding ValidationInspect active system sockets (ss -tlnp) to verify running middleware daemons bind exclusively to localized loopback or the specific LAN 1 interface IP.[ Pass / Fail ]