Securing OT: Navigating NIST SP 800-82 & IEC 62443 Framework

In a world increasingly reliant on interconnected systems, securing Operational Technology (OT) environments has become paramount. No longer isolated domains, OT systems are now integral to critical infrastructure, manufacturing, and various industrial sectors.This convergence with IT systems, while enabling greater efficiency and data-driven insights, nevertheless exposes OT environments to a broader range of cyber threats.For cybersecurity professionals and decision-makers tasked with safeguarding these vital systems, navigating the complexities of OT security can feel like charting unknown waters. Fortunately, established frameworks and standards like NIST SP 800-82 and the IEC 62443 series offer a reliable compass and map.

So, how do you effectively leverage these frameworks to build a robust OT security program? How can your organization navigate the unique challenges and meet the stringent compliance demands of today’s threat landscape? Let’s dive in.

Understanding the OT Security Landscape in the Context of NIST SP 800-82

OT encompasses a wide array of programmable systems and devices that interact with the physical world – for example, everything from industrial control systems (ICS) and building automation systems (BAS) to transportation networks and physical access control systems (see NIST SP 800-82r3, Section 2. OT Overview). However, unlike IT systems focused on data processing and information management, OT directly controls and monitors physical processes (see IEC 62443 standard series).

The convergence of IT and OT has blurred traditional security boundaries. Where once OT systems operated in relative isolation, enterprises are now increasingly connecting them to networks and the internet, creating pathways for cyberattacks to disrupt physical operations. Consequently, traditional IT security solutions often fall short in addressing the unique performance, reliability, and safety requirements of OT environments (see NIST SP 800-82r3, Section 2.4. Comparing OT and IT System Security). 

This requires a new, tailored approach to security – one that considers the specific characteristics of OT systems and leverages established frameworks to build a robust defense. Therefore, a critical area of concern is to understand how to identify and correct vulnerabilities in OT systems. 

NIST SP 800-82: A Foundational Guide

NIST Special Publication 800-82, “Guide to Operational Technology (OT) Security,” provides invaluable guidance for securing OT systems. It emphasizes a risk-based approach, urging organizations to tailor security measures to their specific needs and operational requirements. The latest revision (Rev. 3) expands upon industrial control systems to operational technology (OT), while still focusing on real-world applicability.

Key Takeaways from NIST SP 800-82r3:

• Understanding OT-Specific Risks: Recognizing that OT systems have unique performance, reliability, and safety requirements that differ from traditional IT systems (see NIST SP 800-82r3, Section 2.4).

• Developing an OT Cybersecurity Program: Establishing a structured approach to OT security, including governance, strategy, and incident response (see NIST SP 800-82r3, Section 3).

• Applying Risk Management Framework to OT: Managing OT security risk, implementing appropriate risk responses, and addressing supply chain considerations (see NIST SP 800-82r3, Section 4).

• Leveraging Cybersecurity Architectures: Considering system performance, safety interdependencies, geography distribution, and other factors in designing a cyber security architecture for OT systems (see NIST SP 800-82r3, Section 5).

• Utilizing the Cybersecurity Framework: How to use the Identify, Protect, Detect, Respond, and Recover framework to identify risks, apply safeguards, detect cyber threats, and respond to and recover from cybersecurity incidents (see NIST SP 800-82r3, Section 6).

IEC 62443: A Standard for Industrial Automation and Control Systems (IACS) Security

The IEC 62443 series is a set of international standards that address cybersecurity for industrial automation and control systems (IACS). Unlike NIST SP 800-82, which is a guide, IEC 62443 provides normative requirements for different aspects of IACS security. The current organization of this series are:

• General (62443-1-x): The 62443-1-1 standard outlines fundamental concepts, models, and terminology, establishing a common understanding of IACS security. These standards define the scope of what needs to be protected, providing structure that can be applied. 

• Policies and procedures (62443-2-x): These standards (62443-2-1 is the most commonly known) define the security program requirements for IACS asset owners, covering topics such as security management systems, Risk Assessment, and security policies. They specify how to establish and maintain a robust security program.

• System (62443-3-x): The 62443-3-x standards detail the specific requirements for system-level security, covering areas such as security zoning, security layering, and security testing. For example, these set requirements for proper segmentation, control management, intrusion detection, etc. 

• Component (62443-4-x): The 62443-4-x standards address the product lifecycle requirements for IACS components, covering aspects such as secure design, secure development, and vulnerability management. This is particularly applicable for OEMs. 

Key Concepts from IEC 62443

