Guidelines (based on Foundational Requirements (FRs))

1. Identification and Authentication Control (FR-1) (SG-6)

   1. This will ensure that only authorized entities can interact with the system. For IPC context this requirement often starts at the firmware level. OnLogic’s BIOS does allow the set up for supervisors and user passwords.

      1. For authentication strength policies should enforce a minimum password character limit and should be replaced at X number of days

         1. Password complexity can be any number of these combinations: lowercase, uppercase, numbers, special symbols, and making the password itself case sensitive. (which means if you have a mix of uppercase and lowercase the prospective characters need the proper case in order to work)

         2. Multi-Factor Authentication (MFA) or 2-Factor Authentication (2FA) are optional if you want a more secure authentication method. They have a wide selection of implementation methods. Although MFA may be dependent on the operating system.

            1. They require the user to enter 2 or more verification methods to gain access to an account/system/application. It can be another password, a keypad pin, an answer to a security question, a verification code (randomly generated), a hardware key (yubikey), or a biometric value

   2. The system should have and support unique identifiers(UID) and accounts for all administrative accounts whether that's in the UEFI or OS. They may look like a readable alphanumeric username or a machine-readable system string

      1. In the event of an account lockout make sure there is a way to

         1. Verify the user is in fact the user (ie. verify employee number, verify with personal identifiers, etc)
   3. The system should use a Trusted Platform Module (TPM 2.0) or Intel Trust Technology (PTT) for secure storage of cryptographic keys

