NIST SP 800-82 Rev. 3 日本語訳

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

Keith Stouffer

Michael Pease

CheeYee Tang

Timothy Zimmerman

Smart Connected Systems Division

Communications Technology Laboratory

Victoria Pillitteri

Suzanne Lightman

Computer Security Division

Information 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

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

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

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).

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.

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.

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.

Note to Readers

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

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.

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

(CS3STHLM) — 206

Appendix E. OT Security Capabilities and Tools — 207

E.1. Network Segmentation and Isolation — 207

E.1.1. Firewalls — 207

E.1.2. Unidirectional Gateways — 207

E.1.3. Virtual Local Area Networks (VLANs) — 207

E.1.4. Software-Defined Networking (SDN) — 208

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

E.2.1. Centralized Logging — 208

E.2.2. Passive Scanning — 208

E.2.3. Active Scanning — 209

E.2.4. Malware Detection — 209

E.2.5. Behavioral Anomaly Detection — 209

E.2.6. Data Loss Prevention (DLP) — 210

E.2.7. Deception Technology — 210

E.2.8. Digital Twins — 210

E.3. Data Security — 210

E.3.1. Backup Storage — 210

E.3.2. Immutable Storage — 211

E.3.3. File Hashing — 211

E.3.4. Digital Signatures — 211

E.3.5. Block Ciphers — 211

E.3.6. Remote Access — 212

Appendix F. OT Overlay — 213

F.1. Overlay Characteristics — 213

F.2. Applicability — 214

F.3. Overlay Summary — 214

F.4. Tailoring Considerations — 223

F.5. OT Communication Protocols — 224

F.6. Definitions — 225

F.7. Detailed Overlay Control Specifications — 225

F.7.1. ACCESS CONTROL – AC — 227

F.7.2. AWARENESS AND TRAINING – AT — 235

F.7.3. AUDITING AND ACCOUNTABILITY – AU — 236

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

F.7.5. CONFIGURATION MANAGEMENT – CM — 243

F.7.6. CONTINGENCY PLANNING – CP — 247

F.7.7. IDENTIFICATION AND AUTHENTICATION – IA — 252

F.7.8. INCIDENT RESPONSE – IR — 256

F.7.9. MAINTENANCE – MA — 258

F.7.10. MEDIA PROTECTION –MP — 260

F.7.11. PHYSICAL AND ENVIRONMENTAL PROTECTION – PE — 262

F.7.12. PLANNING – PL — 267

F.7.13. ORGANIZATION-WIDE INFORMATION SECURITY PROGRAM

MANAGEMENT CONTROLS – PM — 269

F.7.14. PERSONNEL SECURITY – PS — 276

F.7.15. RISK ASSESSMENT – RA — 278

F.7.16. SYSTEM AND SERVICES ACQUISITION – SA — 280

F.7.17. SYSTEM AND COMMUNICATIONS PROTECTION – SC — 283

F.7.18. SYSTEM AND INFORMATION INTEGRITY – SI — 291

F.7.19. SUPPLY CHAIN RISK MANAGEMENT – SR — 296

Appendix G. Change Log — 299

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.

This document provides guidance for establishing secure operational technology (OT)¹ 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:

Major security objectives for an OT implementation should include the following:

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:

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:

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.

The purpose of this document is to provide guidance for establishing secure operational technology (OT)² 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.

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:

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

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

