Attachment 3_ NIST SP 800-82r3 Guide to Operational Technology (OT)Security.pdf

NIST Special Publication NIST SP 800-82r3

Guide to Operational Technology (OT) Security

Keith Stouffer Michael Pease CheeYee Tang

Timothy Zimmerman Victoria Pillitteri

Suzanne Lightman Adam Hahn

Stephanie Saravia Aslam Sherule

Michael Thompson

This publication is available free of charge from:

https://doi.org/10.6028/NIST.SP.800-82r3

NIST Special Publication NIST SP 800-82r3

Guide to Operational Technology (OT) Security

Keith Stouffer Victoria Pillitteri Michael Pease Suzanne Lightman CheeYee Tang Computer Security Division

Timothy Zimmerman Information Technology Laboratory Smart Connected Systems Division

Communications Technology Laboratory Adam Hahn Stephanie Saravia

Aslam Sherule Michael Thompson

The MITRE Corporation

This publication is available free of charge from:

https://doi.org/10.6028/NIST.SP.800-82r3

September 2023

U.S. Department of Commerce Gina M. Raimondo, Secretary

National Institute of Standards and Technology Laurie E. Locascio, NIST Director and Under Secretary of Commerce for Standards and Technology

NIST SP 800-82r3 Guide to Operational Technology (OT) Security September 2023

Certain commercial equipment, instruments, software, or materials, commercial or non-commercial, are identified in this paper in order to specify the experimental procedure adequately. Such identification does not imply recommendation or endorsement of any product or service by NIST, nor does it imply that the materials or equipment identified are necessarily the best available for the purpose.

There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST.

Organizations are encouraged to review all draft publications during public comment periods and provide feedback to NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at https://csrc.nist.gov/publications.

Authority This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283.

NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130.

Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or any other federal official. This publication may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.

NIST Technical Series Policies Copyright, Use, and Licensing Statements NIST Technical Series Publication Identifier Syntax

Publication History Approved by the NIST Editorial Review Board on 2023-09-20 Supersedes NIST Special Publication (SP) 800-82 Rev. 2 (May 2015) https://doi.org/10.6028/NIST.SP.800-82r2

How to Cite this NIST Technical Series Publication:

Stouffer K, Pease M, Tang CY, Zimmerman T, Pillitteri V, Lightman S, Hahn A, Saravia S, Sherule A, Thompson M (2023) Title. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) NIST SP 800-82r3. https://doi.org/10.6028/NIST.SP.800-82r3

Author ORCID iDs Keith Stouffer: 0000-0003-1220-5487 Michael Pease: 0000-0002-6489-2621 CheeYee Tang: 0000-0002-5488-8645 Timothy Zimmerman: 0000-0001-8451-0515 Victoria Pillitteri: 0000-0002-7446-7506 Suzanne Lightman: 0000-0002-5007-3887

Contact Information sp800-82rev3@nist.gov

National Institute of Standards and Technology Attn: Computer Security Division, Information Technology Laboratory 100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930

All comments are subject to release under the Freedom of Information Act (FOIA).

i

Abstract

This document provides guidance on how to secure operational technology (OT) while addressing their unique performance, reliability, and safety requirements. OT encompasses a broad range of programmable systems and devices that interact with the physical environment (or manage devices that interact with the physical environment). These systems and devices detect or cause a direct change through the monitoring and/or control of devices, processes, and events. Examples include industrial control systems, building automation systems, transportation systems, physical access control systems, physical environment monitoring systems, and physical environment measurement systems. The document provides an overview of OT and typical system topologies, identifies common threats and vulnerabilities to these systems, and provides recommended security countermeasures to mitigate the associated risks.

Keywords computer security; distributed control systems (DCS); industrial control systems (ICS);

information security; network security; operational technology (OT); programmable logic controllers (PLC); risk management; security controls; supervisory control and data acquisition (SCADA) systems.

Reports on Computer Systems Technology

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analyses to advance the development and productive use of information technology. ITL’s responsibilities include the development of management, administrative, technical, and physical standards and guidelines for the cost-effective security and privacy of other than national security-related information in federal information systems. The Special Publication 800-series reports on ITL’s research, guidelines, and outreach efforts in information system security, and its collaborative activities with industry, government, and academic organizations.

ii

Note to Readers

This document is the third revision of NIST SP 800-82. Updates in this revision include:

• Expansion in scope from industrial control systems to operational technology (OT)

• Updates to OT threats and vulnerabilities

• Updates to OT risk management, recommended practices, and architectures

• Updates to current activities in OT security

• Updates to security capabilities and tools for OT

• Additional alignment with other OT security standards and guidelines, including the Cybersecurity Framework

• New tailoring guidance for NIST SP 800-53, Rev. 5 security controls

• An OT overlay for NIST SP 800-53, Rev. 5 security controls that provides tailored security control baselines for low-, moderate-, and high-impact OT systems iii

Patent Disclosure Notice

NOTICE: ITL has requested that holders of patent claims whose use may be required for compliance with the guidance or requirements of this publication disclose such patent claims to ITL. However, holders of patents are not obligated to respond to ITL calls for patents and ITL has not undertaken a patent search in order to identify which, if any, patents may apply to this publication.

