OT/IT Convergence Security

Operational Technology (OT) refers to hardware and software that monitors and controls physical processes, devices, and infrastructure. Common OT systems include Supervisory Control and Data Acquisition (SCADA) systems, Distributed Control Systems (DCS), Programmable Logic Controllers (PLCs), and Remote Terminal Units (RTUs). These systems manage everything from electrical grids and water treatment plants to manufacturing assembly lines and pipeline valves. Information Technology (IT), by contrast, manages data-centric systems like servers, databases, email, and enterprise resource planning (ERP) software.

Traditionally, OT networks were physically air-gapped from IT networks—no connectivity at all. This isolation provided inherent security: an attacker compromising the corporate email system could not reach the PLC controlling a turbine. However, business demands for real-time data, remote monitoring, predictive maintenance, and integration with enterprise systems have driven convergence. Today, most OT environments have at least some connectivity to IT networks, often through a demilitarized zone (DMZ) or direct connections.

The convergence typically occurs at multiple layers:

Relevant standards: - IEC 62443: International standard for industrial communication network security. Defines security levels (SL 1-4) and zones/conduits. - NIST SP 800-82: Guide to Industrial Control System (ICS) security. - ISA/IEC 62443: Defines roles, risk assessment, and security requirements for IACS (Industrial Automation and Control Systems).

Attackers leverage the trust relationship between IT and OT. The most infamous example is the 2015 Ukraine power grid attack (CVE-2015-5374, BlackEnergy malware). The attack chain:

More recently, TRITON malware (CVE-2017-17674) targeted Schneider Electric Triconex safety controllers by exploiting a programming error in the firmware. The malware was delivered through the IT network and leveraged a zero-day to reprogram safety instrumented systems, potentially causing physical damage.

Common attack vectors: - Ransomware: Encrypts Windows-based HMIs or historian servers, halting production. - Protocol exploitation: Modbus lacks authentication; an attacker can send forged read/write commands to PLCs. - Remote access abuse: Weak credentials on VPNs or jump boxes allow unauthorized control. - Supply chain attacks: Compromised software updates for OT equipment.

Defense-in-depth for OT/IT convergence includes:

# Example iptables rule for OT DMZ
iptables -A FORWARD -i eth0 -o eth1 -p tcp --dport 502 -s 10.0.1.10 -d 192.168.100.0/24 -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -j DROP

This rule allows only the jump box (10.0.1.10) to initiate Modbus connections to the OT network (192.168.100.0/24) and blocks all return traffic from OT to IT, enforcing unidirectional data flow.

OT/IT convergence is inevitable but introduces risks that can lead to physical damage. The Security+ exam expects you to understand the unique security properties of OT (safety, availability, real-time) and the controls (segmentation, unidirectional gateways, jump boxes) that protect converged environments. Focus on the Purdue Model, the differences between IT and OT priorities, and the specific protocols and attack vectors.

Scenario 1: Water Treatment Plant Ransomware

A mid-sized water utility integrated its SCADA system with the corporate network for remote monitoring. An employee clicked a phishing email containing LockBit ransomware. The ransomware encrypted the corporate file server and spread to a shared drive that also mapped to the SCADA historian server. The historian, running Windows, became encrypted. Operators lost access to historical data, but the PLCs continued running autonomously. The SOC detected the ransomware via endpoint alerts on the corporate side. The correct response: immediately disconnect the OT network from IT (pull the network cable between the DMZ and OT). Then restore the historian from offline backups. The common mistake: attempting to remove the ransomware while leaving the network bridge intact, allowing the ransomware to spread to HMIs. The analyst should have identified that the historian was in the DMZ and acted as a bridge.

Scenario 2: Unauthorized Modbus Write Command

A manufacturing plant uses Modbus TCP to control conveyor belts. The SOC's OT monitoring tool (Nozomi) alerted on a Modbus write command to a PLC from an IP address that was not on the authorized list. The command set a motor speed to maximum. The analyst investigated: the IP belonged to a vendor laptop that was connected to the OT switch for maintenance but had been left connected after the vendor left. The correct response: immediately block that IP at the OT firewall, physically disconnect the laptop, and verify the PLC state. Then review logs for any other unauthorized commands. The common mistake: assuming the vendor's laptop was trusted because it was used for legitimate maintenance. The analyst should enforce a policy that all temporary connections require a change request and are monitored.

Scenario 3: TRITON Malware in a Petrochemical Facility

A petrochemical company had a converged network with a jump box for remote access. Attackers used spear-phishing to gain access to the IT network, then moved laterally to the jump box using stolen VPN credentials. From the jump box, they scanned the OT network and discovered a Triconex safety controller. They uploaded a malicious firmware update (TRITON) that modified the safety logic, intending to cause a catastrophic failure. The SOC missed the initial compromise because IT and OT monitoring were separate. The correct response: after discovery, the facility was shut down safely, and the safety controller was reflashed with known-good firmware. The common mistake: not correlating IT alerts (unusual VPN logins) with OT alerts (firmware change). The lesson: integrate IT and OT SIEM feeds and monitor for cross-domain indicators.