Operational technology (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.

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:

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.

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 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.

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.

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

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.

Supervisory control and data acquisition (SCADA) systems are used to control dispersed assets for which centralized data acquisition is as important as control [Bailey][Boyer]. These systems are used in distribution systems, such as water distribution and wastewater collection systems, oil and natural gas pipelines, electrical utility transmission and distribution systems, and rail and other public transportation systems. SCADA systems integrate data acquisition systems with data transmission systems and HMI software to provide a centralized monitoring and control system for numerous process inputs and outputs. SCADA systems are designed to collect field information, transfer it to a control center, and display the information to the operator graphically or textually, thereby allowing the operator to monitor or control an entire system from a central location in near real-time. Based on the sophistication and setup of the individual system, control of any individual system, operation, or task can be automatic, or it can be performed by operator commands. Typical hardware includes a control server placed at a control center, communications equipment (e.g., radio, telephone line, cable, or satellite), and one or more geographically distributed field sites that consist of remote terminal units (RTUs) and/or PLCs that control actuators and/or monitor sensors. The control server stores and processes the information from RTU inputs and outputs, while the RTU or PLC controls the local process. The communications hardware allows for the transfer of information and data between the control server and the RTUs or PLCs. The software is programmed to tell the system what and when to monitor, what parameter ranges are acceptable, and what response to initiate when a process variable changes outside of acceptable values. An intelligent electronic device (IED), such as a protective relay, may communicate directly to the control server, or a local RTU may poll the IEDs to collect the data and pass it to the control server. IEDs provide a direct interface to control and monitor equipment and sensors. IEDs may be directly polled and controlled by the control server and, in most cases, have local programming that allows for the IED to act without direct instructions from the control center. SCADA systems are usually designed to be fault-tolerant systems with significant redundancy built in, although redundancy may not be a sufficient countermeasure in the face of a malicious attack.

Figure 2 shows the components and general configuration of a SCADA system. The control center at the top of the diagram houses a control server and the communications routers. Other control center components include the HMI, engineering workstations, and the data historian, which are all connected by a local area network (LAN). The control center collects and logs information gathered by the field sites, displays information to the HMI, and may generate actions based on detected events. The control center is also responsible for centralized alarming, trend analyses, and reporting.

The field sites at the bottom of Fig. 2 locally control actuators and monitor sensors. Field sites are often equipped with a remote access capability to allow operators to perform remote diagnostics and repairs, usually over a separate dial-up modem or wide area network (WAN) connection. Standard and proprietary communication protocols that run over serial and network communications are used to transport information between the control center and field sites using telemetry techniques, such as telephone line, cable, fiber, and radio frequencies (e.g., broadcast, microwave, satellite).

Fig. 2. A general SCADA system layout that shows control center devices, communications equipment, and field sites

SCADA communication topologies vary among implementations. The various topologies used are shown in Fig. 3, including point-to-point, series, series-star, and multi-drop [AGA12]. Point-to-point is functionally the simplest type, though it can be expensive because of the individual channels needed for each connection. In a series configuration, the number of channels used is reduced, though channel sharing impacts the efficiency and complexity of SCADA operations. Similarly, the series-star and multi-drop configurations’ use of one channel per device results in decreased efficiency and increased system complexity.

The four basic SCADA topologies shown in Fig. 3 can be further augmented by using dedicated devices to manage communication exchanges and perform message switching and buffering.

Fig. 3. Examples of point-to-point, series, series-star, and multi-drop SCADA communications topologies

Large SCADA systems that contain hundreds of RTUs often employ a sub-control server to alleviate the burden on the primary server. This type of topology is shown in Fig. 4.

Fig. 4. An example SCADA topology that supports a large number of remote stations

Figure 5 shows an example SCADA system implementation that consists of a primary control center and three field sites. A second backup control center provides redundancy in the event of a primary control center malfunction. Point-to-point connections are used for all communications between the control center and field site, and two connections use radio telemetry. The third field site is local to the control center and uses the WAN for communications. A regional control center resides above the primary control center for a higher level of supervisory control. The corporate enterprise network has access to all control centers through the WAN, and field sites can be accessed remotely for troubleshooting and maintenance operations. The primary control center polls field devices for data at defined intervals (e.g., 5 seconds, 60 seconds) and can send new set points to field devices as required. In addition to polling and issuing high-level commands, the control server also watches for priority interrupts from field site alarm systems.

Fig. 5. A comprehensive SCADA system implementation example

Figure 6 shows an example implementation for rail monitoring and control. This example includes a rail control center that houses the SCADA system and three sections of a rail system. The SCADA system polls the rail sections for information, such as the status of the trains, signal systems, traction electrification systems, and ticket vending machines. This information is also fed to operator consoles at the HMI stations within the rail control center. The SCADA system monitors operator inputs at the rail control center and disperses high-level operator commands to the rail section components. In addition, the SCADA system monitors conditions at the individual rail sections and issues commands based on these conditions (e.g., stopping a train to prevent it from entering an area that has been flooded or is occupied by another train).

Fig. 6. An example rail monitoring and control SCADA system implementation

A distributed control system (DCS) is used to control production systems within the same geographic location for industries such as oil refineries, water and wastewater treatment, electric power generation, chemical manufacturing, automotive production, and pharmaceutical processing. These systems are usually process control or discrete part control systems.

A DCS is integrated as a control architecture that contains a supervisory level of control to oversee multiple integrated sub-systems that are responsible for controlling the details of a localized process. A DCS uses a centralized supervisory control loop to mediate a group of localized controllers that share the overall tasks of carrying out an entire production process [Erickson]. Product and process control are usually achieved by deploying feedback or feedforward control loops, whereby key product and/or process conditions are automatically maintained around a desired set point. Specific process controllers or more capable PLCs are employed in the field and tuned to provide the desired tolerance and the rate of self-correction during process upsets. By modularizing the production system, a DCS reduces the impact of a single fault on the overall system. In many modern systems, the DCS is interfaced with the corporate enterprise network to give business operations a view of production.

Figure 7 shows an example implementation of the components and general configuration of a DCS. This DCS encompasses an entire facility, from the bottom-level production processes up to the corporate enterprise layer. In this example, a supervisory controller (control server) communicates to its subordinates via a control network. The supervisor sends set points to and requests data from the distributed field controllers. The distributed controllers control their process actuators based on control server commands and sensor feedback from process sensors.

Figure 7 also gives examples of low-level controllers found on a DCS system. The field control devices shown include a machine controller, a PLC, and a process controller. The machine controller interfaces with sensors and actuators using point-to-point wiring, while the other three field devices incorporate fieldbus networks to interface with process sensors and actuators. Fieldbus networks eliminate the need for point-to-point wiring between a controller and individual field sensors and actuators. Additionally, a fieldbus allows for greater functionality beyond control, including field device diagnostics, and can accomplish control algorithms within the fieldbus, thereby avoiding signal routing back to the PLC for every control operation. Standard industrial communication protocols designed by industry groups such as Modbus and Fieldbus [Berge] are often used on control networks and fieldbus networks.

In addition to the supervisory-level and field-level control loops, intermediate levels of control may also exist. For example, in the case of a DCS controlling a discrete part manufacturing facility, there could be an intermediate level supervisor for each cell within the plant. This supervisor encompasses a manufacturing cell containing a machine controller that processes a part and a robot controller that handles raw stock and final products. There could be several of these cells that manage field-level controllers under the main DCS supervisory control loop.

Fig. 7. A comprehensive DCS implementation example

PLCs are used in both SCADA and DCS systems as the control components of an overall hierarchical system to locally manage processes through feedback control, as described in the previous sections. In the case of SCADA systems, they may provide similar functionality to RTUs. When used in DCS systems, PLCs are implemented as local controllers within a supervisory control scheme. PLCs can also be implemented as the primary controller in smaller OT system configurations to provide operational control of discrete processes (e.g., automobile assembly lines, process controllers). These topologies differ from SCADA and DCS in that they generally lack a central control server or HMI and, therefore, primarily provide closed-loop control with minimal human involvement. PLCs have a user-programmable memory for storing instructions for the purpose of implementing specific functions, such as I/O control, logic, timing, counting, three mode proportional-integral-derivative (PID) control, communications, arithmetic, and data and file processing. Figure 8 shows a PLC over a fieldbus network performing the control of a manufacturing process. The PLC is accessible via a programming interface located on an engineering workstation, and data is stored in a data historian, all of which are connected on a LAN.

Fig. 8. A PLC control system implementation example

A building automation system (BAS) is a type of OT used to control the many systems used in a building, including heating, ventilation, and air conditioning (HVAC); fire; electrical; lighting; physical access control; physical security; and other utility systems. Most modern buildings contain some form of a BAS when they are constructed. However, older buildings and equipment may have to be retrofitted to take advantage of the benefits that a BAS provides.

Some of the most common functions of a BAS include maintaining environmental conditions for occupant comfort, reducing energy consumption, reducing operating and maintenance costs, increasing security, recording historical data (e.g., temperature, humidity), and performing general equipment monitoring (e.g., provide alerts to building personnel of device failure or an alarm condition).

An example of a BAS is shown in Fig. 9. A BAS may communicate over wired or wireless paths to controllers or gateways. For example, environmental control sensors can provide the temperature and humidity to a building controller. If the sensor values are outside of the set points, the controller can signal a variable air volume (VAV) box to increase or decrease airflow and bring the temperature to the desired state. Similarly, a building occupant scanning their identification badge at a badge reader can result in the credentials being sent to the access control controller and application control server to determine whether access should be granted.

While this guide contains recommendations that are applicable and could be used as a reference to protect a BAS against cybersecurity threats, readers are encouraged to perform a risk-based assessment on their systems and tailor the recommended guidelines and solutions to meet their specific security, business, and operational requirements.

Fig. 9. A BAS implementation example

A physical access control system (PACS) is a type of physical security system designed to control access to an area. Unlike standard physical barriers, physical access control can control who is granted access, when the access is granted, and how long the access should last. An access point is the entrance or barrier where access control is required. Some common physical access control examples of access points are doors and locks, security gates, turnstiles, and vehicular gate arms. Depending on the type of facility, there can be a single access point (e.g., for high-security areas) or many (e.g., for a large office building). An identification (ID) or personal credential is used to identify the authorized user trying to gain access to the area or facility. A PACS often requires a user to have credentials to gain entrance to a facility or access sensitive data. Examples of identification credentials include simple controls (e.g., PIN codes, passwords, key fobs, key cards) and more advanced credentials (e.g., encrypted badges, mobile credentials). Identification credentials allow the system to know who is attempting to gain access and to maintain access logs. Readers and/or keypads are typically located at the access point. The reader reads the data and sends it to a door controller to validate the credential and determine whether access should be authorized. If a keypad or biometric reader is also required (i.e., for multi-factor authentication), the user will enter their PIN or perform the biometric scan following their credential scan. An example of a PACS is shown in Fig. 10.

Fig. 10. A PACS implementation example

In this example, the door controller receives credential data from the reader and verifies the identification credential. If the credential is approved by the access control server, the control panel transmits the command to authorize access and unlock the door. If the credential is denied, the door will remain locked, and the user will not be able to gain entry. All access attempts are logged by the door controller(s) and, ultimately, the access control server. The access control server is the repository for user information, access privileges, and audit logs. Depending on the system, the server might be on-premises or managed in the cloud.

While this guide contains recommendations that are applicable and could be used as a reference to protect a PACS against cybersecurity threats, readers are encouraged to perform a risk-based assessment on their systems and tailor the recommended guidelines and solutions to meet their specific security, business, and operational requirements.

Many of the physical processes that OT systems control have the potential to create hazardous situations to human life and safety, property, and the environment. Safety systems are designed to reduce the likelihood and/or consequence of these potentially hazardous situations by bringing the system to a safe state. There are several types of safety systems related to OT environments, including emergency shut down (ESD), process safety shutdown (PSS), and fire and gas systems (FGS).

One of the more well-known types of safety system is the safety instrumented system (SIS), which is composed of one or more safety instrumented functions (SIFs). An SIF is an engineered system that is typically comprised of sensors, logic solvers, and final control elements (e.g., actuators) whose purpose is to bring a system to a safe state when predetermined thresholds are violated. An SIS is implemented as part of an overall risk reduction strategy to reduce the likelihood and/or potential consequences of a previously identified event so that it is within the organization’s risk tolerance. Although numerous other terms are associated with safety systems, the SIS is specifically designed in accordance with [IEC61511]. An SIS is typically found in chemical, refinery, and nuclear processes.

An SIS is often independent from all other control systems in such a manner that a failure of the basic process control system (BPCS) will not impact SIS functionality in a deleterious manner. Historically, an SIS was designed to be stand-alone, physically and logically separated, and air-gapped from the rest of the control system. In the configuration shown in Fig. 11, the SIS and BPCS operate completely independent of each other with no direct communication between the systems. However, some modern SISs have been designed to allow communication with the control system. These types of SISs are called Integrated Control and Safety Systems (ICSSs). An ICSS solution may be an all-in-one device from a single vendor or incorporate multiple devices from multiple vendors. While an ICSS combines the functionality of both control and safety systems, the SIS must still comply with the requirements outlined in [IEC61511]. One of the advantages to this ICSS methodology is the ability to communicate information from the SIS to the BPCS.

While this guide contains recommendations that are applicable and could be used as a reference to protect safety systems against cybersecurity threats, readers are encouraged to perform a risk-based assessment on their systems and tailor the recommended guidelines and solutions to meet their specific security, business, and operational requirements.

Fig. 11. An SIS implementation example

The Industrial Internet of Things (IIoT) consists of sensors, instruments, machines, and other devices that are networked together and use internet connectivity to enhance industrial and manufacturing business processes and applications [Berge]. As IT and OT systems continue to converge and become even more interconnected, the control of physical processes remains a relatively unique and critical concept of OT.

The Industry IoT Consortium proposes a three-tier system architecture model for representing IIoT systems [IIRA19]: the edge tier, platform tier, and enterprise tier. Each tier plays a specific role in processing the data flows and control flows involved in usage activities. The tiers are connected by three networks: the proximity network, access network, and service network. An example architecture is shown in Fig. 12.

The enterprise tier implements domain-specific applications and decision support systems, provides interfaces to end users, receives data flows from the other tiers, and issues control commands to the other tiers.

The platform tier receives, processes, and forwards control commands from the enterprise tier to the edge tier. It consolidates processes and analyzes data flows from the other tiers, provides management functions for devices and assets, and offers non-domain-specific services, such as data query and analytics. Based on the specific implementation, these functions can be implemented on the IIoT platform that is deployed in an on-site data center, an off-site data center, or in the cloud.

The service network enables connectivity between the services in the platform tier, the enterprise tier, and the services within each tier. This connectivity may be an overlay private network over the public internet or the internet itself, allowing enterprise-grade security between end users and services.

The edge tier collects data from the edge nodes using the proximity network. The architectural characteristics of this tier vary depending on the specific implementation (e.g., geographical distribution, physical location, governance scope). It is a logical layer rather than a true physical division. From a business perspective, the location of the edge depends on the business objectives.

Fig. 12. A three-tiered IIoT system architecture

Edge computing is a decentralized computing infrastructure in which computing resources and application services can be distributed along the communication path between the data source and the cloud. It exists vertically within the full stack (i.e., from the device to the cloud) and horizontally across IIoT subsystems. The edge is not merely a way to collect data for transmission to the datacenter or cloud; it also processes, analyzes, and acts on data collected at the edge and is, therefore, essential for optimizing industrial data at every aspect of an operation.

The IIoT system architecture is fully distributed and can support a wide range of interactions and communication paradigms, including:

The proximity network connects edge nodes (e.g., sensors, actuators, devices, OT systems and assets) to the stack. It typically connects these edge nodes as one or more clusters to a gateway that bridges to other networks. The access network enables connectivity for data and control flow between the edge and platform tiers. This connection may be a corporate network or an overlay private network over the public internet or a 4G/5G network. While this guide contains recommendations that are applicable and could be used as a reference to protect IIoT against cybersecurity threats, readers are encouraged to perform a risk-based assessment on their systems and tailor the recommended guidelines and solutions to meet their specific security, business, and operational requirements.

OT has many characteristics that differ from traditional IT systems, including different risks and priorities. Some of these include significant risk to the health and safety of human lives, serious damage to the environment, and financial issues, such as production losses. OT has different performance and reliability requirements and uses OSs and applications that may be considered unconventional in a typical IT network environment. Security protections must be implemented in a way that maintains system integrity during normal operations as well as during cyber attacks [Knapp]. Initially, OT systems had little resemblance to IT systems because they were isolated and ran proprietary control protocols using specialized hardware and software. Widely available and low-cost Ethernet, Internet Protocol (IP), and wireless devices are now replacing older proprietary technologies, which increases the likelihood of cybersecurity vulnerabilities and incidents. OT are increasingly resembling IT systems as they adopt IT technologies to promote corporate connectivity and remote access capabilities (e.g., using industry standard computers, OSs, and network protocols). This integration supports new IT capabilities but provides significantly less isolation for OT from the outside world than predecessor systems, creating a greater need to secure them. 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 are needed that are tailored to the OT environment.

Some special considerations when securing OT include:

Table 1 summarizes some of the typical differences between IT and OT systems.

Table 1. Summary of typical differences between IT and OT systems

In summary, the operational and risk differences between IT and OT systems create the need for increased sophistication in applying cybersecurity and operational strategies. A cross-functional team of control engineers, control system operators, and IT security professionals must work closely to understand the possible implications of the installation, operation, and maintenance of security solutions in conjunction with control system operation. IT professionals working with OT need to understand the reliability impacts of information security technologies before deployment. Moreover, some of the OSs and applications that run on OT may not operate correctly with commercial-off-the-shelf (COTS) IT cybersecurity solutions because of their unique requirements.

To mitigate cybersecurity risks to their OT systems, organizations need to develop and deploy an OT cybersecurity program. It should be consistent and integrated with existing IT cybersecurity programs and practices but also account for the specific requirements and characteristics of OT systems and environments. Organizations should regularly review and update their OT cybersecurity plans and programs to reflect changes in technologies, operations, standards, regulations, and the security needs of specific facilities. Effective integration of cybersecurity into the operation of OT requires defining and executing a comprehensive program that addresses all aspects of cybersecurity. This includes defining the objectives and scope of the program; establishing a cross-functional team that understands OT and cybersecurity; establishing policies and procedures; identifying cyber risk management capabilities that include people, processes, and technologies; and identifying day-to-day operations of event monitoring and auditing for compliance and improvement. When a new system is being designed and installed, it is imperative to take the time to address security throughout the life cycle, including architecture, procurement, installation, maintenance, and decommissioning. Deploying systems to the field based on the assumption that these systems will be secured later introduces significant risks to the systems and the organization. If there are not enough time and resources to properly secure the system before deployment, it is unlikely that security will be addressed at a later time. Since new OT systems are designed and deployed less frequently than IT systems, it is much more common to improve, expand, or update an existing OT system than to design a new one. This section introduces the basic process for developing an OT cybersecurity program and applies to new and deployed OT systems. Additional guidance for developing the specific elements of an OT cybersecurity program can be found in Section 3.3.10.

Senior management must demonstrate a clear commitment to cybersecurity and communicate its importance throughout the organization. Cybersecurity is a business responsibility shared by all members of the organization, especially by its leaders and IT and OT teams. Commitment to cybersecurity can be demonstrated by establishing a charter for a cybersecurity program with adequate funding, visibility, governance, and support from senior leaders. A cybersecurity program that has commitment from senior management is more likely to achieve the mission and business goals of the organization. A charter for a cybersecurity program is a plain-language high-level description that establishes clear ownership and accountability for protecting OT resources and provides a mandate for the most senior person responsible to establish and maintain the cybersecurity program (e.g., CISO). This section focuses on an OT-specific program, which should be integrated with the organization’s overall cybersecurity program. A cybersecurity program charter should include program objectives, scope, and responsibilities. Senior management establishes the OT cybersecurity program charter and identifies an OT cybersecurity manager with appropriate authority to lead the OT cybersecurity program. The OT cybersecurity manager should define the roles and responsibilities of system owners, mission and business process managers, and users. The OT cybersecurity manager should also document the objectives and scope of the OT security program, including the business organizations affected, the systems and networks involved, the budget and resources required, and the division of responsibilities. The organization may already have an information security program in place or have developed one for its IT systems. The OT cybersecurity manager should identify which existing practices to leverage and which practices are specific to the OT system. Ultimately, it will be more effective for the team to share resources with others in the organization that have similar objectives.

The cybersecurity of OT systems is a critical component in the overall security of the organization. Cybersecurity events could potentially impact the organization’s mission and objectives, the environment, regulatory compliance, and even human safety. OT systems can also be used as an entry point to organizational IT systems and other enterprise systems. As OT systems are increasingly being connected to IT networks, relying on traditional measures (e.g., air gaps) is not enough to protect such systems from cyber attacks. Therefore, security measures tailored to the OT system are required to protect the organization. An OT cybersecurity program considers the characteristics of OT systems that require special consideration in order to mitigate these risks.

OT cybersecurity supports the mission and business functions of the organization and provides additional benefits, including:

A strong OT cybersecurity program is fundamental to a sustainable business operation and can potentially enhance system reliability and availability. This includes minimizing unintentional OT system information security impacts from inappropriate testing, policies, and misconfigured systems. Cyber attacks can also have other significant impacts, such as:

Additional examples of the potential consequences of an OT incident are listed below. Note that items in this list are not independent. For example, the release of hazardous material could lead to injury or death.

Safety and security incidents can have negative impacts that last longer than other types of incidents on all stakeholders, including employees, shareholders, customers, and the communities in which an organization operates. Senior management should identify and evaluate the highest priority items to estimate the annual business impact (e.g., in financial terms).

A well-defined business case for an OT cybersecurity program is essential for management buy-in to ensure the long-term commitment of the organization and the allocation of resources needed for the development, implementation, and maintenance of the program. The first step in developing an OT security program is to identify the organization’s business objectives and missions, as well as how the cybersecurity program can lower risk and protect the organization’s ability to perform those objectives and missions. The business case should capture the business concerns of senior management and provide the business impact and financial justification for creating an integrated organizational cybersecurity program. It should include detailed information about the following:

The costs and resources required to develop, implement, and maintain the security program should be considered. The economic benefits of the cybersecurity program may be evaluated in the same way that worker health and safety programs are. However, an attack on the OT system could have significant consequences that far exceed monetary costs.

Helpful resources can be found through information sharing exchanges, trade and standards organizations, consulting firms, and internal risk management programs or engineering and operations. External organizations can also provide useful tips as to what factors most strongly influenced management to support their efforts and what resources within their organizations proved most helpful. While these factors may vary across industries, there may be similarities in the roles that other risk management specialists can play. Appendix D lists some current activities in OT security.

Internal resources in related risk management efforts (e.g., information security, health, safety and environmental risk, physical security, business continuity) can provide tremendous assistance in prioritizing threats and estimating business impacts. These resources can also provide insight into which managers are focused on dealing with which risks and who may be the most appropriate or receptive to serving as a champion.

In order to be successful, the OT cybersecurity program must have active participation from senior management. Organization-level management in both IT and OT operations has the perspective to understand the risks as well as the authority to assume responsibility for them.

Senior management will be responsible for approving and driving information security policies, assigning security roles and responsibilities, and implementing the information security program across the organization. Funding for the entire program can usually be done in phases. While some funding may be required to start the program, additional funding can be obtained later as the security vulnerabilities and needs of the program are better understood and additional strategies are developed. Additionally, costs should be considered for retrofitting the OT for security versus addressing security to begin with.

Often, a good approach to obtaining management buy-in is to base the business case on a successful example of another organization that had a similar problem and how they solved it. This will often prompt management to ask how that solution might be applicable to their organization.

When presenting the business case to leadership, it may also be helpful to mention the specific challenges in securing the OT systems:

This section provides recommendations for establishing, implementing, maintaining, and continually improving an OT cybersecurity program. These recommendations are independent, which allows the organization to select the approaches and technologies that are most suitable to its needs.

An OT cybersecurity program is typically tailored to a specific OT environment. An organization may have multiple sites, each with multiple specific OT environments. In such situations, an organizational-level OT security program should be defined with recommendations that cascade down and adapt to the needs of individual sites and OT environments.

The effectiveness of an OT cybersecurity program is often enhanced through coordination or integration with the organization’s processes and information security program. However, information security programs typically focus on the confidentiality, integrity, and availability – in that order – of information for the entire organization. Information security programs do not necessarily address all of the specific security and operational needs of an OT environment, which instead prioritizes safety, followed by availability, integrity, and confidentiality. This difference in focus and priorities between IT and OT security programs should be kept in mind. NIST SP 800-100, Information Security Handbook: A Guide for Managers [SP800-100], provides a broad overview of information security program elements to assist in establishing and implementing an information security program in an organization.

The lifespan of an OT system can exceed 20 years. As a result, many legacy systems may contain hardware and software that are no longer supported by vendors and cannot be patched or updated to protect against new vulnerabilities. In that case, the security program should be tailored to the unique characteristics of the legacy system to determine whether the controls are applicable. When security controls are not supported by the legacy OT system, compensating controls should be considered. For example, anti-malware software may not be available for systems such as PLCs and DCS, which means that malware protection requirements cannot be applied to these endpoints. In this case, a compensating control should be considered, such as using a firewall with a deep packet inspection capability that can monitor and block advanced threats like malware.

The primary purpose of investing in a cybersecurity program is risk management. Risk to operations exists because of the potential of threat actors exploiting the vulnerabilities in the applications and infrastructures. Therefore, the most appropriate decision regarding what to include in the scope of a cybersecurity program can be made if investments are viewed through the lens of corporate risk management. To help design and drive a cybersecurity program with a risk management perspective, NIST SP 800-37, Rev. 2 [SP800-37r2] describes the Risk Management Framework, which defines the core tasks and processes for implementing a cybersecurity program. This is briefly summarized in Section 3.3.6 and further elaborated in Section 4.

The OT cybersecurity program should also address policy exceptions and deviations. In a demanding OT environment, situations may arise that require a temporary deviation from the security policy in order to maintain the mission or goal of the OT system. Such deviations or exceptions must be handled with great care and receive approval from management and the cross-functional team. The security program can establish a policy and procedure for handling these policy exceptions. All of these guidance documents recognize that one size does not fit all. Rather, domain knowledge combined with site-specific constraints should be applied in adapting this guidance to a specific organization.

OT governance should include the policies, procedures, and processes for managing the organization’s regulatory, legal, risk, environmental, and operational requirements. The governance should ensure that the policies, procedures, and processes are well understood by staff and inform the management of OT cybersecurity risk. To establish an effective OT cybersecurity governance capability, develop a process and assign responsibilities and accountability to appropriate roles in the corporate risk management function. Typically, a cybersecurity governance process should include the following:

Further guidance for establishing OT cybersecurity guidance can be found in Section 6. Additional information with specific examples for establishing a cybersecurity governance capability are also provided in NIST Internal or Interagency Report (NIST IR) 8183A, Cybersecurity Framework Manufacturing Profile Low Impact Level Example Implementations Guide [IR8183A].

It is essential for a cross-functional cybersecurity team to share their varied domain knowledge and experience to evaluate and manage risk in OT. The OT cybersecurity team should consist of representatives from the following departments: IT staff, control engineer, control system operator, security subject-matter expert, and enterprise risk management. For completeness, the information security team should also include any cybersecurity service providers.

From a safety perspective, major accident hazards and the loss of containment due to equipment failure or operator mistakes can have serious consequences. Cybersecurity is another threat to the safety and reliability of industrial processes, so including safety experts as part of the cybersecurity team will be beneficial in identifying potential impact areas due to cyber vulnerabilities. Their insight into OT design and safety considerations will also help in formulating cyber mitigations.

While the control engineers will play a large role in securing OT, they will not be able to do so without collaboration and support from both the IT department and management. IT often has years of cybersecurity experience, much of which is applicable to OT. As the cultures of control engineering and IT are often significantly different, their integration will be essential for the development of a collaborative security design and operation.

Organizations come in various sizes, structures, geographical spreads, and complexities. These factors and the strategies related to resources and budget constraints may drive organizations to hire OT cybersecurity resources as employees or contractors or outsource the OT security operation function as a managed security service. Irrespective of the security operation and resource model used, the responsibility for OT cybersecurity management should be integrated with IT cybersecurity and the corporate risk management function.

The responsibility and accountability for implementing and managing cybersecurity functions typically falls under the IT and OT infrastructure organization, whereas cybersecurity operational metrics and risks are reported to the risk management office. These two lines of reporting structure need to collaborate in terms of funding and expectations of what can be achieved given a funding and resource level. The risk executive function works with executive management to decide the risk tolerance and residual risk.

As part of building a cybersecurity team, the following tasks should be included:

Further guidance for establishing a cross-functional team can be found in Section 4 and Appendix D. Additional information with specific examples for establishing a cross-functional team are also provided in NIST IR 8183A, Cybersecurity Framework Manufacturing Profile Low Impact Level Example Implementations Guide [IR8183A].

An organization-wide risk management strategy is foundational to developing an OT cybersecurity strategy.⁴ The OT cybersecurity strategy leverages the organization-wide risk management strategy – including organization-defined risk tolerance, threats, assumptions, constraints, priorities, and trade-offs – to further tailor the strategy to apply to the OT cybersecurity program.

The OT cybersecurity strategy:

The OT cybersecurity strategy should help refine the organizational risk tolerance for the OT operation, which in turn drives the priorities for the OT cybersecurity operation. The program should also address both IT and OT concerns and requirements. For example, IT may consider data loss or system availability as a higher priority, but OT may value system safety, production efficiency, and environmental damage as higher priorities. Further guidance for developing an OT cybersecurity strategy can be found in Section 5, Section 6, Appendix C, and Appendix D. Additional information and specific examples for establishing an OT cybersecurity strategy are also provided in NIST IR 8183A, Cybersecurity Framework Manufacturing Profile Low Impact Level Example Implementations Guide [IR8183A].

Policies and procedures are essential to the success of any cybersecurity program. Where possible, OT-specific security policies and procedures should be derived from existing IT cybersecurity and plant operational policies and procedures for consistency throughout the organization. As discussed earlier, organizational management is responsible for developing and communicating the risk tolerance level of the organization (i.e., the level of risk that the organization is willing to accept), which allows the OT cybersecurity manager to determine the risk management strategy. The development of cybersecurity policies should be based on a risk assessment that will set the security priorities and goals for the organization. Procedures that support the policies need to be developed so that the policies are implemented fully and properly for OT. Cybersecurity procedures should be documented, tested, and updated periodically in response to policy, technology, and threat changes. Further guidance for developing OT-specific policies and procedures can be found in Section 6. Additional information with examples for establishing OT-specific policies and procedures are also provided in NIST IR 8183A, Cybersecurity Framework Manufacturing Profile Low Impact Level Example Implementations Guide [IR8183A].

Organizations should ensure that all personnel who interact with OT systems – including employees, contractors, consultants, and vendors – receive cybersecurity training that is relevant to the OT environment in addition to general IT cybersecurity awareness training. This training is used to inform personnel of basic cybersecurity principles, teach them about their potential impacts on security and safety, and outline the steps that they need to follow when interacting with OT systems. Cybersecurity awareness training should be required for new employees at the time of hire and at regular intervals, as dictated by regulatory requirements and organizational policies.

Further guidance for OT cybersecurity awareness training can be found in Section 6 and Appendix D. Additional information with specific examples for OT cybersecurity awareness training are also provided in NIST IR 8183A, Cybersecurity Framework Manufacturing Profile Low Impact Level Example Implementations Guide [IR8183A].

OT system risk is another risk confronting an organization (e.g., financial, safety, environmental, IT). In each case, managers responsible for the mission or business function establish and operate a risk management program in coordination with senior management. NIST SP 800-39, Managing Information Security Risk: Organization, Mission, and Information System View [SP800-39], provides a framework for an enterprise-level risk management program, which is also detailed in Section 4 of this document. OT personnel should be involved in developing the OT cybersecurity risk management program and communicating with senior management.

NIST SP 800-37, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy [SP800-37r2], provides a structured process for managing security and privacy risk. This includes preparing for organization-wide risk management; system categorization; control selection, implementation, and assessment; system and common control authorizations; and continuous monitoring.

Applying the Risk Management Framework (RMF) to OT systems is detailed in Section 4.

Establish processes and implement tools to ensure that routine and preventative maintenance and repairs (both local and remote) of OT assets are performed consistent with OT organizational policies and procedures. The tools used for maintenance logging and tracking should be controlled and managed. Ensure that the processes and tools allow for scheduling, authorizing, tracking, monitoring, and auditing maintenance and repair activities for OT assets. If the ability for remote maintenance is required, ensure that the remote access tool supports the authentication of maintenance personnel, connection establishment at the beginning of maintenance activities, and immediate teardown once the maintenance activities are performed. Also ensure that the tool can log the remote maintenance activities that are performed.

Further guidance for OT maintenance tracking can be found in Section 6. Additional information with specific examples for OT maintenance tracking are also provided in NIST IR 8183A, Cybersecurity Framework Manufacturing Profile Low Impact Level Example Implementations Guide [IR8183A].

Organizations should establish an OT cybersecurity incident response (IR) function that should include planning, detection, analysis, containment, and reporting activities in the case of a cybersecurity incident. The IR function requires the establishment of several cybersecurity capabilities, including incident management, forensic analysis, vulnerability management, and response communication. As part of building the IR function, the OT cybersecurity department should create an incident response plan. The purpose of the incident response capability is to determine the scope and risk of cybersecurity incidents, respond appropriately to the incident, communicate the incident to all stakeholders, and reduce the future impact. This plan applies to all OT personnel, networks, systems, and data. The IR plan guides the activities of the cybersecurity team to respond, communicate, and coordinate in the event of a cybersecurity incident. Without such a plan, the organization will find it extremely difficult to respond when a cybersecurity incident occurs. The plan includes the roles and responsibilities of personnel, the incident response workflow, incident type and severity classification, contacts of critical personnel who should be involved, contacts of external entities that may be useful in assisting with IR, information sharing policy, and internal and external communication. Further guidance for OT incident response can be found in Section 6.2.4.5 and Appendix C. Additional information with specific examples for OT incident response are also provided in NIST IR 8183A, Cybersecurity Framework Manufacturing Profile Low Impact Level Example Implementations Guide [IR8183A].

The organization should establish the capability to recover from cybersecurity incidents and to restore the assets and services that were impaired by the cybersecurity incident to a pre-cyber-incident state. This capability typically includes the following tasks:

Further guidance for OT recovery and restoration can be found in Section 6. Additional information with specific examples for OT recovery and restoration are also provided in NIST IR 8183A, Cybersecurity Framework Manufacturing Profile Low Impact Level Example Implementations Guide [IR8183A].

This section presented the elements of a cybersecurity program and the various considerations for establishing such a program. Further guidance can be found in the document sections listed in Table 2.

Table 2. Sections with additional guidance for establishing a cybersecurity program

Organizations manage risks every day when meeting their business objectives, including financial losses, equipment failure, and personnel safety. Organizations develop processes to evaluate the risks associated with their business and to decide how to manage those risks based on organizational priorities, risk tolerance, and internal and external constraints. This risk management is an interactive ongoing process that is part of normal operations. Organizations that use OT systems have historically managed risk through good practices in safety and engineering. Safety assessments are well established in most sectors and often incorporated into regulatory requirements. Information security risk management is an added dimension that can be complementary. The risk management process and framework outlined in this section can be applied to managing safety, information security, and cyber supply chain risk. Privacy is also a risk consideration for some OT systems. For additional guidance on privacy risk management, refer to the NIST Risk Management Framework [SP800-37r2] and the Privacy Framework [PF].

A risk management process is deployed throughout an organization using a three-level approach to address risk at the (i) organization level, (ii) mission and business process level, and (iii) system level (i.e., IT and OT). The risk management process is carried out seamlessly across the three levels with the overall objective of continuous improvement in the organization’s risk-related activities and effective inter-tier and intra-tier communication among all stakeholders with a shared interest in the success of the organization.

This section focuses primarily on OT system considerations at the system level, though the risk management activities, information, and artifacts at each level impact and inform the other levels. Section 6 applies the Cybersecurity Framework to OT systems, while Appendix F provides OT-specific recommendations to augment the NIST SP 800-53, Rev. 5 [SP800-53r5] control families. This section also discusses OT system considerations and the impact that these considerations have on the risk management process.

For more information on multi-tiered risk management and the risk management process, refer to NIST SP 800-39, Managing Information Security Risk: Organization, Mission, and Information System View [SP800-39]. NIST SP 800-37, Rev. 2, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy [SP800-37r2], provides guidelines for applying the Risk Management Framework to federal information systems, including conducting the activities of security categorization,⁵ security control selection and implementation, security control assessment, information system authorization,⁶ and security control monitoring. NIST SP 800-30, Guide for Conducting Risk Assessments [SP800-30r1], provides a step-by-step process for organizations on how to (i) prepare for risk assessments, (ii) conduct risk assessments, (iii) communicate risk assessment results to key organizational personnel, and (iv) maintain the risk assessments over time.

While the risk management process presented in NIST SP 800-39 [SP800-39] applies to all types of systems, there are some unique aspects to consider when it comes to managing OT system security risk. As shown in Fig. 13, the risk management process has four components: framing risk (i.e., establishing the context for risk-based decisions), assessing risk, responding to risk, and monitoring risk. These activities are interdependent and often occur simultaneously within an organization. For example, the results of the monitoring component will feed into the framing component. Because the environment in which organizations operate is always changing, risk management must be a continuous process in which all components have ongoing activities. It is important to remember that these components apply to the management of any type of risk, including cybersecurity, physical security, safety, and financial. Sections 4.1.1 through 4.1.4 discuss the four components of the risk management process in further detail and provide OT-specific implementation guidance.

ASSESS

FRAME

RESPOND

MONITOR

Fig. 13. Risk management process: Frame, assess, respond, and monitor

Organization-wide risk management is applied at three levels, as Fig. 14 depicts. Level 1 addresses risk management from the organizational perspective and implements risk framing by providing context for all risk management activities within the organization. Level 2 addresses risk from a mission and business process perspective and is informed by the Level 1 risk context, decisions, and activities. Level 3 addresses risk at the system level and is informed by the Level 1 and 2 activities and outputs.

Strategic Focus

Level 1 Organization

Tactical

Level 2

Focus

Mission / Business Process

Level 3 System (Environment of Operation)

More detailed and granular risk perspective

Fig. 14. Risk management levels: Organization, mission and business process, and system

Together, each of the risk management components (i.e., frame, assess, respond, and monitor) are applied across the risk management levels, resulting in organization-wide risk awareness and the traceability and transparency of risk-based decisions.

The framing component consists of the processes for establishing the required assumptions, constraints, risk tolerances, and risk management strategies for organizations to make consistent risk management decisions. Specifically, risk framing supports the overall risk management strategy by incorporating elements from the organizational governance structure, legal/regulatory environment, and other factors to establish how the organization intends to assess, respond to, and monitor risk to all IT and OT systems.

For OT system operators, safety directly affects decisions on how systems are engineered and operated. Safety can be defined as “freedom from conditions that can cause death, injury, occupational illness, damage to or loss of equipment or property, or damage to the environment.”⁷ Based on this, human safety impacts are typically evaluated based on the degree of injury, disease, or death that could result from the OT system malfunctioning after a cyber incident, taking into consideration any previously performed safety impact assessments regarding the employees and the public. The importance of safety and developing a safety culture plays a critical role in determining risk tolerance.

Organizations should consider incorporating an analysis of cybersecurity effects on OT systems that impact personnel safety and the environment, as well as mitigating controls. More specifically, organizations may want to consider employing a comprehensive process to systematically predict or identify the operational behavior of each safety-critical failure condition, fault condition, or human error that could lead to a hazard or potential human harm.

Organizations may also want to consider the impact of legacy systems and components on their environment. Specifically, legacy systems may be unable to adequately support cybersecurity to prevent risks from exceeding organizational tolerance levels.

Another major concern for OT system operators is the availability of services provided by the OT system. The OT system may be part of critical infrastructure (e.g., water or power systems), where there is a significant need for continuous and reliable operations. As a result, OT systems may have strict requirements for availability or recovery. Organizations should understand and plan for the levels of redundancy required to achieve the desired resilience for their operating environments and incorporate these requirements into their risk framing. This will help organizations make risk decisions that avoid unintended consequences on those who depend on the services provided. More specifically, organizations should consider identifying interdependent OT systems that pose cybersecurity risks that threaten system availability.

Additionally, organizations should consider how an incident could propagate to a connected system and system components. An OT may be interconnected with other systems, such that failures in one system or process can easily cascade to other systems either within or outside of the organization. Impact propagation could occur due to both physical and logical dependencies. Properly communicating the results of risk assessments to the operators of connected or interdependent systems and processes is one way to manage such impacts.

Logical damage to an interconnected OT could occur if the cyber incident propagates to connected OT systems. For example, a virus or worm may propagate to a connected OT and impact that system. Physical damage could also propagate to other interconnected OT or related physical domains. For example, the impact could result in a physical hazard that degrades nearby physical environments or common shared dependencies (e.g., power supply) or result in a shortage of material that will be needed for a later stage in an industrial process.

CISA promotes a cohesive effort between government and industry to improve their ability to anticipate, prioritize, and manage national-level OT risk. CISA assists OT system vendors and asset owners, operators, and other vendors across all critical infrastructure sectors to identify security vulnerabilities and develop sound, proactive mitigation strategies that strengthen their OT systems’ cybersecurity posture.

Organizations may want to consider incorporating resources such as the NIST National Vulnerability Database (NVD) and the MITRE ATT&CK for Industrial Control Systems (ICS) framework [ATTACK-ICS] into their processes for assessing risks to the mission and OT systems. Additionally, the nature of OT systems requires organizations to consider additional factors that may not exist when conducting risk assessment for a traditional IT system. For example, OT will have different threat sources, vulnerabilities, and compensating controls than IT. The impact of a cyber incident in an OT environment may include both physical and digital effects that risk assessments need to incorporate, including:

During risk framing, organizations should select appropriate risk assessment methodologies that include OT. When evaluating the potential physical damage from a cyber incident, organizations with OT systems may consider i) how a cyber incident could manipulate the operation to impact the physical environment, ii) what design features exist in the OT system to prevent or mitigate an impact, and iii) how a physical incident could emerge based on these conditions.

