In another episode of It’s Always the Basics…

The newsworthy attack on refrigeration systems in France appears, at the time of writing, to have involved internet-connected refrigeration controllers running outdated software, including equipment that is now end-of-life.

Once the attackers had access, they were able to manipulate the refrigeration controls, reportedly forcing systems into continuous defrost cycles and pushing temperatures towards 50°C. The result was spoiled food, damaged equipment and, in some locations, reports of fires.

And this is where Operational Technology (OT) worries me.

A compromised corporate system can result in lost data, ransomware or disruption.

A compromised OT system can have real-world, physical consequences.

The remote access presumably exists for a perfectly sensible reason: refrigeration engineers need to maintain these systems without travelling to every site.

But we appear to be learning the same security lessons again and again:

Change the default passwords.

Patch the devices.

Don’t expose management interfaces directly to the internet.

Don’t allow remote access from locations that have no reason to access them.

This has been demonstrated previously: https://lnkd.in/p/ewQ77-72

My own rather less dramatic example happened this week.

I woke up to find a login attempt against one of my cloud accounts from Rajasthan at around 3am.

Fortunately, some time ago I’d enabled MFA.

It’s not a panacea, but in this instance one very basic security control removed most of the worry and potential heartache of someone taking over the account.

So perhaps the strategic security plan for an organisation of almost any size doesn’t need to start with another shiny product.

Start with:

  1. Audit everything connected to the internet corporate, OT and BMS.
  2. Establish what remote access each device actually requires.
  3. Only permit that access.
  4. Use MFA wherever it is supported, particularly at remote-access boundaries.
  5. Put third-party maintenance access behind a bastion/jump host.
  6. Make use of that controlled path mandatory if you don’t use it, you don’t connect.
  7. And most importantly: make somebody responsible for all of the above.

None of this is particularly exciting.

None of it is new.

But attackers don’t get extra points for sophistication.

If the basics give them a way in, they’ll use the basics.

Data sovereignty and Weasel words

Data sovereignty isn’t really a technology discussion. It’s becoming a geopolitical one.

You can no longer rely on global trust.

That assumption is weakening.

Your most sensitive data is one of your organisation’s strategic assets. Don’t let ambiguous language define how it’s protected.

Over the past 20 years, many of us optimised for efficiency because we assumed global trust. Just-in-time deliveries, cloud platforms unhindered by jurisdiction, and globally integrated supply chains all relied on that assumption. That trust is breaking down, and many countries, and soon many organisations, are going to have to consider what that means for them.

“Data sovereignty” can mean many different things. Which of the following does it mean to you?

  • Does it mean the data is stored in-country?
  • Does it mean only local engineers administer it?
  • Does it mean encryption keys never leave your jurisdiction?
  • Or does it mean no foreign government can legally compel access?

The phrase “data sovereignty” is meaningless until everyone in the room agrees what it actually means.

Ask five different vendors and you may well get five different answers.

The US CLOUD Act illustrates that the physical location of a server isn’t the only question. Legal jurisdiction matters too. The EU may ultimately move in a similar direction. History suggests governments rarely seek less access to strategically important data.

This isn’t an argument against cloud. Public cloud remains an extraordinary platform.

It is an argument for classifying data according to geopolitical risk as well as technical risk.

For many organisations, that probably means asking different questions about:

  • PKI
  • Encryption keys
  • Privileged identities
  • HR systems
  • Financial systems
  • Core intellectual property

The answer is unlikely to be “everything on-prem” or “everything in the cloud.”

Increasingly, it’ll be both.

If your board asked you to define “data sovereignty” in one sentence, could everyone in the room agree on the answer?