Operational Technology

Admin Corp (who you may remember from an earlier data export example) has now expanded its portfolio to include a regional water utility called Admin Corp Water (ACW). ACW is a regional water utility that treats and distributes potable water to millions of homes and businesses.

The process of treating water at ACW’s facilities depends on the water source, but typically involves several critical stages, including raw water intake, chemical dosing, filtration, and disinfection. These stages are automated with programmable logic controllers (PLCs) with operator oversight from human-machine interfaces (HMI) and site supervisory control and data acquisition (SCADA) systems. The final product is stored in large reservoirs and distributed through a network of pumping stations and pipelines. The entire process is monitored by operators in a centralised control room via a regional SCADA system that collects data from across the water network via remote telemetry units (RTUs).

These technologies must operate continuously and reliably to ensure both public health and service availability. As an operator of essential services (OES) within the water sector, ACW has a responsibility to prevent any release of water that does not meet quality standards and to ensure the consistent provision of water in accordance with regulatory obligations.

The challenge: standardising digital connectivity

In recent years, ACW has deployed various digital network services to connect site RTUs with its regional SCADA system, driven in part by the UK’s phase‑out of analogue services such as PSTN. On some sites, this connectivity also supports remote maintenance, asset management, centralised software/antivirus updates, and improved identity and access management (IDAM).

Operations teams have reported efficiency gains, including faster troubleshooting, streamlined updates, and enhanced visibility. ACW now aims to standardise remote site connectivity across its entire OT environment. Before doing so, it plans to ensure existing connections are resilient against cyber attacks, and to strengthen protections for legacy infrastructure, which may be more vulnerable when exposed to external networks.

To guide this work, ACW adopted the NCSC’s Secure Connectivity Principles for Operational Technology. ACW also aligned their organisations approach with recognised standards such as the NCSC Cyber Assessment Framework (CAF) and ISA/IEC 62443 to meet regulatory requirements and follow best practice.

Applying the principles

This worked example describes ACW’s implementation of the 8 secure connectivity principles, the reasoning behind key decisions, and how the company addressed the differing needs of modern and legacy environments.

Before expanding or standardising any OT connectivity, ACW recognised the need to make a clear, defensible decision about why connectivity was required, and how much risk the organisation was prepared to accept. To do this, ACW developed a formal business case to guide all subsequent design decisions and approvals. The business case captured:

• operational requirements
• expected benefits
• acceptable risk thresholds
• potential safety and service impacts
• senior risk owners

Importantly, it was treated as a 'living document', updated frequently, stored centrally and reviewed throughout the design and assurance process.

Benefits

ACW began by identifying the operational and security benefits already being realised from remote connectivity, and those expected from a more standardised approach.

• The operations teams reported that remote access significantly reduced downtime by allowing engineers to diagnose and resolve issues without travelling to site. This was particularly valuable for remote or hard‑to‑access facilities, where physical attendance could be substantially delayed.
• Centralised asset management provided improved visibility of OT systems across the estate. This allowed poor configurations to be identified and corrected remotely, reducing configuration drift and improving consistency.
• Improved connectivity enabled OT servers and workstations to receive operating system and antivirus updates in a more timely manner, maintaining protection against common and well‑understood threats that disproportionately affect unpatched systems.
• The move away from shared credentials towards named user accounts improved access control, auditability, and accountability, supporting both security monitoring and regulatory obligations.

These benefits established a clear operational case for connectivity, but ACW recognised that they could only be realised safely if the associated risks were explicitly understood and managed.

Risk tolerance

With the benefits articulated, ACW then defined its organisational risk tolerance for OT connectivity. As an operator of essential services in the water sector, this was driven primarily by safety and continuity of supply.

The business case explicitly recorded a zero tolerance for any risk that could result in the production or distribution of unsafe water. It also set a very low tolerance for any connectivity that could plausibly lead to prolonged loss of water supply. These thresholds became the baseline against which all design options, controls and residual risks would be assessed.

By agreeing these tolerances up front and securing senior sign‑off, ACW ensured that later technical decisions could be challenged objectively, rather than retrospectively justified.