When framing risks within an OT environment, organizations may discover that cybersecurity threats are not always as well understood or predictable as OT hazards. Organizations may consider incorporating cyber attack and IT failure scenarios into their process hazard analysis (PHA) or failure mode and effects analysis (FMEA) processes. By including risks due to cyber attacks and cyber risk management measures in these processes, organizations may gain a better understanding of the cyber risks to the OT operational environment.

As part of risk framing, organizations may also need to consider:

In the context of OT, the potential for damage to equipment, human safety, the natural environment, and other critical infrastructures is part of these considerations. Organizations may need to consider evaluating the potential physical impacts for all parts of an OT system. Organizations may also need to determine how OT systems interact or depend on IT to support risk framing. These processes may require organizations to identify a common framework for evaluating impacts that incorporate OT considerations. One approach is based on NIST FIPS 199 [FIPS199], which specifies that systems are categorized as low impact, moderate impact, or high impact for the security objectives of confidentiality, integrity, and availability. Another approach that is based on ISA 62443-3-2 [ISA62443] provides example definitions for determining a system categorization utilizing OT impacts.

原本PDFの抜粋画像

Table 3 provides possible example categories and impact levels that organizations may customize to meet their specific industry or business requirements. For example, some organizations may see an outage lasting up to one day as a having a high impact instead of moderate, as shown in the table.