As of the date of publication and following call(s) for the identification of patent claims whose use may be required for compliance with the guidance or requirements of this publication, no such patent claims have been identified to ITL.

No representation is made or implied by ITL that licenses are not required to avoid patent infringement in the use of this publication.

iv

Table of Contents

Executive Summary

Introduction

Purpose and Scope

Audience

Document Structure

OT Overview

Evolution of OT

OT-Based Systems and Their Interdependencies

OT System Operation, Architectures, and Components

2.3.1. OT System Design Considerations

2.3.2. SCADA Systems

2.3.3. Distributed Control Systems

2.3.4. Programmable Logic Controller-Based Topologies

2.3.5. Building Automation Systems

2.3.6. Physical Access Control Systems

2.3.7. Safety Systems

2.3.8. Industrial Internet of Things

Comparing OT and IT System Security

OT Cybersecurity Program Development

Establish a Charter for the OT Cybersecurity Program

Business Case for the OT Cybersecurity Program

3.2.1. Benefits of Cybersecurity Investments

3.2.2. Building an OT Cybersecurity Business Case

3.2.3. Resources for Building a Business Case

3.2.4. Presenting the OT Cybersecurity Business Case to Leadership

OT Cybersecurity Program Content

3.3.1. Establish OT Cybersecurity Governance

3.3.2. Build and Train a Cross-Functional Team to Implement the OT Cybersecurity Program

3.3.3. Define the OT Cybersecurity Strategy

3.3.4. Define OT-Specific Policies and Procedures

3.3.5. Establish a Cybersecurity Awareness Training Program for the OT Environment

3.3.6. Implement a Risk Management Framework for OT

3.3.7. Develop a Maintenance Tracking Capability

3.3.8. Develop an Incident Response Capability

v

3.3.9. Develop a Recovery and Restoration Capability

3.3.10. Summary of OT Cybersecurity Program Content

Risk Management for OT Systems

Managing OT Security Risk

4.1.1. Framing OT Risk

4.1.2. Assessing Risk in an OT Environment

4.1.3. Responding to Risk in an OT Environment

4.1.4. Monitoring Risk in an OT Environment

Special Areas for Consideration

4.2.1. Supply Chain Risk Management

4.2.2. Safety Systems

Applying the Risk Management Framework to OT Systems

4.3.1. Prepare

4.3.2. Categorize

4.3.3. Select

4.3.4. Implement

4.3.5. Assess

4.3.6. Authorize

4.3.7. Monitor

OT Cybersecurity Architecture

Cybersecurity Strategy

5.1.1. Impacts of Choosing a Cybersecurity Strategy

5.1.2. Defense-in-Depth Strategy

5.1.3. Other Cybersecurity Strategy Considerations

Defense-in-Depth Architecture Capabilities

5.2.1. Layer 1 – Security Management

5.2.2. Layer 2 – Physical Security

5.2.3. Layer 3 – Network Security

5.2.4. Layer 4 – Hardware Security

5.2.5. Layer 5 – Software Security

Additional Cybersecurity Architecture Considerations

5.3.1. Cyber-Related Safety Considerations

5.3.2. Availability Considerations

5.3.3. Geographically Distributed Systems

5.3.4. Regulatory Requirements

5.3.5. Environmental Considerations

vi

5.3.6. Field I/O (Purdue Level 0) Security Considerations

5.3.7. Additional Security Considerations for IIoT

Cybersecurity Architecture Models

5.4.1. Distributed Control System (DCS)-Based OT Systems

5.4.2. DCS- and PLC-Based OT with IIoT

5.4.3. SCADA-Based OT Environments

Applying the Cybersecurity Framework to OT

Identify (ID)

6.1.1. Asset Management (ID.AM)

6.1.2. Governance (ID.GV)

6.1.3. Risk Assessment (ID.RA)

6.1.4. Risk Management Strategy (ID.RM)

6.1.5. Supply Chain Risk Management (ID.SC)

Protect (PR)

6.2.1. Identity Management and Access Control (PR.AC)

6.2.2. Awareness and Training (PR.AT)

6.2.3. Data Security (PR.DS)

6.2.4. Information Protection Processes and Procedures (PR.IP)

6.2.5. Maintenance (PR.MA)

6.2.6. Protective Technology (PR.PT)

6.2.7. Media Protection (PR.PT-2)

6.2.8. Personnel Security

6.2.9. Wireless Communications

6.2.10. Remote Access

6.2.11. Flaw Remediation and Patch Management

6.2.12. Time Synchronization

Detect (DE)

6.3.1. Anomalies and Events (DE.AE)

6.3.2. Security Continuous Monitoring (DE.CM)

6.3.3. Detection Process (DE.DP)

Respond (RS)

6.4.1. Response Planning (RS.RP)

6.4.2. Response Communications (RS.CO)

6.4.3. Response Analysis (RS.AN)

6.4.4. Response Mitigation (RS.MI)

6.4.5. Response Improvements (RS.IM)

vii

Recover (RC)

6.5.1. Recovery Planning (RC.RP)

6.5.2. Recovery Improvements (RC.IM)

6.5.3. Recovery Communications (RC.CO)

References

Appendix A. List of Symbols, Abbreviations, and Acronyms

Appendix B. Glossary

Appendix C. Threat Sources, Vulnerabilities, and Incidents

