Author: Victor Strang, GICSP — Industrial Cybersecurity Engineer. 15 years of experience in operational technology security across energy, utilities, and manufacturing. Specializes in ICS/SCADA risk assessments, network segmentation for industrial environments, and incident response planning for safety-critical systems.
A clear understanding of why OT security demands a different mindset than IT security, which specific controls eliminate the highest-risk attack vectors, and a realistic starting point for teams that are building a program from scratch.
Why OT Security Starts with Physical Risk
The gap between IT and OT security is not about tools — it is architectural. Industrial control systems were engineered for reliability and deterministic behavior, often decades before network connectivity was ever a design requirement. A historian server logging process data may still run Windows Server 2008 not because no one noticed, but because the ICS vendor certified only that version for use with the system. Replacing it requires re-certification, a process that typically spans 12 to 24 months depending on operational complexity and vendor contract terms.
Availability is the governing constraint. A SCADA system managing a high-voltage substation cannot be taken offline for a security scan without coordinating with grid operators in advance. The consequence of an unplanned restart is not a delayed transaction — it is a regional outage or a safety event that triggers a regulatory investigation.
The attack surface has grown sharply over the past 15 years. OT networks that once ran on isolated serial buses with no IP connectivity now carry IP-based sensors, vendor remote access tunnels, and live integrations with enterprise ERP platforms. Connectivity that improved operational efficiency also introduced exposure that industrial environments were never designed to handle.
Who Attacks Industrial Infrastructure and How
Nation-state actors
Nation-state actors operating against critical infrastructure use extended dwell times and purpose-built implants. Industroyer, deployed against Ukrainian power infrastructure in 2016, was engineered to issue native ICS protocol commands directly — not to encrypt files or exfiltrate data, but to manipulate physical process outputs (ESET). Pipedream, disclosed in 2022, demonstrated modular capability against Modbus, OPC UA, and DNP3 — the protocols that industrial devices actually speak (CISA). These tools are not generic malware repurposed for OT. They were built specifically to understand and abuse industrial protocols.
Ransomware groups
Ransomware groups rarely target OT directly. The 2021 Colonial Pipeline incident illustrates the pattern: ransomware encrypted IT systems, and the operator shut down pipeline operations as a precautionary measure to prevent a compromised billing system from affecting process control. The IT/OT boundary, in practice, is thinner than most network diagrams suggest.
Vendor access abuse and insider threats
Vendor access abuse and insider threats represent a category that conventional perimeter monitoring misses entirely. Third-party maintenance engineers with persistent VPN credentials, contractors who retain access after a project ends, and employees with standing access to engineering workstations create exposure that firewalls and intrusion detection systems do not address. These are identity and access management problems as much as they are network security problems.
The Controls That Matter Most in OT
Network segmentation
Network segmentation delivers the most risk reduction per dollar spent in OT environments. The Purdue Model provides a reference architecture for zoning industrial networks into distinct tiers — enterprise systems, SCADA servers, control systems, and field devices — with controlled crossing points between each layer. NIST SP 800-82 Rev. 3, Guide to Operational Technology Security, provides practical guidance on implementing these boundaries in hybrid environments that mix legacy serial infrastructure with modern IP networks (NIST, 2023).
Passive monitoring
Passive monitoring is the preferred visibility approach in OT for a specific reason. Active scanning can crash PLCs and RTUs that lack the processing capacity to handle unexpected traffic bursts. Passive asset discovery and anomaly detection tools listen without sending traffic, learning the normal communication patterns of the environment and flagging deviations. The meaningful signal is rarely a new device appearing on the network. More often it is a change in the communication pattern between a known engineering workstation and a specific PLC — a change that no firewall rule will catch but that a properly tuned passive monitoring tool will surface.
Remote access
Remote access is the most consistently exploited entry point in documented ICS incidents. Every vendor connection into an OT environment should route through a controlled jump server or privileged access workstation, require multi-factor authentication, and be scoped to the duration of the maintenance window. Persistent always-on VPN tunnels for third-party vendors are a recurring finding in post-incident reviews.
The table below maps the primary threat categories to the controls that address each most directly.
| Threat Category | Primary Control | Key Standard / Reference |
|---|---|---|
| Nation-state ICS-targeted malware | Protocol-aware inspection, OT network monitoring | NIST SP 800-82 Rev. 3 |
| Ransomware lateral movement | IT/OT segmentation, offline backups | IEC 62443-3-3 |
| Vendor / remote access abuse | Time-limited access, MFA on jump servers | NERC CIP-005 |
| Insider threat on engineering workstation | Application whitelisting, USB controls | IEC 62443-2-1 |
OT Incident Response Is a Team Decision
Standard IT incident response playbooks fail in OT environments in a specific and predictable way. Isolating a compromised endpoint by pulling it off the network is the right instinct in an office — in a process plant, isolating the wrong PLC can trigger an emergency shutdown with immediate physical consequences.
Consider a realistic scenario. A security analyst reviewing OT network logs notices that an engineering workstation has begun polling a remote terminal unit it has never communicated with before, outside of any scheduled maintenance window. The analyst escalates to the OT security engineer, who confirms with the plant operator that no authorized work is in progress. Together, they decide to capture traffic passively and quarantine the workstation at the jump server level — blocking outbound sessions without touching the RTU or disrupting the process. Investigation reveals that a stale vendor account was used to log in from an external IP address. The account is disabled, the vendor is notified, and the access management policy is updated to enforce automatic credential expiration after project completion.
OT incident response requires a defined escalation path that includes process engineers and plant managers from the start, not as a late-stage notification. Response playbooks must document which systems can be safely isolated, which cannot be touched without plant operator approval, and what the safe fallback state is for each critical process segment. That documentation must exist offline. An active incident may render your SIEM, ticketing system, and internal knowledge base unavailable at exactly the moment you need them.
Which Standards Apply to Your Organization
IEC 62443 is the industrial cybersecurity standard with the broadest international adoption across critical infrastructure sectors. It addresses both product security requirements for vendors and operational security requirements for asset owners, making it useful across the supply chain (IEC). In the North American electric sector, NERC CIP standards impose specific requirements on electronic security perimeters, access management, and incident reporting for bulk electric system assets (NERC).
Smaller operations — a regional water utility, a mid-size manufacturer — typically lack a dedicated OT security function. The most effective governance move available to them is to designate an OT security owner from the engineering side and invest in training that person on security fundamentals. Engineers already understand process risk in terms that matter. Teaching them to recognize anomalous network behavior is more productive than teaching an IT analyst to interpret ladder logic.
Asset inventory is the prerequisite for everything else in an OT security program. Segmentation, monitoring, and patch management all depend on knowing what you have. A credible OT asset inventory includes device make, model, firmware version, communication protocols in use, and whether a known vulnerability exists with a vendor-issued patch available. Without this baseline, every other security investment is undermined.
Measuring Program Maturity
Tracking the right metrics separates a maturing OT security program from a compliance checkbox exercise.
- Percentage of OT assets with documented owners and confirmed firmware versions (target: 100% of Tier 1 critical assets within 12 months)
- Mean time to detect anomalous lateral movement within the OT network (establish a baseline, then reduce it)
- Number of active third-party remote access credentials versus number of active maintenance contracts (these two figures should match)
- Percentage of incident response scenarios that have been tabletop-tested with operations staff present
Vulnerability closure rates are not a reliable OT metric. Many vulnerabilities will not be patched on any near-term timeline because the vendor patch does not yet exist, or applying it requires a change window that operations cannot schedule. A more honest and actionable metric is the count of unmitigated critical vulnerabilities that have documented compensating controls, a formal review schedule, and a remediation timeline — even if that timeline extends 24 months into a vendor upgrade cycle.
Frequently Asked Questions (FAQ)
The fundamental difference is consequence modeling. In IT, the primary risk from a compromised system is data confidentiality and availability. In OT, a compromised controller can alter physical process outputs — pressure, temperature, flow rate, electrical frequency — with consequences that reach worker safety, environmental damage, and public harm. Every security decision in an OT environment must account for physical process risk, not just data risk.
Partially. Micro-segmentation, least-privilege access, and continuous verification of remote sessions all apply. However, Zero Trust’s assumption of continuous endpoint authentication is difficult to enforce on older PLCs and RTUs that use legacy protocols without native authentication support. The practical approach is to apply Zero Trust controls at the boundary — the jump server, the data diode, the remote access gateway — rather than at the endpoint level, where the technology often cannot support it.
Start with asset inventory and network visibility. Deploy a passive monitoring solution to understand what is communicating with what. Then audit remote access credentials and eliminate any that are persistent, shared, or no longer tied to an active vendor relationship. These two actions address the most commonly exploited attack vectors without requiring significant capital expenditure or operational disruption.
It depends on sector and geography. NIST SP 800-82 is US-centric and widely referenced by federal agencies and critical infrastructure operators in North America. IEC 62443 is internationally recognized and structured to address both asset owners and product vendors, making it more practical when the supply chain spans multiple countries or when procuring new ICS equipment with security requirements built into the contract. Many organizations use both — NIST for internal program structure, IEC 62443 for procurement requirements and third-party assessments.
Document the vulnerability, assess its exploitability within the specific network context, and implement compensating controls. These typically include network segmentation to limit which devices can reach the vulnerable asset, enhanced monitoring tuned to the exploitation indicators specific to that vulnerability, and a defined escalation path if an indicator fires. The compensating control must be logged formally, reviewed on a set schedule, and linked to a remediation timeline — even if that timeline is two years out pending a vendor upgrade cycle.
Leave a Reply