Table 3. Possible definitions for OT impact levels based on the product produced, the industry, and security concerns

To support the risk assessment process, organizations should also define how the likelihood of occurrence for cybersecurity events will be determined to maintain consistency when assessing risks. NIST SP 800-30, Rev. 1 [SP800-30r1] provides guidance for organizations to develop likelihood weighted risk factors. Organizations should consider weighting risk factors based on an analysis of the probability that a given threat is capable of exploiting a given vulnerability (or set of vulnerabilities), that the threat event will be initiated, and that the threat event will result in adverse impacts. For adversarial threats, an assessment of likelihood of occurrence is typically based on adversary intent, capability, and targeting. For other-than-adversarial threat events, the likelihood of occurrence is estimated using historical evidence, empirical data, and other factors. If organizations find that there is minimal organizational historical data, they may want to consider extending their analysis to consider industry-specific data describes cybersecurity events reported for similar organizations. The likelihood of threat occurrence can also be based on the state of the organization (e.g., its core mission and business processes, enterprise architecture, information security architecture, information systems, and the environments in which those systems operate) and consider predisposing conditions and the presence and effectiveness of deployed security controls to protect against unauthorized or undesirable behavior, detect and limit damage, and/or other resiliency factors for the OT capabilities.

Organizations that establish definitions for event likelihood may want to review Appendix G of NIST SP 800-30, Rev. 1 for more detailed guidance and suggestions. Based on this guidance, organizations should consider defining five levels of likelihood from Very Low to Very High based on both adversarial (i.e., intentional threat actors) and non-adversarial (e.g., errors, accidents, acts of nature, etc.) events. Additionally, organizations may want to establish definitions for the likelihood that an event may result in an adverse impact. Using these two factors, organizations can establish a heat map like the one depicted in Table 4 to determine the likelihood factor for supporting the risk analysis.