C.1. Threat Sources

C.2. Vulnerabilities and Predisposing Conditions

C.2.1. Policy and Procedure Vulnerabilities and Predisposing Conditions

C.2.2. System Vulnerabilities and Predisposing Conditions

C.3. Threat Events and Incidents

C.3.1. Adversarial Events

C.3.2. Structural Events

C.3.3. Environmental Events

C.3.4. Accidental Events

Appendix D. OT Security Organizations, Research, and Activities

D.1. Consortiums and Standards

D.1.1. Critical Infrastructure Partnership Advisory Council (CIPAC)

D.1.2. Institute for Information Infrastructure Protection (I3P)

D.1.3. International Electrotechnical Commission (IEC)

D.1.3.1. IEC Technical Committee 57

D.1.3.2. IEC Technical Committee 65

D.1.4. Institute of Electrical and Electronics Engineers, Inc. (IEEE)

D.1.4.1. IEEE Engineering in Medicine and Biology Society (EMBS)

D.1.4.2. IEEE Industrial Electronics Society (IES)

D.1.4.3. IEEE Power & Energy Society (PES)

D.1.4.4. IEEE Technical Committee on Power System Communications and Cybersecurity (PSCCC)

D.1.4.5. IEEE Robotics and Automation Society (RAS)

D.1.4.6. IEEE Vehicular Technology Society (VTS)

D.1.5. International Society of Automation (ISA)

D.1.5.1. ISA95, Enterprise-Control System Integration

D.1.5.2. ISA99, Industrial Automation and Control Systems Security

D.1.5.3. ISASecure

D.1.5.4. ISA-TR84.00.09, Cybersecurity Related to the Functional Safety Lifecycle viii

D.1.6. International Organization for Standardization (ISO)

D.1.6.1. ISO 27001

D.1.6.2. ISO 27002:2022

D.1.7. National Council of Information Sharing and Analysis Centers (ISACs)

D.1.8. National Institute of Standards and Technology (NIST)

D.1.8.1. NIST SP 800 Series Cybersecurity Guidelines

D.1.8.2. NIST SP 1800 Series Cybersecurity Practice Guides

D.1.8.3. NIST Internal or Interagency Reports

D.1.9. North American Electric Reliability Corporation (NERC)

D.1.9.4. NERC Critical Infrastructure Protection (CIP) Standards

D.1.10. Operational Technology Cybersecurity Coalition

D.2. Research Initiatives and Programs

D.2.1. Clean Energy Cybersecurity Accelerator Initiative

D.2.2. Cybersecurity for Energy Delivery Systems (CEDS) R&D Program

D.2.3. Cybersecurity for the Operational Technology Environment (CyOTE)

D.2.4. Cybersecurity Risk Information Sharing Program (CRISP)

D.2.5. Cyber Testing for Resilient Industrial Control Systems (CyTRICS)

D.2.6. Homeland Security Information Network – Critical Infrastructure (HSIN-CI)

D.2.7. INL Cyber-Informed Engineering (CIE) and Consequence-Driven CIE (CCE)

D.2.8. Linking the Oil and Gas Industry to Improve Cybersecurity (LOGIIC)

D.2.9. NIST Cyber-Physical Systems and Internet of Things Program

D.2.10. NIST Cybersecurity for Smart Grid Systems Project

D.2.11. NIST Cybersecurity for Smart Manufacturing Systems Project

D.2.12. NIST Reliable, High Performance Wireless Systems for Factory Automation

D.2.13. NIST Prognostics and Health Management for Reliable Operations in Smart Manufacturing (PHM4SM)

D.2.14. NIST Supply Chain Traceability for Agri-Food Manufacturing

D.3. Tools and Training

D.3.1. CISA Cyber Security Evaluation Tool (CSET®)

D.3.2. CISA Cybersecurity Framework Guidance

D.3.3. CISA ICS Alerts, Advisories, and Reports

D.3.4. CISA ICS Training Courses

D.3.5. MITRE ATT&CK for ICS

D.3.6. NIST Cybersecurity Framework

D.3.7. SANS ICS Security Courses

D.4. Sector-Specific Resources

D.4.1. Chemical ix

D.4.2. Communications

D.4.3. Critical Manufacturing

D.4.4. Dams

D.4.5. Energy

D.4.6. Food and Agriculture

D.4.7. Healthcare and Public Health

D.4.8. Nuclear Reactors, Materials, and Waste

D.4.9. Transportation Systems

D.4.10. Water and Wastewater

D.5. Conferences and Working Groups

D.5.1. Digital Bond’s SCADA Security Scientific Symposium (S4)

D.5.2. Industrial Control Systems Joint Working Group (ICSJWG)

D.5.3. IFIP Working Group 11.10 on Critical Infrastructure Protection

D.5.4. SecurityWeek’s ICS Cyber Security Conference

D.5.5. Stockholm International Summit on Cyber Security in SCADA and ICS

(CS3STHLM)

Appendix E. OT Security Capabilities and Tools

E.1. Network Segmentation and Isolation

E.1.1. Firewalls

E.1.2. Unidirectional Gateways

E.1.3. Virtual Local Area Networks (VLANs)

E.1.4. Software-Defined Networking (SDN)

E.2. Network Monitoring – Security Information and Event Management (SIEM)

