Securing the Industrial Heartbeat: Why Zero Trust is Imperative (and Different) for OT/ICS

As CISOs, we navigate a complex and ever-expanding threat landscape. While our focus has historically been on safeguarding traditional IT assets – data centers, endpoints, cloud services – the digital transformation sweeping across all sectors has fundamentally changed the game. Critical Infrastructure (CI) and the Operational Technology (OT) and Industrial Control Systems (ICS) that power it are now increasingly interconnected and exposed, demanding a paradigm shift in how we approach their security. Zero Trust (ZT), a strategy premised on the idea that no user or asset is implicitly trusted, is no longer just an IT concept; it is becoming an imperative for securing the industrial backbone of our nations.

However, applying ZT principles to OT/ICS environments is not a simple lift-and-shift of IT security practices. These systems have unique characteristics, objectives, and challenges that require a tailored approach. Understanding these differences is the first critical step in building a resilient and secure Critical Infrastructure.

The Fundamental Differences: OT/ICS vs. IT

At its core, the divergence between OT/ICS and IT security stems from their primary objectives.

• IT: Traditionally prioritized the CIA triad (Confidentiality, Integrity, Availability).
• OT/ICS: Designed primarily for reliability, safety, and availability, with less initial emphasis on confidentiality and integrity. The paramount goals are maintaining continuous, safe operation, protecting human lives, and preventing physical harm or damage. Downtime or disruption can have severe safety, health, environmental, national security, and economic consequences.

This fundamental difference dictates that security measures in OT/ICS must not interfere with these critical operational goals, especially during maintenance windows or incidents.

Beyond objectives, significant differences exist in architecture, technology, and operational culture.

• Legacy Systems and Extended Lifespans: CI systems are often static, complex, expensive, and have lifespans measured in decades, sometimes operating far beyond vendor support. Upgrading or replacing them is a complex, time-consuming process. Many run outdated or vendor-modified operating systems that are rarely patched like IT systems. These systems often lack basic protections like automatic antivirus or modern access controls.
• Unique Protocols and Proprietary Configurations: Lower levels of OT/ICS networks use a suite of specific, often proprietary protocols (e.g., Modbus, PROFIBUS, DNP3). Configurations can vary significantly and may not be well-documented. Many of these protocols are unencrypted by design, as encryption can introduce intolerable latency that impacts real-time operations and safety mechanisms.
• Convergence and Connectivity: Historically "air gapped," modern OT/ICS systems are increasingly interconnected via Ethernet, wireless, cloud, and SaaS applications due to digital transformation. Even legacy systems interface with external media or maintenance laptops. This collapsing of traditional boundaries exposes previously isolated systems and makes ZT imperative where there is no physical air gap.
• Policy Enforcement Challenges: Many OT/ICS devices at lower levels (Purdue Model levels 0/1) are legacy, headless, or lack the resources to support software agents. This means ZT policy enforcement often relies on network-based controls (Layer 2/3) or requires retrofitting infrastructure, as opposed to the preferred Layer 7 controls common in IT ZT implementations.
• Monitoring Differences: While operational monitoring is mature, security-focused monitoring lags behind IT. OT-specific protocols require specialized tools, and critical security data often isn't centralized or correlated effectively. However, OT networks offer the potential for more granular visibility and higher-fidelity alerting due to less network chatter than IT.
• Vulnerability Management: Patching is feasible only a small percentage of the time (4-10%) in OT/ICS due to criticality and testing requirements. The focus shifts to contextual vulnerability assessment and relying heavily on mitigating controls like ZT policies.
• Skillset and Collaboration: Securing OT/ICS requires understanding industrial operations and specific technologies (PLCs, SCADA, DCS), distinct from IT. Bridging the divide between IT and OT personnel and fostering cross-functional collaboration is crucial but challenging.
• Physical Exposure: Many OT/ICS components are in exposed, accessible locations, making them vulnerable to physical tampering and sabotage in addition to cyber threats. ZT implementation needs to account for physical security alongside technical controls.
• Supply Chain Challenges: While also an IT issue, OT suppliers often prioritize operational functionality over security, leading to fewer built-in security measures and less robust processes for reporting and patching vulnerabilities.

The Tailored Roadmap: Applying the Five-Step ZT Process to OT/ICS

Implementing ZT in OT/ICS requires a systematic approach that respects the unique environment. The guidance provided outlines a repeatable, five-step implementation process based on the NSTAC Report to the President on Zero Trust and Trusted Identity Management. This process is designed to be incremental and iterative and aligns with established OT/ICS guidance like ISA/IEC 62443 and NIST.

