Operational Technology
Page 20 of 37
Secure Connectivity - Operational OT Data Export Example
On this page
- Meet 'Admin Corp'
- Principle 1: Balance the risk and opportunities
- Principle 2: Limit the exposure of your connectivity
- Principle 3: Centralise and standardise network connections
- Principle 4: Use standardised and secure protocols
- Principle 5: Harden your OT boundary
- Principle 6: Limit the impact of compromise
- Principle 7: Ensure all connectivity is logged and monitored
- Principle 8: Establish an isolation plan
A fictional worked example exploring the application of our secure connectivity principles.
If you design or maintain an operational technology (OT) network, the scenario below will help you navigate the cyber security issues related to external connectivity for your cyber-physical system.
Meet 'Admin Corp'
Let's imagine we're following a fictional organisation who are responsible for making decisions about the cyber security of a CNI processing plant.
Admin Corp runs a plant that produces Adminox, a highly volatile, refined form of administrative paperwork that is essential to every organisation in the country. It is created from volatile raw products using a continuous chemical process.
As an essential service, Admin Corp must comply with the EU NIS Directive. This means that Admin Corp's network, information systems and technology needed for the production of Adminox must be protected from cyber attack.
Admin Corp is regulated for safety by the UK Health and Safety Executive as a COMAH site. Incidents involving uncontrolled release of Adminox would seriously affect the environment and exposed people. The company must ensure the continued safety of the Adminox production process.
The process for producing Adminox involves a number of steps, with the final product stored under pressure in a tank. Clearly, no one would benefit from the unconstrained release of this Adminox, with the potential for additional red-tape clogging up local services for years.
The challenge - secure OT data export
Admin Corp has traditionally kept all OT information internal, sharing it with external partners only in exceptional cases. However, a recent discussion with their industrial oven manufacturer is prompting a review of this approach.
The oven plays a key role in the Adminox production process. Before Adminox takes its final form as a liquefied gas, it exists as a precursor compound that must be heated to remove residual moisture and solvent vapours. This controlled heating ensures the precursor converts efficiently without impurities that could destabilise storage and affect product quality. Admin Corp has only one oven on-site; without it, they cannot produce Adminox.
Admin Corp has a service-level agreement with the oven manufacturer guaranteeing 95% uptime that is nearing its end. The manufacturer has proposed improving this uptime in a new contract if Admin Corp provides access to specific OT data feeds for early fault detection and proactive maintenance.
Admin Corp recognises that secure OT data sharing could also support broader strategic goals. With public commitments on sustainability, the company faces scrutiny from regulators, investors, and environmental groups. Admin Corp leadership sees secure data sharing as a path to greater transparency.
Always seeking to innovate, Admin Corp is eager to explore secure data sharing opportunities with trusted partners.
Applying the principles
The secure connectivity principles apply when redesigning an architecture or creating a new system. Admin Corp is considering designing secure OT data export paths to integrate into an existing system.
In the remaining sections of this document, we’ll walk through each of the NCSC secure connectivity principles and see how they can be applied.
Principle 1: Balance the risk and opportunities
Admin Corp starts by developing formal business cases for its two initial data sharing initiatives:
- Oven operational efficiency
- Sustainability transparency
These business cases underpin all connectivity and engineering decisions and are regularly updated and reviewed through the design process.
Stage 1: High-level description
The first part of the business cases is a high-level description capturing the purpose of the connection, information requirements and third-party involvement
Purpose of the connection
- 1
Why is the connection needed?
The connection is needed to provide trusted stakeholders with access to data on the environmental impact of Adminox production. By sharing targeted OT data feeds, stakeholders can monitor compliance.
- 2
What does it aim to achieve?
The aim is to achieve greater transparency in sustainability efforts, enabling Admin Corp to demonstrate its commitment to environmentally responsible practices. This transparency can help build trust with key partners.
- 3
What are the operational and strategic advantages?
The strategic advantages include enhanced reputation and credibility. Through proactive sharing of relevant data, Admin Corp can position itself as a leader in sustainable manufacturing, potentially attracting more environmentally-conscious customers and investors.
Information requirements
As part of the high-level description, Admin Corp captures detailed information requirements using a process like the CDDB’s integrated approach to information management methodology.
Some of the questions Admin Corp address include:
- What information is required, and why is it relevant?
- Which parties are involved, and what decisions will this information support?
- What data will be shared, and where will it come from and go to?
- How critical and sensitive is the data in both a cyber and protective (that is physical and personnel) security context?
- What is the sharing frequency, volume, and timeliness required?
Third-party involvement
Admin Corp follows the NCSC’s guidance on Creating and maintaining a definitive view of your OT architecture. As such they have a good understanding of existing third-party risks to their system. For each data sharing initiative, Admin Corp:
- documents all third parties involved, whether receiving data or providing enabling technologies
- records the existing security requirements applied to each third party, along with their current compliance status
- assesses the organisation’s ability to further influence or enforce security standards with those third parties
Admin Corp ensures that no new operational dependencies on third parties are introduced as part of any initiative.
Stage 2: Risk assessment
Admin Corp has an existing risk assessment for their system. Given Adminox's cyber-physical production process, the risk analysis covers physical threats (such as damage or interference) and personnel risks (like insider threats), alongside cyber risks. The risk assessment is built upon a thorough understanding of their OT architecture and follows international standards like ISO 27001, IEC 62443-3-2, and the NCSC’s Risk management guidance.
The baseline risk model:
- links each identified risk to its potential operational, safety, and regulatory impacts
- identifies feasible mitigations for each risk
- considers cross-system interdependencies and how these influence the scale and nature of potential impacts
Admin Corp’s senior leadership a define a set of risk thresholds for data sharing activities. These thresholds reflect the organisation’s appetite for operational and cyber risk, and set clear limits on acceptable exposure.
For each information requirement, within each data sharing initiative, the Admin Corp assessment team evaluates its impact on the established baseline risk model and determines whether any of the thresholds are breached. This ensures any new or expanded data flows remain within agreed tolerance levels. Examples of these thresholds include:
- no data sharing arrangement will be approved if it introduces a point of failure that could cause unplanned production downtime
- no new connectivity path created by data sharing may permit direct access to OT systems controlling Adminox production from outside the secure OT network
- no shared dataset may contain operational, system configuration or site layout and security details that, if combined with publicly available or previously compromised information, could enable a threat actor to materially degrade, manipulate, or halt Adminox production processes
Through this structured review process, Admin Corp ensures that any expansion of data flows is aligned with their security, operational resilience, and safety objectives.
Stage 3: Governance framework
Each business case ends by assigning senior accountability, defining roles and responsibilities, setting governance arrangements, and noting relevant policies.
Admin Corp's governance framework for the sustainability transparency use case is shown below. Admin Corp is a medium-sized CNI organisation with separate members of staff for each role. In smaller organisations, one member of staff may fulfil multiple roles.
| Role | Key Responsibilities |
|---|---|
| Risk Owner |
|
| Operational Lead |
|
| Technical Security Lead |
|
| Security Manager |
|
| Supplier Security Lead |
|
| Compliance & Policy Lead |
|
| Compliance Support |
|
| Coordination & Oversight |
|
Relevant policies include:
- approval (defines authority levels and document sign-off procedures)
- monitoring (outlines procedures for reviews to identify and address changes in scope, risk profile, or partner behavior)
- change management (establishes procedures for modifying or terminating data sharing agreements)
- issue resolution (defines escalation routes and assigns responsibilities for efficiently resolving disputes or incidents)
Principle 2: Limit the exposure of your connectivity
In this scenario, the oven operational efficiency business case passes the first approval phase, allowing the project to proceed. A multidisciplinary team is assembled to design and build the necessary data sharing connections. The team combines expertise in operational processes, OT security, IT engineering, IT and corporate security.
Identify and categorise exposure
The team start by reviewing the information requirements in the business case, identifying and categorizing exposures, and highlighting relevant risks. Below are examples of two information requirements for the oven's operational efficiency initiative.
| Information requirement | Data source | Location in system | Exposure type | Notes from risk assessment | Data requirements |
|---|---|---|---|---|---|
| Ramp-up and cool-down rates | Oven onboard computer (PLC) | OT Production network | Local or live-in person | PLC is safety-critical, cannot be directly exposed. PLC is a legacy device with limited security features. | One second time-series resolution for specified PLC tags, covering all operational cycles. Data may be exported up to 24-hours delayed. Data must be output in CSV format with a consistent schema. Ability to export a copy of all files sent in the last 12 months for audit. |
| Thermal leakage | Wireless IR cameras | IIoT Sensor Network | Local | Images may indirectly disclose sensitive information (for example, production volumes and rates, plant layouts, shift patterns). Wireless medium means radio interception risks. | 4 scheduled data snapshots per day (e.g. 00:00, 06:00, 12:00, 18:00). Data may be exported up to 7 days delayed. Each snapshot must include high-resolution thermal images from all active IR cameras (minimum resolution 640x480px, 16-bit depth). Snapshots should be timestamped in UTC (ISO 8601) and compressed in approved lossless format. |
Managing exposure
After the team have identified and categorised exposure, they consider how they can manage exposure for each of the information requirements. The team identify a number of mitigation approaches:
Batch exports
For both information requirements there is a high latency tolerance, 24 hrs and 7 days respectively. As such, batch exports are scheduled to coincide with these limits. Due to network hardware limitations, Admin Corp cannot disable network paths outside of the designated export windows. Even so, a batch export approach still provides benefits. Restricting usage to standardised intervals reduces exposure (for example by limiting the time window during which interception could occur), and supports more effective monitoring for anomalies.
Isolation points
A structured flow‑control pattern is enforced through defined isolation points located at both the internal and external interfaces of the OT DMZ. Admin Corp has considered the overall posture of their network security and decided that hardware security controls such as data diodes would be undermined by weaker controls elsewhere. Instead, firewalls with tightly defined rule sets governing permitted traffic are used.
Push-only architecture
No listening ports are open on the OT side of the DMZ. All data must be pushed from the OT networks upward through the architecture. This design significantly limits the potential for a threat actor to traverse the network from higher‑tier systems back into the OT environment.
Connectivity bearer exposure
The IR cameras are on a wireless network explicitly for IIoT sensors. This network is treated as untrusted, and it therefore has limited access to anything else. To manage the connectivity bearer risk, Admin Corp ensures the wireless network uses WPA3 Enterprise with MAC allow-listing to restrict access to registered cameras only. They also limit power in wireless transmitters to reduce the likelihood of interception of RF traffic from outside the facility perimeter.
Internet exposure
Admin Corp’s core principle for managing internet exposure is that no OT asset is ever directly connected to the internet. The team ensure this principle is not violated. Existing monitoring practices focus on detecting and analysing any internet‑facing endpoints. For this monitoring to be effective it is necessary for Admin Corp to maintain an accurate IP asset inventory. The Admin Corp team note that third‑party endpoints used to receive OT data must also be included in this inventory. This ensures such endpoints are subject to the same monitoring as internal assets.
At this point the team create data export schematics for each of the information requirements:
Initial data export patterns for each information requirement with exposure management controls highlighted in red
Principle 3: Centralise and standardise network connections
As the team reviews data export patterns for each information requirement, they recognise shared architectural characteristics in their design and components. Both information requirements involve machine‑to‑machine operational data flows, as defined in the NCSC’s guidance on Creating and maintaining a definitive view of your Operational Technology (OT) architecture .
The team recognise that standardising these types of data exports around a unified pattern, supported by common infrastructure, would simplify the environment bringing security benefits. Accordingly, the Admin Corp team begins designing a unified pattern for exporting operational data exports. Their objective is to establish a high-level pattern that outlines the main sequence of components and steps. This foundational structure is intended to be adaptable, allowing for customisation or extension to meet specific information or security requirements. By adopting this flexible approach, the pattern can maintain its relevance and effectiveness across a diverse range of operational scenarios, ensuring that the principle of ‘build well once’ is upheld.
There are two key areas of consolidation based on the separate information requirement export paths:
- Data exports traverse a single, standardised OT DMZ architecture, with one controlled point of entry into the OT DMZ. This reduces the attack surface, centralises firewall management, and simplifies policy enforcement. Currently, the replica historian supports the oven operational efficiency use case, and the replica image server supports the thermal leakage use case. Under a consolidated DMZ model, these systems would be made available as shared resources for future use cases; avoiding redundant infrastructure, cutting maintenance overhead, and ensuring consistent security controls at the perimeter.
- Adoption of a single API gateway with a single endpoint in each customers environment, the customer is the same entity for both of the example information requirements. This approach prevents service duplication, simplifies onboarding for new data consumers, and ensures consistent standards. The gateway also serves as a central point for enforcing data governance and logging.
Operational data export patterns with key consolidation areas highlighted in red
Principle 4: Use standardised and secure protocols
The Admin Corp team understands that protocol choice directly affects the confidentiality, integrity, and availability of data flows. Selecting secure, interoperable protocols tailored to each connection type is essential for mitigating risk and supporting long-term operational resilience. With this in mind, the Admin Corp team reviews the data export patterns to identify key protocol considerations.
Legacy communications
In the context of the ramp-up and cool-down rates information requirement, the oven's PLC communicates with the primary historian via a serial link using Modbus RTU. Recognising the limitations of this legacy protocol, the team decides to introduce a serial/IP gateway in front of the PLC. This gateway will convert Modbus RTU to Modbus TCP, thereby minimising the presence of legacy protocols on the network and enhancing communication efficiency.
Database transfers
For both information requirements, database transfers cross an isolation boundary. This boundary separates environments with different trust levels. The Admin Corp team recognise that this process is security‑critical and must be executed using a robust approach and secure protocols. Most conventional historian replication solutions require bidirectional TCP connections within the protocol stack and the establishment of trust relationships between primary and replica systems. This approach is problematic for the Admin Corp team, as it can introduce pathways for lateral movement or attack across the boundary. To mitigate these risks, Admin Corp implement a design that enforces unidirectional, stateless data transfers. Instead of bidirectional streaming replication, their method uses snapshots and exports of tagged data as csv/json files, automated via scripts, and pushes them across the boundary using secure file transfer, effectively executing a backup and restore file transfer process.
External-facing protocols
To help secure the data flowing between the API gateway and the API endpoint, the team refer to the NCSC's guidance on securing HTTP-based APIs. As the API is being hosted for a small community, they decide to utilise Mutual TLS (mTLS). This will provide two-way authentication, ensuring that both the client and server verify each other's identity before establishing a secure connection. In order to adopt mTLS the Admin Corp team build a private PKI for the client authentication portion of mTLS. They separate the TLS offloader function from the web server, meaning that despite the use of mTLS, they are able to inspect communications for malicious content between the offloader and web server.
Operational data export patterns with protocol considerations highlighted in red
Principle 5: Harden your OT boundary
Next, the Admin Corp team focuses on strengthening the OT boundary. They identify the firewalls at isolation points as critical boundary assets. These firewalls form the first layer of defence and primary shield against external threats to OT networks. The Admin Corp team adopts a multi-tiered approach to securing these assets.
Harden
The team ensure firewalls are configured to expose only necessary network services, reducing attack surfaces and limiting potential for exploitation. The team replace default passwords on firewall admin interfaces with secure, unique credentials stored per Admin Corp’s password policy.
Update
The team uses supported firewalls and implements effective vulnerability management processes, updating firewalls by default to align with the latest vendor and industry security guidance. Regular updates close known vulnerabilities, improve performance, and strengthen resilience. When immediate updates are not possible, the team implement compensating controls such as enhancing monitoring until patching is safe. All changes are documented in a formal update schedule for accountability and traceability.
Manage
Firewalls are administered via a dedicated network using Privileged Access Workstations (PAW), built per the NCSC’s Principles for secure privileged access workstations (PAWs). These PAWs incorporate context-aware access controls, making connection decisions based on device location, type, configuration, and user behaviour. They enforce phishing-resistant multi-factor authentication, ensuring administrative access requires robust verification to prevent unauthorised control.
This use of PAWs not only ensures secure management of boundary devices but also plays a pivotal role in containing threats — a principle expanded in the next section.
Operational data export patterns with controls focused on strengthening the OT boundary highlighted in red
Principle 6: Limit the impact of compromise
In addition to hardening the OT boundary, the Admin Corp team ensures that they make architectural design choices that help enforce the principle of least privilege. This approach will help minimise the potential impact of any security breach.
PAWs, as introduced in Principle 5, are central to this containment strategy. When built to NCSC principles, PAWs provide a secure, isolated environment for performing administrative tasks. By separating privileged operations from general‑purpose user activities, PAWs eliminate the common pathways attackers use to move laterally from a compromised endpoint into administrative interfaces. In addition to the network PAW, there are dedicated OT PAWs is used to manage OT devices.
Two further interventions strengthen least‑privilege enforcement:
- Role‑based access control (RBAC) within the API. The API is designed to support fine‑grained RBAC. Authorisation policies are enforced at the endpoint level, allowing distinct access profiles for different users within the same customer organisation. Each user can access only the datasets required to fulfil their operational role.
- Replica databases are provisioned with read‑only permissions. This ensures that no write operations can be performed against primary databases, eliminating the possibility of modifying source data. Furthermore, no trust relationship is established between primary and replica systems, this isolation reduces the risk of tampering, data corruption, or operational disruption.
Through the combined use of secure PAWs, strict RBAC, and replica isolation, the Admin Corp team create an OT environment where the risk of a single compromise escalating into a wider breach is minimised.
Operational data export patterns with architectural design choices for limiting the impact of compromise highlighted in red
Principle 7: Ensure all connectivity is logged and monitored
Early detection is one of the most effective ways to limit the impact of a security compromise. Admin Corp recognises that robust monitoring and clear logging procedures are essential.
Architectural foundations
The operational data flows designed under earlier principles inherently support a robust monitoring strategy by providing:
- predictable batch exports, simplifying the detection of unusual activity outside scheduled intervals
- clearly defined and centralised isolation points between trust levels, enabling targeted monitoring at these boundaries
- push‑only architecture from OT networks into the DMZ, reducing potential attack paths and making unexpected inbound connections immediately visible
Threat-driven monitoring
Admin Corp’s approach to logging prioritises high‑risk components across the OT environment. One example is the serial/IP gateway within the OT Production Network, recognised as a higher‑risk component due to its potential susceptibility to ‘Living Off the Land’ techniques. Such gateways are intrinsically less secure and can be targeted by threat actors to establish a point of persistence within the OT environment, enabling prolonged, covert access or repeated exploitation over time.
While Admin Corp mitigates these risks through patching and hardening, the gateway is also subject to enhanced monitoring. This monitoring is configured to detect behaviours consistent with realistic adversary tactics.
Data sharing visibility
To manage data aggregation risks, Admin Corp keeps a definitive record of all datasets shared with external partners. Each record is linked to its originating business case. By integrating OT data requirements into their threat modelling process (as described in Principle 2 of the the NCSC’s OT Information Security Management), Admin Corp has identified suites of datasets that, if combined, could support an adversary’s attack chain. These high‑risk combinations of datasets are not shared outside the organisation.
Principle 8: Establish an isolation plan
Under Principle 1, Admin Corp’s approach to OT data export balances risks and ensures:
- No new operational dependencies on third parties arise from data export arrangements.
- Failure or unavailability of any data export arrangement cannot cause unplanned downtime or create a critical operational vulnerability.
These measures ensure external data exports can be disconnected without affecting production, aside from losing efficiency benefits. This operational independence protects safety and process continuity.
The Admin Corp team tests and validates a layered isolation strategy around data export paths.
- Isolate a customer from a feed: disconnect a specific user or organisation from the API while maintaining other service routes.
- Isolate a feed entirely: stop distribution of a particular feed to all customers.
- Isolate all outward feeds: shut down all API traffic between the DMZ and external customers.
- Isolate internal feeds: disconnect or block OT network communications to the DMZ.
These layers provide the flexibility to contain issues at the most appropriate level without disrupting unaffected services. Each scenario is mapped in detail and documented within operational playbooks, ensuring that isolation procedures are clearly defined, repeatable, and ready for rapid execution.