IoT and OT Security: Protecting Industrial and Connected Device Environments

The convergence of Information Technology (IT) and Operational Technology (OT) has fundamentally changed the industrial security landscape. Systems that once operated in isolation — programmable logic controllers (PLCs) governing water treatment plants, SCADA systems managing electrical substations, building automation controllers managing HVAC across midtown Manhattan skyscrapers — are now interconnected with corporate networks and, increasingly, the public internet. The attack surface implications are severe and underappreciated by most security programs.

Understanding IT/OT Convergence Risks

Traditional OT environments were designed for availability and physical safety above all else. Security was achieved through obscurity and air gaps. A Modbus RTU device communicating over RS-485 serial cable in 1990 was not an attack target because it was physically inaccessible. The same protocol encapsulated in TCP/IP on a corporate network segment in 2025 is a different matter entirely.

The core tension in OT security is that the CIA triad priority order is inverted relative to IT. In information security, Confidentiality is primary. In operational technology, Availability is paramount — a steel mill that goes dark costs tens of thousands of dollars per minute. This means OT operators historically rejected patching cycles, authentication requirements, and encrypted communications because they introduced availability risk. The result: decades-old vulnerabilities baked into production systems with operational lifespans that, per NIST SP 800-82 Rev. 3, run 10-15 years for components and can exceed 20 years at the system level (versus 3-5 years for typical IT).

For NYC-specific environments, the OT attack surface is broad: building automation systems (BAS) controlling HVAC, access control, and elevators in Class A office towers; utilities infrastructure serving the five boroughs; transportation control systems; and water/wastewater treatment facilities operated by DEP. All of these environments increasingly rely on internet-connected HMIs and remote access portals.

The Purdue Model for ICS Security

The Purdue Enterprise Reference Architecture (PERA) — often called the Purdue Model — provides the foundational framework for understanding ICS/SCADA network segmentation. It defines six hierarchical levels:

• Level 0 — Physical Process: The actual physical equipment — pumps, valves, motors, sensors. This is the physical world being controlled.
• Level 1 — Basic Control: PLCs, RTUs, and DCS controllers that read sensor data and execute control logic. Devices at this level typically run proprietary real-time operating systems with no authentication and minimal logging.
• Level 2 — Area Supervisory Control: HMIs (Human-Machine Interfaces) and supervisory control servers. This is where operators monitor and command Level 1 devices. Windows-based systems running decades-old SCADA software are common here.
• Level 3 — Site Operations: Production control, data historians (OSIsoft PI is ubiquitous), batch management, and site-level reporting. This level often bridges to corporate IT.
• Level 3.5 — Industrial DMZ (iDMZ): A critical security boundary that should exist between OT and IT. Historian replicas, remote access jump servers, and patch management systems reside here. In practice, this layer is missing in most environments.
• Level 4 — Site Business Planning: Corporate IT — ERP systems, email, file shares. This is traditional IT territory.
• Level 5 — Enterprise Network: The corporate WAN/internet zone.

The NIST SP 800-82 Guide to Industrial Control Systems Security formalizes security controls for each Purdue level. The document is technically dense but essential reading for anyone responsible for an ICS environment.

Common OT Vulnerabilities

ICS-CERT advisories from 2023-2025 consistently surface the same vulnerability classes:

• Default credentials: PLCs and HMIs shipped with known default usernames and passwords that operators never change. Siemens S7 devices, Schneider Electric Modicon PLCs, and Allen-Bradley Logix controllers have all shipped with default credentials. Shodan and Censys routinely surface these devices on the public internet with no authentication.
• Unpatched systems: A Windows XP workstation running a legacy SCADA HMI is not unusual. Patching requires vendor qualification, scheduled downtime, and regression testing — operational overhead that leads to indefinite deferral. The Rockwell Automation Logix vulnerabilities disclosed in March 2022 — CVE-2022-1161 (a CVSS 9.8 controller-firmware flaw in ControlLogix, CompactLogix and GuardLogix systems, CISA advisory ICSA-22-090-05) and CVE-2022-1159 (a flaw in the Studio 5000 Logix Designer engineering software, CISA advisory ICSA-22-090-07) — illustrate how OT patching lags: applying firmware updates requires vendor qualification, scheduled downtime, and regression testing, so remediation is often deferred long after an advisory is published.
• Direct internet exposure: Shodan searches for common industrial protocols reveal thousands of directly internet-accessible ICS devices. BACnet (UDP/47808), Modbus TCP (TCP/502), DNP3 (TCP/20000), and EtherNet/IP (TCP/44818) all appear in Shodan results regularly. These protocols implement no authentication at the protocol layer.
• Weak or absent network segmentation: The iDMZ at Purdue Level 3.5 is missing in most environments. Engineers access Level 1/2 OT systems directly from corporate laptops. This means a phishing email that compromises an engineer workstation is two hops from the PLC network.

Landmark OT Attacks

The threat is not theoretical. Three attacks define the current threat landscape:

TRITON/TRISIS (2017, Saudi Arabia): Malware targeting Schneider Electric Triconex Safety Instrumented Systems (SIS). The SIS is the last line of defense preventing catastrophic physical failure — if a petrochemical process goes out of bounds, the SIS triggers an emergency shutdown. TRITON attempted to disable SIS logic, which would have allowed an explosive or toxic release. The attackers had deep knowledge of proprietary SIS protocols and had been inside the OT network for months before discovery.

Industroyer/Crashoverride (2016, Ukraine): Malware used to cause the second major power outage in Ukraine, targeting transmission substations. Industroyer could natively speak IEC 104, IEC 61850, IEC 101, and DNP3 — industrial protocols used for substation automation. It directly commanded breakers to open, causing a 75-minute outage in Kyiv.

Oldsmar Water Treatment (2021, Florida): An attacker accessed the Oldsmar water treatment plant HMI via TeamViewer remote access, raising the sodium hydroxide (lye) dosing from its normal ~100 ppm to 11,100 ppm — a more than 100-fold increase. An operator caught the change manually. The facility used a shared TeamViewer account with no MFA and a direct internet connection from the OT workstation.

OT Network Monitoring and Detection

Passive monitoring is the primary detection approach for OT environments because active scanning can cause availability disruptions on sensitive PLCs. Three purpose-built OT monitoring platforms have emerged as market leaders:

• Claroty Platform: Passive asset discovery using protocol-aware DPI for 450+ industrial protocols. Establishes baseline communication patterns and alerts on deviations. Integrates with Purdue-level network taps.
• Dragos Platform: Developed by former NSA and ICS-CERT practitioners, Dragos combines passive monitoring with threat intelligence specifically developed for ICS threat groups. Their threat intelligence tracks 26 ICS/OT threat groups — 23+ named publicly — including VOLTZITE, ELECTRUM, and CHERNOVITE.
• Nozomi Networks: Combines passive monitoring with optional active querying for environments where availability risk is acceptable. Strong integration with Purdue Level 3 historians and SIEM platforms.

If you are responsible for OT security and need to assess your current posture, Fortress MSSP conducts OT/ICS security assessments using passive methodologies that do not risk production availability. Contact us to discuss your environment.

IT/OT Segmentation Implementation

The most impactful single control for OT security is proper network segmentation following the Purdue model. Practical steps:

• Implement a dedicated industrial DMZ (iDMZ) between Purdue Level 3 and Level 4. All data flows between OT and IT must traverse this DMZ. No direct connections.
• Deploy unidirectional security gateways (data diodes) for historian replication. Waterfall Security and Owl Cyber Defense produce hardware-enforced unidirectional gateways that physically prevent inbound traffic from IT to OT.
• Eliminate direct remote access to OT systems. Implement a dedicated jump server in the iDMZ with session recording, MFA, and privileged access management (PAM).
• Remove all OT systems from internet-accessible ranges. No PLC, HMI, or OT switch should have a default route to the internet.
• Conduct quarterly reviews of firewall rules between OT zones. Rule bloat creates pathways. Every OT firewall rule should have a documented business justification and owner.