1. Define the Protect Surface for OT/ICS: This foundational step involves creating a comprehensive, ideally dynamically maintained, inventory of assets (Data, Applications, Assets, and Services - DAAS elements) and understanding their business value and criticality. In OT/ICS, Protect Surfaces include both digital and physical assets. Leveraging existing frameworks like the ISA/IEC 62443 Zone and Conduit Model can serve as a starting point, where zones can be equated to subsystems or Protect Surfaces. The "crawl, walk, run" approach is recommended, starting with low-risk assets to gain experience before tackling critical systems ("crown jewels"). Gathering metadata for each Protect Surface is essential for subsequent steps. It is crucial to use OT/ICS tailored tools and processes for asset discovery to avoid disrupting systems.
2. Map Operational Flows for OT/ICS: Instead of focusing solely on "transactions" as in IT, this step maps operational flows, process flows, and control flows within, to, and from the Protect Surface. The asset inventory from Step 1 is refined here, documenting dependencies and interactions. The ISA/IEC 62443 Conduit construct aligns well with ZT flow mapping, clearly defining communication paths between zones. It is imperative to map both legitimate and potentially unauthorized flows. Default-deny is the goal, evaluating all permitted traffic, not just active flows. The increasing IT/OT convergence makes this step more critical and complex, requiring mapping a mixed ecosystem of protocols and technologies. Specialized OT-aware discovery and mapping tools are highly valuable here. Collaboration between IT, OT, and security experts is vital.
3. Build a Zero Trust Architecture in OT/ICS: Based on the Protect Surface and mapped flows, this step designs where ZT policies can be enforced, referred to as Policy Enforcement Points (PEPs). Diagramming the environment, ideally referencing the Purdue Model and ISA/IEC 62443 zones/conduits, is key. Segmentation requirements become clear from the zone and conduit view. Placing PEPs as close to the protected asset as possible is the goal. For legacy/headless OT devices that can't support software agents, network-based enforcement (Layer 2/3) or retrofitting is necessary, with L3 policies often more practical than L7 due to specialized protocols. Redundancy across PEPs and Policy Decision Points (PDPs) is crucial for availability and safety.
4. Create Zero Trust Policy in OT/ICS: This is the first "doing" step, implementing the access controls designed in Step 3. The policy centers on granular allow rules, akin to ISA/IEC 62443 conduits. A deny-by-default stance is crucial at zone boundaries. However, due to safety, an allow-by-default within zones may be necessary, a key difference from IT ZT. The principle of least privilege is paramount. User and device authentication must balance rigor with the need for timely access during emergencies. The Kipling Method ("who, what, when, where, why, and how") is recommended for defining precise policies, reducing reliance on traditional port-based rules. Asset-specific security boundaries complement microsegmentation by placing controls directly adjacent to critical assets.
5. Ongoing Monitoring and Maintenance Activities in OT/ICS: ZT is not a one-time project; it requires continuous monitoring, analysis, and adaptation. This step includes Incident Response planning (often requiring specialized OT/ICS partners), visibility and monitoring with OT-aware tools, and vulnerability management focused on mitigating controls rather than just patching. The ZTA itself needs to be revisited and updated as assets, operational flows, and technologies change, ideally through automated processes.

Aligning with and Fortifying Existing Practices

A well-implemented ZT strategy doesn't replace existing OT/ICS security efforts; it fortifies them. The five-step process aligns well with the SANS Top 5 Critical Controls for OT/ICS:

• ICS Incident Response: Integrated into ZT Step 5.
• Defensible Architecture: Explicitly addressed by the ZT five-step process, which enables visibility, asset identification, and segmentation.
• ICS Network Visibility Monitoring: Aligns with ZT Step 5, emphasizing protocol-aware tools and focusing on internal changes.
• Secure Remote Access: Defined and controlled throughout the ZT process (Steps 1-4) and monitored in Step 5. Securing remote access paths is a priority.
• Risk-Based Vulnerability Management: Enhanced by ZT's comprehensive understanding of assets and flows, enabling appropriate mitigation and continuous monitoring.

Looking Ahead: Secure by Design for New Systems

While the guidance primarily addresses retrofitting ZT into existing environments, the industry trend is towards "secure by design". Vendors and OEMs are increasingly embedding ZT capabilities into new OT/ICS technology. Leveraging these modern solutions can significantly accelerate ZT adoption, especially in greenfield deployments. For brownfield scenarios, software-based updates from vendors can sometimes enable ZT features on existing equipment. As ZT matures, integrating these vendor capabilities via open APIs will be crucial for achieving a high maturity level.

Conclusion: A Collaborative Imperative

Securing Critical Infrastructure in the age of IT/OT convergence is a monumental task requiring a strategic, tailored, and collaborative approach. Zero Trust provides a powerful framework for achieving this, shifting from implicit trust at network perimeters to explicit verification for every access attempt to critical assets.

By systematically applying the five-step ZT implementation process – Defining Protect Surfaces, Mapping Operational Flows, Building a ZTA, Creating Policies, and Engaging in Ongoing Monitoring and Maintenance – organizations can build a robust defense that enhances the security, resilience, and reliability of their OT/ICS environments. This journey demands organizational commitment, cross-functional collaboration between cybersecurity, IT, and OT personnel, and strategic engagement with vendors and partners.

Embracing Zero Trust for OT/ICS is not just about adopting new technology; it's about fundamentally rethinking how we protect the systems that underpin our society's health, safety, and economic well-being. It's a continuous process that adapts to evolving threats and technological advancements, ensuring that our critical infrastructure remains resilient in the face of a dynamic future.