E.2.1. Centralized Logging

E.2.2. Passive Scanning

E.2.3. Active Scanning

E.2.4. Malware Detection

E.2.5. Behavioral Anomaly Detection

E.2.6. Data Loss Prevention (DLP)

E.2.7. Deception Technology

E.2.8. Digital Twins

E.3. Data Security

E.3.1. Backup Storage

E.3.2. Immutable Storage

E.3.3. File Hashing

E.3.4. Digital Signatures

E.3.5. Block Ciphers x

E.3.6. Remote Access

Appendix F. OT Overlay

F.1. Overlay Characteristics

F.2. Applicability

F.3. Overlay Summary

F.4. Tailoring Considerations

F.5. OT Communication Protocols

F.6. Definitions

F.7. Detailed Overlay Control Specifications

F.7.1. ACCESS CONTROL – AC

F.7.2. AWARENESS AND TRAINING – AT

F.7.3. AUDITING AND ACCOUNTABILITY – AU

F.7.4. ASSESSMENT, AUTHORIZATION, AND MONITORING – CA

F.7.5. CONFIGURATION MANAGEMENT – CM

F.7.6. CONTINGENCY PLANNING – CP

F.7.7. IDENTIFICATION AND AUTHENTICATION – IA

F.7.8. INCIDENT RESPONSE – IR

F.7.9. MAINTENANCE – MA

F.7.10. MEDIA PROTECTION –MP

F.7.11. PHYSICAL AND ENVIRONMENTAL PROTECTION – PE

F.7.12. PLANNING – PL

F.7.13. ORGANIZATION-WIDE INFORMATION SECURITY PROGRAM

MANAGEMENT CONTROLS – PM

F.7.14. PERSONNEL SECURITY – PS

F.7.15. RISK ASSESSMENT – RA

F.7.16. SYSTEM AND SERVICES ACQUISITION – SA

F.7.17. SYSTEM AND COMMUNICATIONS PROTECTION – SC

F.7.18. SYSTEM AND INFORMATION INTEGRITY – SI

F.7.19. SUPPLY CHAIN RISK MANAGEMENT – SR

Appendix G. Change Log xi

List of Tables

Table 1. Summary of typical differences between IT and OT systems Table 2. Sections with additional guidance for establishing a cybersecurity program Table 3. Possible definitions for OT impact levels based on the product produced, the industry, and security concerns Table 4. Event Likelihood Evaluation Table 5. Categories of non-digital OT control components Table 6. Applying the RMF Prepare step to OT Table 7. Applying the RMF Categorize step to OT Table 8. Applying the RMF Select step to OT Table 9. Applying the RMF Implement step to OT Table 10. Applying the RMF Assess step to OT Table 11. Applying the RMF Authorize step to OT Table 12. Applying the RMF Monitor step to OT Table 13. Threats to OT Table 14. Policy and procedure vulnerabilities and predisposing conditions Table 15. Architecture and design vulnerabilities and predisposing conditions Table 16. Configuration and maintenance vulnerabilities and predisposing conditions Table 17. Physical vulnerabilities and predisposing conditions Table 18. Software development vulnerabilities and predisposing conditions Table 19. Communication and network configuration vulnerabilities and predisposing conditions Table 20. Sensor, final element, and asset management vulnerabilities and predisposing conditions Table 21. Examples of potential threat events Table 22. Control baselines xii

List of Figures

Fig. 1. Basic operation of a typical OT system Fig. 2. A general SCADA system layout that shows control center devices, communications equipment, and field sites Fig. 3. Examples of point-to-point, series, series-star, and multi-drop SCADA communications topologies Fig. 4. An example SCADA topology that supports a large number of remote stations Fig. 5. A comprehensive SCADA system implementation example Fig. 6. An example rail monitoring and control SCADA system implementation Fig. 7. A comprehensive DCS implementation example Fig. 8. A PLC control system implementation example Fig. 9. A BAS implementation example Fig. 10. A PACS implementation example Fig. 11. An SIS implementation example Fig. 12. A three-tiered IIoT system architecture Fig. 13. Risk management process: Frame, assess, respond, and monitor Fig. 14. Risk management levels: Organization, mission and business process, and system ...46 Fig. 15. Risk Management Framework steps Fig. 16. High-level example of the Purdue model and IIoT model for network segmentation with DMZ segments Fig. 17. A DCS implementation example Fig. 18. A defense-in-depth security architecture example for a DCS system Fig. 19. A security architecture example for DCS system with IIoT devices Fig. 20. An example SCADA system in an OT environment Fig. 21. A security architecture example for a SCADA system Fig. 22. Detailed overlay control specifications illustrated xiii

Acknowledgments for Revision 3

The authors gratefully acknowledge and appreciate the significant contributions from Sallie Edwards, Blaine Jefferies, and John Hoyt from The MITRE Corporation and Megan Corso and Brett Ramsay from the Department of Defense. The authors wish to thank their colleagues who reviewed drafts of the document and contributed to its content, including Eran Salfati, Karen Scarfone, and Isabel Van Wyk.

Acknowledgments for Previous Versions

