If you have a command called SET_MODE and it only has the options 1, 2, or 3, it would be ridiculous for the system to accept mode 4 since it doesn't exist. The system should refuse the command. If the SET_MODE command actually just sets a bunch of toggles for you in the background, it would be a good idea to retain control of those toggles so you can customize the configuration and effectively make your own "mode 4" for any emergencies.
I think it was this one [1]. The story is older than I remember (2015) but at the time I was working on aircraft system design and knew people well-versed in ARINC 664 and everything related to aircraft data network segregation between domains.
And a lot of the noise was coming from Boeing requesting Special Conditions [2] for the certification of recent airliners where segregation is less absolute than when systems had a floppy reader to install updates.
> Hacker Chris Roberts claimed he was able to break into the in-flight entertainment system up to 20 times on separate flights and that on one flight he was able to make the plane “climb” and “move sideways” by accessing flight control systems from a laptop in his seat.
[1] https://www.theguardian.com/technology/2015/may/19/hacker-ch...
[2] https://www.federalregister.gov/documents/2007/12/28/E7-2507...
Don't get me wrong, I have the utmost respect for what academic CubeSat teams can pull off with miniscule budgets and resources, but this doesn't reflect what actually happens outside the university context. Modern commercial spacecraft are well-secured, particularly on telecommand. For a look at what the professionals actually do, I suggest people take a look at the CCSDS 350.x series Green Book publications: https://public.ccsds.org/publications/GreenBooks.aspx
Disclosure: I work on satellite design and in the recent years on a program that is part of the NewSpace. I have an intimate knowledge of how what I help design works but a limited knowledge of what others may be doing.
A couple of insights:
* I started working on satellites in a large industrial group where, while not being handled by world class cybersecurity experts, secure communications with the satellites rely on a sane use of proven encryption protocols
* I am not sure when this level of security became standard and what was done to secure the satellites before hardware-level encryption with modern algorithms became available
* I was astounded when I discovered the level of casualness for everything related to security on scientific satellite projects, with even recent projects led by major agencies considering that always encrypting command and monitoring is overkill
And my main grip is that the study relies on asking universities that have the lowest bar in terms of caring about security (they already struggle enough to build a working thing) and then extrapolating from a specious argument that it must be worse on commercial spacecrafts.
> One surprising result was that the larger the satellite, the more vulnerable it was. Larger machinery typically used more commercial off-the-shelf components and was thus more vulnerable since the code base was public, whereas smaller CubeSats tended to use custom code.
Also
> a satellite should be designed so that TCs do not compromise the satellite’s stability without further validation
Says who ? What validation ? If an operator had the right to have a telecommand sent to the satellite, who or what aboard the satellite should decide if this telecommand was legitimate.
From experience, there is a myriad of things that you think are usually not a good idea to make your satellite do and then, when you need it as a workaround or mitigation for an unexpected condition, you are happy you have not implemented a list of authorized actions that is too constrained.
PS: It reminds me of the guy that was able to capture the GPS coordinates of an airplane broadcasted to the In-Flight Entertainment systems and got a lot of press coverage by extrapolating that it meant he could also take control of the aircraft from his seat in the cabin.