The National Institute of Standards and Technology (NIST) has published the Initial Public Draft of Special Publication 800-82 Revision 4 (SP 800-82r4), Guide to Operational Technology (OT) Security. The new revision contains some good improvements, particularly in its emphasis on safety, governance, and the relationship between cybersecurity and operational risk.
Because this is an initial public draft, the OT cybersecurity community has an opportunity to help shape the final publication. This post will highlight some of the changes that stand out, along with discussion areas where the guidance could benefit from greater consistency, clarification, and additional context.
Changes and Improvements
There are several areas where this new draft has made significant changes, usually to good effect.
Alignment to NIST CSF 2.0
One of the most significant structural changes in Revision 4 is its alignment with NIST Cybersecurity Framework (CSF) 2.0. The updated guidance organizes much of its discussion around the six CSF functions: Govern, Identify, Protect, Detect, Respond, and Recover. This provides a familiar structure for organizations already using the CSF to manage cybersecurity risk.
What is particularly interesting is how much attention the document gives to each function. Section 3, which focuses on governance, spans approximately 16 pages. Section 4, covering the other five CSF functions, spans approximately 51 pages. Within that section, Protect receives considerably more attention than the other functions.
Figure 1 – Percent of Pages Devoted to Each CSF Function
This distribution is understandable in some respects. Protect encompasses a broad range of cybersecurity safeguards, and many of the challenges associated with securing OT systems involve adapting protective controls to operational constraints.
However, it also raises an interesting question about how we prioritize cybersecurity capabilities in OT environments. Preventing incidents is important, but industrial organizations must also be prepared to respond to and recover from incidents that cannot be prevented. When a cybersecurity event affects physical operations, the ability to maintain or restore safe operations may be just as important as the controls intended to prevent the event.
Focus on Additional Sectors
Revision 4 adds sections focused on several individual sectors, including Building Automation and Control Systems (BACS), freight railways, food and agriculture, and maritime operations. Although industrial environments share many cybersecurity challenges, the operational requirements, architectures, regulatory obligations, and consequences of failure can differ substantially between sectors.
Sector-specific guidance can help organizations understand how general cybersecurity principles apply to their operational environments. However, that guidance is only useful when it accurately reflects the systems and processes used in those sectors. This is an area where participation from industry practitioners is especially important.
If you work in one of the sectors covered by the new or expanded sections, I encourage you to review the material carefully. The people who design, operate, maintain, and secure these systems are best positioned to identify where generalized cybersecurity recommendations need additional context. You can help to identify assumptions that do not reflect actual operating environments, controls that may be impractical, or areas where additional examples would improve the guidance.
Focus on Governance
Along with the updates to focus on CSF 2.0, the revision devotes significant time to applying the Govern function from CSF 2.0. This makes sense, since prior to CSF 2.0 there was not a specific Govern function in the Framework.
The guidance emphasizes establishing responsibilities and accountability within the organization’s enterprise risk management processes. Effective governance helps establish a mechanism for resolving conflicts between cybersecurity recommendations and operational requirements. For example, cybersecurity personnel may recommend disabling a network service, while operations personnel explain that the service is required for a critical production function. Without effective governance, that disagreement may remain unresolved or one group may make a decision without fully understanding the consequences. Cybersecurity controls must be evaluated with an understanding of the safety, operational, and regulatory operating context, not with a myopic focus on cybersecurity risk. Ensuring all those relevant stakeholders are involved is made possible only with effective governance mechanisms.
Building an OT Cybersecurity Business Case
While not new to Revision 4, there is also a section dedicated to building a business case and then presenting that to executive leadership in order to get organizational support for an OT cybersecurity program. There is a well-placed emphasis on integrating the OT cybersecurity program into the broader enterprise risk and operational management.
“The business case should capture senior management’s concerns and provide the business impact and financial justification for creating an integrated organizational cybersecurity program.” (pg. 46)
This is a good reminder that when you are trying to accomplish something which requires somebody else’s support or efforts, it is critical to focus on what that other person cares about and provide rationales that resonate with your audience.
Zero Trust in OT
Section 5.3 is focused on integrating zero trust architecture (ZTA) principles into OT cybersecurity programs. I appreciate the forward-looking nature of this. While ZTA is not completely new to Revision 4, it had been a subitem of Network Security in Revision 3. ZTA is more broad than just network layer security controls, though. Implementing ZTA concepts requires using a broad range of cybersecurity controls, including identity and access management controls and continuous monitoring.
Revision 3’s treatment of ZTA was relatively short and focused on the problems associated with bringing ZTA concepts into OT environments. While still acknowledging that ZTA concepts may be difficult to implement in some OT networks, Revision 4 does provide good examples of how cybersecurity controls may be expanded to move them towards zero trust security concepts.
One nice example of this is around access management. Many organizations begin improving their access management program with a focus on Privileged Access Management controls. The updated SP 800-82 guidance talks about how “extending this same continuous-evaluation model to non-privileged access is a natural next step in a ZTA implementation.” The guidance also describes how zero trust, which is focused on reducing the likelihood that a threat will succeed, won’t inherently ensure safety and resilience, or that the OT systems shutdown, recover, and remain manageable in the face of degraded operating conditions.
Focus on Safety
One of the best things about SP 800-82 is its repeated emphasis on safety as a fundamental consideration in OT cybersecurity. The document makes it clear that cybersecurity cannot be evaluated or implemented independently of the physical processes that OT systems monitor and control. For example, the guidance states,
It is the organization’s greatest responsibility to ensure that each risk response is ultimately a decision that makes the workplace safer. Risks to safety are generally unacceptable and must be treated accordingly. (page 49)
Perhaps the most important concept appears in its discussion of consequence-driven security. The document explains that while administrative and technical safeguards reduce cybersecurity risk they need to be focused on preventing or limiting unsafe, unreliable, or destructive physical outcomes.
“A mature OT defense mindset is consequence-driven.” (Pg 10)
Consider a control system responsible for maintaining pressure within safe operating limits. Traditional cybersecurity thinking might focus on preventing unauthorized access, detecting malicious activity, or protecting the integrity of control commands. Those are all important objectives. But the ultimate concern is what happens to the physical process if those protections fail.
Can an attacker manipulate the process into an unsafe condition? Are there independent protections that prevent catastrophic outcomes? Can operators safely maintain or shut down the process if the control system becomes unavailable or untrustworthy? Answering these questions requires collaboration among cybersecurity professionals, control engineers, operators, and safety personnel.
This is also where approaches such as Cyber-Informed Engineering become particularly valuable. Rather than relying exclusively on cybersecurity controls to prevent malicious actions, organizations can incorporate design decisions that limit the physical consequences of a cyber compromise. The Guide does a good job of incorporating this concept throughout. Where the 800-82r3 Guide mentioned CIE in an appendix as a useful resource, Revision 4 incorporates CIE (both as a named methodology and as the associated concepts) throughout the document.
Area for Improvement
While I think this is a great initial public draft, there are some areas where improvements could be made.
Threats, Vulnerabilities, and Incidents
Appendix C is focused on defining and discussing threats, vulnerabilities, and incidents. There is some good content in here. I especially like how they frame vulnerabilities as existing either “in the organization” or “in the system.” Vulnerabilities in the organization arise from gaps or problems with documentation (e.g. policies, run books) or processes. For example, if organizational ownership of risk assessments is not defined then even a perfectly performed risk assessment will be unlikely to result in an actual reduction of risk. Without somebody being responsible for owning the process of remediating or mitigating the identified risks then the report will just end up collecting dust somewhere.
The definitions used are fine. A threat is “any circumstance or event with the potential to adversely impact” something, such as the organization, the nation, or individual assets or systems. A vulnerability is described as a “weakness in an information system (including an OT), system security procedures, internal controls, or implementation that could be exploited or triggered,” and when that occurs it is an incident or threat event that actually or potentially causes an undesirable consequence or impact to the operations of the system or organization.
And a side note: It is awesome that the first example given of an adversarial threat event was the Marconi wireless hack in 1903, during what was supposed to be the first public demonstration of long-distance secure wireless communications. Magician Nevil Maskelyne wanted to demonstrate the security flaws as a public service and show that it wasn’t really secure. The more things change, the more they stay the same.
Missing One Key Concept
This section could benefit from adding a definition and discussion of risk. While risk was discussed in section 3.2, with a focus on the NIST CSF Risk Management capability, it would add necessary context to the discussion of threats and vulnerabilities, especially since this Appendix is expected to be a separate document when the final version of the revision is published. Framing threats and vulnerabilities in terms of the risk they pose is how we ensure support and buy-in from the various stakeholders necessary to engage when building and improving an OT cybersecurity program. The goal is to reduce the risk to the organization, not simply to identify a list of threats or vulnerabilities.
Inconsistencies Across the Document
While Revision 4 contains substantial amounts of useful information, some sections would benefit from greater consistency and better integration. One example involves identity management and the separation of credentials across trust domains. On page 115 the draft recommends maintaining credentials separately across trust domains and references section 4.2.1.5. However, that section doesn’t actually recommend separate trust domains. What it does is talk about the tradeoffs involved in IT/OT identity convergence and centralization.
Another example involves the document’s treatment of OT architectures. Section 2.4 describes how OT systems operate and some common architectures seen in OT systems. For example, section 2.4.3 is focused on Distributed Control Systems (DCS), while section 5.2 is also about OT cybersecurity architecture models, with 5.2.2.1 focused on DCS-based OT systems. In section 5, DCS are described using Purdue Level nomenclature, such as how a DCS often has a functional area which is “a field level with devices typically associated with Purdue Levels 0, 1, and 2.” However, in section 2 talking about DCS (or even SCADA or other operational models, for that matter) the concept of Purdue Levels is never mentioned. Relatedly, section 5.2.2.3 talks about dividing a SCADA network architecture into “different zones or regions,” but doesn’t talk about Purdue Level at all. It would be better to be consistent, ideally by removing the Purdue Level nomenclature since it’s limited to the single section and, with the increased prevalence of Industrial Internet of Things and other connected OT environments not everything fits easily into the traditional Purdue Level model.
Section 5, “OT Cybersecurity Architecture,” has good information, but it feels like it was written by a separate group from sections 3 and 4, which were focused on NIST CSF Capabilities. Stronger consistency and cross-references would help readers understand how the different parts of the guidance fit together. This is especially important for something like SP 800-82, which will be used both as a comprehensive guide and as a reference for individual topics.
OT Overlay for SP 800-53r5 Security Controls
The last main section I’m going to focus on is an OT overlay for the security controls in the SP800-53r5 controls catalog, found in Appendix E in Revision 4. The overlay identifies controls which are applicable to low, moderate, or high control baselines and adds implementation guidance to consider when applying the control to OT systems. In some cases, it also adds or removes a control from the baseline (e.g. a control is included in the general SP 800-53r5 medium baseline but is removed for the OT-focused medium baseline). The concept of controls overlays is not new to either SP 800-53r5 nor SP 800-82r4. For background on the OT overlay, you can read our blog on the SP 800-82r3 controls, which goes into detail on the various controls. While there are some changes from the older versions (i.e. SP 800-53r4 and SP 800-82r3) to the new versions, there is also overlap so I won’t go into a full discussion of what the OT Overlay is here. The most important thing to know is that the Overlay is expected to be tailored to meet the operational needs and constraints of your organization and OT systems.
Table 18 of the initial draft is an overview of the controls and how they can be applied to OT environments. Bolded items mean that there is OT-specific discussion in the overlay, while underlined items mean that that specific control has been added to the baseline and strikethrough (not shown in this example) means that that control has been removed from the baseline.
Figure 2 – Sample from OT Controls Overlay
Since many OT systems may not support controls which are common in IT environments, the OT-specific discussion often focuses on compensating controls which may be used instead of the baseline control. For example, if a system has limited user account functionality then many security controls may be impossible to implement, such as automating account removals or automatically enforcing password changes. In that case, a compensating control using manual processes and procedures may be chosen.
These OT discussions and control selections represent about half of the 300+ page document. This post is not going to systematically review the OT Overlay control selection and discussions, but if you are reviewing the initial public draft and submitting your own comments then I’d recommend reading the Overlay with the SP 800-53r5 controls themselves also open, because the OT discussion generally doesn’t include much more than the title of the control. Your comments on the Overlay could focus on which control selections you agree or disagree with or where the OT discussion could be improved.
Why the OT Community Should Participate
NIST SP 800-82 is an important reference for organizations developing and improving OT cybersecurity programs. Its guidance influences cybersecurity assessments, security architecture decisions, procurement requirements, internal policies, and the implementation of security controls across many industries. That influence makes the public review process especially important.
No single organization, standards body, or group of cybersecurity professionals has experience with every type of OT environment. The challenges associated with securing a water treatment facility are not necessarily the same as those found in a manufacturing plant, data center, railway system, or maritime operation. Even within a single sector, organizations may operate systems with very different architectures, ages, capabilities, and operational requirements.
The value of a publication like SP 800-82 comes from incorporating these different perspectives into guidance that is both technically sound and operationally practical. This is also why constructive criticism matters. Identifying an inconsistency, questioning an assumption, or explaining why a recommended control may be impractical is not an attack on the document. It is an opportunity to make the guidance better.
The initial public draft already contains a lot of great content, particularly its emphasis on safety, governance, consequence-driven cybersecurity, and the practical limitations of implementing modern security architectures in OT. At the same time, there are opportunities to improve the consistency of its architectural discussions, expand practical guidance for building cybersecurity business cases, and better connect threats and vulnerabilities to organizational risk.
These are precisely the kinds of issues that benefit from community review. If you are an OT cybersecurity professional, controls engineer, system integrator, operator, asset owner, or vendor, take the time to review the sections most relevant to your experience. You do not need to review every page to provide valuable feedback.
If a recommendation does not reflect how a particular technology operates, explain why. If an architectural description is confusing, identify what needs clarification. If you have implemented a compensating control that could help other organizations address a common limitation, consider recommending that it be included.
And if you find guidance that is particularly useful, that feedback is valuable too. The goal is to produce guidance that helps organizations make informed, practical decisions that reduce cybersecurity risk while protecting the safety and reliability of their operations. The OT cybersecurity community has an opportunity to help make SP 800-82 Revision 4 a better resource. We should take advantage of it.
You can start by visiting the NIST SP 800-82r4 publication page to read the initial public draft and instructions for submitting comments. Contributing is as simple as sending an email to sp800-82rev4@nist.gov.