The authors wish to thank their colleagues who reviewed drafts of the original version of the document and contributed to its technical content. The authors would particularly like to acknowledge Tim Grance, Ron Ross, Stu Katzke, and Freemon Johnson of NIST for their keen and insightful assistance throughout the development of the document. The authors also gratefully acknowledge and appreciate the many contributions from the public and private sectors whose thoughtful and constructive comments improved the quality and usefulness of the publication. The authors would particularly like to thank the members of ISA99, Lisa Kaiser, Department of Homeland Security, the Department of Homeland Security Industrial Control System Joint Working Group (ICSJWG), the Office of the Deputy Undersecretary of Defense for Installations and Environment, Business Enterprise Integration Directorate staff, Daryl Haegley, and Michael Chipley for their exceptional contributions to this publication. The authors would also like to thank the UK National Centre for the Protection of National Infrastructure (CPNI) for allowing portions of the Good Practice Guide on Firewall Deployment for SCADA and Process Control Network to be used in the document as well as ISA for allowing portions of the ISA- 62443 Standards to be used in the document.

Executive Summary

This document provides guidance for establishing secure operational technology (OT)1

1 See https://csrc.nist.gov/Projects/operational-technology-security.

while addressing OT’s unique performance, reliability, and safety requirements. OT encompasses a broad range of programmable systems and devices that interact with the physical environment (or manage devices that interact with the physical environment). These systems and devices detect or cause a direct change through the monitoring and/or control of devices, processes, and events. Examples include industrial control systems (ICS), building automation systems, transportation systems, physical access control systems, physical environment monitoring systems, and physical environment measurement systems. This document provides an overview of OT and typical system topologies, identifies common threats and vulnerabilities to these systems, and recommends security countermeasures to mitigate the associated risks.

OT is vital to the operation of U.S. critical infrastructures, which are often highly interconnected, mutually dependent systems. It is important to note that while federal agencies operate many of the Nation’s critical infrastructures, many others are privately owned and operated. Additionally, critical infrastructures are often referred to as a “system of systems” because of the interdependencies that exist between various industrial sectors and interconnections between business partners.

Initially, OT had little resemblance to traditional information technology (IT) systems because OT systems were isolated, ran proprietary control protocols, and used specialized hardware and software. As OT systems adopt IT solutions to enable corporate business systems connectivity and remote access capabilities and are designed and implemented using industry-standard computers, operating systems (OSs), and network protocols, they have begun to resemble IT systems. This integration supports new IT capabilities, but it provides significantly less isolation for OT from the outside world than predecessor systems, creating a greater need to secure OT systems. The increasing use of wireless networking places OT implementations at greater risk from adversaries who are in relatively close physical proximity but do not have direct physical access to the equipment. While security solutions have been designed to deal with these issues in typical IT systems, special precautions must be taken when introducing these same solutions to OT environments. In some cases, new security solutions that are tailored to the OT environment are needed.

Although some characteristics are similar, OT also has characteristics that differ from traditional information processing systems. Many of these differences stem from the fact that logic executing in OT has a direct effect on the physical world. Some of these characteristics include significant risk to the health and safety of human lives, serious damage to the environment, and severe financial issues, such as production losses, negative impacts to the Nation’s economy, and the compromise of proprietary information. OT has unique performance and reliability requirements and often uses OSs and applications that may be considered unconventional to typical IT personnel. Furthermore, the goals of safety and efficiency sometimes conflict with security in the design and operation of OT systems.

OT cybersecurity programs should always be part of broader OT safety and reliability programs at both industrial sites and enterprise cybersecurity programs because cybersecurity is essential to the safe and reliable operation of modern industrial processes. Threats to OT systems can come from numerous sources, including hostile governments, terrorist groups, disgruntled employees, malicious intruders, complexities, natural disasters, malicious actions by insiders, and unintentional actions such human error or failure to follow established policies and procedures. OT security objectives typically prioritize integrity and availability, followed by confidentiality, but also must consider safety as an overarching priority.

Possible incidents that an OT system may face include:

• Blocked or delayed flow of information through OT networks, which could disrupt OT operation, including loss of view and loss of control

• Unauthorized changes to instructions, commands, or alarm thresholds that could damage, disable, or shut down equipment, create environmental impacts, and/or endanger human life

• Inaccurate information sent to system operators, either to disguise unauthorized changes or to cause operators to initiate inappropriate actions that could have various negative effects

• Modified OT software or configuration settings or OT software infected with malware, which could have various negative effects

• Interference with the operation of equipment protection systems, which could endanger costly and difficult-to-replace equipment

• Interference with the operation of safety systems, which could endanger human life Major security objectives for an OT implementation should include the following:

• Restrict logical access to the OT network, network activity, and systems. This may include using unidirectional gateways, utilizing a demilitarized zone (DMZ) network architecture with firewalls to prevent network traffic from passing directly between the corporate and OT networks, and having separate authentication mechanisms and credentials for users of the corporate and OT networks. The OT system should also use a network topology that has multiple layers, with the most critical communications occurring in the most secure and reliable layer.

• Restrict physical access to the OT network and devices. Unauthorized physical access to components can seriously disrupt the OT’s functionality. A combination of physical access controls should be used, such as locks, card readers, and/or guards.