Dependencies

ACW then assessed the dependencies created or reinforced by increased connectivity, recognising that digital links can reduce isolation and complicate incident response if not carefully designed.

Key dependencies identified included:

• Centralised identity and access management (IDAM) 
  ACW recognised that loss of central IDAM could prevent operator access to site SCADA systems. To mitigate this, the design incorporated credential caching and locally managed break‑glass accounts to maintain operational access during outages.
• Vulnerability management
  Connectivity enabled centralised patching, but ACW noted that sites isolated during an incident might only be patchable through local intervention. This risk was logged and deferred for explicit treatment under Principle 8, where isolation and recovery planning would be addressed.
• Remote access
  While valuable for efficiency, remote access was not considered operationally critical. ACW accepted that, in the event of an outage or deliberate isolation, engineers would revert to physically attending sites.
• Regional SCADA to RTU communications
  Prolonged loss of monitoring and control from the regional SCADA system for an extended period was identified as a major risk to water supply. To address this, the communications architecture was designed with resilience in mind, including backup mobile telecoms links in addition to primary fixed‑line connections. ACW also set a firm requirement that OT connectivity must not rely on the enterprise IT network, ensuring that OT operations could continue independently. Backup links were designed to be logically and physically independent of primary links to avoid common‑mode failures.

Governance 

Connectivity decisions followed ACW’s existing governance framework, with all designs requiring sign‑off from the accountable senior business owner. This was supported by:

• clearly defined roles for risk ownership, operations, and technical security
• regular reviews of connectivity dependencies and threat intelligence
• formal change control for modifying or removing connections
• defined security operations centre (SOC) escalation paths and response responsibilities

Assessing progression to design stage

Before approving progression to the design stage, ACW tested its assumptions through a structured workshop involving stakeholders and subject‑matter experts. The exercise was informed by the business case and aligned to the NCSC’s cyber security risk management framework, alongside IEC 62443‑3‑2 (Cybersecurity in Power Generation) and ISO 27001.

Using structured threat modelling, ACW tested realistic cyber attack scenarios against the agreed risk tolerances to determine whether the proposed connectivity could be taken forward to design. The modelling examined scenarios including:

• Loss of control
  While PLC automation meant short‑term loss of SCADA or HMI would not halt production, unauthorised manipulation of setpoints could. Securing remote user access was therefore identified as a priority.
• Loss of supply
  Sites were categorised by customer impact and time‑to‑impact, informing where additional controls would be deployed first.
• Loss of critical safety systems
  Disinfection systems were protected by electro‑mechanical safeguards designed to shut down production if water quality was compromised. ACW deemed it critical that OT connectivity could not be used as a pathway to these systems, as malicious access could trigger unnecessary shutdowns.
• Infrastructure damage
  The risk of operating assets outside safe limits was addressed by ensuring non‑digital safety protections were in place and not susceptible to cyber compromise.

This process highlighted the need for ACW to do further work to create and maintain a definitive view of their OT architecture in order to support risk‑informed decision making. Asset inventories identified legacy PLCs, HMIs, and unsupported operating systems lacking modern security features. These assets were assessed as higher risk if exposed to external networks and were therefore marked for additional compensating controls under Principle 6, alongside longer‑term replacement planning.

Outcomes

ACW concluded that, with a secure architectural approach and ongoing risk assessment, standardised OT connectivity could be delivered within the organisation’s agreed risk tolerances. Moving to a centrally approved connectivity pattern was expected to reduce overall risk by decreasing exposure to external threats, limiting the potential impact of compromise, and improving visibility and assurance across the OT estate.

Approval was given to proceed to the design and development of a proof of concept. It was noted that a final deployment would require: 

• Business impact analysis (BIA) Incorporating safety, reliability, legal, environmental, financial and reputational factors into cyber risk scoring.
• Threat actor profiling Capability/motivation scoring for adversary types sites categorised by potential customer impact in 24 hours.
• Threat vector mapping Focused on initial access, lateral movement, credential access, execution, and impact using MITRE ATT&CK to identify where threat actors could enter the system.

