Or would this be some other kind of physical interface that took some kind of read-only data (serial?) and sent it up the layers using TCP/IP, where only this box would be at risk?
Edit: looks like you answered part of this below — you suggest switching to UDP protocols.
Apart from this being technologically impossible, if he would have really done it he would have been charged for endangering an aircraft and prosecuted. (So the only explanation why he isn't in prison is that it didn't happen). The technical reason is Data diodes are common in aviation to separate IFE and CAN bus or position data. (e.g in the ARINC)
[1] https://www.pentestpartners.com/security-blog/a-pen-testers-...
SCADA devices are not read-only.
But a hacker wouldn't be able to use their access to the Timeseries database for supply chain and logistics, to pivot to the SCADA system because their attempts would be blocked by a lack of a physical layer connection in that direction.
It would significantly reduce the attack surface of the OT systems.
That would be like deploying the landing gear of the airliner, because someone triggered a bug while changing the channel on the in-flight entertainment system.
A webcam? Second hand, but that's what I was told a dam operator was using as a "grass-roots" solution a while back
Firewalls are currently used, and probably generally configured well. Petrochemical companies have a many-layered onion security strategy with minimal communication paths through the firewalls. Generally you might have 4-8 layers of firewalls from public facing internet to the PLC/DCS/SCADA. Administrative people might VPN 1-2 layers deep and engineers would at worst get remote access to the historian, 1-2 firewall layers above the PLC/DCS/SCADA.
It's my professional opinion that firewalls are not good enough for critical infrastructure. Even a completely air-gapped system was hacked thoroughly over a decade ago in Iran (See Stuxnet).
Your suggestion would suffice, if that box ("gateway", in the IoT parlance) was connected with a one way physical connection to the SCADA system over serial or what-have-you. Then it could communicate with TCP using existing application stacks.
I am designing a system like this at my current job, where luckily we are a small enough team so people have genuinely listened to my suggestions about this.
However, good engineers often disagree with me. I may be overly zealous on this particular issue and I take a lot of criticism about how dogmatic I am at times. I'm not a senior engineer by any stretch.
Low, fixed-bitrate transfer over unidirectional fiber optics. Unidirectional transcievers are the norm for long-haul fiber.
My local electrical utility is still running 11.52kbps RS-232 over fiber for exactly this reason. At those bitrates you don't need backpressure -- your disk will never fill up and if the CPU can't handle that bitrate you already have much larger problems.
It's kind of funny that they have sheaths where one strand is running this piddly dozen-kilobit protocol and other strands in the same sheath are doing 10gbit/sec * 16-channel CWDM.
Most electrical utilities are into fiber optics in a very big way; they already (usually) own the poles and unlike copper it's nonconductive. Many of them have vastly more strands of fiber between substations than they need.
The ones I have worked with convert a TCP stream to UDP, send it across the diode, and then convert it back to TCP. Each UDP packet has a sequence number and there is a single reverse-diode that is fired when a packet is missed or arrives out of order that triggers a retransmission of the last N packets.
A common example is a SQLServer database of all industrial data that is authorized to share with the enterprise. Grab new and changed data as it arrives on the industrial side. Push unidirectionally to the enterprise side. Insert/update the data in an identical SQLServer. Enterprise users & applications interact normally and bi-directionally with the replica database.
The technology is used routinely to provide access to industrial data that enables business efficiencies, without providing access to the industrial systems that produce the data.
For more info see: https://waterfall-security.com
The US government term of art for this pattern is a “guard”, often with a regex or manual filter.
The inside (isolated) server would poll everything, store it into a buffer, and send that buffer (plus error correction) out through an optoisolator to other server.
The outside (internet facing) server would then keep up with the ring buffer, and serve requests, and do any outbound push of data via any protocol required.
A system to do this could be made with a pair of raspberry pi computers and a little bit of discrete components for less than $150 in hardware costs.