• Protect individual OT components from exploitation. This includes deploying security patches in as expeditious a manner as possible after testing them under field conditions, disabling all unused ports and services and ensuring that they remain disabled, restricting OT user privileges to only those that are required for each user’s role, tracking and monitoring audit trails, and using security controls such as antivirus software and file integrity checking software where technically feasible to prevent, deter, detect, and mitigate malware. Keys of OT assets like programmable logic controllers (PLCs) and safety systems should be in the “Run” position at all times unless they are being actively programmed.

• Restrict unauthorized modification of data. This includes data in all states (e.g., at rest, in transit, in use) including data flows crossing network boundaries.

• Detect security events and incidents. Detecting security events that have not yet escalated into incidents can help defenders break the attack chain before attackers attain their objectives. This includes the capability to detect failed OT components, unavailable services, and exhausted resources that are important to provide proper and safe functioning of the OT system.

• Maintain functionality during adverse conditions. This involves designing the OT system with the ability to ensure delivery of critical operations through disruption.

Critical components should have a redundant counterpart. Additionally, if a component fails, it should fail in a manner that does not generate unnecessary traffic on the OT or other networks nor causes another problem elsewhere, such as a cascading event. The OT system should also allow for graceful degradation, such as moving from “normal operation” with full automation to “emergency operation” with operators more involved and less automation to “manual operation” with no automation.

• Restore and recover the system after an incident. Incidents are inevitable, and an incident response plan is essential. A major characteristic of a good security program is how quickly the system can be recovered after an incident has occurred.

A cross-functional cybersecurity team can share their varied domain knowledge and experience to evaluate and mitigate risks to the OT system. At a minimum, the cybersecurity team should consist of a member of the organization’s IT staff, a control engineer, a control system operator, a network and system security expert, a member of the management staff, and a member of the physical security department. For continuity and completeness, the cybersecurity team should consult with the control system vendor and/or system integrator as well. The cybersecurity team should coordinate closely with site management (e.g., facility superintendent) and the company’s Chief Information Officer (CIO) or Chief Security Officer (CSO), who – along with the Chief Executive Officer (CEO) or Chief Operating Officer (COO) – accepts complete responsibility and accountability for the cybersecurity of the OT system and for any safety incidents, reliability incidents, or equipment damage caused directly or indirectly by cyber incidents. An effective cybersecurity program for an OT system should apply a strategy known as “defense in depth,” while calls for layering security mechanisms such that the impact of a failure in any one mechanism is minimized. Organizations should not rely on “security by obscurity.”

In a typical OT system, a defense-in-depth strategy includes:

• Developing security policies, procedures, training, and educational material that apply specifically to the OT system

• Considering OT security policies and procedures based on the National Terrorism Advisory System and deploying increasingly heightened security postures as the Threat Level increases

• Addressing security throughout the life cycle of the OT system, including architecture design, procurement, installation, operations, maintenance, and decommissioning

• Implementing a network topology for the OT system that has multiple layers, with the most critical communications occurring in the most secure and reliable layer

• Providing logical separation between the corporate and OT networks (e.g., stateful inspection firewalls between the networks, unidirectional gateways)

• Considering where physical separation may be required as opposed to logical separation

• Employing a DMZ network architecture (e.g., prevent direct traffic between the corporate and OT networks)

• Using multi-factor authentication for remote access to the OT system

• Ensuring that critical components are redundant and are on redundant networks

• Designing critical systems for graceful degradation (fault tolerant) to prevent catastrophic cascading events

• Disabling unused ports and services on OT devices after testing to ensure that this will not impact OT operation

• Restricting physical access to the OT network and devices

• Restricting OT user privileges to only those that are required to perform each user’s function (e.g., establishing role-based access control, configuring each role based on the principle of least privilege)

• Using separate authentication mechanisms and credentials for users of the OT network and the corporate network (i.e., OT network accounts do not use corporate network user accounts)

• Using modern technology, such as smart cards for user authentication

• Implementing security controls (e.g., intrusion detection software, antivirus software, file integrity checking software) where technically feasible to prevent, deter, detect, and mitigate the introduction, exposure, and propagation of malicious software to, within, and from the OT system

• Applying security techniques, such as encryption and/or cryptographic hashes, to OT data storage and communications where appropriate

• Expeditiously deploying security patches after testing all patches under field conditions on a test system, if possible, before installation on the OT system

• Tracking and monitoring audit trails on critical areas of the OT system

• Employing reliable and secure network protocols and services where feasible

In cooperation with the public and private sector OT community, NIST has developed specific guidance on the application of the security controls in NIST Special Publication (SP) 800-53, Rev. 5, Security and Privacy Controls for Information Systems and Organizations [SP800-53r5], to OT. This guidance is included in Appendix F of this document.

While many of the controls in NIST SP 800-53, Rev. 5 are applicable to OT as written, some controls require OT-specific interpretation and/or augmentation by adding one or more of the following:

• OT Discussion provides organizations with additional information on the application of the security controls and control enhancements to OT and the environments in which these specialized systems operate. The guidance also provides information as to why a particular security control or control enhancement may not be applicable in some OT environments or may be a candidate for tailoring (i.e., the application of scoping guidance and/or compensating controls). OT Discussion does not replace the original Supplemental Guidance in NIST SP 800-53, Rev. 5.

• Control Enhancements (one or more) provide augmentations to the original control that may be required for some OT systems.