Through this approach, ACW ensured that all connectivity decisions:

• balanced operational benefit with proportionate protection
• remained within clearly defined risk tolerances
• preserved water safety and supply resilience

A continual review process was also established, ensuring the approach could adapt as risks, technologies, or operational requirements changed.

Following approval to standardise and expand connectivity, ACW formed a multidisciplinary team to design a secure implementation. Their first step was assessing how the changes would affect the organisation’s attack surface.

Establishing current exposure

The team began by assessing the existing exposure of the OT environment. They reviewed all external interfaces, including connectivity to public networks, third‑party providers, and the enterprise IT network. Using this information, ACW updated its definitive OT architecture documentation to include a detailed inventory of external‑facing IP addresses and the services exposed by them.

This work enabled ACW to establish an exposure and attack surface management (EASM) capability. Using this, the team validated that only intended services were externally visible and assessed whether those services were securely configured.

The initial investigation identified three main risks.

1. Always-on remote access points for vendor maintenance.
2. Direct access to OT assets from unknown/unmanaged devices. 
3. Inbound connections from the enterprise networks to support patching and AV updates.

Based on the value of this exercise, the team embedded a repeatable process to update the IP/services inventory and use EASM tools regularly. Using these tools to continually re‑evaluate exposure and identify new risks, they ensure protection evolves alongside the network.

To manage the above risks, ACW focused on 3 key areas of the NCSC's Secure Connectivity for OT:

Reducing time of exposure 

Always‑on remote access was replaced with a just in time (JIT) model, enabling OT access only when required and disabling it immediately afterwards. All sessions now must be approved and opened by the network team for specific, time‑bound tasks such as vendor PLC diagnostics. This keeps high‑risk pathways ‘off by default’ and sharply reduces opportunities for exploitation.

Managing the exposure of administrative interfaces

The assessment highlighted that administrative access to OT systems could be performed from unknown or unmanaged devices, increasing the risk that compromised endpoints could be used as a pathway into the OT environment. ACW identified that existing laptops were inconsistently built and often lacked essential security controls. Issues included outdated antivirus, delayed patching, weak firewall policies, and no effective control over web access or installed applications.

To address this, ACW issued hardened, standardised privileged access workstations (PAWs), built in line with NCSC guidance. These PAWs follow the browse‑down principle, ensuring that devices used to administer OT systems have stronger security controls than the assets they manage, and can be safely used in less‑trusted environments.

To reduce risks further, ACW moved away from allowing PAWs to connect directly to OT assets. Instead, access is now provided through brokered connections as part of the removal of inbound port exposure. In this model, administrators authenticate to a controlled access broker (for example a jump host or remote access gateway), which then establishes the connection to the OT system on their behalf. This ensures OT assets do not need to expose management ports directly to user devices, and allows access to be centrally controlled, monitored, and logged.

The same principles were applied to vendor and third‑party support access. Where remote support was required, third parties such as vendors were only permitted to connect through the controlled access broker rather than directly to OT assets. ACW additionally issued PAW devices to third parties who routinely supported their systems. In cases where this was not practical, ACW instead implemented an assurance process to gain confidence that vendor‑managed devices met an appropriate security baseline aligned with the organisation’s PAW standard. In both scenarios, access was authenticated through the broker and centrally monitored and logged in the same way as internal administrative activity.

Removing inbound port exposure

Connectivity patterns were redesigned so that OT systems no longer accept unsolicited inbound connections. This included redesigning patching and antivirus update mechanisms so that updates are initiated from the OT environment or delivered via controlled intermediaries, rather than pushed from the enterprise IT network.

ACW expanded this thinking to support legitimate remote maintenance, deploying hardened jump hosts. Remote users connect first to the jump host using their PAW, and then initiate a separate, controlled session into the OT environment. Access is restricted to the minimum required, monitored through activity logging, and reviewed as part of ongoing assurance.

This approach ensures that legacy and obsolete devices are not exposed at the edge of the OT network.

Outcomes