Table 4. Event Likelihood Evaluation

Risk assessments leverage the outputs of framing risk (e.g., acceptable risk assessment methodologies, risk management strategy, and risk tolerance) and facilitate efforts to identify, estimate, and prioritize risks to operations, assets, individuals, and other organizations. Risk assessments occur at all risk management levels (i.e., organization, mission and business function, and system) and can be used to inform risk assessments at other levels. Regardless of which risk management level the risk assessment is conducted at, assessing risk requires identifying threats and vulnerabilities, the harm that such threats and vulnerabilities may cause, and the likelihood that adverse events may arise from those threats and vulnerabilities.

When the organization conducts a risk assessment that includes OT systems, there may be additional considerations that do not exist when assessing the risks of traditional IT systems. For example, the impact of a cyber incident on an OT may include both physical and digital effects.

Risk assessments are typically point-in-time reports. As a result, organizations should ensure that they are updated to remain current and that the security level remains adequate.

Organizations may want to review the information provided by CISA’s Alerts and Advisories, NIST’s NVD, and MITRE ATT&CK for ICS to identify common vulnerability areas for OT environments, such as:

OT systems often have specific environmental requirements (e.g., a manufacturing process may require a precise temperature), or they may be tied to their physical environment for operations. Organizations may want to consider incorporating these requirements and constraints into the framing component so that associated risks are identified. Additionally, organizations may want to consider:

原本PDFの抜粋画像

Risk assessments also require reviewing the digital and non-digital mechanisms that are implemented to minimize adverse event impacts. OT systems often incorporate non-digital mechanisms to provide fault tolerance and prevent the OT from acting outside of acceptable parameters. These non-digital mechanisms may help reduce the negative impacts that a digital incident on the OT might have and should be incorporated into the risk assessment process. For example, OT often have non-digital control mechanisms that can prevent it from operating outside of a safe boundary and thereby limit the impact of an attack (e.g., a mechanical relief pressure valve). Analog mechanisms (e.g., meters, alarms) can also be used to observe the physical system state and provide operators with reliable data if digital readings are unavailable or corrupted. Table 5 categorizes non-digital control mechanisms that could reduce the impact of an OT incident.

Table 5. Categories of non-digital OT control components

Organizations should analyze all digital and non-digital control mechanisms and the extent to which they can mitigate potential negative impacts to the OT. For example, non-digital control mechanisms may require additional time and human involvement, such as operators travelling to a remote site to perform certain control functions. Such mechanisms may also depend on human response times, which may be slower than automated controls.

Additionally, organizations may need to consider privacy with their risk assessment, which sometimes require a different approach. The NIST Privacy Risk Assessment Methodology (PRAM) is a tool that applies the risk model from NIST IR 8062 [IR8062] and helps organizations analyze, assess, and prioritize privacy risks to determine how to respond and select appropriate solutions.