The most successful method for securing OT systems is to gather industry-recommended practices and engage in a proactive, collaborative effort between management, the OT engineers and operators, the IT organization, and a trusted OT advisor. This team should draw upon the wealth of information available from the ongoing Federal Government, industry group, vendor, and standards activities listed in Appendix D.

Introduction

Purpose and Scope

The purpose of this document is to provide guidance for establishing secure operational technology (OT)2

2 The acronym “OT” can stand for either “operational technology” or “operational technologies.” The context around the acronym, especially the use of singular or plural words, will indicate which meaning is intended.

while addressing OT’s unique performance, reliability, and safety requirements. This document gives an overview of OT systems and typical system topologies, identifies common threats and vulnerabilities for these systems, and recommends security countermeasures to mitigate the associated risks. Additionally, it presents an OT-tailored security control overlay based on NIST Special Publication (SP) 800-53, Rev. 5 [SP800-53r5] that customizes controls for the unique characteristics of the OT domain. The body of the document provides context for the overlay, but the overlay is intended to stand alone.

Because there are many types of OT with varying levels of potential risk and impact, this document provides a list of many methods and techniques for securing OT systems. The document should not be used purely as a checklist to secure a specific system. Readers are encouraged to perform a risk-based assessment on their systems and to tailor the recommended guidelines and solutions to meet their specific security, business, and operational requirements.

The range of applicability of the basic concepts for securing OT systems presented in this document continues to expand.

Audience

This document covers details that are specific to OT systems. Readers of this document should be acquainted with general computer security concepts and communication protocols, such as those used in networking. The document is technical in nature. However, it provides the necessary background to understand the topics that are discussed.

The intended audience is varied and includes the following:

• Control engineers, integrators, and architects who design or implement OT systems

• System administrators, engineers, and other information technology (IT) professionals who administer, patch, or secure OT systems

• Security consultants who perform security assessments and penetration testing of OT systems

• Managers who are responsible for OT systems

• Senior management who need to better understand the risks to OT systems as they justify and apply an OT cybersecurity program

• Researchers and analysts who are trying to understand the unique security needs of OT systems

• Vendors who are developing products that will be deployed as part of an OT system

Document Structure

The remainder of this document is divided into the following major sections:

• Section 2 gives an overview of OT, including a comparison between OT and IT systems.

• Section 3 discusses the development and deployment of an OT cybersecurity program to mitigate risk for the vulnerabilities identified in Appendix C.

• Section 4 examines OT security risk management and applying the Risk Management Framework to OT systems.

• Section 5 provides recommendations for integrating security into network architectures typically found in OT systems, with an emphasis on network segmentation and separation practices.

• Section 6 offers guidance on applying the Cybersecurity Framework to OT systems.

• The References section provides a list of references used in the development of this document.

This guide also contains several appendices with supporting material, as follows:

• Appendix A lists the acronyms and abbreviations used in this document.

• Appendix B contains a glossary of the terms used in this document.

• Appendix C discusses OT threat sources, vulnerabilities and predisposing conditions, threat events, and incidents.

• Appendix D presents lists and descriptions of OT security organizations, research, and activities.

• Appendix E discusses various OT security capabilities and tools.

• Appendix F defines the NIST SP 800-53, Rev. 5 OT overlay and lists security controls, enhancements, and supplemental guidance that apply specifically to OT systems.

OT Overview

Operational technology (OT)3

3 See https://csrc.nist.gov/Projects/operational-technology-security.

encompasses a broad range of programmable systems and devices that interact with the physical environment (or manage devices that interact with the physical environment). These systems and devices detect or cause a direct change through the monitoring and/or control of devices, processes, and events. Examples include industrial control systems, building automation systems, transportation systems, physical access control systems, physical environment monitoring systems, and physical environment measurement systems.

OT systems consist of combinations of control components (e.g., electrical, mechanical, hydraulic, pneumatic) that act together to achieve an objective (e.g., manufacturing, transportation of matter or energy). The part of the system primarily concerned with producing an output is referred to as the process. The part of the system primarily concerned with maintaining conformance with specifications is referred to as the controller (or control). The control components of the system include the specification of the desired output or performance.

The system can be configured in one of three ways:

• Open loop: The output is controlled by established settings.

• Closed loop: The output affects the input in such a way as to maintain the desired control objective.

• Manual mode: The system is completely controlled by humans.

This section provides an overview of several types of common OT systems, including supervisory control and data acquisition (SCADA), distributed control systems (DCS), programmable logic controllers (PLCs), building automation systems (BASs), physical access control systems (PACSs), and the Industrial Internet of Things (IIoT). Diagrams depict the network topology, connections, components, and protocols that are typically used for each system type. These examples only attempt to identify notional topology concepts. Actual implementations of these types of control systems may be hybrids that blur the lines between them. Note that the diagrams in this section do not focus on securing OT. Security architecture and security controls are discussed in Section 5 and Appendix F of this document, respectively.

Evolution of OT Much of today’s OT evolved from the insertion of IT capabilities into existing physical systems, often replacing or supplementing physical control mechanisms. For example, embedded digital controls replaced analog mechanical controls in rotating machines and engines. Improvements in cost and performance have encouraged this evolution and resulted in many of today’s “smart” technologies, such as the smart electric grid, smart transportation, smart buildings, smart manufacturing, and the Internet of Things. While this increases the connectivity and criticality of these systems, it also creates a greater need for their adaptability, resilience, safety, and security.