By understanding and actively managing its attack surface, ACW significantly reduced the exposure created by expanded OT connectivity. High‑risk access paths were removed or made time‑limited, administrative access was restricted to hardened and controlled devices, and inbound connectivity to OT systems was eliminated or brokered through secure intermediaries.

This ensured that only intended services were reachable, exposure was minimised by default, and changes to connectivity could be continuously assessed as the network evolved. As a result, ACW reduced the likelihood of initial compromise and established a strong foundation for centralised control and standardisation of connectivity under subsequent principles.

ACW had already deployed a central secure connectivity platform hosting key OT services, such as remote access gateways, patch management servers and data brokers. Consolidating these into a single hub enabled uniform application of security controls and consistent monitoring.

As part of the review initiated under Principle 1, ACW assessed whether existing connectivity aligned with this model. The review identified several sites still using direct external network links, including:

• a legacy plant with an internet ADSL line for vendor support
• a package plant system connected via mobile telecoms
• a site with a direct link to the corporate network

Each of these configurations bypassed the central platform, reducing visibility and weakening ACW’s ability to consistently apply security controls. ACW therefore undertook a structured decommissioning programme to remove these links and transition all OT connectivity through the central platform.

Standardising connectivity patterns

To prevent a return to fragmented connectivity, ACW defined and published a set of approved connectivity patterns, designed to meet common operational requirements such as point‑to‑site and site‑to‑site connectivity. These patterns were designed to be secure by default and to support the addition of further inspection and data‑flow security controls in future if required. Use of any other connectivity method was prohibited unless formally approved.

Managing exceptions through central design

During the business‑case assessment as part of Principle 1, ACW recognised that future operational needs might arise that could not be met by the initial set of approved patterns. Rather than allowing sites to implement bespoke solutions, ACW established a central design function to manage such exceptions.

Whether a new connectivity requirement could be met using existing patterns (or would require development of new centrally managed capability) was assessed as part of the initial business case and subsequent design reviews. This ensured that any new functionality was incorporated into the central architecture, aligned with agreed risk tolerances, and subject to appropriate assurance.

This approach reduced the likelihood of isolated or one‑off services being deployed in response to urgent business needs, helping ACW avoid unnecessary complexity, increased administrative overhead and inconsistent security controls.

ACW recognised that even a well‑architected network can be undermined if the data communication protocols are insecure (such as transmitting sensitive information in cleartext). As part of its secure connectivity overhaul, the company adopted a policy to implement secure protocols by default across the OT environment, and to apply compensating measures for any legacy protocols that could not yet be replaced.

Understanding protocol usage

To inform this work, ACW conducted a comprehensive audit of the protocols in use across the OT estate. The audit covered:

• industrial protocols operating within process control networks
• telemetry protocols used between RTUs and the regional SCADA system
• common IT protocols supporting OT servers and workstations

This audit provided a definitive view of where insecure or outdated protocols were relied upon and allowed ACW to prioritise remediation based on safety, availability, and exploitability.

Key risks identified and mitigations

Weak encryption algorithms

The audit identified that the regional SCADA system used a secure authentication variant of DNP3 (SAv2) that relied on the SHA‑1 algorithm. Given the known weaknesses in SHA‑1 and the criticality of SCADA availability, this was assessed as a high‑priority risk.

ACW identified that newer protocol versions (SAv5/SAv6) addressed these issues through stronger cryptography and improved key management. While an immediate upgrade was not feasible, ACW worked with vendors to develop a transition plan. In the interim, strict key management controls and additional network segmentation were implemented to reduce exposure and limit the potential impact of compromise.

Insecure industrial protocols

EtherNet/IP was identified as the most prevalent industrial protocol across ACW sites. As it lacks native encryption and message authentication, exposing it beyond tightly controlled network boundaries would present an unacceptable risk.

While extending EtherNet/IP with CIP security would provide significant improvements, it required substantial site‑level re‑engineering. ACW therefore formally recorded the residual risk and ensured that external connectivity designs prevented exposure of this protocol to untrusted networks.

