Plane not actually commandeered by wi-fi that was not actually hacked
-
We're talking about the long-term future here. Fear, uncertainty, and doubt are the appropriate emotions.
I'm not sure that an existantial crisis should be the basis upon which we measure technical measures.
-
While I stand behind the security principle arguments, I find that part of the reason there is so much confusion is because I mixed up a previous system, ACARS, with the current system of discussion, ARINC-664. They are both avionics systems but have entirely different purposes. The security argument is old and ongoing. If you read this, please keep the qualification in mind.
Good grief, this fallacy again: "Oh noes, one system has been proven insecure! That means everything else must be insecure too!"
Security is only falsifiable. Break it, and we've proven it is not secure. But even if we fail to break it, that doesn't prove it is secure, merely that we have not found a technique by which it can be broken. Admittedly, re your statement above, it is possible that no such technique exists, but it is impossible to prove no such technique exists.
So because security is only falsifiable, because it is impossible to prove security, it is a fallacy to claim any system is secure; logically, such a statement means nothing. You can evaluate a system and rate its security, but not prove it is secure.
Now with respect to the plane avionics all statements from all the different parties and agencies agree and boil down to, "This system is secure." That statement is a fallacy, meaningless. Since security can only be rated, it would be better for them to be able to say something like, "100 hackers attempted to break this system for a month and found no insecurities."
So give the plans to 10 or 20 or 100 hackers and let them have access to the system, try to break it for a month. If the system survives the challenge, at least we can say X very smart people tried hard and didn't find any way to break it: it's probably secure enough. Publish the plans on the web and set up a public test system; let people continue to try to break it. There's nothing to fear, after all, because the system is secure. Right?
Some mechanisms are inherently more secure. We're not talking about encryption protocols, we're talking about hardcoded routing tables, airgaps, and communication lines to the cabin that are one-way down to the electrical level.
In theory, that should make it more secure, yes. It is the shared endpoints that would be the concern. It will be the implementation details that will be the killer: Did some engineer in some company decide to make a router's configuration accessible to an unrestricted port? Did the information sharing component open an avionics system to attack from the passenger side? Is it possible to block avionics communications by having a passenger-side router jabber at an avionics router? And in the future: Will they someday decide to give the pilot access to the avionics via the passenger WiFi, so he could keep track of things from his cell phone app?
-
So give the plans to 10 or 20 or 100 hackers and let them have access to the system, try to break it for a month. If the system survives the challenge, at least we can say X very smart people tried hard and didn't find any way to break it: it's probably secure enough. Publish the plans on the web and set up a public test system; let let people continue to try to break it. There's nothing to fear, after all, because the system is secure. Right?
The plans are already on the web and have been for a long time.
Did some engineer in some company decide to make a router's configuration accessible to an unrestricted port?
HARDcoded routing table. You don't set that config through mere software. You need physical access to the switch.
@CoyneTheDup said:Did the information sharing component open an avionics system to attack from the passenger side?
The passengers are only receivers. As soon as they try to send stuff to the switch, they won't receive anything because the switch will shut down the offending port.Is it possible to block avionics communications by having a passenger-side router jabber at an avionics router?
This would be the same scenario as "device is malfunctioning" and has already been considered. There's no real difference between "device is sending weird shit due to malfunction" and "device is sending weird shit due to a hacker".And in the future: Will they someday decide to give the pilot access to the avionics via the passenger WiFi, so he could keep track of things from his cell phone app?
Highly unlikely - because that would lead the reasons why they're not using a standard TCP/IP network over CAT5 ad absurdum. Again: They already decided against using a bogstandard network scheme for several reasons - and those reasons were not: "It's cheaper this way".
-
I thought that the cockpit chatter was channel 6 on the headphone jacks.
points at @riking
A hacker! Quickly, put him on the no-fly list!More importantly, should it be "at @riking" or just "@riking"? the former seems a bit redundant... hmm..
-
While I stand behind the security principle arguments, I find that part of the reason there is so much confusion is because I mixed up a previous system, ACARS, with the current system of discussion, ARINC-664. They are both avionics systems but have entirely different purposes. The security argument is old and ongoing. If you read this, please keep the qualification in mind.
The plans are already on the web and have been for a long time.
Really? And they include all the software details and the hardware routing details, and a test system?
HARDcoded routing table. You don't set that config through mere software. You need physical access to the switch.
Well, first of all hard-coded just means that they programmed it in a fixed manner. It doesn't discuss whether it's in memory in the router in a reprogrammable memory chip. Not only that, but the system that generates the hardcoding: can it be exploited? Read Reflections on Trusting Trust (PDF) to get a feel for the difficulties in securing trusted systems from "trusted" insiders. (As in, "How do you know the router tables really are what they say?")
They already decided against using a bogstandard network scheme for several reasons - and those reasons were not: "It's cheaper this way".
To a security designer, this would not increase confidence. Using, "Our own better network," sounds disturbingly like the reasons OSGP decided not to use standard encryption keys; to instead use, "Our own better security." Which is why I posted the "Amateurs Produce Amateur Cryptography" article in the first place.
Not saying the network designers are amateurs, but creating a new network just means that the problems with that network, if there are any, are unknown. For all its flaws, TCP/IP is well understood.
-
Yes, and that is why TCP could never be considered for this application.
It's too damn slow for a start.Add a WiFi latency on top and you'll be laughed out of the building, and have to hand in your pass.
-
All that fool probably managed was to hack the in-flight entertainment, and he had to physically break into the entertainment system's hardware to do that.
TL;DR: Noob FBI hacker REALLY doesnt like Pauly Shore movies, willing to risk jailtime to turn them off.
-
I thought that the cockpit chatter was channel 6 on the headphone jacks.
Channel 9 on United. That was the reason Microsoft DevDiv called their "outside the PR machine" website Channel 9. Also, it's not reversible back into the radio system.@Rhywden said:HARDcoded routing table. You don't set that config through mere software. You need physical access to the switch.
Once a plane leaves the factory, yes. But what about, on a theoretical Boeing 2707, the only lines convenient to wingtip thermal sensors to detect heating due to supersonic air compression were used for in-flight entertainment and a Boeing engineer went "eh, there's enough depth to these defenses, let's make this port bidi..." unknowingly removing the final barrier between systems?
-
An airplane network isn't like the Enterprise where you can reroute power or data channels as needed.
Feature request!!
-
To a security designer, this would not increase confidence. Using, "Our own better network," sounds disturbingly like the reasons OSGP decided not to use standard encryption keys; to instead use, "Our own better security." Which is why I posted the "Amateurs Produce Amateur Cryptography" article in the first place.
Well, maybe before spouting forth rubbish you could take the time to inform yourself? The reasons why they're not using TCP/IP are out there.
Hint: One of the reasons has to do with determinism.
As for the rest: You're arguing without even bothering to inform yourself (something a simple Google search would do),so you're making yourself look like a fool. Which, coincidentally, looks a lot like what this "researcher" did.
-
Once a plane leaves the factory, yes. But what about, on a theoretical Boeing 2707, the only lines convenient to wingtip thermal sensors to detect heating due to supersonic air compression were used for in-flight entertainment and a Boeing engineer went "eh, there's enough depth to these defenses, let's make this port bidi..." unknowingly removing the final barrier between systems?
Since you'd need a media converter for that, that would be pretty unlikely, rendering in-flight entertainment inoperable.Plus, which moron would lead the cables for in-flight entertainment through the wingtips? That would never pass certification.
-
Channel 9 on United. That was the reason Microsoft DevDiv called their "outside the PR machine" website Channel 9. Also, it's not reversible back into the radio system.
In all seriousness is there never anything 'secret' in the cockpit/atc communication? I mean, I don't think my assumption was that stupid.
(i very seldom fly)
@TwelveBaud said:, the only lines convenient to wingtip thermal sensors t
Yeah yeah, make fun of me... 🙇
-
@Buddy said:
We're talking about the long-term future here. Fear, uncertainty, and doubt are the appropriate emotions.
I'm not sure that an existantial crisis should be the basis upon which we measure technical measures.
Sure, just ask Amenemhat III.
-
In all seriousness is there never anything 'secret' in the cockpit/atc communication?
When they're talking to ATC? Not secret; just very dull to most people. When they're gossiping during cruise? Quite possibly stuff that you shouldn't be privy to, just like with any other bunch of workers.
-
More importantly, should it be "at @riking" or just "@riking"? the former seems a bit redundant
Personally, I don't read the @ as "at" but as an indicator that a username is coming up, so I would use "at @riking"
-
In all seriousness is there never anything 'secret' in the cockpit/atc communication?
-
Yay, this topic again! Time for another flamewar where people who don't understand ARINC-664 talk about Ethernet hacking methods that don't work on ARINC-664!
-
In all seriousness is there never anything 'secret' in the cockpit/atc communication? I mean, I don't think my assumption was that stupid.
Yay, this topic again! Time for another flamewar where people who don't understand ARINC-664 talk about Ethernet hacking methods that don't work on ARINC-664!
Besides -- hacking the TMC on a Boeing isn't going to get you very far -- the followup on the Boeing autothrottle systems would be a dead giveaway to the pilots that something is happening, especially if you were silly enough to mess with asymmetric power.
-
Yay, this topic again! Time for another flamewar where people who don't understand ARINC-664 talk about Ethernet hacking methods that don't work on ARINC-664!
BUT YOU NEVER KNOW!
In the recent William Gibson novel, at some point, someone figured out how to do computer communication into the past (whereupon that timeline split off, etc, etc, but that's not important here), or something like that...it's not totally explained, but just go with it for now.
The future people of course have much more advanced computing technology, and are able to do predict / hack things that can make people of the "present" extremely rich (e.g., hacking the lottery, stock markets).
The call is coming from...THE FUTURE!
-
@swayde said:
In all seriousness is there never anything 'secret' in the cockpit/atc communication?
When they're talking to ATC? Not secret; just very dull to most people. When they're gossiping during cruise? Quite possibly stuff that you shouldn't be privy to, just like with any other bunch of workers.
Patterson tower, Aero Club 4658W
Aero Club 4658W, Patterson Tower
Patterson tower, Aero Club 4658W over Point Alpha, inbound for landing, with Victor
4658W cleared to land runway 23L
Roger, 4658W cleared to land 23L<yes, oversimplified. I don't care.
-
What's our vector, Victor?
-
We have clearance, Clarence.
-
Booooring 😏
-
So, Dunn, you were under Oveur and over Unger.
-
While I stand behind the security principle arguments, I find that part of the reason there is so much confusion is because I mixed up a previous system, ACARS, with the current system of discussion, ARINC-664. They are both avionics systems but have entirely different purposes. The security argument is old and ongoing. If you read this, please keep the qualification in mind.
Well, maybe before spouting forth rubbish you could take the time to inform yourself? The reasons why they're not using TCP/IP are out there.
Hint: One of the reasons has to do with determinism.
I didn't say they were using TCP/IP or that they should. What I said was that they basically rolled their own network and, while they may have well have needed a new wheel, re-inventing the wheel is a pejorative in the software community for a reason. Your brand-new wheel is likely to be worse than existing industry wheels (the OGSP security comes to mind) and at best is likely to have a few unexpected problems.
Humans aspire to perfection--perfection is never achieved.
As for the rest: You're arguing without even bothering to inform yourself (something a simple Google search would do),so you're making yourself look like a fool. Which, coincidentally, looks a lot like what this "researcher" did.
With respect to this, it looks like we have irreconcilable arguments.
My argument is centered around the nature of overconfidence and hard-learned lessons in security, some of which I have bothered to learn. So far, humanity has never made a system that is completely secure and there's really no reason to expect that this system would be the first. But we have made an infinitude of systems that were claimed to be secure because they were absolute flawless perfection...right up until they were exploited. Simple rule of thumb: Any system made by man can be broken by another man.
OTOH, if I understand the core of your argument, it is: These systems are absolute flawless perfection and therefore absolutely positively cannot have any bugs or security flaws; so there!
That about sum it up?
-
OTOH, if I understand the core of your argument, it is: These systems are absolute flawless perfection and therefore absolutely positively cannot have any bugs or security flaws; so there!
Totally off. My argument (and I think @Rhywden is on the same page as me) is that the original researcher as well as some of those in this thread who do not have experience with avionics technologies seem to think ARINC-664 is Ethernet and start proposing attack methods that require standard Ethernet, when even a quick study over ARINC-664 would show that its differences will prevent the proposed attacks from being possible.
I'm sure there are ways to hack ARINC-664, but it won't be done by some nobody hacker who knows TCP/IP. It would have to be someone with good working knowledge of the ARINC-664 standards as well as intimate knowledge of that particular plane's systems. Someone without knowledge of the particular plane model could use analyzer hardware and software, but that stuff is literally tens of thousands of dollars at minimum, and then there's the added complication of trying to somehow get physical access to the plane's switch to plug in your analyzer.
-
Am I correct in my assumption that the researchers are saying the in-flight WiFi is connected to the system somehow? Which...... I don't think it is.....
-
In-flight WiFi is not connected to the avionics network. There is no good reason to do so. There is not even a bad reason to do so.
-
In-flight WiFi
is notshould not be connected to the avionics network.FTFY. (And that's the point. Dumb shit happens despite people trying to make sure it doesn't.)
-
If you plugged a WiFi device into the avionics network, it wouldn't work. It would be like plugging your dial-up modem into your monitor. Different protocols and standards.
-
There is not even a bad reason to do so.
I want the artificial horizon to play Beverly Hills Cop II.
-
That's pretty much what I figured.
FTFY. (And that's the point. Dumb shit happens despite people trying to make sure it doesn't.)
In the US, I know there are pretty strict aviation regs, especially when you get in to the commercial side. While it's not impossible, it's extremely unlikely the two networks would ever touch (because I doubt that aircraft would pass the pretty tight flightworthiness rules).
-
It would be like plugging your dial-up modem into your monitor. Different protocols and standards.
Considering that the physical layer is likely the same or highly similar -- I'd say it's more like plugging a Bell 202 into a Japanese Lumaphone (think of their version of the Picturephone) and expecting the two to talk.
-
The physical layer is the same, RJ-45 connectors with CAT-5e or CAT-6 cabling. But the next layers are sufficiently different to prevent inter-operation.
Standard Ethernet switches can switch ARINC-664 frames albeit inefficiently due to COTS hardware not understanding source/destination ports or the virtual link value (also some of the systems I've seen don't even have MAC addresses for nodes), and of course without any kind of fault tolerance or determinism. But ARINC-664/AFDX switches can NOT switch standard Ethernet frames because they don't have the extra fields required, and as far as I know broadcasts are not allowed by the switch and would be ignored so simply blasting data into the switch with a broadcast field wouldn't get your frames to go anywhere.
-
And to exploit that, you'd need physical access to the switch. And..... if you're gonna do that, you might as well just unplug things or have some kind of time-delayed physical disconnect or something.
-
Exactly.
And, if you're going to do that, you'd need physical access to both switches. There are two fully-redundant networks. Each node actually has two ports, one to each network. Transmission always goes on both interfaces, and receiving is simply done by whichever one gets there first.
I don't know if the two switches are adjacent or not, probably depends on the plane, but I'd assume they're physically separated to prevent some kind of catastrophic physical failure from disabling any remaining parts of the plane if it takes down a switch.
-
While I stand behind the security principle arguments, I find that part of the reason there is so much confusion is because I mixed up a previous system, ACARS, with the current system of discussion, ARINC-664. They are both avionics systems but have entirely different purposes. The security argument is old and ongoing. If you read this, please keep the qualification in mind.
Totally off. My argument (and I think @Rhywden is on the same page as me) is that the original researcher as well as some of those in this thread who do not have experience with avionics technologies seem to think ARINC-664 is Ethernet and start proposing attack methods that require standard Ethernet, when even a quick study over ARINC-664 would show that its differences will prevent the proposed attacks from being possible.
I'm sure there are ways to hack ARINC-664, but it won't be done by some nobody hacker who knows TCP/IP. It would have to be someone with good working knowledge of the ARINC-664 standards as well as intimate knowledge of that particular plane's systems. Someone without knowledge of the particular plane model could use analyzer hardware and software, but that stuff is literally tens of thousands of dollars at minimum, and then there's the added complication of trying to somehow get physical access to the plane's switch to plug in your analyzer.
This is a much better position, but don't get me wrong: I never was arguing Ethernet or TCP/IP or anything like that: I was arguing "exploit".
That is a generic verb to a security expert: For key locks, it means lock picks. For safes, safe cracking. For debit cards, it means skimmers. In abstract terms, it means that you have a system, over here, that someone wants to protect and an attacker over there who has some type of motivation to overcome the protections and exploit the system.
That's how an article on weak encryption in OGSP becomes relevant to a discussion of a specialized network in an avionics environment. Abstractly spoken: The OGSP people thought they were smart enough to design their own encryption, but they did not consult any security expert in the technology domain they were using, and their incompetence has now been demonstrated by professional attackers who exploited the system for the world to see. (Please note I'm not saying ARIN-664 designers are as dumb as the OGSP designers were, but it's the attitude that sets off alarms.)
Security experts have learned two major hard lessons over the years which drive their thinking about any system that is being protected:
No system--none--is as good as the designers think it is; particularly given time for attackers to work. So far as I know, a system that cannot be exploited has never been found. Exploits are done by a kind of a repeat and try alternate system: In terms of a physical key lock: You try to pick the lock; if that doesn't work, use a hacksaw, if that doesn't work, you try to get a duplicate key; if that doesn't work, you try to con someone with an authorized key into misusing it. In general, the more complex a system, the more opportunity is offered for alternate approaches. In terms of ARIN-664, it only takes one, say, running light manufacturer who violates the standard to potentially allow an attack.
No system can successfully protect itself by anything other than a changeable key/password/etc. This is one of the hardest things for non security professionals to get: a system cannot be protected by keeping design secrets. Security professionals call this security through obscurity and it is the #1 indicator of a securty
. You simply cannot keep such secrets. Someone will steal the plans, or buy the plans from an insider, or infer the plans by reverse engineering--and that's assuming the attacker isn't already an insider. Therefore, a system only has a level of security if it can be so with everyone having the complete manual..all the complete manuals. (Buy a plane and tear it apart to learn the details?)These are like axioms of security. Perhaps they don't apply to some systems, but security researchers have yet to find a system to which they do not apply.
So the way to validate ARIN-664 security is this: You give people access to a public entertainment network set up around a functional ARIN-664 network, and you let a bunch of people try to exploit it to gain access to things they shouldn't. From that, you either defeat them, in which case your security is demonstrated to be good (at the moment) or they are successful and you address the problems they find.
But you really can't do that for a just a day or a week or a month, because nothing stays static: Not the thinking they will use in their attempts to exploit, and not your system. Amazing the number of systems that were secure enough at onset but became unsafe through subsequent modification by "noobs" who didn't understand the reasons why everything had to be thus and so. (If you need an example of that, read up on the well-understood SQL injection attack and then count the articles about violators right here on TWDTF. Even including people who obviously know better.)
That's not what we're seeing with ARIN-664. Instead we basically see a litany, borrowing from something else I wrote:
- It's secure. Go away.
- It doesn't work that way. Go away.
- It is absolutely perfect. Go away.
- (repeat one of the above in response to every inquiry)
That raises alarms with security experts, especially when we get strong hints that, the exact details are secret--and when I say exact details, I mean all details, routing tables, the live software, the exact working network design on a plane, the interfaces between public and private network, the whole thing...everything but the passwords. The design of ARIN-664 is public, but where are the details of a live working plane that security researchers can (try to) exploit?
-
but where are the details of a live working plane that security researchers can (try to) exploit?
To use Raymond Chen's words, this is one of those "wrong side of the airtight hatchway" things. All the knowledge in the world does nothing if you don't have physical access to the network. If you have physical access to the network, all the encryption or validation in the world is meaningless because you can just start yanking cables instead.
ARINC-664 is secure because it's physically secure and isolated. If you have the right tools and physical access, "hacking" ARINC-664 is child's play.
-
It is absolutely perfect. Go away.
I don't recall you getting that response. The others, sure, but not the "perfect" one.
-
If you have the right tools and physical access, "hacking" ARINC-664 is child's play
would seem to indicate otherwise :)I think @mott555's point is that the security "concern" here is irrelevant given the bigger picture. It's like being worried about door locks on a convertible with the roof down...
-
@CoyneTheDup said:
It is absolutely perfect. Go away.
I don't recall you getting that response. The others, sure, but not the "perfect" one.
I was presenting examples from the airline industry that I had seen previously, linked from this article. Of course, I am paraphrasing since no one would have the nerve to say that outright, but see what you think of this response from a spokesman at EASA.
(Of course, I am now embarrassed to discover I mixed up ACARS and the avionics networks. That doesn't change the principles I espoused, but it sure undercuts some of my statements.
I thought this was new day same system, but I was wrong.)Anyway, the EASA response in question (here):
EASA said that it's been in contact with Teso, but likewise emphasized that training software isn't the same as certified flight software. "This presentation was based on a PC training simulator and did not reveal potential vulnerabilities on actual flying systems," said spokesman Jeremie Teahan via email. "There are major differences between PC-based training FMS software and embedded FMS software. In particular, the FMS simulation software does not have the same overwriting protection and redundancies that is included in the certified flight software."
"For more than 30 years now, the development of certifiable embedded software has been following strict guidance and best practices that include in particular robustness that is not present on ground-based simulation software," he said.
To me, that sounds a lot like, "The real system has no flaws--it's absolutely perfect. Go away."
-
To me, that sounds a lot like, "The real system has no flaws--it's absolutely perfect. Go away."
To me it sounds like, "Hacking a flight sim is a far cry from hacking a real flight, come back when you've done something that actually applies to the real world."
-
To me, that sounds a lot like, "The real system has no flaws--it's absolutely perfect. Go away."
It's possible to develop software to that level of perfection, but it's exceptionally rarely done, and it's even rarer that it's done with the assumption that there's an attacker present who is a devious SOB. Or, worse, an attacker who is not physically present but has a delegate device present that carries out the attack on their behalf. There's also the issue that there is always a pressure from management to do things for less cost, whether or not that saving is passed on to customers; that's an environment where a “minor” security lapse that saves a whole bunch of effort (e.g., dynamically autoconfigured routing would cut costs quite a bit and “nobody can exploit things because they would need physical access”) will be encouraged and rewarded.
It's easy to secure a system where everyone and everything is behaving as expected, so much so that it's arguably the case that you don't need security at all if everyone is being that coöperative. Security is about shutting out people who are deliberately doing unexpected things to try to break your system. And not all attackers are outside the organisation; insiders are much more difficult to defend against.
-
@mott555 said:
There is not even a bad reason to do so.
I want the artificial horizon to play Beverly Hills Cop II.
THE QUOTED POST WAS NOT ROBO-LIKED.
-
No system can successfully protect itself by anything other than a changeable key/password/etc.
This is false, but not because "security by obscurity" is any bit a good idea. Sometimes, the behavior the attacker wants (sending data to the avionics network from the IFE network), can be ruled to be completely useless/undesired for normal operation; in that case, the best security approach is to make the system physically incapable of bending to the attacker's will. (Cue my hardwired data diode.)
-
I want the artificial horizon to play Beverly Hills Cop II
And don't forget that the altimeter needs downloadable Grumpy Cat skins.
-
And don't forget that the altimeter needs downloadable Grumpy Cat skins.
And a Nyan Cat air speed indicator?
-
It's easy to secure a system where everyone and everything is behaving as expected, so much so that it's arguably the case that you don't need security at all if everyone is being that coöperative. Security is about shutting out people who are deliberately doing unexpected things to try to break your system.
Here's the thing though: The airplane's network is designed around the axiom that unexpected things can and will happen. Hence the redundancy. Hence the strict forwarding rules. Hence the disabling of ports leading to malfunctioning devices.
The big flaw of the "but it's not secure" argument around here is that they're assuming that the network is wide open and accepting any crap you spew at it. Plus, certain people are still flogging the dead "security by obscurity" horse which is patently false. There's a metric ton of information out there, if they were just willing to use Google...
For instance, this: http://j661.sourceforge.net/who_we_are.html
-
Here's the thing though: The airplane's network is designed around the axiom that unexpected things can and will happen. Hence the redundancy. Hence the strict forwarding rules. Hence the disabling of ports leading to malfunctioning devices.
All of which means that there's an entirely different set of attack vectors instead, such as trying to fool the routing system into thinking that, say, all the airspeed sensors have simultaneously failed.
You can't just get away with asserting that things must be secure because there's redundancy. Security against systematic, targeted, malicious attack is very much not like security against random environmental hazards. What's more, there's a long and shameful history of people asserting that systems must be secure when in fact they were not. For example, people asserting that routing tables are hard-coded when in fact they're only coded in firmware and can actually be changed (but nobody's really checked that).
We wouldn't be nearly so insistent on this if we hadn't learned this the hard way, over and over.
-
I have a friend who works at a nearby airport doing avionics maintenance and he's always griping about how the network hardware is put in the most restrictive and annoying places possible. Stuff like removing multiple panels from the surface of the aircraft, crawling down an 18" port and having to remove a pipe or strut with a socket wrench once you're halfway in to get past it, all while juggling a flashlight and trying not to get your gut wedged somewhere, just to get at one of the switches which needs to be pulled for a regular maintenance check. Claustrophobics need not apply.
Security is achieved by preventing physical access. The "researcher" who claimed to access the avionics network through the in-flight entertainment network is lying because they are separate networks so that's not an attack vector. And nobody's going to pull exterior body panels on a plane in flight to squeeze into a tight little tunnel and attempt to hijack the plane by plugging into the avionics switch and sending it faulty commands, historically speaking storming the cockpit is a much more viable option.
