Four days offline: What the UK power plant cyber incident should teach us

There has been plenty written over the past month about the cyber-attack affecting a small UK power generator.

Some of the headlines have understandably focused on the attacker, the energy sector and the potential implications for UK critical infrastructure. Those are important conversations.

But there is also a much simpler lesson here.

Know what you've got. Know where it is. Know what it's connected to. And know whether somebody on the internet can reach it.

The facility was reportedly offline for around four days. There was no reported interruption to electricity supplies or wider impact on the UK energy system, but the incident is another useful reminder of the potential for cyber activity to cause real-world operational disruption.

The timing is also important

The National Cyber Security Centre (NCSC) warned of increased targeting of operational technology, including activity affecting UK organisations. The NCSC highlighted the risks associated with internet-exposed systems and edge devices and called on organisations to understand their exposure, address avoidable vulnerabilities and build longer-term resilience.

So rather than adding to the speculation around one incident, perhaps the more useful question is:

What does our own Operating Technology (OT) environment look like, and can we demonstrate it?

Getting the basics right

Asset management sits at the start of good cyber security for a reason.

The ‘Center for Internet Security (CIS) Critical Security Controls v8.1 Industrial Control Systems Guide’ and ‘Cybersecurity and Infrastructure Security Agency’s (CISA) Foundations for OT Cybersecurity: asset inventory guidance’, reinforce the same basic principle: understand the environment you are trying to protect.

That doesn't necessarily mean another expensive platform or sophisticated Configuration Management Database (CMDB). In some environments, a well-maintained spreadsheet may be perfectly adequate.

What matters is whether the organisation knows what the asset is, what it does, where it sits in the network, who owns it, what it connects to and how important it is to the operation.

Then understand the connectivity. What crosses between zones? Which protocols are permitted? Is the traffic monitored? When was the connection last reviewed? Has the risk been assessed?

You can't protect an environment you don't understand.

Connectivity needs to be deliberate

The NCSC's Secure Connectivity Principles for Operational Technology reinforce those same fundamentals. To minimise exposure, control connectivity, harden OT boundaries, limit the impact of compromise, monitor what crosses those boundaries and know how to isolate systems when required.

IEC 62443 gives us an established zones and conduits approach for putting segregation into practice.

It also means challenging arrangements that may simply have become normal over time: flat networks, unnecessary IT-to-OT connections, permanently enabled third-party access, shared services or active directory dependencies spanning IT and OT without appropriate separation.

A firewall between IT and OT doesn't automatically mean the environments are properly segregated.

Good architecture should tell us what is allowed to communicate, why that communication is necessary and what happens if either side of the connection is compromised.

Show me

This is where assurance comes in.

• Don't just tell me there's an asset register. Show me.
• Show me the critical OT assets and where they sit in the architecture.
• Show me the connections between zones, the protocols crossing them and how they're monitored.
• Show me how remote and third-party access is controlled.
• And show me when those connections and their risks were last reviewed.

It doesn't need to be complicated. It does need to be understood, owned, current and evidenced.

Four days offline – what would recovery look like for you?

The facility was reportedly offline for around four days.

It would be wrong to look at that figure alone and draw conclusions about the effectiveness of the organisation's recovery.

We don't know the full circumstances of the incident or everything that happened during those four days. A significant OT cyber incident is rarely just a case of restoring a system and switching it back on.

There may be containment decisions to make, forensic evidence to preserve and analyse, regulatory and reporting obligations to meet, engagement with external incident responders and law enforcement or national cyber authorities. In an OT environment there are additional requirements to establish these systems, controller logic and engineering configurations are trusted so that returning equipment to service can be done safely.

Recovery therefore starts long before recovery itself

Organisations need an incident response plan that supports the complete incident lifecycle: preparation, detection and analysis, containment, eradication, recovery and most importantly: lessons learned.

That plan also needs to work alongside operational, safety, business continuity, disaster recovery and crisis management arrangements. Everyone should understand who makes decisions, who needs to be contacted and what evidence needs to be preserved.

Then exercise it.

‘A Recovery Time Objective (RTO) that has never been exercised is still an assumption.’

A Recovery Point Objective (RPO) that has never been tested against the configurations and data actually needed to recover isn't much better.

Tabletop exercises are valuable, but don't stop there. Test technical recovery. Test communications. Test decision-making. Test third-party involvement. Test whether known-good configurations and backups really can be restored.

Exercise. Learn. Improve. Exercise again. That's how recovery assumptions become recovery capability.

We aren't short of guidance

There is plenty of good guidance available.

The NCSC Secure Connectivity Principles cover how OT connectivity should be designed and managed.

The CISA OT Asset Inventory Guidance focuses on understanding assets, communications and dependencies.

The CIS Critical Security Controls v8.1 ICS Guide applies the CIS Controls specifically to industrial environments.

IEC 62443 provides established approaches to zones, conduits, segmentation and defence in depth.

The NCSC Cyber Assessment Framework provides an outcome-based approach for assessing whether cyber security and resilience measures are actually working.

And the UK Government's Cyber Governance Code of Practice brings the conversation back to leadership: understand the risk, establish accountability, build the right culture, gain assurance and ensure incident response and recovery arrangements are exercised.

Different guidance. Same underlying message.

Know what you've got. Understand how it's connected. Control it. Monitor it. And practise what you're going to do when something goes wrong.

Need some assurance?

And if you don't know exactly where you stand today, that's okay. That's where independent advice and assurance can help.

CGI is an NCSC Assured Cyber Security Consultancy (ACSC), providing NCSC-assured services across Security Architecture, Risk Management, and Audit and Review. CGI is also an NCSC Cyber Resilience Audit (CRA) Assured Service Provider, delivering independent cyber resilience audits aligned to the NCSC Cyber Assessment Framework (CAF).

Whether you need to understand your OT exposure, review an architecture, assess cyber risk, test your incident and recovery arrangements or gain independent assurance over your resilience, we're happy to have a conversation.

Sometimes the best place to start is simply asking:

Show me what we've actually got.