To prevent risk accumulation, ACW updated its internal OT security standards to mandate the use of secure industrial protocols for all new systems and major upgrades, ensuring future deployments were resistant to protocol‑level attacks.

Insecure IT protocols

The audit also identified several outdated IT protocols in use between centralised platforms and on‑site OT servers, including legacy directory, authentication, and file‑sharing protocols. Due to the availability of well‑understood exploits and the potential for lateral movement, these were prioritised for remediation.

ACW initiated a phased programme to remove or upgrade these protocols and update the central connectivity platform accordingly.

Outcomes

By establishing a clear understanding of protocol usage across the OT environment, ACW was able to make risk‑informed decisions about where to upgrade, where to apply compensating controls, and where to accept short‑term residual risk.

Protocol usage and approved standards were incorporated into ACW’s definitive OT architecture documentation and design patterns, ensuring that secure protocol selection became a routine part of connectivity design, rather than a retrospective control.

With connectivity patterns centralised and exposure reduced through protocol and access controls, ACW now focused on strengthening the OT boundary. This boundary includes all devices and systems that sit at the edge of the OT environment and provide the first line of defence against external threats.

Identifying critical boundary assets

ACW identified the OT access hub as a particularly critical boundary control. This platform operates at the junction between the OT environment and external networks, including third‑party connections and the wider ACW corporate network. As such, compromise of this boundary could provide a pathway for initial access into OT systems.

To limit opportunities for initial access, ACW undertook a structured review of all perimeter and boundary assets.

Existing strengths 

The review confirmed that a number of effective security controls were already in place:

• Network filtering and inspection: Previous investment in next‑generation firewalls allowed traffic to be controlled at key network boundaries as part of a broader defence‑in‑depth approach to protecting the OT environment. These controls worked alongside other architectural measures such as segmented connectivity patterns, brokered administrative access, and later the introduction of a DMZ. Firewall rules were subject to routine review and audit to ensure that only services explicitly required by approved designs were permitted.
• Strong authentication for human access: Multi‑factor authentication (MFA) was in place for all remote human‑to‑machine access to OT systems.
• Controlled use of credentials: No default passwords were in use on external‑facing services. All access was provided through individually assigned user accounts, configured according to the principle of least privilege.

Improvements identified and implemented 

The boundary review also highlighted several areas where security could be strengthened.

Updates and lifecycle management 

While processes existed to ensure connectivity‑facilitating devices were supported and routinely updated, the review identified several assets approaching end‑of‑support. These were replaced as part of the assessment to avoid creating future risks at the network boundary.

ACW also recognised that systems operating at the network boundary represent an elevated risk due to their exposure to external networks. Firewalls, VPN gateways, remote access platforms and other connectivity‑facilitating components were therefore prioritised within vulnerability management and updating processes. Maintaining these systems through proactive identification and remediation of vulnerabilities, alongside timely application of vendor updates, helped reduce the likelihood that known weaknesses could be exploited to gain access to the OT environment.

Break glass

Although default credentials were not in use, ACW identified that break‑glass passwords had not been rotated since initial deployment and did not comply with the organisation’s new password policy. These credentials were reset to long, randomly generated values and stored securely, including offline copies.

This activity was also used to test alerting and escalation processes in collaboration with the SOC, providing assurance that emergency access would be detected and appropriately handled.

Context-aware controls

ACW identified that context‑aware access controls were not currently enforced at the OT boundary, despite being supported by the existing identity and access management solution.

By enabling these controls through the centralised platform, ACW introduced additional protection against unauthorised access, including blocking:

• attempts using known leaked credentials
• access from anonymous or high‑risk IP addresses
• logins from unfamiliar locations or geographically improbable travel patterns
• privileged access attempts from devices that had not been validated as PAWs

Deferred controls

ACW determined that implementing unidirectional traffic flows at all required networking flows was not feasible at this stage. This decision reflected the need to prioritise remediation of more immediate risks and limited organisational familiarity with the technology.

