Author: Richard Petter

I am an information security consultant with over 25 years of experience helping organisations protect sensitive data and build secure networks. Over the years, I’ve worked with products and solutions from all major security vendors, giving me a broad understanding of how to defend against today’s evolving threats. My expertise covers securing data at rest and in transit, implementing advanced network security strategies, and advising on best practices for data protection. Right now, I’m particularly focused on how anomaly detection and threat monitoring can be integrated into security operations to provide earlier, smarter defences against attacks. Whether it’s strengthening resilience, improving compliance, or optimising security tools, I help businesses stay one step ahead in a constantly changing digital landscape

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:

Audit everything connected to the internet corporate, OT and BMS.
Establish what remote access each device actually requires.
Only permit that access.
Use MFA wherever it is supported, particularly at remote-access boundaries.
Put third-party maintenance access behind a bastion/jump host.
Make use of that controlled path mandatory if you don’t use it, you don’t connect.
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.

The CLI is dead. Long live the CLI.

(Or perhaps it just speaks API now.)

Classic migration project. ASA to Firepower.

The customer needed another hundred or so network objects and NAT statements adding.

As soon as I heard “about a hundred”, my first thought wasn’t “Right, let’s get clicking.”

It was “This is an automation problem.”

I’d solved something similar before using Postman, importing a CSV and letting the Collection Runner do the heavy lifting.

Except… the Collection Runner now sits behind a paid subscription.

Fair enough. Postman is a commercial product, and good software deserves paying for.

Unfortunately for them, As my children will tell you I’m spectacularly reluctant to spend money especially if I think I can build a workaround..

So necessity became the mother of invention.

A short Python script converted the CSV into the JSON structure the Firepower API expected. Paste the JSON into the request body, hit send…

“…is that working?”

It was.

Around a hundred objects and NAT statements created in less time than it took to ask the question.

The interesting part isn’t really the Python.

It’s how quickly our daily work is changing. Five years ago I’d have accepted repetitive configuration as part of the job.

Today, if I find myself doing the same task more than a handful of times, my first instinct is to ask whether the API can do it instead.

#Automation #Python #APIs #CyberSecurity #NetworkEngineering

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?

Taking a step back from a year of Secure Access deployments…

Looking beyond the engineering, the real business upside becomes clear:

• Zero Trust enforcement delivered from the cloud no longer constrained by on-prem perimeter
• Trust shifted from network location/subnet to identity and device posture
• Per-application access rather than exposing the full corporate network

This isn’t just an upgrade of the traditional VPN . It’s a reduction in implicit trust. It reduces lateral movement risk, limits blast radius, and aligns security controls to a hybrid workforce model. Secure access done properly is not about connectivity it’s about changing the organisation’s risk posture.

Future enhancements: Conditional access continues this evolution. Access decisions can adapt dynamically based on user identity, device posture, location, and application sensitivity enforcing Zero Trust in real time. This strengthens security while improving user experience, only stepping in when risk warrants it.

I’d be interested to hear how others are approaching Zero Trust adoption. Are you prioritising identity-first access, or still relying on traditional network perimeters?

#ZeroTrust

#CloudSecurity

Behavioural Security Metrics and Illegitimate User Detection

Why behavioural security metrics like typing velocity matter when geofencing and zero trust assumptions fail.

This is a really interesting read and a genuinely innovative way of detecting illegitimate users on corporate devices.

Geofencing and heavily locked-down endpoints have limits — particularly when facing nation-state actors using proxy infrastructure, or supply-chain delivery of corporate laptops.

Without wishing to be dramatic, I think security professionals need to recognise that this is the environment we’re now operating in.

At that point, behavioural metrics like typing velocity begin to matter.

What should “normal” network behaviour look like?
What does the bulk of user activity look like?

Log on at 08:30, log off at 17:30.
Who stays online after that — and for how long?
Is that consistent with how they’ve worked historically?

Data transfer rates matter too. Kilobytes. Megabytes. Gigabytes. And occasionally… terabytes.

When the spike appears, does it fit the baseline at all.

Zero Trust has its own operating environment. Once that environment is breached, behavioural signals start to matter far more than controls.

Scope Creep

Scope Creep

I’ve always liked the phrase scope creep not the reality of it, just the wording.

Maybe it’s my fondness for zombie films. Whether it’s the slow, inevitable Romero-style shuffle or the newer, faster variants, they don’t announce themselves. You only realise what’s happening when they’re already too close.

That’s exactly how scope creep behaves in technical projects — and why it’s so damaging.

It rarely arrives as a formal decision. Instead, it slips in through side conversations, “small” assumptions, and unclear ownership — until a straightforward migration quietly turns into a transformation.

In security and infrastructure work, migration versus transformation isn’t semantics. It changes architecture, risk, timelines, and commercial commitments. When that distinction isn’t made explicit, the technical team is left trying to reconcile incompatible expectations.

The solution isn’t heroic engineering.
It’s governance.

Pause. Clarify. Write it down.

Clear scope, clear ownership, and phased delivery aren’t bureaucracy — they’re how you stop projects being overrun and protect both delivery quality and customer trust.

I like the phrase.
I just don’t like what happens when no one deals with it early enough.

Curious to hear others’ worst examples of scope creep or, failing that, favourite zombie films?

Defending Against Cyber Kinetic Attacks: Strategies for Teams

Cyber Kinetic

I came across a new term while reading This Is How They Tell Me the World Ends by Nicole Perlroth a brilliant deep dive into the cyber arms race.

It describes a cyberattack with kinetic (real-world) effects attacks that move beyond the digital realm to cause physical harm. Think dam gates opening, power grids failing, or emergency numbers going dark.

These are the nightmare scenarios and they’re becoming more common, and increasingly difficult to defend against.

So how do we, as smaller IT and security teams, defend against a motivated adversary with nation-state resources and patience?

Do we accept that everything networks, endpoints, even our assumptions is already compromised, and build around that reality?
A “not if, but when” mindset where resilience matters more than prevention?

Air-gapping, while useful, has its own gaps (Pun inteneted) especially in operational technology, where updates and maintenance often become the very vector for compromise.

Is end to end encryption, to inculded data at rest and data in motion a way to solve this.

Perhaps it’s time we shift the conversation: from stopping attacks, to surviving them and acknowledging what security professionals are truly up against.