Engineering OT continues to provide new capabilities while maintaining the typical long life cycles of these systems. The introduction of IT capabilities into physical systems presents emergent behavior with security implications. Engineering models and analysis are evolving to address these emergent properties, including safety, security, privacy, and environmental impact interdependencies.

OT-Based Systems and Their Interdependencies

OT is used in many industries and infrastructures, including those identified by the Cybersecurity and Infrastructure Security Agency (CISA) as critical infrastructure sectors listed below. OT can be found in all critical infrastructures and is more prevalent in the sectors that are in bold.

• Chemical Sector

• Commercial Facilities Sector

• Communications Sector

• Critical Manufacturing Sector

• Dams Sector

• Defense Industrial Base Sector

• Emergency Services Sector

• Energy Sector

• Financial Services Sector

• Food and Agriculture Sector

• Government Facilities Sector

• Healthcare and Public Health Sector

• Information Technology Sector

• Nuclear Reactors, Materials, and Waste Sector

• Transportation Systems Sector

• Water and Wastewater Systems Sector OT is vital to the operation of U.S. critical infrastructures, which are often highly interconnected and mutually dependent systems, both physically and through a host of information and communications technologies. It is important to note that while federal agencies operate many of the critical infrastructures mentioned above, many others are privately owned and operated.

Additionally, critical infrastructures are often referred to as a “system of systems” because of the interdependencies that exist between various industrial sectors and the interconnections between business partners [Peerenboom][Rinaldi]. An incident in one infrastructure can directly and indirectly affect other infrastructures through cascading and escalating failures.

For example, both the electrical power transmission and distribution grid industries use geographically distributed SCADA control technology to operate highly interconnected and dynamic systems that consist of thousands of public and private utilities and rural cooperatives for supplying electricity to end users. Some SCADA systems monitor and control electricity distribution by collecting data from and issuing commands to geographically remote field control stations from a centralized location. SCADA systems are also used to monitor and control water, oil, and natural gas distribution, including pipelines, ships, trucks, rail systems, and wastewater collection systems.

SCADA systems and DCS are often networked together. This is the case for electric power control centers and generation facilities. Although electric power generation facility operation is controlled by a DCS, the DCS must communicate with the SCADA system to coordinate production output with transmission and distribution demands.

Electric power is often thought to be one of the most prevalent sources of disruptions of interdependent critical infrastructures. For example, a cascading failure can be initiated by a disruption of the microwave communications network used for an electric power transmission SCADA system. The lack of monitoring and control capabilities could cause a large generating unit to be taken offline and lead to the loss of power at a transmission substation. This loss could cause a major imbalance, triggering a cascading failure across the power grid and resulting in large area blackouts that potentially affect oil and natural gas production, refinery operations, water treatment systems, wastewater collection systems, and pipeline transport systems that rely on the grid for electric power.

OT System Operation, Architectures, and Components

As Fig. 1 depicts, a typical OT system contains numerous control loops, human-machine interfaces, and remote diagnostics and maintenance tools. The system is built using an array of network protocols on layered network architectures. Some critical processes may also include safety systems.

A control loop utilizes sensors, actuators, and controllers to manipulate some controlled process.

A sensor is a device that produces a measurement of some physical property and then sends this information as controlled variables to the controller. The controller interprets the measurements and generates corresponding manipulated variables based on a control algorithm and target set points, which it transmits to the actuators. Actuators – such as control valves, breakers, switches, and motors – are used to directly manipulate the controlled process based on commands from the controller.

In a typical monitoring system, there are generally no direct connections between the sensors and any actuators. Sensor values are transmitted to a monitoring station to be analyzed by a human.

However, these types of systems can still be considered OT systems (albeit with a human in the loop) because the objective of the monitoring system is likely to identify and ultimately mitigate an event or condition (e.g., a door alerting that it has been forced open, resulting in security personnel being sent to investigate; an environmental sensor that detects high temperatures in a server room, resulting in control center personnel activating an auxiliary air conditioning unit).

Operators and engineers use human-machine interfaces (HMIs) to monitor and configure set points, control algorithms, and adjust and establish parameters in the controller. The HMI also displays process status information and historical information. Diagnostics and maintenance utilities are used to prevent, identify, and recover from abnormal operation or failures.

Sometimes, control loops are nested and/or cascading, whereby the set point for one loop is based on the process variable determined by another loop. Supervisory-level loops and lower-level loops operate continuously over the duration of a process with cycle times ranging in the order of milliseconds to minutes.

Fig. 1. Basic operation of a typical OT system

2.3.1. OT System Design Considerations

The design of an OT system depends on many factors, including whether a SCADA, DCS, or PLC-based topology is used. This section identifies key factors that drive design decisions regarding the control, communication, reliability, and redundancy properties of the OT system.

Because these factors heavily influence the design of the OT system, they also help determine the system’s security needs.

• Safety. Systems must be able to detect unsafe conditions and trigger actions to reduce unsafe conditions to safe ones. In most safety-critical operations, human oversight and control of a potentially dangerous process are essential.

• Control timing requirements.