However, ACW were planning to digitise its Safety Instrumented Systems (SIS), introducing network-connected components that would be exposed to cyber threats from which the existing electro-mechanical safety systems were immune. Given the critical safety function of these systems, preserving their integrity was paramount, and inbound network connectivity would not be permitted.

To support operational monitoring without compromising this security posture, ACW proposed the use of unidirectional gateways. These devices would permit the outbound transmission of alarms, events, and diagnostic data from the SIS environment to monitoring systems, while physically preventing any inbound communications. This approach ensures that monitoring and maintenance activities can be performed without introducing a network pathway through which cyber threats could compromise the safety systems.

This approach allows ACW to revisit the use of unidirectional technologies for future OT deployments or if the threat landscape changes.

Outcome

By reviewing and strengthening its OT boundary controls, ACW reduced the likelihood of initial access while improving assurance that any access attempts would be tightly controlled, visible, and auditable. This work built directly on earlier principles and provided a hardened foundation for the OT environment as connectivity was expanded.

Recognising that no boundary control is infallible, ACW assumed that an attacker could eventually gain a foothold within the OT environment. The focus therefore shifted from ‘preventing all compromise’ to ‘limiting the impact of any successful intrusion.’

To support this work, ACW drew on the definitive OT architecture documentation developed earlier in the programme. This provided a clear and accurate view of network structure and trust boundaries, enabling precise threat modelling of how an attacker could move laterally within the OT environment.

Strengthening containment at the OT boundary

The review began at the OT access hub, which forms the primary interface between OT systems and external networks and is therefore a critical containment point. While existing firewall controls restricted traffic at the boundary, ACW recognised that relying on a single enforcement point could create risk if misconfiguration or vulnerability occurred.

To strengthen resilience, ACW introduced a demilitarised zone (DMZ) between external networks and the internal OT environment. This created multiple independent enforcement points between external connectivity and critical OT systems. As a result, the compromise of a single boundary component, whether through misconfiguration, an unpatched vulnerability, or an otherwise unknown weakness, would not automatically result in direct access to OT systems. This defence-in-depth approach complements broader vulnerability management and updating activities by reducing the impact of individual component failures.

The DMZ architecture applied several layers of control. 

• An external‑facing firewall limited which remote endpoints could initiate connections and required authenticated access through approved mechanisms such as VPN or TLS termination. Connections entering the DMZ could then be inspected and monitored at every layer of the stack, from network to application payload before being permitted onward. 
• A further firewall enforced the boundary between the DMZ and the internal OT network. This layer implemented tightly defined communication paths so that only explicitly authorised services and destinations could traverse into the OT environment.

Importantly, no direct network connection existed between the external-facing firewall and the internal OT firewall. Instead, communications were brokered by dual-homed servers located within the DMZ, with one network interface connected to each security zone. These systems terminated and re-established communications across the security boundary, preventing direct TCP/IP connectivity between external and internal networks. This created a protocol break that further limited attack propagation and provided an additional layer of protection for critical OT systems.

Where appropriate, ACW also considered the trust level of different connections. For example, connectivity supporting internal corporate users was separated from third‑party access to reduce the risk that compromise of one trust domain could affect another.

ACW also recognised that systems and devices operating at the network boundary represent an elevated risk due to their exposure to external networks. Firewalls, VPN gateways, remote access platforms, protocol brokers and other edge networking components were therefore included within proactive vulnerability management and updating processes. While the layered architecture reduced the impact of a single component failure, maintaining the security of boundary systems through timely updates and remediation remained an essential control.

This layered design ensured that no single control determined the security of the OT boundary. It also created clear points where additional inspection, monitoring, or traffic‑flow controls could be introduced in future as threats evolve or organisational risk tolerance change. 

Controlling the import of files into OT

ACW used the DMZ to host services responsible for inspecting any files required to enter the OT environment, such as software updates or configuration data. Files were checked for malware and, where applicable, validated for authenticity.

Where possible, complex file formats were converted into simpler representations (for example, a spreadsheet in a complex office document format into CSV files) to reduce the likelihood that embedded malicious content could be used to compromise OT systems. This reduced the risk associated with a common and often avoidable attack vector.

