Then add a bridge that connects the two buses where you could just pull a fuse for a total disconnect. The bridge would have to have a very simple protocol to make it difficult for a worm to cross.
That’s how I’d do it if I had to design a ship that also had to be networked.
Oops, the technician was having some problems one day, so they plugged a wireless device on one bus and another on the other bus so even after pulling the fuse hackers still had control.
Of course, if they are connected by default, it's very likely the hacker could establish control of a device on the secure side of the bus and load up something in NVRAM on it maintaining control even after a disconnect.
Well I didn't add this but I would stipulate that the secure side would have almost no permanent memory at all if possible. I mean, we've been controlling boats without electronics for millenia so if you make it a priority to have no permanent memory, it should be achievable.
It's doable. The biggest issue is that all these engineers are gonna cost $$$$ to design these systems and you will need to do a lot of QA, which also costs $$$$.
It could be doable to transition back to pneumatic PID blocks by some royal decree but it’s definitely not going to be any real government’s solution. PLC’s are here to stay for all complex machines, and these ships are relatively complex.
More interesting to talk about options that could realistically happen, and discuss pros/cons of various government/industry solutions that are actually likely to occur.
I wish I could find a cutaway of a pneumatic PID block though. They’re quite amazing technology that implemented true P-I-D “calculation” logic in a purely physical form by using pressure of air at two inputs (setpoint, current value) to control one output penumatic pressure which in turn would control some valve a distance away. Really amazing engineering we had before electronic control! The air lines had a bad tendency to get clogged up though.
Specifically, either don't plug wireless devices on the trusted network, or have some procedure that makes it damn sure any such device will be unusable when the ship is running.
We have some ways of protecting against malicious firmware, but the kind of consumer hardware that gets those is so complex and flawed that you are better without. If the hacker needs full physical access to the ship before the attack, you are about as good as you can get.
Two small devices should be fine... you're just bridging the bus with something that can communicate with the bus. The 'unsafe' side of the bus will be doing all the heavy lifting for you across your unauthorized bridge. Think more like "IT guy leaves diagnostic connection up on laptop while connected to wireless type event.
Yeah, well I wouldn't have any component on the secure side have any permanent memory.
PLCs (as used in the Iranian centrifuges) are basically made to re-programmed on the fly. You use them because you didn't want to hire out a team to build a system so it's 1000x cheaper, but it means they are infinitely hackable. They're basically a port 80 web server on your network that openky dumps code into Bash to be run. Having them on any network is extremely dangerous.
If I were to buy a product from a company, I would hope I am paying them good money to at least dedicate some engineering to build a custom device. You know, with circuits and non-networked signed EEPROM. Not ship control code in Bash on port 80.
And at the end of the day, you can't guarantee anything to be unhackable, but practicing defense in depth makes it hard as possible.
But anyway, I think the main issue is that ship companies are not tech companies and don't really have the money to build this. /shrug
> Yeah, well I wouldn't have any component on the secure side have any permanent memory.
Right. It should be possible to force critical systems to restart from ROM and refuse any network updates.
Useful reading: Nevada Gaming Commission technical regs.[1] A typical section:
"System based games must be capable of verifying that all control programs contained on the server or system portion are authentic copies of approved components of the gaming device both automatically, at least once every 24 hours, and on demand. The authentication mechanism must employ a hashing algorithm which produces a messages digest output of a least 128 bits. If the message digest is stored on a memory device other than a Conventional ROM Device the digest must be encrypted using a public/private key algorithm with a minimum of a 512 bit key or
must be a bit-for-bit comparison. The mechanism must prevent the execution of any control program component if the component is determined to be invalid. Any program component of the authentication mechanism must reside on and securely load from non-alterable storage media. A report shall be available which details the outcome of each automated execution of the authentication mechanism and shall identify any program components determined to be invalid."
The parts that verify integrity have to be in ROM, and everything else has to be signed and checksummed. The Gaming Commission prefers that as much as possible be in ROM.
"Remote access to a gaming device may only be granted for the following activities:
(a) Monitoring system health and performance;
(b) Scheduling operational gaming device functions such as downloading of content;
(c) Troubleshooting system issues;
(d) Performing inquiry-only functions such as viewing logs or generating reports"
No remote updating or patching of gaming software. Just inquiries. For changes, someone has to physically go to the device.
"System based games shall be configured such that system administrator level access may not be achieved without the presence and participation of at least two individuals."
Not just two-factor authentication, two people authentication.
"A dedicated video camera specifically installed to monitor access to the system based game must record all accesses to the secure area and the resulting video log must be retained for a period of at least 7 days."
And we're going to check on what those two people are doing.
"System based games must provide a log entry on the server or system portion of the device
and on a computer or other logging device residing outside of the secure area that houses the
server or system portion of the device anytime the server or system portion of the game causes a
change in the software to include control programs, data, graphics or sound information in the
connected conventional gaming device or client. The record must contain the date and time of the
action, identification of the component affected, the reason for the modification, and any pertinent
authentication information, and must be maintained for a minimum of 90 days."
Zero-trust network isolation for the operational side is probably the only real solution, but it's expensive since using the network side to update the industrial control systems on the operational side is no longer allowed. Here's a writeup on the Colonial Pipelines ransoware attack for comparison:
Then put the networked stuff on another bus.
Then add a bridge that connects the two buses where you could just pull a fuse for a total disconnect. The bridge would have to have a very simple protocol to make it difficult for a worm to cross.
That’s how I’d do it if I had to design a ship that also had to be networked.