The risk response component provides an organization-wide response to risk in accordance with the risk framing component by identifying possible courses of actions to address risk, evaluating those possibilities while considering the organization’s risk tolerance and other issues identified during framing, and choosing the best alternative for the organization. The response component includes the implementation of the chosen course of action to address the identified risk: acceptance, avoidance, mitigation, sharing, transfer, or any combination of these options.⁸

For an OT system, available risk responses may be constrained by system requirements, potential adverse impacts on operations, or even regulatory compliance regimes. An example of risk sharing is when utilities enter into agreements to “loan” line workers in an emergency, which reduces the duration of an incident’s effect to acceptable levels.

Monitoring risk is the fourth component of risk management activities. Organizations monitor risk on an ongoing basis, including the implementation of chosen risk management strategies, changes in the environment that may affect the risk calculation, and the effectiveness and efficiency of risk reduction activities. The activities in the monitoring component impact all of the other components.

Many OT system monitoring capabilities leverage passive monitoring techniques to detect system changes. However, this may not always capture all modifications to the system. Modern monitoring platforms that leverage native protocol communications to access more system information may improve awareness, but the limitations of these OT systems must be understood. Often OT systems are implemented with an undefined frequency for monitoring cyber activities. Users should set a frequency in accordance with the respective risk profile.

Threat information as it relates to the OT environment is evolving, and the availability and accuracy of this threat information is early in its development. By their nature, threats may be difficult to accurately predict, even with historical data. Organizations should categorize threats based on the likelihood of occurrence and their potential consequences. For example, the threat of an internet-connected system being scanned would have a high likelihood and a low severity consequence, but the threat of a nation-state actor disrupting a supply chain may have low likelihood and high severity consequences.

Since security countermeasures are typically developed for IT environments, organizations should consider how deploying security technologies into OT environments may negatively impact operations or safety.

Supply chain risk management and risk management for safety are critical aspects of OT cybersecurity risk management.

Cybersecurity risks can arise from the products or services acquired to support OT needs. These risks can be introduced anywhere in the supply chain and at any stage in the life cycle. Whether they are malicious, natural, or unintentional, these risks have the potential to compromise the availability and integrity of critical OT systems and components, as well as the availability, integrity, and confidentiality of the data utilized by the OT, thereby causing harms that range from minor disruptions to impacts on life and safety. With few exceptions, organizations that are responsible for OT rely upon suppliers, other third-party providers, and their extended supply chains for a range of needs. These supply-side organizations perform critical roles and functions, including manufacturing and provisioning technology products, providing software upgrades and patches, performing integration services, or otherwise supporting the day-to-day operations and maintenance of OT systems, components, and operational environments. For this reason, OT organizations should seek to understand and mitigate the supply chain-related risks that can be inherited from these supply-side organizations and the products and services that they provide. Identifying, assessing, and effectively responding to cybersecurity risks in supply chains is best accomplished by incorporating cybersecurity supply chain risk management (C-SCRM) considerations into organizational policies, plans, and practices. This includes extending cybersecurity expectations and requirements to vendors and gaining better understanding, visibility, and control over the supply chains that are associated with acquired products and services. Organizations should vet suppliers and service providers to ascertain their capabilities, trustworthiness, the adequacy of their internal security practices, the effectiveness of safeguards, their supply chain relationships, and any risks that may be associated with those relationships and dependencies. The requirements for and evaluation of products and discrete components should extend beyond an assessment of whether functional and technical requirements are satisfied and address applicable C-SCRM factors, such as a product’s provenance, pedigree, and composition and whether the product is taint-free and authentic. Additionally, special consideration should be given to how difficult it may be to attain original replacement parts or updates over the life of the product and how diverse the sources of supply are and may be in the future.

OT organizations should familiarize themselves with NIST SP 800-161, Supply Chain Risk Management Practices for Federal Information Systems and Organizations [SP800-161], and begin or continue to implement the key practices, C-SCRM security controls, and C-SCRM risk management process activities described in that publication. There is extensive guidance about how to establish a C-SCRM program using a phased approach that begins with putting the foundational elements in place and expanding upon that foundation over time to ensure sustained effectiveness and the ability to enhance program capabilities. There is also guidance about conducting supply chain risk assessments, incorporating C-SCRM into procurement requirements, the importance of an integrated and inter-disciplinary risk management approach, supplemental C-SCRM security control guidance, and templates that organizations can leverage.

