{
	"id": "b7834244-ec84-4af9-80b8-8de1ff8094f5",
	"created_at": "2026-04-29T02:21:11.766174Z",
	"updated_at": "2026-04-29T08:23:00.322566Z",
	"deleted_at": null,
	"sha1_hash": "0442af7100d24be9d0e68f3263edc2be9e39b9be",
	"title": "Guide to Operational Technology (OT) Security",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "2023-09-26T15:39:23Z",
	"file_modification_date": "2023-10-05T14:12:23Z",
	"file_size": 8584345,
	"plain_text": "NIST Special Publication\r\nNIST SP 800-82r3\r\nGuide to Operational Technology\r\n(OT) Security\r\nKeith Stouffer\r\nMichael Pease\r\nCheeYee Tang\r\nTimothy Zimmerman\r\nVictoria Pillitteri\r\nSuzanne Lightman\r\nAdam Hahn\r\nStephanie Saravia\r\nAslam Sherule\r\nMichael Thompson\r\nThis publication is available free of charge from:\r\nhttps://doi.org/10.6028/NIST.SP.800-82r3\n\nNIST Special Publication\r\nNIST SP 800-82r3\r\nGuide to Operational Technology\r\n(OT) Security\r\nKeith Stouffer Victoria Pillitteri\r\nMichael Pease Suzanne Lightman\r\nCheeYee Tang Computer Security Division\r\nTimothy Zimmerman Information Technology Laboratory\r\nSmart Connected Systems Division\r\nCommunications Technology Laboratory Adam Hahn\r\nStephanie Saravia\r\nAslam Sherule\r\nMichael Thompson\r\nThe MITRE Corporation\r\nThis publication is available free of charge from:\r\nhttps://doi.org/10.6028/NIST.SP.800-82r3\r\nSeptember 2023\r\nU.S. Department of Commerce\r\nGina M. Raimondo, Secretary\r\nNational Institute of Standards and Technology\r\nLaurie E. Locascio, NIST Director and Under Secretary of Commerce for Standards and Technology\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\nCertain commercial equipment, instruments, software, or materials, commercial or non-commercial, are identified in\r\nthis paper in order to specify the experimental procedure adequately. Such identification does not imply\r\nrecommendation or endorsement of any product or service by NIST, nor does it imply that the materials or\r\nequipment identified are necessarily the best available for the purpose.\r\nThere may be references in this publication to other publications currently under development by NIST in\r\naccordance with its assigned statutory responsibilities. The information in this publication, including concepts and\r\nmethodologies, may be used by federal agencies even before the completion of such companion publications. Thus,\r\nuntil each publication is completed, current requirements, guidelines, and procedures, where they exist, remain\r\noperative. For planning and transition purposes, federal agencies may wish to closely follow the development of\r\nthese new publications by NIST.\r\nOrganizations are encouraged to review all draft publications during public comment periods and provide feedback\r\nto NIST. Many NIST cybersecurity publications, other than the ones noted above, are available at\r\nhttps://csrc.nist.gov/publications.\r\nAuthority\r\nThis publication has been developed by NIST in accordance with its statutory responsibilities under the Federal\r\nInformation Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283.\r\nNIST is responsible for developing information security standards and guidelines, including minimum requirements\r\nfor federal information systems, but such standards and guidelines shall not apply to national security systems\r\nwithout the express approval of appropriate federal officials exercising policy authority over such systems. This\r\nguideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130.\r\nNothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding\r\non federal agencies by the Secretary of Commerce under statutory authority. Nor should these guidelines be\r\ninterpreted as altering or superseding the existing authorities of the Secretary of Commerce, Director of the OMB, or\r\nany other federal official. This publication may be used by nongovernmental organizations on a voluntary basis and\r\nis not subject to copyright in the United States. Attribution would, however, be appreciated by NIST.\r\nNIST Technical Series Policies\r\nCopyright, Use, and Licensing Statements\r\nNIST Technical Series Publication Identifier Syntax\r\nPublication History\r\nApproved by the NIST Editorial Review Board on 2023-09-20\r\nSupersedes NIST Special Publication (SP) 800-82 Rev. 2 (May 2015) https://doi.org/10.6028/NIST.SP.800-82r2\r\nHow to Cite this NIST Technical Series Publication:\r\nStouffer K, Pease M, Tang CY, Zimmerman T, Pillitteri V, Lightman S, Hahn A, Saravia S, Sherule A, Thompson\r\nM (2023) Title. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP)\r\nNIST SP 800-82r3. https://doi.org/10.6028/NIST.SP.800-82r3\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\nAuthor ORCID iDs\r\nKeith Stouffer: 0000-0003-1220-5487\r\nMichael Pease: 0000-0002-6489-2621\r\nCheeYee Tang: 0000-0002-5488-8645\r\nTimothy Zimmerman: 0000-0001-8451-0515\r\nVictoria Pillitteri: 0000-0002-7446-7506\r\nSuzanne Lightman: 0000-0002-5007-3887\r\nContact Information\r\nsp800-82rev3@nist.gov\r\nNational Institute of Standards and Technology\r\nAttn: Computer Security Division, Information Technology Laboratory\r\n100 Bureau Drive (Mail Stop 8930) Gaithersburg, MD 20899-8930\r\nAll comments are subject to release under the Freedom of Information Act (FOIA).\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\ni\r\nAbstract\r\nThis document provides guidance on how to secure operational technology (OT) while\r\naddressing their unique performance, reliability, and safety requirements. OT encompasses a\r\nbroad range of programmable systems and devices that interact with the physical environment\r\n(or manage devices that interact with the physical environment). These systems and devices\r\ndetect or cause a direct change through the monitoring and/or control of devices, processes, and\r\nevents. Examples include industrial control systems, building automation systems, transportation\r\nsystems, physical access control systems, physical environment monitoring systems, and\r\nphysical environment measurement systems. The document provides an overview of OT and\r\ntypical system topologies, identifies common threats and vulnerabilities to these systems, and\r\nprovides recommended security countermeasures to mitigate the associated risks.\r\nKeywords\r\ncomputer security; distributed control systems (DCS); industrial control systems (ICS);\r\ninformation security; network security; operational technology (OT); programmable logic\r\ncontrollers (PLC); risk management; security controls; supervisory control and data acquisition\r\n(SCADA) systems.\r\nReports on Computer Systems Technology\r\nThe Information Technology Laboratory (ITL) at the National Institute of Standards and\r\nTechnology (NIST) promotes the U.S. economy and public welfare by providing technical\r\nleadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test\r\nmethods, reference data, proof of concept implementations, and technical analyses to advance\r\nthe development and productive use of information technology. ITL’s responsibilities include the\r\ndevelopment of management, administrative, technical, and physical standards and guidelines for\r\nthe cost-effective security and privacy of other than national security-related information in\r\nfederal information systems. The Special Publication 800-series reports on ITL’s research,\r\nguidelines, and outreach efforts in information system security, and its collaborative activities\r\nwith industry, government, and academic organizations.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\nii\r\nNote to Readers\r\nThis document is the third revision of NIST SP 800-82. Updates in this revision include:\r\n• Expansion in scope from industrial control systems to operational technology (OT)\r\n• Updates to OT threats and vulnerabilities\r\n• Updates to OT risk management, recommended practices, and architectures\r\n• Updates to current activities in OT security\r\n• Updates to security capabilities and tools for OT\r\n• Additional alignment with other OT security standards and guidelines, including the\r\nCybersecurity Framework\r\n• New tailoring guidance for NIST SP 800-53, Rev. 5 security controls\r\n• An OT overlay for NIST SP 800-53, Rev. 5 security controls that provides tailored\r\nsecurity control baselines for low-, moderate-, and high-impact OT systems\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\niii\r\nPatent Disclosure Notice\r\nNOTICE: ITL has requested that holders of patent claims whose use may be required for\r\ncompliance with the guidance or requirements of this publication disclose such patent claims to\r\nITL. However, holders of patents are not obligated to respond to ITL calls for patents and ITL\r\nhas not undertaken a patent search in order to identify which, if any, patents may apply to this\r\npublication.\r\nAs of the date of publication and following call(s) for the identification of patent claims whose\r\nuse may be required for compliance with the guidance or requirements of this publication, no\r\nsuch patent claims have been identified to ITL.\r\nNo representation is made or implied by ITL that licenses are not required to avoid patent\r\ninfringement in the use of this publication.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\niv\r\nTable of Contents\r\nExecutive Summary ................................................................................................................. 1\r\n Introduction ...................................................................................................................... 6\r\n Purpose and Scope .................................................................................................... 6\r\n Audience .................................................................................................................... 6\r\n Document Structure .................................................................................................... 7\r\n OT Overview ..................................................................................................................... 8\r\n Evolution of OT ........................................................................................................... 8\r\n OT-Based Systems and Their Interdependencies ....................................................... 9\r\n OT System Operation, Architectures, and Components .............................................10\r\n2.3.1. OT System Design Considerations ..........................................................................11\r\n2.3.2. SCADA Systems .....................................................................................................12\r\n2.3.3. Distributed Control Systems ....................................................................................19\r\n2.3.4. Programmable Logic Controller-Based Topologies ..................................................21\r\n2.3.5. Building Automation Systems ..................................................................................22\r\n2.3.6. Physical Access Control Systems............................................................................24\r\n2.3.7. Safety Systems .......................................................................................................25\r\n2.3.8. Industrial Internet of Things .....................................................................................26\r\n Comparing OT and IT System Security......................................................................28\r\n OT Cybersecurity Program Development ......................................................................33\r\n Establish a Charter for the OT Cybersecurity Program ..............................................33\r\n Business Case for the OT Cybersecurity Program .....................................................34\r\n3.2.1. Benefits of Cybersecurity Investments .....................................................................34\r\n3.2.2. Building an OT Cybersecurity Business Case .........................................................35\r\n3.2.3. Resources for Building a Business Case .................................................................36\r\n3.2.4. Presenting the OT Cybersecurity Business Case to Leadership ..............................36\r\n OT Cybersecurity Program Content ...........................................................................37\r\n3.3.1. Establish OT Cybersecurity Governance .................................................................38\r\n3.3.2. Build and Train a Cross-Functional Team to Implement the OT Cybersecurity\r\nProgram ..................................................................................................................38\r\n3.3.3. Define the OT Cybersecurity Strategy .....................................................................39\r\n3.3.4. Define OT-Specific Policies and Procedures ...........................................................40\r\n3.3.5. Establish a Cybersecurity Awareness Training Program for the OT Environment ....41\r\n3.3.6. Implement a Risk Management Framework for OT .................................................41\r\n3.3.7. Develop a Maintenance Tracking Capability ............................................................41\r\n3.3.8. Develop an Incident Response Capability ...............................................................42\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\nv\r\n3.3.9. Develop a Recovery and Restoration Capability ......................................................42\r\n3.3.10. Summary of OT Cybersecurity Program Content .................................................43\r\n Risk Management for OT Systems .................................................................................44\r\n Managing OT Security Risk .......................................................................................45\r\n4.1.1. Framing OT Risk .....................................................................................................46\r\n4.1.2. Assessing Risk in an OT Environment .....................................................................51\r\n4.1.3. Responding to Risk in an OT Environment ..............................................................53\r\n4.1.4. Monitoring Risk in an OT Environment ....................................................................53\r\n Special Areas for Consideration ................................................................................54\r\n4.2.1. Supply Chain Risk Management .............................................................................54\r\n4.2.2. Safety Systems .......................................................................................................55\r\n Applying the Risk Management Framework to OT Systems ......................................55\r\n4.3.1. Prepare ...................................................................................................................56\r\n4.3.2. Categorize ...............................................................................................................59\r\n4.3.3. Select ......................................................................................................................60\r\n4.3.4. Implement ...............................................................................................................62\r\n4.3.5. Assess ....................................................................................................................63\r\n4.3.6. Authorize .................................................................................................................64\r\n4.3.7. Monitor ....................................................................................................................65\r\n OT Cybersecurity Architecture .......................................................................................66\r\n Cybersecurity Strategy ..............................................................................................66\r\n5.1.1. Impacts of Choosing a Cybersecurity Strategy ........................................................67\r\n5.1.2. Defense-in-Depth Strategy ......................................................................................67\r\n5.1.3. Other Cybersecurity Strategy Considerations ..........................................................68\r\n Defense-in-Depth Architecture Capabilities ...............................................................69\r\n5.2.1. Layer 1 – Security Management ..............................................................................69\r\n5.2.2. Layer 2 – Physical Security .....................................................................................69\r\n5.2.3. Layer 3 – Network Security .....................................................................................71\r\n5.2.4. Layer 4 – Hardware Security ...................................................................................76\r\n5.2.5. Layer 5 – Software Security.....................................................................................76\r\n Additional Cybersecurity Architecture Considerations ................................................79\r\n5.3.1. Cyber-Related Safety Considerations ......................................................................79\r\n5.3.2. Availability Considerations .......................................................................................79\r\n5.3.3. Geographically Distributed Systems ........................................................................81\r\n5.3.4. Regulatory Requirements ........................................................................................81\r\n5.3.5. Environmental Considerations .................................................................................81\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\nvi\r\n5.3.6. Field I/O (Purdue Level 0) Security Considerations .................................................81\r\n5.3.7. Additional Security Considerations for IIoT ..............................................................82\r\n Cybersecurity Architecture Models ............................................................................83\r\n5.4.1. Distributed Control System (DCS)-Based OT Systems ............................................83\r\n5.4.2. DCS- and PLC-Based OT with IIoT .........................................................................86\r\n5.4.3. SCADA-Based OT Environments ............................................................................87\r\n Applying the Cybersecurity Framework to OT ..............................................................90\r\n Identify (ID) ................................................................................................................90\r\n6.1.1. Asset Management (ID.AM) ....................................................................................91\r\n6.1.2. Governance (ID.GV) ................................................................................................93\r\n6.1.3. Risk Assessment (ID.RA) ........................................................................................94\r\n6.1.4. Risk Management Strategy (ID.RM) ........................................................................95\r\n6.1.5. Supply Chain Risk Management (ID.SC) .................................................................95\r\n Protect (PR) ...............................................................................................................96\r\n6.2.1. Identity Management and Access Control (PR.AC) .................................................97\r\n6.2.2. Awareness and Training (PR.AT) ..........................................................................108\r\n6.2.3. Data Security (PR.DS) ...........................................................................................109\r\n6.2.4. Information Protection Processes and Procedures (PR.IP) ...................................110\r\n6.2.5. Maintenance (PR.MA) ...........................................................................................117\r\n6.2.6. Protective Technology (PR.PT) .............................................................................118\r\n6.2.7. Media Protection (PR.PT-2)...................................................................................119\r\n6.2.8. Personnel Security ................................................................................................119\r\n6.2.9. Wireless Communications .....................................................................................120\r\n6.2.10. Remote Access ..................................................................................................122\r\n6.2.11. Flaw Remediation and Patch Management ........................................................124\r\n6.2.12. Time Synchronization ........................................................................................125\r\n Detect (DE) ..............................................................................................................126\r\n6.3.1. Anomalies and Events (DE.AE) .............................................................................126\r\n6.3.2. Security Continuous Monitoring (DE.CM) ..............................................................128\r\n6.3.3. Detection Process (DE.DP) ...................................................................................133\r\n Respond (RS) ..........................................................................................................134\r\n6.4.1. Response Planning (RS.RP) .................................................................................134\r\n6.4.2. Response Communications (RS.CO) ....................................................................134\r\n6.4.3. Response Analysis (RS.AN) ..................................................................................136\r\n6.4.4. Response Mitigation (RS.MI) .................................................................................136\r\n6.4.5. Response Improvements (RS.IM)..........................................................................137\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\nvii\r\n Recover (RC)...........................................................................................................137\r\n6.5.1. Recovery Planning (RC.RP) ..................................................................................137\r\n6.5.2. Recovery Improvements (RC.IM) ..........................................................................137\r\n6.5.3. Recovery Communications (RC.CO) .....................................................................138\r\nReferences ............................................................................................................................139\r\nAppendix A. List of Symbols, Abbreviations, and Acronyms .........................................146\r\nAppendix B. Glossary ........................................................................................................160\r\nAppendix C. Threat Sources, Vulnerabilities, and Incidents ..........................................169\r\nC.1. Threat Sources ........................................................................................................169\r\nC.2. Vulnerabilities and Predisposing Conditions ............................................................170\r\nC.2.1. Policy and Procedure Vulnerabilities and Predisposing Conditions........................ 171\r\nC.2.2. System Vulnerabilities and Predisposing Conditions .............................................173\r\nC.3. Threat Events and Incidents ....................................................................................179\r\nC.3.1. Adversarial Events ................................................................................................180\r\nC.3.2. Structural Events ...................................................................................................183\r\nC.3.3. Environmental Events............................................................................................ 184\r\nC.3.4. Accidental Events ..................................................................................................184\r\nAppendix D. OT Security Organizations, Research, and Activities ................................186\r\nD.1. Consortiums and Standards ....................................................................................186\r\nD.1.1. Critical Infrastructure Partnership Advisory Council (CIPAC) ................................. 186\r\nD.1.2. Institute for Information Infrastructure Protection (I3P) ...........................................186\r\nD.1.3. International Electrotechnical Commission (IEC) ...................................................186\r\nD.1.3.1. IEC Technical Committee 57 ..........................................................................187\r\nD.1.3.2. IEC Technical Committee 65 ..........................................................................187\r\nD.1.4. Institute of Electrical and Electronics Engineers, Inc. (IEEE) ................................. 188\r\nD.1.4.1. IEEE Engineering in Medicine and Biology Society (EMBS) ........................... 188\r\nD.1.4.2. IEEE Industrial Electronics Society (IES) ........................................................188\r\nD.1.4.3. IEEE Power \u0026 Energy Society (PES) .............................................................188\r\nD.1.4.4. IEEE Technical Committee on Power System Communications and\r\nCybersecurity (PSCCC) ..................................................................................188\r\nD.1.4.5. IEEE Robotics and Automation Society (RAS) ...............................................189\r\nD.1.4.6. IEEE Vehicular Technology Society (VTS) .....................................................189\r\nD.1.5. International Society of Automation (ISA) ..............................................................189\r\nD.1.5.1. ISA95, Enterprise-Control System Integration ................................................190\r\nD.1.5.2. ISA99, Industrial Automation and Control Systems Security ........................... 190\r\nD.1.5.3. ISASecure ......................................................................................................191\r\nD.1.5.4. ISA-TR84.00.09, Cybersecurity Related to the Functional Safety Lifecycle .... 191\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\nviii\r\nD.1.6. International Organization for Standardization (ISO) .............................................191\r\nD.1.6.1. ISO 27001 ......................................................................................................191\r\nD.1.6.2. ISO 27002:2022 .............................................................................................191\r\nD.1.7. National Council of Information Sharing and Analysis Centers (ISACs) ................. 192\r\nD.1.8. National Institute of Standards and Technology (NIST) .........................................192\r\nD.1.8.1. NIST SP 800 Series Cybersecurity Guidelines ...............................................192\r\nD.1.8.2. NIST SP 1800 Series Cybersecurity Practice Guides .....................................193\r\nD.1.8.3. NIST Internal or Interagency Reports .............................................................194\r\nD.1.9. North American Electric Reliability Corporation (NERC) ........................................195\r\nD.1.9.4. NERC Critical Infrastructure Protection (CIP) Standards ................................195\r\nD.1.10. Operational Technology Cybersecurity Coalition ................................................196\r\nD.2. Research Initiatives and Programs ..........................................................................196\r\nD.2.1. Clean Energy Cybersecurity Accelerator Initiative .................................................196\r\nD.2.2. Cybersecurity for Energy Delivery Systems (CEDS) R\u0026D Program ....................... 196\r\nD.2.3. Cybersecurity for the Operational Technology Environment (CyOTE) ................... 197\r\nD.2.4. Cybersecurity Risk Information Sharing Program (CRISP) ....................................197\r\nD.2.5. Cyber Testing for Resilient Industrial Control Systems (CyTRICS) ........................ 197\r\nD.2.6. Homeland Security Information Network – Critical Infrastructure (HSIN-CI) ........... 197\r\nD.2.7. INL Cyber-Informed Engineering (CIE) and Consequence-Driven CIE (CCE) ....... 198\r\nD.2.8. Linking the Oil and Gas Industry to Improve Cybersecurity (LOGIIC) .................... 198\r\nD.2.9. NIST Cyber-Physical Systems and Internet of Things Program ............................. 198\r\nD.2.10. NIST Cybersecurity for Smart Grid Systems Project ..........................................199\r\nD.2.11. NIST Cybersecurity for Smart Manufacturing Systems Project .......................... 199\r\nD.2.12. NIST Reliable, High Performance Wireless Systems for Factory Automation..... 199\r\nD.2.13. NIST Prognostics and Health Management for Reliable Operations in Smart\r\nManufacturing (PHM4SM)..................................................................................200\r\nD.2.14. NIST Supply Chain Traceability for Agri-Food Manufacturing ............................ 200\r\nD.3. Tools and Training ...................................................................................................200\r\nD.3.1. CISA Cyber Security Evaluation Tool (CSET®) .....................................................200\r\nD.3.2. CISA Cybersecurity Framework Guidance ............................................................200\r\nD.3.3. CISA ICS Alerts, Advisories, and Reports .............................................................201\r\nD.3.4. CISA ICS Training Courses ...................................................................................201\r\nD.3.5. MITRE ATT\u0026CK for ICS ........................................................................................201\r\nD.3.6. NIST Cybersecurity Framework .............................................................................201\r\nD.3.7. SANS ICS Security Courses..................................................................................202\r\nD.4. Sector-Specific Resources.......................................................................................202\r\nD.4.1. Chemical ...............................................................................................................202\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\nix\r\nD.4.2. Communications ....................................................................................................203\r\nD.4.3. Critical Manufacturing ............................................................................................ 203\r\nD.4.4. Dams .....................................................................................................................203\r\nD.4.5. Energy ...................................................................................................................203\r\nD.4.6. Food and Agriculture .............................................................................................203\r\nD.4.7. Healthcare and Public Health ................................................................................204\r\nD.4.8. Nuclear Reactors, Materials, and Waste................................................................204\r\nD.4.9. Transportation Systems .........................................................................................204\r\nD.4.10. Water and Wastewater ......................................................................................205\r\nD.5. Conferences and Working Groups ...........................................................................205\r\nD.5.1. Digital Bond’s SCADA Security Scientific Symposium (S4) ...................................205\r\nD.5.2. Industrial Control Systems Joint Working Group (ICSJWG) ..................................205\r\nD.5.3. IFIP Working Group 11.10 on Critical Infrastructure Protection ..............................206\r\nD.5.4. SecurityWeek’s ICS Cyber Security Conference ...................................................206\r\nD.5.5. Stockholm International Summit on Cyber Security in SCADA and ICS\r\n(CS3STHLM) .........................................................................................................206\r\nAppendix E. OT Security Capabilities and Tools .............................................................207\r\nE.1. Network Segmentation and Isolation .......................................................................207\r\nE.1.1. Firewalls ................................................................................................................207\r\nE.1.2. Unidirectional Gateways ........................................................................................207\r\nE.1.3. Virtual Local Area Networks (VLANs) ....................................................................207\r\nE.1.4. Software-Defined Networking (SDN) .....................................................................208\r\nE.2. Network Monitoring – Security Information and Event Management (SIEM) ............ 208\r\nE.2.1. Centralized Logging ..............................................................................................208\r\nE.2.2. Passive Scanning ..................................................................................................208\r\nE.2.3. Active Scanning .....................................................................................................209\r\nE.2.4. Malware Detection ................................................................................................. 209\r\nE.2.5. Behavioral Anomaly Detection ...............................................................................2 09\r\nE.2.6. Data Loss Prevention (DLP) ..................................................................................210\r\nE.2.7. Deception Technology ...........................................................................................210\r\nE.2.8. Digital Twins ..........................................................................................................210\r\nE.3. Data Security ...........................................................................................................210\r\nE.3.1. Backup Storage .....................................................................................................210\r\nE.3.2. Immutable Storage ................................................................................................211\r\nE.3.3. File Hashing ..........................................................................................................211\r\nE.3.4. Digital Signatures ..................................................................................................211\r\nE.3.5. Block Ciphers ........................................................................................................211\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\nx\r\nE.3.6. Remote Access .....................................................................................................212\r\nAppendix F. OT Overlay ....................................................................................................213\r\nF.1. Overlay Characteristics ............................................................................................ 213\r\nF.2. Applicability .............................................................................................................214\r\nF.3. Overlay Summary ....................................................................................................214\r\nF.4. Tailoring Considerations ..........................................................................................223\r\nF.5. OT Communication Protocols ..................................................................................224\r\nF.6. Definitions ................................................................................................................225\r\nF.7. Detailed Overlay Control Specifications ................................................................... 225\r\nF.7.1. ACCESS CONTROL – AC ....................................................................................227\r\nF.7.2. AWARENESS AND TRAINING – AT .....................................................................235\r\nF.7.3. AUDITING AND ACCOUNTABILITY – AU ............................................................236\r\nF.7.4. ASSESSMENT, AUTHORIZATION, AND MONITORING – CA ............................. 240\r\nF.7.5. CONFIGURATION MANAGEMENT – CM .............................................................243\r\nF.7.6. CONTINGENCY PLANNING – CP ........................................................................247\r\nF.7.7. IDENTIFICATION AND AUTHENTICATION – IA ..................................................252\r\nF.7.8. INCIDENT RESPONSE – IR .................................................................................256\r\nF.7.9. MAINTENANCE – MA ...........................................................................................258\r\nF.7.10. MEDIA PROTECTION –MP ...............................................................................260\r\nF.7.11. PHYSICAL AND ENVIRONMENTAL PROTECTION – PE ................................262\r\nF.7.12. PLANNING – PL ................................................................................................267\r\nF.7.13. ORGANIZATION-WIDE INFORMATION SECURITY PROGRAM\r\nMANAGEMENT CONTROLS – PM ................................................................... 269\r\nF.7.14. PERSONNEL SECURITY – PS .........................................................................276\r\nF.7.15. RISK ASSESSMENT – RA ................................................................................278\r\nF.7.16. SYSTEM AND SERVICES ACQUISITION – SA ................................................280\r\nF.7.17. SYSTEM AND COMMUNICATIONS PROTECTION – SC ................................. 283\r\nF.7.18. SYSTEM AND INFORMATION INTEGRITY – SI ...............................................291\r\nF.7.19. SUPPLY CHAIN RISK MANAGEMENT – SR ....................................................296\r\nAppendix G. Change Log ..................................................................................................299\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\nxi\r\nList of Tables\r\nTable 1. Summary of typical differences between IT and OT systems ......................................30\r\nTable 2. Sections with additional guidance for establishing a cybersecurity program ................43\r\nTable 3. Possible definitions for OT impact levels based on the product produced, the\r\nindustry, and security concerns .................................................................................................49\r\nTable 4. Event Likelihood Evaluation ........................................................................................50\r\nTable 5. Categories of non-digital OT control components .......................................................52\r\nTable 6. Applying the RMF Prepare step to OT ........................................................................56\r\nTable 7. Applying the RMF Categorize step to OT ....................................................................60\r\nTable 8. Applying the RMF Select step to OT ...........................................................................61\r\nTable 9. Applying the RMF Implement step to OT ....................................................................62\r\nTable 10. Applying the RMF Assess step to OT ........................................................................63\r\nTable 11. Applying the RMF Authorize step to OT ....................................................................64\r\nTable 12. Applying the RMF Monitor step to OT .......................................................................65\r\nTable 13. Threats to OT ..........................................................................................................169\r\nTable 14. Policy and procedure vulnerabilities and predisposing conditions ........................... 172\r\nTable 15. Architecture and design vulnerabilities and predisposing conditions ....................... 174\r\nTable 16. Configuration and maintenance vulnerabilities and predisposing conditions ........... 174\r\nTable 17. Physical vulnerabilities and predisposing conditions ...............................................177\r\nTable 18. Software development vulnerabilities and predisposing conditions ......................... 177\r\nTable 19. Communication and network configuration vulnerabilities and predisposing\r\nconditions ................................................................................................................................178\r\nTable 20. Sensor, final element, and asset management vulnerabilities and predisposing\r\nconditions ................................................................................................................................179\r\nTable 21. Examples of potential threat events ........................................................................179\r\nTable 22. Control baselines ....................................................................................................215\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\nxii\r\nList of Figures\r\nFig. 1. Basic operation of a typical OT system ..........................................................................11\r\nFig. 2. A general SCADA system layout that shows control center devices, communications\r\nequipment, and field sites .........................................................................................................13\r\nFig. 3. Examples of point-to-point, series, series-star, and multi-drop SCADA\r\ncommunications topologies .......................................................................................................14\r\nFig. 4. An example SCADA topology that supports a large number of remote stations .............15\r\nFig. 5. A comprehensive SCADA system implementation example ...........................................17\r\nFig. 6. An example rail monitoring and control SCADA system implementation ........................18\r\nFig. 7. A comprehensive DCS implementation example ...........................................................20\r\nFig. 8. A PLC control system implementation example .............................................................21\r\nFig. 9. A BAS implementation example .....................................................................................23\r\nFig. 10. A PACS implementation example ................................................................................24\r\nFig. 11. An SIS implementation example ..................................................................................26\r\nFig. 12. A three-tiered IIoT system architecture ........................................................................27\r\nFig. 13. Risk management process: Frame, assess, respond, and monitor ..............................45\r\nFig. 14. Risk management levels: Organization, mission and business process, and system ...46\r\nFig. 15. Risk Management Framework steps ............................................................................56\r\nFig. 16. High-level example of the Purdue model and IIoT model for network segmentation\r\nwith DMZ segments ..................................................................................................................72\r\nFig. 17. A DCS implementation example ..................................................................................84\r\nFig. 18. A defense-in-depth security architecture example for a DCS system ...........................85\r\nFig. 19. A security architecture example for DCS system with IIoT devices ..............................87\r\nFig. 20. An example SCADA system in an OT environment......................................................88\r\nFig. 21. A security architecture example for a SCADA system ..................................................89\r\nFig. 22. Detailed overlay control specifications illustrated .......................................................227\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\nxiii\r\nAcknowledgments for Revision 3\r\nThe authors gratefully acknowledge and appreciate the significant contributions from Sallie\r\nEdwards, Blaine Jefferies, and John Hoyt from The MITRE Corporation and Megan Corso and\r\nBrett Ramsay from the Department of Defense. The authors wish to thank their colleagues who\r\nreviewed drafts of the document and contributed to its content, including Eran Salfati, Karen\r\nScarfone, and Isabel Van Wyk.\r\nAcknowledgments for Previous Versions\r\nThe authors wish to thank their colleagues who reviewed drafts of the original version of the\r\ndocument and contributed to its technical content. The authors would particularly like to\r\nacknowledge Tim Grance, Ron Ross, Stu Katzke, and Freemon Johnson of NIST for their keen\r\nand insightful assistance throughout the development of the document. The authors also\r\ngratefully acknowledge and appreciate the many contributions from the public and private\r\nsectors whose thoughtful and constructive comments improved the quality and usefulness of the\r\npublication. The authors would particularly like to thank the members of ISA99, Lisa Kaiser,\r\nDepartment of Homeland Security, the Department of Homeland Security Industrial Control\r\nSystem Joint Working Group (ICSJWG), the Office of the Deputy Undersecretary of Defense for\r\nInstallations and Environment, Business Enterprise Integration Directorate staff, Daryl Haegley,\r\nand Michael Chipley for their exceptional contributions to this publication. The authors would\r\nalso like to thank the UK National Centre for the Protection of National Infrastructure (CPNI) for\r\nallowing portions of the Good Practice Guide on Firewall Deployment for SCADA and Process\r\nControl 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.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n1\r\nExecutive Summary\r\nThis document provides guidance for establishing secure operational technology (OT)1\r\n1\r\n See https://csrc.nist.gov/Projects/operational-technology-security.\r\n while\r\naddressing OT’s unique performance, reliability, and safety requirements. OT encompasses a\r\nbroad range of programmable systems and devices that interact with the physical environment\r\n(or manage devices that interact with the physical environment). These systems and devices\r\ndetect or cause a direct change through the monitoring and/or control of devices, processes, and\r\nevents. Examples include industrial control systems (ICS), building automation systems,\r\ntransportation systems, physical access control systems, physical environment monitoring\r\nsystems, and physical environment measurement systems. This document provides an overview\r\nof OT and typical system topologies, identifies common threats and vulnerabilities to these\r\nsystems, and recommends security countermeasures to mitigate the associated risks.\r\nOT is vital to the operation of U.S. critical infrastructures, which are often highly interconnected,\r\nmutually dependent systems. It is important to note that while federal agencies operate many of\r\nthe Nation’s critical infrastructures, many others are privately owned and operated. Additionally,\r\ncritical infrastructures are often referred to as a “system of systems” because of the\r\ninterdependencies that exist between various industrial sectors and interconnections between\r\nbusiness partners.\r\nInitially, OT had little resemblance to traditional information technology (IT) systems because\r\nOT systems were isolated, ran proprietary control protocols, and used specialized hardware and\r\nsoftware. As OT systems adopt IT solutions to enable corporate business systems connectivity\r\nand remote access capabilities and are designed and implemented using industry-standard\r\ncomputers, operating systems (OSs), and network protocols, they have begun to resemble IT\r\nsystems. This integration supports new IT capabilities, but it provides significantly less isolation\r\nfor OT from the outside world than predecessor systems, creating a greater need to secure OT\r\nsystems. The increasing use of wireless networking places OT implementations at greater risk\r\nfrom adversaries who are in relatively close physical proximity but do not have direct physical\r\naccess to the equipment. While security solutions have been designed to deal with these issues in\r\ntypical IT systems, special precautions must be taken when introducing these same solutions to\r\nOT environments. In some cases, new security solutions that are tailored to the OT environment\r\nare needed.\r\nAlthough some characteristics are similar, OT also has characteristics that differ from traditional\r\ninformation processing systems. Many of these differences stem from the fact that logic\r\nexecuting in OT has a direct effect on the physical world. Some of these characteristics include\r\nsignificant risk to the health and safety of human lives, serious damage to the environment, and\r\nsevere financial issues, such as production losses, negative impacts to the Nation’s economy, and\r\nthe compromise of proprietary information. OT has unique performance and reliability\r\nrequirements and often uses OSs and applications that may be considered unconventional to\r\ntypical IT personnel. Furthermore, the goals of safety and efficiency sometimes conflict with\r\nsecurity in the design and operation of OT systems.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n2\r\nOT cybersecurity programs should always be part of broader OT safety and reliability programs\r\nat both industrial sites and enterprise cybersecurity programs because cybersecurity is essential\r\nto the safe and reliable operation of modern industrial processes. Threats to OT systems can\r\ncome from numerous sources, including hostile governments, terrorist groups, disgruntled\r\nemployees, malicious intruders, complexities, natural disasters, malicious actions by insiders,\r\nand unintentional actions such human error or failure to follow established policies and\r\nprocedures. OT security objectives typically prioritize integrity and availability, followed by\r\nconfidentiality, but also must consider safety as an overarching priority.\r\nPossible incidents that an OT system may face include:\r\n• Blocked or delayed flow of information through OT networks, which could disrupt OT\r\noperation, including loss of view and loss of control\r\n• Unauthorized changes to instructions, commands, or alarm thresholds that could damage,\r\ndisable, or shut down equipment, create environmental impacts, and/or endanger human\r\nlife\r\n• Inaccurate information sent to system operators, either to disguise unauthorized changes\r\nor to cause operators to initiate inappropriate actions that could have various negative\r\neffects\r\n• Modified OT software or configuration settings or OT software infected with malware,\r\nwhich could have various negative effects\r\n• Interference with the operation of equipment protection systems, which could endanger\r\ncostly and difficult-to-replace equipment\r\n• Interference with the operation of safety systems, which could endanger human life\r\nMajor security objectives for an OT implementation should include the following:\r\n• Restrict logical access to the OT network, network activity, and systems. This may\r\ninclude using unidirectional gateways, utilizing a demilitarized zone (DMZ) network\r\narchitecture with firewalls to prevent network traffic from passing directly between the\r\ncorporate and OT networks, and having separate authentication mechanisms and\r\ncredentials for users of the corporate and OT networks. The OT system should also use a\r\nnetwork topology that has multiple layers, with the most critical communications\r\noccurring in the most secure and reliable layer.\r\n• Restrict physical access to the OT network and devices. Unauthorized physical access\r\nto components can seriously disrupt the OT’s functionality. A combination of physical\r\naccess controls should be used, such as locks, card readers, and/or guards.\r\n• Protect individual OT components from exploitation. This includes deploying security\r\npatches in as expeditious a manner as possible after testing them under field conditions,\r\ndisabling all unused ports and services and ensuring that they remain disabled, restricting\r\nOT user privileges to only those that are required for each user’s role, tracking and\r\nmonitoring audit trails, and using security controls such as antivirus software and file\r\nintegrity checking software where technically feasible to prevent, deter, detect, and\r\nmitigate malware. Keys of OT assets like programmable logic controllers (PLCs) and\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n3\r\nsafety systems should be in the “Run” position at all times unless they are being actively\r\nprogrammed.\r\n• Restrict unauthorized modification of data. This includes data in all states (e.g., at rest,\r\nin transit, in use) including data flows crossing network boundaries.\r\n• Detect security events and incidents. Detecting security events that have not yet\r\nescalated into incidents can help defenders break the attack chain before attackers attain\r\ntheir objectives. This includes the capability to detect failed OT components, unavailable\r\nservices, and exhausted resources that are important to provide proper and safe\r\nfunctioning of the OT system.\r\n• Maintain functionality during adverse conditions. This involves designing the OT\r\nsystem with the ability to ensure delivery of critical operations through disruption.\r\nCritical components should have a redundant counterpart. Additionally, if a component\r\nfails, it should fail in a manner that does not generate unnecessary traffic on the OT or\r\nother networks nor causes another problem elsewhere, such as a cascading event. The OT\r\nsystem should also allow for graceful degradation, such as moving from “normal\r\noperation” with full automation to “emergency operation” with operators more involved\r\nand less automation to “manual operation” with no automation.\r\n• Restore and recover the system after an incident. Incidents are inevitable, and an\r\nincident response plan is essential. A major characteristic of a good security program is\r\nhow quickly the system can be recovered after an incident has occurred.\r\nA cross-functional cybersecurity team can share their varied domain knowledge and experience\r\nto evaluate and mitigate risks to the OT system. At a minimum, the cybersecurity team should\r\nconsist of a member of the organization’s IT staff, a control engineer, a control system operator,\r\na network and system security expert, a member of the management staff, and a member of the\r\nphysical security department. For continuity and completeness, the cybersecurity team should\r\nconsult with the control system vendor and/or system integrator as well. The cybersecurity team\r\nshould coordinate closely with site management (e.g., facility superintendent) and the company’s\r\nChief Information Officer (CIO) or Chief Security Officer (CSO), who – along with the Chief\r\nExecutive Officer (CEO) or Chief Operating Officer (COO) – accepts complete responsibility\r\nand accountability for the cybersecurity of the OT system and for any safety incidents, reliability\r\nincidents, or equipment damage caused directly or indirectly by cyber incidents. An effective\r\ncybersecurity program for an OT system should apply a strategy known as “defense in depth,”\r\nwhile calls for layering security mechanisms such that the impact of a failure in any one\r\nmechanism is minimized. Organizations should not rely on “security by obscurity.”\r\nIn a typical OT system, a defense-in-depth strategy includes:\r\n• Developing security policies, procedures, training, and educational material that apply\r\nspecifically to the OT system\r\n• Considering OT security policies and procedures based on the National Terrorism\r\nAdvisory System and deploying increasingly heightened security postures as the Threat\r\nLevel increases\r\n• Addressing security throughout the life cycle of the OT system, including architecture\r\ndesign, procurement, installation, operations, maintenance, and decommissioning\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n4\r\n• Implementing a network topology for the OT system that has multiple layers, with the\r\nmost critical communications occurring in the most secure and reliable layer\r\n• Providing logical separation between the corporate and OT networks (e.g., stateful\r\ninspection firewalls between the networks, unidirectional gateways)\r\n• Considering where physical separation may be required as opposed to logical separation\r\n• Employing a DMZ network architecture (e.g., prevent direct traffic between the corporate\r\nand OT networks)\r\n• Using multi-factor authentication for remote access to the OT system\r\n• Ensuring that critical components are redundant and are on redundant networks\r\n• Designing critical systems for graceful degradation (fault tolerant) to prevent catastrophic\r\ncascading events\r\n• Disabling unused ports and services on OT devices after testing to ensure that this will\r\nnot impact OT operation\r\n• Restricting physical access to the OT network and devices\r\n• Restricting OT user privileges to only those that are required to perform each user’s\r\nfunction (e.g., establishing role-based access control, configuring each role based on the\r\nprinciple of least privilege)\r\n• Using separate authentication mechanisms and credentials for users of the OT network\r\nand the corporate network (i.e., OT network accounts do not use corporate network user\r\naccounts)\r\n• Using modern technology, such as smart cards for user authentication\r\n• Implementing security controls (e.g., intrusion detection software, antivirus software, file\r\nintegrity checking software) where technically feasible to prevent, deter, detect, and\r\nmitigate the introduction, exposure, and propagation of malicious software to, within, and\r\nfrom the OT system\r\n• Applying security techniques, such as encryption and/or cryptographic hashes, to OT data\r\nstorage and communications where appropriate\r\n• Expeditiously deploying security patches after testing all patches under field conditions\r\non a test system, if possible, before installation on the OT system\r\n• Tracking and monitoring audit trails on critical areas of the OT system\r\n• Employing reliable and secure network protocols and services where feasible\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n5\r\nIn cooperation with the public and private sector OT community, NIST has developed specific\r\nguidance on the application of the security controls in NIST Special Publication (SP) 800-53,\r\nRev. 5, Security and Privacy Controls for Information Systems and Organizations [SP800-53r5],\r\nto OT. This guidance is included in Appendix F of this document.\r\nWhile many of the controls in NIST SP 800-53, Rev. 5 are applicable to OT as written, some\r\ncontrols require OT-specific interpretation and/or augmentation by adding one or more of the\r\nfollowing:\r\n• OT Discussion provides organizations with additional information on the application of\r\nthe security controls and control enhancements to OT and the environments in which\r\nthese specialized systems operate. The guidance also provides information as to why a\r\nparticular security control or control enhancement may not be applicable in some OT\r\nenvironments or may be a candidate for tailoring (i.e., the application of scoping\r\nguidance and/or compensating controls). OT Discussion does not replace the original\r\nSupplemental Guidance in NIST SP 800-53, Rev. 5.\r\n• Control Enhancements (one or more) provide augmentations to the original control that\r\nmay be required for some OT systems.\r\nThe most successful method for securing OT systems is to gather industry-recommended\r\npractices and engage in a proactive, collaborative effort between management, the OT\r\nengineers and operators, the IT organization, and a trusted OT advisor. This team should draw\r\nupon the wealth of information available from the ongoing Federal Government, industry\r\ngroup, vendor, and standards activities listed in Appendix D.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n6\r\n Introduction\r\n Purpose and Scope\r\nThe purpose of this document is to provide guidance for establishing secure operational\r\ntechnology (OT)2\r\n2\r\n The acronym “OT” can stand for either “operational technology” or “operational technologies.” The context around the acronym, especially the\r\nuse of singular or plural words, will indicate which meaning is intended.\r\n while addressing OT’s unique performance, reliability, and safety\r\nrequirements. This document gives an overview of OT systems and typical system topologies,\r\nidentifies common threats and vulnerabilities for these systems, and recommends security\r\ncountermeasures to mitigate the associated risks. Additionally, it presents an OT-tailored security\r\ncontrol overlay based on NIST Special Publication (SP) 800-53, Rev. 5 [SP800-53r5] that\r\ncustomizes controls for the unique characteristics of the OT domain. The body of the document\r\nprovides context for the overlay, but the overlay is intended to stand alone.\r\nBecause there are many types of OT with varying levels of potential risk and impact, this\r\ndocument provides a list of many methods and techniques for securing OT systems. The\r\ndocument should not be used purely as a checklist to secure a specific system. Readers are\r\nencouraged to perform a risk-based assessment on their systems and to tailor the recommended\r\nguidelines and solutions to meet their specific security, business, and operational requirements.\r\nThe range of applicability of the basic concepts for securing OT systems presented in this\r\ndocument continues to expand.\r\n Audience\r\nThis document covers details that are specific to OT systems. Readers of this document should\r\nbe acquainted with general computer security concepts and communication protocols, such as\r\nthose used in networking. The document is technical in nature. However, it provides the\r\nnecessary background to understand the topics that are discussed.\r\nThe intended audience is varied and includes the following:\r\n• Control engineers, integrators, and architects who design or implement OT systems\r\n• System administrators, engineers, and other information technology (IT) professionals\r\nwho administer, patch, or secure OT systems\r\n• Security consultants who perform security assessments and penetration testing of OT\r\nsystems\r\n• Managers who are responsible for OT systems\r\n• Senior management who need to better understand the risks to OT systems as they justify\r\nand apply an OT cybersecurity program\r\n• Researchers and analysts who are trying to understand the unique security needs of OT\r\nsystems\r\n• Vendors who are developing products that will be deployed as part of an OT system\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n7\r\n Document Structure\r\nThe remainder of this document is divided into the following major sections:\r\n• Section 2 gives an overview of OT, including a comparison between OT and IT systems.\r\n• Section 3 discusses the development and deployment of an OT cybersecurity program to\r\nmitigate risk for the vulnerabilities identified in Appendix C.\r\n• Section 4 examines OT security risk management and applying the Risk Management\r\nFramework to OT systems.\r\n• Section 5 provides recommendations for integrating security into network architectures\r\ntypically found in OT systems, with an emphasis on network segmentation and separation\r\npractices.\r\n• Section 6 offers guidance on applying the Cybersecurity Framework to OT systems.\r\n• The References section provides a list of references used in the development of this\r\ndocument.\r\nThis guide also contains several appendices with supporting material, as follows:\r\n• Appendix A lists the acronyms and abbreviations used in this document.\r\n• Appendix B contains a glossary of the terms used in this document.\r\n• Appendix C discusses OT threat sources, vulnerabilities and predisposing conditions,\r\nthreat events, and incidents.\r\n• Appendix D presents lists and descriptions of OT security organizations, research, and\r\nactivities.\r\n• Appendix E discusses various OT security capabilities and tools.\r\n• Appendix F defines the NIST SP 800-53, Rev. 5 OT overlay and lists security controls,\r\nenhancements, and supplemental guidance that apply specifically to OT systems.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n8\r\n OT Overview\r\nOperational technology (OT)3\r\n3\r\n See https://csrc.nist.gov/Projects/operational-technology-security.\r\n encompasses a broad range of programmable systems and devices\r\nthat interact with the physical environment (or manage devices that interact with the physical\r\nenvironment). These systems and devices detect or cause a direct change through the monitoring\r\nand/or control of devices, processes, and events. Examples include industrial control systems,\r\nbuilding automation systems, transportation systems, physical access control systems, physical\r\nenvironment monitoring systems, and physical environment measurement systems.\r\nOT systems consist of combinations of control components (e.g., electrical, mechanical,\r\nhydraulic, pneumatic) that act together to achieve an objective (e.g., manufacturing,\r\ntransportation of matter or energy). The part of the system primarily concerned with producing\r\nan output is referred to as the process. The part of the system primarily concerned with\r\nmaintaining conformance with specifications is referred to as the controller (or control). The\r\ncontrol components of the system include the specification of the desired output or performance.\r\nThe system can be configured in one of three ways:\r\n• Open loop: The output is controlled by established settings.\r\n• Closed loop: The output affects the input in such a way as to maintain the desired control\r\nobjective.\r\n• Manual mode: The system is completely controlled by humans.\r\nThis section provides an overview of several types of common OT systems, including\r\nsupervisory control and data acquisition (SCADA), distributed control systems (DCS),\r\nprogrammable logic controllers (PLCs), building automation systems (BASs), physical access\r\ncontrol systems (PACSs), and the Industrial Internet of Things (IIoT). Diagrams depict the\r\nnetwork topology, connections, components, and protocols that are typically used for each\r\nsystem type. These examples only attempt to identify notional topology concepts. Actual\r\nimplementations of these types of control systems may be hybrids that blur the lines between\r\nthem. Note that the diagrams in this section do not focus on securing OT. Security architecture\r\nand security controls are discussed in Section 5 and Appendix F of this document, respectively.\r\n Evolution of OT\r\nMuch of today’s OT evolved from the insertion of IT capabilities into existing physical systems,\r\noften replacing or supplementing physical control mechanisms. For example, embedded digital\r\ncontrols replaced analog mechanical controls in rotating machines and engines. Improvements in\r\ncost and performance have encouraged this evolution and resulted in many of today’s “smart”\r\ntechnologies, such as the smart electric grid, smart transportation, smart buildings, smart\r\nmanufacturing, and the Internet of Things. While this increases the connectivity and criticality of\r\nthese systems, it also creates a greater need for their adaptability, resilience, safety, and security.\r\nEngineering OT continues to provide new capabilities while maintaining the typical long life\r\ncycles of these systems. The introduction of IT capabilities into physical systems presents\r\nemergent behavior with security implications. Engineering models and analysis are evolving to\r\naddress these emergent properties, including safety, security, privacy, and environmental impact\r\ninterdependencies.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n9\r\n OT-Based Systems and Their Interdependencies\r\nOT is used in many industries and infrastructures, including those identified by the Cybersecurity\r\nand Infrastructure Security Agency (CISA) as critical infrastructure sectors listed below. OT can\r\nbe found in all critical infrastructures and is more prevalent in the sectors that are in bold.\r\n• Chemical Sector\r\n• Commercial Facilities Sector\r\n• Communications Sector\r\n• Critical Manufacturing Sector\r\n• Dams Sector\r\n• Defense Industrial Base Sector\r\n• Emergency Services Sector\r\n• Energy Sector\r\n• Financial Services Sector\r\n• Food and Agriculture Sector\r\n• Government Facilities Sector\r\n• Healthcare and Public Health Sector\r\n• Information Technology Sector\r\n• Nuclear Reactors, Materials, and Waste Sector\r\n• Transportation Systems Sector\r\n• Water and Wastewater Systems Sector\r\nOT is vital to the operation of U.S. critical infrastructures, which are often highly interconnected\r\nand mutually dependent systems, both physically and through a host of information and\r\ncommunications technologies. It is important to note that while federal agencies operate many of\r\nthe critical infrastructures mentioned above, many others are privately owned and operated.\r\nAdditionally, critical infrastructures are often referred to as a “system of systems” because of the\r\ninterdependencies that exist between various industrial sectors and the interconnections between\r\nbusiness partners [Peerenboom][Rinaldi]. An incident in one infrastructure can directly and\r\nindirectly affect other infrastructures through cascading and escalating failures.\r\nFor example, both the electrical power transmission and distribution grid industries use\r\ngeographically distributed SCADA control technology to operate highly interconnected and\r\ndynamic systems that consist of thousands of public and private utilities and rural cooperatives\r\nfor supplying electricity to end users. Some SCADA systems monitor and control electricity\r\ndistribution by collecting data from and issuing commands to geographically remote field control\r\nstations from a centralized location. SCADA systems are also used to monitor and control water,\r\noil, and natural gas distribution, including pipelines, ships, trucks, rail systems, and wastewater\r\ncollection systems.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n10\r\nSCADA systems and DCS are often networked together. This is the case for electric power\r\ncontrol centers and generation facilities. Although electric power generation facility operation is\r\ncontrolled by a DCS, the DCS must communicate with the SCADA system to coordinate\r\nproduction output with transmission and distribution demands.\r\nElectric power is often thought to be one of the most prevalent sources of disruptions of\r\ninterdependent critical infrastructures. For example, a cascading failure can be initiated by a\r\ndisruption of the microwave communications network used for an electric power transmission\r\nSCADA system. The lack of monitoring and control capabilities could cause a large generating\r\nunit to be taken offline and lead to the loss of power at a transmission substation. This loss could\r\ncause a major imbalance, triggering a cascading failure across the power grid and resulting in\r\nlarge area blackouts that potentially affect oil and natural gas production, refinery operations,\r\nwater treatment systems, wastewater collection systems, and pipeline transport systems that rely\r\non the grid for electric power.\r\n OT System Operation, Architectures, and Components\r\nAs Fig. 1 depicts, a typical OT system contains numerous control loops, human-machine\r\ninterfaces, and remote diagnostics and maintenance tools. The system is built using an array of\r\nnetwork protocols on layered network architectures. Some critical processes may also include\r\nsafety systems.\r\nA control loop utilizes sensors, actuators, and controllers to manipulate some controlled process.\r\nA sensor is a device that produces a measurement of some physical property and then sends this\r\ninformation as controlled variables to the controller. The controller interprets the measurements\r\nand generates corresponding manipulated variables based on a control algorithm and target set\r\npoints, which it transmits to the actuators. Actuators – such as control valves, breakers, switches,\r\nand motors – are used to directly manipulate the controlled process based on commands from the\r\ncontroller.\r\nIn a typical monitoring system, there are generally no direct connections between the sensors and\r\nany actuators. Sensor values are transmitted to a monitoring station to be analyzed by a human.\r\nHowever, these types of systems can still be considered OT systems (albeit with a human in the\r\nloop) because the objective of the monitoring system is likely to identify and ultimately mitigate\r\nan event or condition (e.g., a door alerting that it has been forced open, resulting in security\r\npersonnel being sent to investigate; an environmental sensor that detects high temperatures in a\r\nserver room, resulting in control center personnel activating an auxiliary air conditioning unit).\r\nOperators and engineers use human-machine interfaces (HMIs) to monitor and configure set\r\npoints, control algorithms, and adjust and establish parameters in the controller. The HMI also\r\ndisplays process status information and historical information. Diagnostics and maintenance\r\nutilities are used to prevent, identify, and recover from abnormal operation or failures.\r\nSometimes, control loops are nested and/or cascading, whereby the set point for one loop is\r\nbased 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\r\norder of milliseconds to minutes.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n11\r\n \r\nFig. 1. Basic operation of a typical OT system\r\n2.3.1. OT System Design Considerations\r\nThe design of an OT system depends on many factors, including whether a SCADA, DCS, or\r\nPLC-based topology is used. This section identifies key factors that drive design decisions\r\nregarding the control, communication, reliability, and redundancy properties of the OT system.\r\nBecause these factors heavily influence the design of the OT system, they also help determine\r\nthe system’s security needs.\r\n• Safety. Systems must be able to detect unsafe conditions and trigger actions to reduce\r\nunsafe conditions to safe ones. In most safety-critical operations, human oversight and\r\ncontrol of a potentially dangerous process are essential.\r\n• Control timing requirements. System processes have a wide range of time-related\r\nrequirements, including very high speed, consistency, regularity, and synchronization.\r\nHumans may be unable to reliably and consistently meet these requirements, so\r\nautomated controllers may be necessary. Some systems may require computation to be\r\nperformed as close to sensors and actuators as possible to reduce communication latency\r\nand perform necessary control actions on time.\r\n• Geographic distribution. Systems have varying degrees of distribution, ranging from a\r\nsmall system (e.g., local PLC-controlled process) to large, distributed systems (e.g., oil\r\npipelines, electric power grids). Greater distribution typically implies a need for wide\r\narea networking (e.g., leased lines, circuit switching, packet switching) and mobile\r\ncommunication.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n12\r\n• Hierarchy. Supervisory control is used to provide a central location that can aggregate\r\ndata from multiple locations to support control decisions based on the current state of the\r\nsystem. A hierarchical or centralized control is often used to provide human operators\r\nwith a comprehensive view of the entire system.\r\n• Control complexity. Simple controllers and preset algorithms can often perform control\r\nfunctions. However, more complex systems (e.g., air traffic control) require human\r\noperators to ensure that all control actions are appropriate for meeting the larger\r\nobjectives of the system.\r\n• Availability. Systems with strong availability and up-time requirements may require\r\nmore redundancy or alternate implementations across all communications and controls.\r\n• Impact of failures. The failure of a control function could cause substantially different\r\nimpacts across domains. Systems with greater impacts often require the ability to\r\ncontinue operations through redundant controls or to operate in a degraded state.\r\n2.3.2. SCADA Systems\r\nSupervisory control and data acquisition (SCADA) systems are used to control dispersed assets\r\nfor which centralized data acquisition is as important as control [Bailey][Boyer]. These systems\r\nare used in distribution systems, such as water distribution and wastewater collection systems, oil\r\nand natural gas pipelines, electrical utility transmission and distribution systems, and rail and\r\nother public transportation systems. SCADA systems integrate data acquisition systems with data\r\ntransmission systems and HMI software to provide a centralized monitoring and control system\r\nfor numerous process inputs and outputs. SCADA systems are designed to collect field\r\ninformation, transfer it to a control center, and display the information to the operator graphically\r\nor textually, thereby allowing the operator to monitor or control an entire system from a central\r\nlocation in near real-time. Based on the sophistication and setup of the individual system, control\r\nof any individual system, operation, or task can be automatic, or it can be performed by operator\r\ncommands.\r\nTypical hardware includes a control server placed at a control center, communications equipment\r\n(e.g., radio, telephone line, cable, or satellite), and one or more geographically distributed field\r\nsites that consist of remote terminal units (RTUs) and/or PLCs that control actuators and/or\r\nmonitor sensors. The control server stores and processes the information from RTU inputs and\r\noutputs, while the RTU or PLC controls the local process. The communications hardware allows\r\nfor the transfer of information and data between the control server and the RTUs or PLCs. The\r\nsoftware is programmed to tell the system what and when to monitor, what parameter ranges are\r\nacceptable, and what response to initiate when a process variable changes outside of acceptable\r\nvalues. An intelligent electronic device (IED), such as a protective relay, may communicate\r\ndirectly to the control server, or a local RTU may poll the IEDs to collect the data and pass it to\r\nthe control server. IEDs provide a direct interface to control and monitor equipment and sensors.\r\nIEDs may be directly polled and controlled by the control server and, in most cases, have local\r\nprogramming that allows for the IED to act without direct instructions from the control center.\r\nSCADA systems are usually designed to be fault-tolerant systems with significant redundancy\r\nbuilt in, although redundancy may not be a sufficient countermeasure in the face of a malicious\r\nattack.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n13\r\nFigure 2 shows the components and general configuration of a SCADA system. The control\r\ncenter at the top of the diagram houses a control server and the communications routers. Other\r\ncontrol center components include the HMI, engineering workstations, and the data historian,\r\nwhich are all connected by a local area network (LAN). The control center collects and logs\r\ninformation gathered by the field sites, displays information to the HMI, and may generate\r\nactions based on detected events. The control center is also responsible for centralized alarming,\r\ntrend analyses, and reporting.\r\nThe field sites at the bottom of Fig. 2 locally control actuators and monitor sensors. Field sites\r\nare often equipped with a remote access capability to allow operators to perform remote\r\ndiagnostics and repairs, usually over a separate dial-up modem or wide area network (WAN)\r\nconnection. Standard and proprietary communication protocols that run over serial and network\r\ncommunications are used to transport information between the control center and field sites\r\nusing telemetry techniques, such as telephone line, cable, fiber, and radio frequencies (e.g.,\r\nbroadcast, microwave, satellite).\r\n \r\n \r\nFig. 2. A general SCADA system layout that shows control center devices, communications equipment,\r\nand field sites\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n14\r\nSCADA communication topologies vary among implementations. The various topologies used\r\nare 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\r\nchannels needed for each connection. In a series configuration, the number of channels used is\r\nreduced, though channel sharing impacts the efficiency and complexity of SCADA operations.\r\nSimilarly, the series-star and multi-drop configurations’ use of one channel per device results in\r\ndecreased efficiency and increased system complexity.\r\nThe four basic SCADA topologies shown in Fig. 3 can be further augmented by using dedicated\r\ndevices to manage communication exchanges and perform message switching and buffering.\r\n \r\n \r\nFig. 3. Examples of point-to-point, series, series-star, and multi-drop SCADA communications topologies\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n15\r\nLarge SCADA systems that contain hundreds of RTUs often employ a sub-control server to\r\nalleviate the burden on the primary server. This type of topology is shown in Fig. 4.\r\n \r\n \r\n \r\nFig. 4. An example SCADA topology that supports a large number of remote stations\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n16\r\nFigure 5 shows an example SCADA system implementation that consists of a primary control\r\ncenter and three field sites. A second backup control center provides redundancy in the event of a\r\nprimary control center malfunction. Point-to-point connections are used for all communications\r\nbetween the control center and field site, and two connections use radio telemetry. The third field\r\nsite is local to the control center and uses the WAN for communications. A regional control\r\ncenter resides above the primary control center for a higher level of supervisory control. The\r\ncorporate enterprise network has access to all control centers through the WAN, and field sites\r\ncan be accessed remotely for troubleshooting and maintenance operations. The primary control\r\ncenter polls field devices for data at defined intervals (e.g., 5 seconds, 60 seconds) and can send\r\nnew set points to field devices as required. In addition to polling and issuing high-level\r\ncommands, the control server also watches for priority interrupts from field site alarm systems.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n17\r\n \r\nFig. 5. A comprehensive SCADA system implementation example\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n18\r\nFigure 6 shows an example implementation for rail monitoring and control. This example\r\nincludes a rail control center that houses the SCADA system and three sections of a rail system.\r\nThe SCADA system polls the rail sections for information, such as the status of the trains, signal\r\nsystems, traction electrification systems, and ticket vending machines. This information is also\r\nfed to operator consoles at the HMI stations within the rail control center. The SCADA system\r\nmonitors operator inputs at the rail control center and disperses high-level operator commands to\r\nthe rail section components. In addition, the SCADA system monitors conditions at the\r\nindividual rail sections and issues commands based on these conditions (e.g., stopping a train to\r\nprevent it from entering an area that has been flooded or is occupied by another train).\r\n \r\nFig. 6. An example rail monitoring and control SCADA system implementation\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n19\r\n2.3.3. Distributed Control Systems\r\nA distributed control system (DCS) is used to control production systems within the same\r\ngeographic location for industries such as oil refineries, water and wastewater treatment, electric\r\npower generation, chemical manufacturing, automotive production, and pharmaceutical\r\nprocessing. These systems are usually process control or discrete part control systems.\r\nA DCS is integrated as a control architecture that contains a supervisory level of control to\r\noversee multiple integrated sub-systems that are responsible for controlling the details of a\r\nlocalized process. A DCS uses a centralized supervisory control loop to mediate a group of\r\nlocalized controllers that share the overall tasks of carrying out an entire production process\r\n[Erickson]. Product and process control are usually achieved by deploying feedback or\r\nfeedforward control loops, whereby key product and/or process conditions are automatically\r\nmaintained around a desired set point. Specific process controllers or more capable PLCs are\r\nemployed in the field and tuned to provide the desired tolerance and the rate of self-correction\r\nduring process upsets. By modularizing the production system, a DCS reduces the impact of a\r\nsingle fault on the overall system. In many modern systems, the DCS is interfaced with the\r\ncorporate enterprise network to give business operations a view of production.\r\nFigure 7 shows an example implementation of the components and general configuration of a\r\nDCS. This DCS encompasses an entire facility, from the bottom-level production processes up to\r\nthe corporate enterprise layer. In this example, a supervisory controller (control server)\r\ncommunicates to its subordinates via a control network. The supervisor sends set points to and\r\nrequests data from the distributed field controllers. The distributed controllers control their\r\nprocess actuators based on control server commands and sensor feedback from process sensors.\r\nFigure 7 also gives examples of low-level controllers found on a DCS system. The field control\r\ndevices shown include a machine controller, a PLC, and a process controller. The machine\r\ncontroller interfaces with sensors and actuators using point-to-point wiring, while the other three\r\nfield devices incorporate fieldbus networks to interface with process sensors and actuators.\r\nFieldbus networks eliminate the need for point-to-point wiring between a controller and\r\nindividual field sensors and actuators. Additionally, a fieldbus allows for greater functionality\r\nbeyond control, including field device diagnostics, and can accomplish control algorithms within\r\nthe fieldbus, thereby avoiding signal routing back to the PLC for every control operation.\r\nStandard industrial communication protocols designed by industry groups such as Modbus and\r\nFieldbus [Berge] are often used on control networks and fieldbus networks.\r\nIn addition to the supervisory-level and field-level control loops, intermediate levels of control\r\nmay also exist. For example, in the case of a DCS controlling a discrete part manufacturing\r\nfacility, there could be an intermediate level supervisor for each cell within the plant. This\r\nsupervisor encompasses a manufacturing cell containing a machine controller that processes a\r\npart and a robot controller that handles raw stock and final products. There could be several of\r\nthese cells that manage field-level controllers under the main DCS supervisory control loop.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n20\r\n \r\nFig. 7. A comprehensive DCS implementation example\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n21\r\n2.3.4. Programmable Logic Controller-Based Topologies\r\nPLCs are used in both SCADA and DCS systems as the control components of an overall\r\nhierarchical system to locally manage processes through feedback control, as described in the\r\nprevious sections. In the case of SCADA systems, they may provide similar functionality to\r\nRTUs. When used in DCS systems, PLCs are implemented as local controllers within a\r\nsupervisory control scheme.\r\nPLCs can also be implemented as the primary controller in smaller OT system configurations to\r\nprovide operational control of discrete processes (e.g., automobile assembly lines, process\r\ncontrollers). These topologies differ from SCADA and DCS in that they generally lack a central\r\ncontrol server or HMI and, therefore, primarily provide closed-loop control with minimal human\r\ninvolvement. PLCs have a user-programmable memory for storing instructions for the purpose of\r\nimplementing specific functions, such as I/O control, logic, timing, counting, three mode\r\nproportional-integral-derivative (PID) control, communications, arithmetic, and data and file\r\nprocessing.\r\nFigure 8 shows a PLC over a fieldbus network performing the control of a manufacturing\r\nprocess. The PLC is accessible via a programming interface located on an engineering\r\nworkstation, and data is stored in a data historian, all of which are connected on a LAN.\r\n \r\nFig. 8. A PLC control system implementation example\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n22\r\n2.3.5. Building Automation Systems\r\nA building automation system (BAS) is a type of OT used to control the many systems used in a\r\nbuilding, including heating, ventilation, and air conditioning (HVAC); fire; electrical; lighting;\r\nphysical access control; physical security; and other utility systems. Most modern buildings\r\ncontain some form of a BAS when they are constructed. However, older buildings and\r\nequipment may have to be retrofitted to take advantage of the benefits that a BAS provides.\r\nSome of the most common functions of a BAS include maintaining environmental conditions for\r\noccupant comfort, reducing energy consumption, reducing operating and maintenance costs,\r\nincreasing security, recording historical data (e.g., temperature, humidity), and performing\r\ngeneral equipment monitoring (e.g., provide alerts to building personnel of device failure or an\r\nalarm condition).\r\nAn example of a BAS is shown in Fig. 9. A BAS may communicate over wired or wireless paths\r\nto controllers or gateways. For example, environmental control sensors can provide the\r\ntemperature and humidity to a building controller. If the sensor values are outside of the set\r\npoints, the controller can signal a variable air volume (VAV) box to increase or decrease airflow\r\nand bring the temperature to the desired state. Similarly, a building occupant scanning their\r\nidentification badge at a badge reader can result in the credentials being sent to the access control\r\ncontroller and application control server to determine whether access should be granted.\r\nWhile this guide contains recommendations that are applicable and could be used as a reference\r\nto protect a BAS against cybersecurity threats, readers are encouraged to perform a risk-based\r\nassessment on their systems and tailor the recommended guidelines and solutions to meet their\r\nspecific security, business, and operational requirements.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n23\r\n \r\nFig. 9. A BAS implementation example\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n24\r\n2.3.6. Physical Access Control Systems\r\nA physical access control system (PACS) is a type of physical security system designed to\r\ncontrol access to an area. Unlike standard physical barriers, physical access control can control\r\nwho is granted access, when the access is granted, and how long the access should last.\r\nAn access point is the entrance or barrier where access control is required. Some common\r\nphysical access control examples of access points are doors and locks, security gates, turnstiles,\r\nand vehicular gate arms. Depending on the type of facility, there can be a single access point\r\n(e.g., for high-security areas) or many (e.g., for a large office building).\r\nAn identification (ID) or personal credential is used to identify the authorized user trying to gain\r\naccess to the area or facility. A PACS often requires a user to have credentials to gain entrance to\r\na facility or access sensitive data. Examples of identification credentials include simple controls\r\n(e.g., PIN codes, passwords, key fobs, key cards) and more advanced credentials (e.g., encrypted\r\nbadges, mobile credentials). Identification credentials allow the system to know who is\r\nattempting to gain access and to maintain access logs.\r\nReaders and/or keypads are typically located at the access point. The reader reads the data and\r\nsends it to a door controller to validate the credential and determine whether access should be\r\nauthorized. If a keypad or biometric reader is also required (i.e., for multi-factor authentication),\r\nthe user will enter their PIN or perform the biometric scan following their credential scan. An\r\nexample of a PACS is shown in Fig. 10.\r\n \r\nFig. 10. A PACS implementation example\r\nIn this example, the door controller receives credential data from the reader and verifies the\r\nidentification credential. If the credential is approved by the access control server, the control\r\npanel transmits the command to authorize access and unlock the door. If the credential is denied,\r\nthe door will remain locked, and the user will not be able to gain entry. All access attempts are\r\nlogged by the door controller(s) and, ultimately, the access control server. The access control\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n25\r\nserver is the repository for user information, access privileges, and audit logs. Depending on the\r\nsystem, the server might be on-premises or managed in the cloud.\r\nWhile this guide contains recommendations that are applicable and could be used as a reference\r\nto protect a PACS against cybersecurity threats, readers are encouraged to perform a risk-based\r\nassessment on their systems and tailor the recommended guidelines and solutions to meet their\r\nspecific security, business, and operational requirements.\r\n2.3.7. Safety Systems\r\nMany of the physical processes that OT systems control have the potential to create hazardous\r\nsituations to human life and safety, property, and the environment. Safety systems are designed\r\nto reduce the likelihood and/or consequence of these potentially hazardous situations by bringing\r\nthe system to a safe state. There are several types of safety systems related to OT environments,\r\nincluding emergency shut down (ESD), process safety shutdown (PSS), and fire and gas systems\r\n(FGS).\r\nOne of the more well-known types of safety system is the safety instrumented system (SIS),\r\nwhich is composed of one or more safety instrumented functions (SIFs). An SIF is an engineered\r\nsystem that is typically comprised of sensors, logic solvers, and final control elements (e.g.,\r\nactuators) whose purpose is to bring a system to a safe state when predetermined thresholds are\r\nviolated. An SIS is implemented as part of an overall risk reduction strategy to reduce the\r\nlikelihood and/or potential consequences of a previously identified event so that it is within the\r\norganization’s risk tolerance. Although numerous other terms are associated with safety systems,\r\nthe SIS is specifically designed in accordance with [IEC61511]. An SIS is typically found in\r\nchemical, refinery, and nuclear processes.\r\nAn SIS is often independent from all other control systems in such a manner that a failure of the\r\nbasic process control system (BPCS) will not impact SIS functionality in a deleterious manner.\r\nHistorically, 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\r\nBPCS operate completely independent of each other with no direct communication between the\r\nsystems. However, some modern SISs have been designed to allow communication with the\r\ncontrol system. These types of SISs are called Integrated Control and Safety Systems (ICSSs).\r\nAn ICSS solution may be an all-in-one device from a single vendor or incorporate multiple\r\ndevices from multiple vendors. While an ICSS combines the functionality of both control and\r\nsafety systems, the SIS must still comply with the requirements outlined in [IEC61511]. One of\r\nthe advantages to this ICSS methodology is the ability to communicate information from the SIS\r\nto the BPCS.\r\nWhile this guide contains recommendations that are applicable and could be used as a reference\r\nto 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\r\ntheir specific security, business, and operational requirements.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n26\r\n \r\nFig. 11. An SIS implementation example\r\n2.3.8. Industrial Internet of Things\r\nThe Industrial Internet of Things (IIoT) consists of sensors, instruments, machines, and other\r\ndevices that are networked together and use internet connectivity to enhance industrial and\r\nmanufacturing business processes and applications [Berge]. As IT and OT systems continue to\r\nconverge and become even more interconnected, the control of physical processes remains a\r\nrelatively unique and critical concept of OT.\r\nThe Industry IoT Consortium proposes a three-tier system architecture model for representing\r\nIIoT systems [IIRA19]: the edge tier, platform tier, and enterprise tier. Each tier plays a specific\r\nrole in processing the data flows and control flows involved in usage activities. The tiers are\r\nconnected by three networks: the proximity network, access network, and service network. An\r\nexample architecture is shown in Fig. 12.\r\nThe enterprise tier implements domain-specific applications and decision support systems,\r\nprovides interfaces to end users, receives data flows from the other tiers, and issues control\r\ncommands to the other tiers.\r\nThe platform tier receives, processes, and forwards control commands from the enterprise tier to\r\nthe edge tier. It consolidates processes and analyzes data flows from the other tiers, provides\r\nmanagement functions for devices and assets, and offers non-domain-specific services, such as\r\ndata query and analytics. Based on the specific implementation, these functions can be\r\nimplemented on the IIoT platform that is deployed in an on-site data center, an off-site data\r\ncenter, or in the cloud.\r\nThe service network enables connectivity between the services in the platform tier, the enterprise\r\ntier, and the services within each tier. This connectivity may be an overlay private network over\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n27\r\nthe public internet or the internet itself, allowing enterprise-grade security between end users and\r\nservices.\r\nThe edge tier collects data from the edge nodes using the proximity network. The architectural\r\ncharacteristics of this tier vary depending on the specific implementation (e.g., geographical\r\ndistribution, physical location, governance scope). It is a logical layer rather than a true physical\r\ndivision. From a business perspective, the location of the edge depends on the business\r\nobjectives.\r\n \r\nFig. 12. A three-tiered IIoT system architecture\r\nEdge computing is a decentralized computing infrastructure in which computing resources and\r\napplication services can be distributed along the communication path between the data source\r\nand the cloud. It exists vertically within the full stack (i.e., from the device to the cloud) and\r\nhorizontally across IIoT subsystems. The edge is not merely a way to collect data for\r\ntransmission to the datacenter or cloud; it also processes, analyzes, and acts on data collected at\r\nthe edge and is, therefore, essential for optimizing industrial data at every aspect of an operation.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n28\r\nThe IIoT system architecture is fully distributed and can support a wide range of interactions and\r\ncommunication paradigms, including:\r\n• Peer-to-peer networking (e.g., security cameras communicating about identified objects)\r\n• Edge-device collaboration (e.g., wind turbines in remote locations)\r\n• Distributed queries across data stored in devices, in the cloud, and anywhere in between\r\n• Distributed data management that defines where and what data is to be stored and for\r\nhow long\r\n• Data governance, including quality, discovery, usability, privacy, and security\r\nThe proximity network connects edge nodes (e.g., sensors, actuators, devices, OT systems and\r\nassets) to the stack. It typically connects these edge nodes as one or more clusters to a gateway\r\nthat bridges to other networks. The access network enables connectivity for data and control flow\r\nbetween the edge and platform tiers. This connection may be a corporate network or an overlay\r\nprivate network over the public internet or a 4G/5G network.\r\nWhile this guide contains recommendations that are applicable and could be used as a reference\r\nto protect IIoT against cybersecurity threats, readers are encouraged to perform a risk-based\r\nassessment on their systems and tailor the recommended guidelines and solutions to meet their\r\nspecific security, business, and operational requirements.\r\n Comparing OT and IT System Security\r\nOT has many characteristics that differ from traditional IT systems, including different risks and\r\npriorities. Some of these include significant risk to the health and safety of human lives, serious\r\ndamage to the environment, and financial issues, such as production losses. OT has different\r\nperformance and reliability requirements and uses OSs and applications that may be considered\r\nunconventional in a typical IT network environment. Security protections must be implemented\r\nin a way that maintains system integrity during normal operations as well as during cyber attacks\r\n[Knapp].\r\nInitially, OT systems had little resemblance to IT systems because they were isolated and ran\r\nproprietary control protocols using specialized hardware and software. Widely available and\r\nlow-cost Ethernet, Internet Protocol (IP), and wireless devices are now replacing older\r\nproprietary technologies, which increases the likelihood of cybersecurity vulnerabilities and\r\nincidents. OT are increasingly resembling IT systems as they adopt IT technologies to promote\r\ncorporate connectivity and remote access capabilities (e.g., using industry standard computers,\r\nOSs, and network protocols). This integration supports new IT capabilities but provides\r\nsignificantly less isolation for OT from the outside world than predecessor systems, creating a\r\ngreater need to secure them. While security solutions have been designed to deal with these\r\nissues in typical IT systems, special precautions must be taken when introducing these same\r\nsolutions to OT environments. In some cases, new security solutions are needed that are tailored\r\nto the OT environment.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n29\r\nSome special considerations when securing OT include:\r\n• Timeliness and performance requirements. OT systems are generally time-critical,\r\nwith the criterion for acceptable levels of delay and jitter dictated by the individual\r\ninstallation. Some systems require reliable, deterministic responses. High throughput is\r\ntypically not essential to OT. In contrast, IT systems typically require high throughput\r\nand can withstand some level of delay and jitter. For some OT, automated response times\r\nor system responses to human interaction is critical. Many OT systems utilize real-time\r\nOSs (RTOS), where real-time refers to timeliness requirements. The units of real time are\r\nhighly application-dependent and must be explicitly stated.\r\n• Availability requirements. Many OT processes are continuous in nature. Unexpected\r\noutages of systems that control industrial processes are unacceptable. Outages must often\r\nbe planned and scheduled days or weeks in advance. Exhaustive pre-deployment testing\r\nis essential to ensuring high availability (i.e., reliability) for the OT. OT systems often\r\ncannot be stopped and started without affecting production. In some cases, the products\r\nproduced or equipment being used are more important than the information being\r\nrelayed. Therefore, typical IT strategies (e.g., rebooting a component) are usually not\r\nacceptable for OT due to adverse impacts on the requirements for high availability,\r\nreliability, and maintainability. Some OT employ redundant components – often running\r\nin parallel – to provide continuity when primary components are unavailable.\r\n• Risk management requirements. In a typical IT system, primary concerns include data\r\nconfidentiality and integrity. For OT, primary concerns include safety, fault tolerance to\r\nprevent the loss of life or endangerment of public health or confidence, regulatory\r\ncompliance, loss of equipment, loss of intellectual property, or lost or damaged products.\r\nThe personnel responsible for operating, securing, and maintaining OT must understand\r\nthe important link between safety and security. Any security measure that impairs safety\r\nis unacceptable.\r\n• Physical effects. Field devices (e.g., PLCs, operator stations, DCS controllers) are\r\ndirectly responsible for controlling physical processes. OT can have complex interactions\r\nwith physical processes and consequences in the OT domain that can manifest in physical\r\nevents. Understanding these potential physical effects often requires communication\r\nbetween experts in OT and experts in the particular physical domain.\r\n• System operation. OT OSs and control networks are often quite different from their IT\r\ncounterparts and require different skill sets, experience, and levels of expertise. Control\r\nnetworks are typically managed by control engineers rather than IT personnel. Assuming\r\nthat differences are insignificant can have disastrous consequences on system operations.\r\n• Resource constraints. OT and their real-time operating systems (RTOSs) are often\r\nresource-constrained systems that do not include typical contemporary IT security\r\ncapabilities. Legacy systems often lack resources that are common on modern IT\r\nsystems. Many systems may also lack desired features, including encryption capabilities,\r\nerror logging, and password protection. Indiscriminate use of IT security practices in OT\r\nmay cause availability and timing disruptions. There may not be computing resources\r\navailable on OT components to retrofit these systems with current security capabilities.\r\nAdding resources or features may not be possible.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n30\r\n• Communications. Communication protocols and media used by OT environments for\r\nfield device control and intra-processor communication are typically different from IT\r\nenvironments and may be proprietary.\r\n• Change management. Change management is paramount to maintaining the integrity of\r\nboth IT and OT systems. Unpatched software represents one of the greatest\r\nvulnerabilities to a system. Software updates on IT systems, including security patches,\r\nare typically applied in a timely fashion based on appropriate security policies and\r\nprocedures. In addition, these procedures are often automated using server-based tools.\r\nSoftware updates on OT cannot always be implemented on a timely basis. These updates\r\nneed to be thoroughly tested by both the vendor and the end user of the industrial control\r\napplication before being implemented. Additionally, the OT owner must plan and\r\nschedule OT outages days or weeks in advance. The OT may also require revalidation as\r\npart of the update process. Another issue is that many OT utilize older versions of OSs\r\nthat are no longer supported by the vendor through patches. Change management is also\r\napplicable to hardware and firmware. The change management process requires careful\r\nassessment by OT experts (e.g., control engineers) working in conjunction with security\r\nand IT personnel.\r\n• Managed support. Typical IT systems allow for diversified support styles, perhaps\r\nsupporting disparate but interconnected technology architectures. For OT, service support\r\nis sometimes only available from a single vendor. In some instances, third-party security\r\nsolutions are not allowed due to OT vendor licensing and service agreements, and service\r\nsupport can be lost if third-party applications are installed without vendor\r\nacknowledgement or approval.\r\n• Component lifetime. Typical IT components have a lifetime on the order of three to five\r\nyears due to the quick evolution of technology. For OT, where technology has been\r\ndeveloped in many cases for specific uses and implementations, the lifetime of the\r\ndeployed technology is often in the order of 10 to 15 years and sometimes longer.\r\n• Component location. Most IT components and some OT components are located in\r\nbusiness and commercial facilities that are physically accessible by local transportation.\r\nRemote locations may be utilized for backup facilities. Distributed OT components may\r\nbe isolated, remote, and require extensive transportation effort to reach. The component\r\nlocation also needs to consider necessary physical and environmental security measures.\r\nTable 1 summarizes some of the typical differences between IT and OT systems.\r\nTable 1. Summary of typical differences between IT and OT systems\r\nCategory Information Technology Operational Technology\r\nPerformance\r\nRequirements\r\nNon-real time\r\nResponse must be consistent.\r\nHigh throughput is demanded.\r\nHigh delay and jitter may be acceptable.\r\nEmergency interaction is less critical.\r\nTightly restricted access control can be\r\nimplemented to the degree necessary for\r\nsecurity.\r\nReal-time\r\nResponse is time-critical.\r\nModest throughput is acceptable.\r\nHigh delay and/or jitter is unacceptable.\r\nResponse to human and other emergency\r\ninteraction is critical.\r\nAccess to OT should be strictly controlled\r\nbut should not hamper or interfere with\r\nhuman-machine interaction.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n31\r\nCategory Information Technology Operational Technology\r\nAvailability\r\n(Reliability)\r\nRequirements\r\nResponses such as rebooting are acceptable.\r\nAvailability deficiencies can often be\r\ntolerated, depending on the system’s\r\noperational requirements.\r\nResponses such as rebooting may not be\r\nacceptable because of process availability\r\nrequirements.\r\nAvailability requirements may necessitate\r\nredundant systems.\r\nOutages must be planned and scheduled\r\ndays or weeks in advance.\r\nHigh availability requires exhaustive pre-deployment testing.\r\nRisk\r\nManagement\r\nRequirements\r\nManage data\r\nData confidentiality and integrity is\r\nparamount.\r\nFault tolerance is less important;\r\nmomentary downtime is not a major risk.\r\nThe major risk impact is a delay of business\r\noperations.\r\nControl physical world\r\nHuman safety is paramount, followed by\r\nprotection of the process.\r\nFault tolerance is essential; even momentary\r\ndowntime may be unacceptable.\r\nThe major risk impacts are regulatory non-compliance, environmental impacts, and the\r\nloss of life, equipment, or production.\r\nSystem\r\nOperation\r\nSystems are designed for use with typical\r\nOSs.\r\nUpgrades are straightforward with the\r\navailability of automated deployment tools.\r\nSystems often use different and possibly\r\nproprietary OSs, sometimes without security\r\ncapabilities built in.\r\nSoftware changes must be carefully made,\r\nusually by software vendors, because of the\r\nspecialized control algorithms and\r\npotentially modified hardware and software\r\ninvolved.\r\nResource\r\nConstraints\r\nSystems are specified with enough\r\nresources to support the addition of third-party applications, such as security\r\nsolutions.\r\nSystems are designed to support the intended\r\nindustrial process and may not have enough\r\nmemory and computing resources to support\r\nthe addition of security capabilities.\r\nCommunications Standard IT communications protocols are\r\nused.\r\nPrimarily wired networks with some\r\nlocalized wireless capabilities.\r\nTypical IT networking practices are\r\nemployed.\r\nMany proprietary and standard\r\ncommunication protocols are used.\r\nSeveral types of communications media are\r\nused, including dedicated wired and wireless\r\n(e.g., radio and satellite).\r\nComplex networks exist that sometimes\r\nrequire the expertise of control engineers.\r\nChange\r\nManagement\r\nSoftware changes are applied in a timely\r\nfashion in the presence of good security\r\npolicies and procedures, and the procedures\r\nare often automated.\r\nSoftware changes must be thoroughly tested\r\nand deployed incrementally throughout a\r\nsystem to ensure that the integrity of the OT\r\nsystem is maintained.\r\nOT outages must often be planned and\r\nscheduled days or weeks in advance. OT\r\nmay use OSs that are no longer supported.\r\nOT systems often have custom applications.\r\nManaged\r\nSupport\r\nAllow for diversified support styles Service support is usually provided through\r\na single vendor.\r\nComponent\r\nLifetime\r\nLifetime on the order of three to five years Lifetime on the order of 10 to 15 years\r\nComponents\r\nLocation\r\nComponents are usually local and easy to\r\naccess.\r\nComponents can be isolated, remote, and\r\nrequire extensive physical effort to gain\r\naccess to them.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n32\r\nIn summary, the operational and risk differences between IT and OT systems create the need for\r\nincreased sophistication in applying cybersecurity and operational strategies. A cross-functional\r\nteam of control engineers, control system operators, and IT security professionals must work\r\nclosely to understand the possible implications of the installation, operation, and maintenance of\r\nsecurity solutions in conjunction with control system operation. IT professionals working with\r\nOT need to understand the reliability impacts of information security technologies before\r\ndeployment. Moreover, some of the OSs and applications that run on OT may not operate\r\ncorrectly with commercial-off-the-shelf (COTS) IT cybersecurity solutions because of their\r\nunique requirements.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n33\r\n OT Cybersecurity Program Development\r\nTo mitigate cybersecurity risks to their OT systems, organizations need to develop and deploy an\r\nOT cybersecurity program. It should be consistent and integrated with existing IT cybersecurity\r\nprograms and practices but also account for the specific requirements and characteristics of OT\r\nsystems and environments. Organizations should regularly review and update their OT\r\ncybersecurity plans and programs to reflect changes in technologies, operations, standards,\r\nregulations, and the security needs of specific facilities.\r\nEffective integration of cybersecurity into the operation of OT requires defining and executing a\r\ncomprehensive program that addresses all aspects of cybersecurity. This includes defining the\r\nobjectives and scope of the program; establishing a cross-functional team that understands OT\r\nand cybersecurity; establishing policies and procedures; identifying cyber risk management\r\ncapabilities that include people, processes, and technologies; and identifying day-to-day\r\noperations of event monitoring and auditing for compliance and improvement.\r\nWhen a new system is being designed and installed, it is imperative to take the time to address\r\nsecurity throughout the life cycle, including architecture, procurement, installation, maintenance,\r\nand decommissioning. Deploying systems to the field based on the assumption that these systems\r\nwill be secured later introduces significant risks to the systems and the organization. If there are\r\nnot enough time and resources to properly secure the system before deployment, it is unlikely\r\nthat security will be addressed at a later time. Since new OT systems are designed and deployed\r\nless frequently than IT systems, it is much more common to improve, expand, or update an\r\nexisting OT system than to design a new one.\r\nThis section introduces the basic process for developing an OT cybersecurity program and\r\napplies to new and deployed OT systems. Additional guidance for developing the specific\r\nelements of an OT cybersecurity program can be found in Section 3.3.10.\r\n Establish a Charter for the OT Cybersecurity Program\r\nSenior management must demonstrate a clear commitment to cybersecurity and communicate its\r\nimportance throughout the organization. Cybersecurity is a business responsibility shared by all\r\nmembers of the organization, especially by its leaders and IT and OT teams. Commitment to\r\ncybersecurity can be demonstrated by establishing a charter for a cybersecurity program with\r\nadequate funding, visibility, governance, and support from senior leaders. A cybersecurity\r\nprogram that has commitment from senior management is more likely to achieve the mission and\r\nbusiness goals of the organization.\r\nA charter for a cybersecurity program is a plain-language high-level description that establishes\r\nclear ownership and accountability for protecting OT resources and provides a mandate for the\r\nmost senior person responsible to establish and maintain the cybersecurity program (e.g., CISO).\r\nThis section focuses on an OT-specific program, which should be integrated with the\r\norganization’s overall cybersecurity program.\r\nA cybersecurity program charter should include program objectives, scope, and responsibilities.\r\nSenior management establishes the OT cybersecurity program charter and identifies an OT\r\ncybersecurity manager with appropriate authority to lead the OT cybersecurity program. The OT\r\ncybersecurity manager should define the roles and responsibilities of system owners, mission and\r\nbusiness process managers, and users. The OT cybersecurity manager should also document the\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n34\r\nobjectives and scope of the OT security program, including the business organizations affected,\r\nthe systems and networks involved, the budget and resources required, and the division of\r\nresponsibilities.\r\nThe organization may already have an information security program in place or have developed\r\none for its IT systems. The OT cybersecurity manager should identify which existing practices to\r\nleverage and which practices are specific to the OT system. Ultimately, it will be more effective\r\nfor the team to share resources with others in the organization that have similar objectives.\r\n Business Case for the OT Cybersecurity Program\r\nThe cybersecurity of OT systems is a critical component in the overall security of the\r\norganization. Cybersecurity events could potentially impact the organization’s mission and\r\nobjectives, the environment, regulatory compliance, and even human safety. OT systems can also\r\nbe used as an entry point to organizational IT systems and other enterprise systems. As OT\r\nsystems are increasingly being connected to IT networks, relying on traditional measures (e.g.,\r\nair gaps) is not enough to protect such systems from cyber attacks. Therefore, security measures\r\ntailored to the OT system are required to protect the organization. An OT cybersecurity program\r\nconsiders the characteristics of OT systems that require special consideration in order to mitigate\r\nthese risks.\r\n3.2.1. Benefits of Cybersecurity Investments\r\nOT cybersecurity supports the mission and business functions of the organization and provides\r\nadditional benefits, including:\r\n• Improving OT system safety, reliability, and availability\r\n• Improving OT system efficiency\r\n• Reducing community concerns\r\n• Reducing legal liabilities\r\n• Meeting regulatory requirements\r\n• Helping with insurance coverage and costs\r\nA strong OT cybersecurity program is fundamental to a sustainable business operation and can\r\npotentially enhance system reliability and availability. This includes minimizing unintentional\r\nOT system information security impacts from inappropriate testing, policies, and misconfigured\r\nsystems. Cyber attacks can also have other significant impacts, such as:\r\n• Physical impacts. Physical impacts encompass the set of direct consequences of OT\r\nfailure, particularly personal injury and the loss of life. Other effects include the loss of\r\nproperty (including data) and potential damage to the environment.\r\n• Economic impacts. Economic impacts are a second-order effect of physical impacts that\r\nensue from an OT incident, which in turn inflict a greater economic loss on the facility,\r\norganization, or others who are dependent on the OT systems. The unavailability of\r\ncritical infrastructure (e.g., electrical power, transportation) can have economic impacts\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n35\r\nfar beyond the systems that sustain direct and physical damage. These effects could\r\nnegatively impact the local, regional, national, or possibly global economy.\r\n• Social impacts. Another second-order effect is the loss of national or public confidence\r\nin an organization.\r\nAdditional examples of the potential consequences of an OT incident are listed below. Note that\r\nitems in this list are not independent. For example, the release of hazardous material could lead\r\nto injury or death.\r\n• Impact on national security (e.g., facilitate an act of terrorism)\r\n• Reduction or loss of production at one site or multiple sites simultaneously\r\n• Injury or death of employees\r\n• Injury or death of persons in the community\r\n• Damage to equipment\r\n• Release, diversion, or theft of hazardous materials\r\n• Environmental damage\r\n• Violation of regulatory requirements\r\n• Product contamination\r\n• Criminal or civil legal liabilities\r\n• Loss of proprietary or confidential information\r\n• Loss of brand image or customer confidence\r\nSafety and security incidents can have negative impacts that last longer than other types of\r\nincidents on all stakeholders, including employees, shareholders, customers, and the\r\ncommunities in which an organization operates. Senior management should identify and evaluate\r\nthe highest priority items to estimate the annual business impact (e.g., in financial terms).\r\n3.2.2. Building an OT Cybersecurity Business Case\r\nA 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\r\nfor the development, implementation, and maintenance of the program. The first step in\r\ndeveloping an OT security program is to identify the organization’s business objectives and\r\nmissions, as well as how the cybersecurity program can lower risk and protect the organization’s\r\nability to perform those objectives and missions. The business case should capture the business\r\nconcerns of senior management and provide the business impact and financial justification for\r\ncreating an integrated organizational cybersecurity program. It should include detailed\r\ninformation about the following:\r\n• Benefits of creating an integrated security program\r\n• Potential costs and failure scenarios if an OT cybersecurity program is not implemented\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n36\r\n• High-level overview of the process required to implement, operate, monitor, review,\r\nmaintain, and improve the information security program\r\nThe costs and resources required to develop, implement, and maintain the security program\r\nshould be considered. The economic benefits of the cybersecurity program may be evaluated in\r\nthe same way that worker health and safety programs are. However, an attack on the OT system\r\ncould have significant consequences that far exceed monetary costs.\r\n3.2.3. Resources for Building a Business Case\r\nHelpful resources can be found through information sharing exchanges, trade and standards\r\norganizations, consulting firms, and internal risk management programs or engineering and\r\noperations. External organizations can also provide useful tips as to what factors most strongly\r\ninfluenced management to support their efforts and what resources within their organizations\r\nproved most helpful. While these factors may vary across industries, there may be similarities in\r\nthe roles that other risk management specialists can play. Appendix D lists some current\r\nactivities in OT security.\r\nInternal resources in related risk management efforts (e.g., information security, health, safety\r\nand environmental risk, physical security, business continuity) can provide tremendous\r\nassistance in prioritizing threats and estimating business impacts. These resources can also\r\nprovide insight into which managers are focused on dealing with which risks and who may be\r\nthe most appropriate or receptive to serving as a champion.\r\n3.2.4. Presenting the OT Cybersecurity Business Case to Leadership\r\nIn order to be successful, the OT cybersecurity program must have active participation from\r\nsenior management. Organization-level management in both IT and OT operations has the\r\nperspective to understand the risks as well as the authority to assume responsibility for them.\r\nSenior management will be responsible for approving and driving information security policies,\r\nassigning security roles and responsibilities, and implementing the information security program\r\nacross the organization. Funding for the entire program can usually be done in phases. While\r\nsome funding may be required to start the program, additional funding can be obtained later as\r\nthe security vulnerabilities and needs of the program are better understood and additional\r\nstrategies are developed. Additionally, costs should be considered for retrofitting the OT for\r\nsecurity versus addressing security to begin with.\r\nOften, a good approach to obtaining management buy-in is to base the business case on a\r\nsuccessful example of another organization that had a similar problem and how they solved it.\r\nThis will often prompt management to ask how that solution might be applicable to their\r\norganization.\r\nWhen presenting the business case to leadership, it may also be helpful to mention the specific\r\nchallenges in securing the OT systems:\r\n• OT systems operate under different environments and requirements than IT systems. For\r\nexample, OT systems tend to prioritize availability and safety over other factors like\r\nconfidentiality.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n37\r\n• IT programs or tools may not be suitable or effective for OT systems.\r\n• Compensatory measures may be an effective solution to securing an OT system without\r\naffecting system performance.\r\n• Protecting OT systems is critical, and a cybersecurity incident on an OT system may have\r\ncatastrophic consequences that affect human life and the environment.\r\n OT Cybersecurity Program Content\r\nThis section provides recommendations for establishing, implementing, maintaining, and\r\ncontinually improving an OT cybersecurity program. These recommendations are independent,\r\nwhich allows the organization to select the approaches and technologies that are most suitable to\r\nits needs.\r\nAn OT cybersecurity program is typically tailored to a specific OT environment. An organization\r\nmay have multiple sites, each with multiple specific OT environments. In such situations, an\r\norganizational-level OT security program should be defined with recommendations that cascade\r\ndown and adapt to the needs of individual sites and OT environments.\r\nThe effectiveness of an OT cybersecurity program is often enhanced through coordination or\r\nintegration with the organization’s processes and information security program. However,\r\ninformation security programs typically focus on the confidentiality, integrity, and availability –\r\nin that order – of information for the entire organization. Information security programs do not\r\nnecessarily address all of the specific security and operational needs of an OT environment,\r\nwhich instead prioritizes safety, followed by availability, integrity, and confidentiality. This\r\ndifference in focus and priorities between IT and OT security programs should be kept in mind.\r\nNIST SP 800-100, Information Security Handbook: A Guide for Managers [SP800-100],\r\nprovides a broad overview of information security program elements to assist in establishing and\r\nimplementing an information security program in an organization.\r\nThe lifespan of an OT system can exceed 20 years. As a result, many legacy systems may\r\ncontain hardware and software that are no longer supported by vendors and cannot be patched or\r\nupdated to protect against new vulnerabilities. In that case, the security program should be\r\ntailored to the unique characteristics of the legacy system to determine whether the controls are\r\napplicable. When security controls are not supported by the legacy OT system, compensating\r\ncontrols should be considered. For example, anti-malware software may not be available for\r\nsystems such as PLCs and DCS, which means that malware protection requirements cannot be\r\napplied to these endpoints. In this case, a compensating control should be considered, such as\r\nusing a firewall with a deep packet inspection capability that can monitor and block advanced\r\nthreats like malware.\r\nThe primary purpose of investing in a cybersecurity program is risk management. Risk to\r\noperations exists because of the potential of threat actors exploiting the vulnerabilities in the\r\napplications and infrastructures. Therefore, the most appropriate decision regarding what to\r\ninclude in the scope of a cybersecurity program can be made if investments are viewed through\r\nthe lens of corporate risk management. To help design and drive a cybersecurity program with a\r\nrisk management perspective, NIST SP 800-37, Rev. 2 [SP800-37r2] describes the Risk\r\nManagement Framework, which defines the core tasks and processes for implementing a\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n38\r\ncybersecurity program. This is briefly summarized in Section 3.3.6 and further elaborated in\r\nSection 4.\r\nThe OT cybersecurity program should also address policy exceptions and deviations. In a\r\ndemanding OT environment, situations may arise that require a temporary deviation from the\r\nsecurity policy in order to maintain the mission or goal of the OT system. Such deviations or\r\nexceptions must be handled with great care and receive approval from management and the\r\ncross-functional team. The security program can establish a policy and procedure for handling\r\nthese policy exceptions. All of these guidance documents recognize that one size does not fit all.\r\nRather, domain knowledge combined with site-specific constraints should be applied in adapting\r\nthis guidance to a specific organization.\r\n3.3.1. Establish OT Cybersecurity Governance\r\nOT governance should include the policies, procedures, and processes for managing the\r\norganization’s regulatory, legal, risk, environmental, and operational requirements. The\r\ngovernance should ensure that the policies, procedures, and processes are well understood by\r\nstaff and inform the management of OT cybersecurity risk. To establish an effective OT\r\ncybersecurity governance capability, develop a process and assign responsibilities and\r\naccountability to appropriate roles in the corporate risk management function. Typically, a\r\ncybersecurity governance process should include the following:\r\n• Ensure that the OT cybersecurity policy is established and communicated.\r\n• Ensure that OT cybersecurity roles and responsibilities are coordinated and aligned with\r\ninternal roles and external partners.\r\n• Ensure that legal and regulatory requirements regarding OT cybersecurity, including\r\nprivacy, are understood and managed.\r\n• Ensure that cybersecurity risks are integrated into corporate risk management processes.\r\nFurther guidance for establishing OT cybersecurity guidance can be found in Section 6.\r\nAdditional information with specific examples for establishing a cybersecurity governance\r\ncapability are also provided in NIST Internal or Interagency Report (NIST IR) 8183A,\r\nCybersecurity Framework Manufacturing Profile Low Impact Level Example Implementations\r\nGuide [IR8183A].\r\n3.3.2. Build and Train a Cross-Functional Team to Implement the OT\r\nCybersecurity Program\r\nIt is essential for a cross-functional cybersecurity team to share their varied domain knowledge\r\nand experience to evaluate and manage risk in OT. The OT cybersecurity team should consist of\r\nrepresentatives from the following departments: IT staff, control engineer, control system\r\noperator, security subject-matter expert, and enterprise risk management. For completeness, the\r\ninformation security team should also include any cybersecurity service providers.\r\nFrom a safety perspective, major accident hazards and the loss of containment due to equipment\r\nfailure or operator mistakes can have serious consequences. Cybersecurity is another threat to the\r\nsafety and reliability of industrial processes, so including safety experts as part of the\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n39\r\ncybersecurity team will be beneficial in identifying potential impact areas due to cyber\r\nvulnerabilities. Their insight into OT design and safety considerations will also help in\r\nformulating cyber mitigations.\r\nWhile the control engineers will play a large role in securing OT, they will not be able to do so\r\nwithout collaboration and support from both the IT department and management. IT often has\r\nyears of cybersecurity experience, much of which is applicable to OT. As the cultures of control\r\nengineering and IT are often significantly different, their integration will be essential for the\r\ndevelopment of a collaborative security design and operation.\r\nOrganizations come in various sizes, structures, geographical spreads, and complexities. These\r\nfactors and the strategies related to resources and budget constraints may drive organizations to\r\nhire OT cybersecurity resources as employees or contractors or outsource the OT security\r\noperation function as a managed security service. Irrespective of the security operation and\r\nresource model used, the responsibility for OT cybersecurity management should be integrated\r\nwith IT cybersecurity and the corporate risk management function.\r\nThe responsibility and accountability for implementing and managing cybersecurity functions\r\ntypically falls under the IT and OT infrastructure organization, whereas cybersecurity operational\r\nmetrics and risks are reported to the risk management office. These two lines of reporting\r\nstructure need to collaborate in terms of funding and expectations of what can be achieved given\r\na funding and resource level. The risk executive function works with executive management to\r\ndecide the risk tolerance and residual risk.\r\nAs part of building a cybersecurity team, the following tasks should be included:\r\n• Establish and maintain cybersecurity roles and responsibilities for building, operating,\r\nand improving an OT cybersecurity program.\r\n• Establish cybersecurity roles and responsibilities for third-party providers, which can\r\ninclude service providers, contractors, and other organizations that provide OT system\r\ndevelopment and services and security operation and management.\r\nFurther guidance for establishing a cross-functional team can be found in Section 4 and\r\nAppendix D. Additional information with specific examples for establishing a cross-functional\r\nteam are also provided in NIST IR 8183A, Cybersecurity Framework Manufacturing Profile\r\nLow Impact Level Example Implementations Guide [IR8183A].\r\n3.3.3. Define the OT Cybersecurity Strategy\r\nAn organization-wide risk management strategy is foundational to developing an OT\r\ncybersecurity strategy.4\r\n4\r\n For additional information on developing an organization-wide risk management strategy, refer to NIST SP 800-37, Rev. 2 [SP800-37r2],\r\nPrepare Step, Task P-2, Risk Management Strategy. Section 3 provides additional information on organization-level and system-level tasks to\r\nprepare for implementing the NIST Risk Management Framework.\r\n The OT cybersecurity strategy leverages the organization-wide risk\r\nmanagement strategy – including organization-defined risk tolerance, threats, assumptions,\r\nconstraints, priorities, and trade-offs – to further tailor the strategy to apply to the OT\r\ncybersecurity program.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n40\r\nThe OT cybersecurity strategy:\r\n• Refines and supplements guidance from the organization-wide risk management strategy\r\nto address OT-specific constraints and requirements\r\n• Identifies the OT cybersecurity team and personnel\r\n• Addresses the OT cybersecurity operation model (e.g., insource, outsource, and/or use\r\nmanaged security services)\r\n• Outlines the appropriate cybersecurity architecture for the various OT sites within the OT\r\nprogram\r\n• Defines OT-specific cybersecurity training and awareness\r\nThe OT cybersecurity strategy should help refine the organizational risk tolerance for the OT\r\noperation, which in turn drives the priorities for the OT cybersecurity operation. The program\r\nshould also address both IT and OT concerns and requirements. For example, IT may consider\r\ndata loss or system availability as a higher priority, but OT may value system safety, production\r\nefficiency, and environmental damage as higher priorities.\r\nFurther guidance for developing an OT cybersecurity strategy can be found in Section 5, Section\r\n6, Appendix C, and Appendix D. Additional information and specific examples for establishing\r\nan OT cybersecurity strategy are also provided in NIST IR 8183A, Cybersecurity Framework\r\nManufacturing Profile Low Impact Level Example Implementations Guide [IR8183A].\r\n3.3.4. Define OT-Specific Policies and Procedures\r\nPolicies and procedures are essential to the success of any cybersecurity program. Where\r\npossible, OT-specific security policies and procedures should be derived from existing IT\r\ncybersecurity and plant operational policies and procedures for consistency throughout the\r\norganization.\r\nAs discussed earlier, organizational management is responsible for developing and\r\ncommunicating the risk tolerance level of the organization (i.e., the level of risk that the\r\norganization is willing to accept), which allows the OT cybersecurity manager to determine the\r\nrisk management strategy. The development of cybersecurity policies should be based on a risk\r\nassessment that will set the security priorities and goals for the organization. Procedures that\r\nsupport the policies need to be developed so that the policies are implemented fully and properly\r\nfor OT. Cybersecurity procedures should be documented, tested, and updated periodically in\r\nresponse to policy, technology, and threat changes.\r\nFurther guidance for developing OT-specific policies and procedures can be found in Section 6.\r\nAdditional information with examples for establishing OT-specific policies and procedures are\r\nalso provided in NIST IR 8183A, Cybersecurity Framework Manufacturing Profile Low Impact\r\nLevel Example Implementations Guide [IR8183A].\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n41\r\n3.3.5. Establish a Cybersecurity Awareness Training Program for the OT\r\nEnvironment\r\nOrganizations should ensure that all personnel who interact with OT systems – including\r\nemployees, contractors, consultants, and vendors – receive cybersecurity training that is relevant\r\nto the OT environment in addition to general IT cybersecurity awareness training. This training\r\nis used to inform personnel of basic cybersecurity principles, teach them about their potential\r\nimpacts on security and safety, and outline the steps that they need to follow when interacting\r\nwith OT systems. Cybersecurity awareness training should be required for new employees at the\r\ntime of hire and at regular intervals, as dictated by regulatory requirements and organizational\r\npolicies.\r\nFurther guidance for OT cybersecurity awareness training can be found in Section 6 and\r\nAppendix D. Additional information with specific examples for OT cybersecurity awareness\r\ntraining are also provided in NIST IR 8183A, Cybersecurity Framework Manufacturing Profile\r\nLow Impact Level Example Implementations Guide [IR8183A].\r\n3.3.6. Implement a Risk Management Framework for OT\r\nOT system risk is another risk confronting an organization (e.g., financial, safety, environmental,\r\nIT). In each case, managers responsible for the mission or business function establish and operate\r\na risk management program in coordination with senior management. NIST SP 800-39,\r\nManaging Information Security Risk: Organization, Mission, and Information System View\r\n[SP800-39], provides a framework for an enterprise-level risk management program, which is\r\nalso detailed in Section 4 of this document. OT personnel should be involved in developing the\r\nOT cybersecurity risk management program and communicating with senior management.\r\nNIST SP 800-37, Risk Management Framework for Information Systems and Organizations: A\r\nSystem Life Cycle Approach for Security and Privacy [SP800-37r2], provides a structured\r\nprocess for managing security and privacy risk. This includes preparing for organization-wide\r\nrisk management; system categorization; control selection, implementation, and assessment;\r\nsystem and common control authorizations; and continuous monitoring.\r\nApplying the Risk Management Framework (RMF) to OT systems is detailed in Section 4.\r\n3.3.7. Develop a Maintenance Tracking Capability\r\nEstablish processes and implement tools to ensure that routine and preventative maintenance and\r\nrepairs (both local and remote) of OT assets are performed consistent with OT organizational\r\npolicies and procedures. The tools used for maintenance logging and tracking should be\r\ncontrolled and managed. Ensure that the processes and tools allow for scheduling, authorizing,\r\ntracking, monitoring, and auditing maintenance and repair activities for OT assets. If the ability\r\nfor remote maintenance is required, ensure that the remote access tool supports the authentication\r\nof maintenance personnel, connection establishment at the beginning of maintenance activities,\r\nand immediate teardown once the maintenance activities are performed. Also ensure that the tool\r\ncan log the remote maintenance activities that are performed.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n42\r\nFurther guidance for OT maintenance tracking can be found in Section 6. Additional information\r\nwith specific examples for OT maintenance tracking are also provided in NIST IR 8183A,\r\nCybersecurity Framework Manufacturing Profile Low Impact Level Example Implementations\r\nGuide [IR8183A].\r\n3.3.8. Develop an Incident Response Capability\r\nOrganizations should establish an OT cybersecurity incident response (IR) function that should\r\ninclude planning, detection, analysis, containment, and reporting activities in the case of a\r\ncybersecurity incident. The IR function requires the establishment of several cybersecurity\r\ncapabilities, including incident management, forensic analysis, vulnerability management, and\r\nresponse communication. As part of building the IR function, the OT cybersecurity department\r\nshould create an incident response plan. The purpose of the incident response capability is to\r\ndetermine the scope and risk of cybersecurity incidents, respond appropriately to the incident,\r\ncommunicate the incident to all stakeholders, and reduce the future impact. This plan applies to\r\nall OT personnel, networks, systems, and data. The IR plan guides the activities of the\r\ncybersecurity team to respond, communicate, and coordinate in the event of a cybersecurity\r\nincident. Without such a plan, the organization will find it extremely difficult to respond when a\r\ncybersecurity incident occurs. The plan includes the roles and responsibilities of personnel, the\r\nincident response workflow, incident type and severity classification, contacts of critical\r\npersonnel who should be involved, contacts of external entities that may be useful in assisting\r\nwith IR, information sharing policy, and internal and external communication.\r\nFurther guidance for OT incident response can be found in Section 6.2.4.5 and Appendix C.\r\nAdditional information with specific examples for OT incident response are also provided in\r\nNIST IR 8183A, Cybersecurity Framework Manufacturing Profile Low Impact Level Example\r\nImplementations Guide [IR8183A].\r\n3.3.9. Develop a Recovery and Restoration Capability\r\nThe organization should establish the capability to recover from cybersecurity incidents and to\r\nrestore the assets and services that were impaired by the cybersecurity incident to a pre-cyber-incident state. This capability typically includes the following tasks:\r\n• Define recovery objectives when recovering from disruptions. For example, the recovery\r\ncapability shall prioritize human safety and environmental safety prior to restarting the\r\nOT operation that was impaired by the cybersecurity event.\r\n• Develop a site disaster recovery plan (DRP) and business continuity plan (BCP) to\r\nprepare the OT organization to respond appropriately to significant disruptions in their\r\noperations due to the cybersecurity incident.\r\n• Establish backup systems and processes to back up the relevant OT systems’ state, data,\r\nconfiguration files, and programs at regular intervals to support recovery to a stable state.\r\n• Establish processes for restoring relevant OT systems’ state, data, configuration files, and\r\nprograms from backups in a timely manner.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n43\r\n• Establish recovery processes and procedures that will be executed to restore the OT\r\nassets and services affected by cybersecurity incidents.\r\n• Establish communication plans to coordinate restoration activities with internal and\r\nexternal stakeholders and the executive management team.\r\n• Establish communication plans to manage public relations.\r\n• Establish a task for lessons learned as part of the recovery process for continuous\r\nimprovement of the cybersecurity capabilities (e.g., vulnerability management,\r\ncybersecurity operation, incident response handling, and recovery handling).\r\n• Test these plans at reasonable intervals that are appropriate for the organization.\r\nFurther guidance for OT recovery and restoration can be found in Section 6. Additional\r\ninformation with specific examples for OT recovery and restoration are also provided in NIST IR\r\n8183A, Cybersecurity Framework Manufacturing Profile Low Impact Level Example\r\nImplementations Guide [IR8183A].\r\n3.3.10. Summary of OT Cybersecurity Program Content\r\nThis section presented the elements of a cybersecurity program and the various considerations\r\nfor establishing such a program. Further guidance can be found in the document sections listed in\r\nTable 2.\r\nTable 2. Sections with additional guidance for establishing a cybersecurity program\r\nCybersecurity Program Element Section Number for Additional\r\nGuidance\r\nEstablish OT cybersecurity governance Section 6\r\nBuild and train a cross-functional team to implement an OT\r\ncybersecurity program Section 4, Appendix D\r\nDefine the OT cybersecurity strategy Sections 5 and 6, Appendices 169 and\r\n186\r\nDefine OT-specific policies and procedures Section 6\r\nEstablish a cybersecurity awareness training program for an OT\r\norganization Section 6, Appendix 186\r\nImplement a Risk Management Framework for OT Section 4 and 6, Appendices 169 and\r\n186\r\nDevelop a maintenance tracking capability Section 6\r\nDevelop an incident response capability Section 6, Appendix 169\r\nDevelop a recovery and restoration capability Section 6\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n44\r\n Risk Management for OT Systems\r\nOrganizations manage risks every day when meeting their business objectives, including\r\nfinancial losses, equipment failure, and personnel safety. Organizations develop processes to\r\nevaluate the risks associated with their business and to decide how to manage those risks based\r\non organizational priorities, risk tolerance, and internal and external constraints. This risk\r\nmanagement is an interactive ongoing process that is part of normal operations. Organizations\r\nthat use OT systems have historically managed risk through good practices in safety and\r\nengineering. Safety assessments are well established in most sectors and often incorporated into\r\nregulatory requirements. Information security risk management is an added dimension that can\r\nbe complementary. The risk management process and framework outlined in this section can be\r\napplied to managing safety, information security, and cyber supply chain risk. Privacy is also a\r\nrisk consideration for some OT systems. For additional guidance on privacy risk management,\r\nrefer to the NIST Risk Management Framework [SP800-37r2] and the Privacy Framework [PF].\r\nA risk management process is deployed throughout an organization using a three-level approach\r\nto address risk at the (i) organization level, (ii) mission and business process level, and (iii)\r\nsystem level (i.e., IT and OT). The risk management process is carried out seamlessly across the\r\nthree 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\r\nwith a shared interest in the success of the organization.\r\nThis section focuses primarily on OT system considerations at the system level, though the risk\r\nmanagement activities, information, and artifacts at each level impact and inform the other\r\nlevels. Section 6 applies the Cybersecurity Framework to OT systems, while Appendix F\r\nprovides OT-specific recommendations to augment the NIST SP 800-53, Rev. 5 [SP800-53r5]\r\ncontrol families. This section also discusses OT system considerations and the impact that these\r\nconsiderations have on the risk management process.\r\nFor more information on multi-tiered risk management and the risk management process, refer to\r\nNIST SP 800-39, Managing Information Security Risk: Organization, Mission, and Information\r\nSystem View [SP800-39]. NIST SP 800-37, Rev. 2, Risk Management Framework for\r\nInformation Systems and Organizations: A System Life Cycle Approach for Security and Privacy\r\n[SP800-37r2], provides guidelines for applying the Risk Management Framework to federal\r\ninformation systems, including conducting the activities of security categorization,5\r\n5\r\n Federal Information Processing Standard (FIPS) 199 [FIPS199] provides security categorization guidance for non-national security systems.\r\nCommittee on National Security Systems (CNSS) Instruction 1253 provides similar guidance for national security systems.\r\n security\r\ncontrol selection and implementation, security control assessment, information system\r\nauthorization,6\r\n6\r\n Security authorization is the official management decision given by a senior organizational official to authorize the operation of an information\r\nsystem and explicitly accept the risk to organizational operations and assets, individuals, other organizations, and the Nation based on the\r\nimplementation of an agreed-upon set of security controls.\r\n and security control monitoring. NIST SP 800-30, Guide for Conducting Risk\r\nAssessments [SP800-30r1], provides a step-by-step process for organizations on how to (i)\r\nprepare for risk assessments, (ii) conduct risk assessments, (iii) communicate risk assessment\r\nresults to key organizational personnel, and (iv) maintain the risk assessments over time.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n45\r\n Managing OT Security Risk\r\nWhile the risk management process presented in NIST SP 800-39 [SP800-39] applies to all types\r\nof systems, there are some unique aspects to consider when it comes to managing OT system\r\nsecurity risk. As shown in Fig. 13, the risk management process has four components: framing\r\nrisk (i.e., establishing the context for risk-based decisions), assessing risk, responding to risk,\r\nand monitoring risk. These activities are interdependent and often occur simultaneously within\r\nan organization. For example, the results of the monitoring component will feed into the framing\r\ncomponent. Because the environment in which organizations operate is always changing, risk\r\nmanagement must be a continuous process in which all components have ongoing activities. It is\r\nimportant to remember that these components apply to the management of any type of risk,\r\nincluding cybersecurity, physical security, safety, and financial. Sections 4.1.1 through 4.1.4\r\ndiscuss the four components of the risk management process in further detail and provide OT-specific implementation guidance.\r\n \r\nFig. 13. Risk management process: Frame, assess, respond, and monitor\r\nOrganization-wide risk management is applied at three levels, as Fig. 14 depicts. Level 1\r\naddresses risk management from the organizational perspective and implements risk framing by\r\nproviding context for all risk management activities within the organization. Level 2 addresses\r\nrisk from a mission and business process perspective and is informed by the Level 1 risk context,\r\ndecisions, and activities. Level 3 addresses risk at the system level and is informed by the Level\r\n1 and 2 activities and outputs.\r\nFRAME\r\nASSESS\r\nMONITOR RESPOND\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n46\r\n \r\n \r\n \r\nStrategic\r\nFocus\r\nTac�cal\r\nFocus\r\nLevel 1\r\nOrganiza�on\r\nLevel 2\r\nMission / Business Process\r\nLevel 3\r\nSystem (Environment of Opera�on)\r\nMore detailed and granular risk perspective\r\nBroad-based risk perspective\r\nFig. 14. Risk management levels: Organization, mission and business process, and system\r\nTogether, each of the risk management components (i.e., frame, assess, respond, and monitor)\r\nare applied across the risk management levels, resulting in organization-wide risk awareness and\r\nthe traceability and transparency of risk-based decisions.\r\n4.1.1. Framing OT Risk\r\nThe framing component consists of the processes for establishing the required assumptions,\r\nconstraints, risk tolerances, and risk management strategies for organizations to make consistent\r\nrisk management decisions. Specifically, risk framing supports the overall risk management\r\nstrategy by incorporating elements from the organizational governance structure, legal/regulatory\r\nenvironment, and other factors to establish how the organization intends to assess, respond to,\r\nand monitor risk to all IT and OT systems.\r\nOT-Specific Recommendations and Guidance\r\nFor OT system operators, safety directly affects decisions on how\r\nsystems are engineered and operated. Safety can be defined as “freedom\r\nfrom conditions that can cause death, injury, occupational illness,\r\ndamage to or loss of equipment or property, or damage to the\r\nenvironment.”7\r\n7\r\n See https://csrc.nist.gov/glossary/term/safety.\r\n Based on this, human safety impacts are typically\r\nevaluated based on the degree of injury, disease, or death that could\r\nresult from the OT system malfunctioning after a cyber incident, taking\r\ninto consideration any previously performed safety impact assessments\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n47\r\nregarding the employees and the public. The importance of safety and\r\ndeveloping a safety culture plays a critical role in determining risk\r\ntolerance.\r\nOrganizations should consider incorporating an analysis of cybersecurity\r\neffects on OT systems that impact personnel safety and the environment,\r\nas well as mitigating controls. More specifically, organizations may want\r\nto consider employing a comprehensive process to systematically predict\r\nor identify the operational behavior of each safety-critical failure\r\ncondition, fault condition, or human error that could lead to a hazard or\r\npotential human harm.\r\nOrganizations may also want to consider the impact of legacy systems\r\nand components on their environment. Specifically, legacy systems may\r\nbe unable to adequately support cybersecurity to prevent risks from\r\nexceeding organizational tolerance levels.\r\nAnother major concern for OT system operators is the availability of\r\nservices provided by the OT system. The OT system may be part of\r\ncritical infrastructure (e.g., water or power systems), where there is a\r\nsignificant need for continuous and reliable operations. As a result, OT\r\nsystems may have strict requirements for availability or recovery.\r\nOrganizations should understand and plan for the levels of redundancy\r\nrequired to achieve the desired resilience for their operating\r\nenvironments and incorporate these requirements into their risk framing.\r\nThis will help organizations make risk decisions that avoid unintended\r\nconsequences on those who depend on the services provided. More\r\nspecifically, organizations should consider identifying interdependent\r\nOT systems that pose cybersecurity risks that threaten system\r\navailability.\r\nAdditionally, organizations should consider how an incident could\r\npropagate to a connected system and system components. An OT may be\r\ninterconnected with other systems, such that failures in one system or\r\nprocess can easily cascade to other systems either within or outside of\r\nthe organization. Impact propagation could occur due to both physical\r\nand logical dependencies. Properly communicating the results of risk\r\nassessments to the operators of connected or interdependent systems and\r\nprocesses is one way to manage such impacts.\r\nLogical damage to an interconnected OT could occur if the cyber\r\nincident propagates to connected OT systems. For example, a virus or\r\nworm may propagate to a connected OT and impact that system.\r\nPhysical damage could also propagate to other interconnected OT or\r\nrelated physical domains. For example, the impact could result in a\r\nphysical hazard that degrades nearby physical environments or common\r\nshared dependencies (e.g., power supply) or result in a shortage of\r\nmaterial that will be needed for a later stage in an industrial process.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n48\r\nCISA promotes a cohesive effort between government and industry to improve their ability to\r\nanticipate, prioritize, and manage national-level OT risk. CISA assists OT system vendors and\r\nasset owners, operators, and other vendors across all critical infrastructure sectors to identify\r\nsecurity vulnerabilities and develop sound, proactive mitigation strategies that strengthen their\r\nOT systems’ cybersecurity posture.\r\nOT-Specific Recommendations and Guidance\r\nOrganizations may want to consider incorporating resources such as the\r\nNIST National Vulnerability Database (NVD) and the MITRE ATT\u0026CK\r\nfor Industrial Control Systems (ICS) framework [ATTACK-ICS] into\r\ntheir processes for assessing risks to the mission and OT systems.\r\nAdditionally, the nature of OT systems requires organizations to consider\r\nadditional factors that may not exist when conducting risk assessment for\r\na traditional IT system. For example, OT will have different threat\r\nsources, vulnerabilities, and compensating controls than IT. The impact\r\nof a cyber incident in an OT environment may include both physical and\r\ndigital effects that risk assessments need to incorporate, including:\r\n• Impacts on safety and the use of safety assessments\r\n• Physical impacts of a cyber incident on an OT, including the\r\nlarger physical environment, and the effect on the process\r\ncontrolled\r\n• The consequences for risk assessments of non-digital control\r\ncomponents within an OT\r\nDuring risk framing, organizations should select appropriate risk assessment methodologies that\r\ninclude OT. When evaluating the potential physical damage from a cyber incident, organizations\r\nwith OT systems may consider i) how a cyber incident could manipulate the operation to impact\r\nthe physical environment, ii) what design features exist in the OT system to prevent or mitigate\r\nan impact, and iii) how a physical incident could emerge based on these conditions.\r\nOT-Specific Recommendations and Guidance\r\nWhen framing risks within an OT environment, organizations may\r\ndiscover that cybersecurity threats are not always as well understood or\r\npredictable as OT hazards. Organizations may consider incorporating\r\ncyber attack and IT failure scenarios into their process hazard analysis\r\n(PHA) or failure mode and effects analysis (FMEA) processes. By\r\nincluding risks due to cyber attacks and cyber risk management measures\r\nin these processes, organizations may gain a better understanding of the\r\ncyber risks to the OT operational environment.\r\nAs part of risk framing, organizations may also need to consider:\r\n• Assumptions about how risk is assessed, responded to, and\r\nmonitored across the organization\r\n• The risk tolerance for the organization, the level of risk that can\r\nbe accepted as part of achieving strategic goals and objectives,\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n49\r\nand the priorities and trade-offs considered as part of managing\r\nrisk\r\nIn the context of OT, the potential for damage to equipment, human\r\nsafety, the natural environment, and other critical infrastructures is part\r\nof these considerations. Organizations may need to consider evaluating\r\nthe potential physical impacts for all parts of an OT system.\r\nOrganizations may also need to determine how OT systems interact or\r\ndepend on IT to support risk framing. These processes may require\r\norganizations to identify a common framework for evaluating impacts\r\nthat incorporate OT considerations. One approach is based on NIST\r\nFIPS 199 [FIPS199], which specifies that systems are categorized as low\r\nimpact, moderate impact, or high impact for the security objectives of\r\nconfidentiality, integrity, and availability. Another approach that is based\r\non ISA 62443-3-2 [ISA62443] provides example definitions for\r\ndetermining a system categorization utilizing OT impacts.\r\nTable 3 provides possible example categories and impact levels that organizations may\r\ncustomize to meet their specific industry or business requirements. For example, some\r\norganizations may see an outage lasting up to one day as a having a high impact instead of\r\nmoderate, as shown in the table.\r\nTable 3. Possible definitions for OT impact levels based on the product produced, the industry, and\r\nsecurity concerns\r\nCategory High Impact Moderate Impact Low Impact\r\nOutage at multiple\r\nSites\r\nSignificant disruption to\r\noperations at multiple sites\r\nwith restoration expected\r\nto require one or more\r\ndays\r\nOperational disruptions at\r\nmultiple sites with\r\nrestoration expected to\r\nrequire more than one\r\nhour\r\nPartially disrupted\r\noperations at multiple sites\r\nwith restoration to full\r\ncapability requiring less\r\nthan one hour\r\nNational\r\ninfrastructure and\r\nservices\r\nImpacts multiple sectors or\r\ndisrupts community\r\nservices in a major way\r\nPotential to impact sector\r\nat a level beyond the\r\ncompany\r\nLittle to no impact to\r\nsectors beyond the\r\nindividual company and\r\nlittle to no impact on\r\ncommunity\r\nCost (% of revenue) \u003e 25 % \u003e 5 % \u003c 5 %\r\nLegal\r\nFelony criminal offense or\r\ncompliance violation that\r\naffects the license to\r\noperate\r\nMisdemeanor criminal\r\noffense or compliance\r\nviolation that results in\r\nfines\r\nNone\r\nPublic confidence Loss of brand image Loss of customer\r\nconfidence None\r\nPeople on-site Fatality Loss of workday or major\r\ninjury\r\nFirst aid or recordable\r\ninjury\r\nPeople off-site Fatality or major\r\ncommunity incident\r\nComplaints or local\r\ncommunity impact No complaints\r\nEnvironment\r\nCitation by regional agency\r\nor long-term significant\r\ndamage over large area\r\nCitation by local agency Small, contained release\r\nbelow reportable limits\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n50\r\nTo support the risk assessment process, organizations should also define how the likelihood of\r\noccurrence for cybersecurity events will be determined to maintain consistency when assessing\r\nrisks. NIST SP 800-30, Rev. 1 [SP800-30r1] provides guidance for organizations to develop\r\nlikelihood weighted risk factors. Organizations should consider weighting risk factors based on\r\nan analysis of the probability that a given threat is capable of exploiting a given vulnerability (or\r\nset of vulnerabilities), that the threat event will be initiated, and that the threat event will result in\r\nadverse impacts.\r\nFor adversarial threats, an assessment of likelihood of occurrence is typically based on adversary\r\nintent, capability, and targeting. For other-than-adversarial threat events, the likelihood of\r\noccurrence is estimated using historical evidence, empirical data, and other factors. If\r\norganizations find that there is minimal organizational historical data, they may want to consider\r\nextending their analysis to consider industry-specific data describes cybersecurity events\r\nreported for similar organizations.\r\nThe likelihood of threat occurrence can also be based on the state of the organization (e.g., its\r\ncore mission and business processes, enterprise architecture, information security architecture,\r\ninformation systems, and the environments in which those systems operate) and consider\r\npredisposing conditions and the presence and effectiveness of deployed security controls to\r\nprotect against unauthorized or undesirable behavior, detect and limit damage, and/or other\r\nresiliency factors for the OT capabilities.\r\nOT-Specific Recommendations and Guidance\r\nOrganizations that establish definitions for event likelihood may want to\r\nreview Appendix G of NIST SP 800-30, Rev. 1 for more detailed\r\nguidance and suggestions. Based on this guidance, organizations should\r\nconsider defining five levels of likelihood from Very Low to Very High\r\nbased on both adversarial (i.e., intentional threat actors) and non-adversarial (e.g., errors, accidents, acts of nature, etc.) events.\r\nAdditionally, organizations may want to establish definitions for the\r\nlikelihood that an event may result in an adverse impact. Using these two\r\nfactors, organizations can establish a heat map like the one depicted in\r\nTable 4 to determine the likelihood factor for supporting the risk\r\nanalysis.\r\nTable 4. Event Likelihood Evaluation\r\nLikelihood of\r\nThreat Event\r\nInitiation or\r\nOccurrence\r\nLikelihood That Threat Events Result in Adverse Impacts\r\nVery Low Low Moderate High Very High\r\nVery High Low Moderate High Very High Very High\r\nHigh Low Moderate Moderate High Very High\r\nModerate Low Low Moderate Moderate High\r\nLow Very Low Low Low Moderate Moderate\r\nVery Low Very Low Very Low Low Low Low\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n51\r\n4.1.2. Assessing Risk in an OT Environment\r\nRisk assessments leverage the outputs of framing risk (e.g., acceptable risk assessment\r\nmethodologies, risk management strategy, and risk tolerance) and facilitate efforts to identify,\r\nestimate, and prioritize risks to operations, assets, individuals, and other organizations. Risk\r\nassessments occur at all risk management levels (i.e., organization, mission and business\r\nfunction, and system) and can be used to inform risk assessments at other levels. Regardless of\r\nwhich risk management level the risk assessment is conducted at, assessing risk requires\r\nidentifying threats and vulnerabilities, the harm that such threats and vulnerabilities may cause,\r\nand the likelihood that adverse events may arise from those threats and vulnerabilities.\r\nWhen the organization conducts a risk assessment that includes OT systems, there may be\r\nadditional considerations that do not exist when assessing the risks of traditional IT systems. For\r\nexample, the impact of a cyber incident on an OT may include both physical and digital effects.\r\nOT-Specific Recommendations and Guidance\r\nRisk assessments are typically point-in-time reports. As a result,\r\norganizations should ensure that they are updated to remain current and\r\nthat the security level remains adequate.\r\nOrganizations may want to review the information provided by CISA’s\r\nAlerts and Advisories, NIST’s NVD, and MITRE ATT\u0026CK for ICS to\r\nidentify common vulnerability areas for OT environments, such as:\r\n• Poor coding practices, network designs, or device configurations\r\n• Vulnerable network services and protocols\r\n• Weak authentication\r\n• Excessive privileges\r\n• Information disclosure\r\nOT systems often have specific environmental requirements (e.g., a\r\nmanufacturing process may require a precise temperature), or they may\r\nbe tied to their physical environment for operations. Organizations may\r\nwant to consider incorporating these requirements and constraints into\r\nthe framing component so that associated risks are identified.\r\nAdditionally, organizations may want to consider:\r\n• Identifying the physical assets and security controls that directly\r\nrelate to safety, human life, and maintaining continuity of\r\noperations of the OT system\r\n• Identifying the cybersecurity risks associated with physical assets\r\nthat could threaten OT system functionality\r\n• Ensuring that physical security personnel understand the relative\r\nrisks and physical security countermeasures associated with the\r\nOT system environments that they protect\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n52\r\n• Ensuring that physical security personnel are aware of areas in an\r\nOT system production environment that house data acquisition\r\nand operate in sensitive spaces\r\n• Mitigating business continuity risks by specifying immediate\r\nresponse plans if physical safety is jeopardized\r\nRisk assessments also require reviewing the digital and non-digital mechanisms that are\r\nimplemented to minimize adverse event impacts. OT systems often incorporate non-digital\r\nmechanisms to provide fault tolerance and prevent the OT from acting outside of acceptable\r\nparameters. These non-digital mechanisms may help reduce the negative impacts that a digital\r\nincident on the OT might have and should be incorporated into the risk assessment process. For\r\nexample, OT often have non-digital control mechanisms that can prevent it from operating\r\noutside of a safe boundary and thereby limit the impact of an attack (e.g., a mechanical relief\r\npressure valve). Analog mechanisms (e.g., meters, alarms) can also be used to observe the\r\nphysical system state and provide operators with reliable data if digital readings are unavailable\r\nor corrupted. Table 5 categorizes non-digital control mechanisms that could reduce the impact of\r\nan OT incident.\r\nTable 5. Categories of non-digital OT control components\r\nControl Type Description\r\nAnalog displays\r\nor alarms\r\nNon-digital mechanisms measure and display the state of the physical system (e.g.,\r\ntemperature, pressure, voltage, current) and can provide the operator with accurate\r\ninformation when digital displays are unavailable or corrupted. The information may be\r\nprovided to the operator on some non-digital display (e.g., thermometers, pressure gauges)\r\nand through audible alarms.\r\nManual control\r\nmechanisms\r\nManual control mechanisms (e.g., manual valve controls, physical breaker switches) allow\r\noperators to manually control an actuator without relying on the digital OT system. This\r\nensures that an actuator can be controlled even if the OT system is unavailable or\r\ncompromised.\r\nAnalog control\r\nsystems\r\nAnalog control systems use non-digital sensors and actuators to monitor and control a\r\nphysical process. These may prevent the physical process from entering an undesired state\r\nwhen the digital OT system is unavailable or corrupted. Analog controls include devices such\r\nas regulators, governors, and electromechanical relays. An example is a device that is\r\ndesigned to open during emergency or abnormal conditions to prevent the rise of internal\r\nfluid pressure in excess of a specified value, thus bringing the process to a safer state. The\r\ndevice may also be designed to prevent an excessive internal vacuum, such as a pressure\r\nrelief valve, a non-reclosing pressure relief device (e.g., rupture disc), or a vacuum relief\r\nvalve.\r\n \r\nOT-Specific Recommendations and Guidance\r\nOrganizations should analyze all digital and non-digital control\r\nmechanisms and the extent to which they can mitigate potential negative\r\nimpacts to the OT. For example, non-digital control mechanisms may\r\nrequire additional time and human involvement, such as operators\r\ntravelling to a remote site to perform certain control functions. Such\r\nmechanisms may also depend on human response times, which may be\r\nslower than automated controls.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n53\r\nAdditionally, organizations may need to consider privacy with their risk assessment, which\r\nsometimes require a different approach. The NIST Privacy Risk Assessment Methodology\r\n(PRAM) is a tool that applies the risk model from NIST IR 8062 [IR8062] and helps\r\norganizations analyze, assess, and prioritize privacy risks to determine how to respond and select\r\nappropriate solutions.\r\n4.1.3. Responding to Risk in an OT Environment\r\nThe risk response component provides an organization-wide response to risk in accordance with\r\nthe risk framing component by identifying possible courses of actions to address risk, evaluating\r\nthose possibilities while considering the organization’s risk tolerance and other issues identified\r\nduring framing, and choosing the best alternative for the organization. The response component\r\nincludes the implementation of the chosen course of action to address the identified risk:\r\nacceptance, avoidance, mitigation, sharing, transfer, or any combination of these options.8 \r\nOT-Specific Recommendations and Guidance\r\nFor an OT system, available risk responses may be constrained by\r\nsystem requirements, potential adverse impacts on operations, or even\r\nregulatory compliance regimes. An example of risk sharing is when\r\nutilities enter into agreements to “loan” line workers in an emergency,\r\nwhich reduces the duration of an incident’s effect to acceptable levels.\r\n4.1.4. Monitoring Risk in an OT Environment\r\nMonitoring risk is the fourth component of risk management activities. Organizations monitor\r\nrisk on an ongoing basis, including the implementation of chosen risk management strategies,\r\nchanges in the environment that may affect the risk calculation, and the effectiveness and\r\nefficiency of risk reduction activities. The activities in the monitoring component impact all of\r\nthe other components.\r\nOT-Specific Recommendations and Guidance\r\nMany OT system monitoring capabilities leverage passive monitoring\r\ntechniques to detect system changes. However, this may not always\r\ncapture all modifications to the system. Modern monitoring platforms\r\nthat leverage native protocol communications to access more system\r\ninformation may improve awareness, but the limitations of these OT\r\nsystems must be understood. Often OT systems are implemented with an\r\nundefined frequency for monitoring cyber activities. Users should set a\r\nfrequency in accordance with the respective risk profile.\r\nThreat information as it relates to the OT environment is evolving, and\r\nthe availability and accuracy of this threat information is early in its\r\ndevelopment. By their nature, threats may be difficult to accurately\r\npredict, even with historical data. Organizations should categorize threats\r\nbased on the likelihood of occurrence and their potential consequences.\r\n 8\r\n For additional information on these options, refer to NIST SP 800-39 [SP800-39].\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n54\r\nFor example, the threat of an internet-connected system being scanned\r\nwould have a high likelihood and a low severity consequence, but the\r\nthreat of a nation-state actor disrupting a supply chain may have low\r\nlikelihood and high severity consequences.\r\nSince security countermeasures are typically developed for IT\r\nenvironments, organizations should consider how deploying security\r\ntechnologies into OT environments may negatively impact operations or\r\nsafety.\r\n Special Areas for Consideration\r\nSupply chain risk management and risk management for safety are critical aspects of OT\r\ncybersecurity risk management.\r\n4.2.1. Supply Chain Risk Management\r\nCybersecurity risks can arise from the products or services acquired to support OT needs. These\r\nrisks can be introduced anywhere in the supply chain and at any stage in the life cycle. Whether\r\nthey are malicious, natural, or unintentional, these risks have the potential to compromise the\r\navailability and integrity of critical OT systems and components, as well as the availability,\r\nintegrity, and confidentiality of the data utilized by the OT, thereby causing harms that range\r\nfrom minor disruptions to impacts on life and safety.\r\nWith 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\r\norganizations perform critical roles and functions, including manufacturing and provisioning\r\ntechnology products, providing software upgrades and patches, performing integration services,\r\nor otherwise supporting the day-to-day operations and maintenance of OT systems, components,\r\nand operational environments. For this reason, OT organizations should seek to understand and\r\nmitigate the supply chain-related risks that can be inherited from these supply-side organizations\r\nand the products and services that they provide.\r\nIdentifying, assessing, and effectively responding to cybersecurity risks in supply chains is best\r\naccomplished by incorporating cybersecurity supply chain risk management (C-SCRM)\r\nconsiderations into organizational policies, plans, and practices. This includes extending\r\ncybersecurity expectations and requirements to vendors and gaining better understanding,\r\nvisibility, and control over the supply chains that are associated with acquired products and\r\nservices. Organizations should vet suppliers and service providers to ascertain their capabilities,\r\ntrustworthiness, the adequacy of their internal security practices, the effectiveness of safeguards,\r\ntheir supply chain relationships, and any risks that may be associated with those relationships\r\nand dependencies. The requirements for and evaluation of products and discrete components\r\nshould extend beyond an assessment of whether functional and technical requirements are\r\nsatisfied and address applicable C-SCRM factors, such as a product’s provenance, pedigree, and\r\ncomposition and whether the product is taint-free and authentic. Additionally, special\r\nconsideration should be given to how difficult it may be to attain original replacement parts or\r\nupdates over the life of the product and how diverse the sources of supply are and may be in the\r\nfuture.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n55\r\nOT organizations should familiarize themselves with NIST SP 800-161, Supply Chain Risk\r\nManagement Practices for Federal Information Systems and Organizations [SP800-161], and\r\nbegin or continue to implement the key practices, C-SCRM security controls, and C-SCRM risk\r\nmanagement process activities described in that publication. There is extensive guidance about\r\nhow to establish a C-SCRM program using a phased approach that begins with putting the\r\nfoundational elements in place and expanding upon that foundation over time to ensure sustained\r\neffectiveness and the ability to enhance program capabilities. There is also guidance about\r\nconducting supply chain risk assessments, incorporating C-SCRM into procurement\r\nrequirements, the importance of an integrated and inter-disciplinary risk management approach,\r\nsupplemental C-SCRM security control guidance, and templates that organizations can leverage.\r\n4.2.2. Safety Systems\r\nThe culture of safety and safety assessments is well established within much of the OT user\r\ncommunity. Information security risk assessments should complement such assessments, though\r\nthey may use different approaches and cover different areas. Safety assessments are primarily\r\nconcerned with the physical world, while information security risk assessments consider the\r\ndigital world. However, in an OT environment, the physical and the digital are intertwined, and\r\nsignificant overlap may occur.\r\nOrganizations should, therefore, consider all aspects of risk management for safety (e.g., risk\r\nframing, risk tolerances) and the safety assessment results when carrying out risk assessments for\r\ninformation security. The personnel responsible for the information security risk assessment\r\nmust be able to identify and communicate identified risks that could have safety implications.\r\nConversely, the personnel charged with safety assessments must be familiar with the potential\r\nphysical impacts and their likelihood.\r\nSafety systems may reduce the impact of a cyber incident on the OT and are often deployed to\r\nperform specific monitoring and control functions to ensure the safety of people, the\r\nenvironment, processes, and assets. While these systems are traditionally implemented to be\r\nfully redundant and independent from the primary OT, some architectures combine control and\r\nsafety functions, components, or networks. Combining control and safety could allow a\r\nsophisticated attacker access to both control and safety systems if the OT were compromised.\r\nOrganizations should ensure the adequate separation of components consistent with the risk of\r\ncompromise and evaluate the impact of the implemented security controls on the safety system to\r\ndetermine whether they negatively impact the system.\r\n Applying the Risk Management Framework to OT Systems\r\nThe NIST Risk Management Framework (RMF) applies the risk management process and\r\nconcepts (i.e., framing risk, assessing risk, responding to risk, and monitoring risk) to systems\r\nand organizations. The following subsections describe the process of applying the RMF to OT\r\nand include a brief description of each step and task, the intended outcome of each task, task\r\nmappings to other standards and guidelines applicable to OT (e.g., the Cybersecurity Framework\r\nand IEC 62443), and OT-specific implementation guidance. Some tasks are optional, and not all\r\ntasks include OT-specific considerations or guidance.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n56\r\nThe RMF steps in Fig. 15, while shown sequentially, can be implemented in a different order to\r\nbe consistent with established management and system development life cycle processes.\r\n \r\nCategorize\r\nSystem\r\nSelect\r\nControls\r\nImplement\r\nControls\r\nAssess\r\nControls\r\nAuthorize\r\nSystem\r\nMonitor\r\nControls\r\nPrepare*\r\nFig. 15. Risk Management Framework steps\r\n4.3.1. Prepare\r\nThe purpose of the Prepare step is to carry out essential activities at the organizational, mission\r\nand business process, and system levels to help the organization manage its security and privacy\r\nrisks using the RMF. The Prepare step leverages activities that are already being conducted\r\nwithin cybersecurity programs to emphasize the importance of having organization-wide\r\ngovernance and resources in place to support risk management. Table 6 provides details on\r\napplying the Prepare step to OT.\r\nTable 6. Applying the RMF Prepare step to OT\r\nTasks Outcomes OT-Specific Guidance\r\nOrganizational and Mission and Business Process Levels\r\nTASK P-1\r\nRISK MANAGEMENT ROLES\r\nIndividuals are identified and assigned key\r\nroles for executing the RMF.\r\n[Cybersecurity Framework: ID.AM-6;\r\nID.GV-2]\r\n[IEC 62443-2-1: ORG 1.3]\r\nEstablish and maintain personnel\r\ncybersecurity roles and\r\nresponsibilities for both IT and\r\nOT systems. Include\r\ncybersecurity roles and\r\nresponsibilities for third-party\r\nproviders. Examples of OT\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n57\r\nTasks Outcomes OT-Specific Guidance\r\npersonnel include the\r\nProcess/Plant Manager, Process\r\nControl Engineer, Operator,\r\nFunctional Safety Engineer,\r\nMaintenance Personnel, and\r\nProcess Safety Manager.\r\nTASK P-2\r\nRISK MANAGEMENT\r\nSTRATEGY\r\nA risk management strategy for the\r\norganization that includes a determination and\r\nexpression of organizational risk tolerance is\r\nestablished.\r\n[Cybersecurity Framework: ID.RM; ID.SC]\r\n[IEC 62443-2-1: ORG 2.1]\r\nThe risk management strategy\r\nencompasses the whole\r\norganization. Consider the unique\r\nregulatory requirements as it\r\nrelates to organizations with OT\r\nsystems.\r\nTASK P-3\r\nRISK ASSESSMENT—\r\nORGANIZATION\r\nAn organization-wide risk assessment is\r\ncompleted, or an existing risk assessment is\r\nupdated.\r\n[Cybersecurity Framework: ID.RA; ID.SC-2]\r\n[IEC 62443-2-1: Event1.9; ORG 1.3; 2.1]\r\n \r\nTASK P-4\r\nORGANIZATIONALLY\r\nTAILORED CONTROL\r\nBASELINES AND\r\nCYBERSECURITY\r\nFRAMEWORK PROFILES\r\n(OPTIONAL)\r\nOrganizationally tailored control baselines\r\nand/or Cybersecurity Framework profiles are\r\nestablished and made available.\r\n[Cybersecurity Framework: Profile]\r\nAn organizationally tailored\r\ncontrol baseline for OT systems\r\ncan be developed to address\r\nmission and business needs,\r\nunique operating environments,\r\nand/or other requirements.\r\nTASK P-5\r\nCOMMON CONTROL\r\nIDENTIFICATION\r\nCommon controls that are available for\r\ninheritance by organizational systems are\r\nidentified, documented, and published.\r\nCommon controls available for\r\ninheritance may adversely impact\r\nOT system operation. Consider\r\nwhether common controls can be\r\napplied to OT systems\r\neffectively, safely, and without\r\nadverse impacts on OT system\r\noperation.\r\nTASK P-6\r\nIMPACT-LEVEL\r\nPRIORITIZATION\r\n(OPTIONAL)\r\nA prioritization of organizational systems with\r\nthe same impact level is conducted.\r\n[Cybersecurity Framework: ID.AM-5]\r\n[IEC 62443-2-1: DATA 1.1]\r\nCriteria such as safety or critical\r\nservice delivery can be used in\r\nthe impact-level prioritization.\r\nTASK P-7\r\nCONTINUOUS MONITORING\r\nSTRATEGY – ORGANIZATION\r\nAn organization-wide strategy for monitoring\r\ncontrol effectiveness is developed and\r\nimplemented.\r\n[Cybersecurity Framework: DE.CM; ID.SC-4]\r\n[IEC 62443-2-1: EVENT 1.1; COMP 2.2\r\nUSER 1.06; EVENT 1.1.; ORG2.2\r\n \r\nSystem-Level\r\nTASK P-8\r\nMISSION OR BUSINESS\r\nFOCUS\r\nMissions, business functions, and mission and\r\nbusiness processes that the system is intended\r\nto support are identified.\r\n[Cybersecurity Framework: Profile;\r\nImplementation Tiers; ID.BE]\r\n[IEC 62443-2-1: ORG1.6; AVAIL 1.2;\r\nAVAIL 1.1]\r\nWhen mapping OT and IT\r\nprocesses, the information flows\r\nand protocols should also be\r\ndocumented.\r\nTASK P-9\r\nSYSTEM STAKEHOLDERS\r\nThe stakeholders with an interest in the system\r\nare identified.\r\nExample OT personnel include\r\nthe Process/Plant Manager,\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n58\r\nTasks Outcomes OT-Specific Guidance\r\n[Cybersecurity Framework: ID.AM; ID.BE] Process Control Engineer,\r\nOperator, Functional Safety\r\nEngineer, and Process Safety\r\nManager.\r\nTASK P-10\r\nASSET IDENTIFICATION\r\nStakeholder assets are identified and\r\nprioritized.\r\n[Cybersecurity Framework: ID.AM]\r\nOT system components can\r\ninclude PLCs, sensors, actuators,\r\nrobots, machine tools, firmware,\r\nnetwork switches, routers, power\r\nsupplies, and other networked\r\ncomponents or devices.\r\nTASK P-11\r\nAUTHORIZATION\r\nBOUNDARY\r\nThe authorization boundary (i.e., system) is\r\ndetermined.\r\nTASK P-12\r\nINFORMATION TYPES\r\nThe types of information processed, stored,\r\nand transmitted by the system are identified.\r\n[Cybersecurity Framework: ID.AM-5]\r\n \r\nTASK P-13\r\nINFORMATION LIFE CYCLE\r\nAll stages of the information life cycle are\r\nidentified and understood for each information\r\ntype processed, stored, or transmitted by the\r\nsystem.\r\n[Cybersecurity Framework: ID.AM-3;\r\nID.AM-4]\r\n \r\nTASK P-14\r\nRISK ASSESSMENT – SYSTEM\r\nA system-level risk assessment is completed,\r\nor an existing risk assessment is updated.\r\n[Cybersecurity Framework: ID.RA; ID.SC-2]\r\nRisk assessments, including\r\nperformance/load testing and\r\npenetration testing, are conducted\r\non the OT systems with care to\r\nensure that OT operations are not\r\nadversely impacted by the testing\r\nprocess.\r\nTASK P-15\r\nREQUIREMENTS DEFINITION\r\nSecurity and privacy requirements are defined\r\nand prioritized.\r\n[Cybersecurity Framework: ID.GV; PR.IP]\r\n \r\nTASK P-16\r\nENTERPRISE ARCHITECTURE\r\nThe placement of the system within the\r\nenterprise architecture is determined.\r\nGroup OT components by\r\nfunction or sensitivity level to\r\noptimize cybersecurity control\r\nimplementation.\r\nTASK P-17\r\nREQUIREMENTS\r\nALLOCATION\r\nSecurity and privacy requirements are\r\nallocated to the system and the environment in\r\nwhich the system operates.\r\n[Cybersecurity Framework: ID.GV]\r\nAs security and privacy\r\nrequirements are allocated to the\r\nOT system, considerations such\r\nas impact on performance and\r\nsafety are considered.\r\nTASK P-18\r\nSYSTEM REGISTRATION\r\nThe system is registered for purposes of\r\nmanagement, accountability, coordination, and\r\noversight.\r\n[Cybersecurity Framework: ID.GV]\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n59\r\n4.3.2. Categorize\r\nIn the Categorize step, the potential adverse impacts of the loss of confidentiality, integrity, and\r\navailability of the information and system are determined. For each information type and system\r\nunder consideration, the three security objectives – confidentiality, integrity, and availability –\r\nare associated with one of three levels of potential impacts of a security breach. Of the three\r\nsecurity objectives, availability is generally the greatest concern for an OT. The standards and\r\nguidance for this categorization process can be found in FIPS 199 [FIPS199] and NIST SP 800-\r\n60 [SP800-60v1r1][SP800-60v2r1], respectively.\r\nThe following OT example is taken from FIPS 199:\r\nOT-Specific Recommendations and Guidance\r\nA power plant contains a SCADA system controlling the distribution of\r\nelectric power for a large military installation. The SCADA system\r\ncontains both real-time sensor data and routine administrative\r\ninformation. The management at the power plant determines that: (i) for\r\nthe sensor data being acquired by the SCADA system, there is no\r\npotential impact from a loss of confidentiality, a high potential impact\r\nfrom a loss of integrity, and a high potential impact from a loss of\r\navailability; and (ii) for the administrative information being processed\r\nby the system, there is a low potential impact from a loss of\r\nconfidentiality, a low potential impact from a loss of integrity, and a low\r\npotential impact from a loss of availability. The resulting security\r\ncategories, SC, of these information types are expressed as:\r\nSC sensor data = {(confidentiality, NA), (integrity, HIGH),\r\n(availability, HIGH)}, and\r\nSC administrative information = {(confidentiality, LOW), (integrity,\r\nLOW), (availability, LOW)}.\r\nThe resulting security category of the system is initially expressed as:\r\nSC SCADA system = {(confidentiality, LOW), (integrity, HIGH),\r\n(availability, HIGH)}\r\nrepresenting the high-water mark or maximum potential impact values\r\nfor each security objective from the information types resident on the\r\nSCADA system. The management at the power plant chooses to increase\r\nthe potential impact from a loss of confidentiality from low to moderate,\r\nreflecting a more realistic view of the potential impact on the system\r\nshould there be a security breach due to the unauthorized disclosure of\r\nsystem-level information or processing functions. The final security\r\ncategory of the system is expressed as:\r\nSC SCADA system = {(confidentiality, MODERATE), (integrity,\r\nHIGH), (availability, HIGH)}\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n60\r\nTable 7 provides details on applying the RMF Categorize step to OT.\r\nTable 7. Applying the RMF Categorize step to OT\r\nTasks Outcomes OT-Specific Guidance\r\nTASK C-1\r\nSYSTEM DESCRIPTION\r\nThe characteristics of the system are described\r\nand documented.\r\n[Cybersecurity Framework: Profile]\r\n \r\nTASK C-2\r\nSECURITY\r\nCATEGORIZATION\r\nA security categorization of the system,\r\nincluding the information processed by the\r\nsystem represented by the organization-identified information types, is completed.\r\n[Cybersecurity Framework: ID.AM-1;\r\nID.AM-2; ID.AM-3; ID.AM-4; ID.AM-5]\r\nSecurity categorization results are documented\r\nin the security, privacy, and SCRM plans.\r\n[Cybersecurity Framework: Profile]\r\nSecurity categorization results are consistent\r\nwith the enterprise architecture and\r\ncommitment to protecting organizational\r\nmissions, business functions, and mission and\r\nbusiness processes.\r\n[Cybersecurity Framework: Profile]\r\nSecurity categorization results reflect the\r\norganization’s risk management strategy.\r\nOT and IT systems may have\r\ndifferent categorization criteria.\r\nSystem information and the\r\nsystem process (e.g., chemical\r\nproduction) should be considered\r\nduring the security categorization.\r\nTASK C-3\r\nSECURITY\r\nCATEGORIZATION REVIEW\r\nAND APPROVAL\r\nThe security categorization results are\r\nreviewed, and the categorization decision is\r\napproved by senior leaders in the\r\norganization.\r\n \r\n \r\n4.3.3. Select\r\nThe purpose of the Select step is to select the initial controls to protect the system commensurate\r\nwith risk. The control baselines are the starting point for the control selection process and are\r\nchosen based on the security category and associated impact level of the systems identified in the\r\nCategorize step. NIST SP 800-53B [SP800-53B] identifies the recommended control baselines\r\nfor federal systems and information. To address the need for developing community-wide and\r\nspecialized sets of controls for systems and organizations, the concept of overlays is introduced.\r\nAn overlay is a fully specified set of controls, control enhancements, and supplemental guidance\r\nderived from the application of tailoring guidance to security control baselines described in NIST\r\nSP 800-53B, Appendix C.\r\nIn general, overlays are intended to reduce the need for ad hoc tailoring of baselines by\r\norganizations through the selection of a set of controls and control enhancements that more\r\nclosely correspond to common circumstances, situations, and/or conditions. Appendix F of this\r\npublication includes an OT-specific overlay of applicable NIST SP 800-53 controls that provides\r\ntailored baselines for low-impact, moderate-impact, and high-impact OT. These tailored\r\nbaselines are starting specifications and recommendations that can be applied to specific OT by\r\nresponsible personnel.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n61\r\nOT owners can tailor the overlay from Appendix F when it is not possible or feasible to\r\nimplement specific controls. The use of overlays does not in any way preclude organizations\r\nfrom performing further tailoring (i.e., overlays can also be subject to tailoring) to reflect\r\norganization-specific needs, assumptions, or constraints. However, all tailoring activities should\r\nprimarily focus on meeting the intent of the original controls whenever possible or feasible. For\r\nexample, when the OT cannot support or the organization determines that it is not advisable to\r\nimplement particular controls or control enhancements in an OT (e.g., performance, safety, or\r\nreliability are adversely impacted), the organization should provide a complete and convincing\r\nrationale for how the selected compensating controls provide an equivalent security capability or\r\nlevel of protection for the OT and why the related baseline controls could not be employed. If the\r\nOT cannot support the use of automated mechanisms, the organization employs nonautomated\r\nmechanisms or procedures as compensating controls in accordance with the general tailoring\r\nguidance in Section 3.3 of NIST SP 800-53. Compensating controls are not exceptions or\r\nwaivers to the baseline controls. Rather, they are alternative safeguards and countermeasures\r\nemployed within the OT that accomplish the intent of the original controls that could not be\r\neffectively employed. Organizational decisions on the use of compensating controls are\r\ndocumented in the security plan for the OT.\r\nTable 8 provides additional details on applying the RMF Select step to OT.\r\nTable 8. Applying the RMF Select step to OT\r\nTasks Outcomes OT-Specific Guidance\r\nTASK S-1\r\nCONTROL SELECTION\r\nControl baselines necessary to protect the\r\nsystem commensurate with risk are selected.\r\n[Cybersecurity Framework: Profile]\r\nOT systems can leverage the OT\r\ncontrol baselines identified in\r\nAppendix F as a starting point or an\r\norganization-defined control\r\nselection approach.\r\nTASK S-2\r\nCONTROL TAILORING\r\nControls are tailored to produce specific\r\ncontrol baselines.\r\n[Cybersecurity Framework: Profile]\r\nDue to operational or technical\r\nconstraints, it may not be feasible\r\nto implement certain controls.\r\nOrganizations should consider the\r\nuse of compensating controls to\r\nmanage risk to an acceptable level.\r\nTASK S-3\r\nCONTROL ALLOCATION\r\nControls are assigned as system-specific,\r\nhybrid, or common controls. Controls are\r\nallocated to the specific system elements\r\n(i.e., machine, physical, or human\r\nelements).\r\n[Cybersecurity Framework: Profile; PR.IP]\r\n \r\nTASK S-4\r\nDOCUMENTATION OF\r\nPLANNED CONTROL\r\nIMPLEMENTATIONS\r\nControls and associated tailoring actions are\r\ndocumented in security and privacy plans or\r\nequivalent documents.\r\n[Cybersecurity Framework: Profile]\r\n \r\nTASK S-5\r\nCONTINUOUS MONITORING\r\nSTRATEGY – SYSTEM\r\nA continuous monitoring strategy for the\r\nsystem that reflects the organizational risk\r\nmanagement strategy is developed.\r\n[Cybersecurity Framework: ID.GV;\r\nDE.CM]\r\nAn OT-specific continuous\r\nmonitoring strategy to measure\r\ncontrol effectiveness may be\r\nnecessary due to unique\r\noperational, environmental, and/or\r\navailability constraints.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n62\r\nTasks Outcomes OT-Specific Guidance\r\nTASK S-6\r\nPLAN REVIEW AND\r\nAPPROVAL\r\nSecurity and privacy plans reflecting the\r\nselection of controls necessary to protect the\r\nsystem and the environment of operation\r\ncommensurate with risk are reviewed and\r\napproved by the authorizing official.\r\nReview any potential impact to the\r\nOT system’s operational\r\neffectiveness and safety.\r\n \r\n4.3.4. Implement\r\nThe Implement step involves the implementation of controls in new or legacy systems. The\r\ncontrol selection process described in this section can be applied to OT from two perspectives:\r\nnew development and legacy.\r\nFor new development systems, the control selection process is applied from a requirements\r\ndefinition perspective since the systems do not yet exist and organizations are conducting initial\r\nsecurity categorizations. The controls included in the security plans for the systems serve as\r\nsecurity specifications and are expected to be incorporated into the systems during the\r\ndevelopment and implementation phases of the system development life cycle.\r\nIn contrast, the security control selection process for legacy systems is applied from a gap\r\nanalysis perspective when organizations anticipate significant changes to the systems (e.g.,\r\nduring major upgrades, modifications, or outsourcing). Since the systems already exist,\r\norganizations have likely completed the security categorization and security control selection\r\nprocesses, resulting in the establishment of previously agreed-upon controls in the respective\r\nsecurity plans and the implementation of those controls within the systems.\r\nTable 9 provides additional details on applying the RMF Implement step to OT.\r\nTable 9. Applying the RMF Implement step to OT\r\nTasks Outcomes OT-Specific Guidance\r\nTASK I-1\r\nCONTROL\r\nIMPLEMENTATION\r\nControls specified in the security and\r\nprivacy plans are implemented.\r\n[Cybersecurity Framework: PR.IP-1]\r\nSystems security and privacy engineering\r\nmethodologies are used to implement the\r\ncontrols in the system security and privacy\r\nplans.\r\n[Cybersecurity Framework: PR.IP-2]\r\nFor existing (operational) OT systems,\r\nschedule control implementation during the\r\nOT system maintenance window. A complete\r\nverification is recommended to ensure that the\r\ncontrols are not affecting or degrading the\r\nperformance and safety of the OT system.\r\nIn some cases, it may not be feasible to\r\nimmediately mitigate the risk due to\r\nscheduling issues. However, interim\r\ncompensating controls can be leveraged.\r\nTASK I-2\r\nUPDATE CONTROL\r\nIMPLEMENTATION\r\nINFORMATION\r\nChanges to the planned implementation of\r\ncontrols are documented.\r\n[Cybersecurity Framework: PR.IP-1]\r\nThe security and privacy plans are updated\r\nbased on information obtained during the\r\nimplementation of the controls.\r\n[Cybersecurity Framework: Profile]\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n63\r\n4.3.5. Assess\r\nThe Assess step of the RMF determines the extent to which the controls in the system are\r\neffective in their application and producing the desired results. NIST SP 800-53A [SP800-\r\n53Ar5] provides guidance for assessing selected controls from NIST SP 800-53 to ensure that\r\nthey are implemented correctly, operating as intended, and producing the desired outcome with\r\nrespect to meeting the security requirements of the system.\r\nTable 10 provides additional details on applying the Assess step to OT.\r\nTable 10. Applying the RMF Assess step to OT\r\nTasks Outcomes OT-Specific Guidance\r\nTASK A-1\r\nASSESSOR\r\nSELECTION\r\nAn assessor or assessment team is selected to\r\nconduct the control assessments. The appropriate\r\nlevel of independence is achieved for the assessor or\r\nassessment team selected.\r\nInclude OT system personnel and\r\noperator in the assessment team.\r\nTASK A-2\r\nASSESSMENT PLAN\r\nDocumentation needed to conduct the assessments is\r\nprovided to the assessor or assessment team.\r\nSecurity and privacy assessment plans are developed\r\nand documented. Security and privacy assessment\r\nplans are reviewed and approved to establish the\r\nexpectations for the control assessments and the level\r\nof effort required.\r\n \r\nTASK A-3\r\nCONTROL\r\nASSESSMENTS\r\nControl assessments are conducted in accordance\r\nwith the security and privacy assessment plans.\r\nOpportunities to reuse assessment results from\r\nprevious assessments to make the risk management\r\nprocess timely and cost-effective are considered.\r\nUse of automation to conduct control assessments is\r\nmaximized to increase speed, effectiveness, and\r\nefficiency of assessments.\r\nConsider the use of tabletop\r\nexercises or simulations to reduce\r\nthe impact to production OT. Use\r\nautomated tools to conduct\r\nassessments with care to ensure\r\nthat the OT system is not adversely\r\nimpacted by the testing process.\r\nTASK A-4\r\nASSESSMENT\r\nREPORTS\r\nSecurity and privacy assessment reports that provide\r\nfindings and recommendations are completed.\r\n[Cybersecurity Framework: ID.RA-1 and ID.RA-3]\r\n \r\nTASK A-5\r\nREMEDIATION\r\nACTIONS\r\nRemediation actions to address deficiencies in the\r\ncontrols implemented in the system and environment\r\nof operation are taken. Security and privacy plans are\r\nupdated to reflect the control implementation\r\nchanges made based on the assessments and\r\nsubsequent remediation actions.\r\n[Cybersecurity Framework: Profile]\r\nEnsure that remediation actions do\r\nnot negatively impact the\r\nefficiency and safe operations of\r\nOT. Consider the use of\r\ncompensating controls as one of\r\nthe remediation actions.\r\nTASK A-6\r\nPLAN OF ACTION\r\nAND MILESTONES\r\nA plan of action and milestones detailing\r\nremediation plans for unacceptable risks identified in\r\nsecurity and privacy assessment reports is developed.\r\n[Cybersecurity Framework: ID.RA-6]\r\nConsider the unique time\r\nconstraints of the OT system in the\r\nplan of action and milestones, and\r\ntake into account planned schedule\r\nmaintenance or shutdowns of the\r\nOT system.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n64\r\n4.3.6. Authorize\r\nThe Authorize step involves a management decision to authorize the operation of a system and\r\nexplicitly accept the risks to operations, assets, and individuals based on the implementation of\r\nan agreed-upon set of controls. A new system is not placed into production or operation until the\r\nsystem is authorized.\r\nTable 11 provides additional details on applying the Authorize step to OT.\r\nTable 11. Applying the RMF Authorize step to OT\r\nTasks Outcomes OT-Specific Guidance\r\nTASK R-1\r\nAUTHORIZATION\r\nPACKAGE\r\nAn authorization package is developed\r\nfor submission to the authorizing official.\r\nTASK R-2\r\nRISK ANALYSIS AND\r\nDETERMINATION\r\nA risk determination by the authorizing\r\nofficial that reflects the risk management\r\nstrategy, including risk tolerance, is\r\nrendered.\r\n \r\nTASK R-3\r\nRISK RESPONSE\r\nRisk responses for determined risks are\r\nprovided.\r\n[Cybersecurity Framework: ID.RA-6]\r\nDevelop and implement a comprehensive\r\nstrategy to manage risk to the OT system\r\nthat includes the identification and\r\nprioritization of risk responses.\r\nTASK R-4\r\nAUTHORIZATION\r\nDECISION\r\nThe authorization for the system or the\r\ncommon controls is approved or denied.\r\nOrganizations may need to determine\r\nremediation strategies when system risks\r\ndrift out of the acceptable range while\r\nconsidering OT-specific dependencies,\r\nsuch as the inability to take a system or\r\ncomponent offline until remediated.\r\nTASK R-5\r\nAUTHORIZATION\r\nREPORTING\r\nAuthorization decisions, significant\r\nvulnerabilities, and risks are reported to\r\norganizational officials.\r\nEnsure that decisions, vulnerabilities, and\r\nrisks are reported to OT and operations\r\npersonnel.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n65\r\n4.3.7. Monitor\r\nThe Monitor step continuously tracks changes to the system that may affect controls and assesses\r\ncontrol effectiveness. NIST SP 800-37, Rev. 2 provides guidance on cybersecurity continuous\r\nmonitoring [SP800-37r2].\r\nTable 12 provides additional details on applying the Monitor step to OT.\r\nTable 12. Applying the RMF Monitor step to OT\r\nTasks Outcomes OT-Specific Guidance\r\nTASK M-1\r\nSYSTEM AND\r\nENVIRONMENT CHANGES\r\nThe system and environment of operation\r\nare monitored in accordance with the\r\ncontinuous monitoring strategy.\r\n[Cybersecurity Framework: DE.CM;\r\nID.GV]\r\nLeverage the OT-specific continuous\r\nmonitoring strategy that considers\r\nperformance impacts and safety systems\r\nto be critical.\r\nTASK M-2\r\nONGOING ASSESSMENTS\r\nOngoing assessments of control\r\neffectiveness are conducted in\r\naccordance with the continuous\r\nmonitoring strategy.\r\n[Cybersecurity Framework: ID.SC-4]\r\nConduct ongoing assessments that\r\nconsider system performance and safety\r\nimpacts.\r\nTASK M-3\r\nONGOING RISK RESPONSE\r\nThe output of continuous monitoring\r\nactivities is analyzed and responded to\r\nappropriately.\r\n[Cybersecurity Framework: RS.AN]\r\nCorrelate detected event information with\r\nrisk assessment outcomes to achieve\r\nperspective on incident impact on the OT\r\nsystem.\r\nTASK M-4\r\nAUTHORIZATION\r\nPACKAGE UPDATES\r\nRisk management documents are updated\r\nbased on continuous monitoring\r\nactivities.\r\n[Cybersecurity Framework: RS.IM]\r\n \r\nTASK M-5\r\nSECURITY AND PRIVACY\r\nREPORTING\r\nA process is in place to report the\r\nsecurity and privacy posture to the\r\nauthorizing official and other senior\r\nleaders and executives.\r\n \r\nTASK M-6\r\nONGOING\r\nAUTHORIZATION\r\nAuthorizing officials conduct ongoing\r\nauthorizations using the results of\r\ncontinuous monitoring activities and\r\ncommunicate changes in risk\r\ndetermination and acceptance decisions.\r\n \r\nTASK M-7\r\nSYSTEM DISPOSAL\r\nA system disposal strategy is developed\r\nand implemented, as needed.\r\nPlanned obsolescence found in IT\r\ncomponents may not extend to OT\r\ncomponents. Consider the maintenance\r\nand repair of OT components that are\r\nrequired to be sustained beyond IT\r\ncomponent availability.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n66\r\n OT Cybersecurity Architecture\r\nWhen designing a security architecture for an OT environment, it is generally recommended to\r\nseparate the OT network(s) from the corporate network. The nature of network traffic on these\r\ntwo network types is different. For example, internet access, email, and remote access are\r\ntypically permitted on the corporate network but not allowed on OT networks. There may also be\r\ndifferences in the degree of rigor associated with corporate and OT environment change control\r\nprocedures. Additionally, using the corporate network for OT communication protocols could\r\nexpose the OT components to cyber attacks (e.g., DoS, adversary-in-the-middle or other\r\nnetwork-based attacks). Utilizing separate networks allows for greater flexibility to address\r\nsecurity and performance requirements between the two environments.\r\nPractical considerations – such as digital transformation, the cost of OT installation, or\r\nmaintaining a homogenous network infrastructure – often mean that a connection is required\r\nbetween OT and corporate or other IT networks. This connection represents additional risk, and\r\norganizations may want to minimize these connections and consider additional security controls\r\nfor them. This section outlines security strategies for organizations to consider when engineering\r\ntheir OT environments to support cybersecurity objectives.\r\n Cybersecurity Strategy\r\nThe adoption of a cybersecurity strategy can result in a more systematic implementation of risk\r\ndecisions into system development and operation. A comprehensive and accepted cybersecurity\r\nstrategy can assist an organization with consistently maintaining acceptable risk management\r\nthroughout the life cycle of an OT system.\r\nSystem security is optimized by engineering design that is based on a proactive loss prevention\r\nstrategy. Such a strategy includes planned measures that are engineered to address what can\r\nhappen rather than what is likely to happen in order to proactively identify and rid the system of\r\nweaknesses and defects that lead to security vulnerabilities, understand the certainty and\r\nuncertainty of adversarial and non-adversarial threats, and put in place the means and methods to\r\nprotect against adverse consequences. Proactive systems security engineering also includes\r\nplanning for failure regardless of whether the failure results from adversarial or non-adversarial\r\nevents and ensuring that the system is resilient to such events.\r\nOT-Specific Recommendations and Guidance\r\nWhen planning a security strategy, organizations may need to consider\r\ncritical infrastructure standards and regulatory requirements. Based on\r\nguidance from CISA, organizations may find that both IT and OT\r\nenvironments fall within the critical infrastructure sectors. These\r\nstandards and requirements are typically designed to protect critical\r\ncyber assets to support reliability and may carry additional legal\r\nobligations for the organization.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n67\r\n5.1.1. Impacts of Choosing a Cybersecurity Strategy\r\nBy consciously choosing to develop and implement a cybersecurity strategy, an organization\r\nestablishes a disciplined approach that considers all aspects of the system life cycle – from\r\nprocurement to decommissioning – with cybersecurity in mind. As a result, the organization can\r\nensure that cybersecurity goals are realized in its systems.\r\nDecisions on cybersecurity strategy should flow from a high-level understanding of the\r\noperations, objectives, and cybersecurity goals of the organization. For example, the organization\r\nmay want its systems to display certain characteristics, such as resiliency or trustworthiness. The\r\nstrategy provides a framework for incorporating those characteristics into the final systems. The\r\nstrategy can also include additional considerations, such as the flexibility to adopt new\r\ntechnologies (e.g., crypto agility, artificial intelligence [AI] and machine learning [ML]\r\ntechnologies, digital twins). Finally, the strategy can state the need for sound cybersecurity\r\npractices, such as patching or monitoring.\r\nThe cybersecurity strategy should directly impact the architectural decisions made for systems.\r\nThe existence of an architecture informed by a cybersecurity strategy increases the likelihood\r\nthat high-level cybersecurity goals will be reflected in the cybersecurity of individual systems.\r\nThe strategy provides a document and reminder of those goals when decisions are being made at\r\nthe system level.\r\nOT-Specific Recommendations and Guidance\r\nOT assets often have long life cycles and reflect massive investments in\r\noperational, reliability, and safety testing. It is sometimes neither\r\neconomically nor technically feasible to replace existing equipment and\r\napplications wholesale with newer alternatives in the short- or medium-term. Such equipment is at greater risk of attacks than equipment with\r\nthe latest versions of security features and security updates. The adoption\r\nof a cybersecurity strategy can assist an organization in understanding\r\nthe life cycle of its OT systems and adjusting its approaches to\r\nmaintaining security.\r\n5.1.2. Defense-in-Depth Strategy\r\nDefense in depth is a multifaceted strategy that integrates people, technology, and operational\r\ncapabilities to establish variable barriers across multiple layers and dimensions of the\r\norganization. Many cybersecurity architectures incorporate the principles of defense in depth. It\r\nis considered best practice and integrates into numerous standards and regulatory frameworks.\r\nThe basic concepts are to prevent single points of failure in cybersecurity defenses and to assume\r\nno single origin of threats. From this position, cybersecurity controls are organized to provide\r\nlayers of protection around the critical system and system components.\r\nOT-Specific Recommendations and Guidance\r\nA defense-in-depth strategy is particularly useful in OT environments\r\nbecause it can focus attention and defensive mechanisms on critical\r\nfunctions. Additionally, the principles of defense in depth are flexible\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n68\r\nand can be applied to a wide range of OT environments, including ICS,\r\nSCADA, Internet of Things (IoT), IIoT, and hybrid environments.\r\nDefense in depth requires an integration of people, processes, and\r\ntechnology to be effective. Additionally, cybersecurity defenses are not\r\nstatic and require changes and updates as risks change for the\r\nenvironment. To help establish and support an effective defense-in-depth\r\narchitecture, organizations should consider:\r\n• Training people to support the security environment and reduce\r\nrisky behaviors\r\n• Implementing appropriate and sustainable cybersecurity\r\ntechnology\r\n• Implementing procedures to monitor, respond, and adapt\r\ncybersecurity defenses to changing conditions\r\n5.1.3. Other Cybersecurity Strategy Considerations\r\nTraditional OT systems were designed to operate industrial processes safely and reliably without\r\nconnections to external networks. However, due to the need for business agility and cost\r\nreduction for OT infrastructures, OT systems and networks are becoming more integrated into\r\nbusiness networks and cloud infrastructures. Additionally, the introduction of IIoT systems into\r\nOT environments may have unintended cybersecurity consequences.\r\nSimilarly, cloud computing capabilities (e.g., infrastructure as a service, platform as a service,\r\nsoftware as a service, and security as a service) are increasingly being utilized by organizations.\r\nWhile the use of these capabilities to support IT services is relatively well understood, the ability\r\nto utilize these services to support OT environments may have additional availability challenges\r\nresulting from increased sensitivity to system performance levels or connection issues. As a\r\nresult, the adoption of a security architecture strategy may be impacted by the current state of\r\nexisting OT environments. For example, based on the architectural strategy, procurement\r\ndecisions might be adjusted to include migrating specific components to support the new\r\nstrategy. Organizations may also find that existing systems already support some or most of the\r\nsecurity architecture strategy, so building on these existing capabilities could accelerate the\r\nstrategy implementation. Additionally, new OT environments provide an opportunity to evaluate\r\ncyber risk early on and build cybersecurity into the design.\r\nOT-Specific Recommendations and Guidance\r\nOrganizations should ensure that their security architecture strategy\r\nprovides the required flexibility to evolve their environment while also\r\ncarefully considering the impacts to operations and cybersecurity.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n69\r\n Defense-in-Depth Architecture Capabilities\r\nMany organizations are embracing digital transformation initiatives that require altering their OT\r\nenvironments and developing strategies that provide a multi-tiered information architecture by\r\nsupporting organization objectives, such as:\r\n• Maintenance of field devices, telemetry collection, or industrial-level process systems\r\n• Enhanced data collection and dissemination\r\n• Remote access\r\nOverall, integration between IT and OT is increasing as organizations adapt to changing local\r\nand global needs and requirements. Utilizing the principles of a defense-in-depth architecture to\r\nsystematically layer security controls – including people, processes, and technology – can help\r\norganizations strengthen their overall cybersecurity defenses. As a result, adversaries may find it\r\nincreasingly difficult to penetrate the environment without detection. The following sections\r\ndiscuss specific defense-in-depth layers, including topics and ideas for organizations to consider\r\nwhen developing and implementing their defense-in-depth cybersecurity architecture. The layers\r\nare:\r\n• Layer 1 – Security Management\r\n• Layer 2 – Physical Security\r\n• Layer 3 – Network Security\r\n• Layer 4 – Hardware Security\r\n• Layer 5 – Software Security\r\n5.2.1. Layer 1 – Security Management\r\nSecurity management or governance is the overarching cybersecurity program that supports the\r\nOT environment. Sections 3 and 4 discuss the program and risk management considerations for\r\norganizations to establish their cybersecurity programs. These programmatic and organizational\r\ndecisions will guide and impact the decisions made for the other defense-in-depth layers. As a\r\nresult, organizations should complete this layer before attempting to implement the other layers.\r\n5.2.2. Layer 2 – Physical Security\r\nPhysical security measures are designed to reduce the risk of accidental or deliberate loss or\r\ndamage to assets and the surrounding environment. Safeguarded assets may include control\r\nsystems, tools, equipment, the environment, the surrounding community, and intellectual\r\nproperty, including proprietary data (e.g., process settings and customer information).\r\nOrganizations may also need to consider additional environmental, safety, regulatory, legal, and\r\nother requirements when implementing physical security.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n70\r\nA defense-in-depth solution to physical security should consider the following attributes:\r\n• Protection of physical locations. Classic physical security considerations typically\r\ninclude an architecture of layered security measures that create several physical barriers\r\naround buildings, facilities, rooms, equipment, and other informational assets. Physical\r\nsecurity controls should be implemented to protect physical locations and may include\r\nfences, anti-vehicle ditches, earthen mounds, walls, reinforced barricades, gates, door and\r\ncabinet locks, guards, or other measures.\r\n• Physical access control. Equipment cabinets should be locked when not required for\r\noperation or safety, and wiring should be neat and contained within cabinets or under\r\nfloors. Additionally, consider keeping all computing and networking equipment in\r\nsecured areas. Keys of OT assets, like PLCs and safety systems, should be in the “Run”\r\nposition at all times unless they are being actively programmed.\r\n• Access monitoring systems. Access monitoring systems include electronic surveillance\r\ncapabilities, such as still and video cameras, sensors, and identification systems (e.g.,\r\nbadge readers, biometric scanners, electronic keypads). Such devices do not typically\r\nprevent access to a particular location. Rather, they store and record either the physical\r\npresence or the lack of physical presence of individuals, vehicles, animals, or other\r\nphysical entities. Adequate lighting should be provided based on the type of access\r\nmonitoring device deployed. These systems can also sometimes alert or initiate action\r\nupon the detection of unauthorized access.\r\n• People and asset tracking. Locating people and vehicles in a facility can be important\r\nfor both safety and security reasons. Asset location technologies can be used to track the\r\nmovements of people and vehicles to ensure that they stay in authorized areas, to identify\r\npersonnel who may need assistance, and to support emergency response.\r\nOT-Specific Recommendations and Guidance\r\nOrganizations should consider whether the physical security of remote\r\nassets is implemented at differing levels and whether those differences\r\ncould create cyber risks. For example, one remote location may utilize\r\nonly a padlock with minimal electronic surveillance to secure access to\r\nnetwork equipment that, if bypassed, could allow a malicious actor to\r\ngain access to an OT network segment from the remote location.\r\nOrganizations should also consider whether secondary services, such as\r\nthe communications and power that support physical security devices\r\n(e.g., cameras, sensors, etc.), require additional redundancy, isolation,\r\nprotection, and monitoring.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n71\r\n5.2.3. Layer 3 – Network Security\r\nBuilding from physical security, organizations should investigate network communications and\r\nhow to protect the data and devices used to support their OT environment. This section focuses\r\non several foundational elements to assist organizations with planning and implementing their\r\nnetwork security capabilities. These include applying the network architecture principles of\r\nsegmentation and isolation, centralizing logging, network monitoring, and malicious code\r\nprotection. Additionally, this section discusses zero trust architecture (ZTA) and considerations\r\nfor applying these architecture enhancements to an OT environment.\r\n5.2.3.1. Network Architecture\r\nA good practice for network architectures is to characterize, segment, and isolate IT and OT\r\ndevices. For example, devices may be segmented based on management authority, level of trust,\r\nfunctional criticality, data flow, location, or other logical combinations. Organizations may also\r\nconsider using an industry-recognized model to organize their OT network segmentation, such as\r\nthe Purdue model [Williams], ISA-95 levels [IEC62264], the three-tier IIoT system architecture\r\n[IIRA19], or a combination of these models.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n72\r\nAdditional, organizations may consider incorporating a DMZ as an enforcement boundary\r\nbetween network segments, as depicted in Fig. 16. Implementing network segmentation utilizing\r\nlevels, tiers, or zones allows organizations to control access to sensitive information and\r\ncomponents while also considering operational performance and safety.\r\n \r\n \r\nFig. 16. High-level example of the Purdue model and IIoT model for network segmentation with DMZ\r\nsegments\r\nOT-Specific Recommendations and Guidance\r\nWhether using a risk-based approach, functional model, or other\r\norganizing principle, grouping components into levels, tiers, or zones is a\r\nprecursor activity before organizations can consider applying isolation\r\ndevices to protect and monitor communications between levels, tiers, or\r\nzones. When organizing assets, organizations should consider how the\r\nzone and isolation configuration impact their day-to-day operations,\r\nsafety, and response capabilities.\r\nWhen properly configured, network architectures support segmentation and isolation by\r\nenforcing security policies and controlling network communications. Organizations typically\r\nutilize their mapped data flows to identify required communications. These requirements are\r\nthen incorporated into the network architecture and configured into the policy engines of the\r\nnetwork devices to support monitoring communication between segments and permitting only\r\nauthorized communications. Network devices that support traffic enforcement capabilities (e.g.,\r\nswitches, routers, firewalls, and unidirectional gateways or data-diodes) can be used to\r\nimplement network segmentation and isolation.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n73\r\nFirewalls are commonly used to support network isolation and employed as boundary protection\r\ndevices to control connections and information flows between network segments. Firewalls may\r\nbe deployed as network devices or directly run on some hosts. Firewalls are very flexible\r\nisolation devices and typically constitute the primary mechanism for protecting OT devices.\r\nOT-Specific Recommendations and Guidance\r\nAppropriate firewall configuration is essential to properly securing the\r\nnetwork segments. Firewall rulesets should be established to only permit\r\nconnections between adjacent levels, tiers, or zones. For example,\r\norganizations that utilize a Purdue model architecture should implement\r\nfirewall rules and connection paths that prevent Level 4 devices from\r\ndirectly communicating with Level 2, 1, or 0 devices. A similar concept\r\nwould be applied to ISA/IEC 62443 and IIC architectures.\r\nOne area of considerable variation in practice associated with firewall\r\nrules is the control of outbound traffic from the control network.\r\nAllowing outbound connections from lower levels, tiers, or zones could\r\nrepresent a significant risk if unmanaged. Organizations should consider\r\nmaking outbound rules as stringent as inbound rules to reduce these\r\nrisks.\r\nAn alternative to firewalls is a unidirectional gateway or data diode that\r\npermits authorized communication in only one direction. The use of\r\nunidirectional gateways may provide additional protections associated\r\nwith system compromises at higher levels or tiers within the\r\nenvironment. For example, a unidirectional gateway deployed between\r\nLayers 2 and 3 may protect Layer 0, 1, and 2 devices from a\r\ncybersecurity event that occurs at Layers 3, 4, or 5.\r\n5.2.3.2. Centralized Logging\r\nNetwork and computing devices (e.g., routers, gateways, switches, firewalls, servers, and\r\nworkstations) should be configured to log events to support monitoring, alerting, and incident\r\nresponse analysis. Logging capabilities are typically available for recording events in\r\napplications, OSs, and network communications. A centralized log management platform can\r\nassist organizations with supporting log retention, monitoring, and analysis efforts.\r\nOT-Specific Recommendations and Guidance\r\nOrganizations should review their available logging capabilities and\r\nconfigure them to record the operational and cybersecurity events that\r\nare appropriate for their environment.\r\nOrganizations should establish how long event logs should be retained\r\nand ensure that adequate storage is available to support log retention\r\nrequirements.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n74\r\n5.2.3.3. Network Monitoring\r\nNetwork monitoring involves reviewing alerts and logs and analyzing them for signs of possible\r\ncybersecurity incidents. Tools and capabilities that support behavior anomaly detection (BAD),\r\nsecurity information and event management (SIEM), intrusion detection systems (IDS), and\r\nintrusion prevention systems (IPS) can assist organizations with monitoring traffic throughout\r\nthe network and generate alerts when they identify anomalous or suspicious traffic. Some other\r\ncapabilities to consider for network monitoring include:\r\n• Asset management, including discovering and inventorying devices connected to the\r\nnetwork\r\n• Baselining typical network traffic, data flows, and device-to-device communications\r\n• Diagnosing network performance issues\r\n• Identifying misconfigurations or malfunctions of networked devices\r\nOrganizations may also want to consider incorporating additional services and capabilities, such\r\nas threat intelligence monitoring, to assist with establishing and maintaining an effective network\r\nmonitoring capability.\r\nOT-Specific Recommendations and Guidance\r\nOT system traffic is typically more deterministic (i.e., repeatable,\r\npredictable, and designed) than IT network traffic, which can leveraged\r\nto support network monitoring for anomaly and error detection.\r\nOrganizations should understand the normal state of the OT network as a\r\nprerequisite for implementing network security monitoring to help\r\ndistinguish attacks from transient conditions or normal operations within\r\nthe environment. Implementing network monitoring in a passive (e.g.,\r\nlisten or learning) mode and analyzing the information to differentiate\r\nbetween known and unknown communication may be a necessary first\r\nstep in implementing network security monitoring.\r\nOrganizations should consider the effects of encrypted network\r\ncommunications on their network monitoring capabilities and\r\ndeployment strategies. For example, a BAD system or IDS may be\r\nunable to determine whether encrypted network communication is\r\nmalicious and could generate false positive or negative alerts for the\r\ntraffic. Changing the data collection point to capture network traffic\r\nbefore or after encryption (e.g., using host-based network monitoring\r\ntools) could help improve monitoring capabilities when encrypted\r\ncommunication is expected.\r\nIDS and IPS products are effective at detecting and preventing well-known internet attacks, and some IDS and IPS vendors have\r\nincorporated attack signatures for various OT protocols, such as Modbus,\r\nDistributed Network Protocol 3 (DNP3), and Inter-Control Center\r\nCommunications Protocol (ICCP). An effective IDS/IPS deployment\r\ntypically involves both host-based and network-based capabilities.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n75\r\nOrganizations should consider the impact that automated responses\r\nassociated with IPS may have on the OT environment before deploying.\r\nIn some cases, organizations may consider placing IPS units at higher\r\nlevels in the environment (e.g., the DMZ interfaces) to minimize\r\npotential issues with automated responses impacting OT.\r\nIn OT environments, network-based monitoring capabilities are typically\r\ndeployed on boundary protection devices using switched port analyzer\r\n(SPAN) ports or passive network taps. Organizations should also\r\nconsider deploying host-based monitoring capabilities on compatible OT\r\ndevices – such as HMIs, SCADA servers, and engineering workstations\r\n– to improve monitoring capabilities, provided that the addition of the\r\ntools does not adversely impact operational performance or safety.\r\n5.2.3.4. Zero Trust Architecture (ZTA)\r\nA ZTA is a cybersecurity paradigm that focuses on protecting resources (e.g., information\r\nservices, data) based on the premise that authorization decisions are made closer to the resource\r\nbeing requested and are continuously evaluated rather than implicitly granted [SP800-207].\r\nConventional network security focuses on segmentation and perimeter defenses. Once inside the\r\nnetwork perimeter, users are typically considered “trusted” and often given broad access to\r\naccessible resources. As a result, boundary protection devices between zones do not mitigate\r\nlateral movement risks within a zone. Additionally, with the growing prevalence of distributed\r\ncomputing, wireless and cellular communications, and cloud and hybrid-cloud environments,\r\ntraditional network perimeters and boundaries are becoming less defined. For these situations,\r\norganizations might consider incorporating the principles of zero trust into their security\r\narchitecture.\r\nSome challenges to implementing a ZTA include:\r\n• Organizations may not find a suitable single solution for a ZTA and may instead need to\r\nintegrate several technologies with varying maturity levels to support their environment.\r\n• Implementing zero trust principles into an existing environment may require more\r\ninvestments in time, resources, and technical ability.\r\nOT-Specific Recommendations and Guidance\r\nSome OT components (e.g., PLCs, controllers, HMI) may not support\r\nthe technologies or protocols required to fully integrate with a ZTA\r\nimplementation. As a result, a ZTA implementation might not be\r\npractical for some OT devices. Instead, organizations should consider\r\napplying a ZTA to compatible devices, such as those typically found at\r\nthe functionally higher levels of the OT architecture (e.g., Purdue model\r\nLevels 3, 4, 5, and the OT DMZ).\r\nOrganizations may also want to consider whether any adverse impacts\r\nmight occur, such as if the ZTA solution increases the latency to respond\r\nto resource requests or if one or more ZTA components become\r\nunavailable. Based on this analysis, organizations should consider\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n76\r\nadjusting the ZTA implementations to minimize latency and ensure\r\nadequate redundancy to minimize risks to OT and safety operations.\r\nAnother important aspect of ZTA implementations is the identity of\r\nperson and non-person entities accessing resources. Within OT\r\nenvironments, shared credentials may be utilized, which could impact\r\nthe ability to fully implement a ZTA solution.\r\n5.2.4. Layer 4 – Hardware Security\r\nHardware security protection mechanisms provide the foundation for supporting security and\r\ntrust for the devices within an environment. Once device trust is established, the state must be\r\nmaintained and tracked in accordance with the system model and policy. To support these\r\ncapabilities, some vendors provide embedded technology, such as the Trusted Platform Module\r\n(TPM), or hardware implementation for the Advanced Encryption Standard (AES) and the\r\nSecure Hash Algorithm (SHA). Overall, hardware security capabilities enhance endpoints to\r\nprovide specific function and security requirements, including:\r\n• Monitoring and analysis\r\n• Secure configuration and management\r\n• Endpoint hardening\r\n• Integrity protection\r\n• Access control\r\n• Device identity\r\n• Root of trust\r\n• Physical security\r\nOT-Specific Recommendations and Guidance\r\nOrganizations should review available hardware security and automated\r\ncapabilities to determine how they can support OT environments without\r\nimpacting operational performance, safety, or capabilities.\r\n5.2.5. Layer 5 – Software Security\r\nSoftware security protection mechanisms provide organizations with capabilities to ensure that\r\napplications and services supporting OT are used and maintained properly. Overall, software\r\nsecurity capabilities can enhance endpoint security when organizations incorporate:\r\n• Application allowlisting\r\n• Patching\r\n• Secure code development\r\n• Configuration management, including application hardening\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n77\r\n5.2.5.1. Application Allowlisting\r\nApplication allowlisting technologies provide an additional protection mechanism on hosts by\r\nrestricting which applications are allowed to execute. When properly configured, non-authorized\r\napplications will not execute on the host environment.\r\nOT-Specific Recommendations and Guidance\r\nThe relatively static nature of OT environments presents an opportunity\r\nfor organizations to include application allowlisting as part of their\r\ndefense-in-depth strategy and is a recommended best practice by DHS.\r\nWhen considering application allowlisting within an OT environment,\r\norganizations should coordinate with their vendors and review available\r\nimplementation guidance, such as NIST SP 800-167, Guide to\r\nApplication Whitelisting [SP800-167]; Guidelines for Application\r\nWhitelisting in Industrial Control Systems; or relevant guidance for their\r\nindustry. The configurations and policies should be thoroughly tested\r\nbefore being deployed to ensure that the rules and settings properly\r\nsupport organizational security objectives.\r\n5.2.5.2. Patching\r\nPatches have two main purposes: to address vulnerabilities and to enhance functionality. In the\r\ncontext of defense-in-depth software security, patching is associated with reducing\r\nvulnerabilities. As a result, patch management is a defense-in-depth capability that supports\r\nvulnerability management as part of an organizational risk management strategy.\r\nDeploying patches to OT environments requires additional considerations for organizations,\r\nincluding testing and validation to ensure that the patches do not impact operational capabilities\r\nor safety. OT operational requirements can also impact the frequency with which patches are\r\napplied. For example, some OT environments must run nearly continuously for extended periods\r\nof time or have small maintenance windows for applying approved updates. Additionally,\r\npatching older OT components that run on unsupported OSs may not be an option. In these\r\ncases, organizations may want to consider updating their OSs or investing in additional controls\r\nthat can protect the environment from attempts to exploit known vulnerabilities. Some tools,\r\nsuch as web application firewalls (WAF) and IPS, could be configured to provide additional\r\nprotection to detect or prevent attacks against unpatched vulnerabilities while the organization\r\nwaits for an opportunity to apply the updates. Other tools, such as bump-in-the-wire security\r\ndevices, can be installed in line with devices that cannot be updated or are using obsolete\r\noperating systems.\r\nOT-Specific Recommendations and Guidance\r\nWhenever possible, patches should be tested on a sandbox system (i.e.,\r\ntest environment) to ensure that they do not cause problems before being\r\ndeployed into a production system. Organizations should plan patches\r\nand updates during scheduled maintenance windows for the environment\r\nand have a recovery plan for the OT component or system being patched.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n78\r\nOrganizations should also consider that different levels, tiers, and zones\r\nmay have different availability requirements and, as such, may have\r\ndifferent abilities to support patching. Whenever possible, organizations\r\nshould prioritize patching components within DMZ environments and\r\nwhen vulnerabilities exist that impact availability and integrity or would\r\nallow unauthorized remote access to the OT environment.\r\n5.2.5.3. Secure Code Development\r\nOrganizations that develop in-house systems and components should incorporate policies and\r\nprocedures that support and validate secure code development practices into the cybersecurity\r\nprogram. The software development life cycle (SDLC) should include security during each phase\r\nof software development. This should include security reviews and coding techniques for each of\r\nthe following processes:\r\n• Using or developing tools to audit and automate secure code techniques\r\n• Testing and reviewing code to comply with secure coding practices\r\n• Testing the software for security errors in programming\r\nFor organizations that procure components or services from third parties, reviewing these same\r\npractices should be considered prior to executing contracts with vendors. Organizations can help\r\nindustries move toward more secure products by requesting these practices in their service-level\r\nagreements and procurement actions.\r\n5.2.5.4. Configuration Management\r\nApplying configuration management practices that support secure configurations and application\r\nhardening is important to meet organizational and regulatory security requirements. These\r\nsettings may include setting access controls to restrict access or enabling encryption to protect\r\ndata at rest or in transit. Application hardening procedures may include disabling or blocking\r\nspecific network communication ports, application features, or unnecessary services that run on\r\nthe system.\r\nEncrypting data that flows over networks (i.e., in transit) or data stored in memory and local\r\nstorage (i.e., at rest) can also be used in defending OT. Encryption prevents an attacker from\r\nviewing or modifying cleartext data streams. Because encryption and the subsequent decryption\r\nprocess use algorithms to create ciphers, encryption adds latency and may not be suitable for all\r\nOT devices. Knowing the advantages and disadvantages of encryption can help organizations\r\nmake an informed decision on where to include encryption in the defense-in-depth strategy.\r\nOT-Specific Recommendations and Guidance\r\nOrganizations should consider using encryption to support secure\r\nconnections or conduits for OT environments when the connections must\r\npass over non-OT network segments, such as the corporate network or\r\nthe internet. Virtual private network (VPN) connections should also use\r\nencryption protocols, such as Transport Layer Security (TLS) or Internet\r\nProtocol Security (IPsec), to secure the data.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n79\r\nEncryption can also be used on hard local storage to protect information\r\nat rest. Full disk encryption is recommended for portable laptops and\r\ndevices. Organizations may also want to consider encrypting folders that\r\ncontain sensitive files.\r\nOrganizations must also consider that encryption can negatively impact\r\nother defense tools, such as network monitoring. For example, an IDS\r\nmight not be able to determine whether an encrypted packet is malicious,\r\nresulting in either false-positive or false-negative alerts.\r\nOrganizations should also create procedures to manage changes to\r\ncontrol logic to protect against the risk that improperly tested or\r\nmalicious changes to logic could disrupt the system.\r\n Additional Cybersecurity Architecture Considerations\r\nOrganizations should include considerations for supporting cyber-related safety, availability,\r\ngeographically distributed systems, environmental considerations, and regulatory requirements\r\ninto the security architecture designs and implementations for OT and IIoT environments. The\r\nfollowing subsections discuss these considerations in more detail.\r\n5.3.1. Cyber-Related Safety Considerations\r\nOT systems are generally designed with specific safety goals, depending on both the business\r\nenvironment and regulatory requirements. Organizations should consider whether the additional\r\ncommunication and cybersecurity requirements of safety systems (e.g., segmentation and the\r\nisolation of safety systems from other OT systems) is required. Additionally, safety requirements\r\ncan influence the selection of security mechanisms. For example, safety considerations may\r\nrequire that an organization use physical separation as opposed to logical separation.\r\nOT systems typically employ fail-to-a-known-state design (i.e., fail-safe design) in the event of\r\nan unexpected situation or a component failure. Fail-safe design considers placing the equipment\r\nor process in a safe state that prevents injury to individuals or the destruction of property and\r\navoids cascading events or secondary hazards. Cyber-related events, such as the loss of network\r\ncommunications, could trigger these fail-safe events. To minimize false positives, organizations\r\nshould define the thresholds at which OT components can operate with reduced or disrupted\r\ncapabilities, such as lost network communications.\r\n5.3.2. Availability Considerations\r\nOperational continuity management requires managing availability at multiple levels, including\r\ndata, applications, IT infrastructure, power, and other supporting utilities (e.g., HVAC, water,\r\nsteam, compressed air, etc.). The failure of these systems can have a cascading effect on OT\r\nsystems and can adversely impact the OT operation. Different availability considerations are\r\npresented below.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n80\r\n5.3.2.1. Data, Applications, and Infrastructure\r\nArchitecture requirements and design should support the redundancy needs of OT systems.\r\nAvailability can be enhanced using redundancy at the communication, system, or component\r\nlevel such that a single failure is less likely to result in a capability or information outage.\r\nCybersecurity architecture should consider any redundant communication and protect it to the\r\nsame security level as the primary.\r\nAdditionally, a data backup and restoration process will facilitate the speedy recovery of systems\r\nif data is lost due to cyber attacks or other reasons. Examples of important data and files are\r\noperational data, program files, configuration files, system images, firewall rules, and access\r\ncontrol lists (ACLs). A “backup-in-depth” approach with multiple layers of backups (e.g., local,\r\nfacility, disaster) that are time-sequenced such that rapid recent local backups are available for\r\nimmediate use and secure backups are available to recover from a massive security incident (e.g.,\r\nransomware attack) can help improve OT system availability. Periodically testing data backup\r\nand restore capabilities will ensure their availability when the need arises.\r\n5.3.2.2. Primary and Alternate Power Sources\r\nArchitectural considerations should include the impact of power outages on OT systems. For\r\nexample, if the OT systems need a graceful degradation or orderly shutdown, then an alternate\r\nbackup power may be considered. In addition, if the organization’s business continuity plan\r\nrequires that the OT systems continue operating in the event of an extended loss of the primary\r\npower source, a long-term alternate power supply for the OT systems that is self-contained and\r\nnot reliant on external power generation can be implemented. The monitoring and controls\r\nsystems for the power system are vulnerable to cyber attacks, so appropriate cybersecurity\r\npractices should be implemented.\r\n5.3.2.3. Other Utilities\r\nIndustrial facilities typically have monitoring and controls systems that manage uninterruptable\r\npower supplies (UPSs), generators, HVAC, fire alarm systems, boilers, cooling water plant,\r\nsteam, compressed air, and other critical functions. These monitoring and controls systems are\r\nalso vulnerable to cyber attacks and can affect the OT systems, so appropriate cybersecurity\r\npractices should be implemented to protect them.\r\nOT-Specific Recommendations and Guidance\r\nDisaster recovery planning is another important activity for OT systems,\r\nespecially when there are safety concerns. Organizations should establish\r\nand maintain a disaster recovery plan (DRP) that details the actions to\r\ntake before, during, and after a natural, environmental, or human-caused\r\n(intentionally or unintentionally) disaster. The DRP should also include\r\ninstructions for restoring and restarting failed components and\r\nintegrating them back into operation. Organizations should consider\r\ntesting the DRP to ensure that the necessary architecture capabilities can\r\nbe operationalized in an actual disaster recovery scenario. Tabletop\r\nexercises can also be used to simulate a disaster recovery event to\r\nsupport testing.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n81\r\n5.3.3. Geographically Distributed Systems\r\nMany critical infrastructure industries have sites that are geographically distributed.\r\nOrganizations should consider whether differences in physical security at remote locations create\r\nrisks to the OT operational capabilities or safety. The necessary cybersecurity and\r\ncommunication infrastructure should be provided at the remote sites to protect them from cyber\r\nthreats and to communicate cybersecurity monitoring information.\r\nOT-Specific Recommendations and Guidance\r\nThe communication between sites should be encrypted and authenticated\r\nend to end, whether the connection is via point-to-point link, satellite, or\r\ninternet. Organizations should also ensure that adequate bandwidth is\r\nprovisioned for collecting cyber monitoring data in addition to the\r\noperational data from remote locations.\r\nIf the organization has several geographically dispersed sites, it should\r\nconsider whether security operation will be managed from a central\r\nsecurity operations center (SOC) or regionally distributed SOCs. The\r\navailability of qualified personnel can impact these decisions.\r\n5.3.4. Regulatory Requirements\r\nRegulated industries must consider cyber-related regulatory requirements when designing their\r\ncybersecurity architecture. For example, NERC Standard CIP-005 (see Appendix D.1.9)\r\nprovides cybersecurity architecture requirements for bulk electric systems. Similar requirements\r\nand guidance exist for other regulated industries.\r\n5.3.5. Environmental Considerations\r\nOrganizations should conduct a hazard analysis to determine whether any of their processes or\r\nequipment pose environmental hazards. If potential environmental hazards due to cybersecurity\r\nfailure have been identified, organizations should consider architectural measures to prevent\r\nthem.\r\n5.3.6. Field I/O (Purdue Level 0) Security Considerations\r\nMany of the devices and the communication protocols at the Field I/O level (Purdue Level 0)\r\n(e.g., sensors, actuators) cannot be authenticated. Without authentication, there is the potential to\r\nreplay, modify, or spoof data. Organizations should make a risk-based decision to decide where\r\nwithin the OT system (e.g., the most critical process) the use of mitigating security controls (e.g.,\r\ndigital twins, separate Field I/O monitoring network) should be implemented to detect incorrect\r\ndata.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n82\r\n5.3.7. Additional Security Considerations for IIoT\r\nThe introduction of IIoT to OT environments can increase connectivity and information\r\nexchanges with enterprise systems and cloud-based systems, which may require additional\r\nconsiderations for the security architecture. For example, the introduction of IIoT devices in OT\r\nenvironments may require altering boundaries or exposing more interfaces and services.\r\nAdditionally, the security capabilities of IIoT devices may need to be considered when\r\ndeveloping the security architecture.\r\nOT-Specific Recommendations and Guidance\r\nOrganizations may need to consider the impacts of supporting IIoT on\r\npolicy management, enforcement, and governance. Additionally, the\r\nintegration of IIoT into OT environments may require a tighter\r\ncollaboration between IT and OT security teams to manage the security\r\noperations. For example, real-time situational awareness should be\r\nshared between IT and OT security teams.\r\n5.3.7.1. Application and Infrastructure\r\nOrganizations should consider the IIoT data flow use cases, including those that share data\r\nexternally, to determine whether additional access control mechanisms are necessary.\r\nOrganizations should also consider that the attack vectors for IIoT may be different from those\r\nmanaged for OT environments (e.g., due to increased communications requirements or the use of\r\nadditional services, such as cloud systems, to support operational requirements).\r\nOT-Specific Recommendations and Guidance\r\nOrganizations should consider the following endpoint security\r\ncapabilities of the IIoT devices being deployed:\r\n• Endpoint tamper resistance capabilities\r\n• Endpoint root of trust\r\n• Endpoint identity\r\n• Endpoint access control\r\n• Endpoint integrity protection\r\n• Endpoint data protection\r\n• Endpoint monitoring and analysis\r\n• Endpoint configuration and management\r\n• Cryptographic techniques\r\n• Capability to harden endpoints\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n83\r\n5.3.7.2. Cybersecurity Capability Considerations\r\nCompute resources – including processing, memory, and storage – vary among IIoT devices.\r\nSome IIoT devices may have constrained resources, while others may have unused capabilities,\r\nboth of which have implications for cybersecurity. Organizations should consider how the\r\nresources and capabilities available in the IIoT devices will integrate into the security\r\narchitecture to achieve their cybersecurity objectives. Additionally, organizations should\r\nconsider whether the operational and safety impacts for IIoT differ from the operational and\r\nsafety impacts for other OT devices. For example, IIoT devices may support a separate data\r\nmonitoring (i.e., read-only capability) for the environment and have minimal impact on\r\noperational controls or safety, which may allow organizations to implement security operations\r\ndifferently than those established for OT devices.\r\n Cybersecurity Architecture Models\r\nBuilding on the concepts and guidance from Sections 5.1, 5.2, and 5.3, the following subsections\r\nexpand on the general OT and IIoT environments described in Section 2 and provide examples\r\nfor how the environments might be adapted to support defense-in-depth security architectures.\r\n5.4.1. Distributed Control System (DCS)-Based OT Systems\r\nAs described in Section 2, a distributed control system (DCS) is used to control production\r\nsystems within the same geographic location for industries. Figure 17 shows an example DCS\r\nsystem implementation. Figure 18 shows an example defense-in-depth architecture applied to\r\nthe DCS system.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n84\r\n \r\nFig. 17. A DCS implementation example\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n85\r\n \r\nFig. 18. A defense-in-depth security architecture example for a DCS system\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n86\r\nIn Fig. 18, the assumption is that the organization has already addressed Layer 1 and Layer 2.\r\nFor Layer 3, the organization should consider incorporating the following capabilities into the\r\nsecurity architecture:\r\n• Separate networks into different levels or zones. In this example, the devices are split into\r\ndifferent levels based on function. The field level includes devices that are typically\r\nfound in the Purdue model levels 0, 1, and 2. The operations management level includes\r\ndevices for monitoring and managing the field level devices and the Purdue level 3\r\ncomponents. The DMZ includes devices that support bridging the operations\r\nmanagement and enterprise tiers. Organizations should also consider whether additional\r\nnetwork segments are required for safety or security systems (e.g., physical monitoring\r\nand access controls, doors, gates, cameras, Voice over Internet Protocol [VoIP], access\r\ncard readers). Network segmentation is an important step in applying a defense-in-depth\r\nstrategy.\r\n• Boundary devices (e.g., firewalls) are added to control and monitor communications\r\nbetween different levels. Industrial-class firewalls are sometimes used between the field\r\nand operations management levels to provide additional support for OT-specific\r\nprotocols or to allow devices to operate in harsh environments. Rules for both inbound\r\nand outbound communication should be defined so that only authorized communication\r\npasses between adjacent levels.\r\n• Implement a DMZ to separate the OT environment from the enterprise network. Any\r\ncommunications between the enterprise level and the operations management level are\r\nrequired to go through services within the DMZ. Since the DMZ connects to outside\r\nenvironments, the services within the DMZ must be monitored and protected to avoid\r\ncompromises that allow attackers to pivot to the OT environment without detection.\r\n• The security architecture diagram shows an IT authentication server in the enterprise\r\nnetwork to authenticate users and a separate OT authentication server in the operations\r\nmanagement network for OT users. Organizations may want to consider this approach if\r\nit supports their risk-based security objectives.\r\nFor Layer 4 and Layer 5, organizations should consider applying the principle of least\r\nfunctionality on all field, operations management, and DMZ devices to support application and\r\ndevice hardening. Organizations should identify and disable any non-essential capability,\r\nsoftware, or ports on the devices. For example, a web server or SSH server may be available in\r\nsome newer PLCs or HMIs. If these services are not used, they should be disabled, and the\r\nassociated TCP/UDP ports should be disabled as well. Only enable the functionality when\r\nrequired.\r\n5.4.2. DCS- and PLC-Based OT with IIoT\r\nBuilding on the guidance for DCS- and PLC-based OT environments in Section 5.4.1, Fig. 19\r\nshows a simplified example security architecture implementation for the DCS system with\r\nadditional IIoT devices configured to utilize a local IIoT platform for providing computing\r\ncapabilities. Due to the different communication and architectural components that support IIoT,\r\nthe example shows separate network segments for supporting the additional IIoT components.\r\nCommunication from the IIoT platform tier is routed through the DMZ border firewall to allow\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n87\r\norganizations to consider data transmission to servers in the DMZ or to the enterprise/internet as\r\nrequired to support IIoT operational requirements. Additionally, this also permits the\r\ncybersecurity services located in the DMZ to monitor the IIoT platform tier.\r\n \r\n \r\nFig. 19. A security architecture example for DCS system with IIoT devices\r\n5.4.3. SCADA-Based OT Environments\r\nFigure 20 shows an example implementation of the components and general configuration of a\r\nSCADA system. Typically, primary and backup control centers support one or more remote\r\nstations based on geographic locations, and regional control centers are geographically located to\r\nsupport one or more primary or backup control centers. Due to the distributed nature of the\r\nremote stations and control centers, communication between locations typically passes over\r\nexternal or WAN connections using wireless or wired mediums.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n88\r\n \r\nFig. 20. An example SCADA system in an OT environment\r\nFigure 21 shows an example defense-in-depth implementation for a SCADA system that\r\nassumes that the organization has already addressed Layer 1 and Layer 2. For Layer 3, the\r\norganization should consider incorporating the following capabilities in the security architecture:\r\n• Separate networks into different zones or regions, which is important for applying a\r\ndefense-in-depth strategy in a SCADA environment. Additional separation should be\r\nconsidered for security systems (e.g., physical monitoring and access controls, doors,\r\ngates, cameras, VoIP, access card readers).\r\n• Boundary devices (e.g., firewalls) are added between the different regions to control and\r\nmonitor communications between the network segments. Industrial-class stateful\r\nfirewalls may offer more support for OT-specific protocols and enhance protection for\r\nOT devices, like the PLC and controllers. Rules for inbound and outbound\r\ncommunication should be defined so that only authorized communication passes between\r\nregions.\r\n• Use secure connections (e.g., VPN tunnel, encrypted channel, point-to-point connection)\r\nbetween network segments, such as between a regional center and primary control\r\ncenters and between remote stations and control centers. For geographically distanced\r\nlocations, secure connections can be connected over the internet/WAN. Devices in the\r\nnetwork segments should only connect to other segments through the secure connection\r\nand should be restricted when accessing the internet.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n89\r\n• Implement a DMZ to separate the control centers from the enterprise network. Any\r\ncommunications between the enterprise network and the control centers must go through\r\nservices within the DMZ. Since the DMZ connects to outside environments, the services\r\nwithin the DMZ must be monitored and protected to avoid compromises within the DMZ\r\nthat might allow attackers to pivot to the OT environment without detection.\r\n \r\n \r\nFig. 21. A security architecture example for a SCADA system\r\nFor Layer 4 and Layer 5, organizations should consider applying the principle of least\r\nfunctionality to all remote station components, control center components, and DMZ devices to\r\nsupport application and device hardening. Organizations should identify and disable any non-essential capability, software, or ports on the devices. For example, a webserver or SSH server\r\nmay be available in some newer PLCs or HMIs. If these services are not used, they should be\r\ndisabled, and the associated TCP/UDP ports should be disabled. Only enable the functionality\r\nwhen required.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n90\r\n Applying the Cybersecurity Framework to OT\r\nMany public and private-sector organizations have adopted the NIST Cybersecurity Framework\r\n(CSF) [CSF] to guide cybersecurity activities and consider cybersecurity risks. The Framework\r\nconsists of five concurrent and continuous Functions – Identify, Protect, Detect, Respond, and\r\nRecover – for presenting industry standards, guidelines, and practices in a manner that allows for\r\nthe communication of cybersecurity activities and outcomes across the organization. When\r\nconsidered together, these Functions provide a high-level, strategic view for cybersecurity risk\r\nmanagement. The Framework further identifies underlying key Categories and Subcategories for\r\neach Function and matches them with example Informative References, such as existing\r\nstandards, guidelines, and practices for each Subcategory.\r\nThe five Functions include 23 Categories of cybersecurity outcomes and Subcategories that\r\nfurther divide the Categories into more specific technical or management activities. For this\r\nsection, each subsection references a CSF Function and Category and includes the CSF two-letter abbreviations for reference.\r\n \r\nThe CSF Functions guide the following actions:\r\nIdentify (ID) – Develop an organizational\r\nunderstanding to manage cybersecurity risk to\r\nsystems, people, assets, data, and capabilities.\r\nProtect (PR) – Develop and implement appropriate\r\nsafeguards to ensure delivery of critical services.\r\nDetect (DE) – Develop and implement appropriate\r\nactivities to identify the occurrence of the\r\ncybersecurity event.\r\nRespond (RS) – Develop and implement\r\nappropriate activities to take action regarding a\r\ndetected cybersecurity incident.\r\nRecover (RC) – Develop and implement\r\nappropriate activities to maintain plans for\r\nresilience and to restore any capabilities or services\r\nthat were impaired due to a cybersecurity incident.\r\nThis section discusses all CSF Functions and selected CSF Categories and Subcategories.\r\nAdditionally, some Categories include additional OT-specific considerations that are not\r\nincluded in the CSF.\r\n Identify (ID)\r\nThe Identify Function provides foundational activities to effectively use the CSF. The intended\r\noutcome of the Identify Function is to develop an organizational understanding to manage\r\ncybersecurity risks to systems, people, assets, data, and capabilities.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n91\r\n6.1.1. Asset Management (ID.AM)\r\nThe ability for organizations to properly and consistently identify and manage data, personnel,\r\ndevices, systems, and facilities based on their relative importance provides a foundational\r\ncapability to support an organizational cybersecurity program. Additionally, updating inventory\r\ninformation when components are added, removed, or changed (e.g., patched, new firmware\r\ninstalled, component swapped during maintenance) helps organizations accurately manage their\r\noverall environmental risks. Organizations should consider including the following to support\r\ntheir asset management capability:\r\n• Unique identifiers to differentiate and track assets\r\n• Hardware inventory management to track computing and network devices within the\r\nenvironment, including device details and location. Device details may include vendor,\r\nmodel, serial number, purchase information, and manufacturing/build information (e.g.,\r\nprovenance information).\r\n• Software and firmware inventory management to track the software and firmware\r\ninstalled with the OT components, including version numbers, location information, and\r\nsoftware bill of materials (SBOM)\r\n• Vendor information to establish a repository of vendor information, points of contact,\r\nwarranty information, locations of recall, and update information\r\n• Documented roles and responsibilities to identify specific individuals, teams, or\r\norganization groups who represent the asset owner and those with operation,\r\nmaintenance, and cybersecurity roles and responsibilities\r\nSupplemental guidance for ID.AM can be found in the following documents:\r\n• NIST SP 1800-5, IT Asset Management\r\n• NIST SP 800-53, Rev. 5, Security and Privacy Controls for Information Systems and\r\nOrganizations\r\nOT-Specific Recommendations and Guidance\r\nOrganizations should consider the criticality of a complete and accurate\r\nasset inventory for managing risk within the OT environment. Accurate\r\ninventory information supports multiple risk management objectives,\r\nincluding risk assessment, vulnerability management, and obsolescence\r\ntracking.\r\nWhile automated tools for supporting asset management are generally\r\npreferable, organizations should consider how the tool collects\r\ninformation and whether the collection method (e.g., active scanning)\r\nmay have a negative impact on their OT systems. Performing a test using\r\nthe automated asset management tools on offline systems or components\r\nis recommended prior to deployment within the OT production\r\nenvironment. When automated tools are not feasible due to network\r\narchitectures or other OT environment issues, the organization should\r\nconsider manual processes for maintaining a current inventory.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n92\r\n6.1.1.1. Mapping Data Flows (ID.AM-3)\r\nData flow diagrams help a manufacturer understand the flow of data between networked\r\ncomponents. Documenting data flows enables organizations to understand the expected behavior\r\nof their networks. This understanding of how devices communicate assists with troubleshooting\r\nas well as response and recovery activities. This information can be leveraged during forensic\r\nactivities or used for analysis to identify anomalies.\r\nOT-Specific Recommendations and Guidance\r\nOrganizations should consider the impact of the use of automated data\r\nflow mapping tools that use active scanning or require network\r\nmonitoring tools (e.g., in-line network probes) on OT systems. Impacts\r\ncould be due to the nature of the information, the volume of network\r\ntraffic, or the momentary disconnection of manufacturing system\r\ncomponents from the network. Consider using data flow mapping tools\r\nthat utilize these methods during planned downtime.\r\n6.1.1.2. Network Architecture Documentation (Supports the Outcome of\r\nID.AM)\r\nNetwork architecture documentation tools help a manufacturer identify, document, and diagram\r\nthe interconnections between networked devices, corporate networks, and other external\r\nconnections. A comprehensive understanding of the interconnections within the environment is\r\ncritical for the successful deployment of cybersecurity controls. This information is equally\r\nimportant for effective network monitoring.\r\nOT-Specific Recommendations and Guidance\r\nNetwork architecture documentation tools that use automated topology\r\ndiscovery technologies can only capture details from IP-based networked\r\ndevices. Many OT environments contain isolated systems, components,\r\nor systems connected on non-IP networks. The OT environment may not\r\nbe technically capable of using automated network architecture\r\ndocumentation tools, and manual processes may be required to document\r\nthese components.\r\nAsset owners may also want to consider how automated scanning\r\nactivities may potentially impact the OT system by testing automation\r\ntools in a non-production environment. Based on testing results, asset\r\nowners should consider utilizing automated OT network architecture\r\ndocumentation tools during planned downtime.\r\nOrganizations may also want to consider physically inspecting OT\r\nnetwork connections or analyzing network logs to document the OT\r\nnetwork architecture, especially if the network is not large or\r\ncomplicated. Incorporating OT network activity monitoring may help\r\norganizations identify the addition or removal of devices within the\r\nenvironment between planned scanning activities.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n93\r\n6.1.2. Governance (ID.GV)\r\nEffective governance involves organizational leadership incorporating risk management\r\nobjectives into the strategic planning process along with resiliency, privacy, and cybersecurity\r\nobjectives, as well as providing the required resources to effectively implement and sustain the\r\ncybersecurity program. From this process, organizational leadership develops and disseminates\r\npolicies that establish security requirements for their environments. These policies may include\r\nthe identification and assignment of roles, responsibilities, management commitment, and\r\ncompliance. The policies may also reflect coordination among the organizational entities\r\nresponsible for the different aspects of security (e.g., technical, physical, personnel, cyber-physical, access control, media protection, vulnerability management, maintenance, monitoring).\r\nSections 3 and 4 provide additional details for governance. Supplemental guidance for ID.GV\r\ncan be found in the following documents:\r\n• NIST SP 800-39, Managing Information Security Risk: Organization, Mission, and\r\nInformation System View\r\n• NIST SP 800-37, Rev. 2, Risk Management Framework for Information Systems and\r\nOrganizations: A System Life Cycle Approach for Security and Privacy\r\n• NIST SP 800-100, Information Security Handbook: A Guide for Managers\r\n• NIST IR 8286, Integrating Cybersecurity and Enterprise Risk Management (ERM)\r\nOT-Specific Recommendations and Guidance\r\nOrganizations should consider:\r\n• Ensuring that the cybersecurity program is given sufficient\r\nresources to support the organization’s IT and OT risk\r\nmanagement strategy\r\n• Ensuring that policies take the full life cycle of the OT systems\r\ninto consideration\r\n• Ensuring that legal and regulatory cybersecurity requirements\r\nthat affect OT operations are understood and managed\r\n• Establishing one or more senior official positions that are\r\nresponsible and accountable for the organization’s governance\r\nand risk management for IT and OT cybersecurity programs\r\n• Establishing communication and coordination between IT and\r\nOT organizations\r\n• Cross-training IT and OT personnel to support the cybersecurity\r\nprogram\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n94\r\n6.1.3. Risk Assessment (ID.RA)\r\nA cybersecurity risk assessment is performed to identify risks and estimate the magnitude of\r\nharm to operations, assets, or individuals that might result from cyber incidents, such as\r\nunauthorized access, use, disclosure, disruption, modification, or destruction of an information\r\nsystem or data. Organizations should consider the frequency with which to update risk\r\nassessments and test system cybersecurity controls.\r\nSupplemental guidance for ID.RA can be found in the following documents:\r\n• NIST SP 800-30, Rev. 1, Guide for Conducting Risk Assessments\r\n• NIST SP 800-37, Rev. 2, Risk Management Framework for Information Systems and\r\nOrganizations: A System Life Cycle Approach for Security and Privacy\r\n• NIST SP 800-39, Managing Information Security Risk: Organization, Mission, and\r\nInformation System View\r\nOT-Specific Recommendations and Guidance\r\nIn OT environments, risks and impacts may be related to safety, health,\r\nand the environment, in addition to business and financial impacts. As a\r\nresult, organizations may find that conducting a cost-benefit analysis for\r\nsome types of risks is not possible. In these cases, organizations should\r\nconsider reviewing past cyber and non-cyber incidents that have resulted\r\nin the loss of power, control, upstream feed, or downstream capacity, as\r\nwell as major equipment failures. A PHA, FMEA, or analysis of past\r\nevents can be used to understand the potential impact of a cyber incident.\r\nISA 62443-3-2 provides guidance on how to assess cyber risk in an\r\nenvironment with these potential consequences.\r\nRisk assessments also require the identification of both vulnerabilities\r\nand threats to the OT environment. Maintaining an accurate inventory of\r\nthe IT and OT assets within the environment of operation – including the\r\nproduct vendor, model numbers, firmware, OSs, and software versions\r\ninstalled on the assets – facilitates the identification, tracking, and\r\nremediation of vulnerabilities. OT-specific vulnerability information is\r\navailable through multiple methods, including:\r\n• Using OT-specific tools to automate asset inventory creation,\r\ncross-correlation of the inventory with known vulnerabilities and\r\nthreats, and regular updates\r\n• Monitoring security groups, associations, and vendors for\r\nsecurity alerts and advisories\r\n• Reviewing the NVD database for detailed information on known\r\nvulnerabilities for hardware and software assets\r\nThreat information that is relevant to the environment can be obtained\r\nfrom both internal resources and external threat intelligence information-sharing forums. Organizations should consider participating in cyber\r\nthreat information sharing [SP800-150].\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n95\r\n6.1.4. Risk Management Strategy (ID.RM)\r\nThe risk management strategy guides how risk is framed, assessed, responded to, and monitored\r\nand provides a consistent approach to making risk-based decisions across the organization. Risk\r\ntolerance, assumptions, constraints, priorities, and trade-offs are identified for investment and\r\noperational decision making. Additionally, the risk management strategy identifies acceptable\r\nrisk assessment methodologies, potential risk responses, and a process to continuously monitor\r\nthe security posture (or implementation of security countermeasures and outcomes) of the\r\norganization.\r\nSection 3 describes the overall risk management process for supporting an effective\r\ncybersecurity program. The following NIST documents provide additional implementation\r\nguidance for developing a risk management strategy:\r\n• NIST SP 800-37, Rev. 2, Risk Management Framework for Information Systems and\r\nOrganizations: A System Life Cycle Approach for Security and Privacy\r\n• NIST SP 800-39, Managing Information Security Risk: Organization, Mission, and\r\nInformation System View\r\n• NIST IR 8179, Criticality Analysis Process Model: Prioritizing Systems and Components\r\nOT-Specific Recommendations and Guidance\r\nWhen establishing an OT risk management strategy, organizations\r\nshould consider:\r\n• Ensuring that the risk tolerance of an OT environment is\r\ninformed by the organization’s role in critical infrastructure and\r\nsector-specific risk analysis\r\n• Documenting failure scenarios that involve IT components within\r\nthe OT environment and their effect on operations and safety\r\n• Establishing processes to periodically update information to\r\ndetermine the current risk posture for the environment and\r\ncoordinate required adjustments to risk management and\r\nmanagement controls\r\nOverall risk can also be reduced by addressing likelihood and\r\nconsequence. For OT systems, the risk management strategy should\r\nconsider non-security and safety controls (e.g., pressure relief valves,\r\nmanual valves) that can also help reduce the consequence of a failure.\r\n6.1.5. Supply Chain Risk Management (ID.SC)\r\nSupply chains are multifaceted and built on a variety of business, economic, and technological\r\nfactors. Organizations choose their suppliers, and consumers choose their sources based on a\r\nrange of factors that vary from corporate preferences and existing business relationships to more\r\ndiscrete considerations, such as the existence of limited sources of supply or other unique\r\ncharacteristics.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n96\r\nThe Subcategories (outcomes) that fall within the CSF Supply Chain Risk Management Category\r\nprovide the basis for developing processes and procedures for managing supply chain risk. These\r\nrisks include the insertion of counterfeits, unauthorized production, malicious insiders,\r\ntampering, theft, and the insertion of malicious software and hardware, as well as poor\r\nmanufacturing and development practices in the cyber supply chain. These risks must be\r\nidentified, assessed, and managed. The CSF Category also addresses supplier and third-party\r\npartner contracts, assessments, evaluations, and response and recovery planning.\r\nAdditionally, organizations should investigate SBOMs and distributed ledger (e.g., blockchain)\r\ntechnologies to support supply chain risk management. For example, SBOM information can\r\nidentify software components and their relationships or dependencies on other components.\r\nHaving this information available can help an organization determine whether a device is\r\naffected by reported software vulnerabilities.\r\nSupplemental guidance for Supply Chain Risk Management can be found in the following\r\ndocuments:\r\n• NIST SP 800-161, Supply Chain Risk Management Practices for Federal Information\r\nSystems and Organizations\r\n• NIST IR 8276, Key Practices in Cyber Supply Chain Risk Management: Observations\r\nfrom Industry\r\nOT-Specific Recommendations and Guidance\r\nOrganizations should consider documenting and tracking serial numbers,\r\nchecksums, digital certificates/signatures, or other identifying features\r\nthat can enable them to verify the authenticity of vendor-provided OT\r\nhardware, software, and firmware. Organizations should also consider\r\nwhether OT is purchased directly from the original equipment\r\nmanufacturer (OEM) or an authorized third-party distributor or reseller.\r\nSuppliers should be assessed or reviewed to ensure that they continue to\r\nfollow best practices.\r\nMany OT components and devices utilize open-source libraries to\r\nsupport their functional capabilities. Organizations should identify the\r\nopen-source dependencies for their OT components and establish\r\nmonitoring for open-source information, such as vendor websites or\r\ncyber news sources, to ensure that no known vulnerabilities or\r\ncounterfeits have been disclosed. Additionally, organizations might\r\nconsider utilizing an industry-recognized certification process for OT\r\nproducts to support supply chain risk management.\r\n Protect (PR)\r\nThe Protect Function supports the ability to limit or contain the impact of a potential\r\ncybersecurity event. Examples of outcome Categories within this Function include: Identity\r\nManagement and Access Control; Awareness and Training; Data Security; Information\r\nProtection Processes and Procedures; Maintenance; and Protective Technology\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n97\r\n6.2.1. Identity Management and Access Control (PR.AC)\r\nIdentity Management and Access Control (PR.AC) identifies outcomes around establishing and\r\nmanaging the identification mechanisms and credentials for users, devices, and services. Identity\r\nmanagement supports the cybersecurity principle of positively and uniquely identifying and\r\nauthorizing a person, process, or device before granting physical or logical access to resources\r\nsuch as the system, information, or location being protected. Access controls represent the\r\npolicies, processes, and technologies for specifying the use of system resources by only\r\nauthorized users, programs, processes, or other systems. PR.AC controls allow organizations to\r\nmanage logical and physical access to support system risk management requirements.\r\nSupplemental guidance for implementing identity management and access control outcomes can\r\nbe found in the following documents:\r\n• NIST SP 800-63-3, Digital Identity Guidelines\r\n• NIST SP 800-73-4, Interfaces for Personal Identity Verification\r\n• NIST SP 800-76-2, Biometric Specifications for Personal Identity Verification\r\n• NIST SP 800-100, Information Security Handbook: A Guide for Managers\r\nOT-Specific Recommendations and Guidance\r\nOrganizations should consider the life cycle for managing OT\r\ncredentials, including issuance, revocation, and updates across the OT\r\nenvironment.\r\nOrganizations should also consider the centralization of identification\r\nand authentication for users, devices, and processes within the OT\r\nenvironments to improve account management and monitoring\r\ncapabilities. Common network technologies – such as Active Directory,\r\nLightweight Directory Access Protocol (LDAP), and similar\r\ntechnologies – can be utilized to support the centralization of identity\r\nmanagement across environments. Organizations should weigh the\r\nincreased risks of authenticated accounts from IT environments having\r\naccess within the OT environment against the benefits of using\r\ncentralized accounts.\r\nWhen OT cannot support authentication or the organization determines\r\nthat it is not advisable due to adverse impacts on performance, safety, or\r\nreliability, the organization should select compensating countermeasures,\r\nsuch as the use of physical security (e.g., control center keycard access\r\nfor authorized users) to provide an equivalent security capability or level\r\nof protection for the OT. This guidance also applies to the use of session\r\nlock and session termination in an OT.\r\nA unique challenge in OT is the need for immediate access to an HMI in\r\nemergency situations. The time needed to enter a user’s credentials may\r\nimpede response or intervention by the operator, resulting in negative\r\nconsequences to safety, health, or the environment.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n98\r\n6.2.1.1. Logical Access Controls (PR.AC)\r\nLogical access controls restrict logical access to an organization’s systems, data, and networks.\r\nACLs are sometimes used to support logical access controls. An ACL is a list of one or more\r\nrules for determining whether an access request should be granted or denied, and it is used to\r\nsupport the principle of least functionality and control access to restricted areas. ACLs are\r\ncommonly used with isolation technologies, such as firewalls, where an ACL might specify the\r\nsource, destination, and protocol allowed through the isolation device to or from the protected\r\nnetwork segment. ACLs may also be used for physical or logical access to areas or information,\r\nsuch as network file shares, databases, or other data repositories and applications.\r\nRole-based access control (RBAC) also supports logical access controls. RBAC is a technology\r\nthat has the potential to reduce the complexity and cost of security administration in networks\r\nwith large numbers of intelligent devices. RBAC is built on the principle that employees change\r\nroles and responsibilities more frequently than the duties within those roles and responsibilities.\r\nUnder RBAC, security administration is simplified using roles, hierarchies, and constraints to\r\norganize user access levels.\r\nAdditionally, attribute-based access control (ABAC) is an access control approach in which\r\naccess is determined based on the attributes associated with subjects (requesters) and the objects\r\nbeing accessed. Each object and subject has a set of associated attributes, such as location, time\r\nof creation, and access rights. Access to an object is authorized or denied depending on whether\r\nthe required (e.g., policy-defined) correlation can be made between the attributes of that object\r\nand the requesting subject.\r\nFor federal employees and contractors, Personal Identity Verification (PIV), used in accordance\r\nwith FIPS 201, may be required to achieve access control. Organizations may also consider one\r\nor more of these techniques when determining how to support local access controls within their\r\nenvironments. Supplemental guidance for access controls can be found in the following\r\ndocuments:\r\n• NIST SP 800-63-3, Digital Identity Guidelines\r\n• NIST SP 800-73-4, Interfaces for Personal Identity Verification\r\n• NIST SP 800-76-2, Biometric Specifications for Personal Identity Verification\r\n• NIST SP 800-78-4, Cryptographic Algorithms and Key Sizes for Personal Identity\r\nVerification\r\n• NIST SP 800-96, PIV Card to Reader Interoperability Guidelines\r\n• NIST SP 800-97, Establishing Wireless Robust Security Networks: A Guide to IEEE\r\n802.11i\r\n• NIST SP 800-162, Guide to Attribute Based Access Control (ABAC) Definition and\r\nConsiderations\r\nOT-Specific Recommendations and Guidance\r\nOrganizations should consider the following:\r\n• Some logical access controls, such as RBAC, support the\r\nprinciple of least privilege and the separation of duties by\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n99\r\nproviding a uniform means to manage access to OT devices while\r\nreducing the cost of maintaining individual device access levels\r\nand minimizing errors. These logical access controls can also\r\nrestrict OT user privileges to only those required to perform each\r\nperson’s job (i.e., configuring each role based on the principle of\r\nleast privilege). The level of access can take several forms,\r\nincluding viewing, using, and altering specific OT data or device\r\nfunctions.\r\n• Solutions that provide credential management, authentication,\r\nauthorization, and system use monitoring technical capabilities.\r\nThese technologies may help manage risks associated with OT\r\ndevices and protocols by providing a secure platform to allow\r\nauthorized personnel to access the OT devices.\r\n• Access control systems that verify the identity of the individual,\r\nprocess, or device before granting access to minimize latency or\r\ndelays in processing OT system access or commands.\r\n• Highly reliable systems that do not interfere with the routine or\r\nemergency duties of OT personnel. Solutions should be designed\r\nto reduce the impact of determining identity and authorization on\r\nOT operations and safety.\r\nTo support access controls, an organization is not limited to a single access control approach. In\r\nsome cases, applying different access control techniques to different zones based on criticality,\r\nsafety, and operational requirements is more efficient and effective. For example, ACLs on\r\nnetwork zone firewalls combined with RBAC on engineering workstations and servers and\r\nABAC integrated into physical security to sensitive areas may achieve the risk-based access\r\ncontrol requirements of an organization.\r\n6.2.1.2. Physical Access Controls (PR.AC-2)\r\nPhysical security controls are physical measures that limit physical access to assets to prevent\r\nundesirable effects, including unauthorized physical access to sensitive locations; the\r\nunauthorized introduction of new systems, infrastructure, communications interfaces, or\r\nremovable media; and unauthorized disruption of the physical process. Physical access controls\r\ninclude controls for managing and monitoring physical access, maintaining logs, and handling\r\nvisitors.\r\nThe deployment of physical security controls is often subject to specific environmental, safety,\r\nregulatory, legal, and other requirements that must be identified and addressed for a given\r\nenvironment. Physical security controls may be broadly applied or specific to certain assets.\r\nThe initial layers of physical access control are often determined based on the risk of access to\r\nthe overall facility, not just OT components. Some regulations, such as NERC CIP-006-5\r\n(Physical Security of BES Cyber Systems) or from the Nuclear Regulatory Commission (NRC),\r\nmay also determine the strength and quantity of barriers used for the physical protection of a\r\nfacility.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n100\r\nOT-Specific Recommendations and Guidance\r\nThe physical protection of the cyber components and data associated\r\nwith OT must be addressed as part of the overall security for OT\r\nenvironments. Security at many OT facilities is closely tied to\r\noperational safety. A primary goal is to keep personnel out of hazardous\r\nsituations without preventing them from doing their jobs or carrying out\r\nemergency procedures.\r\nPhysical access controls are often applied to the OT environment as\r\ncompensating controls when legacy systems do not support modern IT\r\nlogical access controls (e.g., an asset could be locked in a cabinet when\r\nthe USB port or power button cannot be logically disabled). When\r\nimplementing these mitigations, organizations should consider whether\r\nthe OT component being protected can be compromised using a wireless\r\nor network connection that might bypass the physical security controls.\r\nA defense-in-depth solution to physical security should consider the\r\nfollowing attributes:\r\n• Protection of physical locations. Classic physical security\r\nconsiderations typically include an architecture of layered\r\nsecurity measures that create several physical barriers around\r\nbuildings, facilities, rooms, equipment, or other informational\r\nassets. Physical security controls should be implemented to\r\nprotect physical locations and may include fences, anti-vehicle\r\nditches, earthen mounds, walls, reinforced barricades, gates, door\r\nand cabinet locks, guards, or other measures.\r\n• Physical access control. Equipment cabinets should be locked\r\nwhen not required for operation or safety, and wiring should be\r\nneat and contained within cabinets or under floors. Additionally,\r\nconsider keeping all computing and networking equipment in\r\nsecured areas. Keys of OT assets, like PLCs and safety systems,\r\nshould be in the “Run” position at all times unless they are being\r\nactively programmed.\r\n• Access monitoring systems. Access monitoring systems include\r\nelectronic surveillance capabilities, such as still and video\r\ncameras, sensors, and identification systems (e.g., badge readers,\r\nbiometric scanners, electronic keypads). Such devices typically\r\ndo not prevent access to a particular location. Rather, they store\r\nand record either the physical presence or the lack of physical\r\npresence of individuals, vehicles, animals, or other physical\r\nentities. Adequate lighting should be provided based on the type\r\nof access monitoring device deployed. These systems can also\r\nsometimes alert or initiate action upon the detection of\r\nunauthorized access.\r\n• People and asset tracking. Locating people and vehicles in a\r\nfacility can be important for both safety and security reasons.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n101\r\nAsset location technologies can be used to track the movements\r\nof people and vehicles to ensure that they stay in authorized\r\nareas, to identify personnel who may need assistance, and to\r\nsupport emergency response.\r\nThe following are additional physical security considerations:\r\n• Portable devices. Organizations should apply a verification\r\nprocess that includes, at a minimum, scanning devices (e.g.,\r\nlaptops, USB storage, etc.) for malicious code prior to allowing\r\nthe device to connect to OT devices or networks.\r\n• Cabling. While unshielded twisted pair communications cables\r\nmay be acceptable in an office environment, they may not be\r\nsuitable for some OT environments due to their susceptibility to\r\ninterference from magnetic fields, radio waves, temperature\r\nextremes, moisture, dust, and vibration. Organizations should\r\nconsider using alternative cabling or shielding that provides\r\nsuitable protection against environmental threats. Additionally,\r\norganizations should consider color-coded cables, connectors,\r\nconduits, and labeling to clearly delineate OT and IT network\r\nsegments and reduce the risk of potential cross-connections.\r\n• Control centers and control rooms. Providing physical security\r\nfor control centers and control rooms can reduce the potential of\r\nmany threats, including unauthorized access. Access to these\r\nareas should be limited to authorized personnel due to the\r\nincreased probability of finding sensitive servers, network\r\ncomponents, control systems, and consoles that support\r\ncontinuous monitoring and rapid response. Gaining physical\r\naccess to a control room or OT system components often implies\r\ngaining logical access to the system or system components. In\r\nextreme cases, organizations may need to consider designing\r\ncontrol centers to be blast-proof or provide an off-site emergency\r\ncontrol center so that control can be maintained if the primary\r\ncontrol center becomes uninhabitable.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n102\r\n6.2.1.3. Network Segmentation and Isolation (PR.AC-5)\r\nAs discussed in Section 5, a common architecture for supporting a defense-in-depth\r\ncybersecurity approach involves the use of network segmentation or zoning to organize devices\r\nby location or function. Network segmentation is typically implemented physically using\r\ndifferent network switches or logically using virtual local area network (VLAN) configurations.\r\nWhen properly configured, network segmentation helps enforce security policies and segmented\r\ntraffic at the Ethernet layer and facilitates network isolation.\r\nFor network isolation, organizations typically utilize their mapped data flows to identify required\r\ncommunications between segments. Network isolation devices, such as gateways (including\r\nunidirectional gateways or data-diodes) and firewalls, are then configured to enforce these\r\ncommunication restrictions by monitoring all communication traffic and only permitting\r\nexplicitly authorized communication between segments.\r\nSupplemental guidance for access controls can be found in the following documents:\r\n• NIST SP 800-41, Rev. 1, Guidelines on Firewalls and Firewall Policy\r\n• NIST SP 800-207, Zero Trust Architecture\r\n• NIST SP 1800-15, Securing Small-Business and Home Internet of Things (IoT) Devices:\r\nMitigating Network-Based Attacks Using Manufacturer Usage Description (MUD)\r\nOT-Specific Recommendations and Guidance\r\nThe use of network segmentation and isolation should support an\r\norganization’s OT cybersecurity defense-in-depth architecture, as\r\ndescribed in Section 5.\r\nWhile VLANs can be a cost-effective solution for OT network\r\nsegmentation, organizations should consider utilizing physically separate\r\nswitches for segmenting high-criticality devices, such as those that\r\nsupport safety systems.\r\nWhen configuring network isolation devices, organizations may find it\r\ndifficult to determine which network traffic is necessary for proper OT\r\noperations. In these situations, organizations might consider temporarily\r\nallowing and recording all communication between the network\r\nsegments. This can provide reviewable logs to identify and document\r\nauthorized communication for implementing network isolation rules.\r\nThis activity may also reveal previously unknown or undocumented\r\ncommunication that needs to be reviewed by the organization.\r\nOrganizations should also consider whether regulatory requirements\r\nstipulate the type of network isolation devices required for OT\r\nenvironments or specific network segments. If organizations choose to\r\nutilize firewalls to support network isolation, modern firewalls should be\r\nconsidered, such as stateful and deep packet inspection devices and\r\ndevices specifically designed to support OT environments. Organizations\r\nshould enforce a deny-all, permit-by-exception policy where possible\r\nand also review the Centre for the Protection of National Infrastructure’s\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n103\r\n(CPNI) Firewall Deployment for SCADA and Process Control Networks:\r\nGood Practice Guide to assist with their firewall implementations.\r\nNetwork isolation devices may not protect against all network-based\r\nrisks. For example, network isolation does not mitigate risks associated\r\nwith lateral movement within a network segment, such as the\r\npropagation of a worm or other malicious code. Additionally, some IT\r\nprotocols and many industrial communications protocols have known\r\nsecurity vulnerabilities that might be exploitable through network\r\nisolation devices. Organizations should consider limiting the flow of\r\ninsecure protocols, restricting information flow to be unidirectional, and\r\nutilizing secure and authenticated protocols for supporting information\r\nexchange between the OT environment and other network segments.\r\n6.2.1.4. User, Device, and Asset Authentication (PR.AC-7)\r\nVarious authentication methods can be implemented within OT environments, including, but not\r\nlimited to the methods discussed in this section.\r\n6.2.1.4.1. Physical Token Authentication\r\nPhysical token authentication primarily addresses the easy duplication of a secret code or sharing\r\nit with others (e.g., a password to a “secure” system being written on the wall next to a PC or\r\noperator station). With physical token authentication, the security token cannot be duplicated\r\nwithout special access to equipment and supplies.\r\nA second benefit is that the secret within a physical token can be very large, physically secure,\r\nand randomly generated. Because it is embedded in metal or silicon, it does not have the same\r\nrisks that manually entered passwords do. Traditional passwords can become lost or stolen\r\nwithout notice, leaving credentials more vulnerable to exploitation. If a security token is lost or\r\nstolen, the token owner is aware of the missing token and can notify security personnel to disable\r\naccess.\r\nCommon forms of physical or token authentication include:\r\n• Traditional physical locks and keys\r\n• Security cards (e.g., magnetic, smart chip, optical coding)\r\n• Radio frequency devices in the form of cards, key fobs, or mounted tags\r\n• Dongles with secure encryption keys that attach to the USB, serial, or parallel ports of\r\ncomputers\r\n• One-time authentication code generators (e.g., key fobs)\r\nFor single-factor authentication with a physical token, the greatest weakness is that physically\r\nholding the token means access is granted (e.g., anyone who finds a set of lost keys can now\r\naccess whatever those keys open). Physical token authentication is more secure when combined\r\nwith a second form of authentication, such as a memorized PIN used alongside the token.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n104\r\nWhen token-based access control employs cryptographic verification, the access control system\r\nshould conform to the requirements of NIST SP 800-78-4 [SP800-78-4].\r\n6.2.1.4.2. Biometric Authentication\r\nBiometric authentication enhances software-only solutions, such as password authentication, by\r\noffering an additional authentication factor and removing the need for people to memorize\r\ncomplex secrets. In addition, because biometric characteristics are unique to a given individual,\r\nbiometric authentication addresses the issues of lost or stolen physical tokens and smart cards.\r\nBiometric devices make a useful secondary check versus other forms of authentication that can\r\nbecome lost or borrowed. Using biometric authentication in combination with token-based\r\naccess control or badge-operated employee time clocks increases security.\r\nNoted issues with biometric authentication include:\r\n• Distinguishing a real object from a fake one (e.g., distinguishing a real human finger\r\nfrom a silicon rubber cast of one or a real human voice from a recorded one)\r\n• Generating type-I and type-II errors, which is the probability of rejecting a valid\r\nbiometric image and accepting an invalid biometric image, respectively. Biometric\r\nauthentication devices should be configured to the lowest crossover between these two\r\nprobabilities, also known as the crossover error rate.\r\n• Handling environmental factors, such as temperature and humidity, to which some\r\nbiometric devices are sensitive\r\n• Addressing industrial applications where employees may have to wear safety glasses\r\nand/or gloves and industrial chemicals are present\r\n• Retraining biometric scanners that occasionally “drift” over time. Human biometric traits\r\nmay also shift over time, necessitating periodic scanner retraining.\r\n• Requiring face-to-face technical support and verification for device training, unlike a\r\npassword that can be given over a phone or an access card that can be handed out by a\r\nreceptionist\r\n• Denying needed access to the OT system because of a temporary inability of the sensing\r\ndevice to acknowledge a legitimate user\r\n• Being socially acceptable. Users consider some biometric authentication devices more\r\nacceptable than others. For example, retinal scans may be considered very low on the\r\nscale of acceptability, while thumbprint scanners may be considered high on the scale of\r\nacceptability. Users of biometric authentication devices will need to take social\r\nacceptability for their target group into consideration when selecting among biometric\r\nauthentication technologies.\r\nWhen token-based access control employs biometric verification, the access control system\r\nshould conform to the requirements of NIST SP 800-76-2 [SP800-76-2].\r\nOT-Specific Recommendations and Guidance\r\nWhile biometrics can provide a valuable authentication mechanism,\r\norganizations may need to carefully assess the technology for use with\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n105\r\nindustrial applications. Physical and environmental issues within OT\r\nenvironments may decrease the reliability of biometric authorized\r\nauthentication. Organizations may need to coordinate with system\r\nvendors or manufacturers regarding their specific physical and\r\nenvironmental properties and biometric authentication requirements.\r\n6.2.1.4.3. Smart Card Authentication\r\nSmart cards come in a variety of form factors, from USB devices to embedded chips on cards the\r\nsize of credit cards that can be printed and embossed. Smart cards can be customized,\r\nindividualized, and issued in-house or outsourced to service providers who manufacture\r\nhundreds or thousands per day. Smart cards enhance software-only solutions, such as password\r\nauthentication, by offering an additional authentication factor and removing the human element\r\nin memorizing complex secrets by:\r\n• Isolating security-critical computations that involve authentication, digital signatures, and\r\nkey exchange from other parts of the system that do not have a need to know\r\n• Enabling the portability of credentials and other private information between computer\r\nsystems\r\n• Providing tamper-resistant storage for protecting private keys and other forms of personal\r\ninformation\r\nMost issues regarding the use of smart cards are logistical and focus on issuing cards,\r\nparticularly replacing lost or stolen cards.\r\nOT-Specific Recommendations and Guidance\r\nAlthough smart cards offer useful functionality, their implementation in\r\nOT must consider the overall security context of the OT environment.\r\nThe necessary identification of individuals, issuance of cards, revocation\r\nif compromise is suspected, and the assignment of authorizations to\r\nauthenticated identities represents a significant initial and ongoing\r\nchallenge. In some cases, corporate IT or other resources may be\r\navailable to assist in the deployment of smart cards and the required\r\npublic key infrastructures. Organizations should also consider the impact\r\non OT operational capabilities if dependency on IT systems and services\r\nare required to support the smart card technology.\r\nAdditionally, if smart cards are implemented in an OT setting,\r\norganizations should consider provisions for managing lost or damaged\r\ncards, the costs to incorporate and sustain a respective access control\r\nsystem, and a management process for card distribution and retrieval.\r\nThese procedures should consider the ability to grant temporary access to\r\nOT personnel to prevent operational or safety disruptions.\r\nA common approach in the Federal Government is based on the\r\nstandardization on Federal PIV smart cards, which allows organizations\r\nto use the same credential mechanism in multiple applications with one\r\nto three factors for authentication (i.e., Card-Only, Card+PIN,\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n106\r\nCard+PIN+Biometric), depending on the risk level of the protected\r\nresource. If the Federal PIV is used as an identification token, the access\r\ncontrol system should conform to the requirements of FIPS 201\r\n[FIPS201] and NIST SP 800-73-4 [SP800-73-4] and employ either\r\ncryptographic verification or biometric verification.\r\n6.2.1.4.4. Multi-Factor Authentication\r\nThere are several possible factors for determining the authenticity of a person, device, or system,\r\nincluding something you know (e.g., PIN number or password), something you have (e.g., key,\r\ndongle, smart card), and something you are (i.e., a biological characteristic, such as a fingerprint\r\nor retinal signature). When two or more factors are used, the process is known as multi-factor\r\nauthentication (MFA). In general, the more factors that are used in the authentication process, the\r\nmore robust the process.\r\nOT-Specific Recommendations and Guidance\r\nOrganizations need to consider whether MFA is required for protecting\r\nOT environments in whole or in part. MFA is an accepted best practice\r\nfor remote access to OT applications. When determining the placement\r\nand usage of MFA within an OT environment, organizations may need to\r\nconsider different authentication scenarios since some OT components\r\nsupport only a single factor or no authentication. Organizations may\r\nconsider adjusting credential requirements based on the type of access or\r\nother mitigating factors for the environment. For example, remote access\r\nto the OT environment may require MFA, while local access may only\r\nrequire a user ID and password due to other mitigating factors, such as\r\nphysical access controls before gaining physical access to the area where\r\nthe user ID and password may be used.\r\n6.2.1.4.5. Password Authentication\r\nWhile password authentication schemes are arguably the most common and simplest form of\r\nauthentication, numerous vulnerabilities are associated with the use of and reliance on password-only authentication. For example, systems are often delivered with default passwords that can be\r\neasily guessed, discovered, or researched. Another weakness is the ease of third-party\r\neavesdropping. Passwords typed at a keyboard can be visually observed by others or recorded\r\nusing keystroke loggers.\r\nSome network services and protocols transmit passwords as plaintext (unencrypted), allowing\r\nany network capture tool to expose the passwords. Additionally, passwords may be shared and\r\nnot changed frequently. The use of shared credentials, including shared passwords, limits the\r\nability to positively identify the individual person, process, or device that accessed a protected\r\nresource. Defense in depth is often utilized to prevent password authentication from being the\r\nonly control in place to prevent unauthorized modification.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n107\r\nOT-Specific Recommendations and Guidance\r\nMany OT systems do not offer password recovery mechanisms, so the\r\nsecure and reliable handling of passwords is critical to maintaining\r\ncontinuous operation. Organizations are encouraged to change the\r\ndefault password on OT equipment to make it more difficult for an\r\nadversary to guess the password. Once changed, the password needs to\r\nbe made available to those who need to know. Organizations may want\r\nto consider using a password management tool that is secure and\r\naccessible by those who need to know.\r\nSome OT OSs make setting secure passwords difficult if the password\r\nsize is smaller than current password standards and the system allows\r\nonly group passwords at each level of access rather than individual\r\npasswords. Some industrial (and internet) protocols transmit passwords\r\nin plaintext, making them susceptible to interception. In cases where this\r\npractice cannot be avoided, it is important that users have different (and\r\nunrelated) passwords for use with encrypted and non-encrypted\r\nprotocols.\r\nAdditionally, special considerations may be required when applying\r\npolicies based on login password authentication within the OT\r\nenvironment. Without an exclusion list based on machine identification\r\n(ID), non-operator login can result in policies such as auto-logoff\r\ntimeout and administrator password replacement being pushed down,\r\nwhich can be detrimental to the operation of the OT system.\r\nThe following are general recommendations and considerations with\r\nregard to the use of passwords:\r\n• Change all default passwords in OT components.\r\n• Passwords should have appropriate length, strength, and\r\ncomplexity balanced with security and operational ease of access\r\nwithin the capabilities of the software and underlying OS.\r\n• Passwords should not be able to be found in a dictionary or\r\ncontain predictable sequences of numbers or letters.\r\n• Passwords should be used with care on specialized OT devices,\r\nsuch as control consoles on critical processes. Using passwords\r\non these consoles could introduce potential safety issues if\r\noperators are locked out or access is delayed during critical\r\nevents. Organizations should consider physical or network\r\nisolation for devices where password protection is not\r\nrecommended.\r\n• Copies of shared or administrator passwords must be stored in a\r\nsecure location with limited access that can also be accessed in an\r\nemergency. Organizations may also need to consider procedures\r\nto periodically change passwords when a password is\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n108\r\ncompromised or an individual with access leaves the\r\norganization.\r\n• Privileged (administrative) account passwords require additional\r\nprotection, such as stronger password requirements, more\r\nfrequent changing, and additional physical safeguards.\r\n• Passwords should not be sent across any network unless they are\r\nprotected by some form of FIPS-approved encryption or salted\r\ncryptographic hash that is specifically designed to prevent replay\r\nattacks.\r\n6.2.2. Awareness and Training (PR.AT)\r\nThe Awareness and Training category provides policies and procedures for ensuring that all\r\nusers are given basic cybersecurity awareness and training.\r\nSupplemental guidance can be found in the following documents:\r\n• NIST SP 800-50, Building an Information Technology Security Awareness and Training\r\nProgram\r\n• NIST SP 800-100, Information Security Handbook: A Guide for Managers\r\n• NIST SP 800-181, Rev. 1, Workforce Framework for Cybersecurity (NICE Framework)\r\nOT-Specific Recommendations and Guidance\r\nPersonnel should receive security awareness and training for the OT\r\nenvironment and specific applications. In addition, organizations should\r\nidentify, document, and train all personnel who have significant OT roles\r\nand responsibilities. Awareness and training should cover the physical\r\nprocess being controlled as well as the OT system.\r\nSecurity awareness is a critical part of OT incident prevention,\r\nparticularly when it comes to social engineering threats. Social\r\nengineering is a technique used to manipulate individuals into giving\r\naway private information, such as passwords. This information can then\r\nbe used to compromise otherwise secure systems.\r\nOT security-specific awareness and training programs could include a\r\nbasic understanding of social engineering techniques, how to identify\r\nanomalous behavior in the OT environment, when and how to connect\r\nand disconnect the OT environment from external security domains,\r\npassword complexity and management requirements, and reporting\r\npractices. All personnel with OT responsibilities should be provided with\r\ntraining, which may be tailored based on roles and responsibilities. Roles\r\nto consider in the training program could include senior executives,\r\nprivileged account users, third-party providers, physical security\r\npersonnel, control engineers, operators, and maintainers.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n109\r\n6.2.3. Data Security (PR.DS)\r\nProviding data security includes protecting the confidentiality, integrity, and availability of data\r\nat rest and data in transit, protecting assets after removal, and preventing data leaks.\r\nCryptography can support data security requirements. Encryption, digital signatures, hashing,\r\nand other cryptographic functions are available to prevent unauthorized access or the\r\nmodification of data at rest and in transit [RFC4949]. When cryptography is selected,\r\norganizations should use a certified cryptographic system. Federal organizations are required to\r\ncomply with FIPS 140-3 [FIPS140-3] and the Cryptographic Module Validation Program\r\n(CMVP). Additionally, cryptographic hardware should be protected from physical tampering and\r\nuncontrolled electronic connections.\r\nSupplemental guidance for data security can be found in the following documents:\r\n• NIST SP 800-47, Rev. 1, Managing the Security of Information Exchanges\r\n• NIST SP 800-111, Guide to Storage Encryption Technologies for End User Devices\r\n• NIST SP 800-209, Security Guidelines for Storage Infrastructure\r\nOT-Specific Recommendations and Guidance\r\nIdentify critical physical and electronic file types and data to protect\r\nwhile at rest. This may include personally identifiable information and\r\nsensitive, proprietary, or trade secret information (e.g., PLC program\r\ncode, robot programs, computer-aided drafting [CAD] or computer-aided\r\nmanufacturing [CAM] files, operating manuals and documentation,\r\nelectrical diagrams, network diagrams, historical production data\r\n[IR8183A]). Organizations should consider centralizing critical data\r\nwithin secure storage locations.\r\nWhen OT data is stored in the cloud or on vendor servers, organizations\r\nshould consider performing a risk analysis to determine how the data is\r\nprotected by the service provider and whether additional\r\ncountermeasures should be implemented to manage risk to an acceptable\r\nlevel.\r\nMonitor information flows from the OT security domain to other security\r\ndomains and connections between security domains. Technologies such\r\nas data diodes, firewalls, and ACLs can be used to restrict the\r\ninformation flow. Examples of critical interfaces and interconnections\r\nmay include interfaces between IT and OT, OT and external industry\r\npartners, or OT and third-party support vendors.\r\nTo protect data on system components at end of life, an asset disposal\r\nprogram should be implemented, including considerations for wiping,\r\nsanitizing, or otherwise destroying critical data and media prior to\r\ndisposal. The asset disposal program should include any removeable\r\nmedia, mobile devices, and traditional OT hardware.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n110\r\nCryptography\r\nCritical OT data should be protected while in transit, especially over\r\nthird-party network segments and other untrusted or vulnerable network\r\npaths (e.g., cellular, wireless, internet, WAN). Identify critical data, and\r\nimplement cryptographic mechanisms (e.g., encryption) to prevent\r\nunauthorized access or the modification of system data and audit records.\r\nEncryption provides a mechanism for ensuring confidentiality and\r\nintegrity for data in transit.\r\nOT applications often focus on the availability of data. Before deploying\r\nencryption in OT, ensure that confidentiality or integrity is the goal of\r\napplying the security control. The use of encryption within an OT\r\nenvironment could introduce communications latency due to the\r\nadditional time and computing resources required to encrypt, decrypt,\r\nand authenticate each message. Encryption may also cause performance\r\ndegradation of the end device or system. Before deploying encryption\r\nwithin an OT environment, solutions should be tested to determine\r\nwhether latency is acceptable for the application. Encryption at OSI\r\nLayer 2 rather than Layer 3 may be implemented to help reduce\r\nencryption latency.\r\nAdditionally, while encryption provides confidentiality between\r\nencryption and decryption devices, anomaly detection tools that support\r\nOT environments may be unable to read encrypted data. Encryption\r\nshould, therefore, be carefully planned and implemented to manage\r\noperational risks.\r\nOrganizations should also consider that cryptography may introduce key\r\nmanagement issues. Sound security policies require key management\r\nprocesses that can become more difficult as the geographic size of the\r\nOT increases. Because site visits to change or manage keys can be costly\r\nand slow, organizations should consider whether cryptographic\r\nprotection with remote key management may be beneficial, such as when\r\nthe protected units become so numerous or geographically dispersed that\r\nmanaging keys is difficult or expensive.\r\nFor OT, encryption can be deployed as part of a comprehensive,\r\nenforced security policy. A cryptographic key should be long enough so\r\nthat guessing it or determining it through analysis takes more effort,\r\ntime, and cost than the value of the protected asset.\r\n6.2.4. Information Protection Processes and Procedures (PR.IP)\r\nPolicies, processes, and procedures should be maintained and used to manage the protection of\r\ninformation systems and assets. Countermeasures and outcomes should be in place to manage\r\nconfiguration changes throughout the life cycle of the component and system. Backups should be\r\nmaintained, and response and recovery plans should be prepared and tested. A plan should be\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n111\r\ndeveloped and implemented for vulnerability management throughout the life cycle of the\r\ncomponents.\r\n6.2.4.1. Least Functionality (PR.IP-1)\r\nThe principle of least functionality involves configuring systems to only provide essential\r\nfunctions and services. Some default functions and services may not be necessary to support\r\nessential organizational missions, functions, or operations. These functions include network ports\r\nand protocols, software, and services.\r\nSupplemental guidance can be found in the following document:\r\n• NIST SP 800-167, Guide to Application Whitelisting\r\nOT-Specific Recommendations and Guidance\r\nSystems and devices in the OT environment include many functions and\r\nservices that are unnecessary for their proper operation, some of which\r\nmay be enabled by default and without the organization’s knowledge.\r\nAny functions or services that are not required for proper operation\r\nshould be disabled to reduce exposure.\r\nCare should be taken when disabling these functions and services, as\r\nunintended impacts may result if a critical function or service is\r\nunknowingly disabled (e.g., disabling all external communications to a\r\nPLC may also disable the ability to communicate with associated HMIs).\r\nDevices should be subjected to extensive testing before being deployed\r\non the OT network.\r\n6.2.4.2. Configuration Change Control (Configuration Management) (PR.IP-3)\r\nConfiguration management helps ensure that systems are deployed and maintained in a secure\r\nand consistent state to reduce risks from outages due to configuration issues and security\r\nbreaches through improved visibility and tracking of changes to the system. In addition,\r\nconfiguration management can detect improper configurations before they negatively impact\r\nperformance, safety, or security. Configuration management tools enable an asset owner to\r\nestablish and maintain the integrity of system hardware and software components by controlling\r\nthe processes for initializing, changing, monitoring, and auditing the configurations of the\r\ncomponents throughout the system life cycle.\r\nSupplemental guidance for configuration management can be found in the following documents:\r\n• NIST SP 800-128, Guide for Security-Focused Configuration Management of\r\nInformation Systems\r\n• NIST SP 1800-5, IT Asset Management\r\nOT-Specific Recommendations and Guidance\r\nOrganizations should document the approved baseline configuration for\r\ntheir OT devices and establish the system development life cycle\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n112\r\n(SDLC) approach to document, test, and approve changes before\r\ndeploying them to the OT environment.\r\nSome organizations may maintain logbooks or other similar methods to\r\ndocument changes to OT components. Organizations should consider\r\ncentralizing the tracking and documentation of changes to the OT\r\nenvironment to improve visibility and ensure proper testing and\r\napprovals for system changes. Such a process may help organizations to\r\nprevent accidental reconfiguration or identify the intentional\r\nreconfiguration of components to unapproved or untested versions.\r\nIf the use of automated configuration management tools are deemed to\r\nbe appropriate, processes should be in place to validate configurations\r\nprior to deployment. Many changes to OT can be made only during\r\nscheduled maintenance downtimes to minimize impacts. When\r\nconsidering automated configuration management tools, organizations\r\nshould also consider potential impacts to the OT system. In some cases,\r\nthese tools transfer numerous types and potentially large amounts of data\r\nover the manufacturing system network. Additionally, some tools may\r\nalso have the potential to impact OT system operations by attempting to\r\nchange device configurations or manipulating active files.\r\n6.2.4.3. Backups (PR.IP-4)\r\nConducting, maintaining, and testing backups is a critical outcome for the recovery process if a\r\ncyber or reliability incident occurs.\r\nSupplemental guidance for determining the priority and strategy for backups can be found in the\r\nfollowing documents:\r\n• NIST SP 800-34, Rev. 1, Contingency Planning Guide for Federal Information Systems\r\n• NIST SP 800-209, Security Guidelines for Storage Infrastructure\r\nOT-Specific Recommendations and Guidance\r\nA list of all maintained backups should be developed, including\r\ninstallation media, license keys, and configuration information.\r\nAdditional measures should be taken to ensure that backups are readily\r\navailable when needed, such as:\r\n• Verify the backups for reliability and integrity (if technically\r\npossible).\r\n• Establish an on-site location for backups that is accessible to all\r\npersonnel who may need access during a recovery event.\r\n• Establish an alternate secondary storage location for additional\r\ncopies of backups to ensure that the same incident that disrupts\r\nthe primary data cannot modify or destroy the backup (e.g., store\r\nPLC logic and configuration files at an off-site, geographically\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n113\r\ndiverse location that cannot be destroyed by the same [hurricane,\r\nwildfire, tornado] that may destroy the PLC).\r\n• Test the restoration process from backup data as part of\r\ncontingency plan testing.\r\n• Ensure that backup procedures are included in configuration or\r\nchange management processes.\r\n• Secure backups according to access control requirements.\r\n• Monitor environmental conditions where backup media is stored.\r\n6.2.4.4. Physical Operating Environment (PR.IP-5)\r\nManaging the physical operating environment includes emergency protection controls, such as\r\nemergency shutdown of the system, backup for power and lighting, controls for temperature and\r\nhumidity, and protection against fire and water damage. Organizations should develop policies\r\nand procedures to ensure that environmental operating requirements for assets are achieved.\r\nOT-Specific Recommendations and Guidance\r\nOrganizations should consider the following factors when identifying\r\npotential countermeasures to protect the physical operating environment:\r\n• Environmental factors. Environmental factors can be important.\r\nFor example, if a site is dusty, systems should be placed in a\r\nfiltered environment, especially if the dust is likely to be\r\nconductive or magnetic, as in the case of sites that process coal or\r\niron. If vibration is likely to be a problem, systems should be\r\nmounted on rubber bushings to prevent disk crashes and wiring\r\nconnection problems. In addition, environments that contain\r\nsystems and media (e.g., backup tapes, floppy disks) should have\r\nstable temperature and humidity. An alarm to the OT system\r\nshould be generated when environmental specifications, such as\r\ntemperature or humidity, are exceeded.\r\n• Environmental control systems. HVAC systems for control\r\nrooms must support OT personnel during normal operation and\r\nemergency situations, which could include the release of toxic\r\nsubstances. Risk assessments should consider the risk of\r\noperating an HVAC system (e.g., air intakes) in an occupied\r\nshelter during a toxic release, as well as continued operation\r\nduring a power outage (e.g., using an uninterruptible power\r\nsupply in critical environments). Additionally, fire systems must\r\nbe carefully designed to avoid causing more harm than good\r\n(e.g., to avoid mixing water with incompatible products). HVAC\r\nand fire systems have significant roles that arise from the\r\ninterdependence of process control and security. For example,\r\nfire prevention and HVAC systems that support industrial control\r\ncomputers need to be protected against cyber incidents.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n114\r\n• Power. Reliable power for OT is essential, so a UPS should be\r\nprovided for critical systems. If the site has an emergency\r\ngenerator, the UPS battery life may only need to last for a few\r\nseconds. However, if the site relies on external power, the UPS\r\nbattery life may need to last for hours. At a minimum, it should\r\nbe sized so that the system can be shut down safely.\r\n6.2.4.5. Response and Recovery Plans (PR.IP-9) and Response and Recovery\r\nPlan Testing (PR.IP-10)\r\nOrganizations should develop and maintain response plans, including incident response and\r\nbusiness continuity. Response plans should be measured against the service being provided, not\r\njust the system that was compromised. Organizations should consider a systematic approach to\r\nresponse planning, such as the process described in CISA’s Cybersecurity Incident and\r\nVulnerability Response Playbooks [CISA-CIVR]. Common planning steps include preparation,\r\ndetection and analysis, containment, recovery, post-incident activity, communication, and\r\ncoordination. Organizations should also regularly review and update their response plans.\r\nThe response plans should be documented in paper form or on an offline system (i.e., air gapped)\r\nthat cannot be compromised during a cyber attack. Individuals should be trained on where to find\r\nthe response plan and the actions to take as part of an incident response. Additionally, during the\r\npreparation of the incident response plan, input should be obtained from the various\r\nstakeholders, including operations, engineering, IT, system support vendors, management,\r\norganized labor, legal, and safety. These stakeholders should also review and approve the plan.\r\nBusiness continuity planning addresses the overall issue of maintaining or reestablishing\r\nproduction in the case of an interruption. An outage can take days, weeks, or months to recover\r\nfrom a natural disaster or minutes or hours to recover from a malware infection or a mechanical\r\nor electrical failure. Business continuity plans (BCPs) are often written to cover many types of\r\nincidents involving several different disciplines. The BCP for cybersecurity incidents should\r\nbroadly cover long-term outages, including disaster recovery, and short-term outages that require\r\noperational recovery. It is important to work with physical security on developing the BCP\r\nrelated to cybersecurity incidents. This collaboration with physical security should include the\r\nidentification of critical equipment and the associated countermeasures in place to prevent an\r\nincident.\r\nBefore creating a BCP to address potential outages, it is important to specify the recovery\r\nobjectives for the various systems and subsystems involved based on typical business needs.\r\nThere are two distinct types of objectives: system recovery and data recovery. System recovery\r\ninvolves the recovery of communication links and processing capabilities and is usually specified\r\nin terms of a recovery time objective (RTO). Management should define the acceptable RTO,\r\nand technical personnel should work to achieve that target. Data recovery involves the recovery\r\nof data that describes production or product conditions in the past and is usually specified in\r\nterms of a recovery point objective (RPO). This is defined as the time for which an absence of\r\ndata can be tolerated. The RTO and RPO may justify investment in spare inventory if recovery\r\nobjectives cannot be met by other means.\r\nOnce the recovery objectives are defined, a list of potential interruptions should be created, and\r\nthe recovery procedure should be developed and described. A contingency plan is then created\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n115\r\nfor the variety of potential interruptions. The contingency plan should be reviewed with\r\nmanagers to ensure that the cost to meet the contingency plan is approved. For many smaller-scale interruptions, a critical spares inventory will likely prove adequate to meet the recovery\r\nobjectives. For larger-scale recovery, vendor relationships will likely be leveraged. For all types\r\nof recovery, backups are critical.\r\n \r\nA disaster recovery plan (DRP) is a documented process or set of procedures that comprise a\r\ncomprehensive statement of recovery actions to be taken before, during, and after a disaster. The\r\nDRP is ordinarily documented in both electronic and paper form to ensure that it is readily\r\navailable during any type of disaster (e.g., natural, environmental, or caused by humans, whether\r\nintentionally or unintentionally). Organizations should develop, maintain, and validate disaster\r\nrecovery plans for their environments to help minimize an event impact by reducing the time\r\nrequired to restore capabilities.\r\nOrganizations may already have some emergency response plans in place and should consider\r\nleveraging existing plans when developing a response plan for cybersecurity events.\r\nSupplemental guidance for response planning can be found in the following documents:\r\n• NIST SP 800-34, Rev. 1, Contingency Planning Guide for Federal Information Systems\r\n• NIST SP 800-61, Rev. 2, Computer Security Incident Handling Guide\r\n• NIST SP 800-83, Rev. 1, Guide to Malware Incident Prevention and Handling for\r\nDesktops and Laptops\r\n• NIST SP 800-100, Information Security Handbook: A Guide for Managers\r\n• CISA, Handling Destructive Malware\r\n• Federal Emergency Management Agency (FEMA) National Incident Management\r\nSystem (NIMS)\r\n• FEMA National Preparedness Goal\r\nOT-Specific Recommendations and Guidance\r\nIncident response planning may include the following elements:\r\n• Identification and classification of incidents. The various types\r\nof OT incidents should be identified and classified based on\r\npotential impact so that a proper response can be formulated for\r\neach potential incident.\r\n• Response actions. Incident response can range from doing\r\nnothing to performing a full system shutdown, which could result\r\nin a shutdown of the physical process. The response taken will\r\ndepend on the type of incident and its effect on the OT system\r\nand the physical process being controlled. A written plan that\r\ndocuments the response to each type of incident should be\r\nprepared. This will provide guidance during times when there\r\nmight be confusion or stress due to the incident. This plan should\r\ninclude step-by-step actions to be taken by various stakeholders.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n116\r\nReporting requirements should be documented along with contact\r\ninformation and the reporting format to reduce confusion.\r\nResponse actions should also include steps for detection,\r\nanalysis, containment, eradication, recovery, and post-incident\r\nactivity. Some considerations for OT may include:\r\no Determining a priority, such as returning to normal\r\noperations as quickly as possible or performing an\r\ninvestigation and preserving forensic data\r\no Communicating with the incident response team\r\no Disconnecting infected systems from the network\r\no Physically isolating operationally independent networks\r\n(e.g., enterprise from control or control from safety)\r\no Transitioning to manual operations\r\no Resourcing for additional operations support to manually\r\nvalidate data\r\no Notifying management, public relations, and/or outside\r\ncompanies and agencies as required\r\nIf an incident is discovered, organizations should conduct a focused risk\r\nassessment on the OT environment to evaluate the effects of the attack\r\nand the options to respond. For example, one possible response option is\r\nto physically isolate the system under attack. However, this may have a\r\nnegative impact on the OT and may not be possible without impacting\r\noperational performance or safety. A focused risk assessment should be\r\nused to determine the response action.\r\nThe plan should also indicate requirements for the timely replacement of\r\ncomponents in the case of an emergency. If possible, replacements for\r\nhard-to-obtain critical components should be kept in inventory.\r\nThe organization should have a means for prioritizing recovery\r\nactivities. This prioritization may leverage existing documentation, such\r\nas risk assessments or startup procedures. For example, the focus may be\r\nto recover the systems that support critical utilities prior to the systems\r\nthat support manufacturing based on the order of start-up activities.\r\nTesting recovery plan procedures for OT components may be difficult\r\ndue to operational and safety requirements. Organizations may need to\r\ndetermine if “bench tests” or other offline testing is possible to confirm\r\nthe recovery procedures for OT components. At a minimum,\r\norganizations should verify the integrity of the backups if a full recovery\r\ntest cannot be performed.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n117\r\n6.2.5. Maintenance (PR.MA)\r\nThe outcomes that fall within the CSF Maintenance Category provide guidance for performing\r\nroutine and preventative maintenance on the components of an information system. This includes\r\nthe usage of local and remote maintenance tools and the management of maintenance personnel.\r\nOT-Specific Recommendations and Guidance\r\nMaintenance tracking solutions enable an organization to schedule, track,\r\nauthorize, monitor, and audit maintenance and repair activities to OT and\r\nensure that maintenance logs or changes are properly documented.\r\nDocumenting these events provides an audit trail that can aid in\r\ncybersecurity-related troubleshooting, response, and recovery activities.\r\nMaintenance tracking can also provide visibility into scheduled\r\nmaintenance for OT devices and help inform end-of-life decisions.\r\nThe software used for OT maintenance activities should be approved and\r\ncontrolled by the organization. Approved software should be obtained\r\ndirectly from vendors and its authenticity verified (e.g., by validating\r\ncertificates or comparing the hashes of installers).\r\nAny maintenance performed on an OT device can inadvertently modify\r\nits configuration and result in an increased attack surface. The hardened\r\nstate of the OT device should be maintained regardless of the\r\nmaintenance performed. Device configuration should be verified after\r\nmaintenance and software patching, as some features may have\r\ninadvertently been reenabled or new features installed. Best practices and\r\nother supporting documents should be obtained from the device vendor\r\nto guide and inform maintenance activities.\r\nLimiting the use of certain devices for maintenance activities can help\r\nreduce the chances of device compromise by exposure to external\r\nnetworks, unauthorized users, or theft. Maintenance devices that remain\r\nsecure within the OT environment reduce their exposure. Using\r\nmaintenance devices outside of the OT environment or connecting the\r\ndevices to non-OT networks should be restricted or minimized.\r\nAny device connected to the OT system should be disconnected after the\r\nmaintenance activities are completed, and any temporary connections\r\nshould be removed.\r\nThe operation, capabilities, and features of the devices used for\r\nmaintenance activities should be well understood. Devices may contain\r\nwireless radios and other communications devices that may be\r\nvulnerable to side-channel attacks or may allow simultaneous\r\nconnections between networks (i.e., dual-homed). Vendor documentation\r\nshould be thoroughly reviewed to understand these capabilities.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n118\r\n6.2.6. Protective Technology (PR.PT)\r\nTechnical mechanisms assist organizations with protecting the devices and information within\r\ntheir environments. These technologies alone may not be sufficient to sustain security\r\ncapabilities as threats evolve and change. As such, organizations should manage the technical\r\nsolutions that secure the organizational assets in a manner consistent with policies, procedures,\r\nand agreements.\r\n6.2.6.1. Logging (PR.PT-1)\r\nLogging enables an organization to capture events that occur within its systems and networks.\r\nEvents can be generated by many different systems, including OSs, workstations, servers,\r\nnetworking devices, cybersecurity software, and applications.\r\nSupplemental guidance can be found in the following document:\r\n• NIST SP 800-92, Guide to Computer Security Log Management\r\nOT-Specific Recommendations and Guidance\r\nCapturing log events is critical to maintaining situational awareness of\r\nthe OT system. Typical events include maintenance functions (e.g.,\r\naccess control, configuration changes, backup and restore), OS functions,\r\nand application (i.e., process) events. The specific types of events\r\navailable for logging will vary between OT devices and should be\r\nchosen based on the capabilities of the device and the desired events to\r\nbe captured.\r\nTo support log correlation, each log entry should identify the device that\r\ngenerated the event, the timestamp of the event, and the user or system\r\naccount that generated the event. In general, each log entry should also\r\ninclude where the event occurred, the type of event, when the event\r\noccurred, the source of the event, the identity of any users or system\r\naccounts related to the event, and the outcome of the event.\r\nCorrelating events across multiple OT devices can be difficult if the\r\nevent timestamps generated by the devices were not informed by a\r\nshared time source. The internal clocks of each device should be\r\nsynchronized with a primary clock to support event correlation between\r\ndevices. Log entries should also produce a consistent timestamp format\r\n(e.g., time zone format, string format, daylight saving).\r\nThe collection and event forwarding functions may impact the\r\nperformance of the OT device. Depending on the frequency of events\r\nbeing logged, the log size may grow quickly and result in increasing\r\nspace utilization. Disk space and memory are limited on most OT\r\ndevices, so adequate storage should be locally or remotely provided to\r\nreduce the likelihood of exceeding the device capacity, which could\r\nultimately result in the loss of logging capability. Transferring logs from\r\nthe OT devices to alternate storage should be considered.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n119\r\n6.2.7. Media Protection (PR.PT-2)\r\nRemovable media is protected, and use is restricted in accordance with policy. This includes\r\nlabeling media for distribution and handling requirements, as well as storage, transport,\r\nsanitization, destruction, and disposal of the media.\r\nSupplemental guidance can be found in the following documents:\r\n• NIST SP 800-88, Rev. 1, Guidelines for Media Sanitation\r\n• NIST SP 800-100, Information Security Handbook: A Guide for Managers\r\n• NIST SP 800-209, Security Guidelines for Storage Infrastructure\r\nOT-Specific Recommendations and Guidance\r\nProcesses and procedures for the handling of media assets should be\r\ndeveloped and followed. Media assets include removable media and\r\ndevices, such as floppy disks, CDs, DVDs, SD cards, and USB memory\r\nsticks, as well as printed reports and documents. Physical security\r\ncontrols should address specific requirements for the safe and secure\r\nmaintenance of these assets and provide guidance for transporting,\r\nhandling, and erasing or destroying these assets. Security requirements\r\ncould include safe storage from loss, fire, theft, unintentional\r\ndistribution, or environmental damage.\r\nOT devices should be protected against the misuse of media. The use of\r\nany unauthorized removable media or device on any node that is part of\r\nor connected to the OT should not be permitted. Solutions could be\r\neither procedural or technical to prevent the introduction of malware or\r\nthe inadvertent loss or theft of data.\r\nPhysically protecting media or encrypting the data on media is critical to\r\nprotecting the OT environment. Gaining access to media that contains\r\nOT data could provide a malicious actor with valuable information for\r\nlaunching an attack.\r\n6.2.8. Personnel Security\r\nCybersecurity should be included in human resources practices to reduce the risk of human error,\r\ntheft, fraud, or other intentional or unintentional misuse of information systems.\r\nSupplemental guidance for the Personnel Security controls can be found in the following\r\ndocuments:\r\n• NIST SP 800-35, Guide to Information Technology Security Services\r\n• NIST SP 800-73-4, Interfaces for Personal Identity Verification\r\n• NIST SP 800-76-2, Biometric Specifications for Personal Identity Verification\r\n• NIST SP 800-100, Information Security Handbook: A Guide for Managers\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n120\r\nOT-Specific Recommendations and Guidance\r\nA general personnel security program should address policy, position\r\nrisk designations, personnel screening, terminations, transfers, access\r\nagreements, and third-party roles and responsibilities. OT personnel\r\nshould communicate with human resources, IT, and physical security to\r\nensure that personnel security requirements are being met.\r\nAn organization should consider establishing an access agreement and\r\nrequest form for managing physical and/or logical access to OT\r\nequipment. Organizations should also screen the personnel assigned to\r\ncritical positions who control and maintain the OT.\r\nAdditionally, each employee should receive training that is relevant to\r\nand necessary for their job functions. Employees should demonstrate\r\ncompetence in their job functions to retain physical and logical access to\r\nOT. Organizations should consider adopting a framework, such as the\r\nNational Initiative for Cybersecurity Education (NICE) Framework, for\r\ntraining their OT personnel.\r\n6.2.9. Wireless Communications\r\nWireless communications utilize radio frequency (RF) to support data transmission. This can\r\ninclude a Wireless Fidelity (Wi-Fi) local area network communication based on IEEE 802.11\r\nprotocols and may also include cellular or other radio-based communications. RF-based\r\ncommunications provide enhanced flexibility over traditional physical (i.e., wired)\r\ncommunication capabilities. However, RF communications are also more susceptible to\r\ninterference and may allow unauthorized personnel to eavesdrop.\r\nSupplemental guidance for wireless communications can be found in the following documents:\r\n• NIST SP 800-97, Establishing Wireless Robust Security Networks: A Guide to IEEE\r\n802.11i\r\n• NIST SP 800-121, Rev. 2, Guide to Bluetooth Security\r\n• NIST SP 800-153, Guidelines for Securing Wireless Local Area Networks (WLANs)\r\n• NIST SP 800-187, Guide to LTE Security\r\nOT-Specific Recommendations and Guidance\r\nThe use of temporary or permanent wireless communication within an\r\nOT is a risk-based decision determined by the organization. Generally,\r\ndevices that utilize wireless communication should be placed in a\r\nseparate network segment and only be deployed where the residual risks\r\nto health, safety, the environment, and finances are low.\r\nPrior to installation, a wireless survey should be performed to identify\r\nantenna locations and signal strength for adequate coverage and to\r\nminimize the exposure of the wireless network to interference from OT\r\nenvironmental factors and eavesdropping. Attackers typically use\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n121\r\ndirectional antennas to extend the effective range of a wireless network\r\nbeyond the standard range.\r\nOrganizations may choose to implement a wireless mesh network to\r\nimprove resiliency or to eliminate areas with poor signal strength. Mesh\r\nnetworks can provide fault tolerance through alternate route selection\r\nand preemptive fail-over of the network. Organizations should also\r\nconsider the performance and security impacts associated with the use of\r\nmesh networks. For example, when roaming between access points,\r\ndevices may experience temporary communication loss. Roaming may\r\nalso require different security controls to reduce the transition time.\r\nOrganizations will need to find the appropriate balance between\r\nfunctional capabilities and cybersecurity to achieve the risk tolerance.\r\nWireless LANs\r\n• Wireless device communications should be encrypted, and the\r\nencryption must not degrade the operational performance of the\r\nend devices. To reduce encryption latency, encryption should be\r\nconsidered at OSI Layer 2 rather than at Layer 3. The use of\r\nhardware accelerators to perform cryptographic functions should\r\nalso be considered.\r\n• Wireless access points should establish independent network\r\nsegments (rather than extending an existing segment) and be used\r\nin combination with a boundary protection device to restrict and\r\ncontrol communication.\r\n• Wireless access points should be configured to have a unique\r\nservice set identifier (SSID) and enable media access control\r\n(MAC) address filtering at a minimum.\r\n• Wireless devices may require different security controls and\r\nshould be zoned accordingly.\r\n• An adaptive routing protocol should be considered if the devices\r\nare to be used for wireless mobility. The convergence time of the\r\nnetwork should be as fast as possible to support rapid network\r\nrecovery in the event of a failure or power loss.\r\nWireless Field Networks\r\nWhen implementing a wireless field network, the following security\r\nfeatures should be considered:\r\n• Selecting a standard, non-proprietary protocol (e.g., IEEE\r\n802.15.x)\r\n• Ensuring that encryption is used between field instruments and\r\nwireless access points\r\n• Allowlisting devices into the wireless device manager so that\r\nrogue devices cannot connect\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n122\r\n• Implementing appropriately complex passwords and join keys\r\nMost wireless field networks are inherently less reliable than their wired\r\ncounterparts due to their susceptibility to signal jamming, distance\r\nlimitations, and line-of-sight requirements. Work with the system vendor\r\nto design a wireless network that is appropriate for the application.\r\n6.2.10. Remote Access\r\nSecurity controls should be implemented to prevent unauthorized remote access to the\r\norganization’s networks, systems, and data. A virtual private network (VPN) is a set of protocols\r\ndesigned to support secure remote access to network environments. A VPN can provide both\r\nstrong authentication and encryption to secure communication data by establishing a private\r\nnetwork that operates as an overlay on a public infrastructure. The most common types of VPN\r\ntechnologies are:\r\n• Internet Protocol Security (IPsec). IPsec supports two encryption modes: transport and\r\ntunnel. Transport mode encrypts only the data portion (i.e., payload) of each packet while\r\nleaving the packet header untouched. The more secure tunnel mode adds a new header to\r\neach packet and encrypts both the original header and the payload. On the receiving side,\r\nan IPsec-compliant device decrypts each packet.\r\n• Transport Layer Security (TLS). Sometimes referred to by the legacy terminology of\r\nSecure Sockets Layer (SSL), TLS provides a secure channel between two machines that\r\nencrypts the contents of each packet. TLS is most often recognized for securing\r\nHypertext Transfer Protocol (HTTP) traffic in a protocol implementation known as\r\nHTTP Secure (HTTPS). However, TLS is not limited to HTTP traffic and can be used to\r\nsecure many application-layer programs. Only TLS 1.2 or above should be considered.\r\n• Secure Shell (SSH). SSH is a command interface and protocol for securely gaining\r\naccess to a remote computer. It is widely used by network administrators to remotely\r\ncontrol Linux-based servers. SSH is a secure alternative to a telnet application, is\r\nincluded in most UNIX distributions, and is typically added to other platforms through a\r\nthird-party package.\r\nSupplemental guidance for access controls can be found in the following documents:\r\n• NIST SP 800-52, Rev. 2, Guidelines for the Selection, Configuration, and Use of\r\nTransport Layer Security (TLS) Implementations\r\n• NIST SP 800-63B, Digital Identity Guidelines: Authentication and Lifecycle\r\nManagement\r\n• NIST SP 800-77, Rev. 1, Guide to IPsec VPNs\r\n• NIST SP 800-113, Guide to SSL VPNs\r\nOT-Specific Recommendations and Guidance\r\nMany OT security architectures are designed with multiple levels, such\r\nas in the Purdue model. This can significantly limit access, which can\r\nminimize accidental or unauthorized disruptions to operations. A process\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n123\r\nshould be developed and communicated to the organization for\r\nrequesting and enabling remote access. Remote access should be\r\nprovided only if justified and limited to what is required for the business\r\nneed. Remote access should not circumvent or negate safety or security\r\ncontrols. Multi-factor authentication should be considered for remote\r\naccess to the OT system.\r\nIn critical situations or when vendor support is needed, temporary remote\r\naccess may be requested to perform maintenance. In such cases,\r\nprocedures should still be followed to ensure that secure connections are\r\nbeing utilized.\r\nThere are several different techniques for implementing temporary\r\nremote access, including:\r\n• Users or protocols (e.g., RDP, SSH) that are temporarily\r\npermitted through the OT or enterprise firewall\r\n• Screen-sharing technologies\r\n• Modems\r\n• VPNs\r\nRegardless of the technology, organizations should consider the\r\nfollowing:\r\n• Implementing unique usernames and complex passwords\r\n• Removing, disabling, or modifying any default credentials\r\n• Updating any software and firmware to the latest versions\r\n• Removing access when no longer required. Consider\r\nimplementing automatic timers for removing access or managing\r\nchange processes to manually confirm the removal of access.\r\n• Monitoring remote activities\r\n• Ensuring that operations personnel are aware of planned remote\r\nactivity in the OT environment\r\n• Initiating the connection from the OT environment\r\n• Labeling remote connection devices so that operations may\r\ndisconnect quickly in the case of unauthorized use\r\nDial-Up Modems\r\nIf dial-up modems are used in OT environments, consider using callback\r\nsystems. This ensures that a dialer is an authorized user by having the\r\nmodem establish the working connection based on the dialer’s\r\ninformation and a callback number stored in the OT-approved authorized\r\nuser list.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n124\r\nIf feasible, disconnect modems when not in use, or consider automating\r\nthis disconnection process by having modems disconnect after being on\r\nfor a given amount of time. Sometimes, modem connections are part of\r\nthe legal support service agreement with the vendor (e.g., 24/7 support\r\nwith 15-minute response time). Personnel should be aware that\r\ndisconnecting or removing the modems may require contracts to be\r\nrenegotiated.\r\nVPNs\r\nVPN devices used to protect OT systems should be thoroughly tested to\r\nverify that the VPN technology is compatible with the application and\r\nthat implementation of the VPN devices does not negatively impact\r\nnetwork traffic characteristics.\r\nVPN technology can also be applied between network segments. For\r\nexample, a remote site might have a boundary protection device on-site\r\nthat uses a VPN to establish a secure tunnel over an untrusted network\r\n(e.g., the internet) to a VPN-enabled device in the main control center at\r\na different location.\r\n6.2.11. Flaw Remediation and Patch Management\r\nPatches are additional pieces of code that have been developed to address specific problems or\r\nflaws in existing software. A systematic approach to managing and using software patches can\r\nhelp organizations improve the overall security of their systems in a cost-effective way.\r\nOrganizations that actively manage and use software patches can reduce the chances that the\r\nvulnerabilities in their systems can be exploited, and they can save time and money that might be\r\nbetter spent responding to vulnerability-related incidents.\r\nNIST SP 800-40, Rev. 4 [SP800-40r4] provides guidance for CIOs, CISOs, and others who are\r\nresponsible for managing organizational risk related to the use of software. This publication\r\nframes patching as a critical component of preventive maintenance for computing technologies –\r\na cost of doing business and a necessary part of what organizations need to do in order to achieve\r\ntheir missions. This publication also discusses common factors that affect enterprise patch\r\nmanagement and recommends creating an enterprise strategy to simplify and operationalize\r\npatching while also improving risk reduction. This guidance may also be useful to business and\r\nmission owners, security engineers and architects, system administrators, and security operations\r\npersonnel.\r\nSupplemental guidance for flaw remediation and patch management can be found in the\r\nfollowing document:\r\n• NIST SP 800-40, Rev. 4, Guide to Enterprise Patch Management Planning: Preventive\r\nMaintenance for Technology\r\nOT-Specific Recommendations and Guidance\r\nSignificant care should be exercised when applying patches to OS\r\ncomponents. Patches should be adequately tested (e.g., offline system\r\ntesting) to determine the acceptability of any performance impacts.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n125\r\nRegression testing is also advised. It is not uncommon for patches to\r\nhave an adverse impact on other software. A patch may remove a\r\nvulnerability, but it can also introduce a greater risk from a production or\r\nsafety perspective. Patching the vulnerability may also change the way\r\nthe OS or application works with control applications, causing the\r\ncontrol application to lose some of its functionality. Many OT systems\r\nutilize older versions of OSs that are no longer supported by the vendor,\r\nso patches may not be available.\r\nOrganizations should implement a systematic, accountable, and\r\ndocumented OT patch management process for managing exposure to\r\nvulnerabilities. The patch management process should include guidance\r\non how to monitor for patches, when to apply patches, how to test the\r\npatches (e.g., with vendors or on offline systems), and how to select\r\ncompensating controls to limit exposure of the vulnerable system when\r\npatching is delayed.\r\nMany OT vulnerabilities are published to CISA as advisories. However,\r\nnot all vendors report known vulnerabilities to CISA. Organizations can\r\noften stay informed of vulnerabilities by subscribing to vendor-specific\r\nnotifications in addition to CISA alerts and advisories. Private\r\ncybersecurity companies also offer services to assist organizations with\r\nstaying informed about known vulnerabilities within their OT\r\nenvironment. An organization is responsible for staying informed and\r\ndetermining when patches should be applied as part of their documented\r\npatch management process.\r\nWhen and how to deploy patches should be determined by\r\nknowledgeable OT personnel. Consider separating the automated process\r\nfor OT patch management from the automated process for non-OT\r\napplications. Patching should be deployed during planned OT outages.\r\nOrganizations may be required to follow industry-specific guidance on\r\npatch management. Otherwise, they may develop patch management\r\nprocedures based on existing standards, such as NIST SP 800-40, Rev. 4\r\n[SP800-40r4]; NERC CIP-007, or ISA 62443-2-3, Patch Management in\r\nthe IACS Environment.\r\n6.2.12. Time Synchronization\r\nTime synchronization solutions enable an organization to synchronize time across many devices.\r\nThis is important for many functions, including event and log correlation, authentication\r\nmechanisms, access control, and quality of service.\r\nSupplemental guidance can be found in the following documents:\r\n• NIST SP 800-92, Guide to Computer Security Log Management\r\n• NIST IR 8323, Foundational PNT Profile: Applying the Cybersecurity Framework for\r\nthe Responsible Use of Positioning, Navigation, and Timing (PNT) Services\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n126\r\nOT-Specific Recommendations and Guidance\r\nSynchronizing the internal clocks of OT systems and devices is critical\r\nfor cyber event correlation and other OT functions (e.g., motion control).\r\nIf a device or system clock is inaccurate, the timestamps generated by\r\nthe clock for event and log entries will also be inaccurate, as well as any\r\nother functions that utilize the clock.\r\nA common time should be used across all OT devices. Utilizing multiple\r\ntime sources can benefit OT devices by reducing clock error and\r\nproviding backup time sources if the primary time source is lost or if the\r\ntime quality of a primary time source has degraded.\r\nAuthenticated Network Time Protocol (NTP) and secure Precision Time\r\nProtocol (PTP) (i.e., PTP with an authentication TLV [type, length,\r\nvalue]) can be used if there is a risk of malicious modification to the\r\nnetwork time (e.g., RF jamming, packet spoofing, denial of service).\r\nNon-authenticated NTP is susceptible to spoofing and should be located\r\nbehind the firewall.\r\nTime sources located in the OT environment should be included in the\r\nsystem and network monitoring programs. If available, logs from each\r\ntime source (e.g., syslog) should be forwarded to a log collection system.\r\n Detect (DE)\r\nThe Detect Function enables the timely discovery of cybersecurity events by ensuring that\r\nappropriate activities are developed and implemented.\r\n6.3.1. Anomalies and Events (DE.AE)\r\nOrganizations should understand different events, anomalies, and their potential impacts to\r\nsystems and the environment to establish an effective detection capability. Within any\r\nenvironment, numerous non-malicious and potentially malicious events and anomalies occur\r\nalmost continuously. Some examples of common events include:\r\nInformation Events\r\n• Multiple failed logon attempts\r\n• Locked-out accounts\r\n• Unauthorized creation of new accounts\r\n• Unexpected remote logons (e.g., logons of individuals who are on vacation, remote logon\r\nwhen the individual is expected to be local, remote logon for maintenance support when\r\nno support was requested)\r\n• Cleared event logs\r\n• Unexpectedly full event logs\r\n• Antivirus or IDS alerts\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n127\r\n• Disabled antivirus or other security controls\r\n• Requests for information about the system or architecture (e.g., social engineering or\r\nphishing attempts)\r\nOperational Events\r\n• Unauthorized configuration changes\r\n• Unauthorized patching of systems\r\n• Unplanned shutdowns\r\nPhysical Access Events\r\n• Physical intrusions\r\nNetworking Events\r\n• Unexpected communication, including new ports or protocols being used without\r\nappropriate change management\r\n• Unusually heavy network traffic\r\n• Unauthorized devices connecting to the network\r\n• Unauthorized communication to external IPs\r\nOrganizations should consider that not all events and anomalies are malicious or require\r\ninvestigation. Organizations should define incident alerting thresholds and response requirements\r\nfor the events and anomalies that affect their systems and environment to establish an efficient\r\nincident detection capability.\r\nOrganizations should consider collecting and correlating event data from multiple sources and\r\nsensors using automated mechanisms where possible to improve detecting and alerting\r\ncapabilities. For example, a centralized intrusion detection system could accept data feeds and\r\nlogs from multiple devices and network segments to identify organization- or environment-specific events and sound an alarm. Detection tools should also be integrated with asset\r\nmanagement tools. This integration can provide additional context to an event (e.g., where the\r\nsystem is located, which firmware version it runs, what the criticality of the system is) to help an\r\norganization determine the event impact.\r\nSupplemental guidance can be found in the following documents:\r\n• NIST SP 800-92, Guide to Computer Security Log Management\r\n• NIST SP 800-94, Guide to Intrusion Detection and Prevention Systems\r\n• NIST SP 1800-7, Situational Awareness for Electric Utilities\r\nOT-Specific Recommendations and Guidance\r\nOrganizations should consider OT-specific events and anomalies for\r\ntheir processes and environments. Organizations should also note that\r\nsome tools and alerts for behaviors or events that could indicate an\r\nintrusion may be normal behaviors and events within the OT\r\nenvironment. To reduce false positive and nuisance alarms, organizations\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n128\r\nshould establish their OT alerting thresholds based on baselines of\r\nnormal network traffic and data flows in addition to normal human and\r\nOT process behavior. Additionally, OT components are often physically\r\nremote and not continually staffed. Alerting thresholds may need to take\r\ninto consideration the response time associated with the alert. For\r\nexample, a temperature alert threshold may have to be set to alert earlier\r\nbased on the expected response time to correct the situation in order to\r\navoid an incident.\r\nShared credentials are often used on OT systems. Anomalous behavior\r\non shared accounts may be more difficult to determine, so organizations\r\nshould consider whether additional controls are required, such as\r\nidentifying the use of shared credentials using physical access\r\nmonitoring.\r\n6.3.2. Security Continuous Monitoring (DE.CM)\r\nOrganizations should implement continuous monitoring as part of the organizational risk\r\nmanagement strategy to monitor the effectiveness of protective measures. This includes\r\nestablishing the frequency for evaluating the implementation of the desired outcomes.\r\nContinuous monitoring can be performed by internal or external resources to identify security\r\ngaps within the environment. Peer reviews (i.e., cold eyes reviews) between sites of the same\r\norganization are highly encouraged. When leveraging third-party services for security continuous\r\nmonitoring, it is important to understand and evaluate how the organization’s continuous\r\nmonitoring data is protected by the third party. A third party that aggregates continuous\r\nmonitoring information from multiple organizations may be a desirable target for adversaries.\r\nSupplemental guidance can be found in the following documents:\r\n• NIST SP 800-53A, Rev. 5, Assessing Security and Privacy Controls in Information\r\nSystems and Organizations\r\n• NIST SP 800-55, Rev. 1, Performance Measurement Guide for Information Security\r\n• NIST SP 800-115, Technical Guide to Information Security Testing and Assessment\r\n• NIST SP 800-137, Information Security Continuous Monitoring (ISCM) for Federal\r\nInformation Systems and Organizations\r\n• NIST SP 800-137A, Assessing Information Security Continuous Monitoring (ISCM)\r\nPrograms: Developing an ISCM Program Assessment\r\nOT-Specific Recommendations and Guidance\r\nOrganizations may find that automation within OT environments may\r\nnot be possible due to the sensitivity of the systems or the resources\r\nrequired to support the automation. For example, some automated\r\nsystems may utilize active scanning to support vulnerability or patch\r\nmanagement or to validate device configurations. Solutions that perform\r\nactive scanning or use local resources to support automation should be\r\ntested before deployment into the OT system.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n129\r\nContinuous monitoring can be achieved using automated tools, through\r\npassive scanning, or with manual monitoring performed at a frequency\r\ndeemed commensurate with the risk. For example, a risk assessment may\r\ndetermine that the logs from isolated (i.e., non-networked), non-critical\r\ndevices should be reviewed monthly by OT personnel to determine\r\nwhether anomalous behavior is occurring. Alternatively, a passive\r\nnetwork monitor might be able to detect vulnerable network services\r\nwithout having to scan the devices.\r\nWhen organizations implement a sampling methodology, the criticality\r\nof the components should be considered. For example, the sampling\r\nmethodology should not inadvertently exclude higher risk devices, such\r\nas Layer 3 or Layer 4 firewalls.\r\nWhen using third parties to continuously monitor security controls,\r\nensure that the personnel involved have the appropriate skillset to\r\nanalyze OT environments.\r\n6.3.2.1. Network Monitoring (DE.CM-1)\r\nNetwork monitoring involves organizations reviewing alerts and logs and analyzing them for\r\nsigns of possible cybersecurity incidents. Organizations should consider automation – including\r\nin-house developed, commercially available solutions or some combination of tools – to assist\r\nwith monitoring efforts. Tools and capabilities that support behavior anomaly detection (BAD),\r\nsecurity information and event management (SIEM), intrusion detection systems (IDS), and\r\nintrusion prevention systems (IPS) can assist organizations with monitoring traffic throughout\r\nthe network and generate alarms when they identify anomalous or suspicious traffic. Some other\r\ncapabilities to consider for network monitoring include:\r\n• Asset management, including discovering and inventorying devices connected to the\r\nnetwork\r\n• Baselining typical network traffic, data flows, and device-to-device communications\r\n• Diagnosing network performance issues\r\n• Identifying misconfigurations or malfunctions of networked devices\r\nSupplemental guidance can be found in the following documents:\r\n• NIST SP 800-94, Guide to Intrusion Detection and Prevention Systems (IDPS)\r\n• NIST IR 8219, Securing Manufacturing Industrial Control Systems: Behavioral Anomaly\r\nDetection\r\nOT-Specific Recommendations and Guidance\r\nNetwork monitoring can greatly enhance the ability to detect attacks\r\nentering or leaving the OT networks. It can also improve network\r\nefficiency by detecting non-essential traffic. OT cybersecurity personnel\r\nmust be part of the diagnostic process of interpreting the alerts provided\r\nby network monitoring tools. Careful monitoring and an understanding\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n130\r\nof the normal state of the OT network can help distinguish transient\r\nconditions from legitimate attacks and provide insight into events that\r\nare outside of the normal state.\r\nGaining access to network traffic is typically performed with network\r\ntest access points (TAPs) and switched port analyzer (SPAN) ports,\r\nthough performance impacts to the OT system may result from their use,\r\nespecially with SPAN ports.\r\nNetwork sensors should be placed to effectively monitor the OT\r\nnetwork. Typical installations locate the network sensors between the\r\ncontrol network and corporate network, but other locations can include\r\nnetwork perimeters, key network segments (e.g., DMZ), and critical OT\r\ndevices.\r\nAll sensors should be subjected to extensive testing and be implemented\r\nin a test environment before being deployed into the OT network.\r\nConfiguring the sensor into a test or learning mode after it is installed on\r\nthe network provides an opportunity to tune the device with real OT\r\nnetwork traffic. Tuning can help reduce false positive alerts, reduce the\r\nalert “noise” from typical network traffic, and help identify\r\nimplementation and configuration problems.\r\nFailure modes of network sensors in the event of a sensor failure should\r\nbe considered (e.g., does the sensor fail-safe or fail-open if the device\r\nfails).\r\n6.3.2.2. System Use Monitoring (DE.CM-1 and DE-CM-3)\r\nSystem use monitoring solutions enable an organization to monitor, store, and audit system\r\nevents (e.g., system logs, running processes, file access and modification, system and application\r\nconfiguration changes) that occur within a system. Monitoring users and systems helps to ensure\r\nthat they are behaving as expected and can aid in troubleshooting when events occur by\r\nproviding information about which users were working within the system during the event.\r\nSystem and device misconfigurations can also be identified.\r\nCompared to network monitoring, system use monitoring solutions can analyze activity that does\r\nnot traverse the network. In host-based solutions, this can be achieved with real-time monitoring\r\nof inter-process communications and other internal OS data, while active scanning solutions\r\ngather information by querying the OS or application programming interfaces (APIs).\r\nSupplemental guidance can be found in the following documents:\r\n• NIST SP 800-94, Guide to Intrusion Detection and Prevention Systems (IDPS)\r\n• NIST SP 800-137, Information Security Continuous Monitoring (ISCM) for Federal\r\nInformation Systems and Organizations\r\nOT-Specific Recommendations and Guidance\r\nSituational awareness of the OT system is imperative to understanding\r\nthe current state of the system, validating that it is operating as intended,\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n131\r\nand ensuring that no policy violations or cyber incidents have hindered\r\nits operation. Strong device monitoring, logging, and auditing are\r\nnecessary to collect, correlate, and analyze security-related information\r\nand provide actionable communication about the security status across\r\nthe complete OT system. In the event of a cybersecurity incident, the\r\ninformation gathered by system use monitoring solutions can be used to\r\nperform forensic analysis of the OT system.\r\nSystem use monitoring solutions can generate significant amounts of\r\nevents, so these solutions should be used in combination with a control\r\nlog management system, such as a SIEM, to help filter the types of\r\nevents and reduce alert fatigue. The amount of tuning and customization\r\nof events and alerts depends on the type of OT system and the number of\r\ndevices in the system.\r\nSystem use monitoring solutions should be subjected to extensive testing\r\nand implemented in a test environment before being deployed to devices\r\nin the OT system. Concerns include the performance impacts of host-based agents on devices, the impact of active scanning on devices, and\r\nthe capability of the network infrastructure bandwidth. Separate\r\nappliances can offload the processing. Host-based agents can impact the\r\nperformance of the OT device because of the resources that they\r\nconsume.\r\n6.3.2.3. Malicious Code Detection (DE.CM-4)\r\nWhen stored, processed, and transmitted, files and data streams should be scanned using\r\nspecialized tools with a combination of heuristic algorithms and known malware signatures to\r\ndetect and block potentially malicious code. Malicious code protection tools only function\r\neffectively when they are installed, configured, run full-time, and maintained properly against\r\nthe state of known attack methods and payloads.\r\nSupplemental guidance for anti-malware practices can be found in the following documents:\r\n• NIST SP 800-83, Rev. 1, Guide to Malware Incident Prevention and Handling for\r\nDesktops and Laptops\r\n• NIST SP 1058, Using Host-Based Anti-Virus Software on Industrial Control Systems:\r\nIntegration Guidance and a Test Methodology for Assessing Performance Impacts\r\nOT-Specific Recommendations and Guidance\r\nWhile antivirus tools are common in IT computer systems, the use of\r\nantivirus with OT may require adopting special practices, including\r\ncompatibility checks, change management, and performance impact\r\nmetrics. These practices should be utilized to test new signatures and\r\nnew versions of antivirus software.\r\nSome OT vendors recommend and even support the use of vendor-specific antivirus tools. In some cases, OT system vendors may have\r\nperformed regression testing across their product line for supported\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n132\r\nversions of a particular antivirus tool and provide associated installation\r\nand configuration documentation.\r\nGenerally:\r\n• General-purpose Windows, Unix, and Linux systems that are\r\nused as engineering workstations, data historians, maintenance\r\nlaptops, and backup servers can be secured like commercial IT\r\nequipment by installing push or auto-updated antivirus software\r\nwith updates distributed via an antivirus server located inside the\r\nprocess control network. Follow organization-developed\r\nprocedures for transferring the latest updates from known vendor\r\nsites to the OT antivirus servers and other OT computers and\r\nservers.\r\n• Follow vendor recommendations on all other servers and\r\ncomputers (e.g., DCS, PLC, instruments) that have time-dependent code, modified or extended OSs, or any other change\r\nthat makes them different from a standard PC. Test the antivirus\r\nsoftware and updates on an offline system if possible (e.g., install\r\non a backup HMI and validate that performance is not degraded\r\nbefore applying to the primary HMI).\r\nAccording to NIST SP 1058 [SP1058], antivirus software may\r\nnegatively impact the time-critical control processes of an ICS. The SP\r\nalso identified significant CPU usage when running manual scans and\r\nsignature updates, which could have negative impacts on OT computers\r\nand servers. As a result:\r\n• Configuration of the antivirus software should be tested on an\r\noffline system, if possible.\r\n• Manual scanning and signature updates should be performed\r\nwhile the system is not critical for operations.\r\n• Redundancy should be considered for critical systems that require\r\nongoing antivirus updates such that signature updates can be\r\nperformed without impacting operations (e.g., consoles and\r\nHMIs).\r\n• When configuring file exclusion lists, determine which control\r\napplication files should not be scanned during production time\r\nbecause of possible OT system malfunction or performance\r\ndegradation.\r\nCISA provides a recommended practice for updating antivirus in OT\r\nenvironments.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n133\r\n6.3.2.4. Vulnerability Scanning (DE.CM-8)\r\nVulnerabilities can be identified through a combination of automated and manual techniques.\r\nThese vulnerability scans should be performed on an ongoing basis to capture new\r\nvulnerabilities as they are discovered.\r\nOT-Specific Recommendations and Guidance\r\nSome common ways to achieve vulnerability identification in the OT\r\nenvironment are:\r\n• Continuous monitoring using passive or active scanning\r\ncapabilities. Organizations should consider how vulnerability\r\nscanning tools may impact OT components and communications\r\nby testing them in an offline environment prior to implementing\r\nthem in production.\r\no Passive scanning tools typically utilize network traffic\r\nanalyzers to detect assets and determine possible\r\nvulnerabilities affecting the assets.\r\no Active scanning tools typically utilize an agent to connect\r\nto networked assets and perform detailed queries and\r\nanalysis of the components to determine possible\r\nvulnerabilities affecting the assets.\r\n• Performance testing, load testing, and penetration testing if the\r\ntest will not adversely impact the production environment\r\n• Regular audits, assessments, and peer reviews to identify gaps in\r\nsecurity\r\n6.3.3. Detection Process (DE.DP)\r\nThe detection process includes maintaining and testing processes, procedures, and tools to ensure\r\nthat anomalous events are identified in a prompt manner and responsible parties (individuals) are\r\nalerted and held accountable for adequate responses. To ensure the ongoing awareness of\r\nanomalous events, define roles and responsibilities for accountability, periodically review that\r\ndetection activities comply with the requirements, test the detection processes regularly,\r\ncommunicate detected events to appropriate personnel to act, and continuously improve\r\ndetection capabilities.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n134\r\n Respond (RS)\r\nThe Respond Function supports the ability to take the appropriate course of action and activities\r\nto contain a cybersecurity incident when it occurs.\r\n6.4.1. Response Planning (RS.RP)\r\nWhen responding to events, organizations should attempt to capture the details associated with\r\nexecuting the documented response plans. This may help organizations identify gaps or potential\r\nopportunities for improvement in the response plan during the post-incident review process. Due\r\nto the time sensitivity of response efforts, organizations may want to consider other techniques\r\n(e.g., reviewing logs, reviewing video footage captured during the response activities, or\r\ninterviewing response personnel) if capturing execution details impacts safety or increases the\r\ntime to complete the response plan.\r\n6.4.2. Response Communications (RS.CO)\r\nResponding to a cybersecurity incident includes coordinating with internal and external\r\nstakeholders. An incident response team should be assembled. Depending on the complexity and\r\nimpact of the incident, the incident response team could consist of one or many individuals who\r\nhave been trained on incident response. The FEMA National Incident Management System\r\n(NIMS) can be used to standardize common terminology and roles for incident response.\r\nPrior to an incident, organizations should consider how to communicate with response personnel\r\nand external entities, including:\r\n• Developing an email distribution list for incident response\r\n• Leveraging an emergency notification system\r\n• Establishing backup communication plans for radio, phone, or email if primary\r\ncommunication systems fail\r\n• Designating a spokesperson for external communications\r\n• Designating a scribe for internal incident communications\r\nOT-Specific Recommendations and Guidance\r\nOrganizations should consider FEMA’s guidance on crisis\r\ncommunications when establishing their communication plans and\r\nstrategies.\r\nThe personnel responsible for responding to an incident should be\r\ninformed of and trained on their responsibilities.\r\nThe response plan should include a detailed list of organizations and\r\npersonnel that should be contacted for incident response and reporting\r\nunder various circumstances. Each individual should be assigned roles\r\nthat are required for incident response, which could include incident\r\ncommander; operations, planning, logistics, or finance/administration\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n135\r\nsection chief or member; and public information, safety, or liaison\r\nofficer.\r\nTo support a response in an OT environment, an organization should\r\nconsider including the following personnel in the response plan.\r\nInternal Resources\r\n• Designated Incident Commander\r\n• Operations leadership\r\n• Safety personnel\r\n• On-call OT systems personnel\r\n• On-call IT personnel\r\n• Physical security personnel\r\n• Administrative personnel\r\n• Procurement personnel\r\n• Public relations personnel\r\n• Legal personnel\r\nExternal Industry Partners\r\n• OT technical support (e.g., vendors, integrators)\r\n• Operational supply chain (e.g., suppliers, customers, distributors,\r\nbusiness partners)\r\n• Incident response team\r\n• Surge support\r\n• Impacted community (e.g., facility neighbors)\r\nOrganizations are required to report incidents involving federal agencies\r\nin accordance with PPD-21 [PPD-21] and PPD-41 [PPD-41]. CISA\r\nmaintains the list of sector-specific contacts.\r\nLegal departments can often assist with developing non-disclosure\r\nagreements or other contracts if an organization plans to utilize external\r\nresources for incident response. It may be beneficial to develop these\r\ncontracts prior to an incident occurring so that incident response can be\r\nimmediate. Private companies can be held on retainer in case of an OT\r\nincident.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n136\r\n6.4.3. Response Analysis (RS.AN)\r\nCybersecurity incidents are analyzed to ensure effective response and recovery activities that are\r\nconsistent with the detection process and the response plan. Analysis includes reviewing\r\nnotifications, determining whether an investigation is required, understanding potential impacts,\r\nperforming forensics, categorizing the incident consistent with the response plan, and analyzing\r\ndisclosed vulnerabilities.\r\nSupplemental guidance for the response analysis controls can be found in the following\r\ndocument:\r\n• NIST SP 800-86, Guide to Integrating Forensic Techniques into Incident Response\r\nOT-Specific Recommendations and Guidance\r\nWhen determining the overall impact of a cybersecurity incident,\r\nconsider the dependencies of OT and its resulting impact on operations.\r\nFor example, an OT system may be dependent on IT for business\r\napplications, such that an incident on the IT network results in an OT\r\ndisconnect or shutdown.\r\nIf an organization does not have adequate resources or capabilities to\r\nconduct OT forensics, consider engaging external organizations to\r\nperform forensic analysis.\r\nOrganizations should identify and classify cyber and non-cyber incidents\r\nthat affect the OT environment according to the incident response plan.\r\nWhen developing the OT incident response plan, potential classes of\r\nincidents could include accidental actions taken by authorized personnel,\r\ntargeted malicious attacks, and untargeted malicious attacks.\r\n6.4.4. Response Mitigation (RS.MI)\r\nMitigation activities are meant to prevent expansion of the incident, mitigate its effects, and\r\nresolve the incident and should be consistent with the response plan.\r\nOT-Specific Recommendations and Guidance\r\nOT components are often physically remote and not continually staffed.\r\nFor these cases, consider how the organization would respond during an\r\nincident and the additional time required to coordinate the response. The\r\nsystem may need to be designed with the capability to minimize impacts\r\nuntil personnel can arrive on-site (e.g., remote shutdown or disconnects).\r\nCyber incident mitigation may involve process shutdowns or\r\ncommunication disconnects that impact operations. These impacts\r\nshould be understood and communicated during incident mitigation.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n137\r\n6.4.5. Response Improvements (RS.IM)\r\nOrganizational response activities are improved by incorporating lessons learned from current\r\nand previous detection and response activities. Organizations should designate one or more\r\nindividuals to be responsible for documenting and communicating response actions to the\r\nincident response team, which can later be reviewed for lessons learned.\r\n Recover (RC)\r\nTimely recovery to normal operations after a cybersecurity incident is critical. The Recover\r\nFunction addresses developing and implementing activities to maintain system resilience and\r\nensure timely restoration of capabilities and services affected by a cybersecurity incident.\r\n6.5.1. Recovery Planning (RC.RP)\r\nWhen recovering from events, organizations should attempt to capture details associated with the\r\nexecution of the documented recovery plans. Capturing execution details may help organizations\r\nduring the post-incident review process to determine whether any gaps or potential opportunities\r\nfor improvement in the recovery plan should be considered. Due to the time sensitivity of\r\nrecovery efforts, organizations may want to consider other techniques (e.g., reviewing logs,\r\nreviewing video footage captured during the recovery activities, or interviewing recovery\r\npersonnel) if capturing execution details impacts safety or increases the time to complete the\r\nrecovery plan.\r\nSupplemental guidance for recovery planning can be found in the following documents:\r\n• NIST SP 800-184, Guide for Cybersecurity Event Recovery\r\n• NIST SP 800-209, Security Guidelines for Storage Infrastructure\r\n6.5.2. Recovery Improvements (RC.IM)\r\nAs a recovery effort is ongoing, the recovery steps taken should be documented to identify\r\nlessons learned. These lessons can be used to improve recovery plans and processes.\r\nSupplemental guidance for recovery improvements can be found in the following document:\r\n• NIST SP 800-184, Guide for Cybersecurity Event Recovery\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n138\r\n6.5.3. Recovery Communications (RC.CO)\r\nRestoration activities are coordinated with internal and external parties. In addition to operational\r\nrecovery, an organization may need to manage public relations and repair its reputation.\r\nSupplemental guidance for recovery communications can be found in the following document:\r\n• NIST SP 800-184, Guide for Cybersecurity Event Recovery\r\nOT-Specific Recommendations and Guidance\r\nA list of internal and external resources for recovery activities should be\r\ndeveloped as part of the recovery planning effort. During an event, this\r\nlist should be used to get all necessary personnel on-site, as required, to\r\nrecover within the RTO and RPO.\r\nInternal Communications\r\n• OT personnel\r\n• IT personnel\r\n• Procurement\r\n• Management with appropriate authority to approve the cost of\r\nrecovery\r\n• Storage or warehouse personnel\r\nExternal Communications\r\n• OT vendors\r\n• Security companies that may be held on retainer for response and\r\nrecovery efforts\r\n• Storage or warehouse personnel\r\n• Internet service providers\r\n• Owners of the attacking systems and potential victims\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n139\r\nReferences\r\n[AGA12] American Gas Association (2006) Cryptographic Protection of SCADA\r\nCommunications, Part 1: Background, Policies and Test Plan. AGA Report\r\nNo. 12.\r\n[ANSI-ISA-5-1] International Society of Automation (2009) Instrumentation Symbols and\r\nIdentification, ANSI/ISA-5.1-2009. Available at\r\nhttps://webstore.ansi.org/Standards/ISA/ANSIISA2009\r\n[ANSI-ISA-51-1] International Society of Automation (1993) Process Instrumentation\r\nTerminology, ANSI/ISA-51.1-1979 (R1993). Available at\r\nhttps://www.isa.org/products/isa-51-1-1979-r1993-process-instrumentation-termin\r\n[ANSI-ISA-84] Instrumentation, Systems, and Automation Society (2004) Functional Safety:\r\nSafety Instrumented Systems for the Process Industry Sector – Part 1:\r\nFramework, Definitions, System, Hardware, and Software Requirements.\r\nANSI/ISA-84.00.01-2004 Part 1. Available at\r\nhttps://webstore.ansi.org/standards/isa/ansiisa8400012004part\r\n[ATTACK-ICS] The MITRE Corporation (2022) ATT\u0026CK® for Industrial Control Systems.\r\nAvailable at https://attack.mitre.org/techniques/ics/\r\n[Bailey] Bailey D, Wright E (2003) Practical SCADA for Industry. (IDC\r\nTechnologies, Vancouver, Canada).\r\n[Berge] Berge J (2002) Fieldbuses for Process Control: Engineering, Operation, and\r\nMaintenance. (International Society of Automation, Research Triangle Park,\r\nNorth Carolina).\r\n[Boyer] Boyer S (2010) SCADA: Supervisory Control and Data Acquisition. 4th ed.\r\n(International Society of Automation, Research Triangle Park, North\r\nCarolina).\r\n[CISA-CIVR] Cybersecurity and Infrastructure Security Agency (2021) Cybersecurity\r\nIncident \u0026 Vulnerability Response Playbooks: Operational Procedures for\r\nPlanning and Conducting Cybersecurity Incident and Vulnerability Response\r\nActivities in FCEB Information Systems. Available at\r\nhttps://www.cisa.gov/sites/default/files/publications/Federal_Government_Cy\r\nbersecurity_Incident_and_Vulnerability_Response_Playbooks_508C.pdf\r\n[CNSS1253] Committee on National Security Systems (2014) Security Categorization and\r\nControl Selection for National Security Systems. CNSS Instruction (CNSSI)\r\nNo. 1253. Available at\r\nhttps://www.cnss.gov/CNSS/issuances/Instructions.cfm\r\n[CNSS4009] Committee on National Security Systems (2022) Committee on National\r\nSecurity Systems (CNSS) Glossary. CNSS Instruction (CNSSI) No. 4009.\r\nAvailable at https://www.cnss.gov/CNSS/issuances/Instructions.cfm\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n140\r\n[CSF] National Institute of Standards and Technology (2018) Framework for\r\nImproving Critical Infrastructure Cybersecurity, Version 1.1. (National\r\nInstitute of Standards and Technology, Gaithersburg, MD).\r\nhttps://doi.org/10.6028/NIST.CSWP6\r\n[EO13636] Executive Order 13636 (2013) Improving Critical Infrastructure\r\nCybersecurity. (The White House, Washington, DC), DCPD-201300091,\r\nFebruary 12, 2013. https://www.govinfo.gov/app/details/DCPD-201300091\r\n[Erickson] Erickson K, Hedrick J (1999) Plantwide Process Control. (John Wiley \u0026\r\nSons, Inc., New York, NY).\r\n[FIPS140-2] National Institute of Standards and Technology (2001) Security Requirements\r\nfor Cryptographic Modules. (U.S. Department of Commerce, Washington,\r\nDC), Federal Information Processing Standards Publication (FIPS) 140-2,\r\nChange Notice 2 December 03, 2002. https://doi.org/10.6028/NIST.FIPS.140-\r\n2\r\n[FIPS140-3] National Institute of Standards and Technology (2019) Security Requirements\r\nfor Cryptographic Modules. (U.S. Department of Commerce, Washington,\r\nDC), Federal Information Processing Standards Publication (FIPS) 140-3.\r\nhttps://doi.org/10.6028/NIST.FIPS.140-3\r\n[FIPS180] National Institute of Standards and Technology (2015) Secure Hash Standard\r\n(SHS). (U.S. Department of Commerce, Washington, DC), Federal\r\nInformation Processing Standards Publication (FIPS) 180-4.\r\nhttps://doi.org/10.6028/NIST.FIPS.180-4\r\n[FIPS186] National Institute of Standards and Technology (2023) Digital Signature\r\nStandard (DSS). (U.S. Department of Commerce, Washington, DC), Federal\r\nInformation Processing Standards Publication (FIPS) 186-5.\r\nhttps://doi.org/10.6028/NIST.FIPS.186-5\r\n[FIPS197] National Institute of Standards and Technology (2001) Advanced Encryption\r\nStandard (AES). (U.S. Department of Commerce, Washington, DC), Federal\r\nInformation Processing Standards Publication (FIPS) NIST FIPS 197-upd1,\r\nupdated May 9, 2023. https://doi.org/10.6028/NIST.FIPS.197-upd1\r\n[FIPS199] National Institute of Standards and Technology (2004) Standards for Security\r\nCategorization of Federal Information and Information Systems. (U.S.\r\nDepartment of Commerce, Washington, DC), Federal Information Processing\r\nStandards Publication (FIPS) 199. https://doi.org/10.6028/NIST.FIPS.199\r\n[FIPS200] National Institute of Standards and Technology (2006) Minimum Security\r\nRequirements for Federal Information and Information Systems. (U.S.\r\nDepartment of Commerce, Washington, DC), Federal Information Processing\r\nStandards Publication (FIPS) 200. https://doi.org/10.6028/NIST.FIPS.200\r\n[FIPS201] National Institute of Standards and Technology (2022) Personal Identity\r\nVerification (PIV) of Federal Employees and Contractors. (U.S. Department\r\nof Commerce, Washington, DC), Federal Information Processing Standards\r\nPublication (FIPS) 201-3. https://doi.org/10.6028/NIST.FIPS.201-3\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n141\r\n[FIPS202] National Institute of Standards and Technology (2015) SHA-3 Standard:\r\nPermutation-Based Hash and Extendable-Output Functions. (U.S. Department\r\nof Commerce, Washington, DC), Federal Information Processing Standards\r\nPublication (FIPS) 202. https://doi.org/10.6028/NIST.FIPS.202\r\n[FISMA] Federal Information Security Modernization Act of 2014, Pub. L. 113-283,\r\n128 Stat. 3073. https://www.govinfo.gov/app/details/PLAW-113publ283\r\n[IEC61511] International Electrotechnical Commission (2016) Functional safety – Safety\r\ninstrumented systems for the process industry sector – Part 1: Framework,\r\ndefinitions, system, hardware and application programming requirements, IEC\r\n61511-1:2016. Available at https://webstore.iec.ch/publication/24241\r\n[IEC62264] International Electrotechnical Commission (2013) Enterprise-control system\r\nintegration - Part 1: Models and terminology, IEC 62264-1:2013. Available at\r\nhttps://webstore.iec.ch/publication/6675\r\n[IIRA19] Industry IoT Consortium (2019) The Industrial Internet of Things Volume G1:\r\nReference Architecture, Version 1.9. Available at\r\nhttps://www.iiconsortium.org/pdf/IIRA-v1.9.pdf\r\n[IR6859] Falco J, Stouffer K, Wavering A, Proctor F (2002) IT Security for Industrial\r\nControl Systems. (National Institute of Standards and Technology,\r\nGaithersburg, MD), NIST Interagency Report (IR) 6859. Available at\r\nhttps://doi.org/10.6028/NIST.IR.6859\r\n[IR8062] Brooks SW, Garcia ME, Lefkovitz NB, Lightman S, Nadeau EM (2017) An\r\nIntroduction to Privacy Engineering and Risk Management in Federal\r\nSystems. (National Institute of Standards and Technology, Gaithersburg,\r\nMD), NIST Internal or Interagency Report (IR) 8062.\r\nhttps://doi.org/10.6028/NIST.IR.8062\r\n[IR8183A] Stouffer KA, Zimmerman T, Tang C, Pease M, Cichonski JA, Shah N,\r\nDownard W (2019) Cybersecurity Framework Manufacturing Profile Low\r\nImpact Level Example Implementations Guide: Volume 1 – General\r\nImplementation Guidance. (National Institute of Standards and Technology,\r\nGaithersburg, MD), NIST Interagency or Internal Report (IR) 8183A, Vol. 1.\r\nhttps://doi.org/10.6028/NIST.IR.8183A-1\r\n Stouffer KA, Zimmerman T, Tang C, Pease M, Cichonski JA, Shah N,\r\nDownard W (2019) Cybersecurity Framework Manufacturing Profile Low\r\nImpact Level Example Implementations Guide: Volume 2 – Process-based\r\nManufacturing System Use Case. (National Institute of Standards and\r\nTechnology, Gaithersburg, MD), NIST Interagency or Internal Report (IR)\r\n8183A, Vol. 2. https://doi.org/10.6028/NIST.IR.8183A-2\r\n Stouffer KA, Zimmerman T, Tang C, Pease M, Cichonski JA, Shah N,\r\nDownard W (2019) Cybersecurity Framework Manufacturing Profile Low\r\nImpact Level Example Implementations Guide: Volume 3 – Discrete-based\r\nManufacturing System Use Case. (National Institute of Standards and\r\nTechnology, Gaithersburg, MD), NIST Interagency or Internal Report (IR)\r\n8183A, Vol. 3. https://doi.org/10.6028/NIST.IR.8183A-3\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n142\r\n[ISA62443] International Society of Automation (2020) Security for industrial automation\r\nand control systems (all parts), ISA-62443. Available at\r\nhttps://www.isa.org/standards-and-publications/isa-standards/isa-standards-committees/isa99\r\n[ISADICT] International Society of Automation [2002] The Automation, Systems, and\r\nInstrumentation Dictionary, 4th Edition. International Society of Automation.\r\n[ISO7498-1] ISO/IEC 7498-1:1994, Available at https://www.iso.org/standard/20269.html\r\n[Knapp] Knapp E (2011) Industrial Network Security: Securing Critical Infrastructure\r\nNetworks for Smart Grid, SCADA, and Other Industrial Control Systems,\r\n(Syngress, Waltham, Massachusetts).\r\n[OMB-A130] Office of Management and Budget (2016) Managing Information as a\r\nStrategic Resource. (The White House, Washington, DC), OMB Circular A-130, July 28, 2016. Available at\r\nhttps://www.federalregister.gov/documents/2016/07/28/2016-17872/revision-of-omb-circular-no-a-130-managing-information-as-a-strategic-resource\r\n[OMB-M1917] Office of Management and Budget (2019) Enabling Mission Delivery through\r\nImproved Identity, Credential, and Access Management. (The White House,\r\nWashington, DC), OMB Memorandum M-19-17, May 21, 2019. Available at\r\nhttps://www.whitehouse.gov/wp-content/uploads/2019/05/M-19-17.pdf\r\n[Peerenboom] Peerenboom J (2001) “Infrastructure Interdependencies: Overview of\r\nConcepts and Terminology.” (NSF/OSTP Workshop on Critical\r\nInfrastructure: Needs in Interdisciplinary Research and Graduate Training,\r\nWashington, DC).\r\n[PF] National Institute of Standards and Technology (2020) NIST Privacy\r\nFramework: A Tool for Improving Privacy Through Enterprise Risk\r\nManagement, Version 1.0. (National Institute of Standards and Technology,\r\nGaithersburg, MD). https://doi.org/10.6028/NIST.CSWP.10\r\n[PPD-21] Presidential Policy Directive 21 (2013) Critical Infrastructure Security and\r\nResilience. (The White House, Washington, DC), February 12, 2013.\r\nAvailable at https://obamawhitehouse.archives.gov/the-press-office/2013/02/12/presidential-policy-directive-critical-infrastructure-security-and-resil\r\n[PPD-41] Presidential Policy Directive 41 (2016) United States Cyber Incident\r\nCoordination. (The White House, Washington, DC), July 26, 2016. Available\r\nat https://obamawhitehouse.archives.gov/the-press-office/2016/07/26/presidential-policy-directive-united-states-cyber-incident\r\n[RFC4949] Shirey R (2007) Internet Security Glossary, Version 2. (Internet Engineering\r\nTask Force (IETF)), IETF Request for Comments (RFC) 4949.\r\nhttps://doi.org/10.17487/RFC4949\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n143\r\n[Rinaldi] Rinaldi SM, Peerenboom JP, Kelly TK (2001) “Identifying, Understanding,\r\nand Analyzing Critical Infrastructure Interdependencies,” IEEE Control\r\nSystems Magazine, Vol. 21, No. 6, pp. 11-25, December 2001).\r\nhttps://doi.org/10.1109/37.969131\r\n[SP1058] Falco JA, Hurd S, Teumim D (2006) Using Host-Based Anti-Virus Software\r\non Industrial Control Systems: Integration Guidance and a Test Methodology\r\nfor Assessing Performance Impacts. (National Institute of Standards and\r\nTechnology, Gaithersburg, MD), NIST Special Publication (SP) 1058.\r\nhttps://doi.org/10.6028/NIST.SP.1058\r\n[SP800-100] Bowen P, Hash J, Wilson M (2006) Information Security Handbook: A Guide\r\nfor Managers. (National Institute of Standards and Technology, Gaithersburg,\r\nMD), NIST Special Publication (SP) 800-100, Includes updates as of March 7,\r\n2007. https://doi.org/10.6028/NIST.SP.800-100\r\n[SP800-150] Johnson CS, Waltermire DA, Badger ML, Skorupka C, Snyder J (2016) Guide\r\nto Cyber Threat Information Sharing. (National Institute of Standards and\r\nTechnology, Gaithersburg, MD), NIST Special Publication (SP) 800-150.\r\nhttps://doi.org/10.6028/NIST.SP.800-150\r\n[SP800-161] Boyens JM, Smith AM, Bartol N, Winkler K, Holbrook A, Fallon M (2022)\r\nCybersecurity Supply Chain Risk Management Practices for Systems and\r\nOrganizations. (National Institute of Standards and Technology, Gaithersburg,\r\nMD), NIST Special Publication (SP) 800-161r1.\r\nhttps://doi.org/10.6028/NIST.SP.800-161r1\r\n[SP800-167] Sedgewick A, Souppaya MP, Scarfone KA (2015) Guide to Application\r\nWhitelisting. (National Institute of Standards and Technology, Gaithersburg,\r\nMD), NIST Special Publication (SP) 800-167.\r\nhttps://doi.org/10.6028/NIST.SP.800-167\r\n[SP800-18r1] Swanson MA, Hash J, Bowen P (2006) Guide for Developing Security Plans\r\nfor Federal Information Systems. (National Institute of Standards and\r\nTechnology, Gaithersburg, MD), NIST Special Publication (SP) 800-18, Rev.\r\n1. https://doi.org/10.6028/NIST.SP.800-18r1\r\n[SP800-207] Rose SW, Borchert O, Mitchell S, Connelly S (2020) Zero Trust Architecture.\r\n(National Institute of Standards and Technology, Gaithersburg, MD), NIST\r\nSpecial Publication (SP) 800-207. https://doi.org/10.6028/NIST.SP.800-207\r\n[SP800-28v2] Jansen W, Winograd T, Scarfone KA (2008) Guidelines on Active Content\r\nand Mobile Code. (National Institute of Standards and Technology,\r\nGaithersburg, MD), NIST Special Publication (SP) 800-28, Version 2.\r\nhttps://doi.org/10.6028/NIST.SP.800-28ver2\r\n[SP800-30r1] Joint Task Force Transformation Initiative (2012) Guide for Conducting Risk\r\nAssessments. (National Institute of Standards and Technology, Gaithersburg,\r\nMD), NIST Special Publication (SP) 800-30, Rev. 1.\r\nhttps://doi.org/10.6028/NIST.SP.800-30r1\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n144\r\n[SP800-34r1] Swanson MA, Bowen P, Phillips AW, Gallup D, Lynes D (2010) Contingency\r\nPlanning Guide for Federal Information Systems. (National Institute of\r\nStandards and Technology, Gaithersburg, MD), NIST Special Publication\r\n(SP) 800-34, Rev. 1, Includes updates as of November 11, 2010.\r\nhttps://doi.org/10.6028/NIST.SP.800-34r1\r\n[SP800-37r2] Joint Task Force (2018) Risk Management Framework for Information\r\nSystems and Organizations: A System Life Cycle Approach for Security and\r\nPrivacy. (National Institute of Standards and Technology, Gaithersburg, MD),\r\nNIST Special Publication (SP) 800-37, Rev. 2.\r\nhttps://doi.org/10.6028/NIST.SP.800-37r2\r\n[SP800-39] Joint Task Force Transformation Initiative (2011) Managing Information\r\nSecurity Risk: Organization, Mission, and Information System View.\r\n(National Institute of Standards and Technology, Gaithersburg, MD), NIST\r\nSpecial Publication (SP) 800-39. https://doi.org/10.6028/NIST.SP.800-39\r\n[SP800-40r4] Souppaya MP, Scarfone KA (2022) Guide to Enterprise Patch Management\r\nPlanning: Preventive Maintenance for Technology. (National Institute of\r\nStandards and Technology, Gaithersburg, MD), NIST Special Publication\r\n(SP) 800-40, Rev. 4. https://doi.org/10.6028/NIST.SP.800-40r4\r\n[SP800-41r1] Scarfone KA, Hoffman P (2009) Guidelines on Firewalls and Firewall Policy.\r\n(National Institute of Standards and Technology, Gaithersburg, MD), NIST\r\nSpecial Publication (SP) 800-41, Rev. 1.\r\nhttps://doi.org/10.6028/NIST.SP.800-41r1\r\n[SP800-47] Grance T, Hash J, Peck S, Smith J, Korow-Diks K (2002) Security Guide for\r\nInterconnecting Information Technology Systems. (National Institute of\r\nStandards and Technology, Gaithersburg, MD), NIST Special Publication\r\n(SP) 800-47. https://doi.org/10.6028/NIST.SP.800-47\r\n[SP800-53Ar5] Joint Task Force (2022) Assessing Security and Privacy Controls in\r\nInformation Systems and Organizations. (National Institute of Standards and\r\nTechnology, Gaithersburg, MD), NIST Special Publication (SP) 800-53A,\r\nRev. 5. https://doi.org/10.6028/NIST.SP.800-53Ar5\r\n[SP800-53B] Joint Task Force (2020) Control Baselines for Information Systems and\r\nOrganizations. (National Institute of Standards and Technology, Gaithersburg,\r\nMD), NIST Special Publication (SP) 800-53B, Includes updates as of\r\nDecember 10, 2020. https://doi.org/10.6028/NIST.SP.800-53B\r\n[SP800-53r5] Joint Task Force (2020) Security and Privacy Controls for Information\r\nSystems and Organizations. (National Institute of Standards and Technology,\r\nGaithersburg, MD), NIST Special Publication (SP) 800-53, Rev. 5. Includes\r\nupdates as of December 10, 2020. https://doi.org/10.6028/NIST.SP.800-53r5\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n145\r\n[SP800-60v1r1] Stine KM, Kissel RL, Barker WC, Fahlsing J, Gulick J (2008) Guide for\r\nMapping Types of Information and Information Systems to Security\r\nCategories. (National Institute of Standards and Technology, Gaithersburg,\r\nMD), NIST Special Publication (SP) 800-60, Vol. 1, Rev. 1.\r\nhttps://doi.org/10.6028/NIST.SP.800-60v1r1\r\n[SP800-60v2r1] Stine KM, Kissel RL, Barker WC, Lee A, Fahlsing J (2008) Guide for\r\nMapping Types of Information and Information Systems to Security\r\nCategories: Appendices. (National Institute of Standards and Technology,\r\nGaithersburg, MD), NIST Special Publication (SP) 800-60, Vol. 2, Rev. 1.\r\nhttps://doi.org/10.6028/NIST.SP.800-60v2r1\r\n[SP800-61] Grance T, Kent K, Kim B (2004) Computer Security Incident Handling\r\nGuide. (National Institute of Standards and Technology, Gaithersburg, MD),\r\nNIST Special Publication (SP) 800-61. https://doi.org/10.6028/NIST.SP.800-\r\n61\r\n[SP800-61r2] Cichonski PR, Millar T, Grance T, Scarfone KA (2012) Computer Security\r\nIncident Handling Guide. (National Institute of Standards and Technology,\r\nGaithersburg, MD), NIST Special Publication (SP) 800-61, Rev. 2.\r\nhttps://doi.org/10.6028/NIST.SP.800-61r2\r\n[SP800-67r2] Barker EB, Mouha N (2017) Recommendation for the Triple Data Encryption\r\nAlgorithm (TDEA) Block Cipher. (National Institute of Standards and\r\nTechnology, Gaithersburg, MD), NIST Special Publication (SP) 800-67, Rev.\r\n2. https://doi.org/10.6028/NIST.SP.800-67r2\r\n[SP800-73-4] Cooper DA, Ferraiolo H, Mehta KL, Francomacaro S, Chandramouli R,\r\nMohler J (2015) Interfaces for Personal Identity Verification. (National\r\nInstitute of Standards and Technology, Gaithersburg, MD), NIST Special\r\nPublication (SP) 800-73-4, Includes updates as of February 8, 2016.\r\nhttps://doi.org/10.6028/NIST.SP.800-73-4\r\n[SP800-76-2] Grother PJ, Salamon WJ, Chandramouli R (2013) Biometric Specifications\r\nfor Personal Identity Verification. (National Institute of Standards and\r\nTechnology, Gaithersburg, MD), NIST Special Publication (SP) 800-76-2.\r\nhttps://doi.org/10.6028/NIST.SP.800-76-2\r\n[SP800-78-4] Polk WT, Dodson DF, Burr WE, Ferraiolo H, Cooper DA (2015)\r\nCryptographic Algorithms and Key Sizes for Personal Identity Verification.\r\n(National Institute of Standards and Technology, Gaithersburg, MD), NIST\r\nSpecial Publication (SP) 800-78-4. https://doi.org/10.6028/NIST.SP.800-78-4\r\n[USC44-3552] “Definitions,” Title 44 U.S. Code, Sec. 3552. 2018 ed. Available at\r\nhttps://www.govinfo.gov/app/details/USCODE-2020-title44/USCODE-2020-\r\ntitle44-chap35-subchapII-sec3552\r\n[Williams] Williams TJ (1989) A Reference Model For Computer Integrated\r\nManufacturing (CIM). (Instrument Society of America, Research Triangle\r\nPark, NC). Available at\r\nhttp://www.pera.net/Pera/PurdueReferenceModel/ReferenceModel.html\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n146\r\nAppendix A. List of Symbols, Abbreviations, and Acronyms\r\nSelected acronyms and abbreviations used in this paper are defined below.\r\nA3\r\nAssociation for Advancing Automation\r\nABAC\r\nAttribute-Based Access Control\r\nACC\r\nAmerican Chemistry Council\r\nACI\r\nAviation Cyber Initiative\r\nACL\r\nAccess Control List\r\nAES\r\nAdvanced Encryption Standard\r\nAFPM\r\nAmerican Fuel and Petrochemical Manufacturers\r\nAGA\r\nAmerican Gas Association\r\nAHA\r\nAmerican Hospital Association\r\nAI\r\nArtificial Intelligence\r\nAMA\r\nAmerican Medical Association\r\nAMWA\r\nAssociation of Metropolitan Water Agencies\r\nAO\r\nAuthorizing Official\r\nAPCP\r\nAmerican Hospital Association Preferred Cybersecurity Provider\r\nAPI\r\nAmerican Petroleum Institute, Application Programming Interface\r\nAPPA\r\nAmerican Public Power Association\r\nASDSO\r\nAssociation of State Dam Safety Officials\r\nATO\r\nAir Traffic Organization\r\nAWWA\r\nAmerican Water Works Association\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n147\r\nBAD\r\nBehavioral Anomaly Detection\r\nBAS\r\nBuilding Automation System\r\nBCP\r\nBusiness Continuity Plan\r\nBES\r\nBulk Electric System\r\nBPCS\r\nBasic Process Control System\r\nC-SCRM\r\nCybersecurity Supply Chain Risk Management\r\nCCE\r\nConsequence-Driven Cyber-Informed Engineering\r\nCD\r\nCompact Disc\r\nCDC\r\nCybersecurity Defense Community\r\nCEDS\r\nCybersecurity for Energy Delivery Systems\r\nCEO\r\nChief Executive Officer\r\nCERT\r\nComputer Emergency Response Team\r\nCESER\r\nCybersecurity, Energy Security, and Emergency Response\r\nCFATS\r\nChemical Facility Anti-Terrorism Standards\r\nCI\r\nCritical Infrastructure\r\nCIE\r\nCyber-Informed Engineering\r\nCIGRE\r\nInternational Council on Large Electric Systems\r\nCIM\r\nComputer Integrated Manufacturing\r\nCIO\r\nChief Information Officer\r\nCIP\r\nCommon Industrial Protocol, Critical Infrastructure Protection\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n148\r\nCIPAC\r\nCritical Infrastructure Partnership Advisory Council\r\nCISA\r\nCybersecurity and Infrastructure Security Agency\r\nCISO\r\nChief Information Security Officer\r\nCMVP\r\nCryptographic Module Validation Program\r\nCNSS\r\nCommittee on National Security Systems\r\nCNSSI\r\nCommittee on National Security Systems Instruction\r\nCOO\r\nChief Operating Officer\r\nCOTS\r\nCommercial Off-the-Shelf\r\nCPNI\r\nCentre for the Protection of National Infrastructure\r\nCPS\r\nCyber-Physical System\r\nCPU\r\nCentral Processing Unit\r\nCRISP\r\nCybersecurity Risk Information Sharing Program\r\nCS3STHLM\r\nStockholm International Summit on Cyber Security in SCADA and ICS\r\nCSET\r\nCyber Security Evaluation Tool\r\nCSF\r\nCybersecurity Framework\r\nCSO\r\nChief Security Officer\r\nCSRC\r\nComputer Security Resource Center\r\nCSRIC\r\nCommunications Security, Reliability, and Interoperability Council\r\nCVE\r\nCommon Vulnerabilities and Exposures\r\nCyOTE\r\nCybersecurity for the Operational Technology Environment\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n149\r\nCyTRICS\r\nCyber Testing for Resilient Industrial Control Systems\r\nDCS\r\nDistributed Control System\r\nDES\r\nData Encryption Standard\r\nDHCP\r\nDynamic Host Configuration Protocol\r\nDHS\r\nDepartment of Homeland Security\r\nDICWG\r\nDigital Instrumentation and Control Working Group\r\nDLP\r\nData Loss Prevention\r\nDMZ\r\nDemilitarized Zone\r\nDNP3\r\nDNP3 Distributed Network Protocol (published as IEEE 1815)\r\nDNS\r\nDomain Name System\r\nDOE\r\nDepartment of Energy\r\nDoS\r\nDenial of Service\r\nDOT\r\nUnited States Department of Transportation\r\nDRP\r\nDisaster Recovery Plan\r\nDSS\r\nDigital Signature Standard\r\nDVD\r\nDigital Video Disc\r\nE-ISAC\r\nElectricity Information Sharing and Analysis Center\r\nEM\r\nElectromagnetic\r\nEMBS\r\nIEEE Engineering in Medicine and Biology Society\r\nEMP\r\nElectromagnetic Pulse\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n150\r\nEMS\r\nEnergy Management System\r\nEPA\r\nUnited States Environmental Protection Agency\r\nEPRI\r\nElectric Power Research Institute\r\nERM\r\nEnterprise Risk Management\r\nESD\r\nEmergency Shutdown\r\nFAA\r\nFederal Aviation Administration\r\nFCC\r\nFederal Communications Commission\r\nFDA\r\nUnited States Food and Drug Administration\r\nFEMA\r\nFederal Emergency Management Agency\r\nFGS\r\nFire and Gas System\r\nFHWA\r\nFederal Highway Administration\r\nFIPS\r\nFederal Information Processing Standards\r\nFISMA\r\nFederal Information Security Modernization Act\r\nFMCSA\r\nFederal Motor Carrier Safety Administration\r\nFMEA\r\nFailure Mode and Effects Analysis\r\nFRA\r\nFederal Railroad Administration\r\nFTA\r\nFederal Transit Administration\r\nFTP\r\nFile Transfer Protocol\r\nGCC\r\nGovernment Coordinating Council\r\nGCIP\r\nGIAC Critical Infrastructure Protection\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n151\r\nGIAC\r\nGlobal Information Assurance Certification\r\nGICSP\r\nGlobal Industrial Cyber Security Professional\r\nGPS\r\nGlobal Positioning System\r\nGRID\r\nGIAC Response and Industrial Defense\r\nHART\r\nHighway Addressable Remote Transducer Protocol\r\nHC3\r\nHealth Sector Cybersecurity Coordination Center\r\nHHS\r\nHealth and Human Services\r\nHMI\r\nHuman-Machine Interface\r\nHR\r\nHuman Resources\r\nHSIN\r\nHomeland Security Information Network\r\nHSIN-CI\r\nHomeland Security Information Network - Critical Infrastructure\r\nHTTP\r\nHypertext Transfer Protocol\r\nHTTPS\r\nHypertext Transfer Protocol Secure\r\nHVAC\r\nHeating, Ventilation, and Air Conditioning\r\nI/O\r\nInput/Output\r\nI3P\r\nInstitute for Information Infrastructure Protection\r\nIAARC\r\nInternational Association for Automation and Robotics in Construction\r\nIACS\r\nIndustrial Automation and Control System\r\nIAEA\r\nInternational Atomic Energy Agency\r\nICCP\r\nInter-Control Center Communications Protocol\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n152\r\nICS\r\nIndustrial Control System\r\nICSJWG\r\nIndustrial Control Systems Joint Working Group\r\nICSS\r\nIntegrated Control and Safety Systems\r\nID\r\nIdentification\r\nIDS\r\nIntrusion Detection System\r\nIEC\r\nInternational Electrotechnical Commission\r\nIED\r\nIntelligent Electronic Device\r\nIEEE\r\nInstitute of Electrical and Electronics Engineers\r\nIES\r\nIEEE Industrial Electronics Society\r\nIETF\r\nInternet Engineering Task Force\r\nIFIP\r\nInternational Federation for Information Processing\r\nIIC\r\nIndustry IoT Consortium, Industrial Internet of Things Consortium\r\nIIoT\r\nIndustrial Internet of Things\r\nINL\r\nIdaho National Laboratory\r\nIoT\r\nInternet of Things\r\nIP\r\nInternet Protocol\r\nIPS\r\nIntrusion Prevention System\r\nIPsec\r\nInternet Protocol Security\r\nIR\r\nIncident Response\r\nISA\r\nInternational Society of Automation\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n153\r\nISAC\r\nInternational Sharing and Analysis Center\r\nISCM\r\nInformation Security Continuous Monitoring\r\nISO\r\nInternational Organization for Standardization\r\nIT\r\nInformation Technology\r\nITL\r\nInformation Technology Laboratory\r\nLAN\r\nLocal Area Network\r\nLDAP\r\nLightweight Directory Access Protocol\r\nLOGIIC\r\nLinking the Oil and Gas Industry to Improve Cybersecurity\r\nMAC\r\nMedia Access Control\r\nMARAD\r\nMaritime Administration\r\nMBR\r\nMaster Boot Record\r\nMCAA\r\nMeasurement, Control, \u0026 Automation Association\r\nMFA\r\nMulti-Factor Authentication\r\nMIB\r\nManagement Information Base\r\nML\r\nMachine Learning\r\nMTU\r\nMaster Terminal Unit\r\nNAM\r\nNational Association of Manufacturers\r\nNAWC\r\nNational Association of Water Companies\r\nNCC\r\nNational Coordinating Center for Communications\r\nNEA\r\nNuclear Energy Agency\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n154\r\nNEI\r\nNuclear Energy Institute\r\nNERC\r\nNorth American Electric Reliability Corporation\r\nNESCOR\r\nNational Electric Sector Cybersecurity Resource\r\nNFS\r\nNetwork File System\r\nNFU\r\nNational Farmers Union\r\nNGFW\r\nNext Generation Firewall\r\nNHTSA\r\nNational Highway Traffic Safety Administration\r\nNICE\r\nNational Initiative for Cybersecurity Education\r\nNIH\r\nNational Institutes of Health\r\nNIMS\r\nNational Incident Management System\r\nNIST\r\nNational Institute of Standards and Technology\r\nNIST IR\r\nNational Institute of Standards and Technology Internal or Interagency Report\r\nNITAAC\r\nNational Institutes of Health Information Technology Acquisition and Assessment Center\r\nNRC\r\nUnited States Nuclear Regulatory Commission\r\nNREL\r\nNational Renewable Energy Laboratory\r\nNTP\r\nNetwork Time Protocol\r\nNTSB\r\nNational Transportation Safety Board\r\nNVD\r\nNational Vulnerability Database\r\nOEM\r\nOriginal Equipment Manufacturer\r\nOMB\r\nOffice of Management and Budget\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n155\r\nOPC\r\nOpen Platform Communications\r\nOS\r\nOperating System\r\nOSI\r\nOpen Systems Interconnection\r\nOT\r\nOperational Technology\r\nPACS\r\nPhysical Access Control System, Picture Archiving and Communications Systems\r\nPC\r\nPersonal Computer\r\nPERA\r\nPurdue Enterprise Reference Architecture\r\nPES\r\nIEEE Power \u0026 Energy Society\r\nPHA\r\nProcess Hazard Analysis\r\nPHM4SM\r\nPrognostics and Health Management for Reliable Operations in Smart Manufacturing\r\nPHMSA\r\nPipeline and Hazardous Materials Safety Administration\r\nPID\r\nProportional-Integral-Derivative\r\nPIN\r\nPersonal Identification Number\r\nPIV\r\nPersonal Identity Verification\r\nPLC\r\nProgrammable Logic Controller\r\nPNNL\r\nPacific Northwest National Laboratory\r\nPNT\r\nPositioning, Navigation, and Timing\r\nPPD\r\nPresidential Policy Directive\r\nPRAM\r\nPrivacy Risk Assessment Methodology\r\nPSCCC\r\nIEEE Power System Communications and Cybersecurity\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n156\r\nPSS\r\nProcess Safety Shutdown\r\nPT\r\nPressure Transmitter\r\nPTP\r\nPrecision Time Protocol\r\nR\u0026D\r\nResearch and Development\r\nRAS\r\nIEEE Robotics and Automation Society\r\nRBAC\r\nRole-Based Access Control\r\nRDP\r\nRemote Desktop Protocol\r\nRF\r\nRadio Frequency\r\nRFC\r\nRequest for Comments\r\nRFID\r\nRadio Frequency Identification\r\nRMF\r\nRisk Management Framework\r\nRPC\r\nRemote Procedure Call\r\nRPO\r\nRecovery Point Objective\r\nRTO\r\nRecovery Time Objective\r\nRTOS\r\nReal-Time Operating System\r\nRTU\r\nRemote Terminal Unit\r\nS4\r\nSCADA Security Scientific Symposium\r\nSBOM\r\nSoftware Bill of Materials\r\nSBU\r\nSensitive But Unclassified\r\nSC\r\nSecurity Category\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n157\r\nSCADA\r\nSupervisory Control and Data Acquisition\r\nSCAI\r\nSafety, Controls, Alarms, and Interlocks\r\nSCC\r\nSector Coordinating Council\r\nSD\r\nSecure Digital\r\nSDLC\r\nSoftware Development Life Cycle, System Development Life Cycle\r\nSDN\r\nSoftware-Defined Networking\r\nSEPA\r\nSmart Electric Power Alliance\r\nSGCC\r\nSmart Grid Cybersecurity Committee\r\nSHA\r\nSecure Hash Algorithm\r\nSIEM\r\nSecurity Information and Event Management\r\nSIF\r\nSafety Instrumented Function\r\nSIS\r\nSafety Instrumented System\r\nSOC\r\nSecurity Operations Center\r\nSOCMA\r\nSociety of Chemical Manufacturers and Affiliates\r\nSP\r\nSpecial Publication\r\nSPAN\r\nSwitched Port Analyzer\r\nSQL\r\nStructured Query Language\r\nSSA\r\nSector-Specific Agency\r\nSSCP\r\nSecure SCADA Communications Protocol\r\nSSH\r\nSecure Shell\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n158\r\nSSID\r\nService Set Identifier\r\nSSL\r\nSecure Sockets Layer\r\nSSPP\r\nSubstation Serial Protection Protocol\r\nTC\r\nTechnical Committee\r\nTCP\r\nTransmission Control Protocol\r\nTCP/IP\r\nTransmission Control Protocol/Internet Protocol\r\nTFTP\r\nTrivial File Transfer Protocol\r\nTIP\r\nTechnical Information Paper\r\nTLS\r\nTransport Layer Security\r\nTLV\r\nType, Length, Value\r\nTPM\r\nTrusted Platform Module\r\nTSA\r\nTransportation Security Administration\r\nTT\r\nTemperature Transmitter\r\nUDP\r\nUser Datagram Protocol\r\nUPS\r\nUninterruptible Power Supply\r\nU.S.\r\nUnited States\r\nUSB\r\nUniversal Serial Bus\r\nUSDA\r\nUnited States Department of Agriculture\r\nVAV\r\nVariable Air Volume\r\nVDP\r\nVulnerability Disclosure Policy\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n159\r\nVLAN\r\nVirtual Local Area Network\r\nVoIP\r\nVoice over Internet Protocol\r\nVPN\r\nVirtual Private Network\r\nVTS\r\nIEEE Vehicular Technology Society\r\nWAF\r\nWeb Application Firewall\r\nWAN\r\nWide Area Network\r\nWG\r\nWorking Group\r\nWi-Fi\r\nWireless Fidelity\r\nWINS\r\nWorld Institute of Nuclear Security\r\nZTA\r\nZero Trust Architecture\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n160\r\nAppendix B. Glossary\r\nSelected terms used in this publication are defined below. Source references are included for\r\ncertain definitions.\r\naccess control list\r\nA mechanism that implements access control for a system resource by enumerating the identities of the system\r\nentities that are permitted to access the resources. [RFC4949] (adapted)\r\nactuator\r\nA device for moving or controlling a mechanism or system. It is operated by a source of energy, typically electric\r\ncurrent, hydraulic fluid pressure, or pneumatic pressure, and converts that energy into motion. An actuator is the\r\nmechanism by which a control system acts upon an environment. The control system can be simple (a fixed\r\nmechanical or electronic system), software-based (e.g., a printer driver, robot control system), or a human or other\r\nagent.\r\nalarm\r\nA device or function that signals the existence of an abnormal condition by making an audible or visible discrete\r\nchange, or both, so as to attract attention to that condition. [ANSI-ISA-5-1]\r\nantivirus tools\r\nSoftware products and technology used to detect malicious code, prevent it from infecting a system, and remove\r\nmalicious code that has infected the system.\r\nattack\r\nAn attempt to gain unauthorized access to system services, resources, or information or an attempt to compromise\r\nsystem integrity, availability, or confidentiality.\r\nauthentication\r\nVerifying the identity of a user, process, or device, often as a prerequisite to allowing access to resources in an\r\ninformation system. [FIPS200]\r\nauthorization\r\nThe right or a permission that is granted to a system entity to access a system resource. [RFC4949] (adapted)\r\nbackdoor\r\nAn undocumented way of gaining access to a computer system. A backdoor is a potential security risk.\r\nbuffer overflow\r\nA condition at an interface under which more input can be placed into a buffer or data holding area than the capacity\r\nallocated, overwriting other information. Adversaries exploit such a condition to crash a system or to insert specially\r\ncrafted code that allows them to gain control of the system. [SP800-28v2]\r\ncleartext\r\nInformation that is not encrypted.\r\ncommunications router\r\nA communications device that transfers messages between two networks. Common uses for routers include\r\nconnecting a LAN to a WAN and connecting MTUs and RTUs to a long-distance network medium for SCADA\r\ncommunication.\r\nconfidentiality\r\nPreserving authorized restrictions on information access and disclosure, including means for protecting personal\r\nprivacy and proprietary information. [USC44-3552] (adapted)\r\nconfiguration (of a system or device)\r\nStep in system design; for example, selecting functional units, assigning their locations, and defining their\r\ninterconnections.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n161\r\nconfiguration control\r\nProcess for controlling modifications to hardware, firmware, software, and documentation to ensure the information\r\nsystem is protected against improper modifications before, during, and after system implementation. [CNSS4009]\r\n(adapted)\r\ncontrol\r\nThe part of the OT system used to monitor and control the physical process. This includes all control servers, field\r\ndevices, actuators, sensors, and their supporting communication systems.\r\ncontrol algorithm\r\nA mathematical representation of the control action to be performed. [ISADICT]\r\ncontrol center\r\nAn equipment structure or group of structures from which a process is measured, controlled, and/or monitored.\r\n[ANSI-ISA-51-1]\r\ncontrol loop\r\nA control loop consists of sensors for measurement, controller hardware (e.g., PLCs), actuators (e.g., control valves,\r\nbreakers, switches, and motors), and the communication of variables. Controlled variables are transmitted to the\r\ncontroller from the sensors. The controller interprets the signals and generates corresponding manipulated variables\r\nbased on set points, which it transmits to the actuators. Process changes from disturbances result in new sensor\r\nsignals, identifying the state of the process, to again be transmitted to the controller.\r\ncontrol network\r\nThose networks of an enterprise typically connected to equipment that controls physical processes and that is time or\r\nsafety critical. The control network can be subdivided into zones, and there can be multiple separate control\r\nnetworks within one enterprise and site.\r\ncontrol server\r\nA controller that also acts as a server that hosts the control software that communicates with lower-level control\r\ndevices, such as remote terminal units (RTUs) and programmable logic controllers (PLCs), over an OT network. In\r\na SCADA system, this is often called a SCADA server, MTU, or supervisory controller.\r\ncontrol system\r\nA system in which deliberate guidance or manipulation is used to achieve a prescribed value for a variable. Control\r\nsystems include SCADA, DCS, PLCs, BAS, and other types of OT measurement and control systems.\r\ncontrolled variable\r\nThe variable that the control system attempts to keep at the set point value. The set point may be constant or\r\nvariable. [ISADICT]\r\ncontroller\r\nA device or program that operates automatically to regulate a controlled variable. [ANSI-ISA-51-1]\r\ncycle time\r\nThe time, usually expressed in seconds, for a controller to complete one control loop where sensor signals are read\r\ninto memory, control algorithms are executed, and corresponding control signals are transmitted to actuators that\r\ncreate changes to the process resulting in new sensor signals. [ISADICT]\r\ndata diode\r\nA network appliance or device that allows data to travel only in one direction. Also referred to as a unidirectional\r\ngateway, deterministic one-way boundary device, or unidirectional network.\r\ndata historian\r\nA centralized database that supports data analysis using statistical process control techniques.\r\ndatabase\r\nA repository of information that usually holds plant-wide information including process data, recipes, personnel\r\ndata, and financial data. [IR6859] (adapted)\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n162\r\ndemilitarized zone\r\nAn interface on a routing firewall that is similar to the interfaces found on the firewall’s protected side. Traffic\r\nmoving between the DMZ and other interfaces on the protected side of the firewall still goes through the firewall\r\nand can have firewall protection policies applied. [SP800-41r1]\r\ndenial of service\r\nThe prevention of authorized access to a system resource or the delaying of system operations and functions.\r\n[RFC4949]\r\ndiagnostics\r\nInformation concerning known failure modes and their characteristics. Such information can be used in\r\ntroubleshooting and failure analysis to help pinpoint the cause of a failure and help define suitable corrective\r\nmeasures. [ISADICT]\r\ndisaster recovery plan\r\nA written plan for processing critical applications in the event of a major hardware or software failure or destruction\r\nof facilities. [SP800-34r1] (adapted)\r\ndiscrete process\r\nA type of process where a specified quantity of material moves as a unit (part or group of parts) between work\r\nstations and each unit maintains its unique identity. [ISADICT]\r\ndistributed control system\r\nIn a control system, refers to control achieved by intelligence that is distributed about the process to be controlled,\r\nrather than by a centrally located single unit. [ISADICT]\r\ndisturbance\r\nAn undesired change in a variable being applied to a system that tends to adversely affect the value of a controlled\r\nvariable. [ANSI-ISA-51-1]\r\ndomain\r\nAn environment or context that includes a set of system resources and a set of system entities that have the right to\r\naccess the resources as defined by a common security policy, security model, or security architecture. [RFC4949]\r\n(adapted)\r\nencryption\r\nCryptographic transformation of data (called “plaintext”) into a form (called “ciphertext”) that conceals the data’s\r\noriginal meaning to prevent it from being known or used. If the transformation is reversible, the corresponding\r\nreversal process is called “decryption,” which is a transformation that restores encrypted data to its original state.\r\n[RFC4949] (adapted)\r\nenterprise\r\nAn organization that coordinates the operation of one or more processing sites.\r\nfault tolerant\r\nA system having the built-in capability to provide continued, correct execution of its assigned function in the\r\npresence of a hardware and/or software fault.\r\nfield device\r\nEquipment that is connected to the field side on an ICS. Types of field devices include RTUs, PLCs, actuators,\r\nsensors, HMIs, and associated communications.\r\nfield site\r\nA subsystem that is identified by physical, geographical, or logical segmentation within the ICS. A field site may\r\ncontain RTUs, PLCs, actuators, sensors, HMIs, and associated communications.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n163\r\nfieldbus\r\nA digital, serial, multi-drop, two-way data bus or communication path or link between low-level industrial field\r\nequipment, such as sensors, transducers, actuators, local controllers, and even control room devices. Use of fieldbus\r\ntechnologies eliminates the need for point-to-point wiring between the controller and each device. A protocol is used\r\nto define messages over the fieldbus network, and each message identifies a particular sensor on the network.\r\nFile Transfer Protocol\r\nAn standard for transferring files over the internet. FTP programs and utilities are used to upload and download web\r\npages, graphics, and other files between local media and a remote server that allows FTP access.\r\nfirewall\r\nAn inter-network gateway that restricts data communication traffic to and from one of the connected networks (the\r\none said to be “inside” the firewall) and thus protects that network’s system resources against threats from the other\r\nnetwork (the one that is said to be “outside” the firewall). [RFC4949]\r\nhuman-machine interface\r\nThe hardware or software through which an operator interacts with a controller. An HMI can range from a physical\r\ncontrol panel with buttons and indicator lights to an industrial PC with a color graphics display running dedicated\r\nHMI software. [IR6859]\r\nidentification\r\nThe process of verifying the identity of a user, process, or device, usually as a prerequisite for granting access to\r\nresources in an IT system. [SP800-47]\r\nincident\r\nAn occurrence that actually or potentially jeopardizes the confidentiality, integrity, or availability of an information\r\nsystem or the information the system processes, stores, or transmits or that constitutes a violation or imminent threat\r\nof violation of security policies, security procedures, or acceptable use policies. [FIPS200]\r\nindustrial control system\r\nGeneral term that encompasses several types of control systems, including supervisory control and data acquisition\r\n(SCADA) systems, distributed control systems (DCS), and other control system configurations that are often found\r\nin the industrial sectors and critical infrastructures, such as programmable logic controllers (PLC). An ICS consists\r\nof combinations of control components (e.g., electrical, mechanical, hydraulic, pneumatic) that act together to\r\nachieve an industrial objective (e.g., manufacturing, transportation of matter or energy).\r\ninformation security program plan\r\nFormal document that provides an overview of the security requirements for an organization-wide information\r\nsecurity program and describes the program management controls and common controls in place or planned for\r\nmeeting those requirements. [OMB-A130]\r\ninput/output\r\nA general term for the equipment that is used to communicate with a computer as well as the data involved in the\r\ncommunications. [ISADICT]\r\ninsider\r\nAn entity inside the security perimeter that is authorized to access system resources but uses them in a way that is\r\nnot approved by those who granted the authorization.\r\nintegrity\r\nGuarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity. [USC44-3552] (adapted)\r\nintelligent electronic device\r\nAny device incorporating one or more processors with the capability to receive or send data/control from or to an\r\nexternal source (e.g., electronic multifunction meters, digital relays, controllers). [AGA12]\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n164\r\ninternet\r\nThe single interconnected worldwide system of commercial, government, educational, and other computer networks\r\nthat share the set of protocols specified by the Internet Architecture Board (IAB) and the name and address spaces\r\nmanaged by the Internet Corporation for Assigned Names and Numbers (ICANN). [RFC4949] (adapted)\r\nintrusion detection system\r\nA security service that monitors and analyzes network or system events for the purpose of finding, and providing\r\nreal-time or near real-time warning of, attempts to access system resources in an unauthorized manner. [RFC4949]\r\n(adapted)\r\nintrusion prevention system\r\nA system that can detect an intrusive activity and also attempt to stop the activity, ideally before it reaches its\r\ntargets.\r\njitter\r\nThe time or phase difference between the data signal and the ideal clock.\r\nkey logger\r\nA program designed to record which keys are pressed on a computer keyboard in order to obtain passwords or\r\nencryption keys and thus bypass other security measures.\r\nlocal area network\r\nA group of computers and other devices dispersed over a relatively limited area and connected by a communications\r\nlink that enables any device to interact with any other on the network.\r\nmachine controller\r\nA control system/motion network that electronically synchronizes drives within a machine system instead of relying\r\non synchronization via mechanical linkage. [IR6859]\r\nmaintenance\r\nAny act that either prevents the failure or malfunction of equipment or restores its operating capability. [ISADICT]\r\nmalware\r\nSoftware or firmware intended to perform an unauthorized process that will have adverse impact on the\r\nconfidentiality, integrity, or availability of an information system. A virus, worm, Trojan horse, or other code-based\r\nentity that infects a host. [SP800-53r5] (adapted)\r\nmanipulated variable\r\nIn a process that is intended to regulate some condition, a quantity or a condition that the control alters to initiate a\r\nchange in the value of the regulated condition. [ISADICT]\r\nmaster terminal unit\r\nSee Control Server.\r\nmodem\r\nA device used to convert serial digital data from a transmitting terminal to a signal suitable for transmission over a\r\ntelephone channel to reconvert the transmitted signal to serial digital data for the receiving terminal. [IR6859]\r\noperating system\r\nAn integrated collection of service routines for supervising the sequencing of programs by a computer. An operating\r\nsystem may perform the functions of input/output control, resource scheduling, and data management. It provides\r\napplication programs with the fundamental commands for controlling the computer. [ISADICT]\r\noperational controls\r\nThe security controls (i.e., safeguards or countermeasures) for an information system that are primarily implemented\r\nand executed by people (as opposed to systems). [FIPS200]\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n165\r\noperational technology\r\nA broad range of programmable systems and devices that interact with the physical environment or manage devices\r\nthat interact with the physical environment. These systems and devices detect or cause a direct change through the\r\nmonitoring and/or control of devices, processes, and events. Examples include industrial control systems, building\r\nautomation systems, transportation systems, physical access control systems, physical environment monitoring\r\nsystems, and physical environment measurement systems.\r\npassword\r\nA string of characters (letters, numbers, and other symbols) used to authenticate an identity or to verify access\r\nauthorization. [FIPS140-2]\r\nphishing\r\nTricking individuals into disclosing sensitive personal information by claiming to be a trustworthy entity in an\r\nelectronic communication (e.g., internet web sites).\r\nplant\r\nThe physical elements necessary to support the physical process. This can include many of the static components not\r\ncontrolled by the ICS. However, the operation of the ICS may impact the adequacy, strength, and durability of the\r\nplant’s components.\r\nport\r\nThe entry or exit point from a computer for connecting communications or peripheral devices.\r\nport scanning\r\nUsing a program to remotely determine which ports on a system are open (e.g., whether systems allow connections\r\nthrough those ports).\r\npredisposing condition\r\nA condition that exists within an organization, a mission/business process, enterprise architecture, or information\r\nsystem including its environment of operation, which contributes to (i.e., increases or decreases) the likelihood that\r\none or more threat events, once initiated, will result in undesirable consequences or adverse impact to organizational\r\noperations and assets, individuals, other organizations, or the Nation. [SP800-30r1]\r\npressure regulator\r\nA device used to control the pressure of a gas or liquid. [IR6859]\r\npressure sensor\r\nA sensor system that produces an electrical signal related to the pressure acting on it by its surrounding medium.\r\nPressure sensors can also use differential pressure to obtain level and flow measurements. [IR6859] (adapted)\r\nprinter\r\nA device that converts digital data to human-readable text on a paper medium. [IR6859] (adapted)\r\nprocess controller\r\nA type of computer system, typically rack-mounted, that processes sensor input, executes control algorithms, and\r\ncomputes actuator outputs. [IR6859] (adapted)\r\nprogrammable logic controller\r\nA solid-state control system that has a user-programmable memory for storing instructions for the purpose of\r\nimplementing specific functions such as I/O control, logic, timing, counting, three mode (PID) control,\r\ncommunication, arithmetic, and data and file processing. [ISADICT]\r\nprotocol\r\nA set of rules (i.e., formats and procedures) to implement and control some type of association (e.g.,\r\ncommunication) between systems. [RFC4949]\r\nprotocol analyzer\r\nA device or software application that enables the user to analyze the performance of network data so as to ensure\r\nthat the network and its associated hardware/software are operating within network specifications. [ISADICT]\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n166\r\nreal time\r\nPertaining to the performance of a computation during the actual time that the related physical process transpires so\r\nthat the results of the computation can be used to guide the physical process.\r\nredundant control server\r\nA backup to the control server that maintains the current state of the control server at all times. [IR6859]\r\nrelay\r\nAn electromechanical device that completes or interrupts an electrical circuit by physically moving conductive\r\ncontacts. The resultant motion can be coupled to another mechanism such as a valve or breaker. [ISADICT]\r\nremote access\r\nAccess to an organizational system by a user (or a process acting on behalf of a user) communicating through an\r\nexternal network. [SP800-53r5]\r\nremote diagnostics\r\nDiagnostic activities conducted by individuals who are outside of an information system security perimeter.\r\nremote maintenance\r\nMaintenance activities conducted by individuals communicating through an external network. [SP800-53r5]\r\nremote terminal unit\r\nA computer with radio interfacing used in remote situations where communications via wire is unavailable. Usually\r\nused to communicate with remote field equipment. PLCs with radio communication capabilities are also used in\r\nplace of RTUs. [IR6859]\r\nrisk\r\nThe level of impact on agency operations (including mission, functions, image, or reputation), agency assets, or\r\nindividuals resulting from the operation of an information system, given the potential impact of a threat and the\r\nlikelihood of that threat occurring. [FIPS200] (adapted)\r\nrisk assessment\r\nThe process of identifying risks to agency operations (including mission, functions, image, or reputation), agency\r\nassets, or individuals by determining the probability of occurrence, the resulting impact, and additional security\r\ncontrols that would mitigate this impact. Part of risk management, synonymous with risk analysis. Incorporates\r\nthreat and vulnerability analyses. [SP800-39] (adapted)\r\nrisk management\r\nThe process of managing risks to organizational operations (including mission, functions, image, reputation),\r\norganizational assets, individuals, other organizations, and the Nation, resulting from the operation of an information\r\nsystem, and includes: (i) the conduct of a risk assessment; (ii) the implementation of a risk mitigation strategy; and\r\n(iii) employment of techniques and procedures for the continuous monitoring of the security state of the information\r\nsystem. [FIPS200] (adapted)\r\nrouter\r\nA computer that is a gateway between two networks at OSI layer 3 and that relays and directs data packets through\r\nthat inter-network. The most common form of router operates on IP packets. [RFC4949] (adapted)\r\nsafety instrumented system\r\nA system that is composed of sensors, logic solvers, and final control elements whose purpose is to take the process\r\nto a safe state when predetermined conditions are violated. Other terms commonly used include emergency\r\nshutdown system (ESS), safety shutdown system (SSD), and safety interlock system (SIS). [ANSI-ISA-84]\r\nSCADA server\r\nThe device that acts as the master in a SCADA system.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n167\r\nsecurity audit\r\nIndependent review and examination of a system’s records and activities to determine the adequacy of system\r\ncontrols, ensure compliance with established security policy and procedures, detect breaches in security services,\r\nand recommend any changes that are indicated for countermeasures. [ISO7498-1]\r\nsecurity controls\r\nThe management, operational, and technical controls (i.e., safeguards or countermeasures) prescribed for an\r\ninformation system to protect the confidentiality, integrity, and availability of the system and its information.\r\n[FIPS199]\r\nsecurity plan\r\nFormal document that provides an overview of the security requirements for an information system and describes\r\nthe security controls in place or planned for meeting those requirements. [SP800-18r1]\r\nsecurity policy\r\nSecurity policies define the objectives and constraints for the security program. Policies are created at several levels,\r\nranging from organization or corporate policy to specific operational constraints (e.g., remote access). In general,\r\npolicies provide answers to the questions “what” and “why” without dealing with “how.” Policies are normally\r\nstated in terms that are technology-independent.\r\nsensor\r\nA device that produces a voltage or current output that is representative of some physical property being measured\r\n(e.g., speed, temperature, flow). [ISADICT]\r\nset point\r\nAn input variable that sets the desired value of the controlled variable. This variable may be manually set,\r\nautomatically set, or programmed. [ISADICT]\r\nsingle loop controller\r\nA controller that controls a very small process or a critical process. [IR6859]\r\nsocial engineering\r\nAn attempt to trick someone into revealing information (e.g., a password) that can be used to attack systems or\r\nnetworks. [SP800-61r2]\r\nsupervisory control\r\nA term that is used to imply that the output of a controller or computer program is used as input to other controllers.\r\nSee Control Server. [ISADICT]\r\nsupervisory control and data acquisition\r\nA generic name for a computerized system that is capable of gathering and processing data and applying operational\r\ncontrols over long distances. Typical uses include power transmission and distribution and pipeline systems.\r\nSCADA was designed for the unique communication challenges (e.g., delays, data integrity) posed by the various\r\nmedia that must be used, such as phone lines, microwave, and satellite. Usually shared rather than dedicated.\r\n[ISADICT]\r\ntechnical controls\r\nThe security controls (i.e., safeguards or countermeasures) for an information system that are primarily implemented\r\nand executed by the information system through mechanisms contained in the hardware, software, or firmware\r\ncomponents of the system. [FIPS200]\r\nthreat\r\nAny circumstance or event with the potential to adversely impact agency operations (including safety, mission,\r\nfunctions, image, or reputation), agency assets, or individuals through an information system via unauthorized\r\naccess, destruction, disclosure, modification of information, and/or denial of service. [FIPS200] (adapted)\r\nthreat event\r\nAn event or situation that has the potential for causing undesirable consequences or impact. [SP800-30r1]\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n168\r\nthreat source\r\nThe intent and method targeted at the intentional exploitation of a vulnerability or a situation and method that may\r\naccidentally trigger a vulnerability. Synonymous with threat agent. [FIPS200]\r\nTransmission Control Protocol\r\nTCP is one of the main protocols in TCP/IP networks. Whereas the IP protocol deals only with packets, TCP enables\r\ntwo hosts to establish a connection and exchange streams of data. TCP guarantees the delivery of data and also\r\nguarantees that packets will be delivered in the same order in which they were sent.\r\nTrojan horse\r\nA computer program that appears to have a useful function, but also has a hidden and potentially malicious function\r\nthat evades security mechanisms, sometimes by exploiting legitimate authorizations of a system entity that invokes\r\nthe program. [RFC4949]\r\nunauthorized access\r\nA person gains logical or physical access without permission to a network, system, application, data, or other\r\nresource. [SP800-61]\r\nunidirectional gateway\r\nUnidirectional gateways are a combination of hardware and software. The hardware permits data to flow from one\r\nnetwork to another but is physically unable to send any information at all back to the source network. The software\r\nreplicates databases and emulates protocol servers and devices.\r\nvalve\r\nAn in-line device in a fluid-flow system that can interrupt flow, regulate the rate of flow, or divert flow to another\r\nbranch of the system. [ISADICT]\r\nvirtual private network\r\nA restricted-use, logical (i.e., artificial or simulated) computer network that is constructed from the system resources\r\nof a relatively public, physical (i.e., real) network (such as the Internet), often by using encryption (located at hosts\r\nor gateways), and often by tunneling links of the virtual network across the real network. [RFC4949] (adapted)\r\nvirus\r\nA hidden, self-replicating section of computer software, usually malicious logic, that propagates by infecting (i.e.,\r\ninserting a copy of itself into and becoming part of) another program. A virus cannot run by itself; it requires that its\r\nhost program be run to make the virus active. [RFC4949] (adapted)\r\nvulnerability\r\nWeakness in an information system, system security procedures, internal controls, or implementation that could be\r\nexploited or triggered by a threat source. [FIPS200]\r\nwide area network\r\nA physical or logical network that provides data communications to a larger number of independent users than are\r\ntypically served by a local area network (LAN) and that is usually spread over a larger geographic area than that of a\r\nLAN.\r\nwireless device\r\nAny device that can connect to an OT network via radio or infrared waves, usually to collect or monitor data but\r\nalso to modify control set points in some cases.\r\nworkstation\r\nA computer used for tasks such as programming, engineering, and design. [IR6859]\r\nworm\r\nA computer program that can run independently, can propagate a complete working version of itself onto other hosts\r\non a network, and may consume computer resources destructively. [RFC4949] (adapted)\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n169\r\nAppendix C. Threat Sources, Vulnerabilities, and Incidents\r\nSeveral terms are used to describe the interrelated concepts of threat, threat source, threat event,\r\nand incident. A threat is any circumstance or event with the potential to adversely impact\r\norganizational operations (including mission, functions, image, or reputation), organizational\r\nassets, individuals, other organizations, or the Nation through an information system via\r\nunauthorized access, destruction, disclosure, modification of information, and/or denial of\r\nservice. Threats have some intent or method that may exploit a vulnerability through either\r\nintentional or unintentional means. This intent or method is referred to as the threat source. A\r\nvulnerability is a weakness in an information system (including an OT), system security\r\nprocedures, internal controls, or implementation that could be exploited or triggered by a threat\r\nsource. A threat event is an event or situation that has the potential to cause undesirable\r\nconsequences or impacts. When a threat event occurs, it becomes an incident that actually or\r\npotentially jeopardizes the confidentiality, integrity, or availability of an information system or\r\nthe information the system processes, stores, or transmits or that constitutes a violation or\r\nimminent threat of violation of security policies, security procedures, or acceptable use policies.\r\nThis appendix explores OT-specific threat sources, vulnerabilities, and incidents. It also cites\r\nexamples of OT-specific incidents to illustrate their potential impacts. Each organization\r\ncalculates risk based on the specific threats, vulnerabilities, impacts, and likelihood of incidents\r\nwithin their environment.\r\nC.1. Threat Sources\r\nThreats to OT can come from numerous sources that can be classified as adversarial, accidental,\r\nstructural, or environmental. Table 13 lists and defines known threat sources to OT. These threat\r\nsources should be considered part of the risk management strategy. The threat source must be\r\nwell understood in order to define and implement adequate protection. For example,\r\nenvironmental events (e.g., floods, earthquakes) are well understood but may vary in their\r\nmagnitude, frequency, and ability to compound other interconnected events. However,\r\nadversarial threats depend on the resources available to the adversary and the emergence of\r\npreviously unknown vulnerabilities or attacks.\r\nTable 13. Threats to OT\r\nType of Threat Source Description Characteristics\r\nADVERSARIAL\r\n- Bot network operators\r\n- Criminal groups\r\n- Hackers/hacktivists\r\n- Insiders\r\n- Nations\r\n- Terrorists\r\nIndividuals, groups, organizations, or nation-states that\r\nseek to exploit the organization’s dependence on cyber\r\nresources (e.g., information in electronic form,\r\ninformation and communications technologies, and the\r\ncommunications and information-handling capabilities\r\nprovided by those technologies)\r\nCapability,\r\nIntent, Targeting\r\n \r\nACCIDENTAL\r\n- User\r\n- Privileged user or administrator\r\nErroneous actions taken by individuals in the course of\r\nexecuting their everyday responsibilities (e.g., operator\r\naccidentally typing 100 instead of 10 as a set point;\r\nengineer making a change in the production\r\nenvironment while thinking that they are in the\r\ndevelopment environment)\r\nRange of effects\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n170\r\nType of Threat Source Description Characteristics\r\nSTRUCTURAL\r\n- Hardware failure\r\n• Processors, input/output\r\ncards, communications cards\r\n• Networking equipment\r\n• Power supply\r\n• Sensor, final element\r\n• HMI, displays\r\n- Software failure\r\n• OS\r\n• General-purpose applications\r\n• Mission-specific applications\r\n- Environmental controls failure\r\n• Temperature control\r\n• Humidity control\r\n- Communications degradation\r\n• Wireless\r\n• Wired\r\nFailures of equipment, environmental controls, or\r\nsoftware due to aging, resource depletion, or other\r\ncircumstances that exceed expected operating\r\nparameters, including failures of critical infrastructures\r\nwithin the control of the organization\r\n \r\nRange of effects\r\n \r\nENVIRONMENTAL\r\n- Natural or human-caused disaster\r\n• Fire\r\n• Flood/tsunami\r\n• Windstorm/tornado\r\n• Hurricane\r\n• Earthquake\r\n• Bombing\r\n• Animal interference\r\n• Solar flares, meteorites\r\n- Critical infrastructure failure\r\n• Telecommunications\r\n• Electrical power\r\n• Transportation\r\n• Water/wastewater\r\nNatural disasters and failures of critical infrastructures\r\non which the organization depends but that are outside\r\nof the control of the organization.\r\nNote: Natural and human-caused disasters can also be\r\ncharacterized in terms of their severity and/or duration.\r\nHowever, because the threat source and the threat event\r\nare strongly identified, severity and duration can be\r\nincluded in the description of the threat event (e.g.,\r\nCategory 5 hurricane causes extensive damage to the\r\nfacilities that house mission-critical systems, making\r\nthose systems unavailable for three weeks).\r\n \r\nRange of effects\r\n \r\nC.2. Vulnerabilities and Predisposing Conditions\r\nVulnerabilities are weaknesses in information systems, system procedures, controls, or\r\nimplementations that can be exploited by a threat source. Predisposing conditions are properties\r\nof the organization, mission or business process, architecture, or information systems that\r\ncontribute to the likelihood of a threat event. The order of these vulnerabilities and predisposing\r\nconditions does not reflect priority in terms of likelihood of occurrence or severity of impact.\r\nAdditionally, the vulnerabilities and predisposing conditions identified in this section should not\r\nbe considered a complete list, nor should they be assumed to occur in every OT environment.\r\nVulnerabilities and predisposing conditions are grouped according to where they exist, such as in\r\nthe organization’s policy and procedures, or the inadequacy of security mechanisms\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n171\r\nimplemented in hardware, firmware, and software. The former is referred to as being in the\r\norganization and the latter as being in the system. Understanding the source of vulnerabilities\r\nand predisposing conditions can help identify optimal mitigation strategies. Deeper analysis may\r\nuncover that causes and observations may not be one-to-one – that is, some underlying causes\r\nmay exhibit multiple symptoms, and some symptoms may come from more than one cause.\r\nAny given OT will usually exhibit a subset of the identified vulnerabilities in this appendix but\r\nmay also contain additional vulnerabilities and predisposing conditions that are unique to a\r\nparticular technology or implementation. Specific current information on OT vulnerabilities can\r\nbe found on the CISA website, though many vendors publish notifications and patches that are\r\nnot always found on the CISA website. It is beneficial to maintain relationships with vendors in\r\norder to stay up to date with known vulnerabilities.\r\nSome vulnerabilities and predisposing conditions can be mitigated. Others can only be accepted\r\nand controlled by appropriate countermeasures but will result in some residual risk to the OT\r\nenvironment. For example, some existing policies and procedures may be changed with a level\r\nof effort that the organization considers acceptable, while others are more expeditiously dealt\r\nwith by instituting additional policies and procedures.\r\nVulnerabilities in the products and services acquired from outside of the organization are rarely\r\nunder the direct control of the organization. Changes may be influenced by market forces, but\r\nthis is a slow and indirect approach. Instead, the organization may change predisposing\r\nconditions to reduce the likelihood that a systemic vulnerability will be exploited.\r\nC.2.1. Policy and Procedure Vulnerabilities and Predisposing Conditions\r\nVulnerabilities and predisposing conditions are often introduced into the OT environment\r\nbecause of incomplete, inappropriate, or nonexistent security policy, including documentation,\r\nimplementation guides (e.g., procedures), and enforcement. Management support of security\r\npolicy and procedures is the cornerstone of any security program. Organization security policy\r\ncan reduce vulnerabilities by mandating and enforcing proper conduct. Written policy and\r\nprocedures are mechanisms for informing staff and stakeholders of decisions about behavior that\r\nis beneficial to the organization. From this perspective, policy is an educational and instructive\r\nway to reduce vulnerabilities. Enforcement is a partner to policy and encourages people to do the\r\nproper thing. Various forms of corrective action are the usual consequences to personnel not\r\nfollowing policy and procedures. Policies should be explicit about the consequences to\r\nindividuals or organizations that do not conform.\r\nThere is usually a complex policy and procedure environment that includes laws, regulations,\r\noverlapping jurisdictions and spheres of influence, economics, custom, and history. The larger\r\nenterprise is often subdivided into organizational units that should work together to reduce\r\nvulnerabilities. The scope and hierarchical relationship among policies and procedures needs to\r\nbe managed for maximum effectiveness.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n172\r\nTable 14 presents examples of observed policy and procedure vulnerabilities and predisposing\r\nconditions for OT.\r\nTable 14. Policy and procedure vulnerabilities and predisposing conditions\r\nVulnerability Description\r\nInadequate organizational\r\nownership of risk assessments\r\nRisk assessments should be performed with acknowledgement from\r\nappropriate levels within the organization. The lack of understanding of\r\nrisk could lead to under-mitigated scenarios or inadequate funding and\r\nselection of controls.\r\nInadequate security policy for OT Vulnerabilities are often introduced into the OT environment due to\r\ninadequate policies or the lack of policies specifically for OT system\r\nsecurity. Controls and countermeasures should be derived from a risk\r\nassessment or policy to ensure uniformity and accountability.\r\nInadequate OT security training\r\nand awareness program\r\nA documented formal OT security training and awareness program is\r\ndesigned to keep staff up to date on organizational security policies and\r\nprocedures, threats, industry cybersecurity standards, and recommended\r\npractices. Without adequate ongoing training on specific OT policies and\r\nprocedures, staff cannot be expected to maintain a secure OT environment.\r\nLack of inventory management\r\npolicy\r\nInventory policy and procedures should include installation, removal, and\r\nchanges made to hardware, firmware, and software. An incomplete\r\ninventory could lead to unmanaged and unprotected devices within the OT\r\nenvironment.\r\nLack of configuration\r\nmanagement policy\r\nLack of policy and procedures for OT configuration management can lead\r\nto an unmanageable and highly vulnerable inventory of hardware,\r\nfirmware, and software.\r\nInadequate OT equipment\r\nimplementation guidelines\r\nEquipment implementation guidelines should be kept up to date and\r\nreadily available. These guidelines are an integral part of security\r\nprocedures in the event of an OT malfunction.\r\nLack of administrative\r\nmechanisms for security policy\r\nenforcement\r\nWithout accountability for enforcing policy, there is limited ability to\r\nensure that security policies are followed adequately. Administrative\r\nmechanisms should be in place to ensure accountability.\r\nInadequate review of the\r\neffectiveness of the OT security\r\ncontrols\r\nProcedures and schedules should exist to determine the extent to which the\r\nsecurity program and its constituent controls are implemented correctly,\r\noperating as intended, and producing the desired outcome with respect to\r\nmeeting the security requirements of the OT. The examination is\r\nsometimes called an “audit,” “evaluation,” or “assessment.” Policy should\r\naddress the stage of the life cycle, purpose, technical expertise,\r\nmethodology, and level of independence.\r\nNo OT-specific contingency plan A contingency plan (e.g., business continuity plan, disaster recovery plan)\r\nshould be prepared, tested, and available in the event of a major hardware\r\nor software failure or destruction of facilities. The lack of a specific plan\r\nfor the OT could lead to extended downtimes and production losses.\r\nLack of adequate access control\r\npolicy\r\nAccess control enforcement depends on policy that correctly models roles,\r\nresponsibilities, and authorizations. The policy model must enable the way\r\nthe organization functions.\r\nLack of adequate authentication\r\npolicy\r\nAuthentication policies are needed to define when authentication\r\nmechanisms (e.g., passwords, smart cards) must be used, how strong they\r\nmust be, and how they must be maintained. Without this policy, systems\r\nmay not have appropriate authentication controls, making unauthorized\r\naccess to systems more likely. Authentication policies should be\r\ndeveloped as part of an overall OT security program, taking into account\r\nthe capabilities of the OT and its personnel to handle more complex\r\npasswords and other mechanisms.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n173\r\nVulnerability Description\r\nInadequate incident detection and\r\nresponse plan and procedures\r\nIncident detection and response plans, procedures, and methods are\r\nnecessary for rapidly detecting incidents, minimizing loss and destruction,\r\npreserving evidence for later forensic examination, mitigating the\r\nweaknesses that were exploited, and restoring services. Establishing a\r\nsuccessful incident response capability includes continually monitoring for\r\nanomalies, prioritizing the handling of incidents, and implementing\r\neffective methods for collecting, analyzing, and reporting data.\r\nLack of redundancy for critical\r\ncomponents\r\nLack of redundancy in critical components could provide single-point-of-failure possibilities.\r\nC.2.2. System Vulnerabilities and Predisposing Conditions\r\nSecurity controls must clearly identify the systems to which they apply. Systems range widely in\r\nsize, scope, and capability. At the small end of the spectrum, a system may be an individual\r\nhardware or software product or service. At the other end of the spectrum are large and complex\r\nsystems, systems-of-systems, and networks, all of which incorporate hardware architectures and\r\nsoftware frameworks (including application frameworks) to support operations. An organization\r\nmay choose to identify security zones such that security controls may be applied to all systems\r\nwithin the security zone.\r\nSystem vulnerabilities can occur in the hardware, firmware, and software used to build the OT.\r\nSources of vulnerabilities include design flaws, development flaws, misconfigurations, poor\r\nmaintenance, poor administration, and connections with other systems and networks. Many of\r\nthe controls in the NIST SP 800-53 and the OT overlay in Appendix F specify what the system\r\nmust do to mitigate these vulnerabilities.\r\nVulnerabilities can also exist in the auxiliary components that support the OT systems. A subset\r\nof those vulnerabilities with the potential to impact the physical process are described in this\r\nsection.\r\nThe potential vulnerabilities and predisposing conditions commonly found within OT systems\r\nare categorized into the following tables:\r\n• Table 15. Architecture and design vulnerabilities and predisposing conditions\r\n• Table 16. Configuration and maintenance vulnerabilities and predisposing conditions\r\n• Table 17. Physical vulnerabilities and predisposing conditions\r\n• Table 18. Software development vulnerabilities and predisposing conditions\r\n• Table 19. Communication and network configuration vulnerabilities and predisposing\r\nconditions\r\n• Table 20. Sensor, final element, and asset management vulnerabilities and predisposing\r\nconditions\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n174\r\nTable 15. Architecture and design vulnerabilities and predisposing conditions\r\nVulnerability Description\r\nInadequate incorporation of\r\nsecurity into architecture and\r\ndesign\r\nIncorporating security into the OT architecture and design must start with\r\na budget and schedule designated for OT. The architectures must address\r\nthe identification and authorization of users, access control mechanism,\r\nnetwork topologies, and system configuration and integrity mechanisms.\r\nInadequate management of change\r\nthat allows insecure architecture to\r\nevolve\r\nThe network infrastructure within the OT environment has often been\r\ndeveloped and modified based on business and operational requirements\r\nwith little consideration for the potential security impacts of the changes.\r\nOver time, security gaps may have been inadvertently introduced within\r\nthe infrastructure. Without remediation, these gaps may represent\r\nbackdoors into the OT.\r\nSensors and controllers that were historically simple devices are now often\r\nmanufactured as intelligent devices. In some cases, sensors and controllers\r\nmay be replaced with IIoT devices that allow direct internet connections.\r\nSecurity should be incorporated into change management for all OT\r\ndevices, not just traditional IT components.\r\nNo security perimeter defined If the OT does not have a security perimeter clearly defined, it is not\r\npossible to ensure that the necessary security controls are deployed and\r\nconfigured properly. This can lead to unauthorized access to systems and\r\ndata, as well as other problems.\r\nControl networks used for non-control trafficControl and non-control traffic have different requirements, such as\r\ndeterminism and reliability. Having both types of traffic on a single\r\nnetwork creates challenges for meeting the requirements of control traffic.\r\nFor example, non-control traffic could inadvertently consume resources\r\nthat control traffic needs, causing disruptions in OT functions.\r\nControl network services\r\ndependent on a non-control\r\nnetwork\r\nWhen IT services such as a Domain Name System (DNS) and Dynamic\r\nHost Configuration Protocol (DHCP) are used by control networks, they\r\nare often implemented in the IT network. This causes the OT network to\r\nbecome dependent on the IT network, which may not have the reliability\r\nand availability requirements needed by OT.\r\nInadequate collection of event data\r\nhistory\r\nForensic analysis depends on the collection and retention of sufficient\r\ndata. Without proper and accurate data collection, it may be impossible to\r\ndetermine what caused a security incident to occur. Incidents might go\r\nunnoticed, leading to additional damage and/or disruption. Regular\r\nsecurity monitoring is also needed to identify problems with security\r\ncontrols, such as misconfigurations and failures.\r\nEvent data for an OT environment could include physical process data,\r\nsystem use data, and network data.\r\n \r\nTable 16. Configuration and maintenance vulnerabilities and predisposing conditions\r\nVulnerability Description\r\nHardware, firmware, and software\r\nthat are not under asset\r\nmanagement\r\nThe organization does not know what it has (e.g., make, model), where\r\nthey are, or what version it is, resulting in an inconsistent and ineffective\r\ndefense posture. To properly secure an OT, there should be an accurate\r\ninventory of the assets in the environment. Procedures should be in place\r\nto manage additions, deletions, and modifications of assets, which include\r\nasset inventory management. These procedures are critical to executing\r\nbusiness continuity and disaster recovery plans.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n175\r\nVulnerability Description\r\nHardware, firmware, and software\r\nare not under configuration\r\nmanagement\r\nThe organization does not know the patch management status, security\r\nsettings, or configuration versions that it has, resulting in an inconsistent\r\nand ineffective defense posture. A lack of configuration change\r\nmanagement procedures can lead to security oversights, exposures, and\r\nrisks. A process for controlling modifications to hardware, firmware,\r\nsoftware, and documentation should be implemented to ensure that an OT\r\nis protected against inadequate or improper modifications before, during,\r\nand after system implementation. To properly secure an OT, there should\r\nbe an accurate listing or repository of the current configurations.\r\nOS and vendor software patches\r\nmay not be developed until long\r\nafter security vulnerabilities are\r\nfound\r\nBecause of the tight coupling between OT software and the underlying\r\nOT, changes must undergo expensive and time-consuming comprehensive\r\nregression testing. The elapsed time for such testing and the subsequent\r\ndistribution of updated software provides a long window of vulnerability.\r\nVulnerability management procedures should include flexibility for\r\ninterim alternative mitigations.\r\nVendor declines to develop\r\npatches for vulnerability\r\nOut-of-date OSs and applications may contain newly discovered\r\nvulnerabilities that could be exploited. Security patch support may not be\r\navailable for legacy OT, so vulnerability management procedures should\r\ninclude contingency plans for mitigating vulnerabilities where patches\r\nmay never be available or replacement plans.\r\nLack of a vulnerability\r\nmanagement program\r\nVulnerabilities not considered by the organization could result in\r\nexploitation. Vulnerability management procedures should be in place to\r\ndetermine a plan of action or inaction upon the discovery of a\r\nvulnerability. Some OT considerations are: availability concerns may push\r\npatching until the next planned operational downtime; security patch\r\nsupport may not be available for OT systems that use outdated OSs;\r\nisolated systems may not require immediate patching; and OT exposed to\r\nthe internet may need to be prioritized for patching.\r\nInadequate testing of security\r\nchanges\r\nModifications to hardware, firmware, and software deployed without\r\ntesting could compromise normal operation of the OT. Documented\r\nprocedures should be developed for testing all changes for security\r\nimpacts. The live operational systems should never be used for testing.\r\nThe testing of system modifications may need to be coordinated with\r\nsystem vendors and integrators.\r\nPoor remote access controls There are many reasons why an OT may need to be remotely accessed,\r\nincluding vendors and system integrators performing system maintenance\r\nfunctions or OT engineers accessing geographically remote system\r\ncomponents. The concept of least privilege should be applied to remote\r\naccess controls. Remote access capabilities must be adequately controlled\r\nto prevent unauthorized individuals from gaining access or authorized\r\nindividuals from gaining excessive access to the OT.\r\nPoor configurations are used Improperly configured systems may leave unnecessary ports and protocols\r\nopen. These unnecessary functions may contain vulnerabilities that\r\nincrease the overall risk to the system. Using default configurations often\r\nexposes vulnerabilities and exploitable services. All settings should be\r\nexamined.\r\nCritical configurations are not\r\nstored or backed up\r\nProcedures should be available for restoring OT configuration settings in\r\nthe event of accidental or adversary-initiated configuration changes to\r\nmaintain system availability and prevent the loss of data. Documented\r\nprocedures should be developed for maintaining configuration settings.\r\nData unprotected on portable\r\ndevice\r\nSystem security could be compromised if sensitive data (e.g., passwords,\r\ndial-up numbers) is stored in cleartext on lost or stolen portable devices,\r\nsuch as laptops and mobile devices. Policy, procedures, and mechanisms\r\nare required for protection.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n176\r\nVulnerability Description\r\nVendor default passwords are used Most vendor default passwords are easy to discover within vendor product\r\nmanuals, which are also available to adversaries. Using the default\r\npassword can drastically increase OT vulnerability.\r\nPassword generation, use, and\r\nprotection do not comply with\r\npolicy\r\nPassword policy and procedures must be followed to be effective.\r\nViolations of password policy and procedures can increase OT\r\nvulnerability.\r\nInadequate access controls applied Access controls must match how the organization allocates\r\nresponsibilities and privilege to its personnel. Poorly specified access\r\ncontrols can result in an OT user having too many or too few privileges.\r\nThe following exemplify each case:\r\n• System configured with default access control settings gives an\r\noperator administrative privileges\r\n• System configured improperly results in an operator being unable to\r\ntake corrective actions in an emergency situation\r\nImproper data linking OT data storage systems may be linked to non-OT data sources. An\r\nexample of this is database links, which allow data from one database\r\n(e.g., data historian) to be automatically replicated on others. Data linkage\r\nmay create a vulnerability if it is not properly configured and may allow\r\nunauthorized data access or manipulation.\r\nMalware protection is not installed\r\nor up to date\r\nThe installation of malware (i.e., malicious software) is a common attack.\r\nMalware protection software, such as antivirus software, should be kept\r\ncurrent in a dynamic environment. Outdated malware protection software\r\nand definitions leave the system open to malware threats.\r\nMalware protection implemented\r\nwithout sufficient testing\r\nMalware protection software that is deployed without sufficient testing\r\ncould impact normal operation of the OT and block the system from\r\nperforming necessary control actions.\r\nDenial of service (DoS) OT software could be vulnerable to DoS attacks, resulting in the\r\nprevention of authorized access to a system resource or delaying system\r\noperations and functions.\r\nIntrusion detection and prevention\r\nsoftware is not installed\r\nIncidents can result in loss of system availability and integrity; the\r\ncapture, modification, and deletion of data; and incorrect execution of\r\ncontrol commands. IDS/IPS software may stop or prevent various types of\r\nattacks, including DoS attacks, and also identify attacked internal hosts,\r\nsuch as those infected with worms. IDS/IPS software must be tested prior\r\nto deployment to ensure that it does not compromise normal operation of\r\nthe OT.\r\nLogs are not maintained Without proper and accurate logs, it might be impossible to determine\r\nwhat caused a security event to occur and perform adequate forensics.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n177\r\nTable 17. Physical vulnerabilities and predisposing conditions\r\nVulnerability Description\r\nUnauthorized personnel have\r\nphysical access to equipment\r\nPhysical access to OT equipment should be restricted to only the\r\nnecessary personnel while taking safety requirements into account, such as\r\nemergency shutdown or restarts. Improper access to OT equipment can\r\nlead to any of the following:\r\n• Physical theft of data and hardware\r\n• Physical damage to or destruction of data and hardware\r\n• Modification of the operational process\r\n• Unauthorized changes to the functional environment (e.g., data\r\nconnections, unauthorized use of removable media, adding/removing\r\nresources)\r\n• Disconnection of physical data links\r\n• Undetectable interception of data (e.g., keystroke and other input\r\nlogging)\r\nRadio frequency, electromagnetic\r\npulse (EMP), static discharge,\r\nbrownouts, and voltage spikes\r\nSome hardware used for OT systems is vulnerable to radio frequency,\r\nelectromagnetic pulses (EMP), static discharge, brownouts, and voltage\r\nspikes. The impacts can range from the temporary disruption of command\r\nand control to permanent damage to circuit boards. Proper shielding,\r\ngrounding, power conditioning, and/or surge suppression is recommended.\r\nLack of backup power Without backup power to critical assets, a general loss of power will shut\r\ndown the OT and could create an unsafe situation. Loss of power could\r\nalso lead to insecure default settings. If the program file or data is stored in\r\nvolatile memory, the process may not be able to restart after a power\r\noutage without appropriate backup power.\r\nLoss of environmental control The loss of environmental control (e.g., temperatures, humidity) could\r\nlead to equipment damage, such as processors overheating. Some\r\nprocessors will shut down to protect themselves. Others may continue to\r\noperate in a minimal capacity and produce intermittent errors, continually\r\nreboot, or become permanently inoperable.\r\nUnsecured physical ports Unsecured universal serial bus (USB) and PS/2 ports could allow\r\nunauthorized connection of thumb drives or keystroke loggers.\r\n \r\nTable 18. Software development vulnerabilities and predisposing conditions\r\nVulnerability Description\r\nImproper data validation OT software may not properly validate user inputs or received data to\r\nensure validity. Invalid data may result in numerous vulnerabilities,\r\nincluding buffer overflows, command injections, cross-site scripting, and\r\npath traversals.\r\nInstalled security capabilities are\r\nnot enabled by default\r\nSecurity capabilities that were installed with the product are useless if they\r\nare not enabled or at least identified as being disabled.\r\nInadequate authentication,\r\nprivileges, and access control in\r\nsoftware\r\nUnauthorized access to configuration and programming software could\r\nprovide the ability to corrupt a device.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n178\r\nTable 19. Communication and network configuration vulnerabilities and predisposing conditions\r\nVulnerability Description\r\nData flow controls are not\r\nemployed\r\nData flow controls based on data characteristics are needed to restrict the\r\ninformation that is permitted between systems. These controls can prevent\r\nthe exfiltration of information and illegal operations.\r\nFirewalls are nonexistent or\r\nimproperly configured\r\nA lack of properly configured firewalls could permit unnecessary data to\r\npass between networks, such as control and corporate networks, thus\r\nallowing attacks and malware to spread between networks, making\r\nsensitive data susceptible to monitoring/eavesdropping, and providing\r\nindividuals with unauthorized access to systems.\r\nInadequate firewall and router logs Without proper and accurate logs, it might be impossible to determine\r\nwhat caused a security incident to occur.\r\nStandard, well-documented\r\ncommunication protocols are used\r\nin plaintext\r\nAdversaries that can monitor the OT network activity can use a protocol\r\nanalyzer or other utilities to decode the data transferred by protocols, such\r\nas telnet, File Transfer Protocol (FTP), Hypertext Transfer Protocol\r\n(HTTP), and Network File System (NFS). The use of such protocols also\r\nmakes it easier for adversaries to perform attacks against the OT and\r\nmanipulate OT network activity.\r\nAuthentication of users, data, or\r\ndevices is substandard or\r\nnonexistent\r\nMany OT protocols have no authentication at any level. Without\r\nauthentication, there is the potential to replay, modify, or spoof data or\r\ndevices, such as sensors and user identities.\r\nUse of unsecure OT protocols OT protocols often have few or no security capabilities, such as\r\nauthentication and encryption, to protect data from unauthorized access or\r\ntampering. The incorrect implementation of the protocols can also lead to\r\nadditional vulnerabilities.\r\nLack of integrity checking for\r\ncommunications\r\nIntegrity checks are not built into most OT protocols, so adversaries could\r\nmanipulate communications undetected. To ensure integrity, the OT can\r\nuse lower-layer protocols (e.g., IPsec) that offer data integrity protection\r\nwhen traversing untrusted physical media.\r\nInadequate authentication between\r\nwireless clients and access points\r\nStrong mutual authentication between wireless clients and access points is\r\nneeded to ensure that legitimate OT clients do not connect to a rogue\r\naccess point deployed by an adversary and that adversary clients do not\r\nconnect to any of the OT wireless networks.\r\nInadequate data protection\r\nbetween wireless clients and\r\naccess points\r\nSensitive data between wireless clients and access points should be\r\nprotected using strong encryption to ensure that adversaries cannot gain\r\nunauthorized access to the unencrypted data.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n179\r\nTable 20. Sensor, final element, and asset management vulnerabilities and predisposing conditions\r\nVulnerability Description\r\nUnauthorized physical access to\r\nsensors or final elements\r\nPhysical access to sensors and final elements allows for direct\r\nmanipulation of the physical process. Many devices are configured on a\r\nfieldbus such that physical access to the sensor network allows for\r\nmanipulation of controlling parameters. Physical access to the whole of\r\nthe loop should be managed to prevent incidents.\r\nUnauthorized wireless access to\r\nsensors or final elements\r\nWireless access to sensors and final elements allows for direct\r\nmanipulation of the physical process. Many smart devices allow for\r\nwireless configuration (e.g., Bluetooth, Wi-Fi, WirelessHART). Wireless\r\naccess should be securely configured or disabled using hardware write-protect where possible to prevent unauthorized modification of the sensors\r\nand final elements that are connected to both the physical process and the\r\nOT environment.\r\nInappropriate segmentation of the\r\nasset management system\r\nMost architectures are designed for PLCs, RTUs, DCS, and SCADA\r\ncontrollers to manipulate the process and for asset management systems to\r\nmonitor the assets connected to the controllers. Many asset management\r\nsystems also have the technical ability to modify the configuration of\r\nsensors and final elements, although modification may not be their\r\nprimary function. The asset management system should be controlled\r\nappropriately based on its ability (or lack of ability) to manipulate the\r\nprocess.\r\nC.3. Threat Events and Incidents\r\nA threat event is an event or situation that could potentially cause an undesirable consequence or\r\nimpact to operations resulting from some threat source. NIST SP 800-30, Rev. 1 [SP800-30r1]\r\nAppendix E identifies a broad set of threat events that could potentially impact information\r\nsystems. The properties of OT may also present unique threat events, such as how the threat\r\nevents can manipulate OT processes to cause physical damage. Table 21 provides an overview\r\nof potential OT threat events and leverages MITRE’s ATT\u0026CK® for Industrial Control Systems\r\n[ATTACK-ICS].\r\nTable 21. Examples of potential threat events\r\nThreat Event Description\r\nDenial of control Temporarily prevents operators and engineers from interfacing with\r\nprocess controls. An affected process may still be operating during the\r\nperiod of control loss but not necessarily in a desired state.\r\nManipulation of control Unauthorized changes made to programmed instructions in PLCs, RTUs,\r\nDCS, or SCADA controllers, alarm thresholds changed, or unauthorized\r\ncommands issued to control equipment. These changes could potentially\r\nresult in damage to equipment (if tolerances are exceeded), premature\r\nshutdown of processes (e.g., prematurely shutting down transmission\r\nlines), an environmental incident, or even disabled control equipment.\r\nSpoofed reporting message False information sent to an OT system operator, either for evasion or to\r\nimpair process control. The adversary could make the defenders and\r\noperators think that other errors are occurring in order to distract them\r\nfrom the actual source of the problem (i.e., alarm floods).\r\nTheft of operational information Adversaries may steal operational information for personal gain or to\r\ninform future operations.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n180\r\nThreat Event Description\r\nLoss of safety Adversaries may target and disable safety system functions as a\r\nprerequisite to subsequent attack execution or to allow future unsafe\r\nconditionals to go unchecked.\r\nLoss of availability Adversaries may leverage malware to delete or encrypt critical data on\r\nHMIs, workstations, or databases.\r\n \r\nNumerous OT incidents have been reported and documented. Descriptions of these events help\r\ndemonstrate the severity of the threat sources, vulnerabilities, and impacts within the OT domain.\r\nAs mentioned in Appendix C.2, the four broad categories of threat sources are adversarial,\r\naccidental, structural, and environmental. Often, the incident can be the result of multiple threat\r\nsources (e.g., an environmental event causes a system failure, which is responded to incorrectly\r\nby an operator and results in an accidental event).\r\nBelow is a limited selection of reported incidents that fall into each of the four categories. The\r\nincidents have been additionally categorized into malicious or non-malicious and direct or\r\nindirect to further distinguish the possible causes of OT incidents.\r\nM = Malicious. The event was initiated by someone for a harmful purpose. The initiator\r\nmay or may not have been targeting the OT or known the potential consequences.\r\nN = Non-malicious. There does not appear to be evidence that the initiating event was\r\nintended to cause an incident.\r\nD = Direct. The event was designed to discover, inhibit, impair, or otherwise impact the\r\nOT system.\r\nI = Indirect. The event was not believed to be designed to discover, inhibit, impair, or\r\notherwise impact the OT system. The OT system shut down or caused disruption as a\r\nresult of impact to the supporting infrastructure.\r\nC.3.1. Adversarial Events\r\n• [M][D] Marconi wireless hack.\r\n9\r\n9\r\n Additional information on the Marconi wireless hack incident can be found at https://www.osti.gov/biblio/1505628.\r\n In 1903, Italian radio pioneer Guglielmo Marconi was\r\npreparing for his first public demonstration of long-distance secure wireless\r\ncommunications from Cornwall to Professor Fleming at the Royal Institution of London.\r\nInventor and magician Nevil Maskelyne hacked the system and sent a comical message\r\nin Morse code referencing “rats.” Maskelyne then published an explanation of his hack in\r\nthe trade journal The Electrician.\r\n• [M][I] Worcester air traffic communications. In March 1997, a teenager in\r\nWorcester, Massachusetts, disabled part of the public switched telephone network using a\r\ndial-up modem connected to the system. This disabled phone service at the control tower,\r\nairport security, the airport fire department, the weather service, and carriers that use the\r\nairport. The tower’s main radio transmitter and another transmitter that activated runway\r\nlights were also shut down, as well as a printer that controllers used to monitor flight\r\n10\r\n \r\n10 Additional information on the Worcester air traffic communications incident can be found at\r\nhttp://www.cnn.com/TECH/computing/9803/18/juvenile.hacker/index.html\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n181\r\nprogress. The attack also disabled phone service to 600 homes and businesses in the\r\nnearby town of Rutland.\r\n• [M][D] Maroochy Shire sewage spill. In the spring of 2000, a former employee of an\r\nAustralian organization that developed manufacturing software applied for a job with the\r\nlocal government but was rejected. Over a two-month period, the disgruntled employee\r\nreportedly used a radio transmitter on as many as 46 occasions to remotely break into the\r\ncontrols of a sewage treatment system. He altered electronic data for particular sewerage\r\npumping stations and caused malfunctions in their operations, ultimately releasing about\r\n264,000 gallons of raw sewage into nearby rivers and parks.\r\n11\r\n11 Additional information on the Maroochy Shire sewage spill incident can be found at\r\nhttp://www.theregister.co.uk/2001/10/31/hacker_jailed_for_revenge_sewage/.\r\n• [M McAfee reported a series of attacks that were designed to steal\r\nsensitive data from global oil, energy, and petrochemical industries. Adversaries\r\nexfiltrated proprietary operations data and project financing information with regard to\r\noil and gas field bids and operations.\r\n][I] Night Dragon.\r\n12\r\n12 Additional information on Night Dragon was published as a McAfee white paper at https://www.heartland.org/_template-assets/documents/publications/29423.pdf.\r\n• [M][D] Iranian centrifuge, Stuxnet. Stuxnet was a Microsoft Windows computer\r\nworm discovered in July 2010 that specifically targeted industrial software and\r\nequipment. The worm initially spread indiscriminately but included a highly specialized\r\nmalware payload that was designed to only target particular SCADA systems that were\r\nconfigured to control and monitor specific industrial processes.\r\n13\r\n13 Additional information on the Stuxnet worm can be found at https://www.wired.com/2014/11/countdown-to-zero-day-stuxnet/.\r\n• [M][D] German steel mill attack. In 2014, hackers manipulated and disrupted control\r\nsystems to such a degree that a blast furnace could not be properly shut down, resulting in\r\nunspecified “massive” damage.\r\n14\r\n14 Additional information on the German steel mill incident can be found at http://www.wired.com/2015/01/german-steel-mill-hack-destruction/\r\n• [M][I] Shamoon. In 2012, Saudi Aramco experienced a malware attack that targeted\r\ntheir refineries and overwrote the attacked systems’ master boot records (MBRs),\r\npartition tables, and other data files. This caused the systems to become unusable.\r\n15\r\n15Additional information on Shamoon can be found at https://www.cisa.gov/uscert/ics/monitors/ICS-MM201209.\r\n• [M][D] New York dam. In 2013, an Iranian computer security company obtained\r\nremote access to a computer that controlled the SCADA system for the Bowman Dam\r\nlocated in Rye, New York. The adversary was able to view water levels, temperature, and\r\nthe status of the sluice gate. The sluice gate control was disconnected for maintenance at\r\nthe time of adversarial remote access, so the dam could not be remotely controlled.\r\n16\r\n16 The U.S. Department of Justice indictment for the New York dam attacks can be found at https://www.justice.gov/opa/file/834996/download\r\n• [M][D] Dragonfly campaign, Havex. The energy sector was targeted during a multi-year cyber-espionage campaign that primarily used Havex malware. Havex was a remote\r\naccess Trojan that used the Open Platform Communications (OPC) standard to gather\r\ninformation about connected ICS devices on a network. The campaigns were exploratory.\r\n17\r\n \r\n.\r\n. 17 Additional information on the Dragonfly/Energetic Bear Campaign can be found at https://www.osti.gov/servlets/purl/1505628.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n182\r\n• [M][D] Ukrainian power grid, BlackEnergy3. On December 23, 2015, Ukrainian\r\npower companies experienced a cyberattack that caused power outages and impacted\r\nover 225,000 customers in Ukraine. Over 50 regional substations experienced malicious\r\nremote operation of their breakers. KillDisk malware was used to erase files on targeted\r\nsystems, including at least one Windows-based HMI. The actors also corrupted the\r\nfirmware of serial-to-Ethernet devices at the substations. This was the first known cyber\r\nattack on a power grid.\r\n18\r\n18 Additional information about the first Ukrainian power grid attack can be found at https://info.publicintelligence.net/NCCIC-UkrainianPowerAttack.pdf. 19\r\n• [M][D] Ukrainian power grid, Industroyer. On December 17, 2016, a cyber attack\r\noccurred at a substation outside of Kyiv, Ukraine, and resulted in an outage for customers\r\nof one substation for approximately one hour. This attack was the first known malware\r\nspecifically designed to attack the power grid.\r\n19\r\n Additional information on Industroyer malware can be found at https://us-cert.cisa.gov/ncas/alerts/TA17-163A\r\n• [M][I] Maersk, NotPetya. In 2017, the NotPetya malware encrypted computers globally\r\nwith no method for decryption. Although the malware initially targeted Ukrainian\r\ncompanies, it spread throughout the world with significant impacts to Maersk, FedEx,\r\nMerck, and Saint-Gobain. The malware destroyed data and disrupted shipping operations\r\nfor Maersk, costing the company over $300 million in repairs and recovery efforts.\r\n• [M][D] Saudi Petrochem, TRITON. A petrochemical facility in Saudi Arabia was\r\nattacked using malicious software that targeted the industrial SIS. The SIS initiated a safe\r\nshutdown of the petrochemical process in 2017 when the triple-redundant processors\r\nidentified mismatched code amongst the processors.\r\n20\r\n20 Additional information on the TRITON attack can be found at https://www.mandiant.com/resources/triton-actor-ttp-profile-custom-attack-tools-detections.\r\n• [M][I] Norsk Hydro, LockerGoga. In March 2019, Norsk Hydro experienced a\r\ncyberattack that used LockerGoga ransomware to encrypt its computer files. The\r\naluminum and renewable energy company transitioned to manual operations and was\r\ntransparent with the public on its progress to recovery. Norsk Hydro’s transparency\r\nthroughout the discovery and recovery process is well regarded by the security industry.\r\n21\r\n21 Additional information on Norsk Hydro attack can be found at https://news.microsoft.com/transform/hackers-hit-norsk-hydro-ransomware-company-responded-transparency/, https://doublepulsar.com/how-lockergoga-took-down-hydro-ransomware-used-in-targeted-attacks-aimed-at-big-business-c666551f5880, and https://www.darkreading.com/application-security/ransomware/norsk-hydro-this-is-how-you-react-to-a-ransomware-breach/a/d-id/750396.\r\n• [M][I] Colonial Pipeline. In May 2021, over 5,500 miles of pipeline transporting more\r\nthan 100 million gallons per day of refined products to the East Coast of the U.S.\r\nshutdown operations because of a ransomware attack. Colonial Pipeline was a victim of a\r\nransomware cyber attack that encrypted their IT systems by exploiting a legacy VPN\r\nprofile. The investigation is ongoing, but at the time of this writing, there is no evidence\r\nthat the ransomware had any direct impact on the OT environment. Colonial made the\r\ndecision to shut down the physical operations on the pipeline to contain any potential\r\ndamage. Colonial Pipeline also decided to pay the ransom to cybercriminal group\r\nDarkside in order to have all possible tools, including the decryption tools, available to\r\n22\r\n \r\n.\r\n22 Additional information on the Colonial Pipeline incident can be found at https://www.c-span.org/video/?512247-1/senate-homeland-security-hearing-colonial-pipeline-cyber-attack and https://www.hsgac.senate.gov/imo/media/doc/Testimony-Blount-2021-06-08.pdf.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n183\r\nbring the pipeline system back online. The U.S. Government was able to recover some of\r\nthe ransom payment.23\r\n23 Additional information can be found at https://www.justice.gov/opa/pr/department-justice-seizes-23-million-cryptocurrency-paid-ransomware-extortionists-darkside.\r\n• [M][I] Ransomware targeting healthcare. A string of malware delivered via phishing\r\nattacks targeted the healthcare and public health sectors to disrupt services and steal data.\r\nIn fall 2020, a CISA Alert (AA20-302A) was issued to warn healthcare and public health\r\nsector companies of the prevalence of these attacks.\r\n24\r\n24 Additional information on the series of malware targeting healthcare can be found at Ransomware Activity Targeting the Healthcare and Public\r\nHealth Sector | CISA.\r\nC.3.2. Structural Events\r\n• [N][D] Bellingham, Washington, gasoline pipeline failure. In June 1999, 237,000\r\ngallons of gasoline leaked from a 16-inch pipeline and ignited 1.5 hours later, causing\r\nthree deaths, eight injuries, and extensive property damage. The pipeline failure was\r\nexacerbated by control systems that were unable to perform control and monitoring\r\nfunctions. Immediately prior to and during the incident, the SCADA system exhibited\r\npoor performance that inhibited the pipeline controllers from seeing and reacting to the\r\ndevelopment of an abnormal pipeline operation. A key recommendation from the NTSB\r\nreport issued in October 2002 was to utilize an offline development and testing system\r\nfor implementing and testing changes to the SCADA database.\r\n25\r\n25 Additional information on the Bellingham, Washington, gasoline pipeline failure incident can be found at\r\nhttp://www.ntsb.gov/investigations/AccidentReports/Reports/PAR0202.pdf.\r\n• [M][I] CSX train signaling system. In August 2003, the Sobig computer virus was\r\nblamed for shutting down train signaling systems throughout the East Coast of the U.S.\r\nThe virus infected the computer system at CSX Corp.’s Jacksonville, Florida,\r\nheadquarters and shut down signaling, dispatching, and other systems. According to\r\nAmtrak spokesman Dan Stessel, 10 Amtrak trains were affected in the morning. Trains\r\nbetween Pittsburgh, PA, and Florence, South Carolina, were halted because of dark\r\nsignals, and one regional Amtrak train from Richmond, Virginia, to Washington and New\r\nYork was delayed for more than two hours. Long-distance trains were also delayed\r\nbetween four and six hours.\r\n26\r\n26 Additional information on the CSX train signaling system incident can be found at\r\nhttp://www.informationweek.com/story/showArticle.jhtml?articleID=13100807.\r\n• [N][D] Browns Ferry-3 PLC failure. In August 2006, TVA was forced to manually\r\nshut down one of their plant’s two reactors after unresponsive PLCs problems caused two\r\nwater pumps to fail and threatened the stability of the plant itself. Although there were\r\ndual redundant PLCs, they were connected to the same Ethernet network. Later testing on\r\nthe failed devices discovered that they would crash when they encountered excessive\r\nnetwork traffic.\r\n27\r\n \r\n27 Additional information on the Browns Ferry -3 PLC failure incident can be found at\r\nhttp://www.nrc.gov/reading-rm/doc-collections/gen-comm/info-notices/2007/in200715.pdf.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n184\r\nC.3.3. Environmental Events\r\n• [N][I] Fukushima Daiichi nuclear disaster. The Great East Japan Earthquake on\r\nMarch 11, 2011, struck off the coast of Japan and sent a massive tsunami inland toward\r\nthe nuclear plant. The tsunami compromised the plant’s seawall, flooding much of the\r\nplant, including the location housing the emergency generators. This emergency power\r\nwas critical for operating the control rooms and providing coolant water for the reactors.\r\nThe loss of coolant caused the reactor cores to overheat to the point where the fuel’s\r\nzirconium cladding reacted with water, releasing hydrogen gas and fueling large\r\nexplosions in three of the four reactor buildings. This resulted in large-scale radiation\r\nleakage that has impacted plant employees, nearby citizens, and the local environment.\r\nPost-event analysis found that the plant’s emergency response center had insufficient\r\nsecure communication lines to provide other areas of the plant with information on key\r\nsafety-related instrumentation.\r\n28\r\n28 Additional information can be found at http://www-pub.iaea.org/MTCD/meetings/PDFplus/2011/cn200/documentation/cn200_Final-Fukushima-Mission_Report.pdf and http://pbadupws.nrc.gov/docs/ML1414/ML14140A185.pdf.\r\nC.3.4. Accidental Events\r\n• [N][D] Vulnerability scanner incidents. While a ping sweep was being performed on\r\nan active SCADA network that controlled 9-foot robotic arms, one arm became active\r\nand swung around 180 degrees. The controller for the arm was in standby mode before\r\nthe ping sweep was initiated. In a separate incident, a ping sweep was being performed\r\non an ICS network to identify the hosts that were attached to the network for inventory\r\npurposes, and it caused a system that controlled the creation of integrated circuits in the\r\nfabrication plant to hang. This test resulted in the destruction of $50,000 worth of wafers.\r\n29\r\n29 Additional information on the vulnerability scanner incidents can be found at https://energy.sandia.gov/wp-content/gallery/uploads/sand_2005_2846p.pdf.\r\n• [N][D] Penetration testing incident. A natural gas utility hired an IT security\r\nconsulting organization to conduct penetration testing on its corporate IT network. The\r\nconsulting organization carelessly ventured into a part of the network that was directly\r\nconnected to the SCADA system. The penetration test locked up the SCADA system, and\r\nthe utility was not able to send gas through its pipelines for four hours.\r\n30\r\n30 Additional information on penetration testing incidents can be found at https://energy.sandia.gov/wp-content/gallery/uploads/sand_2005_2846p.pdf.\r\n• [N][I] NERC Enforcement Action. In 2019, a U.S. energy company was fined $10\r\nmillion by NERC for cybersecurity violations that took place between 2015 and 2018.\r\nThe inability to comply with U.S. standards for cybersecurity was seen as a risk to the\r\nsecurity and reliability of the overall power system.\r\n31\r\n31 For additional information about fines imposed on energy companies, see Enforcement Actions 2019 (nerc.com).\r\n• [N][D] NASA fire. A security patch was applied to an OT component that controlled a\r\nlarge engineering oven. The patch and associated reboot caused the oven to stop running,\r\nwhich led to a fire that destroyed the spacecraft hardware. The reboot also impeded alarm\r\nactivation, which allowed the fire to go undetected for 3.5 hours before discovery.\r\n32\r\n \r\n32 For additional information on accidental OT losses from applying IT security controls in NASA, see Final Report - IG-17-011 (nasa.gov).\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n185\r\n• [N][D] Hatch Nuclear Power Plant. In 2008, the Hatch nuclear power plant in\r\nGeorgia was forced into an emergency shutdown for forty-eight hours after a software\r\nupdate was installed on a single Windows computer. When the updated computer\r\nrebooted, it reset the data on the control system, causing safety systems to errantly\r\ninterpret the lack of data as a drop in water reservoirs that cool the plant’s\r\nradioactive nuclear fuel rods. As a result, automated safety systems at the plant\r\ntriggered a shutdown.\r\n33\r\n \r\n 33 Additional information can be found at https://www.homelandsecuritynewswire.com/cyber-mishap-causes-nuclear-power-plant-shutdown\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n186\r\nAppendix D. OT Security Organizations, Research, and Activities\r\nThis appendix contains abstracts of some of the many activities that are addressing OT\r\ncybersecurity. Organization descriptions and the related information provided in this appendix\r\nhave been drawn primarily from the listed organizations’ websites and other reliable public\r\nsources but have not been verified. Readers are encouraged to contact the organizations directly\r\nfor the most up-to-date and complete information.\r\nD.1. Consortiums and Standards\r\nD.1.1. Critical Infrastructure Partnership Advisory Council (CIPAC)\r\nThe U.S. Department of Homeland Security established the Critical Infrastructure Partnership\r\nAdvisory Council (CIPAC) to facilitate interaction between governmental entities and critical\r\ninfrastructure owners and operators. CIPAC is aligned with and supports the implementation of\r\nthe National Infrastructure Protection Plan 2013: Partnering for Critical Infrastructure Security\r\nand Resilience and Presidential Policy Directive 21, Critical Infrastructure Security and\r\nResilience to provide a forum in which the government and private-sector entities, organized as\r\ncoordinating councils, can jointly engage in a broad spectrum of activities to support and\r\ncollaborate on critical infrastructure security and resilience efforts.\r\nhttps://www.cisa.gov/critical-infrastructure-partnership-advisory-council\r\nD.1.2. Institute for Information Infrastructure Protection (I3P)\r\nThe Institute for Information Infrastructure Protection (I3P) is a consortium of leading national\r\ncybersecurity institutions, including academic research centers, government laboratories, and\r\nnon-profit organizations. It was founded in September 2001 to help meet a well-documented\r\nneed for improved research and development (R\u0026D) to protect the Nation’s information\r\ninfrastructure against catastrophic failures. The institute’s main role is to coordinate a national\r\ncybersecurity R\u0026D program and help build bridges between academia, industry, and\r\ngovernment. The I3P works toward identifying and addressing critical research problems in\r\ninformation infrastructure protection and opening information channels between researchers,\r\npolicymakers, and infrastructure operators.\r\nhttps://www.thei3p.org\r\nD.1.3. International Electrotechnical Commission (IEC)\r\nIEC is a standards organization that prepares and publishes international standards for all\r\nelectrical, electronic, and related technologies. These standards serve as a basis for creating\r\nnational standards and as references for drafting international tenders and contracts. IEC’s\r\nmembers include manufacturers, providers, distributors, vendors, consumers, users, and all levels\r\nof governmental agencies, professional societies, trade associations, and standards developers\r\nfrom over 60 countries. Below are relevant IEC Technical Committees (TC) that contribute to\r\nthe field of OT security.\r\nhttps://www.iec.ch\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n187\r\nD.1.3.1. IEC Technical Committee 57\r\nThe scope of TC 57 is to prepare international standards for power systems control equipment\r\nand systems, including energy management systems (EMSs), SCADA, distribution automation,\r\nteleprotection, and associated information exchange for real-time and non-real-time information\r\nused in the planning, operation, and maintenance of power systems.\r\nhttps://www.iec.ch/dyn/www/f?p=103:7:3323052731869::::FSP_ORG_ID,FSP_LANG_ID:1273\r\n,25\r\nThe list of current working groups (WGs) within TC 57 includes:\r\n• WG 3: Telecontrol protocols\r\n• WG 10: Power system IED communication and associated data models\r\n• WG 13: Software interfaces for operation and planning of the electric grid\r\n• WG 14: Enterprise business function interfaces for utility operations\r\n• WG 15: Data and communication security\r\n• WG 16: Deregulated energy market communications\r\n• WG 17: Power system intelligent electronic device communication and associated data\r\nmodels for microgrids, distributed energy resources and distribution automation\r\n• WG 18: Hydroelectric power plants - Communication for monitoring and control\r\n• WG 19: Interoperability within TC 57 in the long term\r\n• WG 20: Power Line Carrier Communication Systems\r\n• WG 21: Interfaces and protocol profiles relevant to systems connected to the electrical\r\ngrid\r\nD.1.3.2. IEC Technical Committee 65\r\nThe scope of TC 65 is to prepare international standards for the systems and elements used for\r\nindustrial process measurement, control, and automation to coordinate standardization activities\r\nthat affect the integration of components and functions into such systems, including safety and\r\nsecurity aspects. This work of standardization is to be carried out in the international fields for\r\nequipment and systems.\r\nhttps://www.iec.ch/dyn/www/f?p=103:7:3323052731869::::FSP_ORG_ID,FSP_LANG_ID:1250\r\n,25\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n188\r\nD.1.4. Institute of Electrical and Electronics Engineers, Inc. (IEEE)\r\nIEEE inspires the global community to innovate for a better tomorrow through its more than\r\n400,000 members in more than 160 countries and its highly cited publications, conferences,\r\ntechnology standards, and professional and educational activities.\r\nhttps://www.ieee.org/\r\nBelow are relevant IEEE subsocieties that contribute to the field of OT security.\r\nD.1.4.1. IEEE Engineering in Medicine and Biology Society (EMBS)\r\nEMBS is the world’s largest international society of biomedical engineers who design the\r\nelectrical circuits that make a pacemaker run, create the software that reads an MRI, and help\r\ndevelop the wireless technologies that allow patients and doctors to communicate over long\r\ndistances.\r\nhttps://www.embs.org/\r\nD.1.4.2. IEEE Industrial Electronics Society (IES)\r\nIES members focus on the theory and application of electronics, controls, communications,\r\ninstrumentation, and computational intelligence for industrial and manufacturing systems and\r\nprocesses.\r\nhttp://www.ieee-ies.org/\r\nD.1.4.3. IEEE Power \u0026 Energy Society (PES)\r\nIEEE PES is the world’s largest forum for sharing the latest in technological developments in the\r\nelectric power industry, for developing standards that guide the development and construction of\r\nequipment and systems, and for educating members of the industry and the general public.\r\nhttps://www.ieee-pes.org/\r\nD.1.4.4. IEEE Technical Committee on Power System Communications and\r\nCybersecurity (PSCCC)\r\nIEEE PSCCC Cybersecurity Subcommittee (SO) leads numerous working groups dedicated to\r\nmaintaining standards within the field of OT security.\r\nhttps://site.ieee.org/pes-pscc/cybersecurity-subcommittee-s0/\r\n• IEEE Std 1686, Standard for Intelligent Electronic Devices Cyber Security Capabilities\r\n• IEEE Std 1711.1, Standard for a Cryptographic Protocol for Cyber Security of Substation\r\nSerial Links: Substation Serial Protection Protocol (SSPP)\r\n• IEEE Std 2030.102.1-2020, Standard for Interoperability of Internet Protocol Security\r\n(IPsec) Utilized within Utility Control Systems\r\n• IEEE Std 1711.2-2019, Standard for Secure SCADA Communications Protocol (SSCP)\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n189\r\n• IEEE Std C37.240, Standard Cybersecurity Requirements for Power System Automation,\r\nProtection and Control Systems\r\n• IEEE Std 2808, Standard for Function Designations used in Electrical Power Systems for\r\nCyber Services and Cybersecurity\r\n• IEEE Std 2658, Guide for Cybersecurity Testing in Electric Power Systems\r\n• IEEE Std 1547.3, Guide for Cybersecurity of DERs Interface with Electric Power\r\nSystems\r\n• IEEE Std 1815-2012, Standard for Electric Power Systems Communications-Distributed\r\nNetwork Protocol (DNP3)\r\nD.1.4.5. IEEE Robotics and Automation Society (RAS)\r\nRAS members foster the development and facilitate the exchange of scientific and technological\r\nknowledge in robotics and automation that benefits the profession and humanity.\r\nhttps://www.ieee-ras.org/\r\nD.1.4.6. IEEE Vehicular Technology Society (VTS)\r\nThe Vehicular Technology Society (VTS) is composed of engineers, scientists, students, and\r\ntechnicians interested in advancing the theory and practice of electrical engineering as it applies\r\nto mobile communications, land transportation, railroad/mass transit, vehicular electro-technology equipment and systems, and land, airborne, and maritime mobile services.\r\nhttps://vtsociety.org\r\nD.1.5. International Society of Automation (ISA)\r\nThe International Society of Automation (ISA) is a non-profit professional association founded\r\nin 1945 to create a better world through automation. ISA advances technical competence by\r\nconnecting the automation community to achieve operational excellence. It is the trusted\r\nprovider of standards-based foundational technical resources, driving the advancement of\r\nindividual careers and the overall profession. ISA develops widely used global standards,\r\ncertifies professionals, provides education and training, publishes books and technical articles,\r\nhosts conferences and exhibits, and provides networking and career development programs for\r\nits members and customers around the world.\r\nhttps://www.isa.org\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n190\r\nD.1.5.1. ISA95, Enterprise-Control System Integration\r\nThe ISA95 standards development committee defines the interface between control functions\r\nand other enterprise functions based upon the Purdue Reference Model for Computer Integrated\r\nManufacturing (CIM). The ISA95 standard grew from the Purdue Enterprise Reference\r\nArchitecture (PERA), first published by ISA in 1992. Since then, it has served as a common\r\nreference for defining the interfaces between the enterprise and control networks across all OT\r\nsectors.\r\nhttps://www.isa.org/standards-and-publications/isa-standards/isa-standards-committees/isa95\r\nD.1.5.2. ISA99, Industrial Automation and Control Systems Security\r\nThe ISA99 standards development committee brings together industrial cybersecurity experts\r\nfrom across the globe to develop ISA standards on industrial automation and control systems\r\nsecurity. This original and ongoing ISA99 work is being utilized by the International\r\nElectrotechnical Commission in producing the multi-standard ISA/IEC 62443 series, which are\r\ncurrently organized into four categories: General, Policies and Procedures, System, and\r\nComponent.\r\nhttps://www.isa.org/standards-and-publications/isa-standards/isa-standards-committees/isa99\r\nGeneral\r\n• ISA-62443-1-1, Concepts and models\r\n• ISA-62443-1-2, Master glossary of terms and abbreviations\r\n• ISA-62443-1-3, Security system conformance metrics\r\n• ISA-62443-1-4, IACS security lifecycle and use cases Policies and Procedures\r\n• ISA-62443-2-1, Security program requirements for IACS asset owners\r\n• ISA-62443-2-2, IACS Security Protection Ratings (Draft)\r\n• ISA-62443-2-3, Patch management in the IACS environment\r\n• ISA-62443-2-4, Security Program requirements for IACS service providers\r\n• ISA-62443-2-5, Implementation guidance for IACS asset owners\r\nSystem\r\n• ISA-62443-3-1, Security technologies for IACS\r\n• ISA-62443-3-2, Security risk assessment for system design\r\n• ISA-62443-3-3, System security requirements and security levels\r\nComponent\r\n• ISA-62443-4-1, Product security development life cycle requirements\r\n• ISA-62443-4-2, Technical security requirements for IACS components\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n191\r\nD.1.5.3. ISASecure\r\nhttps://isasecure.org/\r\nThe ISASecure program is a certification scheme certifying off-the-shelf automation and control\r\nsystems to the ISA/IEC 62443 series of standards.\r\nD.1.5.4. ISA-TR84.00.09, Cybersecurity Related to the Functional Safety\r\nLifecycle\r\nThis document provides guidance for integrating the cybersecurity life cycle with the safety life\r\ncycle as they relate to Safety Controls, Alarms, and Interlocks (SCAI), inclusive of safety\r\ninstrumented systems (SISs). This scope includes the work processes and countermeasures used\r\nto reduce the risk involved due to cybersecurity threats to the industrial automation and control\r\nsystem (IACS) network.\r\nhttps://www.isa.org/products/isa-tr84-00-09-2017-cybersecurity-related-to-the-f\r\nD.1.6. International Organization for Standardization (ISO)\r\nThe International Organization for Standardization (ISO) is an independent, non-governmental\r\ninternational organization with a membership of 165 national standards bodies. Through its\r\nmembers, it brings together experts to share knowledge and develop voluntary, consensus-based,\r\nand market-relevant international standards that support innovation and provide solutions to\r\nglobal challenges. While the 27001/27002 standards are defined for IT systems and\r\nenvironments, they still have many applications to OT security. The most recent versions of each\r\nstandard were released in 2013.\r\nhttps://www.iso.org/home.html\r\nD.1.6.1. ISO 27001\r\nISO/IEC 27001 specifies the requirements for establishing, implementing, maintaining, and\r\ncontinually improving an information security management system within the context of the\r\norganization. It also includes requirements for the assessment and treatment of information\r\nsecurity risks tailored to the needs of the organization. The requirements set out in ISO/IEC\r\n27001 are generic and intended to be applicable to all organizations, regardless of type, size, or\r\nnature.\r\nhttps://www.iso.org/standard/54534.html\r\nD.1.6.2. ISO 27002:2022\r\nISO/IEC 27002:2022 gives guidelines for organizational information security standards and\r\ninformation security management practices, including the selection, implementation, and\r\nmanagement of controls while taking into consideration the organization’s information security\r\nrisk environment.\r\nhttps://www.iso.org/standard/75652.html\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n192\r\nD.1.7. National Council of Information Sharing and Analysis Centers (ISACs)\r\nFormed in 2003, the NCI is comprised of 25 organizations and is a coordinating body designed\r\nto maximize information flow across private-sector critical infrastructures and with government.\r\nInformation Sharing and Analysis Centers help critical infrastructure owners and operators\r\nprotect their facilities, personnel, and customers from cyber and physical security threats and\r\nother hazards. ISACs collect, analyze, and disseminate actionable threat information to their\r\nmembers and provide tools to mitigate risks and enhance resiliency. ISACs reach deep into their\r\nsectors, communicating critical information far and wide and maintaining sector-wide situational\r\nawareness.\r\nhttps://www.nationalisacs.org/member-isacs-3\r\nD.1.8. National Institute of Standards and Technology (NIST)\r\nNIST promotes U.S. innovation and industrial competitiveness by advancing measurement\r\nscience, standards, and technology in ways that enhance economic security and improve quality\r\nof life. From the smart electric power grid and electronic health records to atomic clocks,\r\nadvanced nanomaterials, and computer chips, innumerable products and services rely on NIST’s\r\ntechnology, measurements, and standards. NIST’s Information Technology Laboratory (ITL)\r\ndevelops and maintains an extensive collection of computer security standards, guidelines,\r\nrecommendations, and research, which are released through SPs and other reporting mediums.\r\nhttps://csrc.nist.gov/publications/\r\nD.1.8.1. NIST SP 800 Series Cybersecurity Guidelines\r\nThe NIST SP 800 series on information technology reports on the NIST ITL research, guidance,\r\nand outreach efforts in computer security and its collaborative activities with industry,\r\ngovernment, and academic organizations. Focus areas include cryptographic technology and\r\napplications, advanced authentication, public key infrastructure, internetworking security, criteria\r\nand assurance, and security management and support.\r\nhttps://csrc.nist.gov/publications/sp800\r\nIn addition to NIST SP 800-82, the following is an abbreviated list of additional 800 series\r\ndocuments that are broadly applicable to the OT security community:\r\n• NIST SP 800-30, Rev. 1, Guide for Conducting Risk Assessments\r\n• NIST SP 800-37, Rev. 2, Risk Management Framework for Information Systems and\r\nOrganizations: A System Life Cycle Approach for Security and Privacy\r\n• NIST SP 800-40, Rev. 4, Guide to Enterprise Patch Management Planning: Preventive\r\nMaintenance for Technology\r\n• NIST SP 800-50, Building an Information Technology Security Awareness and Training\r\nProgram\r\n• NIST SP 800-53, Rev. 5, Security and Privacy Controls for Information Systems and\r\nOrganizations\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n193\r\n• NIST SP 800-53A, Rev. 5, Assessing Security and Privacy Controls in Information\r\nSystems and Organizations\r\n• NIST SP 800-53B, Control Baselines for Information Systems and Organizations\r\n• NIST SP 800-70, Rev. 4, National Checklist Program for IT Products: Guidelines for\r\nChecklist Users and Developers\r\n• NIST SP 800-98, Guidelines for Securing Radio Frequency Identification (RFID)\r\nSystems\r\n• NIST SP 800-116, Rev. 1, Guidelines for the Use of PIV Credentials in Facility Access\r\n• NIST SP 800-123, Guide to General Server Security\r\n• NIST SP 800-124, Rev. 1, Guidelines for Managing the Security of Mobile Devices in the\r\nEnterprise\r\n• NIST SP 800-125, Guide to Security for Full Virtualization Technologies\r\n• NIST SP 800-137, Information Security Continuous Monitoring (ISCM) for Federal\r\nInformation Systems and Organizations\r\n• NIST SP 800-137A, Assessing Information Security Continuous Monitoring (ISCM)\r\nPrograms: Developing an ISCM Program Assessment\r\n• NIST SP 800-150, Guide to Cyber Threat Information Sharing\r\n• NIST SP 800-160 Vol. 1, Systems Security Engineering: Considerations for a\r\nMultidisciplinary Approach in the Engineering of Trustworthy Secure Systems\r\n• NIST SP 800-160 Vol. 2, Rev. 1, Developing Cyber-Resilient Systems: A Systems\r\nSecurity Engineering Approach\r\nD.1.8.2. NIST SP 1800 Series Cybersecurity Practice Guides\r\nNIST SP 1800 series presents practical and usable solutions for applying standards-based\r\ncybersecurity approaches and best practices in the real world. The guides are designed to help\r\norganizations gain efficiencies in implementing cybersecurity technologies while saving them\r\nresearch and proof-of-concept costs. An 1800 document can map capabilities to the\r\nCybersecurity Framework and outline the steps needed for another entity or organization to\r\nrecreate an example solution.\r\nhttps://csrc.nist.gov/publications/sp1800\r\nThe following 1800 series documents are applicable to the OT security community:\r\n• NIST SP 1800-2, Identity and Access Management for Electric Utilities\r\n• NIST SP 1800-7, Situational Awareness for Electric Utilities\r\n• NIST SP 1800-8, Securing Wireless Infusion Pumps in Healthcare Delivery\r\nOrganizations\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n194\r\n• NIST SP 1800-10, Protecting Information and System Integrity in Industrial Control\r\nSystem Environments: Cybersecurity for the Manufacturing Sector\r\n• NIST SP 1800-11, Data Integrity: Recovering from Ransomware and Other Destructive\r\nEvents\r\n• NIST SP 1800-23, Energy Sector Asset Management: For Electric Utilities, Oil \u0026 Gas\r\nIndustry\r\n• NIST SP 1800-24, Securing Picture Archiving and Communication System (PACS):\r\nCybersecurity for the Healthcare Sector\r\n• NIST SP 1800-25, Data Integrity: Identifying and Protecting Assets Against\r\nRansomware and Other Destructive Events\r\n• NIST SP 1800-26, Data Integrity: Detecting and Responding to Ransomware and Other\r\nDestructive Events\r\n• NIST SP 1800-27, Securing Property Management Systems\r\n• NIST SP 1800-30, Securing Telehealth Remote Patient Monitoring Ecosystem\r\n• NIST SP 1800-32, Securing Distributed Energy Resources: An Example of Industrial\r\nInternet of Things\r\nD.1.8.3. NIST Internal or Interagency Reports\r\nNIST IR series documents are reports on research findings, including background information\r\nfor FIPS and SPs.\r\nhttps://csrc.nist.gov/publications/ir\r\nThe following NIST IR documents are applicable to the OT security community:\r\n• NIST IR 7628, Rev. 1, Guidelines for Smart Grid Cybersecurity\r\n• NIST IR 8011 Vol. 1, Automation Support for Security Control Assessments: Volume 1:\r\nOverview\r\n• NIST IR 8011 Vol. 2, Automation Support for Security Control Assessments: Volume 2:\r\nHardware Asset Management\r\n• NIST IR 8011 Vol. 3, Automation Support for Security Control Assessments: Software\r\nAsset Management\r\n• NIST IR 8011 Vol. 4, Automation Support for Security Control Assessments: Software\r\nVulnerability Management\r\n• NIST IR 8170, Approaches for Federal Agencies to Use the Cybersecurity Framework\r\n• NIST IR 8183, Rev. 1, Cybersecurity Framework Version 1.1 Manufacturing Profile\r\n• NIST IR 8183A Vol. 1, Cybersecurity Framework Manufacturing Profile Low Impact\r\nLevel Example Implementations Guide: Volume 1 – General Implementation Guidance\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n195\r\n• NIST IR 8183A Vol. 2, Cybersecurity Framework Manufacturing Profile Low Impact\r\nLevel Example Implementations Guide: Volume 2 – Process-based Manufacturing\r\nSystem Use Case\r\n• NIST IR 8183A Vol. 3, Cybersecurity Framework Manufacturing Profile Low Impact\r\nLevel Example Implementations Guide: Volume 3 – Discrete-based Manufacturing\r\nSystem Use Case\r\n• NIST IR 8212, ISCMA: An Information Security Continuous Monitoring Program\r\nAssessment\r\n• NIST IR 8219, Securing Manufacturing Industrial Control Systems: Behavioral Anomaly\r\nDetection\r\nD.1.9. North American Electric Reliability Corporation (NERC)\r\nThe mission of the North American Electric Reliability Corporation (NERC) is to improve the\r\nreliability and security of the bulk power system in North America. To achieve that, NERC\r\ndevelops and enforces reliability standards; monitors the bulk power system; assesses future\r\nadequacy; audits owners, operators, and users for preparedness; and educates and trains industry\r\npersonnel. NERC is a self-regulatory organization that relies on the diverse and collective\r\nexpertise of industry participants. As the Electric Reliability Organization, NERC is subject to\r\naudit by the U.S. Federal Energy Regulatory Commission and governmental authorities in\r\nCanada.\r\nhttps://www.nerc.com\r\nD.1.9.4. NERC Critical Infrastructure Protection (CIP) Standards\r\nNERC has issued a set of cybersecurity standards to reduce the risk of compromise to electrical\r\ngeneration resources and high-voltage transmission systems above 100 kV, also referred to as\r\nbulk electric systems. Bulk electric systems include balancing authorities, reliability\r\ncoordinators, interchange authorities, transmission providers, transmission owners, transmission\r\noperators, generation owners, generation operators, and load serving entities. The cybersecurity\r\nstandards include audit measures and levels of non-compliance that can be tied to penalties.\r\nNERC currently maintains 12 Critical Infrastructure Protection (CIP) standards subject to\r\nenforcement with two additional standards that are filed and pending regulatory approval.\r\nhttps://www.nerc.com/pa/Stand/Pages/ReliabilityStandards.aspx\r\n• CIP-002, Cyber Security - BES Cyber System Categorization\r\n• CIP-003, Cyber Security - Security Management Controls\r\n• CIP-004, Cyber Security - Personnel \u0026 Training\r\n• CIP-005, Cyber Security - Electronic Security Perimeter(s)\r\n• CIP-006, Cyber Security - Physical Security of BES Cyber Systems\r\n• CIP-007, Cyber Security - System Security Management\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n196\r\n• CIP-008, Cyber Security - Incident Reporting and Response Planning\r\n• CIP-009, Cyber Security - Recovery Plans for BES Cyber Systems\r\n• CIP-010, Cyber Security - Configuration Change Management and Vulnerability\r\nAssessments\r\n• CIP-011, Cyber Security - Information Protection\r\n• CIP-013, Cyber Security - Supply Chain Risk Management\r\n• CIP-014, Cyber Security - Physical Security\r\nD.1.10. Operational Technology Cybersecurity Coalition\r\nThe Operational Technology Cybersecurity Coalition’s mission is to promote open, vendor-neutral, interoperable, standards-based cybersecurity solutions for OT.\r\nhttps://www.otcybercoalition.org/\r\nD.2. Research Initiatives and Programs\r\nD.2.1. Clean Energy Cybersecurity Accelerator Initiative\r\nThis initiative is led by the U.S. Department of Energy (DOE) and the National Renewable\r\nEnergy Laboratory (NREL) and brings together federal infrastructure and expertise, asset owners\r\nin the energy sector, and technology innovators in a unified effort to catalyze the development of\r\nnew cybersecurity solutions for the Nation’s future clean energy grid.\r\nThe Cybersecurity Accelerator program offers a world-class facility for asset owners of all sizes\r\nand types to work jointly to develop and deploy renewable, modern, and secure grid technologies\r\nthat are cost competitive. These innovative technologies will also advance the state of the\r\npractice in demonstrating “security by design,” thus ensuring that cybersecurity is built into\r\nrenewable technologies and architectures at the start of the design and development process, not\r\nbolted on after deployment.\r\nhttps://www.energy.gov/ceser/department-energy-clean-energy-accelerator-initiative\r\nD.2.2. Cybersecurity for Energy Delivery Systems (CEDS) R\u0026D Program\r\nThe Department of Energy (DOE) Cybersecurity, Energy Security, and Emergency Response\r\n(CESER) Office designed the CEDS R\u0026D program in 2010 to develop cybersecurity solutions\r\nfor energy delivery systems through a focused research and development effort. Since then, DOE\r\nCESER has invested more than $240 million with industry partners to make advances in\r\ncybersecurity capabilities for energy delivery systems. These research partnerships are helping to\r\ndetect, prevent, and mitigate the consequences of a cyber incident for current and future energy\r\ndelivery systems.\r\nhttps://www.energy.gov/ceser/activities/cybersecurity-critical-energy-infrastructure/cybersecurity-research-development-and\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n197\r\nD.2.3. Cybersecurity for the Operational Technology Environment (CyOTE)\r\nDOE CESER has partnered with the Idaho National Laboratory and energy companies on a\r\nresearch initiative to enhance energy-sector threat detection of anomalous behavior that\r\npotentially indicates malicious cyber activity in OT networks.\r\nhttps://inl.gov/cyote/\r\nD.2.4. Cybersecurity Risk Information Sharing Program (CRISP)\r\nThe Cybersecurity Risk Information Sharing Program (CRISP) is a public-private partnership\r\nthat is co-funded by DOE and industry and managed by the Electricity Information Sharing and\r\nAnalysis Center (E-ISAC) at NERC. The purpose of CRISP is to collaborate with energy-sector\r\npartners to facilitate the timely bidirectional sharing of unclassified and classified threat\r\ninformation and to develop situational awareness tools that enhance the sector’s ability to\r\nidentify, prioritize, and coordinate the protection of critical infrastructure and key resources.\r\nCRISP leverages DOE’s advanced sensors, threat analysis techniques, and expertise to better\r\ninform the energy sector of high-level cyber risks. This information is shared with voluntary\r\nutility participants who collectively deliver more than 80 % of the Nation’s electricity. The\r\nPacific Northwest National Laboratory (PNNL) plays a lead role at CRISP.\r\nhttps://www.energy.gov/sites/default/files/2021-12/CRISP%20Fact%20Sheet_508.pdf\r\nD.2.5. Cyber Testing for Resilient Industrial Control Systems (CyTRICS)\r\nDOE CESER has partnered with the Idaho National Laboratory and other stakeholders to\r\nidentify high-priority OT components, perform expert testing, share information about\r\nvulnerabilities in the digital supply chain, and inform improvements in component design and\r\nmanufacturing.\r\nhttps://inl.gov/cytrics/\r\nD.2.6. Homeland Security Information Network – Critical Infrastructure (HSIN-CI)\r\nThe Homeland Security Information Network (HSIN) is the trusted network for homeland\r\nsecurity mission operations to share Sensitive But Unclassified (SBU) information. The critical\r\ninfrastructure community on HSIN (HSIN-CI) is the primary system through which private-sector owners and operators, DHS, and other federal, state, and local government agencies\r\ncollaborate to protect the Nation’s critical infrastructure. HSIN-CI provides real-time\r\ncollaboration tools at no charge, including a virtual meeting space, document sharing, alerts, and\r\ninstant messaging.\r\nhttps://www.dhs.gov/hsin-critical-infrastructure\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n198\r\nD.2.7. INL Cyber-Informed Engineering (CIE) and Consequence-Driven CIE (CCE)\r\nThe DOE and the Idaho National Laboratory have developed a framework to guide the\r\napplication of cybersecurity principles across the engineering design life cycle. The Cyber-Informed Engineering (CIE) framework and body of knowledge drives the inclusion of\r\ncybersecurity as a foundational element of risk management for engineering functions that are\r\naided by digital technology. Consequence-Driven Cyber-Informed Engineering (CCE) is a\r\nrigorous process for applying CIE’s core principles to a specific organization, facility, or mission\r\nby identifying their most critical functions and methods, as well as the means by which an\r\nadversary would likely use to manipulate or compromise them, and determining the most\r\neffective means of removing or mitigating those risks.\r\nCIE emphasizes “engineering out” potential risk in key areas and ensuring resiliency and\r\nresponse maturity within the design of the engineered system. CCE walks an organization\r\nthrough core components of CIE in CCE’s 4-phase process to evaluate and remove or mitigate\r\nweaknesses in their critical functions.\r\nhttps://inl.gov/cie/\r\nD.2.8. Linking the Oil and Gas Industry to Improve Cybersecurity (LOGIIC)\r\nThe Linking the Oil and Gas Industry to Improve Cybersecurity (LOGIIC) program is a\r\ncollaboration of oil and natural gas companies and the U.S. Department of Homeland Security\r\nScience and Technology Directorate. LOGIIC undertakes collaborative research and\r\ndevelopment projects to improve the level of cybersecurity in critical systems of interest to the\r\noil and natural gas sector. The objective is to promote the cybersecurity of the sector while\r\nmaintaining impartiality, the independence of the participants, and vendor neutrality.\r\nThe Automation Federation serves as the LOGIIC host organization and has entered into\r\nagreements with LOGIIC member companies and all other LOGIIC project participants. The\r\nU.S. Department of Homeland Security Science and Technology Directorate previously\r\ncontracted with scientific research organization SRI International to provide scientific and\r\ntechnical guidance for LOGIIC.\r\nhttps://www.logiic.org/\r\nD.2.9. NIST Cyber-Physical Systems and Internet of Things Program\r\nThe definitions of cyber-physical systems (CPS) and IoT are converging over time to include a\r\ncommon emphasis on interacting digital, analog, physical, and human components in systems\r\nengineered for function through integrated physics and logic. CPS and IoT enable innovative\r\napplications in important economic sectors, such as smart cities, energy, manufacturing,\r\ntransportation, and emergency response. The CPS/IoT Program develops and demonstrates new\r\nmeasurement science and promotes the emergence of consensus standards and protocols for\r\nadvanced cyber-physical systems and IoT that are scalable, effective, measurable, interoperable,\r\ntrustworthy, and assured. The Engineering Laboratory’s Smart Grid and Cyber-Physical Systems\r\nProgram Office also provides leadership to support NIST-wide CPS/IoT program coordination\r\nwith the Information Technology, Communications Technology, and Physical Measurement\r\nLaboratories.\r\nhttps://www.nist.gov/programs-projects/cyber-physical-systems-and-internet-things-program\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n199\r\nD.2.10. NIST Cybersecurity for Smart Grid Systems Project\r\nSmart grid cybersecurity must address both inadvertent compromises of the electric\r\ninfrastructure due to user error, equipment failures, and natural disasters, as well as deliberate\r\nattacks, such as from disgruntled employees, industrial espionage, and terrorists. NIST will\r\naddress these challenges through research conducted in the NIST Smart Grid Testbed facility and\r\nleadership within the Smart Electric Power Alliance (SEPA) Cybersecurity Committee (SGCC)\r\nto evaluate cybersecurity policies and measures in industry standards and develop relevant\r\nguidance documents for the smart grid cybersecurity community. The primary goal is to develop\r\na cybersecurity risk management strategy for the smart grid to enable secure interoperability of\r\nsolutions across different domains and components. The Cybersecurity for Smart Grid Systems\r\nProject is moving forward to address critical cybersecurity needs by promoting the technology\r\ntransfer of best practices, standards, voluntary guidance, and research in the areas of applied\r\ncryptography and cybersecurity for microgrids. This project will provide foundational\r\ncybersecurity guidance, cybersecurity reviews and recommendations for standards and\r\nrequirements, outreach, and collaborations in the cross-cutting issue of cybersecurity in the smart\r\ngrid.\r\nhttps://www.nist.gov/programs-projects/cybersecurity-smart-grid-systems\r\nD.2.11. NIST Cybersecurity for Smart Manufacturing Systems Project\r\nThe Cybersecurity for Smart Manufacturing Systems project develops cybersecurity\r\nimplementation methods, metrics, and tools to enable manufacturers to implement cybersecurity\r\ncapabilities in smart manufacturing systems while addressing the demanding performance,\r\nreliability, and safety requirements of these systems.\r\nhttps://www.nist.gov/programs-projects/cybersecurity-smart-manufacturing-systems\r\nD.2.12. NIST Reliable, High Performance Wireless Systems for Factory\r\nAutomation\r\nThe Reliable, High Performance Wireless Systems for Factory Automation project develops\r\nrobust requirements, system models, recommended architectures, and guidelines for the\r\nintegration of trustworthy wireless systems within a factory workcell where wireless is the\r\nprimary mode of communication enabling robot mobility and ease of installation of edge\r\ndevices.\r\nhttps://www.nist.gov/programs-projects/reliable-high-performance-wireless-systems-factory-automation\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n200\r\nD.2.13. NIST Prognostics and Health Management for Reliable Operations in\r\nSmart Manufacturing (PHM4SM)\r\nThe NIST Prognostics and Health Management for Reliable Operations in Smart Manufacturing\r\n(PHM4SM) project develops and deploys measurement science to promote the implementation,\r\nverification, and validation of advanced monitoring, diagnostic, and prognostic technologies to\r\nincrease reliability and decrease downtime in smart manufacturing systems.\r\nhttps://www.nist.gov/programs-projects/prognostics-and-health-management-reliable-operations-smart-manufacturing-phm4sm\r\nD.2.14. NIST Supply Chain Traceability for Agri-Food Manufacturing\r\nThe NIST Supply Chain Traceability for Agri-Food Manufacturing project develops and deploys\r\nnew standards, tools, and guidelines for traceability and cybersecurity that increase trust among\r\nparticipants and customers of agri-food manufacturing supply chains.\r\nhttps://www.nist.gov/programs-projects/supply-chain-traceability-agri-food-manufacturing\r\nD.3. Tools and Training\r\nD.3.1. CISA Cyber Security Evaluation Tool (CSET®)\r\nCISA’s Cyber Security Evaluation Tool (CSET®) provides a systematic, disciplined, and\r\nrepeatable approach for evaluating an organization’s security posture. CSET is a desktop\r\nsoftware tool that guides asset owners and operators through a step-by-step process to evaluate\r\nICS and IT network security practices. Users can evaluate their own cybersecurity stance using\r\nmany recognized government and industry standards and recommendations.\r\nhttps://github.com/cisagov/cset/releases\r\nD.3.2. CISA Cybersecurity Framework Guidance\r\nSector-specific guidance has been completed by all six critical infrastructure sectors for which\r\nthe Department of Homeland Security’s Office of Infrastructure Protection is the Sector-Specific\r\nAgency (SSA): Chemical, Commercial Facilities, Critical Manufacturing, Dams, Emergency\r\nServices, and Nuclear. Guidance is developed in close collaboration with the SSA alongside the\r\nSector Coordinating Councils (SCC) and Government Coordinating Councils (GCC) to provide a\r\nholistic view of a sector’s cybersecurity risk environment.\r\nhttps://www.cisa.gov/resources-tools/resources/chemical-sector-cybersecurity-framework-implementation-guidance\r\nhttps://www.cisa.gov/resources-tools/resources/commercial-facilities-sector-cybersecurity-framework-implementation\r\nhttps://www.cisa.gov/resources-tools/resources/critical-manufacturing-sector-cybersecurity-framework-implementation\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n201\r\nhttps://www.cisa.gov/resources-tools/resources/dams-sector-cybersecurity-framework-implementation-guidance-2020\r\nhttps://www.cisa.gov/resources-tools/resources/emergency-services-sector-cybersecurity-framework-implementation-guidance\r\nhttps://www.cisa.gov/resources-tools/resources/nuclear-sector-cybersecurity-framework-implementation-guidance\r\nD.3.3. CISA ICS Alerts, Advisories, and Reports\r\nCISA Alert is intended to provide timely notification to critical infrastructure owners and\r\noperators concerning threats or activities with the potential to impact critical infrastructure\r\ncomputing networks.\r\nAdvisories provide timely information about current security issues, vulnerabilities, and exploits.\r\nCISA maintains a list of ICS-related Technical Information Papers (TIPs), Annual Reports (Year\r\nin Review), and third-party products that it considers to be of interest to persons engaged in\r\nprotecting ICS.\r\nhttps://www.cisa.gov/topics/industrial-control-systems\r\nD.3.4. CISA ICS Training Courses\r\nCISA offers both self-paced virtual online training courses via a virtual learning portal as well as\r\ninstructor-led classes provided at various venues. All CISA training courses are presented with\r\nno tuition cost to the attendee.\r\nhttps://www.cisa.gov/uscert/ics/Training-Available-Through-CISA\r\nD.3.5. MITRE ATT\u0026CK for ICS\r\nMITRE ATT\u0026CK for ICS is a curated knowledge base for cyber adversary behavior in the ICS\r\ntechnology domain. It reflects the various phases of an adversary’s attack life cycle and the\r\nassets and systems they are known to target. ATT\u0026CK for ICS originated from MITRE internal\r\nresearch focused on applying the ATT\u0026CK methodology to the ICS technology domain.\r\nhttps://attack.mitre.org/techniques/ics/\r\n \r\nD.3.6. NIST Cybersecurity Framework\r\nRecognizing that the national and economic security of the United States depends on the reliable\r\nfunctioning of critical infrastructure, the President issued Executive Order 13636, Improving\r\nCritical Infrastructure Cybersecurity, in February 2013 [EO13636]. It directed NIST to work\r\nwith stakeholders to develop a voluntary framework for reducing cyber risks to critical\r\ninfrastructure based on existing standards, guidelines, and practices.\r\nNIST released the first version of the Framework for Improving Critical Infrastructure\r\nCybersecurity on February 12, 2014. The Framework was created through collaboration between\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n202\r\nindustry and government and consists of standards, guidelines, and practices to promote the\r\nprotection of critical infrastructure. The prioritized, flexible, repeatable, and cost-effective\r\napproach of the Framework helps owners and operators of critical infrastructure to manage\r\ncybersecurity-related risk.\r\nIn April of 2018, NIST published Version 1.1 of the Framework for Improving Critical\r\nInfrastructure Cybersecurity. Edits were driven by dialogue with over 1200 participants at the\r\n2016 and 2017 annual framework workshops in addition to over 200 written comments regarding\r\ndraft publications.\r\nhttps://www.nist.gov/cyberframework/framework\r\nD.3.7. SANS ICS Security Courses\r\nSANS offers several courses that provide hands-on training focused on the cybersecurity of OT\r\nenvironments. These courses equip both security professionals and control system engineers with\r\nthe knowledge and skills that they need to safeguard critical infrastructure.\r\nhttps://www.sans.org/industrial-control-systems-security/\r\nCurrent course offerings and their corresponding certifications are listed below:\r\n• ICS410: ICS/SCADA Security Essentials, Global Industrial Cyber Security Professional\r\n(GICSP)\r\n• ICS456: Essentials for NERC CIP, GIAC Critical Infrastructure Protection (GCIP)\r\n• ICS515: ICS Visibility Detection, and Response, GIAC Response and Industrial Defense\r\n(GRID)\r\nD.4. Sector-Specific Resources\r\nD.4.1. Chemical\r\n• Chemical Facility Anti-Terrorism Standards (CFATS) – https://www.cisa.gov/chemical-facility-anti-terrorism-standards\r\n• ChemLock – https://www.cisa.gov/chemlock\r\n• American Chemistry Council (ACC) – https://www.americanchemistry.com\r\n• American Petroleum Institute (API) – https://www.api.org\r\n• American Gas Association (AGA) – https://www.aga.org\r\n• American Fuel and Petrochemical Manufacturers (AFPM) – https://www.afpm.org\r\n• Society of Chemical Manufacturers and Affiliates (SOCMA) – https://www.socma.org\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n203\r\nD.4.2. Communications\r\n• Federal Communications Commission (FCC) – https://www.fcc.gov\r\no Cybersecurity and Communications Reliability Division\r\no Communications Security, Reliability, and Interoperability Council (CSRIC)\r\nD.4.3. Critical Manufacturing\r\n• National Association of Manufacturers (NAM) – https://www.nam.org\r\no NAM Cyber Cover\r\n• Association for Advancing Automation (A3) – https://www.automate.org\r\n• Measurement, Control \u0026 Automation Association (MCAA) – https://www.themcaa.org\r\n• International Association for Automation and Robotics in Construction (IAARC) –\r\nhttps://www.iaarc.org\r\n• ODVA – https://www.odva.org\r\nD.4.4. Dams\r\n• Association of State Dam Safety Officials (ASDSO) – http://www.damsafety.org\r\nD.4.5. Energy\r\n• U.S. Department of Energy (DOE) – https://www.energy.gov\r\no The Office of Cybersecurity, Energy Security, and Emergency Response\r\n(CESER)\r\n• International Council on Large Electric Systems (CIGRE) – https://www.cigre.org\r\n• American Public Power Association (APPA) – https://www.publicpower.org\r\no Cybersecurity Defense Community (CDC)\r\n• Electric Power Research Institute (EPRI) – https://www.epri.com\r\no National Electric Sector Cybersecurity Resource (NESCOR)\r\nD.4.6. Food and Agriculture\r\n• U.S. Department of Agriculture (USDA) – https://www.usda.gov\r\n• U.S. Food and Drug Administration (FDA) – https://www.fda.gov\r\n• National Farmers Union (NFU) – https://www.nfu.org\r\no Farm Crisis Center\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n204\r\nD.4.7. Healthcare and Public Health\r\n• U.S. Food and Drug Administration (FDA) – https://www.fda.gov\r\no Digital Health Center of Excellence\r\n• Department of Health and Human Services (HHS) – https://www.hhs.gov\r\no Health Sector Cybersecurity Coordination Center (HC3)\r\n• American Hospital Association (AHA) – https://www.aha.org/\r\no AHA Preferred Cybersecurity Provider (APCP) Program\r\n• National Institutes of Health (NIH) – https://www.nih.gov\r\no NIH Information Technology Acquisition and Assessment Center (NITAAC)\r\n• American Medical Association (AMA) – https://www.ama-assn.org\r\nD.4.8. Nuclear Reactors, Materials, and Waste\r\n• U.S. Nuclear Regulatory Commission (NRC) – https://www.nrc.gov\r\no Office of Nuclear Security and Incident Response Cyber Security Branch (CSB)\r\n• International Atomic Energy Agency (IAEA) – https://www.iaea.org\r\n• Nuclear Energy Agency (NEA) – https://www.oecd-nea.org\r\no Digital Instrumentation and Control Working Group (DICWG)\r\n• Nuclear Energy Institute (NEI) – https://www.nei.org\r\n• World Institute of Nuclear Security (WINS) – https://www.wins.org\r\nD.4.9. Transportation Systems\r\n• U.S. Department of Transportation (DOT) – https://www.transportation.gov\r\no Intelligent Transportation Systems Joint Program Office\r\n• Federal Aviation Administration (FAA) – https://www.faa.gov\r\no Aviation Cyber Initiative (ACI)\r\no Air Traffic Organization (ATO) Cybersecurity Group\r\n• Federal Highway Administration (FHWA) – https://highways.dot.gov\r\no FHWA Office of Operations Research, Development, and Technology\r\n• Federal Motor Carrier Safety Administration (FMCSA) – https://www.fmcsa.dot.gov\r\n• Federal Railroad Administration (FRA) – https://railroads.dot.gov\r\no FRA Office of Research, Development, and Technology\r\n• Federal Transit Administration (FTA) – https://www.transit.dot.gov\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n205\r\n• Maritime Administration (MARAD) – https://www.maritime.dot.gov\r\no Office of Maritime Security\r\n• Pipeline and Hazardous Materials Safety Administration (PHMSA) –\r\nhttps://www.phmsa.dot.gov\r\n• National Highway Traffic Safety Administration (NHTSA) – https://www.nhtsa.gov\r\n• Transportation Security Administration (TSA) – https://www.tsa.gov/for-industry\r\no Surface Transportation Cybersecurity Resource Toolkit\r\n• Association of American Railroads – https://www.aar.org\r\nD.4.10. Water and Wastewater\r\n• U.S. Environmental Protection Agency (EPA) – https://www.epa.gov\r\no Drinking Water and Wastewater Resilience\r\n• American Water Works Association (AWWA) – https://www.awwa.org\r\no AWWA Cybersecurity Tool\r\n• Association of Metropolitan Water Agencies (AMWA) – https://www.amwa.net\r\n• National Association of Water Companies (NAWC) – https://www.nawc.org\r\nD.5. Conferences and Working Groups\r\nD.5.1. Digital Bond’s SCADA Security Scientific Symposium (S4)\r\nSince 2007, S4 has hosted an ICS security conference that was initially founded to showcase\r\nadvanced and highly technical content to the ICS audience. S4 has since grown to accommodate\r\nother ICS security content but remains a premier venue to present technical findings within OT\r\nsecurity.\r\nhttps://s4xevents.com/\r\nD.5.2. Industrial Control Systems Joint Working Group (ICSJWG)\r\nCISA hosts a bi-annual working group to facilitate communication and partnerships between\r\nfederal agencies and departments and private asset owners and operators of industrial control\r\nsystems across all critical infrastructure (CI) sectors. The goal of the ICSJWG is to enhance the\r\ncollaborative efforts of the industrial control systems stakeholder community in securing CI by\r\naccelerating the design, development, and deployment of secure industrial control systems.\r\nhttps://www.cisa.gov/resources-tools/groups/industrial-control-systems-joint-working-group-icsjwg\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n206\r\nD.5.3. IFIP Working Group 11.10 on Critical Infrastructure Protection\r\nThe International Federation for Information Processing (IFIP) Working Group 11.10 is an\r\nactive international community of scientists, engineers, and practitioners dedicated to advancing\r\nstate-of-the-art of research and practices in the emerging field of critical infrastructure\r\nprotection.\r\nhttp://ifip1110.org/Conferences/\r\nD.5.4. SecurityWeek’s ICS Cyber Security Conference\r\nSince 2002, SecurityWeek has held an annual conference focused on cybersecurity for the\r\nindustrial control systems sector where ICS users, vendors, system security providers, and\r\ngovernment representatives can meet to discuss the latest cyber incidents, analyze their causes,\r\nand cooperate on solutions.\r\nhttps://www.icscybersecurityconference.com/\r\nD.5.5. Stockholm International Summit on Cyber Security in SCADA and ICS\r\n(CS3STHLM)\r\nOrganized in 2014, CS3STHLM has quickly become the premier ICS Security Summit in\r\nNorthern Europe. CS3STHLM is a summit that offers generous time for lectures, networking,\r\nand knowledge sharing with regard to today’s ICS security challenges.\r\nhttps://cs3sthlm.se/\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n207\r\nAppendix E. OT Security Capabilities and Tools\r\nThis appendix provides an overview of key security technologies that are available to or being\r\ndeveloped to support the OT community. There are several security products that are marketed\r\nspecifically for OT, while others are general IT security products that are also applicable to OT.\r\nMany cybersecurity products are marketed as a single platform that combines the capabilities\r\nand tools listed here. Each organization should make a risk-based determination on whether to\r\nemploy the security technologies and tools mentioned in this appendix.\r\nE.1. Network Segmentation and Isolation\r\nNetwork segmentation and separation technologies allow OT network owners to implement\r\ncybersecurity strategies that isolate devices and network traffic by both physical and logical\r\nmeans. Popular tooling for this capability area is described below.\r\nE.1.1. Firewalls\r\nFirewalls can be used to logically enforce user-defined rule sets on network traffic. Commonly\r\nplaced at network boundaries, firewalls can limit both incoming and outgoing traffic based on a\r\nvariety of data characteristics.\r\nThere are several types of general IT firewalls. Basic packet filtering firewalls directly inspect\r\ncurrent network traffic at OSI Layers 3 and 4 to inform decisions on whether to drop or forward\r\npackets to their destination. Conversely, stateful inspection firewalls draw upon the memory of\r\nboth past and present network connections when making filtering decisions, thereby offering\r\nmore capabilities at an increased computational cost. Next generation firewalls (NGFWs) expand\r\nupon stateful inspection firewalls by adding features such as application filtering, deep packet\r\ninspection, VPN traffic awareness, adaptive rules, and threat detection.\r\nSeveral vendors also offer OT-specific firewalls with unique feature sets. For example, they\r\noften provide built-in parsers for common OT protocols, such as DNP3, CIP, and Modbus,\r\nallowing for deep packet inspection of OT traffic.\r\nE.1.2. Unidirectional Gateways\r\nUnidirectional gateways, also referred to as data diodes, are designed to only allow data\r\ntransmission in a single direction. Unlike a firewall, data diodes cannot be programmed to allow\r\ndata to flow in both directions because the hardware is incapable. A common use case is placing\r\na data diode at the boundary between the operational network and the enterprise network. The\r\ndata diode would allow network traffic to leave the operational network but not enter, preventing\r\na potential avenue of cyber attack.\r\nE.1.3. Virtual Local Area Networks (VLANs)\r\nA VLAN can be used to logically separate areas within a network when physical separation may\r\nnot be feasible due to cost or other prohibitive measures. VLANs are implemented on modern\r\nnetwork switching equipment that logically separates network traffic based on switch ports. For\r\nexample, an 8-port switch can be configured to separate traffic into two VLANs. One VLAN\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n208\r\nwould be provided for ports 1-4, while another would be provided for ports 5-8. While all eight\r\nports are physically connected to a single device, each port is only logically connected to the\r\nother ports within its VLAN.\r\nE.1.4. Software-Defined Networking (SDN)\r\nTraditional networking switches are responsible for both forwarding packets (data plane) and\r\nrunning the distributed algorithms that determine routing (control plane). SDN is a technology\r\nthat evolves this concept by keeping the data plane at the switch and moving the control plane to\r\na centralized controller. The centralized controller acts as an abstraction layer for network\r\nprogrammability, eliminating the need to individually manage each switch within the network.\r\nSDN allows for easy dynamic reconfiguration of the data plane, which can in turn allow for the\r\nquick isolation of devices or redirection and duplication of traffic for monitoring and data\r\ncapture. Utilizing SDN technology within an OT environment gives asset owners greater\r\nflexibility when initially designing their network architectures and when updating them in the\r\nfuture.\r\nE.2. Network Monitoring – Security Information and Event Management (SIEM)\r\nNetwork monitoring technologies allow OT network owners to maintain situational awareness of\r\ntheir controlled processes and support cybersecurity objectives, such as event or anomaly\r\ndetection. OT vendors often market their network monitoring technology as being capable of\r\nintegrating with SIEM technologies. These systems collect data through log aggregation and\r\nnetwork scanning tools, detect threats through analytics, and can provide automated incident\r\nresponse. Capabilities continue to be added, including the use of ML and AI to improve\r\ndetection and reduce unnecessary alerts. OT owners must exercise caution when implementing\r\nthese technologies as they can directly impact the availability of the controlled process.\r\nE.2.1. Centralized Logging\r\nSystem and network logs from all sources in an environment are the foundation of SIEM. Logs\r\nact as the primary historical artifact for incident response. When aggregated at a central location,\r\nlogs can be analyzed together to provide a holistic view of the network state. A SIEM will utilize\r\na variety of sensors strategically placed within a target network to collect logs from endpoints\r\nand network traffic information, which are then stored in a database for real-time analysis.\r\nSpecific to OT networks, data historians can serve as a supplemental source of event data to\r\nprovide greater context surrounding a cyber incident.\r\nE.2.2. Passive Scanning\r\nPassive network scans are a form of network discovery that inspects existing network traffic by\r\nwatching traffic passing through network switches or other dedicated network capture devices.\r\nSystems that implement passive network scans do not introduce any additional traffic to the\r\nnetwork, which is ideal for sensitive devices found on OT networks that may exhibit unexpected\r\nbehavior when directly probed. Passive scanning can identify all of the devices that are actively\r\ncommunicating on monitored network segments. Through the inspection of network data,\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n209\r\npassive scanning can identify significant amounts of information about devices, potentially\r\nincluding manufacturers, part numbers, and firmware versions. Passive scanning cannot identify\r\ndevices that are not actively communicating, nor can it inspect encrypted traffic (without special\r\nprovisioning). Additionally, a passive scan will often take days to complete due to its\r\ndependence on existing network traffic.\r\nE.2.3. Active Scanning\r\nActive network scans are a form of network discovery that directly probe the network for\r\nattached devices. Systems that employ active scanning introduce traffic to the network and will\r\ndirectly interact with the devices within the scan’s scope. OT network owners should exercise\r\nextreme caution when permitting active scanning on an operational network due to device\r\nsensitivity on the target network. Active scans may cause device instability or interfere with the\r\ndevice process state, potentially impacting safety and integrity. Active scans should be scheduled\r\nto occur during planned OT outages whenever possible.\r\nSome OT-specific scanning devices combine passive and active scanning to enable a safer\r\nversion of active scanning. Safe active scanning first learns about connected equipment through\r\npassive means and then uses device-specific communication to actively gain additional\r\ninformation about connected equipment without risk to OT operations.\r\n \r\nE.2.4. Malware Detection\r\nEndpoint malware detection can be bolstered with antivirus software. Antivirus software\r\nmonitors activity on the host device and alerts the user to possible malicious activities. Older\r\ndetection techniques rely on file signatures to detect known threats. Over time, malware\r\ndevelopers have found ways to bypass this mechanism, such as with polymorphic code. Modern\r\nantivirus software uses behavioral analysis of running processes and advanced file analysis to\r\ndetect potentially malicious activity.\r\nHost-based malware detection with antivirus software may not be advisable for some OT\r\nendpoints due to OS incompatibility, software incompatibility, or runtime requirements.\r\nHowever, network-based malware detection can still be utilized. Unlike host-based antivirus\r\nsoftware, network-based malware detection runs on an independent system that aggregates and\r\ninspects network traffic for anomalies. Network-based malware detection offers similar\r\ncapabilities to host-based detection without the computational overhead being placed on the\r\ndefended component. Network-based detection is a primary component of SIEM packages.\r\nE.2.5. Behavioral Anomaly Detection\r\nBehavioral anomaly detection (BAD) systems compare the current state of an environment with\r\na baseline to detect abnormal activity for further investigation. This could be unusual network\r\ntraffic, such as large amounts of data being transferred, new ports or protocols, or new\r\nconnections between devices. Unusual activity on an endpoint may include excessive processor\r\nusage, logins outside of work hours, or new processes. The detectable events are dependent on\r\nthe sensor capabilities of the specific implementation. Some BAD systems utilize AI and ML\r\nalgorithms to automatically update the baseline model. By automating this process, the BAD\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n210\r\nsystem can maintain knowledge of normal activity even as the environment evolves over time.\r\nThis ultimately reduces false positive detections and improves incident response capabilities.\r\nE.2.6. Data Loss Prevention (DLP)\r\nDLP is a collection of tools built to improve the confidentiality of sensitive data on a network.\r\nDLP is often marketed as a feature set within SIEM that actively monitors both data at rest to\r\nprevent unauthorized access and data in transit to prevent unauthorized extraction. Even if DLP\r\nis unable to prevent the data loss, it can still alert the organization to a breach.\r\nE.2.7. Deception Technology\r\nA deception technology uses decoy data and/or devices placed across the network to lure\r\nattackers away from legitimate assets. Decoys can range from access credentials and files to\r\ncomplete endpoints. When a threat actor interacts with a decoy, it triggers an alarm to alert cyber\r\ndefenders to its presence. Defenders can then choose to further monitor the adversary for\r\nintelligence or immediately mitigate the threat. Because decoys do not actively interact with\r\nother network components, deception technologies can support malicious activity monitoring\r\nand detection without jeopardizing the controlled process.\r\nE.2.8. Digital Twins\r\nA digital twin is a digital replica of a physical system or component that can be deployed within\r\nOT environments as a tool for anomaly detection. The digital twin utilizes real-time sensor\r\ninputs and compares them using heuristics and algorithms (including ML) against a baseline\r\nmodel. Operational anomalies detected by digital twins most often indicate a maintenance or\r\nfailure situation. However, a detected operational anomaly could indicate an advanced cyber\r\nattack that has bypassed other security mechanisms and would otherwise have gone undetected.\r\nE.3. Data Security\r\nVarious data security technologies assist information owners in protecting the confidentiality,\r\nintegrity, and availability of their data. OT network owners are encouraged to identify the critical\r\nfiles and data that reside in their networks and implement data security technologies to mitigate\r\nrisk.\r\nE.3.1. Backup Storage\r\nBackup storage is an alternative file storage location where copies of critical files are stored and\r\nprotected to assist with recovery should the originals be lost, compromised, or unusable. Using\r\nbackup tools and procedures is fundamental to ensuring the availability of critical data within an\r\nOT network environment. Based on risk, backup plans should specify which files require\r\nbackup, how often they should be backed up, the number of copies to be made, the location of\r\nthe backup (e.g., offline, off-site) and how long backup copies should be kept. Various solutions\r\nexist to automate backup storage of critical data on a regular basis.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n211\r\nE.3.2. Immutable Storage\r\nImmutable storage is a special type of backup storage that provides additional data integrity\r\nthrough data storage in a read-only format. Immutable storage can be used to store backups of\r\nprograms or device configurations. It can also be used as a read-only drive in a maintenance\r\nworkstation for added protection against the installation of new software.\r\nE.3.3. File Hashing\r\nThe integrity of critical files such as program logic can be validated by using hashes. A hashing\r\nalgorithm calculates a fixed-size string from a file’s contents. If a hash is calculated and stored\r\nfor a critical file when it is first created, the integrity of the file can be checked later by\r\ncalculating the hash again. For example, if an end user needs to restore functionality to a device\r\nby returning it to a baseline, the integrity of the baseline files can first be validated by\r\nrecomputing the file hash. If a different hash is calculated for a target file, the data owner can\r\nassume that the backup files have been compromised. Many data backup software systems\r\ninclude hashing within their feature set. NIST-approved hash algorithms are specified in FIPS\r\n180-4, Secure Hash Standard , and FIPS 202, [FIPS180] SHA-3 Standard [FIPS202].\r\nE.3.4. Digital Signatures\r\nDigital signatures are an additional data integrity measure. They are the electronic analogue of a\r\nwritten signature and provide assurance that the claimed signatory signed the information and\r\nthat the information was not modified following signature. FIPS 186-4, Digital Signature\r\nStandard (DSS) , specifies three NIST-approved digital signature algorithms: DSA,\r\nRSA, and ECDSA.\r\n[FIPS186]\r\nE.3.5. Block Ciphers\r\nAsset owners can protect the confidentiality of data at rest using block ciphers. Block ciphers are\r\nalgorithms that encrypt data in block-sized chunks rather than one bit at a time. This is beneficial\r\nwhen encrypting large amounts of data at once. NIST-approved block ciphers are the Advanced\r\nEncryption Standard (AES) and Triple Data Encryption Standard (DES). AES is specified in\r\nFIPS 197, Advanced Encryption Standard [FIPS197]. Triple DES is specified in NIST SP 800-\r\n67, Rev. 2, Recommendation for the Triple Data Encryption Algorithm Block Cipher [SP800-\r\n67r2].\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n212\r\nE.3.6. Remote Access\r\nSecurity controls should be implemented to prevent unauthorized remote access to an\r\norganization’s networks, systems, and data. A virtual private network (VPN) is a set of\r\ntechnologies and protocols designed to support secure remote access to network environments. A\r\nVPN can provide both strong authentication and encryption to secure communication data by\r\nestablishing a private network that operates as an overlay on a public infrastructure. The most\r\ncommon types of VPN technologies are:\r\n• Internet Protocol Security (IPsec). IPsec supports two encryption modes: transport and\r\ntunnel. Transport mode encrypts only the data portion (payload) of each packet while\r\nleaving the packet header untouched. The more secure tunnel mode adds a new header to\r\neach packet and encrypts both the original header and the payload. On the receiving side,\r\nan IPsec-compliant device decrypts each packet. See NIST SP 800-77, Rev. 1, Guide to\r\nIPsec VPNs for more information.\r\n• Transport Layer Security (TLS). Sometimes referred to by the legacy terminology of\r\nSecure Sockets Layer (SSL), TLS provides a secure channel between two machines that\r\nencrypts the contents of each packet. TLS is most often recognized for securing HTTP\r\ntraffic in a protocol implementation known as HTTP Secure (HTTPS). However, TLS is\r\nnot limited to HTTP traffic and can be used to secure many application-layer programs.\r\nFor more information, see NIST SP 800-52, Rev. 2, Guidelines for the Selection,\r\nConfiguration, and Use of Transport Layer Security (TLS) Implementations.\r\n• Secure Shell (SSH). SSH is a command interface and protocol for securely gaining\r\naccess to a remote computer. It is widely used by network administrators to remotely\r\ncontrol Linux-based servers. SSH is a secure alternative to a telnet application, is\r\nincluded in most UNIX distributions, and is typically added to other platforms through a\r\nthird-party package.\r\nWhen implemented with diligence, remote access technologies can improve an organization’s\r\ncapabilities. There are several options for remote access and desktop control, including the\r\nRemote Desktop Protocol (RDP), screens, and other stand-alone packages. If remote\r\ntechnologies are not managed properly using vulnerability and patch management, these\r\nconnections can serve as another channel for an adversary to exploit.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n213\r\nAppendix F. OT Overlay\r\nNote to Readers\r\nThe OT overlay is a partial tailoring of the controls and control baselines\r\nin NIST SP 800-53, Rev. 5 and adds supplementary guidance specific to\r\nOT. The concept of overlays is discussed in Appendix C of NIST SP\r\n800-53B. The OT overlay is intended to be applicable to all OT systems\r\nin all industrial sectors. Further tailoring can add specificity to a\r\nparticular sector (e.g., pipeline, energy). Ultimately, an overlay may be\r\nproduced for a specific system (e.g., the XYZ company).\r\nThis OT overlay constitutes supplemental guidance and tailoring for\r\nNIST SP 800-53, Rev. 5. Duplicating Appendix F of NIST SP 800-53\r\nwould increase the size of this publication significantly, so it is not\r\nincluded here.\r\nThe authoring team also considered that this OT overlay may serve as a\r\nmodel for other overlays. Feedback on this appendix’s structure would\r\nbe appreciated, especially on the level of abstraction and whether the\r\nexamples provided in the supplemental guidance are sufficient and\r\nbeneficial for implementation.\r\nOverlays provide a structured approach to help organizations tailor control baselines and develop\r\nspecialized security plans that can be applied to specific mission and business functions,\r\nenvironments of operation, and/or technologies. This specialization approach is important as the\r\nnumber of threat-driven controls and control enhancements in the catalog increases and\r\norganizations develop risk management strategies to address their specific protection needs\r\nwithin defined risk tolerances.\r\nA repository of overlays may be found at https://csrc.nist.gov/Projects/risk-management/sp800-\r\n53-controls/overlay-repository. This overlay may be referenced as the NIST SP 800-82, Rev. 3\r\nOperational Technology Overlay (“NIST SP 800-82 Rev 3 OT Overlay”). It is based on NIST SP\r\n800-53, Rev. 5 [SP800-53r5].\r\nNIST developed this overlay in furtherance of its statutory responsibilities under the Federal\r\nInformation Security Modernization Act (FISMA) of 2014 (Public Law 113-283) [FISMA],\r\nPresidential Policy Directive 21 (PPD-21) [PPD-21], and Executive Order 13636 [EO13636].\r\nNIST is responsible for developing standards and guidelines, including minimum requirements,\r\nfor providing adequate information security for all agency operations and assets, but such\r\nstandards and guidelines shall not apply to national security systems without the express\r\napproval of appropriate federal officials exercising policy authority over such systems.\r\nF.1. Overlay Characteristics\r\nOT encompasses a broad range of programmable systems and devices that interact with the\r\nphysical environment (or manage devices that interact with the physical environment). These\r\nsystems and devices detect or cause a direct change through the monitoring and/or control of\r\ndevices, processes, and events. Examples include industrial control systems, building automation\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n214\r\nsystems, transportation systems, physical access control systems, physical environment\r\nmonitoring systems, and physical environment measurement systems.\r\nICS consists of combinations of control components (e.g., electrical, mechanical, hydraulic,\r\npneumatic) that act together to achieve an objective (e.g., manufacturing, transportation of matter\r\nor energy). The part of the system primarily concerned with producing an output is referred to as\r\nthe process. The control part of the system includes the specification of the desired output or\r\nperformance. Control can be fully automated or may include a human in the loop.\r\nSection 2 provides an overview of various OT systems, such as SCADA, DCS, PLCs, BASs,\r\nPACSs, and IIoT.\r\nF.2. Applicability\r\nThe purpose of this overlay is to provide guidance for securing OT systems. This overlay has\r\nbeen prepared for use by federal agencies. It may be used by non-governmental organizations on\r\na voluntary basis.\r\nPrivacy is a risk consideration for OT systems. For additional guidance, refer to the NIST\r\nPrivacy Framework [PF]. The application of privacy in OT will depend on sector and\r\norganizational risks, so controls that are exclusively related to privacy have not been included in\r\nthis OT overlay. Each organization will need to independently determine applicability. All\r\ncontrols and control enhancements that only appear in the privacy baseline have been removed\r\nfrom this OT overlay according to this rationale.\r\nF.3. Overlay Summary\r\nTable 22 provides a summary of the controls and control enhancements from NIST SP 800-53,\r\nRev. 5, Appendix F [SP800-53r5] that have been allocated to the initial control baselines (i.e.,\r\nLow, Moderate, and High) along with indications of OT discussion and OT tailoring. The table\r\nuses the following conventions:\r\n• Bold indicates controls and control enhancements with OT discussions.\r\n• Underline indicates that this overlay has added a control to the baseline that is\r\nsupplemental to the baselines provided in NIST SP 800-53B.\r\n• Strikethrough indicates that a control or control enhancement has been removed from this\r\nbaseline compared to the baselines provided in NIST SP 800-53B.\r\nIn the following example, OT discussion was added to Control Enhancement 1 of AU-4\r\n(bolded). In addition, Control Enhancement 1 of AU-4 was added to the Low, Moderate (Mod),\r\nand High baselines (underlined), compared with the NIST 800-53B baseline, which did not\r\ninclude AU-4 Control Enhancement 1.\r\nAU-4 Audit Storage Capacity AU-4 (1) AU-4 (1) AU-4 (1)\r\nSome controls and control enhancements are useful to many OT environments but are not\r\napplicable across all OT sectors or architectures. Such controls may have additional OT\r\ndiscussion. These will appear in the individual control tables. Controls and control enhancements\r\nwithout baselines are not included in Table 22.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n215\r\nTable 22. Control baselines\r\nCNTL\r\nNO. CONTROL NAME\r\nINITIAL CONTROL BASELINES\r\nLOW MOD HIGH\r\nAC-1 Policy and Procedures AC-1 AC-1 AC-1\r\nAC-2 Account Management AC-2 AC-2 (1) (2)\r\n(3) (4) (5) (13)\r\nAC-2 (1) (2) (3)\r\n(4) (5) (11) (12)\r\n(13)\r\nAC-3 Access Enforcement AC-3 AC-3 AC-3 (11)\r\nAC-4 Information Flow Enforcement AC-4 AC-4 (4)\r\nAC-5 Separation of Duties AC-5 AC-5\r\nAC-6 Least Privilege AC-6 (1) (2)\r\n(5) (7) (9) (10)\r\nAC-6 (1) (2) (3)\r\n(5) (7) (9) (10)\r\nAC-7 Unsuccessful Logon Attempts AC-7 AC-7 AC-7\r\nAC-8 System Use Notification AC-8 AC-8 AC-8\r\nAC-10 Concurrent Session Control AC-10\r\nAC-11 Device Lock AC-11 (1) AC-11 (1)\r\nAC-12 Session Termination AC-12 AC-12\r\nAC-14 Permitted Actions without Identification or\r\nAuthentication AC-14 AC-14 AC-14\r\nAC-17 Remote Access AC-17 (9) AC-17 (1) (2)\r\n(3) (4) (9) (10)\r\nAC-17 (1) (2) (3)\r\n(4) (9) (10)\r\nAC-18 Wireless Access AC-18 AC-18 (1) (3) AC-18 (1) (3) (4)\r\n(5)\r\nAC-19 Access Control for Mobile Devices AC-19 AC-19 (5) AC-19 (5)\r\nAC-20 Use of External Systems AC-20 AC-20 (1) (2) AC-20 (1) (2)\r\nAC-21 Information Sharing AC-21 AC-21\r\nAC-22 Publicly Accessible Content AC-22 AC-22 AC-22\r\nAT-1 Policy and Procedures AT-1 AT-1 AT-1\r\nAT-2 Literacy Training and Awareness AT-2 (2) AT-2 (2) (3)\r\n(4) AT-2 (2) (3) (4)\r\nAT-3 Role-Based Training AT-3 AT-3 AT-3\r\nAT-4 Training Records AT-4 AT-4 AT-4\r\nAU-1 Policy and Procedures AU-1 AU-1 AU-1\r\nAU-2 Event Logging AU-2 AU-2 AU-2\r\nAU-3 Content of Audit Records AU-3 AU-3 (1) AU-3 (1)\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n216\r\nCNTL\r\nNO. CONTROL NAME\r\nINITIAL CONTROL BASELINES\r\nLOW MOD HIGH\r\nAU-4 Audit Log Storage Capacity AU-4 (1) AU-4 (1) AU-4 (1)\r\nAU-5 Response to Audit Logging Process Failures AU-5 AU-5 AU-5 (1) (2)\r\nAU-6 Audit Record Review, Analysis, and\r\nReporting AU-6 AU-6 (1) (3) AU-6 (1) (3) (5)(6)\r\nAU-7 Audit Record Reduction and Report\r\nGeneration AU-7 (1) AU-7 (1)\r\nAU-8 Time Stamps AU-8 AU-8 AU-8\r\nAU-9 Protection of Audit Information AU-9 AU-9 (4) AU-9 (2) (3) (4)\r\nAU-10 Non-repudiation AU-10\r\nAU-11 Audit Record Retention AU-11 AU-11 AU-11\r\nAU-12 Audit Generation AU-12 AU-12 AU-12 (1) (3)\r\nCA-1 Policy and Procedures CA-1 CA-1 CA-1\r\nCA-2 Control Assessments CA-2 CA-2 (1) CA-2 (1) (2)\r\nCA-3 Information Exchange CA-3 CA-3 CA-3 (6)\r\nCA-5 Plan of Action and Milestones CA-5 CA-5 CA-5\r\nCA-6 Authorization CA-6 CA-6 CA-6\r\nCA-7 Continuous Monitoring CA-7 (4) CA-7 (1) (4) CA-7 (1) (4)\r\nCA-8 Penetration Testing CA-8 (1)\r\nCA-9 Internal System Connections CA-9 CA-9 CA-9\r\nCM-1 Policy and Procedures CM-1 CM-1 CM-1\r\nCM-2 Baseline Configuration CM-2 CM-2 (2) (3)\r\n(7) CM-2 (2) (3) (7)\r\nCM-3 Configuration Change Control CM-3 (2) (4) CM-3 (1) (2) (4)\r\n(6)\r\nCM-4 Impact Analysis CM-4 CM-4 (2) CM-4 (1) (2)\r\nCM-5 Access Restrictions for Change CM-5 CM-5 CM-5 (1)\r\nCM-6 Configuration Settings CM-6 CM-6 CM-6 (1) (2)\r\nCM-7 Least Functionality CM-7 CM-7 (1) (2)\r\n(5) CM-7 (1) (2) (5)\r\nCM-8 System Component Inventory CM-8 CM-8 (1) (3) CM-8 (1) (2) (3)\r\n(4)\r\nCM-9 Configuration Management Plan CM-9 CM-9\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n217\r\nCNTL\r\nNO. CONTROL NAME\r\nINITIAL CONTROL BASELINES\r\nLOW MOD HIGH\r\nCM-10 Software Usage Restrictions CM-10 CM-10 CM-10\r\nCM-11 User-Installed Software CM-11 CM-11 CM-11\r\nCM-12 Information Location CM-12 (1) CM-12 (1)\r\nCP-1 Policy and Procedures CP-1 CP-1 CP-1\r\nCP-2 Contingency Plan CP-2 CP-2 (1) (3) (8) CP-2 (1) (2) (3)\r\n(5) (8)\r\nCP-3 Contingency Training CP-3 CP-3 CP-3 (1)\r\nCP-4 Contingency Plan Testing CP-4 CP-4 (1) CP-4 (1) (2)\r\nCP-6 Alternate Storage Site CP-6 (1) (3) CP-6 (1) (2) (3)\r\nCP-7 Alternate Processing Site CP-7 (1) (2) (3) CP-7 (1) (2) (3)\r\n(4)\r\nCP-8 Telecommunications Services CP-8 (1) (2) CP-8 (1) (2) (3)\r\n(4)\r\nCP-9 System Backup CP-9 CP-9 (1) (8) CP-9 (1) (2) (3)\r\n(5) (8)\r\nCP-10 System Recovery and Reconstitution CP-10 CP-10 (2) (6) CP-10 (2) (4) (6)\r\nCP-12 Safe Mode CP-12 CP-12 CP-12\r\nIA-1 Policy and Procedures IA-1 IA-1 IA-1\r\nIA-2 Identification and Authentication\r\n(Organizational Users)\r\nIA-2 (1) (2) (8)\r\n(12)\r\nIA-2 (1) (2) (8)\r\n(12)\r\nIA-2 (1) (2) (5)\r\n(8) (12)\r\nIA-3 Device Identification and Authentication IA-3 IA-3 IA-3\r\nIA-4 Identifier Management IA-4 IA-4 (4) IA-4 (4)\r\nIA-5 Authenticator Management IA-5 (1) IA-5 (1) (2) (6) IA-5 (1) (2) (6)\r\nIA-6 Authentication Feedback IA-6 IA-6 IA-6\r\nIA-7 Cryptographic Module Authentication IA-7 IA-7 IA-7\r\nIA-8 Identification and Authentication (Non-Organizational Users) IA-8 (1) (2) (4) IA-8 (1) (2) (4) IA-8 (1) (2) (4)\r\nIA-11 Re-authentication IA-11 IA-11 IA-11\r\nIA-12 Identity Proofing IA-12 (2) (3)\r\n(5)\r\nIA-12 (1) (2) (3)\r\n(4) (5)\r\nIR-1 Policy and Procedures IR-1 IR-1 IR-1\r\nIR-2 Incident Response Training IR-2 IR-2 IR-2 (1) (2)\r\nIR-3 Incident Response Testing IR-3 (2) IR-3 (2)\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n218\r\nCNTL\r\nNO. CONTROL NAME\r\nINITIAL CONTROL BASELINES\r\nLOW MOD HIGH\r\nIR-4 Incident Handling IR-4 IR-4 (1) IR-4 (1) (4) (11)\r\nIR-5 Incident Monitoring IR-5 IR-5 IR-5 (1)\r\nIR-6 Incident Reporting IR-6 IR-6 (1) (3) IR-6 (1) (3)\r\nIR-7 Incident Response Assistance IR-7 IR-7 (1) IR-7 (1)\r\nIR-8 Incident Response Plan IR-8 IR-8 IR-8\r\nMA-1 Policy and Procedures MA-1 MA-1 MA-1\r\nMA-2 Controlled Maintenance MA-2 MA-2 MA-2 (2)\r\nMA-3 Maintenance Tools MA-3 (1) (2)\r\n(3) MA-3 (1) (2) (3)\r\nMA-4 Nonlocal Maintenance MA-4 MA-4 (1) MA-4 (1) (3)\r\nMA-5 Maintenance Personnel MA-5 MA-5 MA-5 (1)\r\nMA-6 Timely Maintenance MA-6 MA-6\r\nMA-7 Field Maintenance MA-7 MA-7 MA-7\r\nMP-1 Policy and Procedures MP-1 MP-1 MP-1\r\nMP-2 Media Access MP-2 MP-2 MP-2\r\nMP-3 Media Marking MP-3 MP-3\r\nMP-4 Media Storage MP-4 MP-4\r\nMP-5 Media Transport MP-5 MP-5\r\nMP-6 Media Sanitization MP-6 MP-6 MP-6 (1) (2) (3)\r\nMP-7 Media Use MP-7 MP-7 MP-7\r\nPE-1 Policy and Procedures PE-1 PE-1 PE-1\r\nPE-2 Physical Access Authorizations PE-2 PE-2 PE-2\r\nPE-3 Physical Access Control PE-3 PE-3 PE-3 (1)\r\nPE-4 Access Control for Transmission PE-4 PE-4\r\nPE-5 Access Control for Output Devices PE-5 PE-5\r\nPE-6 Monitoring Physical Access PE-6 PE-6 (1) (4) PE-6 (1) (4)\r\nPE-8 Visitor Access Records PE-8 PE-8 PE-8 (1)\r\nPE-9 Power Equipment and Cabling PE-9 PE-9\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n219\r\nCNTL\r\nNO. CONTROL NAME\r\nINITIAL CONTROL BASELINES\r\nLOW MOD HIGH\r\nPE-10 Emergency Shutoff PE-10 PE-10\r\nPE-11 Emergency Power PE-11 PE-11 (1)\r\nPE-12 Emergency Lighting PE-12 PE-12 PE-12\r\nPE-13 Fire Protection PE-13 PE-13 (1) PE-13 (1) (2)\r\nPE-14 Environmental Controls PE-14 PE-14 PE-14\r\nPE-15 Water Damage Protection PE-15 PE-15 PE-15 (1)\r\nPE-16 Delivery and Removal PE-16 PE-16 PE-16\r\nPE-17 Alternate Work Site PE-17 PE-17\r\nPE-18 Location of System Components PE-18\r\nPE-22 Component Marking PE-22 PE-22\r\nPL-1 Policy and Procedures PL-1 PL-1 PL-1\r\nPL-2 System Security and Privacy Plans PL-2 PL-2 PL-2\r\nPL-4 Rules of Behavior PL-4 (1) PL-4 (1) PL-4 (1)\r\nPL-8 Security and Privacy Architecture PL-8 PL-8\r\nPL-10 Baseline Selection PL-10 PL-10 PL-10\r\nPL-11 Baseline Tailoring PL-11 PL-11 PL-11\r\nPM-1 Information Security Program Plan PM-1\r\nPM-2 Information Security Program Leadership\r\nRole PM-2\r\nPM-3 Information Security and Privacy Resources PM-3\r\nPM-4 Plan of Action and Milestones Process PM-4\r\nPM-5 System Inventory PM-5\r\nPM-6 Measures of Performance PM-6\r\nPM-7 Enterprise Architecture PM-7\r\nPM-8 Critical Infrastructure Plan PM-8\r\nPM-9 Risk Management Strategy PM-9\r\nPM-10 Authorization Process PM-10\r\nPM-11 Mission and Business Process Definition PM-11\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n220\r\nCNTL\r\nNO. CONTROL NAME\r\nINITIAL CONTROL BASELINES\r\nLOW MOD HIGH\r\nPM-12 Insider Threat Program PM-12\r\nPM-13 Security and Privacy Workforce PM-13\r\nPM-14 Testing, Training, and Monitoring PM-14\r\nPM-15 Security and Privacy Groups and\r\nAssociations PM-15\r\nPM-16 Threat Awareness Program PM-16\r\nPM-17 Protecting Controlled Unclassified\r\nInformation on External Systems PM-17\r\nPM-18 Privacy Program Plan PM-18\r\nPM-19 Privacy Program Leadership Role PM-19\r\nPM-20 Dissemination of Privacy Program\r\nInformation PM-20 (1)\r\nPM-21 Accounting of Disclosures PM-21\r\nPM-22 Personally Identifiable Information Quality\r\nManagement PM-22\r\nPM-23 Data Governance Body PM-23\r\nPM-24 Data Integrity Board PM-24\r\nPM-25\r\nMinimization of Personally Identifiable\r\nInformation Used in Testing, Training, and\r\nResearch\r\nPM-25\r\nPM-26 Complaint Management PM-26\r\nPM-27 Privacy Reporting PM-27\r\nPM-28 Risk Framing PM-28\r\nPM-29 Risk Management Program Leadership\r\nRoles PM-29\r\nPM-30 Supply Chain Risk Management Strategy PM-30 (1)\r\nPM-31 Continuous Monitoring Strategy PM-31\r\nPM-32 Purposing PM-32\r\nPS-1 Policy and Procedures PS-1 PS-1 PS-1\r\nPS-2 Position Risk Designation PS-2 PS-2 PS-2\r\nPS-3 Personnel Screening PS-3 PS-3 PS-3\r\nPS-4 Personnel Termination PS-4 PS-4 PS-4 (2)\r\nPS-5 Personnel Transfer PS-5 PS-5 PS-5\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n221\r\nCNTL\r\nNO. CONTROL NAME\r\nINITIAL CONTROL BASELINES\r\nLOW MOD HIGH\r\nPS-6 Access Agreements PS-6 PS-6 PS-6\r\nPS-7 External Personnel Security PS-7 PS-7 PS-7\r\nPS-8 Personnel Sanctions PS-8 PS-8 PS-8\r\nPS-9 Position Descriptions PS-9 PS-9 PS-9\r\nRA-1 Policy and Procedures RA-1 RA-1 RA-1\r\nRA-2 Security Categorization RA-2 RA-2 RA-2\r\nRA-3 Risk Assessment RA-3 (1) RA-3 (1) RA-3 (1)\r\nRA-5 Vulnerability Monitoring and Scanning RA-5 (2) (11) RA-5 (2) (5)\r\n(11)\r\nRA-5 (2) (4) (5)\r\n(11)\r\nRA-7 Risk Response RA-7 RA-7 RA-7\r\nRA-9 Criticality Analysis RA-9 RA-9\r\nSA-1 Policy and Procedures SA-1 SA-1 SA-1\r\nSA-2 Allocation of Resources SA-2 SA-2 SA-2\r\nSA-3 System Development Life Cycle SA-3 SA-3 SA-3\r\nSA-4 Acquisition Process SA-4 (10) (12) SA-4 (1) (2) (9)\r\n(10) (12)\r\nSA-4 (1) (2) (5)\r\n(9) (10) (12)\r\nSA-5 System Documentation SA-5 SA-5 SA-5\r\nSA-8 Security and Privacy Engineering Principles SA-8 SA-8 SA-8\r\nSA-9 External System Services SA-9 SA-9 (2) SA-9 (2)\r\nSA-10 Developer Configuration Management SA-10 SA-10\r\nSA-11 Developer Testing and Evaluation SA-11 SA-11\r\nSA-15 Development Process, Standards, and Tools SA-15 (3) SA-15 (3)\r\nSA-16 Developer-Provided Training SA-16\r\nSA-17 Developer Security Architecture and Design SA-17\r\nSA-21 Developer Screening SA-21\r\nSA-22 Unsupported System Components SA-22 SA-22 SA-22\r\nSC-1 Policy and Procedures SC-1 SC-1 SC-1\r\nSC-2 Separation of System and User Functionality SC-2 SC-2\r\nSC-3 Security Function Isolation SC-3\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n222\r\nCNTL\r\nNO. CONTROL NAME\r\nINITIAL CONTROL BASELINES\r\nLOW MOD HIGH\r\nSC-4 Information in System Shared Resources SC-4 SC-4\r\nSC-5 Denial-of-Service Protection SC-5 SC-5 SC-5\r\nSC-7 Boundary Protection SC-7 (28) (29)\r\nSC-7 (3) (4) (5)\r\n(7) (8) (18) (28)\r\n(29)\r\nSC-7 (3) (4) (5)\r\n(7) (8) (18) (21)\r\n(28) (29)\r\nSC-8 Transmission Confidentiality and Integrity SC-8 (1) SC-8 (1)\r\nSC-10 Network Disconnect SC-10 SC-10\r\nSC-12 Cryptographic Key Establishment and\r\nManagement SC-12 SC-12 SC-12 (1)\r\nSC-13 Cryptographic Protection SC-13 SC-13 SC-13\r\nSC-15 Collaborative Computing Devices and\r\nApplications SC-15 SC-15 SC-15\r\nSC-17 Public Key Infrastructure Certificates SC-17 SC-17\r\nSC-18 Mobile Code SC-18 SC-18\r\nSC-20 Secure Name /Address Resolution Service\r\n(Authoritative Source) SC-20 SC-20 SC-20\r\nSC-21 Secure Name /Address Resolution Service\r\n(Recursive or Caching Resolver) SC-21 SC-21 SC-21\r\nSC-22 Architecture and Provisioning for\r\nName/Address Resolution Service SC-22 SC-22 SC-22\r\nSC-23 Session Authenticity SC-23 SC-23\r\nSC-24 Fail in Known State SC-24 SC-24\r\nSC-28 Protection of Information at Rest SC-28 (1) SC-28 (1)\r\nSC-39 Process Isolation SC-39 SC-39 SC-39\r\nSC-41 Port and I/O Device Access SC-41 SC-41 SC-41\r\nSC-45 System Time Synchronization SC-45 SC-45 SC-45\r\nSC-47 Alternate Communications Path SC-47\r\nSI-1 Policy and Procedures SI-1 SI-1 SI-1\r\nSI-2 Flaw Remediation SI-2 SI-2 (2) SI-2 (2)\r\nSI-3 Malicious Code Protection SI-3 SI-3 SI-3\r\nSI-4 System Monitoring SI-4 SI-4 (2) (4) (5)\r\nSI-4 (2) (4) (5)\r\n(10) (12) (14)\r\n(20) (22)\r\nSI-5 Security Alerts, Advisories, and Directives SI-5 SI-5 SI-5 (1)\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n223\r\nCNTL\r\nNO. CONTROL NAME\r\nINITIAL CONTROL BASELINES\r\nLOW MOD HIGH\r\nSI-6 Security and Privacy Function Verification SI-6\r\nSI-7 Software, Firmware, and Information\r\nIntegrity SI-7 (1) (7) SI-7 (1) (2) (5)(7) (15)\r\nSI-8 Spam Protection SI-8 (2) SI-8 (2)\r\nSI-10 Information Input Validation SI-10 SI-10\r\nSI-11 Error Handling SI-11 SI-11\r\nSI-12 Information Handling and Retention SI-12 SI-12 SI-12\r\nSI-13 Predictable Failure Prevention SI-13\r\nSI-16 Memory Protection SI-16 SI-16\r\nSI-17 Fail-Safe Procedures SI-17 SI-17 SI-17\r\nSR-1 Policy and Procedures SR-1 SR-1 SR-1\r\nSR-2 Supply Chain Risk Management Plan SR-2 (1) SR-2 (1) SR-2 (1)\r\nSR-3 Supply Chain Controls and Processes SR-3 SR-3 SR-3\r\nSR-5 Acquisition Strategies, Tools, and Methods SR-5 SR-5 (1) SR-5 (1)\r\nSR-6 Supplier Assessments and Reviews SR-6 SR-6\r\nSR-8 Notification Agreements SR-8 SR-8 SR-8\r\nSR-9 Tamper Resistance and Detection SR-9 (1)\r\nSR-10 Inspection of Systems or Components SR-10 SR-10 SR-10\r\nSR-11 Component Authenticity SR-11 (1) (2) SR-11 (1) (2) SR-11 (1) (2)\r\nSR-12 Component Disposal SR-12 SR-12 SR-12\r\nF.4. Tailoring Considerations\r\nThe OT overlay in this publication leverages the NIST SP 800-53B control baselines that\r\naccount for the unique characteristics of OT systems, such as an increased need for availability,\r\nsafety, and environmental or operating environment considerations. Additionally, OT systems\r\nvary widely in their architecture and technology selection. The NIST SP 800-53B control\r\nbaselines were tailored for these general considerations, including the addition of controls\r\nrelevant for OT environments. Organizations can use this overlay as a starting point and further\r\ntailor controls to meet specific operational needs to address the variability of OT systems.\r\nAs organizations further tailor controls to meet their internal security requirements, limitations\r\n(e.g., technology, operational constraints, environmental considerations) may necessitate the\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n224\r\nselection of compensating controls. Compensating controls in the OT environment may be\r\nrequired when the OT cannot support certain controls or control enhancements or when the\r\norganization determines that it is not advisable to implement controls or control enhancements\r\ndue to potential adverse impacts to performance, safety, or reliability. Compensating controls are\r\nalternatives to a specific baseline control or enhancement that provides equivalent or comparable\r\nprotection. For example, if controls or control enhancements require automated mechanisms that\r\nare not readily available, cost-effective, or technically feasible in OT environments,\r\ncompensating controls implemented through nonautomated mechanisms or procedures may be\r\nacceptable to meet the intent of the control.\r\nCompensating controls implemented in accordance with PL-11 from SP 800-53, Rev. 5 are not\r\nconsidered exceptions or waivers to the baseline controls. Rather, they are alternative safeguards\r\nand countermeasures employed within the OT environment that accomplish the intent of the\r\noriginal controls that could not be effectively employed. See “Control Tailoring” in Section 3.3\r\nof NIST SP 800-37, Rev. 2 [SP800-37r2].\r\nUsing compensating controls may also include control enhancements that supplement the\r\nbaseline. Using compensating controls typically involves a trade-off between additional risk and\r\nreduced functionality. Every use of compensating controls should involve a risk-based\r\ndetermination of how much residual risk to accept and how much functionality to reduce.\r\nAdditionally, when compensating controls are employed, organizations should document the\r\nrationale and describe:\r\n• Why the baseline control could not be implemented\r\n• How the compensating controls provide equivalent security capabilities for OT systems\r\n• The risk acceptance for any residual risk that results from using the compensating\r\ncontrols instead of the baseline control\r\nOrganizational decisions on the use of compensating controls are documented in the security\r\nplan for the OT.\r\nControls that contain assignments (e.g., Assignment: organization-defined conditions or trigger\r\nevents) may be tailored out of the baseline. This is equivalent to assigning a value of “none.” The\r\nassignment may take on different values for different impact baselines.\r\nF.5. OT Communication Protocols\r\nThe unique network properties within OT may warrant specific attention when applying certain\r\ncontrols. Many of the controls in NIST SP 800-53, Rev. 5 that pertain to communication,\r\ndevices, and interfaces implicitly assume the applicability of network routing or communication\r\nbetween network segments or zones. Some devices or subsystems used in OT may be configured\r\nor architected in a way that may create an exception to this assumption. As a result, controls for\r\ndevices that communicate using standards and protocols that do not include network addressing\r\ngenerally require tailoring. An RS-232 (serial) interface is an example of a non-network\r\naddressable or routable communication method that is commonly employed in OT equipment.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n225\r\nF.6. Definitions\r\nTerms used in this overlay are listed in the CSRC glossary.\r\nF.7. Detailed Overlay Control Specifications\r\nThis overlay is based on NIST SP 800-53, Rev. 5, Security and Privacy Controls for Information\r\nSystems and Organizations [SP800-53r5], which provides a catalog of security and privacy\r\ncontrols, and NIST SP 800-53B, Control Baselines for Information Systems and Organizations\r\n[SP800-53B]. The controls are customizable and implemented as part of an organization-wide\r\nprocess that manages security and privacy risk. The controls address a diverse set of security and\r\nprivacy requirements across the Federal Government and critical infrastructure and are derived\r\nfrom legislation, Executive Orders, policies, directives, regulations, standards, and mission and\r\nbusiness needs. The documents also describe how to develop specialized sets of controls or\r\noverlays that are tailored for specific types of mission and business functions, technologies, or\r\nenvironments of operation. Finally, the catalog controls address security from both a\r\nfunctionality perspective (i.e., the strength of security and privacy functions and mechanisms\r\nprovided) and an assurance perspective (i.e., the measures of confidence in the implemented\r\ncapability). Addressing both functionality and assurance helps to ensure that component products\r\nand the systems built from those products use sound system and security engineering principles\r\nand are sufficiently trustworthy.\r\nIn preparation for selecting and specifying the appropriate controls for organizational systems\r\nand their respective environments of operation, organizations should first determine the\r\ncriticality and sensitivity of the information to be processed, stored, or transmitted by those\r\nsystems. This process is known as security categorization. FIPS 199 [FIPS199] enables federal\r\nagencies to establish security categories for both information and information systems. Other\r\ndocuments, such as those produced by ISA and CNSS, also provide guidance for defining low,\r\nmoderate, and high levels of security based on impact. The security categories are based on the\r\npotential impact on an organization or on people (i.e., employees and/or the public) should\r\ncertain events occur that jeopardize the information and systems needed by the organization to\r\naccomplish its assigned mission, such as protecting its assets, fulfilling its legal responsibilities,\r\nmaintaining its day-to-day functions, and protecting individuals’ safety, health, and life. Security\r\ncategories are to be used in conjunction with vulnerability and threat information to assess the\r\nrisk to an organization.\r\nThis overlay provides OT Discussions for the controls and control enhancements prescribed for a\r\nsystem or an organization designed to protect the confidentiality, integrity, and availability of its\r\ndata and to meet a set of defined security requirements. Discussions for all controls and control\r\nenhancements in Section 3 of NIST SP 800-53, Rev. 5 should be used in conjunction with the\r\nOT Discussions in this overlay. This overlay contains a tailoring of the control baselines, and its\r\nspecification may be more stringent or less stringent than the original control baseline\r\nspecification. It is high-level, applicable to all OT environments, can be applied to multiple\r\nsystems, and may be used as the basis for more specific overlays. Use cases for specific systems\r\nin specific environments may be separately published (e.g., as a NIST IR).\r\nFigure 22 uses the AU-4 control as an example of the format and content of the detailed overlay\r\ncontrol specifications.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n226\r\n Control number and title\r\n Column for control and control enhancement number\r\n Column for control and control enhancement name\r\n Columns for baselines. If the baselines have been supplemented, then SUPPLEMENTED\r\nappears.\r\n A row for each control or control enhancement\r\n Columns for LOW, MODERATE, and HIGH baselines\r\n “Select” indicates that the control is selected in NIST SP 800-53, Rev. 5. “Add” indicates\r\nthat the control is added to a baseline in the OT overlay. A blank cell indicates that the\r\ncontrol is not selected. “Remove” indicates that the control is removed from the baseline.\r\n The OT Discussion. If there is none, that is stated.\r\n The control enhancement OT Discussion. If there is none, that is stated.\r\n The rationale for changing the presence of a control or control enhancement in the\r\nbaseline\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n227\r\n \r\n➊AC-3 ACCESS ENFORCEMENT\r\n \r\n➋CNTL\r\nNO.\r\n➌CONTROL NAME Control Enhancement Name➍SUPPLEMENTED\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAC-3 Access Enforcement Select Select Select\r\nAC-3 (11) ACCESS ENFORCEMENT | RESTRICT ACCESS TO SPECIFIC\r\nINFORMATION TYPES Add\r\n \r\n➑ OT Discussion: The organization ensures that access enforcement mechanisms do not\r\nadversely impact the operational performance of the OT. Example compensating controls\r\ninclude encapsulation. The policy for logical access control to non-addressable and non-routable system resources and the associated information is made explicit. Access control\r\nmechanisms include hardware, firmware, and software that control the device or have\r\ndevice access, such as device drivers and communications controllers. Physical access\r\ncontrol may serve as a compensating control for logical access control. However, it may\r\nnot provide sufficient granularity when users require access to different functions.\r\n➒ Control Enhancement: (11) OT Discussion: The organization identifies and restricts\r\naccess to information that could impact the OT environment and accounts for\r\ninformation types that are sensitive, proprietary, contain trade secrets, or support safety\r\nfunctions.\r\n➓ Rationale for adding AC-3 (11) to HIGH baseline: The loss of availability, integrity,\r\nand confidentiality of certain types of information that reside on a high-impact OT\r\nsystem may result in severe or catastrophic adverse effects on operations, assets, or\r\nindividuals, including severe degradation or loss of mission capability, major damage to\r\norganizational assets, or harm to individuals involving the loss of life or life-threatening\r\ninjuries.\r\nFig. 22. Detailed overlay control specifications illustrated\r\nF.7.1. ACCESS CONTROL – AC\r\nTailoring Considerations for the Access Control Family\r\nBefore implementing controls in the AC family, consider the trade-offs among security, privacy,\r\nlatency, performance, throughput, and reliability. For example, the organization considers\r\nwhether latency induced from the use of confidentiality and integrity mechanisms that employ\r\ncryptographic mechanisms would adversely impact the operational performance of the OT.\r\nWhen the OT cannot support the specific access control requirements of a control, the\r\norganization employs compensating controls in accordance with the general tailoring guidance.\r\nExamples of compensating controls are given with each control as appropriate.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n228\r\nAC-1 ACCESS CONTROL POLICY AND PROCEDURES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAC-1 Policy and Procedures Select Select Select\r\nOT Discussion: The policy specifically addresses the unique properties and requirements of OT\r\nand the relationship to non-OT systems. OT access by vendors and maintenance staff can occur\r\nover a large facility footprint or geographic area and into unobserved spaces, such as mechanical\r\nor electrical rooms, ceilings, floors, field substations, switch and valve vaults, and pump stations.\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAC-2 Account Management Select Select Select\r\nAC-2 (1) ACCOUNT MANAGEMENT | AUTOMATED SYSTEM ACCOUNT\r\nMANAGEMENT Select Select\r\nAC-2 (2) ACCOUNT MANAGEMENT | AUTOMATED TEMPORARY AND\r\nEMERGENCY ACCOUNT MANAGEMENT Select Select\r\nAC-2 (3) ACCOUNT MANAGEMENT | DISABLE ACCOUNTS Select Select\r\nAC-2 (4) ACCOUNT MANAGEMENT | AUTOMATED AUDIT ACTIONS Select Select\r\nAC-2 (5) ACCOUNT MANAGEMENT | INACTIVITY LOGOUT Select Select\r\nAC-2\r\n(11) ACCOUNT MANAGEMENT | USAGE CONDITIONS Select\r\nAC-2\r\n(12)\r\nACCOUNT MANAGEMENT | ACCOUNT MONITORING FOR ATYPICAL\r\nUSAGE Select\r\nAC-2\r\n(13)\r\nACCOUNT MANAGEMENT | DISABLE ACCOUNTS FOR HIGH-RISK\r\nINDIVIDUALS Select Select\r\nOT Discussion: In OT systems, physical security, personnel security, intrusion detection, or\r\nauditing measures may support this control objective.\r\nControl Enhancement: (1) (3) (4) No OT discussion for this control.\r\nControl Enhancement: (2) OT Discussion: When the OT (e.g., field devices) cannot support\r\ntemporary or emergency accounts, this enhancement does not apply. Example compensating\r\ncontrols include employing nonautomated mechanisms or procedures.\r\nControl Enhancement: (5) OT Discussion: This control enhancement defines situations or\r\ntimeframes in which users log out of accounts in the policy. Automatic enforcement is not\r\naddressed by this control enhancement. Organizations determine whether this control\r\nenhancement is appropriate for the mission and/or functions of the OT system and define the\r\ntimeframe or scenarios. If no timeframe or scenarios apply, the organization-defined parameter\r\nreflects as much.\r\nControl Enhancement: (11) (12) No OT Discussion for this control.\r\nControl Enhancement: (13) OT Discussion: Close coordination occurs between OT, HR, IT, and\r\nphysical security personnel to ensure the timely removal of high-risk individuals.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n229\r\nAC-3 ACCESS ENFORCEMENT\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nSUPPLEMENTED\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAC-3 Access Enforcement Select Select Select\r\nAC-3\r\n(11)\r\nACCESS ENFORCEMENT | RESTRICT ACCESS TO SPECIFIC\r\nINFORMATION TYPES Add\r\nOT Discussion: The organization ensures that access enforcement mechanisms do not adversely\r\nimpact the operational performance of the OT. Example compensating controls include\r\nencapsulation. The policy for logical access control to non-addressable and non-routable system\r\nresources and the associated information is made explicit. Access control mechanisms include\r\nhardware, firmware, and software that control the device or have device access, such as device\r\ndrivers and communications controllers. Physical access control may serve as a compensating\r\ncontrol for logical access control. However, it may not provide sufficient granularity when users\r\nrequire access to different functions.\r\nControl Enhancement: (11) OT Discussion: The organization identifies and restricts access to\r\ninformation that could impact the OT environment and accounts for information types that are\r\nsensitive, proprietary, contain trade secrets, or support safety functions.\r\nRationale for adding AC-3 (11) to HIGH baseline: The loss of availability, integrity, and\r\nconfidentiality of certain types of information that reside on a high-impact OT system may result\r\nin severe or catastrophic adverse effects on operations, assets, or individuals, including severe\r\ndegradation or loss of mission capability, major damage to organizational assets, or harm to\r\nindividuals involving the loss of life or life-threatening injuries.\r\nAC-4 INFORMATION FLOW ENFORCEMENT\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAC-4 Information Flow Enforcement Select Select\r\nAC-4 (4) INFORMATION FLOW ENFORCEMENT | FLOW CONTROL OF\r\nENCRYPTED INFORMATION Select\r\nOT Discussion: Information flow policy may be achieved using a combination of logical and\r\nphysical flow restriction techniques. The inspection of message content may enforce information\r\nflow policy. For example, industrial OT protocols may be restricted using inbound and outbound\r\ntraffic rules on a network control device between OT and IT networks. For non-routable\r\ncommunication, such as serial connections, devices may be configured to limit commands to and\r\nfrom specific tags within the OT device. The information flow policy may be supported by\r\nlabeling or coloring physical connectors to aid in connecting networks. Devices that do not have\r\na business need to communicate should not be connected (i.e., air gapped).\r\nControl Enhancement: (4) No OT discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n230\r\nAC-5 SEPARATION OF DUTIES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAC-5 Separation of Duties Select Select\r\nOT Discussion: Example compensating controls include providing increased personnel security\r\nand auditing. The organization carefully considers the appropriateness of a single individual\r\nperforming multiple critical roles.\r\nAC-6 LEAST PRIVILEGE\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAC-6 Least Privilege Select Select\r\nAC-6 (1) LEAST PRIVILEGE | AUTHORIZE ACCESS TO SECURITY FUNCTIONS Select Select\r\nAC-6 (2) LEAST PRIVILEGE | NON-PRIVILEGED ACCESS FOR NONSECURITY\r\nFUNCTIONS Select Select\r\nAC-6 (3) LEAST PRIVILEGE | NETWORK ACCESS TO PRIVILEGED COMMANDS Select\r\nAC-6 (5) LEAST PRIVILEGE | PRIVILEGED ACCOUNTS Select Select\r\nAC-6 (7) LEAST PRIVILEGE | REVIEW OF USER PRIVILEGES Select Select\r\nAC-6 (9) LEAST PRIVILEGE | LOG USE OF PRIVILEGED FUNCTIONS Select Select\r\nAC-6\r\n(10)\r\nLEAST PRIVILEGE | PROHIBIT NON-PRIVILEGED USERS FROM\r\nEXECUTING PRIVILEGED FUNCTIONS Select Select\r\nOT Discussion: Example compensating controls include providing increased personnel security\r\nand auditing. The organization carefully considers the appropriateness of a single individual\r\nhaving multiple critical privileges. System privilege models may be tailored to enforce integrity\r\nand availability (e.g., lower privileges include read access, and higher privileges include write\r\naccess).\r\nControl Enhancement: (1) (2) (3) (5) (9) OT Discussion: When OT components (e.g., PLCs)\r\ncannot support the logging of privileged functions, other system components within the\r\nauthorization boundary may be used (e.g., engineering workstations or physical access\r\nmonitoring).\r\nControl Enhancement: (7) No OT Discussion for this control.\r\nControl Enhancement: (10) OT Discussion: Example compensating controls include enhanced\r\nauditing.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n231\r\nAC-7 UNSUCCESSFUL LOGON ATTEMPTS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAC-7 Unsuccessful Logon Attempts Select Select Select\r\nOT Discussion: Many OT systems remain in continuous operation, and operators remain logged\r\nonto the system at all times. A “log-over” capability may be employed. Example compensating\r\ncontrols include logging or recording all unsuccessful logon attempts and alerting OT security\r\npersonnel through alarms or other means when the number of organization-defined consecutive\r\ninvalid access attempts is exceeded. Unsuccessful logon attempt limits are enforced for accounts\r\n(e.g., administrator) or systems (e.g., engineering workstations) that are not required for\r\ncontinuous operation.\r\nAC-8 SYSTEM USE NOTIFICATION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAC-8 System Use Notification Select Select Select\r\nOT Discussion: Many OT systems must remain in continuous operation, and system use\r\nnotification may not be supported or effective. Example compensating controls include posting\r\nphysical notices in OT facilities or providing recurring training on system use prior to permitting\r\naccess.\r\nAC-10 CONCURRENT SESSION CONTROL\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAC-10 Concurrent Session Control Select\r\nOT Discussion: The number, account type, and privileges of concurrent sessions consider the\r\nroles and responsibilities of the affected individuals. Example compensating controls include\r\nproviding increased auditing measures.\r\nAC-11 DEVICE LOCK\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAC-11 Device Lock Select Select\r\nAC-11\r\n(1) DEVICE LOCK | PATTERN-HIDING DISPLAYS Select Select\r\nOT Discussion: This control assumes a staffed environment where users interact with system\r\ndisplays. This control may be tailored appropriately where systems do not have displays\r\nconfigured, systems are placed in an access-controlled facility or locked enclosure, or immediate\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n232\r\noperator response is required in emergency situations. Example compensating controls include\r\nlocating the display in an area with physical access controls that limit access to individuals with\r\npermission and need-to-know for the displayed information.\r\nControl Enhancement: (1) OT Discussion: Physical protection may be employed to prevent\r\naccess to a display or the attachment of a display. When the OT cannot conceal displayed\r\ninformation, the organization employs nonautomated mechanisms or procedures as\r\ncompensating controls in accordance with the general tailoring guidance.\r\nAC-12 SESSION TERMINATION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAC-12 Session Termination Select Select\r\nOT Discussion: Example compensating controls include providing increased auditing measures\r\nor limiting remote access privileges to key personnel.\r\nAC-14 PERMITTED ACTIONS WITHOUT IDENTIFICATION OR AUTHENTICATION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAC-14 Permitted Actions without Identification or Authentication Select Select Select\r\nNo OT Discussion for this control.\r\nAC-17 REMOTE ACCESS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nSUPPLEMENTED\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAC-17 Remote Access Select Select Select\r\nAC-17\r\n(1) REMOTE ACCESS | AUTOMATED MONITORING / CONTROL Select Select\r\nAC-17\r\n(2)\r\nREMOTE ACCESS | PROTECTION OF CONFIDENTIALITY / INTEGRITY\r\nUSING ENCRYPTION Select Select\r\nAC-17\r\n(3) REMOTE ACCESS | MANAGED ACCESS CONTROL POINTS Select Select\r\nAC-17\r\n(4) REMOTE ACCESS | PRIVILEGED COMMANDS / ACCESS Select Select\r\nAC-17\r\n(9) REMOTE ACCESS | DISCONNECT OR DISABLE ACCESS Add Add Add\r\nAC-17\r\n(10) REMOTE ACCESS | AUTHENTICATE REMOTE COMMANDS Add Add\r\nOT Discussion: When the OT cannot implement any or all of the components of this control, the\r\norganization employs other mechanisms or procedures as compensating controls in accordance\r\nwith the general tailoring guidance.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n233\r\nControl Enhancement: (1) OT Discussion: Example compensating controls include employing\r\nnonautomated mechanisms or procedures as compensating controls. Compensating controls\r\ncould include limiting remote access to a specified period of time or placing a call from the OT\r\nsite to the authenticated remote entity.\r\nControl Enhancement: (2) OT Discussion: Encryption-based technologies should be used to\r\nsupport the confidentiality and integrity of remote access sessions. While OT devices often lack\r\nthe ability to support modern encryption, additional devices (e.g., VPNs) can be added to support\r\nthese features. This control should not be confused with SC-8 – Transmission Confidentiality\r\nand Integrity, which discusses confidentiality and integrity requirements for general\r\ncommunications, including between OT devices.\r\nControl Enhancement: (3) OT Discussion: Example compensating controls include connection-specific manual authentication of the remote entity.\r\nControl Enhancement: (4) (10) No OT Discussion for this control.\r\nControl Enhancement: (9) OT Discussion: Implementation of the remote access disconnect\r\nshould not impact OT operations. OT personnel should be trained on how to use the remote\r\naccess disconnect.\r\nRationale for adding AC-17 (9) to LOW, MOD, and HIGH baselines: As more OT systems\r\nbecome accessible remotely, the capability to disconnect or disable remote access is critical to\r\nmanaging risk and may be required to provide stable and safe operations.\r\nRationale for adding AC-17 (10) to MOD and HIGH baselines: The ability to authenticate\r\nremote commands is important to prevent unauthorized commands that may have immediate or\r\nserious consequences, such as injury, death, property damage, the loss of high-value assets, the\r\nfailure of mission or business functions, or compromise of sensitive information.\r\nAC-18 WIRELESS ACCESS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAC-18 Wireless Access Select Select Select\r\nAC-18\r\n(1) WIRELESS ACCESS | AUTHENTICATION AND ENCRYPTION Select Select\r\nAC-18\r\n(3) WIRELESS ACCESS | DISABLE WIRELESS NETWORKING Select Select\r\nAC-18\r\n(4) WIRELESS ACCESS | RESTRICT CONFIGURATIONS BY USERS Select\r\nAC-18\r\n(5) WIRELESS ACCESS | ANTENNAS AND TRANSMISSION POWER LEVELS Select\r\nOT Discussion: When OT cannot implement any or all of the components of this control, the\r\norganization employs other mechanisms or procedures as compensating controls in accordance\r\nwith the general tailoring guidance.\r\nControl Enhancement: (1) OT Discussion: The implementation of authentication and encryption\r\nis driven by the OT environment. If devices and users cannot all be authenticated and encrypted\r\ndue to operational or technology constraints, compensating controls include providing increased\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n234\r\nauditing for wireless access, limiting wireless access privileges to key personnel, or using AC-18\r\n(5) to reduce the boundary of wireless access.\r\nControl Enhancement: (3) (4) No OT Discussion for this control.\r\nControl Enhancement: (5) Availability and interference for wireless signals may be a concern\r\nwithin OT environments. Antennas and power levels should be designed to overcome and\r\nachieve availability goals. Where confidentiality is concerned, antennas and power levels can\r\nalso be designed to minimize signal exposure outside of the facility.\r\nAC-19 ACCESS CONTROL FOR MOBILE DEVICES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAC-19 Access Control for Mobile Devices Select Select Select\r\nAC-19\r\n(5)\r\nACCESS CONTROL FOR MOBILE DEVICES | FULL DEVICE /\r\nCONTAINER-BASED ENCRYPTION Select Select\r\nNo OT Discussion for this control.\r\nAC-20 USE OF EXTERNAL SYSTEMS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAC-20 Use of External Systems Select Select Select\r\nAC-20\r\n(1) USE OF EXTERNAL SYSTEMS | LIMITS ON AUTHORIZED USE Select Select\r\nAC-20\r\n(2) USE OF EXTERNAL SYSTEMS | PORTABLE STORAGE MEDIA Select Select\r\nOT Discussion: Organizations refine the definition of “external” to reflect lines of authority and\r\nresponsibility, the granularity of an organization entity, and their relationships. An organization\r\nmay consider a system to be external if that system performs different functions, implements\r\ndifferent policies, falls under different management authorities, or does not provide sufficient\r\nvisibility into the implementation of controls to allow the establishment of a satisfactory trust\r\nrelationship. For example, an OT system and a business data processing system may be\r\nconsidered external to each other depending on the organization’s system boundaries.\r\nAccess to an OT for support by a business partner, such as a vendor or support contractor, is\r\nanother common example. The definition and trustworthiness of external systems is reexamined\r\nwith respect to OT functions, purposes, technology, and limitations to establish a clearly\r\ndocumented technical or business case for use and an acceptance of the risk inherent in the use of\r\nan external system.\r\nControl Enhancement: (1) (2) No OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n235\r\nAC-21 INFORMATION SHARING\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAC-21 Information Sharing Select Select\r\nNo OT Discussion for this control.\r\nAC-22 PUBLICLY ACCESSIBLE CONTENT\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAC-22 Publicly Accessible Content Select Select Select\r\nOT Discussion: Generally, public access to OT systems is not permitted. Select information may\r\nbe transferred to a publicly accessible system, possibly with added controls. The organization\r\nshould review what information is being made accessible prior to publication.\r\nF.7.2. AWARENESS AND TRAINING – AT\r\nAT-1 POLICY AND PROCEDURES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAT-1 Policy and Procedures Select Select Select\r\nOT Discussion: The policy specifically addresses the unique properties and requirements of OT\r\nand the relationship to non-OT systems.\r\nAT-2 LITERACY TRAINING AND AWARENESS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nSUPPLEMENTED\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAT-2 Literacy Training and Awareness Select Select Select\r\nAT-2 (2) LITERACY TRAINING AND AWARENESS | INSIDER THREAT Select Select Select\r\nAT-2 (3) LITERACY TRAINING AND AWARENESS | SOCIAL ENGINEERING AND\r\nMINING Select Select\r\nAT-2 (4) LITERACY TRAINING AND AWARENESS | SUSPICIOUS\r\nCOMMUNICATIONS AND ANOMALOUS SYSTEM BEHAVIOR Add Add\r\nOT Discussion: Security awareness training includes initial and periodic review of OT-specific\r\npolicies, standard operating procedures, security trends, and vulnerabilities. The OT security\r\nawareness program is consistent with the requirements of the security awareness and training\r\npolicy established by the organization.\r\nControl Enhancement: (2) (3) No OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n236\r\nControl Enhancement: (4) OT Discussion: Identify and communicate suspicious and anomalous\r\nbehaviors within the OT environment. Some examples of OT suspicious or anomalous behavior\r\nmay include a PLC still in programming mode when it is expected to be in run mode, process\r\ntrips with an undetermined root cause, malware on an HMI, unexpected mouse movement, or\r\nprocess changes that are not being performed by the operator.\r\nRationale for adding AT-2 (4) to MOD and HIGH baselines: Training OT personnel on\r\npotentially suspicious communications and anomalous behaviors as well as the actions to take if\r\nanomalous system behavior occurs can supplement system detection and protection mechanisms\r\nfor improved response.\r\nAT-3 ROLE-BASED TRAINING\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAT-3 Role-Based Training Select Select Select\r\nOT Discussion: Security training includes initial and periodic review of OT-specific policies,\r\nstandard operating procedures, security trends, and vulnerabilities. The OT security training\r\nprogram is consistent with the requirements of the security awareness and training policy\r\nestablished by the organization. The training may be customized for specific OT roles, which\r\ncould include operators, maintainers, engineers, supervisors, and administrators.\r\nAT-4 TRAINING RECORDS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAT-4 Training Records Select Select Select\r\nNo OT Discussion for this control.\r\nF.7.3. AUDITING AND ACCOUNTABILITY – AU\r\nTailoring Considerations for the Audit Family\r\nIn general, security audit information and audit tools are not available on legacy OT. When OT\r\ncannot support the specific audit and accountability requirements of a control, the organization\r\nemploys compensating controls in accordance with the general tailoring guidance. For example,\r\norganizations may want to consider whether security audit information is available from separate\r\nsystems or system components (e.g., the historian, firewall logs, physical security systems).\r\nAdditional examples of compensating controls are given with each control as appropriate.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n237\r\nAU-1 AUDIT AND ACCOUNTABILITY POLICY AND PROCEDURES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAU-1 Policy and Procedures Select Select Select\r\nOT Discussion: The policy specifically addresses the unique properties and requirements of OT\r\nand the relationship to non-OT systems.\r\nAU-2 EVENT LOGGING\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAU-2 Event Logging Select Select Select\r\nOT Discussion: Organizations may want to include relevant OT events (e.g., alerts, alarms,\r\nconfiguration and status changes, operator actions) in their event logging, which may be\r\ndesignated as audit events.\r\nAU-3 CONTENT OF AUDIT RECORDS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAU-3 Content of Audit Records Select Select Select\r\nAU-3 (1) CONTENT OF AUDIT RECORDS | ADDITIONAL AUDIT INFORMATION Select Select\r\nNo OT Discussion for this control.\r\nAU-4 AUDIT LOG STORAGE CAPACITY\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nSUPPLEMENTED\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAU-4 Audit Log Storage Capacity Select Select Select\r\nAU-4 (1) AUDIT LOG STORAGE CAPACITY | TRANSFER TO ALTERNATE\r\nSTORAGE Add Add Add\r\nNo OT Discussion for this control.\r\nRationale for adding AU-4 (1) to LOW, MOD, and HIGH baselines: Organizational\r\nrequirements may require the storage of very large amounts of data, which OT components may\r\nnot be able to support directly.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n238\r\nAU-5 RESPONSE TO AUDIT LOGGING PROCESS FAILURES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAU-5 Response to Audit Logging Process Failures Select Select Select\r\nAU-5 (1) RESPONSE TO AUDIT LOGGING PROCESS FAILURES | AUDIT STORAGE\r\nCAPACITY Select\r\nAU-5 (2) RESPONSE TO AUDIT LOGGING PROCESS FAILURES | REAL-TIME\r\nALERTS Select\r\nNo OT Discussion for this control.\r\nAU-6 AUDIT RECORD REVIEW, ANALYSIS, AND REPORTING\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAU-6 Audit Review, Analysis, and Reporting Select Select Select\r\nAU-6 (1) AUDIT RECORD REVIEW, ANALYSIS, AND REPORTING | AUTOMATED\r\nPROCESS INTEGRATION Select Select\r\nAU-6 (3) AUDIT RECORD REVIEW, ANALYSIS, AND REPORTING | CORRELATE\r\nAUDIT RECORD REPOSITORIES Select Select\r\nAU-6 (5) AUDIT RECORD REVIEW, ANALYSIS, AND REPORTING | INTEGRATED\r\nANALYSIS OF AUDIT RECORDS Select\r\nAU-6 (6) AUDIT RECORD REVIEW, ANALYSIS, AND REPORTING | CORRELATION\r\nWITH PHYSICAL MONITORING Select\r\nNo OT Discussion for this control.\r\nControl Enhancement: (1) OT Discussion: Example compensating controls include manual\r\nmechanisms or procedures. For devices where audit records cannot be feasibly collected,\r\nperiodic manual review may be necessary.\r\nControl Enhancement: (3) (5) (6) No OT Discussion for this control.\r\nAU-7 AUDIT RECORD REDUCTION AND REPORT GENERATION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAU-7 Audit Record Reduction and Report Generation Select Select\r\nAU-7 (1) AUDIT RECORD REDUCTION AND REPORT GENERATION |\r\nAUTOMATIC PROCESSING Select Select\r\nNo OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n239\r\nAU-8 TIME STAMPS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAU-8 Time Stamps Select Select Select\r\nOT Discussion: Example compensating controls include using a separate system designated as an\r\nauthoritative time source. See related control SC-45.\r\nAU-9 PROTECTION OF AUDIT INFORMATION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAU-9 Protection of Audit Information Select Select Select\r\nAU-9 (2) PROTECTION OF AUDIT INFORMATION | STORE ON SEPARATE\r\nPHYSICAL SYSTEMS OR COMPONENTS Select\r\nAU-9 (3) PROTECTION OF AUDIT INFORMATION | CRYPTOGRAPHIC\r\nPROTECTION Select\r\nAU-9 (4) PROTECTION OF AUDIT INFORMATION | ACCESS BY SUBSET OF\r\nPRIVILEGED USERS Select Select\r\nNo OT Discussion for this control.\r\nAU-10 NON-REPUDIATION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAU-10 Non-Repudiation Select\r\nOT Discussion: OT devices may not enforce non-repudiation of audit records and may require\r\ncompensating controls. Example compensating controls include physical security systems,\r\ncameras to monitor user access, or a separate device for log collection.\r\nAU-11 AUDIT RECORD RETENTION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAU-11 Audit Record Retention Select Select Select\r\nNo OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n240\r\nAU-12 AUDIT RECORD GENERATION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nAU-12 Audit Record Generation Select Select Select\r\nAU-12\r\n(1)\r\nAUDIT RECORD GENERATION | SYSTEM-WIDE AND TIME-CORRELATED AUDIT TRAIL Select\r\nAU-12\r\n(3)\r\nAUDIT RECORD GENERATION | CHANGES BY AUTHORIZED\r\nINDIVIDUALS Select\r\nNo OT Discussion for this control.\r\nControl Enhancement: (1) OT Discussion: Example compensating controls include providing\r\ntime-correlated audit records on a separate system.\r\nControl Enhancement: (3) OT Discussion: Example compensating controls include employing\r\nnonautomated mechanisms or procedures.\r\nF.7.4. ASSESSMENT, AUTHORIZATION, AND MONITORING – CA\r\nTailoring Considerations for the Security Assessment and Authorization Family\r\nWhen the OT cannot support the specific assessment, authorization, and monitoring\r\nrequirements of a control, the organization employs compensating controls in accordance with\r\nthe general tailoring guidance. Examples of compensating controls are given with each control as\r\nappropriate.\r\nCA-1 POLICY AND PROCEDURES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nCA-1 Policy and Procedures Select Select Select\r\nOT Discussion: The policy specifically addresses the unique properties and requirements of OT\r\nand the relationship to non-OT systems.\r\nCA-2 CONTROL ASSESSMENTS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nCA-2 Control Assessments Select Select Select\r\nCA-2 (1) CONTROL ASSESSMENTS | INDEPENDENT ASSESSORS Select Select\r\nCA-2 (2) CONTROL ASSESSMENTS | SPECIALIZED ASSESSMENTS Select\r\nOT Discussion: Assessments are performed and documented by qualified assessors (i.e.,\r\nexperienced in assessing OT) authorized by the organization. The individual or group conducting\r\nthe assessment fully understands the organizational information security policies and procedures,\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n241\r\nthe OT security policies and procedures, and the specific health, safety, and environmental risks\r\nassociated with a particular facility and/or process. The organization ensures that the assessment\r\ndoes not affect system operation or result in unintentional system modification. If assessment\r\nactivities must be performed on the production OT, it may need to be taken offline before an\r\nassessment can be conducted, or the assessment should be scheduled to occur during planned OT\r\noutages whenever possible.\r\nControl Enhancement: (1) No OT Discussion on this control.\r\nControl Enhancement: (2) OT Discussion: The organization conducts risk analysis to support the\r\nselection of an assessment target (e.g., the live system, an offline replica, or lab system).\r\nCA-3 INFORMATION EXCHANGE\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nCA-3 Information Exchange Select Select Select\r\nCA-3 (6) INFORMATION EXCHANGE | TRANSFER AUTHORIZATION Select\r\nOT Discussion: Organizations perform risk-benefit analysis to determine whether an OT should\r\nbe connected to other systems. The authorizing official (AO) fully understands the organizational\r\ninformation security policies and procedures; the OT security policies and procedures; the risks\r\nto organizational operations and assets, individuals, other organizations, and the Nation\r\nassociated with the connection to other systems; the individuals and organizations that operate\r\nand maintain the systems, including maintenance contractors or service providers; and the\r\nspecific health, safety, and environmental risks associated with a particular interconnection.\r\nConnections from the OT environment to other security zones may cross the authorization\r\nboundary such that two different authorizing officials may be required to approve the connection.\r\nDecisions to accept risk are documented.\r\nControl Enhancement: (6) No OT Discussion for this control.\r\nCA-5 PLAN OF ACTION AND MILESTONES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nCA-5 Plan of Action and Milestones Select Select Select\r\nOT Discussion: Corrective actions identified in assessments may not be immediately actionable\r\nin an OT environment. Therefore, short-term mitigations may be implemented to reduce risk as\r\npart of the gap closure plan or plan of action and milestones.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n242\r\nCA-6 AUTHORIZATION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nCA-6 Authorization Select Select Select\r\nNo OT Discussion for this control.\r\nCA-7 CONTINUOUS MONITORING\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nCA-7 Continuous Monitoring Select Select Select\r\nCA-7 (1) CONTINUOUS MONITORING | INDEPENDENT ASSESSMENT Select Select\r\nCA-7 (4) CONTINUOUS MONITORING | RISK MONITORING Select Select Select\r\nOT Discussion: Continuous monitoring programs for OT are designed, documented, and\r\nimplemented with input from OT personnel. The organization ensures that continuous\r\nmonitoring does not interfere with OT functions. The individual or group designing and\r\nconducting the continuous monitoring for the OT systems implements a monitoring program that\r\nis consistent with the organizational information security policies and procedures, the OT\r\nsecurity policies and procedures, and the specific health, safety, and environmental risks\r\nassociated with a particular facility and/or process. Continuous monitoring can be automated or\r\nmanual at a frequency sufficient to support risk-based decisions. For example, the organization\r\nmay monitor event logs manually on a specified frequency less often for lower-risk, isolated\r\nsystems than for higher-risk, networked systems.\r\nControl Enhancement: (1) (4) No OT Discussion for this control.\r\nCA-8 PENETRATION TESTING\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nCA-8 Penetration Testing Select\r\nCA-8 (1) PENETRATION TESTING | INDEPENDENT PENETRATION TESTING\r\nAGENT OR TEAM Remove\r\nOT Discussion: Penetration testing is used with care on OT networks to ensure that OT functions\r\nare not adversely impacted by the testing process. In general, OT systems are highly sensitive to\r\ntiming constraints and have limited resources. Example compensating controls include\r\nemploying a replicated, virtualized, or simulated system to conduct penetration testing.\r\nProduction OT may need to be taken offline before testing can be conducted. If OT systems are\r\ntaken offline for testing, tests are scheduled to occur during planned OT outages whenever\r\npossible. If penetration testing is performed on non-OT networks, extra care is taken to ensure\r\nthat tests do not propagate into the OT network.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n243\r\nRationale for removing CA-8 (1) from HIGH baseline: Specific expertise is necessary to conduct\r\neffective penetration testing on OT systems, and it may not be feasible to identify independent\r\npersonnel with the appropriate skillset or knowledge to perform penetration testing on an OT\r\nenvironment. While an independent penetration test agent or team is recommended, it may not be\r\nfeasible for all high-impact OT systems.\r\nCA-9 INTERNAL SYSTEM CONNECTIONS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nCA-9 Internal System Connections Select Select Select\r\nOT Discussion: Organizations perform risk-benefit analysis to determine whether OT equipment\r\nshould be connected to other internal system components and then document those connections.\r\nThe AO fully understands the potential risks associated with approving individual connections or\r\napproving a class of components to be connected. For example, the AO may broadly approve the\r\nconnection of any sensors limited to 4 to 20 milliamp (mA) communication, while other\r\nconnection types (e.g., serial or Ethernet) require individual approval. Decisions to accept risk\r\nare documented.\r\nF.7.5. CONFIGURATION MANAGEMENT – CM\r\nTailoring Considerations for the Configuration Management Family\r\nWhen the OT cannot be configured to restrict the use of unnecessary functions or cannot support\r\nthe use of automated mechanisms to implement configuration management functions, the\r\norganization employs nonautomated mechanisms or procedures as compensating controls in\r\naccordance with the general tailoring guidance. Examples of compensating controls are given\r\nwith each control as appropriate.\r\nCM-1 POLICY AND PROCEDURES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nCM-1 Policy and Procedures Select Select Select\r\nOT Discussion: The policy specifically addresses the unique properties and requirements of OT\r\nand the relationship to non-OT systems.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n244\r\nCM-2 BASELINE CONFIGURATION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nCM-2 Baseline Configuration Select Select Select\r\nCM-2 (2) BASELINE CONFIGURATION | AUTOMATION SUPPORT FOR\r\nACCURACY / CURRENCY Select Select\r\nCM-2 (3) BASELINE CONFIGURATION | RETENTION OF PREVIOUS\r\nCONFIGURATIONS Select Select\r\nCM-2 (7) BASELINE CONFIGURATION | CONFIGURE SYSTEMS, COMPONENTS,\r\nOR DEVICES FOR HIGH-RISK AREAS Select Select\r\nNo OT Discussion for this control.\r\nCM-3 CONFIGURATION CHANGE CONTROL\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nCM-3 Configuration Change Control Select Select\r\nCM-3 (1) CONFIGURATION CHANGE CONTROL | AUTOMATED DOCUMENT /\r\nNOTIFICATION / PROHIBITION OF CHANGES Select\r\nCM-3 (2) CONFIGURATION CHANGE CONTROL | TEST / VALIDATE / DOCUMENT\r\nCHANGES Select Select\r\nCM-3 (4) CONFIGURATION CHANGE CONTROL | SECURITY AND PRIVACY\r\nREPRESENTATIVES Select Select\r\nCM-3 (6) CONFIGURATION CHANGE CONTROL | CRYPTOGRAPHY\r\nMANAGEMENT Select\r\nCM-3 (7) CONFIGURATION CHANGE CONTROL | REVIEW SYSTEM CHANGES\r\nCM-3 (8) CONFIGURATION CHANGE CONTROL | PREVENT OR RESTRICT\r\nCONFIGURATION CHANGES\r\nOT Discussion: Configuration change control procedures should align with the organization’s\r\nmanagement of change practices.\r\nControl Enhancement: (1) (2) (4) (6) No OT Discussion for this control.\r\nControl Enhancement: (7) OT Discussion: The organization considers OT-specific requirements\r\nwhen determining the frequency and/or circumstances for reviewing system changes. For\r\nexample, safety instrumented systems may be justified for the review of system changes on a\r\npredetermined frequency to ensure that no inadvertent changes have been made to the logic\r\nsolver portion of a safety instrumented function.\r\nControl Enhancement: (8) OT Discussion: The organization prevents or restricts configuration\r\nchanges based on a risk determination that the system should not be modified without additional\r\npermission. For example, some PLCs have physical key switches that are used to place the PLC\r\nin a mode that allows for programming changes. Physical key switches can restrict configuration\r\nchanges so that physical access is required to make a modification to the system.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n245\r\nCM-4 IMPACT ANALYSES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nCM-4 Impact Analyses Select Select Select\r\nCM-4 (1) IMPACT ANALYSES | SEPARATE TEST ENVIRONMENTS Select\r\nCM-4 (2) IMPACT ANALYSES | VERIFICATION OF CONTROLS Select Select\r\nOT Discussion: The organization considers OT safety and security interdependencies. OT\r\nsecurity and safety personnel are included in change process management if the change to the\r\nsystem may impact safety or security.\r\nControl Enhancement: (1) (2) No OT Discussion for this control.\r\nCM-5 ACCESS RESTRICTIONS FOR CHANGE\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nCM-5 Access Restrictions for Change Select Select Select\r\nCM-5 (1) ACCESS RESTRICTIONS FOR CHANGE | AUTOMATED ACCESS\r\nENFORCEMENT / AUDITING Select\r\nOT Discussion: Some OT devices allow for the configuration and use of mode change switches.\r\nWhere available, these should be used to prevent unauthorized changes. For example, many\r\nPLCs have key switches that allow the device to be placed in a programming mode or a running\r\nmode. Those PLCs should be placed in a running or remote mode to prevent unauthorized\r\nprogramming changes, and the key should be removed from the key switch and managed\r\nappropriately.\r\nControl Enhancement: (1) No OT Discussion for this control.\r\nCM-6 CONFIGURATION SETTINGS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nCM-6 Configuration Settings Select Select Select\r\nCM-6 (1) CONFIGURATION SETTINGS | AUTOMATED CENTRAL MANAGEMENT /\r\nAPPLICATION / VERIFICATION Select\r\nCM-6 (2) CONFIGURATION SETTINGS | RESPOND TO UNAUTHORIZED\r\nCHANGES Select\r\nNo OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n246\r\nCM-7 LEAST FUNCTIONALITY\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nCM-7 Least Functionality Select Select Select\r\nCM-7 (1) LEAST FUNCTIONALITY | PERIODIC REVIEW Select Select\r\nCM-7 (2) LEAST FUNCTIONALITY | PREVENT PROGRAM EXECUTION Select Select\r\nCM-7 (5) LEAST FUNCTIONALITY | AUTHORIZED SOFTWARE — ALLOW-BY-EXCEPTION Select Select\r\nOT Discussion: The organization implements least functionality by allowing only the specified\r\nfunctions, protocols, and/or services required for OT operations. For non-routable protocols,\r\nsuch as serial communications, interrupts could be disabled or set points could be made read-only except for privileged users to limit functionality. Ports are part of the address space in\r\nnetwork protocols and are often associated with specific protocols or functions. For routable\r\nprotocols, ports can be disabled on many networking devices to limit functionality to the\r\nminimum required for operation.\r\nControl Enhancement: (1) (2) No OT Discussion.\r\nControl Enhancement: (5) OT Discussion: The set of applications that run in OT is relatively\r\nstatic, making allowlisting practical. DHS recommends using application allowlisting for OT\r\nequipment.\r\nCM-8 SYSTEM COMPONENT INVENTORY\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nCM-8 System Component Inventory Select Select Select\r\nCM-8 (1) SYSTEM COMPONENT INVENTORY | UPDATES DURING\r\nINSTALLATIONS / REMOVALS Select Select\r\nCM-8 (2) SYSTEM COMPONENT INVENTORY | AUTOMATED MAINTENANCE Select\r\nCM-8 (3) SYSTEM COMPONENT INVENTORY | AUTOMATED UNAUTHORIZED\r\nCOMPONENT DETECTION Select Select\r\nCM-8 (4) SYSTEM COMPONENT INVENTORY | PROPERTY ACCOUNTABILITY\r\nINFORMATION Select\r\nNo OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n247\r\nCM-9 CONFIGURATION MANAGEMENT PLAN\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nCM-9 Configuration Management Plan Select Select\r\nOT Discussion: Configuration management plans apply to the internal and external (e.g.,\r\ncontractors, integrators) resources responsible for device configuration.\r\nCM-10 SOFTWARE USAGE RESTRICTIONS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nCM-10 Software Usage Restrictions Select Select Select\r\nNo OT Discussion for this control.\r\nCM-11 USER-INSTALLED SOFTWARE\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nCM-11 User-Installed Software Select Select Select\r\nNo OT Discussion for this control.\r\nCM-12 INFORMATION LOCATION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nCM-12 Information Location Select Select\r\nCM-12 (1) INFORMATION LOCATION | AUTOMATED TOOLS TO SUPPORT\r\nINFORMATION LOCATION Select Select\r\nOT Discussion: Organizations identify specific information types or components to track where\r\ninformation is being processed and stored. Information to consider in the OT environment may\r\ninclude shared account passwords, PLC backup files, detailed network drawings, and risk\r\nassessments that identify specific threats with the environment.\r\nControl Enhancement: (1) No OT Discussion for this control.\r\nF.7.6. CONTINGENCY PLANNING – CP\r\nTailoring Considerations for the Contingency Planning Family\r\nOT systems often contain a physical component at a fixed location that may not be relocated\r\nlogically, and some replacement components may not be readily available. The continuance of\r\nessential mission and business functions with little or no loss of operational continuity may not\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n248\r\nbe possible. When the organization cannot provide necessary essential services, support, or\r\nautomated mechanisms during contingency operations, it should provide nonautomated\r\nmechanisms or predetermined procedures as compensating controls in accordance with the\r\ngeneral tailoring guidance. Examples of compensating controls are given with each control as\r\nappropriate.\r\nCP-1 POLICY AND PROCEDURES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nCP-1 Policy and Procedures Select Select Select\r\nOT Discussion: The policy specifically addresses the unique properties and requirements of OT\r\nand the relationship to non-OT systems.\r\nCP-2 CONTINGENCY PLAN\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nCP-2 Contingency Plan Select Select Select\r\nCP-2 (1) CONTINGENCY PLAN | COORDINATE WITH RELATED PLANS Select Select\r\nCP-2 (2) CONTINGENCY PLAN | CAPACITY PLANNING Select\r\nCP-2 (3) CONTINGENCY PLAN | RESUME MISSION AND BUSINESS FUNCTIONS Select Select\r\nCP-2 (5) CONTINGENCY PLAN | CONTINUE MISSION AND BUSINESS\r\nFUNCTIONS Select\r\nCP-2 (8) CONTINGENCY PLAN | IDENTIFY CRITICAL ASSETS Select Select\r\nOT Discussion: The organization defines contingency plans for categories of disruptions or\r\nfailures. In the case of a contingency, the OT equipment executes preprogrammed functions,\r\nsuch as alerting the operator of the failure and then doing nothing, alerting the operator and then\r\nsafely shutting down the industrial process, or alerting the operator and then maintaining the last\r\noperational setting prior to failure. Contingency plans for widespread disruption may involve\r\nspecialized organizations (e.g., FEMA, emergency services, regulatory authorities).\r\nControl Enhancement: (1) (2) (3) (5) (8) No OT Discussion for this control.\r\nCP-3 CONTINGENCY TRAINING\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nCP-3 Contingency Training Select Select Select\r\nCP-3 (1) CONTINGENCY TRAINING | SIMULATED EVENTS Select\r\nNo OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n249\r\nCP-4 CONTINGENCY PLAN TESTING\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nCP-4 Contingency Plan Testing Select Select Select\r\nCP-4 (1) CONTINGENCY PLAN TESTING | COORDINATE WITH RELATED PLANS Select Select\r\nCP-4 (2) CONTINGENCY PLAN TESTING | ALTERNATE PROCESSING SITE Select\r\nNo OT Discussion for this control.\r\nControl Enhancement: (1) No OT Discussion for this control.\r\nControl Enhancement: (2) OT Discussion: Not all systems will have alternate processing sites, as\r\ndiscussed in CP-7.\r\nCP-6 ALTERNATE STORAGE SITE\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nCP-6 Alternate Storage Site Select Select\r\nCP-6 (1) ALTERNATE STORAGE SITE | SEPARATION FROM PRIMARY SITE Select Select\r\nCP-6 (2) ALTERNATE STORAGE SITE | RECOVERY TIME AND RECOVERY POINT\r\nOBJECTIVES Select\r\nCP-6 (3) ALTERNATE STORAGE SITE | ACCESSIBILITY Select Select\r\nNo OT Discussion for this control.\r\nCP-7 ALTERNATE PROCESSING SITE\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nCP-7 Alternate Processing Site Select Select\r\nCP-7 (1) ALTERNATE PROCESSING SITE | SEPARATION FROM PRIMARY SITE Select Select\r\nCP-7 (2) ALTERNATE PROCESSING SITE | ACCESSIBILITY Select Select\r\nCP-7 (3) ALTERNATE PROCESSING SITE | PRIORITY OF SERVICE Select Select\r\nCP-7 (4) ALTERNATE PROCESSING SITE | PREPARATION FOR USE Select\r\nOT Discussion: Many site-wide supervisory or optimization servers (i.e., Level 3 and above of\r\nthe Purdue model) can be supported from an alternate processing site. It is likely not feasible for\r\ncontrol systems or field devices, such as sensors or final elements (i.e., Level 1 and 0 of the\r\nPurdue model), to be made available from an alternate processing site.\r\nControl Enhancement: (1) (2) (3) (4) No OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n250\r\nCP-8 TELECOMMUNICATIONS SERVICES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nCP-8 Telecommunications Services Select Select\r\nCP-8 (1) TELECOMMUNICATIONS SERVICES | PRIORITY OF SERVICE\r\nPROVISIONS Select Select\r\nCP-8 (2) TELECOMMUNICATIONS SERVICES | SINGLE POINTS OF FAILURE Select Select\r\nCP-8 (3) TELECOMMUNICATIONS SERVICES | SEPARATION OF PRIMARY AND\r\nALTERNATE PROVIDERS Select\r\nCP-8 (4) TELECOMMUNICATIONS SERVICES | PROVIDER CONTINGENCY PLAN Select\r\nOT Discussion: Quality of service factors for OT include latency and throughput.\r\nControl Enhancement: (1) (2) (3) (4) No OT Discussion for this control.\r\nCP-9 SYSTEM BACKUP\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nCP-9 System Backup Select Select Select\r\nCP-9 (1) SYSTEM BACKUP | TESTING FOR RELIABILITY AND INTEGRITY Select Select\r\nCP-9 (2) SYSTEM BACKUP | TEST RESTORATION USING SAMPLING Select\r\nCP-9 (3) SYSTEM BACKUP | SEPARATE STORAGE FOR CRITICAL INFORMATION Select\r\nCP-9 (5) SYSTEM BACKUP | TRANSFER TO ALTERNATE STORAGE SITE Select\r\nCP-9 (8) SYSTEM BACKUP | CRYPTOGRAPHIC PROTECTION Select Select\r\nNo OT Discussion for this control.\r\nControl Enhancement: (1) (2) OT Discussion: Testing for reliability and integrity increases\r\nconfidence that the system can be restored after an incident and minimizes the impact associated\r\nwith downtime and outages. The ability to test backups is often dependent on the resources\r\nneeded to appropriately represent the environment, such as the availability of spare devices and\r\ntesting equipment. Testing backup and restoration on OT is often limited to systems with\r\nredundancy or spare equipment. In certain cases, sampling will be limited to those redundant\r\nsystems. Compensating controls may include alternative methods for testing backups, such as\r\nhash or checksum validations.\r\nControl Enhancement: (3) (5) (8) No OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n251\r\nCP-10 SYSTEM RECOVERY AND RECONSTITUTION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nSUPPLEMENTED\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nCP-10 System Recovery and Reconstitution Select Select Select\r\nCP-10 (2) SYSTEM RECOVERY AND RECONSTITUTION | TRANSACTION\r\nRECOVERY Select Select\r\nCP-10 (4) SYSTEM RECOVERY AND RECONSTITUTION | RESTORE WITHIN TIME\r\nPERIOD Select\r\nCP-10 (6) SYSTEM RECOVERY AND RECONSTITUTION | COMPONENT\r\nPROTECTION Add Add\r\nOT Discussion: Reconstitution of the OT includes considering whether system state variables\r\nshould be restored to initial values or the values before disruption (e.g., are valves restored to full\r\nopen, full closed, or settings prior to disruption). Restoring system state variables may be\r\ndisruptive to ongoing physical processes (e.g., valves initially closed may adversely affect\r\nsystem cooling).\r\nControl Enhancement: (2) (4) No OT Discussion for this control.\r\nControl Enhancement: (6) OT Discussion: Organizations should consider recovery and\r\nreconstitution timeframes when storing spare equipment, including environmental hazards that\r\ncould damage the equipment. Storage locations and environments should be chosen\r\nappropriately for the type of backup equipment.\r\nRationale for adding CP-10 (6) to MOD and HIGH baselines: OT system components stored\r\nwithout protection against environmental threats and unauthorized physical or logical access can\r\nbe susceptible to compromise or damage. Certain system components may include embedded\r\nelectronics that must be protected from environmental hazards.\r\nCP-12 SAFE MODE\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nSUPPLEMENTED\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nCP-12 Safe Mode Add Add Add\r\nNo OT Discussion for this control.\r\nRationale for adding CP-12 to LOW, MOD, and HIGH baselines: This control provides a\r\nframework for the organization to plan its policy and procedures for dealing with IT and OT\r\nconditions beyond its control in the environment of operations to minimize potential safety and\r\nenvironmental impacts.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n252\r\nF.7.7. IDENTIFICATION AND AUTHENTICATION – IA\r\nTailoring Considerations for the Identification and Authentication Family\r\nBefore implementing controls in the IA family, consider the trade-offs among security, privacy,\r\nlatency, performance, and throughput. For example, the organization considers whether latency\r\ninduced from the use of authentication mechanisms that employ cryptography would adversely\r\nimpact the operational performance of the OT.\r\nWhen the OT cannot support the specific identification and authentication requirements of a\r\ncontrol, the organization employs compensating controls in accordance with the general tailoring\r\nguidance. Examples of compensating controls are given with each control as appropriate.\r\nIA-1 POLICY AND PROCEDURES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nIA-1 Policy and Procedures Select Select Select\r\nOT Discussion: The policy specifically addresses the unique properties and requirements of OT\r\nand the relationship to non-OT systems.\r\nIA-2 IDENTIFICATION AND AUTHENTICATION (ORGANIZATIONAL USERS)\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nIA-2 Identification and Authentication (Organizational Users) Select Select Select\r\nIA-2 (1) IDENTIFICATION AND AUTHENTICATION | MULTI-FACTOR\r\nAUTHENTICATION TO PRIVILEGED ACCOUNTS Select Select Select\r\nIA-2 (2) IDENTIFICATION AND AUTHENTICATION | MULTI-FACTOR\r\nAUTHENTICATION TO NON-PRIVILEGED ACCOUNTS Select Select Select\r\nIA-2 (5) IDENTIFICATION AND AUTHENTICATION | INDIVIDUAL\r\nAUTHENTICATION WITH GROUP AUTHENTICATION Select\r\nIA-2 (8) IDENTIFICATION AND AUTHENTICATION | ACCESS TO ACCOUNTS -\r\nREPLAY RESISTANT Select Select Select\r\nIA-2 (12) IDENTIFICATION AND AUTHENTICATION | ACCEPTANCE OF PIV\r\nCREDENTIALS Select Select Select\r\nOT Discussion: When shared accounts are required, compensating controls include providing\r\nincreased physical security, personnel security, and auditing measures. For certain OT, the\r\ncapability for immediate operator interaction is critical. Local emergency actions for OT are not\r\nhampered by identification or authentication requirements. Access to these systems may be\r\nrestricted by appropriate physical controls.\r\nControl Enhancement: (1) (2) OT Discussion: As a compensating control, physical access\r\nrestrictions may sufficiently represent one authentication factor, provided that the system is not\r\nremotely accessible.\r\nControl Enhancement: (5) OT Discussion: For local access, physical access controls and logging\r\nmay be used as an alternative to individual authentication on an OT system. For remote access,\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n253\r\nthe remote access authentication mechanism will be used to identify, permit, and log individual\r\naccess before permitting the use of shared accounts.\r\nControl Enhancement: (8) No OT Discussion for this control.\r\nControl Enhancement: (12) OT Discussion: The acceptance of PIV credentials is only required\r\nfor federal organizations, as defined by OMB Memorandum M-19-17 [OMB-M1917]. Non-federal organizations should refer to IA-2 (1) (2) for guidance on multi-factor authentication\r\ncredentials. Furthermore, many OT systems do not have the ability to accept PIV credentials and\r\nwill require compensating controls.\r\nIA-3 DEVICE IDENTIFICATION AND AUTHENTICATION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nSUPPLEMENTED\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nIA-3 Device Identification and Authentication Add Select Select\r\nIA-3 (1) DEVICE IDENTIFICATION AND AUTHENTICATION | CRYPTOGRAPHIC\r\nBIDIRECTIONAL AUTHENTICATION\r\nIA-3 (4) DEVICE IDENTIFICATION AND AUTHENTICATION | DEVICE\r\nATTESTATION\r\nOT Discussion: OT devices may not inherently support device authentication. If devices are local\r\nto one another, physical security measures that prevent unauthorized communication between\r\ndevices can be used as compensating controls. For remote communication, additional hardware\r\nmay be required to meet authentication requirements.\r\nControl Enhancement: (1) (4) OT Discussion: For OT systems that include IIoT devices, these\r\nenhancements may be needed to protect device-to-device communication.\r\nRationale for adding IA-3 to LOW baseline: Given the variety of OT devices and physical\r\nlocations of OT devices, organizations may consider whether OT devices that may be vulnerable\r\nto tampering or spoofing require unique identification and authentication and for what types of\r\nconnections.\r\nIA-4 IDENTIFIER MANAGEMENT\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nIA-4 Identifier Management Select Select Select\r\nIA-4 (4) IDENTIFIER MANAGEMENT | IDENTIFY USER STATUS Select Select\r\nNo OT Discussion for this control.\r\nControl Enhancement: (4) OT Discussion: This control enhancement is typically implemented by\r\nthe organization rather than at the system level. However, to manage risk for certain OT\r\nenvironments, identifiers (e.g., badges) may have different markings to indicate the status of\r\nindividuals, such as contractors, foreign nationals, and non-organizational users.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n254\r\nIA-5 AUTHENTICATOR MANAGEMENT\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nIA-5 Authenticator Management Select Select Select\r\nIA-5 (1) AUTHENTICATOR MANAGEMENT | PASSWORD-BASED\r\nAUTHENTICATION Select Select Select\r\nIA-5 (2) AUTHENTICATOR MANAGEMENT | PUBLIC KEY-BASED\r\nAUTHENTICATION Select Select\r\nIA-5 (6) AUTHENTICATOR MANAGEMENT | PROTECTION OF\r\nAUTHENTICATORS Select Select\r\nOT Discussion: Example compensating controls include physical access control and\r\nencapsulating the OT to provide authentication external to the OT.\r\nControl Enhancement: (1) (2) (6) No OT Discussion for this control.\r\nIA-6 AUTHENTICATION FEEDBACK\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nIA-6 Authentication Feedback Select Select Select\r\nOT Discussion: This control assumes a visual interface that provides feedback about\r\nauthentication information during the authentication process. When OT authentication uses an\r\ninterface that does not support visual feedback (e.g., protocol-based authentication), this control\r\nmay be tailored out.\r\nIA-7 CRYPTOGRAPHIC MODULE AUTHENTICATION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nIA-7 Cryptographic Module Authentication Select Select Select\r\nNo OT Discussion for this control.\r\nIA-8 IDENTIFICATION AND AUTHENTICATION (NON-ORGANIZATIONAL USERS)\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nIA-8 Identification and Authentication (Non-Organizational\r\nUsers) Select Select Select\r\nIA-8 (1)\r\nIDENTIFICATION AND AUTHENTICATION (NON-ORGANIZATIONAL\r\nUSERS) | ACCEPTANCE OF PIV CREDENTIALS FROM OTHER\r\nAGENCIES\r\nSelect Select Select\r\nIA-8 (2) IDENTIFICATION AND AUTHENTICATION (NON-ORGANIZATIONAL\r\nUSERS) | ACCEPTANCE OF EXTERNAL AUTHENTICATORS Select Select Select\r\nIA-8 (4) IDENTIFICATION AND AUTHENTICATION (NON-ORGANIZATIONAL\r\nUSERS) | USE OF DEFINED PROFILES Select Select Select\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n255\r\nOT Discussion: The OT Discussion for IA-2, Identification and Authentication (Organizational\r\nUsers) is applicable for non-organizational users.\r\nControl Enhancement: (1) OT Discussion: Acceptance of PIV credentials is only required for\r\norganizations that follow OMB Memorandum M-19-17 [OMB-M1917] (e.g., federal agencies\r\nand contractors).\r\nControl Enhancement: (2) (4) OT Discussion: Example compensating controls include\r\nimplementing support external to the OT and multi-factor authentication.\r\nIA-11 RE-AUTHENTICATION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nIA-11 Re-authentication Select Select Select\r\nNo OT Discussion for this control.\r\nIA-12 IDENTITY PROOFING\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nSUPPLEMENTED\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nIA-12 Identity Proofing Select Select\r\nIA-12 (1) IDENTITY PROOFING | SUPERVISOR AUTHORIZATION Add\r\nIA-12 (2) IDENTITY PROOFING | IDENTITY EVIDENCE Select Select\r\nIA-12 (3) IDENTITY PROOFING | IDENTITY EVIDENCE VALIDATION AND\r\nVERIFICATION Select Select\r\nIA-12 (4) IDENTITY PROOFING | IN-PERSON VALIDATION AND VERIFICATION Select\r\nIA-12 (5) IDENTITY PROOFING | ADDRESS CONFIRMATION Select Select\r\nOT Discussion: Identity proofing is likely performed by different departments within the\r\norganization. Existing organizational systems (e.g., HR or IT processes) should be leveraged to\r\nperform this control.\r\nControl Enhancement: (1) OT Discussion: Maintenance, engineering, or third-party\r\norganizations may require OT access in order to support operations. The organization should\r\ndetermine the AO for proving identity prior to allowing access to the OT environment. Consider\r\nobtaining supervisor or sponsor authorization, where the sponsor may be someone within\r\noperations.\r\nControl Enhancement: (2) (3) (4) (5) OT Discussion: If the organization already performs these\r\ncontrols, existing organizational processes should be leveraged. For example, HR may provide a\r\nsystem for tracking identity evidence. OT does not need to develop an independent system for\r\nachieving this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n256\r\nRationale for adding IA-12 (1) to HIGH baseline: A supervisor or sponsor should be made aware\r\nof any access that an employee has to the OT environment since unauthorized or accidental\r\naccess could affect the physical process.\r\nF.7.8. INCIDENT RESPONSE – IR\r\nTailoring Considerations for the Incident Response Family\r\nThe automated mechanisms used to support the tracking of security incidents are typically not\r\npart of or connected to the OT.\r\nIR-1 POLICY AND PROCEDURES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nIR-1 Policy and Procedures Select Select Select\r\nOT Discussion: The policy specifically addresses the unique properties and requirements of OT\r\nand the relationship to non-OT systems.\r\nIR-2 INCIDENT RESPONSE TRAINING\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nIR-2 Incident Response Training Select Select Select\r\nIR-2 (1) INCIDENT RESPONSE TRAINING | SIMULATED EVENTS Select\r\nIR-2 (2) INCIDENT RESPONSE TRAINING | AUTOMATED TRAINING ENVIRONMENTS Select\r\nNo OT Discussion for this control.\r\nIR-3 INCIDENT RESPONSE TESTING\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nIR-3 Incident Response Testing Select Select\r\nIR-3 (2) INCIDENT RESPONSE TESTING | COORDINATION WITH RELATED\r\nPLANS Select Select\r\nNo OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n257\r\nIR-4 INCIDENT HANDLING\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nIR-4 Incident Handling Select Select Select\r\nIR-4 (1) INCIDENT HANDLING | AUTOMATED INCIDENT HANDLING\r\nPROCESSES Select Select\r\nIR-4 (4) INCIDENT HANDLING | INFORMATION CORRELATION Select\r\nIR-4 (11) INCIDENT HANDLING | INTEGRATED INCIDENT RESPONSE TEAM Select\r\nOT Discussion: As part of the incident handling capability, the organization coordinates with\r\nexternal vendors, integrators, or suppliers as necessary to ensure that they have the capability to\r\naddress events that are specific to embedded components and devices.\r\nControl Enhancement: (1) (4) (11) No OT Discussion for this control.\r\nIR-5 INCIDENT MONITORING\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nIR-5 Incident Monitoring Select Select Select\r\nIR-5 (1) INCIDENT MONITORING | AUTOMATED TRACKING, DATA\r\nCOLLECTION, AND ANALYSIS Select\r\nNo OT Discussion for this control.\r\nIR-6 INCIDENT REPORTING\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nIR-6 Incident Reporting Select Select Select\r\nIR-6 (1) INCIDENT REPORTING | AUTOMATED REPORTING Select Select\r\nIR-6 (3) INCIDENT REPORTING | SUPPLY CHAIN COORDINATION Select Select\r\nOT Discussion: The organization should report incidents on a timely basis. CISA collaborates\r\nwith international and private-sector computer emergency response teams (CERTs) to share\r\ncontrol systems-related security incidents and mitigation measures.\r\nControl Enhancement: (1) OT Discussion: The automated mechanisms used to support the\r\nincident reporting process are not necessarily part of or connected to the OT.\r\nControl Enhancement: (3) No OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n258\r\nIR-7 INCIDENT RESPONSE ASSISTANCE\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nIR-7 Incident Response Assistance Select Select Select\r\nIR-7 (1) INCIDENT RESPONSE ASSISTANCE | AUTOMATION SUPPORT FOR\r\nAVAILABILITY OF INFORMATION AND SUPPORT Select Select\r\nNo OT Discussion for this control.\r\nIR-8 INCIDENT RESPONSE PLAN\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nIR-8 Incident Response Plan Select Select Select\r\nNo OT Discussion for this control.\r\nF.7.9. MAINTENANCE – MA\r\nTailoring Considerations for the Maintenance Family\r\nThe automated mechanisms used to schedule, conduct, and document maintenance and repairs\r\nare not necessarily part of or connected to the OT.\r\nWhen the OT cannot support the specific maintenance requirements of a control, the\r\norganization employs compensating controls in accordance with the general tailoring guidance.\r\nExamples of compensating controls are given with each control as appropriate.\r\nMA-1 POLICY AND PROCEDURES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nMA-1 Policy and Procedures Select Select Select\r\nOT Discussion: The policy specifically addresses the unique properties and requirements of OT\r\nand the relationship to non-OT systems.\r\nMA-2 CONTROLLED MAINTENANCE\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nMA-2 Controlled Maintenance Select Select Select\r\nMA-2 (2) CONTROLLED MAINTENANCE | AUTOMATED MAINTENANCE\r\nACTIVITIES Select\r\nNo OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n259\r\nMA-3 MAINTENANCE TOOLS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nMA-3 Maintenance Tools Select Select\r\nMA-3 (1) MAINTENANCE TOOLS | INSPECT TOOLS Select Select\r\nMA-3 (2) MAINTENANCE TOOLS | INSPECT MEDIA Select Select\r\nMA-3 (3) MAINTENANCE TOOLS | PREVENT UNAUTHORIZED REMOVAL Select Select\r\n No OT Discussion for this control.\r\nMA-4 NONLOCAL MAINTENANCE\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nSUPPLEMENTED\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nMA-4 Nonlocal Maintenance Select Select Select\r\nMA-4 (1) NONLOCAL MAINTENANCE | LOGGING AND REVIEW Add Add\r\nMA-4 (3) NONLOCAL MAINTENANCE | COMPARABLE SECURITY AND\r\nSANITIZATION Select\r\nNo OT Discussion for this control.\r\nControl Enhancement: (1) No OT Discussion for this control.\r\nControl Enhancement: (3) OT Discussion: The organization may need access to nonlocal\r\nmaintenance and diagnostic services in order to restore essential OT operations or services.\r\nExample compensating controls include limiting the extent of the maintenance and diagnostic\r\nservices to the minimum essential activities and carefully monitoring and auditing the nonlocal\r\nmaintenance and diagnostic activities.\r\nRationale for adding MA-4 (1) to MOD and HIGH baselines: OT environments are often heavily\r\ndependent on nonlocal maintenance providers, so organizations should have the ability to review\r\nlogs about relevant maintenance activities.\r\nMA-5 MAINTENANCE PERSONNEL\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nMA-5 Maintenance Personnel Select Select Select\r\nMA-5 (1) MAINTENANCE PERSONNEL | INDIVIDUALS WITHOUT APPROPRIATE\r\nACCESS Select\r\nNo OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n260\r\nMA-6 TIMELY MAINTENANCE\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nMA-6 Timely Maintenance Select Select\r\nNo OT Discussion for this control.\r\nMA-7 FIELD MAINTENANCE\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nSUPPLEMENTED\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nMA-7 Field Maintenance Add Add Add\r\nOT Discussion: Organizations identify OT systems and system components with specific\r\ncalibration, maintenance, or other requirements and limit maintenance to specific facilities. Some\r\nexamples may include safety-critical systems or systems involved in custody transfer where\r\naccuracy tolerances are limited and additional quality control checks are required.\r\nRationale for adding MA-7 to LOW, MOD, and HIGH baselines: Some OT equipment have\r\nspecific requirements for calibration, maintenance, and modification to meet regulatory or safety\r\nstandards. Different deployed locations may impact the quality and precision of field\r\nmaintenance.\r\nF.7.10. MEDIA PROTECTION –MP\r\nMP-1 POLICY AND PROCEDURES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nMP-1 Policy and Procedures Select Select Select\r\nOT Discussion: The policy specifically addresses the unique properties and requirements of OT\r\nand the relationship to non-OT systems.\r\nMP-2 MEDIA ACCESS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nMP-2 Media Access Select Select Select\r\nNo OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n261\r\nMP-3 MEDIA MARKING\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nMP-3 Media Marking Select Select\r\nNo OT Discussion for this control.\r\nMP-4 MEDIA STORAGE\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nMP-4 Media Storage Select Select\r\nNo OT Discussion for this control.\r\nMP-5 MEDIA TRANSPORT\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nMP-5 Media Transport Select Select\r\nNo OT Discussion for this control.\r\nMP-6 MEDIA SANITIZATION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nMP-6 Media Sanitization Select Select Select\r\nMP-6 (1) MEDIA SANITIZATION | REVIEW, APPROVE, TRACK, DOCUMENT, AND\r\nVERIFY Select\r\nMP-6 (2) MEDIA SANITIZATION | EQUIPMENT TESTING Select\r\nMP-6 (3) MEDIA SANITIZATION | NONDESTRUCTIVE TECHNIQUES Select\r\nNo OT Discussion for this control.\r\nMP-7 MEDIA USE\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nMP-7 Media Use Select Select Select\r\nNo OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n262\r\nF.7.11. PHYSICAL AND ENVIRONMENTAL PROTECTION – PE\r\nTailoring Considerations for the Physical and Environmental Protection Family\r\nPhysical and environmental protections are often used as a compensating control for many OT\r\nsystems, so physical and environmental protection controls are especially important. Any\r\nselected compensating control mitigates risk to an acceptable level.\r\n \r\nPE-1 POLICY AND PROCEDURES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPE-1 Policy and Procedures Select Select Select\r\nOT Discussion: The policy specifically addresses the unique properties and requirements of OT\r\nand the relationship to non-OT systems. The OT components can be distributed over a large\r\nfacility footprint or geographic area and can be an entry point into the entire organizational\r\nnetwork OT. Regulatory controls may also apply.\r\nPE-2 PHYSICAL ACCESS AUTHORIZATIONS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPE-2 Physical Access Authorizations Select Select Select\r\nNo OT Discussion for this control.\r\nPE-3 PHYSICAL ACCESS CONTROL\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPE-3 Physical Access Control Select Select Select\r\nPE-3 (1) PHYSICAL ACCESS CONTROL | SYSTEM ACCESS Select\r\nOT Discussion: The organization considers OT safety and security interdependencies and access\r\nrequirements in emergency situations. During an emergency, the organization may restrict access\r\nto OT facilities and assets to authorized individuals only. OT systems are often constructed of\r\ndevices that do not have or cannot use comprehensive access control capabilities due to time-restrictive safety constraints. Physical access controls and defense-in-depth measures are used by\r\nthe organization when necessary and possible to supplement OT security when electronic\r\nmechanisms are unable to fulfill the security requirements of the organization’s security plan.\r\nControl Enhancement: (1) No OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n263\r\nPE-4 ACCESS CONTROL FOR TRANSMISSION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPE-4 Access Control for Transmission Select Select\r\nNo OT Discussion for this control.\r\n \r\nPE-5 ACCESS CONTROL FOR OUTPUT DEVICES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPE-5 Access Control for Output Devices Select Select\r\nNo OT Discussion for this control.\r\nPE-6 MONITORING PHYSICAL ACCESS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nSUPPLEMENTED\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPE-6 Monitoring Physical Access Select Select Select\r\nPE-6 (1) MONITORING PHYSICAL ACCESS | INTRUSION ALARMS AND\r\nSURVEILLANCE EQUIPMENT Select Select\r\nPE-6 (4) MONITORING PHYSICAL ACCESS | MONITORING PHYSICAL ACCESS\r\nTO SYSTEMS Add Select\r\nNo OT Discussion for this control.\r\nControl Enhancement: (1) (4) No OT Discussion for this control.\r\nRationale for adding PE-6 (4) to MOD baseline: Many of the OT components are in remote\r\ngeographical and dispersed locations. Other components may be in ceilings, floors, or\r\ndistribution closets. Furthermore, physical access controls are frequently used as compensating\r\ncontrols when devices lack the ability to enforce logical access restrictions.\r\nPE-8 VISITOR ACCESS RECORDS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPE-8 Visitor Access Records Select Select Select\r\nPE-8 (1) VISITOR ACCESS RECORDS | AUTOMATED RECORDS MAINTENANCE\r\nAND REVIEW Select\r\nNo OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n264\r\nPE-9 POWER EQUIPMENT AND CABLING\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPE-9 Power Equipment and Cabling Select Select\r\nNo OT Discussion for this control.\r\n \r\nPE-10 EMERGENCY SHUTOFF\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPE-10 Emergency Shutoff Select Select\r\nOT Discussion: It may not be possible or advisable to shut off power to some OT. The\r\norganizational-defined parameters for this control should be implemented in consultation with\r\nsafety and operational personnel. Example compensating controls include failing to a known\r\nstate and emergency procedures.\r\nPE-11 EMERGENCY POWER\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nSUPPLEMENTED\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPE-11 Emergency Power Select Select\r\nPE-11 (1) EMERGENCY POWER | ALTERNATE POWER SUPPLY - MINIMAL\r\nOPERATIONAL CAPABILITY Select\r\nPE-11 (2) EMERGENCY POWER | ALTERNATE POWER SUPPLY - SELF-CONTAINED\r\nNo OT Discussion for this control.\r\nPE-12 EMERGENCY LIGHTING\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPE-12 Emergency Lighting Select Select Select\r\nNo OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n265\r\nPE-13 FIRE PROTECTION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPE-13 Fire Protection Select Select Select\r\nPE-13 (1) FIRE PROTECTION | DETECTION SYSTEMS – AUTOMATIC ACTIVATION\r\nAND NOTIFICATION Select Select\r\nPE-13 (2) FIRE PROTECTION | SUPPRESSION SYSTEMS – AUTOMATIC\r\nACTIVATION AND NOTIFICATION Select\r\nOT Discussion: Fire suppression mechanisms should take the OT environment into account (e.g.,\r\nwater sprinkler systems could be hazardous in specific environments).\r\nControl Enhancement: (1) (2) No OT Discussion for this control.\r\nPE-14 ENVIRONMENTAL CONTROLS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPE-14 Environmental Controls Select Select Select\r\nOT Discussion: Temperature and humidity controls are typically components of other OT\r\nsystems (e.g., HVAC, process, or lighting systems) or can be a stand-alone and unique OT\r\nsystem. OT can operate in extreme environments and both interior and exterior locations. For a\r\nspecific OT, the temperature and humidity design and operational parameters dictate the\r\nperformance specifications. Power circuits, distribution closets, routers, and switches that\r\nsupport fire protection and life safety systems must be maintained at the proper temperature and\r\nhumidity. When environmental controls cannot be implemented, use hardware that is engineered\r\nto withstand the OT’s unique environmental hazards.\r\nPE-15 WATER DAMAGE PROTECTION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPE-15 Water Damage Protection Select Select Select\r\nPE-15 (1) WATER DAMAGE PROTECTION | AUTOMATION SUPPORT Select\r\nOT Discussion: Water damage protection and the use of shutoff and isolation valves are\r\nprocedural actions and specific types of OT. OT used in the manufacturing, hydropower,\r\ntransportation/navigation, water, and wastewater industries rely on the movement of water and\r\nare specifically designed to manage the quantity, flow, and pressure of water. Power circuits,\r\ndistribution closets, routers, and switches that support fire protection and life safety systems\r\nshould ensure that water will not disable the system (e.g., a fire that activates the sprinkler\r\nsystem does not spray onto the fire control servers, routers, or switches or short out the alarms,\r\negress systems, emergency lighting, or suppression systems).\r\nControl Enhancement: (1) No OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n266\r\nPE-16 DELIVERY AND REMOVAL\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPE-16 Delivery and Removal Select Select Select\r\nNo OT Discussion for this control.\r\nPE-17 ALTERNATE WORK SITE\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPE-17 Alternate Work Site Select Select\r\nNo OT Discussion for this control.\r\nPE-18 LOCATION OF SYSTEM COMPONENTS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPE-18 Location of System Components Select\r\nNo OT Discussion for this control.\r\nPE-21 ELECTROMAGNETIC PULSE PROTECTION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPE-21 Electromagnetic Pulse Protection\r\nOT Discussion: Organizations that manage OT equipment may choose to utilize EMP protection\r\nto prevent adversarial or environmental electromagnetic threats. Organizations may select to\r\nfollow National Coordinating Center for Communications (NCC) guidelines on EM pulse\r\nprotection.\r\nPE-22 COMPONENT MARKING\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nSUPPLEMENTED\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPE-22 Component Marking Add Add\r\nOT Discussion: Hardware components are marked or labeled to indicate information that is\r\nprocessed, stored, or transmitted. Component markings can be useful for differentiating between\r\nsafety and control systems, OT and IT equipment, and internally and externally connected\r\nsystems. Marking components reduces the probability of mismanaging the system or performing\r\nmaintenance on an incorrect device.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n267\r\nRationale for adding PE-22 to MOD and HIGH baselines: OT is unique in that it may look like\r\nan IT component but perform a very different function. Visible differentiation between\r\ncomponents that perform different functions can help reduce reliability incidents due to\r\nmaintenance errors.\r\nF.7.12. PLANNING – PL\r\nPL-1 POLICY AND PROCEDURES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPL-1 Policy and Procedures Select Select Select\r\nOT Discussion: The policy specifically addresses the unique properties and requirements of OT\r\nand the relationship to non-OT systems.\r\nPL-2 SYSTEM SECURITY AND PRIVACY PLANS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPL-2 System Security and Privacy Plans Select Select Select\r\nOT Discussion: When systems are highly interconnected, coordinated planning is essential. A\r\nlow-impact system could adversely affect a higher-impact system.\r\nPL-4 RULES OF BEHAVIOR\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPL-4 Rules of Behavior Select Select Select\r\nPL-4 (1) RULES OF BEHAVIOR | SOCIAL MEDIA AND EXTERNAL SITE /\r\nAPPLICATION USAGE RESTRICTIONS Select Select Select\r\nNo OT Discussion for this control.\r\nPL-7 CONCEPT OF OPERATIONS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nSUPPLEMENTED\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPL-7 Concept of Operations\r\nOT Discussion: Organizations need to consider documenting known operational procedures and\r\nexploring how they relate to the combination of IT and OT technologies within the environment.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n268\r\nPL-8 SECURITY AND PRIVACY ARCHITECTURES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nSUPPLEMENTED\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPL-8 Security and Privacy Architectures Select Select\r\nPL-4 (1) SECURITY AND PRIVACY ARCHITECTURES | DEFENSE IN DEPTH\r\nNo OT Discussion for this control.\r\nControl Enhancement: (1) OT Discussion: Defense in depth is considered a common practice for\r\nsecurity architecture within OT environments.\r\nPL-9 CENTRAL MANAGEMENT\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPL-9 Central Management\r\nOT Discussion: If the architecture allows for it, consider centrally managing flaw remediation,\r\nmalicious code protection, logging, and incident detection.\r\nPL-10 BASELINE SELECTION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPL-10 Baseline Selection Select Select Select\r\nNo OT Discussion for this control.\r\nPL-11 BASELINE TAILORING\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPL-11 Baseline Tailoring Select Select Select\r\nNo OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n269\r\nF.7.13. ORGANIZATION-WIDE INFORMATION SECURITY PROGRAM\r\nMANAGEMENT CONTROLS – PM\r\nCharacteristics of the Organization-Wide Information Security Program Management\r\nControl Family\r\nOrganization-wide information security program management controls are deployed to support\r\nthe information security program. They are not associated with control baselines and are\r\nindependent of any system impact level.\r\nProgram management controls should specifically address the unique properties and\r\nrequirements of OT, the relationship to non-OT systems, and the relationship to other programs\r\nconcerned with the operational characteristics of OT (e.g., safety, efficiency, reliability,\r\nresilience). To achieve this, the security program should utilize interdisciplinary teams that can\r\nhelp reconcile and balance conflicting equities, objectives, and responsibilities, such as\r\ncapability, adaptability, resilience, safety, security, usability, and efficiency.\r\nPM-1 INFORMATION SECURITY PROGRAM PLAN\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nPM-1 Information Security Program Plan\r\nNo OT Discussion for this control.\r\nPM-2 INFORMATION SECURITY PROGRAM LEADERSHIP ROLE\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nPM-2 Information Security Program Leadership Role\r\nNo OT Discussion for this control.\r\nPM-3 INFORMATION SECURITY AND PRIVACY RESOURCES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nPM-3 Information Security and Privacy Resources\r\nNo OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n270\r\nPM-4 PLAN OF ACTION AND MILESTONES PROCESS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nPM-4 Plan of Action and Milestones Process\r\nNo OT Discussion for this control.\r\nPM-5 SYSTEM INVENTORY\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nPM-5 System Inventory\r\nNo OT Discussion for this control.\r\nPM-6 MEASURES OF PERFORMANCE\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nPM-6 Measures of Performance\r\nNo OT Discussion for this control.\r\nPM-7 ENTERPRISE ARCHITECTURE\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nPM-7 Enterprise Architecture\r\nNo OT Discussion for this control.\r\nPM-8 CRITICAL INFRASTRUCTURE PLAN\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nPM-8 Critical Infrastructure Plan\r\nOT Discussion: Organizations should be familiar with the protection requirements and guidance\r\ndefined by Executive Orders, government sector-specific agencies (SSAs), and industry trade\r\norganizations.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n271\r\nPM-9 RISK MANAGEMENT STRATEGY\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nPM-9 Risk Management Strategy\r\nNo OT Discussion for this control.\r\nPM-10 AUTHORIZATION PROCESS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nPM-10 Authorization Process\r\nNo OT Discussion for this control.\r\nPM-11 MISSION AND BUSINESS PROCESS DEFINITION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nPM-11 Mission and Business Process Definition\r\nNo OT Discussion for this control.\r\nPM-12 INSIDER THREAT PROGRAM\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nPM-12 Insider Threat Program\r\nNo OT Discussion for this control.\r\nPM-13 SECURITY AND PRIVACY WORKFORCE\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nPM-13 Security and Privacy Workforce\r\nNo OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n272\r\nPM-14 TESTING, TRAINING, AND MONITORING\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nPM-14 Testing, Training, and Monitoring\r\nNo OT Discussion for this control.\r\nPM-15 SECURITY AND PRIVACY GROUPS AND ASSOCIATIONS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nPM-15 Security and Privacy Groups and Associations\r\nOT Discussion: Organizations should be familiar with relevant security-focused and industry-specific groups or associations, including government sector-specific agencies (SSAs),\r\nInformation Sharing and Analysis Centers (ISACs), and industry trade organizations.\r\nPM-16 THREAT AWARENESS PROGRAM\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nPM-16 Threat Awareness Program\r\nOT Discussion: The organization should collaborate and share information about potential\r\nincidents on a timely basis. CISA serves as a centralized location where operational elements\r\ninvolved in cybersecurity and communications reliance are coordinated and integrated.\r\nOrganizations should consider having both an unclassified and classified information sharing\r\ncapability.\r\nPM-17 PROTECTING CONTROLLED UNCLASSIFIED INFORMATION ON EXTERNAL SYSTEMS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nPM-17 Protecting Controlled Unclassified Information on External Systems\r\nOT Discussion: This control applies to federal agencies and other organizations that support the\r\nGovernment and process controlled unclassified information (CUI).\r\nPM-18 PRIVACY PROGRAM PLAN\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nPM-18 Privacy Program Plan\r\nNo OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n273\r\nPM-19 PRIVACY PROGRAM LEADERSHIP ROLE\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nPM-19 Privacy Program Leadership Role\r\nNo OT Discussion for this control.\r\nPM-20 DISSEMINATION OF PRIVACY PROGRAM INFORMATION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nPM-20 Dissemination of Privacy Program Information\r\nPM-20 (1) DISSEMINATION OF PRIVACY PROGRAM INFORMATION | PRIVACY POLICIES ON WEBSITES, APPLICATIONS,\r\nAND DIGITAL SERVICES\r\nNo OT Discussion for this control.\r\nPM-21 ACCOUNTING OF DISCLOSURES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nPM-21 Accounting of Disclosures\r\nNo OT Discussion for this control.\r\nPM-22 PERSONALLY IDENTIFIABLE INFORMATION QUALITY MANAGEMENT\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nPM-22 Personally Identifiable Information Quality Management\r\nNo OT Discussion for this control.\r\nPM-23 DATA GOVERNANCE BODY\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nPM-23 Data Governance Body\r\nNo OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n274\r\nPM-24 DATA INTEGRITY BOARD\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nPM-24 Data Integrity Board\r\nNo OT Discussion for this control.\r\nPM-25 MINIMIZATION OF PERSONALLY IDENTIFIABLE INFORMATION USED IN TESTING,\r\nTRAINING, AND RESEARCH\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nPM-25 Minimization of Personally Identifiable Information Used in Testing, Training, and\r\nResearch\r\nNo OT Discussion for this control.\r\nPM-26 COMPLAINT MANAGEMENT\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nPM-26 Complaint Management\r\nNo OT Discussion for this control.\r\nPM-27 PRIVACY REPORTING\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nPM-27 Privacy Reporting\r\nNo OT Discussion for this control.\r\nPM-28 RISK FRAMING\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nPM-28 Risk Framing\r\nNo OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n275\r\nPM-29 RISK MANAGEMENT PROGRAM LEADERSHIP ROLES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nPM-29 Risk Management Program Leadership Roles\r\nNo OT Discussion for this control.\r\nPM-30 SUPPLY CHAIN RISK MANAGEMENT STRATEGY\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nPM-30 Supply Chain Risk Management Strategy\r\nPM-30 (1) SUPPLY CHAIN RISK MANAGEMENT STRATEGY | SUPPLIERS OF CRITICAL OR MISSION-ESSENTIAL ITEMS\r\nNo OT Discussion for this control.\r\nPM-31 CONTINUOUS MONITORING STRATEGY\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nPM-31 Continuous Monitoring Strategy\r\nNo OT Discussion for this control.\r\nPM-32 PURPOSING\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nPM-32 Purposing\r\nNo OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n276\r\nF.7.14. PERSONNEL SECURITY – PS\r\nTailoring Considerations for the Personnel Security Family\r\nPersonnel security controls require collaboration between OT, IT, security, and HR personnel.\r\nPS-1 POLICY AND PROCEDURES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPS-1 Policy and Procedures Select Select Select\r\nOT Discussion: The policy specifically addresses the unique properties and requirements of OT\r\nand the relationship to non-OT systems.\r\nPS-2 POSITION RISK DESIGNATION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPS-2 Position Risk Designation Select Select Select\r\nOT Discussion: Private organizations should utilize existing sector-specific regulations, laws,\r\npolicy, and guidance for determining appropriate risk designations for positions.\r\nPS-3 PERSONNEL SCREENING\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPS-3 Personnel Screening Select Select Select\r\nNo OT Discussion for this control.\r\nPS-4 PERSONNEL TERMINATION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPS-4 Personnel Termination Select Select Select\r\nPS-4 (2) PERSONNEL TERMINATION | AUTOMATED ACTIONS Select\r\nNo OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n277\r\nPS-5 PERSONNEL TRANSFER\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPS-5 Personnel Transfer Select Select Select\r\nNo OT Discussion for this control.\r\nPS-6 ACCESS AGREEMENTS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPS-6 Access Agreements Select Select Select\r\nNo OT Discussion for this control.\r\nPS-7 EXTERNAL PERSONNEL SECURITY\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPS-7 External Personnel Security Select Select Select\r\nNo OT Discussion for this control.\r\nPS-8 PERSONNEL SANCTIONS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPS-8 Personnel Sanctions Select Select Select\r\nNo OT Discussion for this control.\r\nPS-9 POSITION DESCRIPTIONS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nPS-9 Position Descriptions Select Select Select\r\nNo OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n278\r\nF.7.15. RISK ASSESSMENT – RA\r\nMany OT organizations have well-established risk assessment programs that can be leveraged\r\nfor cybersecurity risk analysis.\r\nRA-1 POLICY AND PROCEDURES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nRA-1 Policy and Procedures Select Select Select\r\nOT Discussion: The policy specifically addresses the unique properties and requirements of OT\r\nand the relationship to non-OT systems.\r\nRA-2 SECURITY CATEGORIZATION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nRA-2 Security Categorization Select Select Select\r\nOT Discussion: PHA, functional safety assessments, and other organization-established risk\r\nassessments can be referenced to identify the impact level of the OT systems.\r\nRA-3 RISK ASSESSMENT\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nRA-3 Risk Assessment Select Select Select\r\nRA-3 (1) RISK ASSESSMENT | SUPPLY CHAIN RISK ASSESSMENT Select Select Select\r\nNo OT Discussion for this control.\r\nRA-5 VULNERABILITY MONITORING AND SCANNING\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nRA-5 Vulnerability Monitoring and Scanning Select Select Select\r\nRA-5 (2) VULNERABILITY MONITORING AND SCANNING | UPDATE\r\nVULNERABILITIES TO BE SCANNED Select Select Select\r\nRA-5 (4) VULNERABILITY MONITORING AND SCANNING | DISCOVERABLE\r\nINFORMATION Select\r\nRA-5 (5) VULNERABILITY MONITORING AND SCANNING | PRIVILEGED ACCESS Select Select\r\nRA-5\r\n(11)\r\nVULNERABILITY MONITORING AND SCANNING | PUBLIC DISCLOSURE\r\nPROGRAM Select Select Select\r\nOT Discussion: The organization makes a risk-based determination of how to monitor or scan for\r\nvulnerabilities on their system. This may include active scanning, passive monitoring, or\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n279\r\ncompensating controls, depending on the system being scanned. For example, vulnerability\r\nexamination may be performed using passive monitoring and manual visual inspection to\r\nmaintain an up-to-date inventory of assets. That inventory can be cross-referenced against a list\r\nof known vulnerabilities (e.g., CISA advisories, NIST NVD). Production may need to be taken\r\noffline before active scans can be conducted. Scans are scheduled to occur during planned OT\r\noutages whenever possible. If vulnerability scanning tools are used on adjacent non-OT\r\nnetworks, extra care is taken to ensure that they do not mistakenly scan the OT network.\r\nAutomated network scanning is not applicable to non-routable communications, such as serial\r\nnetworks. Compensating controls include providing a replicated or simulated system for\r\nconducting scans or host-based vulnerability applications.\r\nControl Enhancement: (2) (5) No OT Discussion for this control.\r\nControl Enhancement: (4) OT Discussion: Examples of discoverable information in OT could\r\ninclude information about key personnel or technical information related to systems and\r\nconfigurations. Locations that may need to be monitored or scanned include technical forums,\r\nblogs, and vendor or contractor websites.\r\nControl Enhancement: (11) OT Discussion: For federal organizations, CISA Binding Operational\r\nDirective 20-01 requires individual federal civilian executive branch agencies to develop and\r\npublish a vulnerability disclosure policy (VDP) for their internet-accessible systems and services\r\nand maintain processes to support their VDP. A VDP may be implemented at the organization\r\nlevel rather than for each individual system. Federal and non-federal organizations could achieve\r\nthis control by creating and monitoring an email address published on a public-facing website for\r\ncontacting the organization regarding disclosures.\r\nRA-7 RISK RESPONSE\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nRA-7 Risk Response Select Select Select\r\nNo OT Discussion for this control.\r\nRA-9 CRITICALITY ANALYSIS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nRA-9 Criticality Analysis Select Select\r\nNo OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n280\r\nF.7.16. SYSTEM AND SERVICES ACQUISITION – SA\r\nTailoring Considerations for the System and Services Acquisition Family\r\nIn situations where the OT cannot support the specific system and services acquisition\r\nrequirements of a control, the organization employs compensating controls in accordance with\r\nthe general tailoring guidance. Examples of compensating controls are given with each control as\r\nappropriate.\r\nSA-1 POLICY AND PROCEDURES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSA-1 Policy and Procedures Select Select Select\r\nOT Discussion: The policy specifically addresses the unique properties and requirements of OT\r\nand the relationship to non-OT systems.\r\nSA-2 ALLOCATION OF RESOURCES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSA-2 Allocation of Resources Select Select Select\r\nNo OT Discussion for this control.\r\nSA-3 SYSTEM DEVELOPMENT LIFE CYCLE\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSA-3 System Development Life Cycle Select Select Select\r\nSA-3 (1) SYSTEM DEVELOPMENT LIFE CYCLE | MANAGE PREPRODUCTION\r\nENVIRONMENT\r\nSA-3 (3) SYSTEM DEVELOPMENT LIFE CYCLE | TECHNOLOGY REFRESH\r\nNo OT Discussion for this control.\r\nControl Enhancements: (1) OT Discussion: Organizations that do not maintain local pre-production environments and utilize a third-party integrator should ensure that contracts are\r\ndeveloped to limit security and privacy risks.\r\nControl Enhancements: (3) OT Discussion: Many OT systems have an expected life cycle that is\r\nlonger than most IT components. Technology refresh is addressed in budget planning to limit the\r\nuse of obsolete systems that present security or reliability risks.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n281\r\nSA-4 ACQUISITION PROCESS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nSUPPLEMENTED\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSA-4 Acquisition Process Select Select Select\r\nSA-4 (1) ACQUISITION PROCESS | FUNCTIONAL PROPERTIES OF CONTROLS Select Select\r\nSA-4 (2) ACQUISITION PROCESS | DESIGN AND IMPLEMENTATION\r\nINFORMATION FOR CONTROLS Select Select\r\nSA-4 (5) ACQUISITION PROCESS | SYSTEM, COMPONENT, AND SERVICE\r\nCONFIGURATIONS Select\r\nSA-4 (9) ACQUISITION PROCESS | FUNCTIONS, PORTS, PROTOCOLS, AND\r\nSERVICES IN USE Select Select\r\nSA-4 (10) ACQUISITION PROCESS | USE OF APPROVED PIV PRODUCTS Select Select Select\r\nSA-4 (12) ACQUISITION PROCESS | DATA OWNERSHIP Add Add Add\r\nOT Discussion: Organizations engage with OT suppliers to raise awareness of cybersecurity\r\nneeds. The SCADA/Control Systems Procurement Project provides example cybersecurity\r\nprocurement language for OT.\r\nControl Enhancements: (1) (2) (9) OT Discussion: When acquiring OT products, consideration\r\nfor security requirements may not have been incorporated into the design. Procurement may need\r\nto consider alternative products or complementary hardware or plan for compensating controls.\r\nControl Enhancement: (10) OT Discussion: The use of approved PIV products is only required\r\nfor organizations that follow OMB Memorandum M-19-17 (e.g., federal agencies and\r\ncontractors). Example compensating controls include employing external products on the FIPS\r\n201-approved products list for PIV capabilities in conjunction with OT products.\r\nControl Enhancement: (5) (12) No OT Discussion for this control.\r\nRationale for adding SA-4 (12) to LOW, MOD, and HIGH baselines: Organizationally sensitive\r\nor proprietary OT data is often provided to contractors for project development or support, so\r\ndata ownership should be defined prior to exchanging data with a vendor or integrator. The\r\npotential sharing of data with other parties and the potential deletion of the data after project\r\ncompletion should be determined. OT systems that are operated by contractors on behalf of the\r\norganization may be subject to the same requirements (e.g., legal, regulatory, etc.) for data\r\nownership and retention.\r\nSA-5 SYSTEM DOCUMENTATION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSA-5 System Documentation Select Select Select\r\nNo OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n282\r\nSA-8 SECURITY AND PRIVACY ENGINEERING PRINCIPLES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSA-8 Security and Privacy Engineering Principles Select Select Select\r\nNo OT Discussion for this control.\r\nSA-9 EXTERNAL SYSTEM SERVICES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSA-9 External System Services Select Select Select\r\nSA-9 (2) EXTERNAL SYSTEM SERVICES | IDENTIFICATION OF FUNCTIONS,\r\nPORTS, PROTOCOLS, AND SERVICES Select Select\r\nNo OT Discussion for this control.\r\nSA-10 DEVELOPER CONFIGURATION MANAGEMENT\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSA-10 Developer Configuration Management Select Select\r\nOT Discussion: Personnel with knowledge about security and privacy requirements are included\r\nin the change management process for the developer.\r\nSA-11 DEVELOPER TESTING AND EVALUATION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSA-11 Developer Testing and Evaluation Select Select\r\nNo OT Discussion for this control.\r\nSA-15 DEVELOPMENT PROCESS, STANDARDS, AND TOOLS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSA-15 Development Process, Standards, and Tools Select Select\r\nSA-15 (3) DEVELOPMENT PROCESS, STANDARDS, AND TOOLS | CRITICALITY\r\nANALYSIS Select Select\r\nNo OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n283\r\nSA-16 DEVELOPER-PROVIDED TRAINING\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSA-16 Developer-Provided Training Select\r\nNo OT Discussion for this control.\r\nSA-17 DEVELOPER SECURITY AND PRIVACY ARCHITECTURE AND DESIGN\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSA-17 Developer Security and Privacy Architecture and Design Select\r\nNo OT Discussion for this control.\r\nSA-21 DEVELOPER SCREENING\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSA-21 Developer Screening Select\r\nNo OT Discussion for this control.\r\nSA-22 UNSUPPORTED SYSTEM COMPONENTS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSA-22 Unsupported System Components Select Select Select\r\nOT Discussion: OT systems may contain system components that are no longer supported by the\r\ndeveloper, vendor, or manufacturer and have not been replaced due to various operational,\r\nsafety, availability, or lifetime constraints. Organizations identify alternative methods to continue\r\nsupported operation of such system components and consider additional compensating controls\r\nto mitigate against known threats and vulnerabilities to unsupported system components.\r\nF.7.17. SYSTEM AND COMMUNICATIONS PROTECTION – SC\r\nTailoring Considerations for the System and Communications Protection Family\r\nThe use of cryptography is determined after careful consideration of the security needs and the\r\npotential ramifications on system performance. For example, the organization considers whether\r\nlatency induced from the use of cryptography would adversely impact the operational\r\nperformance of the OT. While the legacy devices commonly found within OT often lack direct\r\nsupport for cryptographic functions, compensating controls (e.g., encapsulations) may be used to\r\nmeet the intent of the control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n284\r\nWhen the OT cannot support the specific system and communications protection requirements of\r\na control, the organization employs compensating controls in accordance with the general\r\ntailoring guidance. Examples of compensating controls are given with each control as\r\nappropriate.\r\nSC-1 POLICY AND PROCEDURES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSC-1 Policy and Procedures Select Select Select\r\nOT Discussion: The policy specifically addresses the unique properties and requirements of OT\r\nand the relationship to non-OT systems.\r\nSC-2 SEPARATION OF SYSTEM AND USER FUNCTIONALITY\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSC-2 Separation of System and User Functionality Select Select\r\nOT Discussion: Physical separation includes using separate systems for managing the OT and for\r\noperating OT components. Logical separation includes the use of different user accounts for\r\nadministrative and operator privileges. Example compensating controls include providing\r\nincreased auditing measures.\r\nSC-3 SECURITY FUNCTION ISOLATION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSC-3 Security Function Isolation Select\r\nOT Discussion: Organizations consider implementing this control when designing new\r\narchitectures or updating existing components. An example compensating control includes\r\naccess controls.\r\nSC-4 INFORMATION IN SHARED SYSTEM RESOURCES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSC-4 Information in Shared System Resources Select Select\r\nOT Discussion: This control is especially relevant for OT systems that process confidential data.\r\nExample compensating controls include engineering the use of the OT to prevent sharing system\r\nresources.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n285\r\nSC-5 DENIAL-OF-SERVICE PROTECTION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSC-5 Denial-of-Service Protection Select Select Select\r\nOT Discussion: Some OT equipment may be more susceptible to DoS attacks due to the time\r\ncriticality of some OT applications. Risk-based analysis informs the prioritization of DoS\r\nprotection and the establishment of policy and procedure.\r\nSC-7 BOUNDARY PROTECTION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nSUPPLEMENTED\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSC-7 Boundary Protection Select Select Select\r\nSC-7 (3) BOUNDARY PROTECTION | ACCESS POINTS Select Select\r\nSC-7 (4) BOUNDARY PROTECTION | EXTERNAL TELECOMMUNICATIONS\r\nSERVICES Select Select\r\nSC-7 (5) BOUNDARY PROTECTION | DENY BY DEFAULT – ALLOW BY\r\nEXCEPTION Select Select\r\nSC-7 (7) BOUNDARY PROTECTION | SPLIT TUNNELING FOR REMOTE DEVICES Select Select\r\nSC-7 (8) BOUNDARY PROTECTION | ROUTE TRAFFIC TO AUTHENTICATED\r\nPROXY SERVERS Select Select\r\nSC-7 (18) BOUNDARY PROTECTION | FAIL SECURE Add Select\r\nSC-7 (21) BOUNDARY PROTECTION | ISOLATION OF SYSTEM COMPONENTS Select\r\nSC-7 (28) BOUNDARY PROTECTION | CONNECTIONS TO PUBLIC NETWORKS Add Add Add\r\nSC-7 (29) BOUNDARY PROTECTION | SEPARATE SUBNETS TO ISOLATE\r\nFUNCTIONS Add Add Add\r\nNo OT Discussion for this control.\r\nControl Enhancement: (3) (4) (5) (7) (8) (21) No OT discussion for this control.\r\nControl Enhancement: (18) OT Discussion: The organization selects an appropriate failure mode\r\n(e.g., permit or block all communications).\r\nControl Enhancement: (28) OT Discussion: Organizations consider the need for a direct\r\nconnection to a public network for each OT system, including potential benefits, additional threat\r\nvectors, and potential adverse impacts that are specifically relevant to the type of public access\r\nthat connection introduces.\r\nControl Enhancement: (29) OT Discussion: Subnets can be used to isolate low-risk functions\r\nfrom higher-risk ones and control from safety. Subnets should be considered along with other\r\nboundary protection technologies.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n286\r\nRationale for adding SC-7 (18) to MOD baseline: The ability to choose the failure mode for the\r\nphysical part of the OT differentiates the OT from other IT systems. This choice may be a\r\nsignificant influence in mitigating the impact of a failure.\r\nRationale for adding SC-7 (28) to LOW, MOD, and HIGH baselines: Access to OT should be\r\nrestricted to the individuals required for operation. A connection made from the OT directly to a\r\npublic network has limited applicability in OT environments but significant potential risk.\r\nRationale for adding SC-7 (29) to LOW, MOD, and HIGH baselines: In OT environments,\r\nsubnets and zoning are common practices for isolating functions.\r\nSC-8 TRANSMISSION CONFIDENTIALITY AND INTEGRITY\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSC-8 Transmission Confidentiality and Integrity Select Select\r\nSC-8 (1) TRANSMISSION CONFIDENTIALITY AND INTEGRITY | CRYPTOGRAPHIC\r\nPROTECTION Select Select\r\nNo OT Discussion for this control.\r\nControl Enhancement: (1) OT Discussion: When transmitting across untrusted network\r\nsegments, the organization explores all possible cryptographic integrity mechanisms (e.g., digital\r\nsignature, hash function) to protect the confidentiality and integrity of the information. Example\r\ncompensating controls include physical protections, such as a secure conduit (e.g., point-to-point\r\nlink) between two system components.\r\nSC-10 NETWORK DISCONNECT\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSC-10 Network Disconnect Remove Remove\r\nNo OT Discussion for this control.\r\nRationale for removing SC-10 from MOD and HIGH baselines: The intent of this control is\r\neffectively covered by AC-17 (9) for OT systems.\r\nSC-12 CRYPTOGRAPHIC KEY ESTABLISHMENT AND MANAGEMENT\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSC-12 Cryptographic Key Establishment and Management Select Select Select\r\nSC-12 (1) CRYPTOGRAPHIC KEY ESTABLISHMENT AND MANAGEMENT |\r\nAVAILABILITY Select\r\nNo OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n287\r\nSC-13 CRYPTOGRAPHIC PROTECTION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSC-13 Cryptographic Protection Select Select Select\r\nNo OT Discussion for this control.\r\nSC-15 COLLABORATIVE COMPUTING DEVICES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSC-15 Collaborative Computing Devices Select Select Select\r\nNo OT Discussion for this control.\r\nSC-17 PUBLIC KEY INFRASTRUCTURE CERTIFICATES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSC-17 Public Key Infrastructure Certificates Select Select\r\nNo OT Discussion for this control.\r\nSC-18 MOBILE CODE\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSC-18 Mobile Code Select Select\r\nNo OT Discussion for this control.\r\nSC-20 SECURE NAME / ADDRESS RESOLUTION SERVICE (AUTHORITATIVE SOURCE)\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSC-20 Secure Name /Address Resolution Service\r\n(Authoritative Source) Select Select Select\r\nOT Discussion: Secure name/address resolution services should only be used after careful\r\nconsideration and verification that they do not adversely impact the operational performance of\r\nthe OT.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n288\r\nSC-21 SECURE NAME / ADDRESS RESOLUTION SERVICE (RECURSIVE OR CACHING\r\nRESOLVER)\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSC-21 Secure Name /Address Resolution Service\r\n(Recursive or Caching Resolver) Select Select Select\r\nOT Discussion: Secure name/address resolution services should only be used after careful\r\nconsideration and verification that they do not adversely impact the operational performance of\r\nthe OT.\r\nSC-22 ARCHITECTURE AND PROVISIONING FOR NAME / ADDRESS RESOLUTION SERVICE\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSC-22 Architecture and Provisioning for\r\nName/Address Resolution Service Select Select Select\r\nOT Discussion: Secure name/address resolution services should only be used after careful\r\nconsideration and verification that they do not adversely impact the operational performance of\r\nthe OT.\r\nSC-23 SESSION AUTHENTICITY\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSC-23 Session Authenticity Select Select\r\nOT Discussion: Example compensating controls include auditing measures.\r\nSC-24 FAIL IN KNOWN STATE\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nSUPPLEMENTED\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSC-24 Fail in Known State Add Select\r\nOT Discussion: The organization selects an appropriate failure state. Preserving OT state\r\ninformation includes consistency among OT state variables and the physical state that the OT\r\nrepresents (e.g., whether valves are open or closed, communication permitted or blocked,\r\ncontinue operations).\r\nRationale for adding SC-24 to MOD baseline: As part of the architecture and design of the OT,\r\nthe organization selects an appropriate failure state in accordance with the function performed by\r\nthe OT and the operational environment. The ability to choose the failure mode for the physical\r\npart of OT differentiates OT systems from other IT systems. This choice may be a significant\r\ninfluence in mitigating the impact of a failure since it may be disruptive to ongoing physical\r\nprocesses (e.g., valves failing in closed position may adversely affect system cooling).\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n289\r\nSC-28 PROTECTION OF INFORMATION AT REST\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSC-28 Protection of Information at Rest Select Select\r\nSC-28 (1) PROTECTION OF INFORMATION AT REST |CRYPTOGRAPHIC\r\nPROTECTION Select Select\r\nOT Discussion: Cryptographic mechanisms are implemented only after careful consideration and\r\nverification that they do not adversely impact the operational performance of the OT. When\r\ncryptographic mechanisms are not feasible on certain OT devices, compensating controls may\r\ninclude relocating the data to a location that does support cryptographic mechanisms.\r\nControl Enhancement: (1) No OT Discussion for this control.\r\nSC-32 SYSTEM PARTITIONING\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSC-32 System Partitioning\r\nSC-32 (1) SYSTEM PARTITIONING | SEPARATE PHYSICAL DOMAINS FOR\r\nPRIVILEGED FUNCTIONS\r\nNo OT Discussion for this control.\r\nControl Enhancement: (1) OT Discussion: Organizations consider separate physical domains for\r\nprivileged functions, such as those that affect security and safety.\r\nSC-39 PROCESS ISOLATION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSC-39 Process Isolation Select Select Select\r\nOT Discussion: Example compensating controls include partition processes to separate\r\nplatforms.\r\nSC-41 PORT AND I/O DEVICE ACCESS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nSUPPLEMENTED\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSC-41 Port and I/O Device Access Add Add Add\r\nNo OT discussion for this control.\r\nRationale for adding SC-41 to LOW, MOD, and HIGH baselines: OT functionality is generally\r\ndefined in advance and does not change often.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n290\r\nSC-45 SYSTEM TIME SYNCHRONIZATION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nSUPPLEMENTED\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSC-45 System Time Synchronization Add Add Add\r\nSC-45 (1) SYSTEM TIME SYNCHRONIZATION | SYNCHRONIZATION WITH\r\nAUTHORITATIVE TIME SOURCE\r\nOT Discussion: Organizations coordinate time synchronization on OT to allow for accurate\r\ntroubleshooting and forensics.\r\nControl Enhancement: (1) OT Discussion: Syncing with an authoritative time source may be\r\nselected as a control when data is being correlated across organizational boundaries. OT employ\r\nsuitable mechanisms (e.g., GPS, IEEE 1588) for timestamps.\r\nRationale for adding SC-45 to LOW, MOD, and HIGH baselines: Organizations may find\r\nrelative system time beneficial for many OT systems to ensure the safe and reliable delivery of\r\nessential functions. Time synchronization can also make root cause analysis more efficient by\r\nensuring that audit logs from different systems are aligned so that organizations have an accurate\r\nview of events across multiple systems when the logs are aggregated.\r\nSC-47 ALTERNATE COMMUNICATIONS PATHS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nSUPPLEMENTED\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSC-47 Alternate Communications Paths Add\r\nOT Discussion: Organizations consider which systems require alternate communication paths to\r\nensure that a loss of communication does not lead to an unacceptable loss of view or control or to\r\na safety event.\r\nRationale for adding SC-47 to HIGH baseline: For continuity of operations during an incident,\r\norganizations should consider establishing alternate communications paths for command-and-control purposes to continue to operate and take appropriate actions for high-impact systems\r\nwhen the loss of availability or integrity may result in severe or catastrophic adverse impacts,\r\nincluding impacts to safety and critical service delivery.\r\nSC-51 HARDWARE-BASED PROTECTION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nSUPPLEMENTED\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSC-51 Hardware-Based Protection\r\nOT Discussion: Some OT systems support write-protection by implementing physical key\r\nswitches or write-protect switches. Organizations define the systems for which write-protection\r\nwill be enabled and develop a process for how to take the system out of write-protect mode.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n291\r\nF.7.18. SYSTEM AND INFORMATION INTEGRITY – SI\r\nTailoring Considerations for the System and Information Integrity Family\r\nWhen the OT cannot support the specific system and information integrity requirements of a\r\ncontrol, the organization employs compensating controls in accordance with the general tailoring\r\nguidance. Examples of compensating controls are given with each control as appropriate.\r\nSI-1 POLICY AND PROCEDURES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSI-1 Policy and Procedures Select Select Select\r\nOT Discussion: The policy specifically addresses the unique properties and requirements of OT\r\nand the relationship to non-OT systems.\r\nSI-2 FLAW REMEDIATION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSI-2 Flaw Remediation Select Select Select\r\nSI-2 (2) FLAW REMEDIATION | AUTOMATED FLAW REMEDIATION STATUS Select Select\r\nOT Discussion: Flaw remediation, or patching, is complicated since many OT employ OSs and\r\nother software that are no longer maintained by the vendors. OT operators may also not have the\r\nresources or capability to test patches and are dependent on vendors to validate the operability of\r\na patch. Sometimes, the organization has no choice but to accept additional risk if no vendor\r\npatch is available, if patching requires additional time to complete validation or testing, or if\r\ndeployment requires an unacceptable operations shutdown. In these situations, compensating\r\ncontrols should be implemented (e.g., limiting the exposure of the vulnerable system, restricting\r\nvulnerable services, implementing virtual patching). Other compensating controls that do not\r\ndecrease the residual risk but increase the ability to respond may be desirable (e.g., provide a\r\ntimely response in case of an incident, devise a plan to ensure that the OT can identify\r\nexploitation of the flaw). Testing flaw remediation in an OT may exceed the organization’s\r\navailable resources.\r\nControl Enhancement: (2) No OT discussion for this control.\r\nSI-3 MALICIOUS CODE PROTECTION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSI-3 Malicious Code Protection Select Select Select\r\nOT Discussion: Malicious code protection should only be deployed after careful consideration\r\nand verification that it does not adversely impact the operation of the OT. Malicious code\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n292\r\nprotection tools should be configured to minimize their potential impact on the OT (e.g., employ\r\nnotification rather than quarantine). Example compensating controls include increased traffic\r\nmonitoring and auditing.\r\nSI-4 SYSTEM MONITORING\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSI-4 System Monitoring Select Select Select\r\nSI-4 (2) SYSTEM MONITORING | AUTOMATED TOOLS AND MECHANISMS FOR\r\nREAL-TIME ANALYSIS Select Select\r\nSI-4 (4) SYSTEM MONITORING | INBOUND AND OUTBOUND\r\nCOMMUNICATIONS TRAFFIC Select Select\r\nSI-4 (5) SYSTEM MONITORING | SYSTEM-GENERATED ALERTS Select Select\r\nSI-4 (10) SYSTEM MONITORING | VISIBILITY OF ENCRYPTED\r\nCOMMUNICATIONS Select\r\nSI-4 (12) SYSTEM MONITORING | AUTOMATED ORGANIZATION-GENERATED\r\nALERTS Select\r\nSI-4 (14) SYSTEM MONITORING | WIRELESS INTRUSION DETECTION Select\r\nSI-4 (20) SYSTEM MONITORING | PRIVILEGED USERS Select\r\nSI-4 (22) SYSTEM MONITORING | UNAUTHORIZED NETWORK SERVICES Select\r\nOT Discussion: The organization ensures that the use of monitoring tools and techniques does\r\nnot adversely impact the operational performance of the OT. Example compensating controls\r\ninclude deploying sufficient network, process, and physical monitoring.\r\nControl Enhancement: (2) OT Discussion: When the OT cannot support the use of automated\r\ntools for near-real-time analysis of events, the organization employs compensating controls (e.g.,\r\nproviding an auditing capability on a separate system, nonautomated mechanisms or procedures)\r\nin accordance with the general tailoring guidance.\r\nControl Enhancement: (4) (10) (12) (14) (20) (22) No OT Discussion for this control.\r\nControl Enhancement: (5) OT Discussion: Example compensating controls include manually\r\ngenerating alerts.\r\nSI-5 SECURITY ALERTS, ADVISORIES, AND DIRECTIVES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSI-5 Security Alerts, Advisories, and Directives Select Select Select\r\nSI-5 (1) SECURITY ALERTS, ADVISORIES, AND DIRECTIVES | AUTOMATED\r\nALERTS AND ADVISORIES Select\r\nOT Discussion: CISA generates security alerts and advisories relative to OT at\r\nhttps://www.cisa.gov/uscert/ics. Industry-specific ISACs often provide tailored advisories and\r\nalerts, which can be found at https://www.nationalisacs.org/.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n293\r\nControl Enhancement: (1) No OT Discussion for this control.\r\nSI-6 SECURITY AND PRIVACY FUNCTION VERIFICATION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSI-6 Security and Privacy Function Verification Select\r\nOT Discussion: Shutting down and restarting the OT may not always be feasible upon the\r\nidentification of an anomaly. These actions should be scheduled according to OT operational\r\nrequirements.\r\nSI-7 SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSI-7 Software, Firmware, and Information Integrity Select Select\r\nSI-7 (1) SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY | INTEGRITY\r\nCHECKS Select Select\r\nSI-7 (2) SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY |\r\nAUTOMATED NOTIFICATIONS OF INTEGRITY VIOLATIONS Select\r\nSI-7 (5) SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY |\r\nAUTOMATED RESPONSE TO INTEGRITY VIOLATIONS Select\r\nSI-7 (7) SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY |\r\nINTEGRATION OF DETECTION AND RESPONSE Select Select\r\nSI-7 (15) SOFTWARE, FIRMWARE, AND INFORMATION INTEGRITY | CODE\r\nAUTHENTICATION Select\r\nOT Discussion: The organization determines whether the use of integrity verification\r\napplications would adversely impact operation of the ICS and employs compensating controls\r\n(e.g., manual integrity verifications that do not affect performance).\r\nControl Enhancements: (1) OT Discussion: The organization ensures that the use of integrity\r\nverification applications does not adversely impact the operational performance of the OT.\r\nControl Enhancement: (2) OT Discussion: When the organization cannot employ automated\r\ntools that provide notifications about integrity discrepancies, the organization employs\r\nnonautomated mechanisms or procedures. Example compensating controls include performing\r\nscheduled manual inspections for integrity violations.\r\nControl Enhancement: (5) OT Discussion: Shutting down and restarting the ICS may not always\r\nbe feasible upon identification of an anomaly. These actions should be scheduled according to\r\nICS operational requirements.\r\nControl Enhancement: (7) OT Discussion: When the ICS cannot detect unauthorized security-relevant changes, the organization employs compensating controls (e.g., manual procedures) in\r\naccordance with the general tailoring guidance.\r\nControl Enhancement: (15) OT Discussion: Code authentication provides assurance that the\r\nsoftware and firmware have not been tampered with. If automated mechanisms are not available,\r\norganizations could manually verify code authentication by using a combination of techniques,\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n294\r\nincluding verifying hashes, downloading from reputable sources, verifying version numbers with\r\nthe vendor, or testing software and firmware in offline or test environments.\r\nSI-8 SPAM PROTECTION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSI-8 Spam Protection Select Select\r\nSI-8 (2) SPAM PROTECTION | AUTOMATIC UPDATES Remove Remove\r\nOT Discussion: OT organizations implement spam protection by removing spam transport\r\nmechanisms, functions, and services (e.g., electronic mail, web browsing) from the OT.\r\nRationale for removing SI-8 (2) from MOD and HIGH baselines: Spam transport mechanisms\r\nare disabled or removed from the OT, so automatic updates are not necessary.\r\nSI-10 INFORMATION INPUT VALIDATION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSI-10 Information Input Validation Select Select\r\nNo OT Discussion for this control.\r\nSI-11 ERROR HANDLING\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSI-11 Error Handling Select Select\r\nNo OT Discussion for this control.\r\nSI-12 INFORMATION MANAGEMENT AND RETENTION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSI-12 Information Management and Retention Select Select Select\r\nNo OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n295\r\nSI-13 PREDICTABLE FAILURE PREVENTION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nSUPPLEMENTED\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSI-13 Predictable Failure Prevention Add\r\nNo OT Discussion for this control.\r\nRationale for adding SI-13 control to HIGH baseline: OT are designed and built with certain\r\nboundary conditions, design parameters, and assumptions about their environment and mode of\r\noperation. OT may run much longer than conventional systems, allowing latent flaws that are not\r\nmanifest in other environments to become effective. For example, integer overflow might never\r\noccur in systems that are re-initialized more frequently than the occurrence of the overflow.\r\nExperience and forensic studies of anomalies and incidents in OT can lead to the identification of\r\nemergent properties that were previously unknown, unexpected, or unanticipated. Preventative\r\nand restorative actions (e.g., restarting the system or application) are prudent but may not be\r\nacceptable in OT for operational reasons.\r\nSI-16 MEMORY PROTECTION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSI-16 Memory Protection Select Select\r\nNo OT Discussion for this control.\r\nSI-17 FAIL-SAFE PROCEDURES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nSUPPLEMENTED\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSI-17 Fail-Safe Procedures Add Add Add\r\nOT Discussion: The selected failure conditions and corresponding procedures may vary among\r\nbaselines. The same failure event may trigger different responses, depending on the impact level.\r\nMechanical and analog systems can be used to provide mechanisms to ensure fail-safe\r\nprocedures. Fail-safe states should incorporate potential impacts to human safety, physical\r\nsystems, and the environment. A related controls is CP-6.\r\nRationale for adding SI-17 to LOW, MOD, and HIGH baselines: This control provides a\r\nstructure for the organization to identify its policy and procedures for dealing with failures and\r\nother incidents. Creating a written record of the decision process for selecting incidents and\r\nappropriate responses in light of a changing environment of operations is part of risk\r\nmanagement.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n296\r\nSI-22 INFORMATION DIVERSITY\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nSUPPLEMENTED\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSI-22 Information Diversity\r\nOT Discussion: Many OT systems use information diversity in their design to achieve reliability\r\nrequirements. Some examples of information diversity for an OT system include sensor voting\r\nand state estimation.\r\nF.7.19. SUPPLY CHAIN RISK MANAGEMENT – SR\r\nSR-1 POLICY AND PROCEDURES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSR-1 Policy and Procedures Select Select Select\r\nOT Discussion: Supply chain policies and procedures for OT should consider both components\r\nreceived and components produced. Many OT systems use legacy components that cannot meet\r\nmodern supply chain expectations. Appropriate compensating controls should be developed to\r\nachieve organizational supply chain expectations for legacy systems.\r\nSR-2 SUPPLY CHAIN RISK MANAGEMENT PLAN\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSR-2 Supply Chain Risk Management Plan Select Select Select\r\nSR-2 (1) SUPPLY CHAIN RISK MANAGEMENT PLAN | ESTABLISH SCRM TEAM Select Select Select\r\nNo OT Discussion for this control.\r\nSR-3 SUPPLY CHAIN CONTROLS AND PROCESSES\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nSUPPLEMENTED\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSR-3 Supply Chain Controls and Processes Select Select Select\r\nSR-3 (1) SUPPLY CHAIN CONTROLS AND PROCESSES | DIVERSE SUPPLY BASE\r\nNo OT Discussion for this control.\r\nControl Enhancement: (1) OT Discussion: Using a diverse set of suppliers in the OT\r\nenvironment can improve reliability by reducing common cause failures. This is not always\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n297\r\npossible since some technologies have limited supply options that meet the operational\r\nrequirements.\r\nSR-5 ACQUISITION STRATEGIES, TOOLS, AND METHODS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nSUPPLEMENTED\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSR-5 Acquisition Strategies, Tools, and Methods Select Select Select\r\nSR-5 (1) ACQUISITION STRATEGIES, TOOLS, AND METHODS | ADEQUATE\r\nSUPPLY Add Add\r\nNo OT Discussion for this control.\r\nControl Enhancement: (1) OT Discussion: Vendor relationships and spare parts strategies are\r\ndeveloped to ensure that an adequate supply of critical components is available to meet\r\noperational needs.\r\nRationale for adding SR-5 (1) to MOD and HIGH baselines: OT systems and system components\r\nare often built for purpose and have a limited number of vendors or suppliers for a specific\r\ncomponent. Organizations identify critical OT system components and controls to ensure an\r\nadequate supply in the event of supply chain disruptions.\r\nSR-6 SUPPLIER ASSESSMENTS AND REVIEWS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSR-6 Supplier Assessments and Reviews Select Select\r\nNo OT Discussion for this control.\r\nSR-8 NOTIFICATION AGREEMENTS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSR-8 Notification Agreements Select Select Select\r\nNo OT Discussion for this control.\r\nSR-9 TAMPER RESISTANCE AND DETECTION\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSR-9 Tamper Resistance and Detection Select\r\nSR-9 (1) TAMPER RESISTANCE AND DETECTION | MULTIPLE STAGES OF\r\nSYSTEM DEVELOPMENT LIFE CYCLE Select\r\nNo OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n298\r\nSR-10 INSPECTION OF SYSTEMS OR COMPONENTS\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSR-10 Inspection of Systems or Components Select Select Select\r\nNo OT Discussion for this control.\r\nSR-11 COMPONENT AUTHENTICITY\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSR-11 Component Authenticity Select Select Select\r\nSR-11 (1) COMPONENT AUTHENTICITY | ANTI-COUNTERFEIT TRAINING Select Select Select\r\nSR-11 (2) COMPONENT AUTHENTICITY | CONFIGURATION CONTROL FOR\r\nCOMPONENT SERVICE AND REPAIR Select Select Select\r\nNo OT Discussion for this control.\r\nSR-12 COMPONENT DISPOSAL\r\nCNTL\r\nNO.\r\nCONTROL NAME\r\nControl Enhancement Name\r\nCONTROL BASELINES\r\nLOW MOD HIGH\r\nSR-12 Component Disposal Select Select Select\r\nNo OT Discussion for this control.\n\nNIST SP 800-82r3 Guide to Operational Technology (OT) Security\r\nSeptember 2023\r\n299\r\nAppendix G. Change Log\r\nThis document is the third revision of NIST SP 800-82. Updates in this revision include:\r\n• Expansion in scope from industrial control systems to OT\r\n• Updates to OT threats and vulnerabilities\r\n• Updates to OT risk management, recommended practices, and architectures\r\n• Updates to current activities in OT security\r\n• Updates to security capabilities and tools for OT\r\n• Additional alignment with other OT security standards and guidelines, including the\r\nCybersecurity Framework\r\n• New tailoring guidance for NIST SP 800-53, Rev. 5 security controls\r\n• An OT overlay for NIST SP 800-53, Rev. 5 security controls that provides tailored\r\nsecurity control baselines for low-, moderate-, and high-impact OT systems\n\nNIST SP 800-82r3   Guide to Operational Technology (OT) Security\nSeptember 2023     \nAU-5 RESPONSE TO AUDIT LOGGING PROCESS FAILURES  \nCNTL CONTROL NAME  CONTROL BASELINES \nNO. Control Enhancement Name  LOW MOD HIGH\nAU-5 Response to Audit Logging Process Failures  Select Select Select\nAU-5 (1) RESPONSE CAPACITY TO AUDIT LOGGING PROCESS FAILURES | AUDIT STORAGE  Select\nAU-5 (2) RESPONSE ALERTS TO AUDIT LOGGING PROCESS FAILURES | REAL-TIME  Select\nNo OT Discussion for this control.    \nAU-6 AUDIT RECORD REVIEW, ANALYSIS, AND REPORTING  \nCNTL CONTROL NAME  CONTROL BASELINES \nNO. Control Enhancement Name  LOW MOD HIGH\nAU-6 Audit Review, Analysis, and Reporting  Select Select Select\nAU-6 (1) AUDIT PROCESS RECORD REVIEW, INTEGRATION ANALYSIS, AND REPORTING | AUTOMATED Select Select\nAU-6 (3) AUDIT AUDIT RECORD REVIEW, RECORD REPOSITORIES ANALYSIS, AND REPORTING | CORRELATE Select Select\nAU-6 (5) AUDIT ANALYSIS RECORD REVIEW, OF AUDIT RECORDS ANALYSIS, AND REPORTING | INTEGRATED  Select\nAU-6 (6) AUDIT WITH RECORD REVIEW, PHYSICAL MONITORING ANALYSIS, AND REPORTING | CORRELATION  Select\nNo OT Discussion for this control.    \nControl Enhancement: (1) OT Discussion: Example compensating controls include manual\nmechanisms or procedures. For devices where audit records cannot be feasibly collected, \nperiodic manual review may be necessary.   \nControl Enhancement: (3) (5) (6) No OT Discussion for this control.  \nAU-7 AUDIT RECORD REDUCTION AND REPORT GENERATION  \nCNTL CONTROL NAME  CONTROL BASELINES \nNO. Control Enhancement Name  LOW MOD HIGH\nAU-7 Audit Record Reduction and Report Generation  Select Select\nAU-7 (1) AUDIT AUTOMATIC RECORD REDUCTION PROCESSING AND REPORT GENERATION | Select Select\nNo OT Discussion for this control.    \n   238",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"pdf"
	],
	"references": [
		"https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r3.pdf"
	],
	"report_names": [
		"NIST.SP.800-82r3.pdf"
	],
	"threat_actors": [
		{
			"id": "9de1979b-40fc-44dc-855d-193edda4f3b8",
			"created_at": "2025-08-07T02:03:24.92723Z",
			"updated_at": "2026-04-29T06:58:57.580831Z",
			"deleted_at": null,
			"main_name": "GOLD LOCUST",
			"aliases": [
				"Anunak",
				"Carbanak",
				"Carbon Spider ",
				"FIN7 ",
				"Silicon "
			],
			"source_name": "Secureworks:GOLD LOCUST",
			"tools": [
				"Carbanak"
			],
			"source_id": "Secureworks",
			"reports": null
		},
		{
			"id": "cfdd35af-bd12-4c03-8737-08fca638346d",
			"created_at": "2022-10-25T16:07:24.165595Z",
			"updated_at": "2026-04-29T06:58:58.153884Z",
			"deleted_at": null,
			"main_name": "Sea Turtle",
			"aliases": [
				"Cosmic Wolf",
				"Marbled Dust",
				"Silicon",
				"Teal Kurma",
				"UNC1326"
			],
			"source_name": "ETDA:Sea Turtle",
			"tools": [
				"Drupalgeddon"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "33ae2a40-02cd-4dba-8461-d0a50e75578b",
			"created_at": "2023-01-06T13:46:38.947314Z",
			"updated_at": "2026-04-29T06:58:56.380057Z",
			"deleted_at": null,
			"main_name": "Sea Turtle",
			"aliases": [
				"UNC1326",
				"COSMIC WOLF",
				"Marbled Dust",
				"SILICON",
				"Teal Kurma"
			],
			"source_name": "MISPGALAXY:Sea Turtle",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "62b1b01f-168d-42db-afa1-29d794abc25f",
			"created_at": "2025-04-23T02:00:55.22426Z",
			"updated_at": "2026-04-29T06:58:57.823281Z",
			"deleted_at": null,
			"main_name": "Sea Turtle",
			"aliases": [
				"Sea Turtle",
				"Teal Kurma",
				"Marbled Dust",
				"Cosmic Wolf",
				"SILICON"
			],
			"source_name": "MITRE:Sea Turtle",
			"tools": [
				"SnappyTCP"
			],
			"source_id": "MITRE",
			"reports": null
		}
	],
	"ts_created_at": 1777429271,
	"ts_updated_at": 1777450980,
	"ts_creation_date": 1695742763,
	"ts_modification_date": 1696515143,
	"files": {
		"pdf": "https://archive.orkl.eu/0442af7100d24be9d0e68f3263edc2be9e39b9be.pdf",
		"text": "https://archive.orkl.eu/0442af7100d24be9d0e68f3263edc2be9e39b9be.txt",
		"img": "https://archive.orkl.eu/0442af7100d24be9d0e68f3263edc2be9e39b9be.jpg"
	}
}