2. Use Control (UC) (FR-2) (SG-6

   1. Least Privilege - this policy enforces the least privilege common practice, which in turn only allows authenticated users to only perform actions or tasks necessary and appropriate for their role. (same can be applied for access levels) This can also mean that restrictions are in place for BIOS settings to prevent any unauthorized changes to the boot order

      1. When setting up accounts make sure you always start with the minimum amount of privileges that users may need and make adjustments as needed. Good to also note that only admins should have the capability to do so

Introduction and Purpose

This technical manual provides explicit, step-by-step instructions for reducing the attack surface of Industrial PCs (IPCs) in accordance with the IEC 62443-4-1 SG-3 (Security Hardening Guidelines) requirement. Initial out-of-the-box factory configurations are often optimized for ease of use rather than security, frequently leaving default credentials, open ports, and unmanaged services active. Implementing this guide ensures compliance with IACS (Industrial Automation and Control Systems) security objectives before connecting the asset to the operational network.

Hardening Framework Overview

The following table outlines the core hardening categories, specific technical requirements, and underlying security objectives enforced during this out-of-the-box setup procedure:

3.1 Physical Security & BIOS/UEFI Configuration (Pre-Boot Environment)

Physical modifications and low-level firmware configuration must be completed prior to operating system installation or network initialization.

1. Establish Firmware Security: Power on the IPC and enter the BIOS/UEFI setup utility (typically via F2, F12, or Del keys). Navigate to the Security tab and configure a strong supervisor/administrative password to restrict unauthorized modification of boot parameters.

2. Disable External Boot Vectors: Modify the Boot Priority order to set the internal primary drive (SSD/HDD) as the sole boot device. Explicitly disable booting from USB interfaces, optical drives, and network-based Preboot Execution Environment (PXE).

3. Lock Inactive Physical Interfaces: Physically seal or disable unused external ports (e.g., USB, Serial, extra RJ45 ports) using physical port locks or by disabling the controller directly within the BIOS peripherals menu.

3.2 Integrity Protection

Integrity protection ensures that the operating system kernel and boot loaders have not been modified by malicious software or rootkits.

• Enable UEFI Secure Boot: Inside the BIOS/UEFI interface, ensure the Boot Mode is explicitly set to Native UEFI (disable Legacy/CSM support). Locate and enable "Secure Boot" to enforce cryptographic signature verification on all loaded binaries.

• Activate Trusted Platform Module (TPM): Verify that TPM 2.0 (or equivalent hardware security chip) is enabled and activated in the firmware. This facilitates measured boot operations and anchors system encryption keys into hardware.

• Enable Storage Volume Encryption: Configure full disk encryption (such as Windows BitLocker or Linux LUKS) utilizing the TPM chip to automatically protect data at rest against physical drive theft.

3.3 Identity Management (OS Initialization)

During the initial boot of the operating system, default access structures must be systematically dismantled.

1. Purge Default Accounts: Identify and eliminate pre-configured OEM or OS accounts (e.g., "admin", "user", "root"). Under no circumstances should default factory usernames remain active.

2. Provision Unique Accounts: Establish role-based accounts dedicated to individual personnel. Create separate non-administrative user accounts for operational routines and distinct administrator accounts reserved strictly for maintenance.

3. Enforce Complex Password Policies: Apply local security policies mandating a minimum length of 14 characters, combining uppercase, lowercase, numeric, and special characters. Enforce account lockout thresholds (e.g., 3 failed attempts triggers a 15-minute lock).

3.4 Service Minimization

Unnecessary processes running in the background present a severe, unmonitored risk profile.

• Identify Active Services: Execute a scan or review running processes to evaluate legacy protocols (e.g., Telnet, FTP, HTTP, SMBv1).

• Disable Protocols and Port Listeners: Explicitly turn off or uninstall unneeded daemon architectures. For example, disable legacy clear-text administration protocols (Telnet/HTTP) and enforce encrypted variants (SSH/HTTPS) exclusively if remote management is justified by operational requirements.

• Remove Superfluous Software: Uninstall development utilities, games, browsers, and default trial software packages shipped with the stock operating system image.

3.5 Network Security (Host-Based Firewall)

The system must be isolated from the broader network environment by restricting boundary data transmissions.

1. Enforce a Deny-All Default Policy: Access the local host-based firewall settings (e.g., Windows Defender Firewall or iptables/ufw on Linux). Set the global behavior for all incoming connections to "Block/Deny All" across all network profiles (Domain, Private, Public).

2. Define Explicit Inbound Exceptions: Create surgical firewall rules allowing incoming traffic only on mandatory operational ports (e.g., specific industrial protocol ports such as Modbus TCP, OPC UA, or Ethernet/IP) and restrict the allowed source scopes to known, trusted engineering workstations or PLCs.

3. Restrict Outbound Traffic: Where feasible, limit outbound connectivity from the IPC to designated logging servers (Syslog) or local patch repositories, blocking general outbound internet access completely.

3.6 Audit and Event Logging (System Accountability)

To support system accountability and satisfy diagnostic requirements, robust trace logging must be configured locally and prepared for transport.

1. Configure Local Audit Policies: Enable advanced auditing within local system security policies. Ensure active monitoring and logging are configured for the following critical event classes:

   1. Logon/Logoff events (both successful and failed attempts)

   2. Privilege use and administrative elevation

3.7 Patch Management Lifecycle (Offline Deployment Prep)

Maintaining security status requires systematic operating system and software maintenance processes, even in highly segregated (air-gapped) environments.

1. Define Baseline Target Version: Prior to deployment, catalog and verify the precise OS patch baseline version approved by the IACS vendor/integrator.

2. Configure Offline Update Channels: Disable default automated internet search routes for software updates. Configure the local updater agent to pull approved binaries only from an on-premise local management node (e.g., WSUS or local package mirror) or secure USB "transient" deployment procedures.

3. Establish Update Windows: Program local update installation policies to restrict automatic restarts of critical system nodes. Updates must only install manually during controlled engineering maintenance windows.

• Firm password prompt appears when attempting to access BIOS/UEFI.

• System fails to boot when an external bootable USB drive is inserted.

• Secure Boot status is verified as "Active" or "Enabled" within the OS environment.

Overview

SG-4 guidelines for IPCs are primarily focused on the sanitization of storage media (SSDs and NVMe drives). The framework is based on NIST SP 800-88, which defines three levels of sanitization: Clear, Purge, and Destroy. The choice of method depends on the sensitivity of the data and whether the hardware will be reused, sold, or destroyed. Below is a detailed guide for its secure retirement to prevent the leakage of sensitive data

This method is not appropriate for hard copy under any conditions but may be appropriate for ISM (information storage media). This method applies logical techniques to sanitize data in all user-addressable storage locations of an ISM for protection against simple, non-invasive data recovery techniques using the same interface that is available to the user host interface. These standard techniques generally do not affect the ISM's usability; it involves using software or hardware to overwrite an ISM's user-addressable storage and metadata with non-sensitive data via standard read/write commands. Historically, hard drives were erased using multiple overwrite passes (e.g., DoD 5220.22-M5) with various binary patterns. These methods are ineffective for certain ISM, such as SSDs with overprovisioning; more secure methods like purge or destroy should be utilized. Overwriting is unsuitable for non-rewriteable or inoperable ISM, as it cannot reach all sensitive data areas. ISM type and size further limit its effectiveness. Specifically, flash memory-based devices use spare cells and wear leveling, making it impossible to address all storage areas through standard read/write interfaces. Continuing use of magnetic ISM overwrite methods on newer media, like flash memory, risks unintentional data disclosure. The ISM may support dedicated sanitize commands that address all storage areas more effectively. Clear sanitization techniques vary for devices. Always consult the manufacturer’s documentation for the most effective proprietary tool for your specific device.

• Overwriting. Typically done through the standard read and write commands to the storage device, such as by rewriting with a new value (either random patterns or zeros’) or (if available) using a menu option to reset the device to the factory state (when & where rewriting is not supported).

  • If compatible with your storage media device. Some devices may come with manufacturer tools, in those cases their tools are best to use for clear sanitization. They work by sending and executing secure erase commands directly to the drive’s firmware, removing the stress of overwriting manually.

    • Manufacturer resets without rewriting still qualify as clear sanitization, provided the standard user interface prevents original data retrieval.

This method is not appropriate for hard copy under any conditions but may be appropriate for some ISM. Purge sanitization employs physical or logical methods to make data recovery infeasible against state of the art laboratory techniques while keeping the ISM potentially reusable. This method is preferred over clear sanitization whenever possible.

Logical purge techniques vary by ISM type; acceptable methods are overwrite, block erase, or cryptographic erase using dedicated, standardized device sanitize commands that bypass typical command abstractions, increasing the chance of keeping the device usable. Of the logical purge sanitization techniques, cryptographic erase is noteworthy in its ability to rapidly sanitize target data. However, the effective use of cryptographic erase depends on the pedigree of cryptographic capabilities and meeting certain pre-conditions.

For an ISM that takes the form of logical/virtual storage (e.g., cloud storage), cryptographic erase may be the only viable purge sanitization option. Typically, the underlying physical ISM is abstracted so that the data owner has no direct access to the physical ISM, and sanitizing them is not possible. Organizations should clearly understand their purge sanitization technique options and the effectiveness of the technique prior to storing sensitive data on such ISM.

Physical purge sanitization techniques historically included degaussing for magnetic tapes, magnetic removable disks, and magnetic hard disk drives. Degaussing should not be used for non-magnetic ISM (e.g., flash storage, such as SSDs). The use of degaussing as a purge sanitization technique has become more complicated as ISM have evolved to use hybrids of magnetic and non-magnetic storage as well as variations of magnetic recording technologies with higher coercivity (i.e., magnetic force). As a result, many existing degaussers do not have sufficient force to effectively degauss such ISM. Additionally, degaussing can make some types of ISM unusable, potentially making them inoperable (if the servo tracks are damaged), but fail to sanitize the target data. At the time of this writing, degaussing is not considered an approved destroy sanitization technique, but IEEE 2883 and/or NSA/CSS Policy Manual 9-12 should be consulted for further clarification.

Other physical purge sanitization techniques can also exist. The above clear overwrite methods can be reused here as well.

• Overwriting. Typically done through the standard read and write commands to the storage device, such as by rewriting with a new value (either random patterns or zeros’) or (if available) using a menu option to reset the device to the factory state (when & where rewriting is not supported).

  • If compatible with your storage media device. Some devices may come with manufacturer tools, in those cases their tools are best to use for clear sanitization. They work by sending and executing secure erase commands directly to the drive’s firmware, removing the stress of overwriting manually.

    • Manufacturer resets without rewriting still qualify as clear sanitization, provided the standard user interface prevents original data retrieval.

This method is appropriate for all hard copies and most ISM (not including logical or virtual storage). Sanitization techniques make target data recovery infeasible using ‘state of the art laboratory techniques and results in the inability to use the ISM for storage of the data. With the many different types of this technique the ISM is not “the ISM is not considered destroyed unless target data access or recovery is infeasible using state-of-the-art laboratory techniques”. This MAY be the only option when the ISM fails or is obsolete and clear and purge techniques cannot be applied effectively.

Bending, cutting, or other produces (ie. shooting or drilling) may only partly damage the ISM, leaving portions of it still accessible via “state-of-the-art laboratory techniques”. As the density of data and the hardness of the internal components materials increase on an ISM, certain techniques can become ineffective. Note: Pulverize and shred techniques for ISM should be avoided for anything other than the lowest security categories of data.

Below are some of the more common destruction methods for media:

• Disintegrate. Process that destroys the media by breaking, separating, or decomposing media into its constituent elements, parts, or small particles such that there is nothing or very little of it that is recognizable after the process.

  • For example, dissolving with acid will disintegrate the product or at the very least destroy the outer layer and make content very difficult to impossible to recover.

• Incinerate. Process that destroys the media by burning it to ash.

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.

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:

1. If the output returns 1, immediately inject a persistent configuration override block to disable it. Bash:

For Windows IoT Enterprise Environments:

1. 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.

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:

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.

The field deployment engineer or certified system integration provider must validate this security baseline utilizing the verification checklist below before formal site handover.