The culture of safety and safety assessments is well established within much of the OT user community. Information security risk assessments should complement such assessments, though they may use different approaches and cover different areas. Safety assessments are primarily concerned with the physical world, while information security risk assessments consider the digital world. However, in an OT environment, the physical and the digital are intertwined, and significant overlap may occur. Organizations should, therefore, consider all aspects of risk management for safety (e.g., risk framing, risk tolerances) and the safety assessment results when carrying out risk assessments for information security. The personnel responsible for the information security risk assessment must be able to identify and communicate identified risks that could have safety implications. Conversely, the personnel charged with safety assessments must be familiar with the potential physical impacts and their likelihood. Safety systems may reduce the impact of a cyber incident on the OT and are often deployed to perform specific monitoring and control functions to ensure the safety of people, the environment, processes, and assets. While these systems are traditionally implemented to be fully redundant and independent from the primary OT, some architectures combine control and safety functions, components, or networks. Combining control and safety could allow a sophisticated attacker access to both control and safety systems if the OT were compromised. Organizations should ensure the adequate separation of components consistent with the risk of compromise and evaluate the impact of the implemented security controls on the safety system to determine whether they negatively impact the system.

The NIST Risk Management Framework (RMF) applies the risk management process and concepts (i.e., framing risk, assessing risk, responding to risk, and monitoring risk) to systems and organizations. The following subsections describe the process of applying the RMF to OT and include a brief description of each step and task, the intended outcome of each task, task mappings to other standards and guidelines applicable to OT (e.g., the Cybersecurity Framework and IEC 62443), and OT-specific implementation guidance. Some tasks are optional, and not all tasks include OT-specific considerations or guidance.

The RMF steps in Fig. 15, while shown sequentially, can be implemented in a different order to be consistent with established management and system development life cycle processes.

Fig. 15. Risk Management Framework steps

The purpose of the Prepare step is to carry out essential activities at the organizational, mission and business process, and system levels to help the organization manage its security and privacy risks using the RMF. The Prepare step leverages activities that are already being conducted within cybersecurity programs to emphasize the importance of having organization-wide governance and resources in place to support risk management. Table 6 provides details on applying the Prepare step to OT.

Table 6. Applying the RMF Prepare step to OT

In the Categorize step, the potential adverse impacts of the loss of confidentiality, integrity, and availability of the information and system are determined. For each information type and system under consideration, the three security objectives – confidentiality, integrity, and availability – are associated with one of three levels of potential impacts of a security breach. Of the three security objectives, availability is generally the greatest concern for an OT. The standards and guidance for this categorization process can be found in FIPS 199 [FIPS199] and NIST SP 800-60 [SP800-60v1r1][SP800-60v2r1], respectively.

The following OT example is taken from FIPS 199:

A power plant contains a SCADA system controlling the distribution of electric power for a large military installation. The SCADA system contains both real-time sensor data and routine administrative information. The management at the power plant determines that: (i) for the sensor data being acquired by the SCADA system, there is no potential impact from a loss of confidentiality, a high potential impact from a loss of integrity, and a high potential impact from a loss of availability; and (ii) for the administrative information being processed by the system, there is a low potential impact from a loss of confidentiality, a low potential impact from a loss of integrity, and a low potential impact from a loss of availability. The resulting security categories, SC, of these information types are expressed as:

SC sensor data = {(confidentiality, NA), (integrity, HIGH), (availability, HIGH)}, and

SC administrative information = {(confidentiality, LOW), (integrity, LOW), (availability, LOW)}.

The resulting security category of the system is initially expressed as:

SC SCADA system = {(confidentiality, LOW), (integrity, HIGH), (availability, HIGH)}

representing the high-water mark or maximum potential impact values for each security objective from the information types resident on the SCADA system. The management at the power plant chooses to increase the potential impact from a loss of confidentiality from low to moderate, reflecting a more realistic view of the potential impact on the system should there be a security breach due to the unauthorized disclosure of system-level information or processing functions. The final security category of the system is expressed as:

SC SCADA system = {(confidentiality, MODERATE), (integrity, HIGH), (availability, HIGH)}

Table 7 provides details on applying the RMF Categorize step to OT.

Table 7. Applying the RMF Categorize step to OT

The purpose of the Select step is to select the initial controls to protect the system commensurate with risk. The control baselines are the starting point for the control selection process and are chosen based on the security category and associated impact level of the systems identified in the Categorize step. NIST SP 800-53B [SP800-53B] identifies the recommended control baselines for federal systems and information. To address the need for developing community-wide and specialized sets of controls for systems and organizations, the concept of overlays is introduced. An overlay is a fully specified set of controls, control enhancements, and supplemental guidance derived from the application of tailoring guidance to security control baselines described in NIST SP 800-53B, Appendix C.

In general, overlays are intended to reduce the need for ad hoc tailoring of baselines by organizations through the selection of a set of controls and control enhancements that more closely correspond to common circumstances, situations, and/or conditions. Appendix F of this publication includes an OT-specific overlay of applicable NIST SP 800-53 controls that provides tailored baselines for low-impact, moderate-impact, and high-impact OT. These tailored baselines are starting specifications and recommendations that can be applied to specific OT by responsible personnel.

OT owners can tailor the overlay from Appendix F when it is not possible or feasible to implement specific controls. The use of overlays does not in any way preclude organizations from performing further tailoring (i.e., overlays can also be subject to tailoring) to reflect organization-specific needs, assumptions, or constraints. However, all tailoring activities should primarily focus on meeting the intent of the original controls whenever possible or feasible. For example, when the OT cannot support or the organization determines that it is not advisable to implement particular controls or control enhancements in an OT (e.g., performance, safety, or reliability are adversely impacted), the organization should provide a complete and convincing rationale for how the selected compensating controls provide an equivalent security capability or level of protection for the OT and why the related baseline controls could not be employed. If the OT cannot support the use of automated mechanisms, the organization employs nonautomated mechanisms or procedures as compensating controls in accordance with the general tailoring guidance in Section 3.3 of NIST SP 800-53. Compensating controls are not exceptions or waivers to the baseline controls. Rather, they are alternative safeguards and countermeasures employed within the OT that accomplish the intent of the original controls that could not be effectively employed. Organizational decisions on the use of compensating controls are documented in the security plan for the OT.

Table 8 provides additional details on applying the RMF Select step to OT.

Table 8. Applying the RMF Select step to OT

The Implement step involves the implementation of controls in new or legacy systems. The control selection process described in this section can be applied to OT from two perspectives: new development and legacy. For new development systems, the control selection process is applied from a requirements definition perspective since the systems do not yet exist and organizations are conducting initial security categorizations. The controls included in the security plans for the systems serve as security specifications and are expected to be incorporated into the systems during the development and implementation phases of the system development life cycle. In contrast, the security control selection process for legacy systems is applied from a gap analysis perspective when organizations anticipate significant changes to the systems (e.g., during major upgrades, modifications, or outsourcing). Since the systems already exist, organizations have likely completed the security categorization and security control selection processes, resulting in the establishment of previously agreed-upon controls in the respective security plans and the implementation of those controls within the systems. Table 9 provides additional details on applying the RMF Implement step to OT.

Table 9. Applying the RMF Implement step to OT

The Assess step of the RMF determines the extent to which the controls in the system are effective in their application and producing the desired results. NIST SP 800-53A [SP800-53Ar5] provides guidance for assessing selected controls from NIST SP 800-53 to ensure that they are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements of the system.

Table 10 provides additional details on applying the Assess step to OT.

Table 10. Applying the RMF Assess step to OT

The Authorize step involves a management decision to authorize the operation of a system and explicitly accept the risks to operations, assets, and individuals based on the implementation of an agreed-upon set of controls. A new system is not placed into production or operation until the system is authorized.

Table 11 provides additional details on applying the Authorize step to OT.

Table 11. Applying the RMF Authorize step to OT