• Zone and Conduit Model: Section 4.1 Risk Management for OT Systems. The 62443 standard advocates for dividing the OT environment into zones (grouping assets with similar security requirements) and conduits (communication pathways between zones) as a basis for implementing security controls. This model has been designed to segregate systems to increase performance of controls. A failure to take this action can cause cascading failures to other devices and systems. In addition to the network topology, organizations should also review the types of communication between the zones. For example, are only peer systems allowed to communicate? What happens when there are communication failures?

• Security Levels: Section 5.2. Defense-In-Depth Architecture Capabilities. IEC 62443 defines security levels (SLs) that describe the capabilities of security controls, from SL 1 (basic protection) to SL 4 (enhanced protection). Applying a particular system that does not meet standards can put the system at risk of over tolerance or risk tolerance. Organizations should document and record appropriate measures.

• Lifecycle Approach: Section 3.3.6 Implement a Risk Management Framework for OT. The standards emphasize that organizations must consider security throughout the entire lifecycle of an IACS, from design and implementation to operation and maintenance. Furthermore, since the system is not static, teams should regularly reevaluate system designs to ensure proper upkeep.

Building Your OT Security Program: A Practical Approach

Here’s how you can combine the guidance from NIST SP 800-82 and the requirements of IEC 62443 to create a robust OT security

Building the Foundation of Your OT Security Program in Alignment with NIST SP 800-82

• Establish a Cross-Functional Team (NIST SP 800-82r3, Section 3.3.2). Assemble a team with expertise in OT operations, IT security, risk management, and compliance. This team will drive the security program and ensure that security measures align with business objectives and operational realities. This promotes a “shared responsibility model” to ensure both understanding of all security concerns for the enterprise’s assets.

• Define Your OT Security Strategy: Define the software vulnerability risk response scenarios they need to be prepared to handle with routine patching and emergency patching procedures. Establish a clear understanding of your risk tolerance, regulatory requirements, and business priorities to develop a tailored strategy (NIST SP 800-82r3, Section 3.3.3, IEC 62443).

• Identify OT assets: The inventory should include information on each computing asset’s technical characteristics and mission/business characteristics (per-asset perspective) (see NIST SP 800-82r3, Section 3.2).

• Conduct a Risk Assessment: (see NIST SP 800-82r3, Section 4.1.2, IEC 62443-3-2): Identify threats, vulnerabilities, and potential impacts to your OT systems. The CISA’s Known Exploited Vulnerabilities Catalog (see NIST SP 800-40 Rev. 4) can assist with the process. This includes assessing risks through identifying technical and mission characteristics to the entire IT and OT infrastructure. Evaluate your current security posture and identify vulnerabilities and any potential impacts.

Section 2: Implementing, Maintaining, and Improving OT Security

• Segment your network (see IEC 62443 standard series): Implement your strategy to include zoning, firewall rules, monitoring and control methods, etc.

• Implement Security Controls: Implement OT-specific long-term risk mitigation methods, as well as mitigations needed to prevent exploitation of specific vulnerabilities. Prioritize those controls that protect the most critical assets and align with your risk management strategy. Consider also routine and emergency procedures (see NIST SP 800-82r3, Section 6.2).

• Monitor and Maintain: Develop a maintenance tracking capability for implementing and automating any changes. Develop ways to track compliance requirements, too, and identify any patterns that lead to a higher risk of cybersecurity threats to a business. (See NIST SP 800-82r3, Section 2.3.4, applying the “plan, do, check, act” cycle).

• Test Your Response and Update Continuously: Review data, identify any patterns of security risks, and then update risk management and control plans accordingly. Develop/test a system of checks and balances for changes to systems and configurations.

Specific Threat Event Examples and Solutions

To get a firmer grasp on how to build your OT security, here are some examples of incidents that are of interest:

• Compromised industrial networks: Implement separate and direct, offline communication protocols to prevent loss of view and loss of control (based on information from multiple sections of NIST SP 800-82).

• Consider the impact on safety systems: These systems may need to provide real time information for safety interlocks. If disconnected, ensure a known safestate can be entered quickly and reliably.

• Compromised system software and config settings: Implement a temporary response (based on information from multiple sections of NIST SP 800-82).

• Implement separate and direct, offline communication protocols to prevent loss of view and loss of control. Should it occur, can you shut down the device itself from initiating unsafe states?

• Inaccurate information sent to system operators: Implement controls to prevent the device itself from initiating unsafe states (based on information from multiple sections of NIST SP 800-82).

• Implement controls to prevent the device itself from initiating unsafe states. Does the engineering team regularly audit for changes? Review vendor-specific settings. Can a secure baseline config be implemented from the system’s data historian?

This section is intended to illustrate the importance of recognizing unique events and, consequently, what organizations need to reliably achieve in order to meet their goals. For instance, to ensure proper visibility, make the logging system highly scalable.