OT security explained: why valid credentials aren't enough

0:00Trust between machines

Every plant, substation and pipeline runs on trust between machines. kin ensures that the provenance of each device in the connection is, and remains, exactly what it's supposed to be, and that nothing has changed along the way.

0:12Five attacks that look legitimate on the wire

Stolen credentials are one of the most common ways in, but they're not the only one. A cloned device can present a real device's identity. Firmware, software or even hardware can be quietly changed. Something can be slipped onto the path between two machines to read or alter what passes through. And genuine commands can be captured and replayed. Every one of these looks legitimate on the wire. Your firewall, remote access, monitoring and PKI all do their jobs, but they trust a device once. Nothing proves it stays exactly what it was, or that the path between hasn't changed. That's the white space kin fills.

0:49Why the gap exists

Here's why that gap exists. Since public-key cryptography arrived in 1976, authentication has rested on stored keys and certificates that can be stolen, copied and reused. Trust is granted once, then assumed. kin takes a different approach: Continuous Proof Trust, born out of the work of mathematicians and cryptographers at the University of Oxford. Trust isn't inherited from a stored credential. It's proven fresh, over and over again, as the provenance of each device is reauthenticated in every packet, for as long as the connection is open.

1:27kin proves the device, the path and every packet

kin proves three things, continuously: the device, the path, and every packet. Each device is provisioned once. From then on, kin proves its provenance: that it is what it claims to be, and that it hasn't been changed. Every packet is encrypted and carries anti-cloning and anti-tampering markers, verified by the receiving device. So anything inserted, altered or replayed along the path triggers an alert and a user-defined action. A device kin has never seen gets nowhere: its packets are dropped. And every connection, including the traffic exchanged over it, can be audited.

1:59One attack on a plant floor (illustration)

Here's one of those attacks on a plant floor: a contractor's valid credentials, used from a device that isn't part of the kin network.

This line is running normally. Firewall in place. Remote access locked down. Monitoring on. But a contractor's username and password have been stolen. Today, that's all it takes. The attacker signs in remotely, changes a setpoint on the PLC, and the process runs out of range. Every tool in the stack let it through, because the credentials were valid.

Now add kin. The contractor connects from his provisioned laptop. Before any sign-in screen appears, kin checks the device itself: its behaviour, its environment, its shared history. It passes, and he signs in like always. The attacker tries the same credentials from his own machine. It fails every check. His packets are dropped. There's no sign-in screen, nothing to type into. The connection just times out.

2:59The same moment in a recorded test

Here's that moment in a real test. A device that isn't part of the kin network tries to connect. Its provenance is unknown, so it simply times out. The line holds at its setpoint. The connection was never made, so there's nothing to chase down.

That's Continuous Proof Trust. Traditional security trusts a device once it's signed in. kin keeps proving every device is what it claims to be, so stolen credentials alone aren't enough.

3:29Where kin fits in your stack

So where does kin fit? Each layer you run does its job. Your firewall allows traffic on approved paths, but it can't tell whether the device on that path is the real one. Remote access checks a user's credentials, but not whether they're coming from the approved device. Encrypted tunnels protect data in transit, but not against an endpoint that's been cloned or tampered with. PKI confirms a certificate is valid, not whether it's been stolen, copied or replayed. And monitoring watches for unusual behaviour, but a cloned or altered device can look perfectly normal. kin fills each of those gaps by proving the device, the path and every packet, continuously.

4:09Tested on the equipment you run

kin has been tested on the kind of control equipment that runs plants and critical infrastructure. Panduit examined kin running with Rockwell PLC data. In hundreds of controlled test runs by Iothic, kin blocked or flagged every attack attempted. And kin protects against spoofing, cloning, tampering, replay and man-in-the-middle attacks.

4:30Nothing to rip out

There's nothing to rip out. kin runs alongside your firewall, monitoring, remote access and PKI, machine to machine, so your people keep the logins they already use and never see kin. Gateway mode protects legacy devices that can't run kin themselves. If something inside the protected network is altered, kin alerts your team in the tools they already use. And with kin Library, kin can be built into the software you already buy.

4:51Start with a pilot

The easiest way to see it is a pilot. Start with one production line, one remote site like a substation or pump station, or one remote access path. kin runs alongside your existing stack, with no change to the process. And we agree what success looks like up front. Devices without provenance known to the network are prevented from establishing any connection. Cloning, tampering and replay trigger an alert and the response you've chosen. Every connection can be audited. And normal operations carry on undisturbed.

kin, from Iothic. Talk to us about a pilot.