Reading the posts I feel like a lot of HN doesnt fully understand what we're defending against? These ships are BIG.
First, "manually control" engines and rudder isnt a thing. You're talking about a rudder that could be four stories tall. manual input is physically impossible and you wouldnt want it anyway. screw around with the rudder too much or too quickly and the underway mass of a 500,000 short-ton tanker will rip it out of the ship.
a tanker engine starts at 2.5 stories tall (8-10m). Before ECM and modern SCADA automation these things could take an entire day to start. Everything from fueling to speed and fire suppression are intimately linked through a network on the ship. you can restrict these networks from the rest of the ship but its generally not advised. ship engines communicate with breaker panels, engine controls on the bridge, and telemetry from shipping companies for preventative maintenance.
the solution to this is to have a SOC or rapid response team combined with redundant systems. assume a serious compromise is a failure condition and start the EPO/Mayday.
all it takes is a hacker to add a couple extra zeroes to the idle speed of the engines and youre now a runaway ship, or worse, a runaway engine fire.
I was in the US Navy decades ago, long before these digital systems. That said, there are many ways to control rudders, and for that matter engines, that don't rely on someone hooking up a block and tackle (although that actually was the method of last resort for destroyers, of course much smaller than these cargo ships). Taking "manual control" simply meant not running the steering directly from the bridge, e.g. instead running it from the hydraulic controls in after steering (a compartment directly above the rudders).
Exactly, ultimately there is always a point where the digital control meets up with the mechanical control that does the actual work. If the digital fails then you assess the mechanical control directly.
> First, "manually control" engines and rudder isnt a thing. You're talking about a rudder that could be four stories tall.
Except it is actually a thing. Large ships have a separate emergency steering hydraulic circuit driven by its own generator, and operated by hand, commands given from the bridge by radio or telephone.
Namely that every tanker, chemical tanker or gas carrier of 10,000 gross tonnage and upwards or every other ship of 70,000 gross tonnage and upwards, the main steering gear shall comprise two or more identical power units. Theres no requirement for separate circuits in these large applications. "power units" meaning we just duplicate the engine/partial drivetrain and slave it to the SCADA system as a standby unit. these standby's can be started by using residual air in the compressor system (if available) or by diverting charge air from the compressor system to the standby.
remember: we've been hacked, so compressor valves are likely to be locked shut (or worse, destroyed) until someone can get down to the engine room and force-open the valve manually.
ships will often "flip" between engines for service intervals, so it can be useful for the SOC team during triaging the problem, but the failover likely wouldnt provide much help.
to answer the question "couldnt we steer using air?" and yes you could, but it would be glacially slow. you might only have enough power air to move 5-10 degrees.
I’m in an adjacent industry, with less risk of death or commercial loss, and the compressor backups only output to SCADA. The pressure regulation is all relay based and the on switch is a manual secondary contactor.
I absolutely admit I dont know all the fine points (I'm a diesel engine mechanic by trade) but ive worked on large diesels for tankers. Theyre a mechanical Goliath, and they cost nearly as much as the tanker. The shipyard that contracted us frequently ganged engines together to a single controls system from Siemens/Fischer or part of a larger command system with a small "service mode" override you could patch a laptop into for diagnostics. Newer ships just send that diag data straight to us over satellite or wifi (sending techs is costly)
Also another problem I noticed is the engines are often on the ships controls (network maybe?) As the manufacturer name. Something like MANN1 and MANN2 or MITSU1 is a dead giveaway: thats propulsion.
You probably still have a better perspective than me; at least having worked on these specifically.
I suspect that at least some ships/designs are done right ‘right’.
(1) the engine controllers are internal safety limits and have very controlled input ranges. Cummins engines as an example.
(2) the network has a ‘Battlestar’ mode where you can just cut the wire. People would still need to connect laptops or jumpers locally to control devices in anything beyond a ‘max’ vs ‘idle’ vs ‘off’ mode… but 100%, ready, and off should be enough in an emergency.
> First, "manually control" engines and rudder isnt a thing.
I think you're taking "manually control" a little literally here. Based on the other comments I saw that used this phrase (or roughly similar phrases), it didn't sound like they expected a crew to strap a rope to the rudder and start pulling.
It sounded more like a way to physically disconnect everything "smart" in the event that it became compromised, and have a way to interact manually with the rudder (now air-gapped) via dumb electronics (probably integrated circuits and an analog pid system) would meet their criteria.
That may or may not be possible for various reasons on modern ships, but what's being implied in this comment doesn't seem to be being suggested.
For the sake of an example, if we assume the Baltimore bridge ship was hacked to crash, I think it's doubtful crew could have gotten to and manually actuated the rudder (assuming that was possible) fast enough to prevent the collision.
They got the engine restarted, though, right? If there's a manual override for the rudder hydraulics it stands to reason that would also be located in the engine room, or at least very nearby. So I suspect this incident actually proves they could have responded to a fly-by-wire anomaly, but can't know without reading the report.
My guess is that the rudder hydraulics are not located in the engine room, rather they're in a compartment directly over the rudder (or over both rudders, on a twin screw ship). That's how it was on the destroyer I was on, admittedly a very different kind of ship.
That's what I'm thinking too, and furthermore that the mechanical advantage in that system means that the rudder can only be moved by hand very slowly.
There's probably no way to move it by hand on a ship of sufficient size, only hydraulically, but emergency steering would be a completely separate hydraulic system (separate pump, rams, and mechanical controls) powered by a separate generator or engine. The mode of operation is a person goes down into the steering gear room (as parent mentioned) and responds to instructions telephoned, shouted in person, radioed, or some other way communicated. E.g. "starboard 15°". So your "fly-by-wire" controls can be all kinds of messed up, so long as you can disconnect them and operate the backup system by hand you maintain control.
On a small boat we just have a small cover in the cockpit over the rudder pin where we can insert an emergency tiller and steer "by hand" (realistically need to quickly rig some lines for mechanical assistance but that's okay because the secondaries are right there).
I assume it would be a hydraulic system using hand-power. If it's got electrical/mechanical power and is intended to be an infrequently used emergency system, then you probably have to count on it being poorly maintained and still have a fully manual fallback.
From what I understand, these sort of systems on old 20th century warships ar least are all hand-crank powered.
If they were standing by to do so, then yes, they would be able to take action in a timely fashion. (It is a standard practice on some ships to have such personnel standing by during high-risk situations.)
The question is how much time does it take to realize what the emergency actually is? I'm sure the protocol for "X is broke and doing Y" is probably much different than "X is not broke but is actually being controlled by someone else who may also have control with other systems"
Yeah if they control the systems you use to navigate and assess the status of the ship you might not notice it isn't under your control for quite a while.
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:
What are some of the solutions to an cybersecurity incident in-progress that involves taking over a moving ship? Much of the article talks about how it's important to prepare for this incident and that there's a simulation developed for this scenario, but the recommendations at the end look preventative instead of intended to fix an active incident.
The article's preventative methods include "Install security updates as soon as they come and automatically as much as possible," "Do not assign administrator rights to end users," "Do not allow the use of weak passwords," use multi-factor authentication, don't install non-approved software, conduct risk assessments for computer systems in use, and make plans for cyber incidents in advance.
Lol, preventative measures in this case are dumb as crap in the sense of they should be more
"This is an extremely locked down industrial device that only executes signed code and has every port on the machine epoxied over" as just the starting paragraph.
Unfortunately the exact details of what to do in a cyber incident are really closer to a per system plan. Honestly it's something that should be red teamed/blue teamed in a simulator many times, then dump some harbor pilots and captains in the sim against the red team to see what the common default reactions are.
I'm not concerned about this kind of attack. Very few people live or work sufficiently close to the sea to be a potential target. Nobody can crash a container ship into the Pentagon. The damage a ship colision could do is probably mostly economic (a refinery, some docks, a bridge) and environmental (storage tanks near docks, a nuclear power station).
It makes sense to do training for the shipping companies. Cyberattacks on shipping companies happend before, just not on ships. These attacks were ransomware. They don't intend to destroy their hacked assets, because no ransom would be paid, and they don't hack one system/target, they hack all of them at the same time.
Good article, because it's a canary in the coal-mine that warns us against drive-by-wire in personal automobiles. Personally I will never own or use a car that is drive-by-wire, especially if it's connected to the internet. I believe strongly there will be (soon?) be an incident where an org or individual will hack a fleet of such cars, cause widespread death, and the public will pull their hair and say "how could this have happened?!"
To what end? If the hack happens, I think it's much more likely that we see a string of assassinations that look like accidents, or kidnappings that don't look like vehicle-related skulduggery at all. It's just not as valuable if you pull the trigger all at once.
Turn all stoplights green (not red!) at the same time. This was actually the idea of a scifi story back in the 1960s--it came out first as a short story (probably in Analog), then as a book. (FWIW, I found the short story better.)
Like many of the ideas in the book 1984, turning all the stoplights green at the same time in New York City was probably not possible in the 1960s. It is now.
The Italian Job has this as a plot point back in 1969. IIRC, it was even more sophisticated than just turning all the lights green.
Retrieving the gold is left as an exercise to the reader.
IMHO: if you want an entertaining movie, watch the 2003 movie. If you're planning a bank heist, the 1969 version is probably more informative. N.B.: I've never done a bank job.
I don't think it is. When you install a signal controller there's this diode board, one diode for each phase. You use a wirecutter and remove diodes in order to tell the controller which phases ought to be allowed at the same time. What you're describing would only be possible if all signals were installed with all diodes removed.
I can't speak for the whole industry, but back when I was part of it, thats how our controllers worked. Admittedly, I don't think New York City was a customer.
A few decades back, Texas law specified that traffic lights must be wired in relays to not allow 2 perpendicular directions to be green at once. I hope this has not changed.
“Because some people just want to see the world burn”, unfortunately.
The idea that someone would actually fly two commercial airliners into downtown manhattan to take out the World Trade Center was also pretty unlikely, circa 2000 and 2001.
The thing about airliners is that they run out of fuel or get shot down. It's not like you can hijack a few and use them repeatedly for decades. They only way they're decent weapons is if you use them immediately.
The US and China go to war, over Taiwan say. This would be part of a general attack on the US, and would include things like the power grid, internet infrastructure, and anything else that can be disabled or turned against us.
Terrorists decide that 9/11 wasn't good enough, and they can do 1000x more damage, death and terror from the comfort of their computers.
Extortionists decide to leverage this capability to extort money from car companies.
More targeted killings would be motivated according to your thought.
This is just the top of my head. I'm sure there are others.
It just seems like the degree of premeditation involved here would also come to the conclusion, given how over invested we are in our military, that is better to make it seem like the US is perpetually shooting itself in the foot rather than make it seems like the US has been shot. We tend to get all rambunctious when we know it was an attack, better to have us lose the war before we know we're fighting it.
When it comes to remote vehicle access I think you could do more damage carefully over the course of a decade than you could do rashly in a day.
I think Taiwan is the most logical short-term thread model that could lead to widespread cyber incidents internally.
Other continues be something like NotPetya, localized cyberwar tactic that hits public internet and runs amuck. But to get from that to critical infra in US, let alone personal autos, is hard to picture.
> It's just not as valuable if you pull the trigger all at once.
Not if they short-sell the car-manufacturer stock first! Granted, that might increase their odds of being caught, but attackers don't have to be wise to be dangerous.
Depending on what can be hacked, another possibility would be a string of suspiciously-smooth thefts.
I don't want to want to discount the possibility that this would be the ambitious endeavor of an actor with otherwise small-time-crook vibes, but I think it's more likely to be a nation state with bigger plans than getting rich.
Do you drive an old car? Drive-by-wire throttles and controller area networks became commonplace in cars a solid 20 years ago. The benefits of these components within a car is completely orthogonal to any sort of external network connectivity.
I swapped an EJ22 out of a 2001 Subaru Impreza into an '86 BRAT. At least as of 2001, there were still a lot of discrete pairs of wires that a sufficiently savvy person (I.e., not me) could debug with a multimeter. Thank goodness. It was enough fun getting it running without involving CANBUS in the process.
I believe our 2005 Civic was largely discrete pairs of analog wires too, even if it was throttle by wire. It gave me very little electrical trouble.
Troubleshooting the headlights on my 2010 Suzuki SX-4 involved printing some 30 pages from TFM. The entirety of the wiring diagram for my '76 Triumph TR6 fit on three pages. We own a Willys CJ-2A, and the whole wiring diagram fits on one sheet. The wiring diagram for the circuits that actually make it run probably fits on an index card.
When you turn off the headlights in my wife's 2018 Impreza, there's a noticeable delay between turning the switch and the computer deigning to allow you to turn the lights off.
Analog systems can be difficult to troubleshoot too, depending on the issue. I've spent some time scratching my head on some old turn signal systems on old motorcycles before, and their diagrams looked simple... at first. Digital electronics can be a pleasure to work with if you have the right tools, the right information, and the system wasn't designed poorly. The Suzuki and the Impreza aren't just more complicated for no reason -- they're also most sophisticated vehicles that do more things.
Are there recent model vehicles without computer controlled throttles?
I know ABS implies computer modulated braking, but I don't think it implies the computer can brake without user input or override user input and not brake. Otoh, automatic emergency braking is standard on some vehicles and optional on many.
Computer controlled steering is currently rare, but is part of lane keeping assistance.
ESC (basically same actuator hardware as ABS) can definitely brake without user input and it's mandatory in all cars sold after 2012. Steering assist is mostly torque limited by design, you should be able to easily overpower it.
>Steering assist is mostly torque limited by design, you should be able to easily overpower it.
Glad you said "mostly". The Cybertruck is an exception, with full drive-by-wire. There may be others. If the 'truck is a hit (and it is) expect its ideas to spread.
Yeah, my info was based on George Hotz interviews on Openpilot. He said they are safe because even if the software wants to steer the car off the road, the lane keep assist actuator won’t be able to steer that hard and will disengage. Haven’t personally tested that myself :)
I’m saying the physical actuators that turn the steering wheel when LKA is on are torque limited on purpose, so they won’t be able to make a sharp turn or overpower a human, even if they won’t disengage when a human tries to override it (e.g. due to a bug or sensor failure).
Well the authorities will probably do something sensible like ban keyboards or something. They already banned the flipper zero in Canada because it can be used to unlock insecure cars.
So I agree, but my question next is what cars are you finding that meet this standard? Networks show up in cars quite early, not sure how far back I’d have to go to buy one that is suitably off grid.
I own a 1999 Mercedes-Benz E300 turbodiesel and a 1995 Toyota Land Cruiser. Both of these vehicles are modern, computerized machines with electronic engine management, airbags, and computer controlled transmissions. Neither of them have any need for "software updates" nor do they have any way to do so. They both have OBD-II interfaces, and the Benz has a proprietary interface as well. I'll be sticking with these vehicles for as long as it takes for the current complexity fetish to subside. If that means never buying another vehicle that's fine by me :)
My plan for the Land Cruiser is to install the engine and transmission from an early 2000s Mitsubishi Fuso. This will entail grafting the ECU and TCU from the Fuso into the Cruiser's wiring harness, and doing some transmission modifications to hook up the tailshaft to the Toyota transfer case. Should just about double fuel economy and improve driveability. I can't think of any reason I'd buy a newer vehicle, the "improvements" they offer just aren't worth the cost.
> Neither of them have any need for "software updates" nor do they have any way to do so.
Pretty sure they could get firmware updates for the ECU and TCU. There's probably somebody doing ECU tunes for more power / better efficiency / better noises, even if that's just tweaking the tables ajd even if there are no factory software updates. Electronicly controlled transmissions often have some updates available over their early service life, even if they're not well publicized or pushed. ODB-II is commonly used for that, although maybe the 1995 would need modules removed and rom chips replaced.
Yes, and there are aftermarket standalone transmission and engine controllers available. Another thing people do is stick another node in the CAN network which intercepts packets and rewrites them. But what I meant is that the cars, when they were shipped, were done. Like, they struck the right balance between features and complexity s.t. the product that was shipped was complete. That's the kind of equipment I like to depend on, not something that's a constant experiment.
Are they fully reflashable or can be just parameter adjusted? I have a random power steering ECU, it came with a mask ROM variant of a Fujitsu MPU. Having a microcontroller != having a field malware programmable micro.
> nor do they have any way to do so. They both have OBD-II interfaces,
You sure about that, at least if someone has direct access to your car I'm guessing they could very easily clip something on that could control the car under particular conditions.
Sure they could plug a device which sniffs or rewrites CAN frames right into the OBD-II port or the 38 pin port on the Benz. I have done so myself even. I'm not worried about it one bit. Someone would have to specifically want to target me, and if they have access to my car they also have (much easier) access to my house. I am not worried about that either.
Look, if you want to really mess up a car all you need is a pair of needle nose pliers. Locate the brake lines where the hard line meets the soft line going to each caliper, and squash each hard line to crack it just enough that fluid starts to slightly weep out. When the driver first steps on the brakes in earnest the fluid will flow out, and eventually (maybe 5-10 braking events later) the brakes will no longer work.
Again, my threat model does not include someone targeting me specifically. If someone wants to hurt me or vandalize my property they're not gonna do it by writing some esoteric computer program. If you connect your car to the Internet the threat model needs to expand to include "bulk" attacks, which I suspect are actually much more likely.
Got it, so you accept the risk of local access and poorly segmented canbus and maybe access via complex RF style-hacks more or less, but remove the software, wifi, cell and presumably Bluetooth threat models. That makes sense to me.
I also have a simple downgrade path to a fully mechanical vehicle. On the Benz replace the injector pump with a mechanical one and the transmission with an older hydraulically controlled automatic or manual. Similar options available on the Toyota.
But really the "threat model" is about complexity, not malice. I'm not worried someone will try to hack my car. If they manage it, good on them. I am worried about a manufacturer preventing me from maintaining my cars. Newer cars are so tightly locked down that maintenance is unnecessarily difficult.
On grid cars don't tend to stay that way. My 2013 Ford was built with a 2g modem, a recall replaced that with a 3g modem, and now the 3g modem has no one to talk to. My 2017 Chrysler also has a 3g modem with no one to talk to.
A malicious person could standup a fake 3g network, I guess. But LTE has strong mutual auth, so cars with 4g modems will be very hard to attack once 4g is dead. OTOH, 4g and 5g can more easily coexist: as I understand it, 5g can run with 4g compatible control protocol, with some slots 4g and some 5g depending on the needs of the mobile stations nearby, 2g and 3g needed a block allocated, so once the minimum size block was no longer well utilized, it's a waste of spectrum. This may mean 4g is kept alive a lot longer than 2g/3g.
I have some friends that work in a variety of positions on older boats in the maritime industry, and are quite skeptical about upgrades to drive by wire systems.
They also generally aren't technically advanced, so I'm wondering what the extent of training they'd consume outside of highly technical roles - if it is really value adding, or your typical corporate security training "don't click phishing links".
Of course, there's a _very_ big difference between a drive-by-wire system that has a set of dedicated electric wires with some simple communication scheme, and a networked, potentially hackable, system based on UDP packets.
I think that there is a growing need for more training and education in cybersecurity due to the increasing reliance on digital technologies and the ever-evolving cyber threat landscape... It is a vital part of our life
I'd heard the solution involves getting Jonny Lee Miller and Angelina Jolie to help you hack the Gibson, but it's been a while and maybe that's out of date.
Virus was an awful movie, not redeemed by the honorable efforts of those among its actors who understood there was nothing about it that needed taking seriously.
No, but it is worth considering what might be possible for a malicious actor in the near future, considering how disastrous this single collision is (which could have been significantly worse in lives lost had it been in the middle of the day).
As it turns out had this happened in the middle of the day we might have been able to avoid all of the casualties. The harbor pilot managed to call shore early enough to have the bridge closed before the ship hit, so the only casualties were an extremely unlucky pothole crew who didn't get the warning in time.
The bridge closure was so fast because there were already police on the bridge for traffic control around the repair crew.
Had it happened during the day, police may not have made it to the entrances in time. Or, if during rush hour, there may not have been time for the bridge to clear even if the entrances were closed.
First, "manually control" engines and rudder isnt a thing. You're talking about a rudder that could be four stories tall. manual input is physically impossible and you wouldnt want it anyway. screw around with the rudder too much or too quickly and the underway mass of a 500,000 short-ton tanker will rip it out of the ship.
a tanker engine starts at 2.5 stories tall (8-10m). Before ECM and modern SCADA automation these things could take an entire day to start. Everything from fueling to speed and fire suppression are intimately linked through a network on the ship. you can restrict these networks from the rest of the ship but its generally not advised. ship engines communicate with breaker panels, engine controls on the bridge, and telemetry from shipping companies for preventative maintenance.
the solution to this is to have a SOC or rapid response team combined with redundant systems. assume a serious compromise is a failure condition and start the EPO/Mayday.
all it takes is a hacker to add a couple extra zeroes to the idle speed of the engines and youre now a runaway ship, or worse, a runaway engine fire.