Reducing lateral movement within OT

Beyond the boundary, ACW identified further opportunities to reduce the potential impact of compromise.

Advanced segmentation

Network segmentation was strengthened by replacing standard service‑provider routers with centrally managed security gateways combining the deployment of firewalls with OT‑aware intrusion detection and prevention capabilities. These were deployed at sites requiring higher protection.

Rules were tailored to OT use cases, such as enforcing read‑only communication between reservoirs and pumping stations. At more complex facilities, these gateways were used to divide flat process control networks into smaller security zones, in some cases isolating individual high‑value assets such as SCADA servers. This significantly limited an attacker’s ability to pivot between systems.

Host-based firewalls

At the asset level, host‑based firewalls were deployed on SCADA platforms, HMIs and supporting systems. These allowed only explicitly required services, such as EtherNet/IP (CIP) and RDP, blocking all others to reduce attack surface.

ACW recognised that host‑based controls on obsolete operating systems could potentially be bypassed if an attacker obtained OS‑level access. In this environment, remote desktop protocol (RDP) was used to administer these hosts and could therefore provide a pathway to compromise if not tightly controlled.

Administrative connectivity was therefore restricted to secured jump hosts, providing a controlled management pathway with a centralised point for additional authentication, monitoring and policy enforcement.

Network‑level monitoring was also applied to these administrative connections to provide compensating detection and assurance for the obsolete systems.

Outcomes

By combining DMZ separation, controlled file‑import mechanisms, enhanced segmentation, OT‑aware IDS/IPS and host‑level filtering, ACW established layered defences designed to contain compromise and limit its operational impact.

This approach ensured that even if an attacker gained access to part of the OT environment, their ability to move laterally, escalate privileges, or affect safety‑critical systems was reduced.

ACW recognised that, even with robust preventative and containment measures in place, some forms of compromise might still occur. To enable timely detection and response, logging and monitoring were treated as core design requirements rather than optional operational add‑ons.

Extending monitoring into OT

ACW already operated a SOC covering enterprise IT systems. As part of the secure connectivity programme, this capability was extended to become OT‑aware.

The team identified event sources within the OT environment that could be readily integrated with existing SOC processes. These included IDAM systems, firewalls, operating systems, and endpoint protection platforms, alongside OT‑specific sources such as intrusion detection system (IDS) alerts.

A review of assets also found that newer PLCs and industrial ethernet switches provided simple but valuable security event logs, including authentication failures. To collect these, ACW deployed a syslog server within the OT access hub, forwarding events to the central SIEM. Because these logs closely resembled familiar IT event types, such as access control records, SOC analysts were able to interpret them with minimal additional training.

ACW were able to use the NCSC’s Operational OT Data Export example to aid in the design of a secure log export solution from OT.

Improving detection capability

With logs centralised, ACW identified several opportunities to strengthen detection of unauthorised activity.

Analytic rule development

Centralised logging enabled the development of analytic rules to correlate events across systems and highlight suspicious behaviour, such as brute‑force login attempts or indicators of malware activity. For example, unusual HMI login patterns could be correlated with anomalous network behaviour to raise SOC alerts.

Monitoring of break‑glass account usage

Use of break‑glass accounts, intended only for emergency access, was configured to generate high‑severity alerts when used on OT assets. This ensured rapid investigation of any such activity.

Baselining and anomaly detection

The relatively static and predictable nature of OT communications made them well suited to monitoring that uses baselines. ACW established expected patterns of behaviour and configured alerts for deviations from these baselines.

Recognising that planned maintenance activities could generate unusual but legitimate events, ACW introduced a process for operational teams to notify the SOC in advance of maintenance windows. This allowed alerts to be tuned or reviewed with appropriate context, reducing false positives while preserving visibility.

Monitoring data flows between zones

ACW’s OT protocol‑aware IDS was used to monitor traffic between security zones. Alerts were generated when unexpected commands or messages were observed, or when permitted communication paths were used for unintended purposes.

For each alert type, ACW developed SOC playbooks to ensure a consistent and effective response. These covered:

