Question?
How the hell do you propose to slip "one small malicious device" into a spacecraft and hook it into the wiring harness?
A vulnerability in network technology widely used in space and aircraft could, if successfully exploited, have disastrous effects on those critical systems, according to academics. That includes putting crewed NASA missions in peril – if someone were able to get into a position to pull off such an attack, natch. Abusing this …
I think it would be entirely possible to get employed by a major contractor on Orion and introduce something into the capsule. Just look at all the problems they've had trying to launch SLS / Orion, there's a good chance NASA would ignore any funny messages coming from networking kit just to launch the thing. If you can get a dodgy USB key into Iran's nuclear facilities it shouldn't be that hard to compromise Orion.
Anon because I am employed by a major SLS / Orion contractor. (although not on NASA contracts)
By compromising the laptop one of the astronauts is using (or the astronaut themself of course), or one of the various things running one of the many experiments that will be carried out during missions. The whole point is that you don't need to hook anything into the harness, the flaw allows any device plugged into the network to disrupt critical systems. You usually avoid that by having entirely separate physical networks so that it's not possible even in principle, but the idea of TTE is supposed to be that you can achieve the same separation while saving the weight and complexity of separate wiring. This exploit shows that's not necessarily the case.
And bear in mind, we're long past the days of astronauts being thoroughly screened military personnel, even if you assume such people could not be compromised. We've already sent multiple random tourists into space, including spending time on the ISS, along with a wide variety of scientists, teachers and others, and that trend is only going to continue. How do you slip a malicious device onto a spaceship? Drop a USB stick in the spaceport car park, and it won't be long before someone decides to pick it up and plug it in halfway to orbit.
I used to look after the OSS network on a major telco. The attempts to defeat security from within to streamline a project or business need was a constant battle.
Once a management network is compromised then you have the crown jewels of access to company devices.
Point being, it's extremally possible to to have a compromise and most of the time it's initiated from internal foolishness.
The article is somewhat sensationalistic but the basic concept is valid and a concern for all companies ... especially Rogers Canada ;-)
The Rogers incident had nothing to do with the scenario I mentioned but I could not resist a Dig at them.
How do you protect the second, dedicated network from perps with access to the hardware?
Probably better to scrap what was a daft idea in the first place and replace it with something designed from the ground up for such critical controls, and allow the non-critical systems to piggy-back on a subset of that new system.
It can all too easily be the case, fg_swe, with it being incredibly lucrative and ludicrously exciting to boot and root, that security and secret intelligence services aid and abet sabotage and insurrection rather more simply than their agency services being able to prevent and protect systems from them, for such a latter expectation may very well be both a physical and virtual impossibility.
Every single worker should be vetted by security agenciies.
Saboteurs can do plenty of bad things.
Spoken like someone who has no clue about the aviation industry...or any large scale operation.
Justvan example, who vets the staff in China, or Saudi, or Argentina, or Ireland, or Isreal.
Please explain who vets who.
I wonder if this flaw can be patched or corrected. It seems inherent in the protocol itself.
I personally believe that critical data should travel on a separate bus, making it physically infeasible to interfere with it. But that's just my take on it. TTE does seem reasonable when you read the specs, but this vulnerability has shown that this doesn't mean much.
Well spacecraft (especially transports and space stations - rather than major missions) often carry all sorts of experiments and devices, and most of the software in those is probably written by PhD students who only care about getting the results so probably isn't very secure or bug-free. So a separate bus for non-core systems seems like a reasonable idea.
And are you absolutely certain that every aircraft you fly on has complete, and effective, isolation between the usb ports in passenger-accessible areas (including galleys, etc) and critical networks?
The way I see it that you can not permit any random device onto the TTE network. I don't think this is quite applicable for space and aircraft applications. I imagine for industrial control applications where the control and generic LAN can be combined (marketing: "It's a feature!") is more of a plausible scenario. There will probably be some policy that prohibits unauthorised equipment from being connected, but given the way this attack functions I don't think it will stop the attack.
Aircraft and trains could potentially provide LAN ports for travellers and this would then be a cause for concern. Though I think WiFi will be more popular since all the ethernet ports are likely to be stuffed with used chewing gum. Space probably is likely better controlled and unlikely to have such a device installed since anyone with the required access likely has better attack opportunities.
Though I don't like the fact that one link can affect all three link. Seems that should be fixable with an update.
I hate to say that "they don't know what they're talking about" but this might be a time when this might be the the case. First of all, The only thing I'd need to smuggle onto a craft to disrupt it would be a pair of wirecutters. Second, CAN buses might be relatively slow but they do include an option for timed messages, both synchronization and regularly timed messages. Third, clock synchronization doesn't rely on network timing, you can miss messages and still keep timing relatively accurate (see "PTP"). Fourth, isosynchronous buses used in machine control have a lot of safety features built into them. This can be something like duplicate data paths (useful where you have to keep going even if a link is damaged), detection of missing or out of sync messages with appropriate safety action, overall control of messaging -- its all about what the design criteria were. As for putting 'other stuff' on such a network, typically you wouldn't just park a PC or you favorite security camera on an isosynchronous network because while it might use Ethernet cabling -- everything will look Ethernet -- the rules for network access will be very different, generally a station will have to ask some kind of controller for permission to access that network. (Also, since these MACs don't play by CSMA rules its quite likely that RougeNet might not get a look in if it tries to just transmit on a well utilized net!).
(The exception to the 'controlled access' rule is Ethernet/IP. This might be vulnerable to a DoS attack, flooding the network with junk packets to deny other units access, but its not a true isosynchonous network, it relies on clock synchronization and advance notification to cause events to happen at particular times. Like everywhere else you'd rely on the system designers to have worked through all the "what if" scenarios, generally you'd not want to be vulnerable to a single point of failure.)
So, in summary, TTE isn't about hardening or making more efficient critical systems. It's about running critical systems on non-critical hardware to save money while introducing new and/or extra potential and actual vulnerabilities.
Yes, someone mentioned weight or mass. But that's not important in all the suggested applications.