• triage to confirm true positives
• assessment of incident severity
• immediate containment actions
• escalation to the appropriate technical and operational teams

Outcomes

By integrating IT and OT event sources into a single SOC view, ACW established continuous monitoring across its connectivity environment. This significantly improved the organisation’s ability to detect anomalous activity early, reduce attacker dwell time, and respond effectively to potential incidents.

ACW recognised that effective monitoring must be matched by the ability to take rapid, proportionate action under pressure. In the event of a cyber incident affecting OT systems, the organisation needed to be prepared to isolate parts of the environment to protect process safety, maintain essential services, and support decision‑making during a crisis.

This approach aligns with the NCSC’s guidance on planning and preparing for severe cyber threat for critical national infrastructure, which emphasises the importance of preparing containment actions in advance so that organisations can act decisively when faced with high uncertainty and time pressure.

Purpose of isolation

ACW treated isolation as both a reactive and proactive control:

• reactive - to contain confirmed compromise, limit lateral movement, and prevent escalation
• proactive - to reduce exposure during periods of severe cyber threat, such as when credible threat intelligence indicates an increased likelihood of attack

Isolation decisions were therefore designed to be executable even when the full scope of an incident was not yet understood.

Triggers for isolation

ACW identified a set of plausible scenarios that could require isolation, informed by threat intelligence and sector experience. These included:

• malware such as ransomware, with the potential to propagate rapidly across networks
• intelligence indicating a capable and motivated adversary had identified an exploitable weakness
• large‑scale compromise of authentication data that could enable unauthorised access

These scenarios were used in tabletop exercises and crisis rehearsals to test decision‑making and communications under realistic conditions.

Developing an isolation plan

To support rapid, informed decisions during an incident, ACW developed a documented isolation plan as part of its wider cyber crisis response framework. The plan brought together cyber, operational, and safety considerations, and referenced:

• the definitive OT network and system architecture documentation
• existing boundary, segmentation, and monitoring controls
• common OT threat vectors and attack patterns
• potential impacts on safety, supply, regulatory obligations, and public confidence
• predefined containment actions that could be taken immediately
• the operational consequences and recovery considerations associated with each action

This ensured that isolation decisions could be taken with a clear understanding of trade‑offs, rather than relying on ad‑hoc technical judgement during a crisis.

An up-to-date physical copy of this isolation plan was stored in a safe and secure location at key sites to provide redundancy in a wider enterprise IT outage or ransomware incident. 

Isolation approach

ACW assessed full site isolation but determined that disconnecting RTUs from the regional SCADA system would significantly reduce central monitoring and control, potentially creating additional operational risk and business continuity impacts.

Instead, ACW adopted a service‑level isolation model, enabled by the centralised and segmented architecture established under earlier principles.

Two primary isolation options were defined:

• targeted service isolation - where specific services suspected of acting as an access route for an ongoing threat could be quickly blocked
• restrictive isolation - where all services except the essential telemetry protocol between RTUs and the regional SCADA system were blocked

These actions could be implemented by modifying predefined rulesets on firewalls within the OT access hub and, where deployed, on site‑level firewalls. For restrictive isolation, ACW maintained an approved and tested firewall policy that could be rapidly applied without requiring emergency design changes.

While firewall policy changes provided the primary mechanism for implementing isolation, ACW recognised that no single control should be relied upon in isolation. The layered boundary architecture described earlier including the DMZ, multiple firewall enforcement points, and segmented internal networks provided additional containment should a single device or control be bypassed or compromised.

This approach allowed ACW to scale its response based on the quality of available information, consistent with NCSC guidance on operating during severe cyber threat where uncertainty is unavoidable.

Outcomes

By establishing and rehearsing an isolation plan in advance, ACW ensured it could act quickly and confidently to contain cyber incidents affecting OT systems. The plan enabled proportionate responses that balanced safety, availability and security, and reduced the likelihood that hesitation or uncertainty would exacerbate an incident.

This completed ACW’s secure connectivity approach by ensuring that detection, containment, and recovery were fully integrated into the OT design and operating model.