[00:06.880 --> 00:14.440] Hello and welcome to my talk here at the Aerospace Village at DEF CON SIGMODE. [00:14.520 --> 00:20.300] MITM, the mystery in the middle. My name is Matthew Gaffney and I'll be taking you through [00:20.680 --> 00:30.120] an introductory level talk about the Aircraft Information Systems Domain, also known as the AISD. [00:31.240 --> 00:38.380] We'll be covering through these topics throughout the 50 minutes or so talk today, [00:39.060 --> 00:42.860] covering most of it on EFBs, if I'm honest. [00:43.720 --> 00:46.780] So, why the mystery? [00:47.480 --> 00:54.740] So, the reason I call it the mystery in the middle was due to the lack of public information [00:54.740 --> 01:01.500] I could find about the AISD when I started my journey into aviation cybersecurity [01:02.360 --> 01:08.240] several years ago. I could find lots out about hacking avionics systems, [01:08.240 --> 01:13.700] IFE and all about their weaknesses, but very little about the AISD. [01:14.300 --> 01:19.620] So, that's the reason, the main reason for the talk today is to try and improve knowledge and [01:19.620 --> 01:25.640] awareness of this part of the aircraft and generate the healthy discussion about security [01:26.060 --> 01:34.880] within. So, logically, the AISD sits in between the Aircraft Control Domain and the Passenger [01:34.880 --> 01:40.460] Information and Entertainment Systems Domain, both known as the ACD and the PIESD. [01:41.280 --> 01:47.400] And essentially, what makes an aircraft, what's known as E-enabled. [01:47.480 --> 01:54.100] And E-enabled means that it will integrate, the aircraft will integrate with the airline [01:54.100 --> 02:01.340] IT systems to provide significant cost savings to the business. What it does is it allows remote [02:01.340 --> 02:07.580] maintenance and uploading of software updates, which is a key time saver, especially when you [02:07.580 --> 02:14.540] consider that previously, if you wanted to update the firmware on a module, you'd have to remove it, [02:14.540 --> 02:17.760] send it away, in the meantime, put in a replacement, [02:18.540 --> 02:22.400] then get the old unit back with the new firmware and swap it over. [02:24.280 --> 02:32.440] So, being able to upload new software remotely without having to remove modules or LRUs, [02:33.560 --> 02:37.080] is a considerable cost and time saving for an airline. [02:38.320 --> 02:46.840] It also allows the airline to download logs, both operational logs and security. [02:47.440 --> 02:53.960] So, for airlines, the AISD is the most important part to get right for the business. At least, [02:53.960 --> 03:00.680] that's my view of it. An airline cannot have much influence on how the ACD is constructed. [03:00.680 --> 03:07.100] Maybe a small amount of customization, but not very much at all. It's heavily regulated, [03:07.100 --> 03:14.140] it's heavily dependent on certifications, which are long, expensive and time consuming. [03:14.520 --> 03:20.060] So, the AISD is where the airline, the operator, really has to get it right. [03:21.740 --> 03:27.680] But there's lots of challenges in doing that. There's, across all aviation, not just [03:27.680 --> 03:32.500] enabled aircraft, there's a lot of older technology that gets reused. [03:32.820 --> 03:39.400] And it's not really a surprise, because if it works and it meets the requirements, why change [03:39.400 --> 03:47.120] it? Certifying new modules is expensive and time consuming as well. So, the older modules [03:47.760 --> 03:53.140] that are still fit for purpose will be reused a lot, because it's cheaper to modify them [03:53.140 --> 04:01.420] or to use the old ones. What this also means, though, is that when threats change over time, [04:01.420 --> 04:07.040] these older modules can be attacked in new ways nobody thought about when they were conceived. [04:07.260 --> 04:15.760] We're seeing this with avionics hardware today, but we are not really thinking about this when [04:15.760 --> 04:23.120] it comes to the AISD, and maybe we should. When I say we have new risks to manage, what I mean is, [04:23.140 --> 04:31.140] engineering now needs to consider cyber and infosec risks. Infosec teams now need to [04:31.140 --> 04:36.020] understand and consider engineering. Traditionally, these are two areas of the business that have [04:36.020 --> 04:42.280] been completely isolated. And it has allowed engineering to operate in its own little bubble, [04:43.320 --> 04:52.440] which has led to engineering not following infosec policy 100%. And you see examples of bad [04:52.440 --> 04:57.640] practice, such as post-it notes with passwords, or even passwords being written into procedure [04:57.640 --> 05:02.820] documentation, because it's easier to operate that way when you're an engineer than it is to [05:02.820 --> 05:10.660] use a password manager or to remember the password off by heart. At the same time, IT and infosec [05:10.660 --> 05:15.440] are implementing systems for engineers to use without fully understanding the constraints of [05:15.440 --> 05:21.780] engineering. They don't always have really good 3G connection on board an aircraft. They don't [05:21.780 --> 05:31.340] always have time to be able to learn new systems in depth. What they do have is very [05:32.240 --> 05:39.840] pressured time constraints in order to get aircraft back on the line, because all the time spent [05:39.840 --> 05:49.620] being fixed is money. But when IT comes along and comes along and implements a new IT system, [05:49.620 --> 05:55.020] say for example they don't have single sign-on, all of a sudden that engineer, instead of 20 [05:55.020 --> 05:59.340] passwords to remember, they now have 21. And then we ask the question, why are they writing down [05:59.340 --> 06:06.580] passwords? So understanding the constraints and the difficulty of engineering can go a long way [06:06.580 --> 06:14.050] to improving the security posture of an airline. And operators really need to get these departments [06:14.050 --> 06:21.070] working together in harmony. When dealing with engineering and e-operations, you cannot bring [06:21.070 --> 06:25.790] the corporate information or cyber security mentality and templates to the party. They just [06:25.790 --> 06:31.370] won't work. You're dealing with an area of the business which historically has not been great [06:31.370 --> 06:38.190] with cyber. So you have to go slow. One thing that's on your side though, as an InfoSec person, [06:38.190 --> 06:43.930] is that aircraft engineers love processes and procedures. Oh boy, do they love it. [06:44.750 --> 06:49.010] Before you can even touch an aircraft on the ground, you must have a job card which outlines [06:49.010 --> 06:57.830] the steps engineers must take for each task. So if you can bring influence to these procedures [06:57.830 --> 07:06.510] to improve security, that's half the battle won. And then finally, I should probably explain that [07:06.510 --> 07:11.790] last comment on the slide. This is my humble opinion and I know many would disagree, [07:12.270 --> 07:17.990] but I feel that when looking at aviation security, hackers should not focus entirely on avionics. [07:19.010 --> 07:25.450] Although the ACV and the avionics have a number of well-documented and technical weaknesses, [07:25.450 --> 07:33.310] it does have a very effective physical security model. You can only access the avionics bay from [07:33.310 --> 07:38.390] outside the aircraft. So when the aircraft is in flight, not even the pilots can get to it. [07:38.450 --> 07:44.610] So only the engineers on the ground can do that. And if you're going to try to get access airside [07:44.610 --> 07:50.330] for legitimate reasons, you know how difficult it would be to get airside for illegitimate reasons. [07:54.490 --> 08:01.870] Also, there's usually only one network interface between the ACV and the AISD, and I'm talking [08:01.870 --> 08:08.230] about aircraft that are fully compliant with ARINC 821 here. But this separation is normally [08:08.230 --> 08:15.150] implemented with protections such as a firewall or even a data diode. And sometimes we also [08:15.150 --> 08:23.090] base that network communication on proprietary protocols, not on TCPIP. So if you can get into [08:23.090 --> 08:27.610] the ACV, yes, you can inflict a lot of damage, but gaining that access either through physical [08:27.610 --> 08:34.710] or technological means would be extremely difficult. And if you can go to that level, [08:35.230 --> 08:41.030] if you can get physical access to an aircraft, why go hacking? You know, you can do something [08:41.030 --> 08:48.850] much more nefarious with a much greater guarantee of success if that's what you wanted to do. [08:49.830 --> 08:55.490] So for me, instead, the aircraft information systems domain has multiple touch points ranging [08:55.990 --> 09:03.810] from the airline network, Wi-Fi, even the internet and the cabin. And these attack scenarios are much [09:03.810 --> 09:08.970] more traditional and realistic for hacking. Okay, it's not sexy. You can't control the [09:11.290 --> 09:16.300] aircraft control services from the AISD. You can have other effects on the aircraft, [09:17.130 --> 09:22.250] effects which may impact operations. And if you know what you were doing, [09:22.250 --> 09:29.920] you could modify some of the data presented to pilots. So [09:33.000 --> 09:38.960] manufacturer challenges. So I explained the challenge about technical debt. And the reason [09:38.960 --> 09:50.700] for that is that airworthiness timescales are huge. And they encourage, or they almost force [09:52.100 --> 09:56.940] manufacturers to really think about what they're going to reuse and what they have to rebuild from [09:56.940 --> 10:02.120] scratch. Because those brand new modules are really expensive to get certified. [10:03.560 --> 10:11.000] Challenges from the operator are very different and in many ways are quite significant. [10:12.300 --> 10:19.020] The key one is they have zero visibility of the manufacturer's risk assessment. So when [10:19.020 --> 10:25.820] the manufacturer is designing and building an aircraft, they perform extensive and detailed [10:26.350 --> 10:29.610] risk assessments to mitigate system vulnerabilities. [10:32.180 --> 10:38.420] They will mitigate many of these issues themselves, but they will also transfer some [10:38.420 --> 10:46.020] to the operators. And this is communicated in a number of ways, such as security handbooks or [10:46.020 --> 10:52.720] ANSOGs, depending on which manufacturer you're dealing with. But no operator will get to see [10:52.720 --> 11:00.680] details of the original vulnerability or the risk assessment. So despite the quality of this [11:00.680 --> 11:06.500] manufacturer guidance, these recommendations which come down, there's no real mechanism [11:06.500 --> 11:13.340] for the operator to assess the effectiveness of implemented controls. And this can, [11:13.340 --> 11:18.540] and from what I've seen, probably does lead to gaps in the cybersecurity protections [11:18.540 --> 11:22.240] of e-enabled aircraft at the operator level. [11:24.340 --> 11:31.580] When you think about it, airlines are heavily reliant on legacy IT systems. For example, [11:31.580 --> 11:38.520] many use at the core of their business, a TPF system, which handles all of the real-time [11:38.520 --> 11:44.500] transactions. It's not a traditional operating system. It is based on technology that was [11:44.500 --> 11:54.360] released in 1979. To program it, it's done in hexadecimal. It's just not what we would, [11:54.360 --> 11:59.960] people of my generation, would consider a traditional operating system. But it handles [11:59.960 --> 12:06.740] transaction messages one-to-one at an extremely high volume and extremely high speed. [12:07.320 --> 12:12.180] And what that does is make sure that the same seat isn't booked twice by separate transactions [12:12.180 --> 12:17.940] milliseconds apart. And there's nothing out there on the market that can really [12:17.940 --> 12:27.620] replicate that right now. Also, airlines, over time, have grown and have added new systems [12:27.620 --> 12:34.900] on top of the old systems. And until quite recently, this may have been done without [12:34.900 --> 12:40.100] consideration of all the risks. In fact, some of them would have been done before cybersecurity [12:40.100 --> 12:49.140] was really a thing. So some may not have followed good practice, such as network segregation. [12:51.560 --> 12:56.780] Airlines also operate 24-7. And that means that outages are very costly. [12:58.200 --> 13:05.740] When an airline IT system goes down, aircraft stop. They just cannot take off because they [13:05.740 --> 13:09.360] haven't got the information for the pre-flight. [13:11.060 --> 13:16.020] So any introduction of a new system that could have an impact on operations is [13:19.200 --> 13:24.420] risk managed to the nth degree. And there's a lot of risk avoidance going on when these new [13:24.420 --> 13:30.300] systems are put in place. Either that, or you just throw resources at it to make sure that [13:30.300 --> 13:33.700] if something does go wrong when you introduce a new system, [13:33.700 --> 13:37.160] that the impacts are mitigated as much as possible. [13:38.700 --> 13:44.700] What it does mean is that over time, airlines can become quite flat in their networks. And [13:44.700 --> 13:49.580] what that means is if the perimeter is at a breach, it's very easy for an attacker to then pivot [13:50.540 --> 13:59.880] inside the networks. So where regulators fit in. So speaking from a European perspective, [14:00.760 --> 14:07.740] there's some really positive steps going on right now in the critical national infrastructure [14:07.740 --> 14:15.440] sphere of which aviation forms a part. And maturity in cyber security, aviation cyber [14:15.440 --> 14:21.320] security is growing slowly and gathering momentum. Or at least it was before COVID. [14:21.320 --> 14:28.360] It was the last time I was really involved. From what I've seen, the UK CAA is growing the [14:29.320 --> 14:34.920] cyber oversight function in a very positive way. And rather than just setting out a framework [14:34.920 --> 14:40.980] and directing airlines to comply, they are working closely with operators instead, [14:40.980 --> 14:45.980] guiding them and helping them through their assure process, which is really good to see. [14:45.980 --> 14:54.780] So going back to this gap in the risk assessment, could the regulator help bridge that gap? [14:55.340 --> 14:59.660] The issue is sharing the risk assessments with operators as they are highly sensitive. [15:00.460 --> 15:06.500] Maybe some trusted government bodies could be given more details on the risks and help guide [15:06.500 --> 15:11.540] operators on the effectiveness of their controls without passing on that sensitive detail. [15:12.460 --> 15:18.420] If we can't trust the government, what about the aviation ISAC? Although they are a member [15:18.420 --> 15:24.320] organization, most of the large operators and manufacturers are members. Could this be another [15:24.320 --> 15:31.420] suitable mechanism to do the same thing? Whatever happens, I feel something does need to be done. [15:31.420 --> 15:41.410] Otherwise, pardon the pun, airlines could be flying blind. So here is a rather simplified [15:41.410 --> 15:50.720] overview of a E-enabled aircraft. This diagram is based on compliance to the ARIC-821 protocol. [15:51.670 --> 15:55.500] And as you can see, we've got the three main domains, [15:55.500 --> 16:00.260] the aircraft control domain, the aircraft information systems domain, [16:00.260 --> 16:03.360] and the passenger information and entertainment systems domain. [16:04.720 --> 16:11.940] The AISD, as well as being a main communications hub or hosting a main communications hub, [16:11.940 --> 16:17.820] will host the electronic flight bag if it's a class two. If it's a class two, the EFB will sit [16:17.820 --> 16:24.560] in the avionics. More on that later. Some aircraft have their flight standard panel, or FAP, [16:24.560 --> 16:32.560] connected in the AISD. And there's also occasionally printers, maintenance terminals, [16:33.360 --> 16:39.680] which can be USB or Ethernet port, depending on what kind of device you're using, if you're using [16:39.680 --> 16:47.800] just a straight up USB as a tool, or if you're using a portable data loader. And those maintenance [16:47.800 --> 16:53.680] ports are used as a backup for the IPSET panels that sit between the aircraft and the ground [16:53.680 --> 17:04.520] system. So these IPSET tunnels are really well... the security is excellent. So they are managed [17:05.040 --> 17:10.840] from mostly on board, but the ground systems are involved in the keying of the aircraft. [17:11.560 --> 17:22.560] And there's... I'll talk a bit more about PKI later on. What we do have is the EFBs, [17:22.560 --> 17:29.540] if they are connected to the AISD, they will often route traffic to the internet through [17:29.540 --> 17:39.380] the IPSET panel, through the DMZ and out into the internet, which is usually for software updates, [17:39.380 --> 17:44.620] and it's usually a very restricted set of websites where the EFBs can go. [17:45.480 --> 17:49.600] That is usually done on the ground as well, because if you imagine, if this is happening [17:49.600 --> 17:54.800] during the flight phase, you have the latency of the SATCOM connection down to the ground [17:54.800 --> 18:03.940] systems through the DMZ and out to the internet. So the response time on that in flight would be [18:04.640 --> 18:13.380] pretty long, but on the ground it's manageable. One thing to note as well is sometimes in [18:13.380 --> 18:21.580] enabled aircraft, instead of having a SATCOM in the AISD, there is an option whereby the [18:21.580 --> 18:30.180] manufacturer offers the operator the ability to use the passenger SATCOM connection. Remember, [18:30.180 --> 18:35.280] this SATCOM connection, the passenger name, does not go through this IPSET panel here, [18:35.280 --> 18:39.540] it goes off through the service provider's network. [18:40.840 --> 18:48.240] And one option that some manufacturers are offering to operators is that the [18:50.180 --> 18:57.520] information system domain here can connect to the ground systems, but through the same SATCOM here, [18:57.520 --> 19:04.260] and that is quite advantageous in terms of cost. The more you use SATCOM, the cheaper it is. [19:04.260 --> 19:10.440] So if you have two connections, that's going to cost you quite a bit of money. If you have one, [19:10.440 --> 19:15.480] yes, you're going to be paying for more data, but because prices come down with volume, [19:15.480 --> 19:23.100] you'll actually pay less overall. What I have seen though is quite promising that when this [19:23.100 --> 19:31.000] is implemented, the connection from the AISD into the SATCOM is through a separate VLAN. [19:31.000 --> 19:37.000] So essentially that's a mini network segregation on its own there, and that data is not accessible [19:37.000 --> 19:46.010] from the IFE or the cabin Wi-Fi. So moving on to my favorite subjects, electronic flight bags. [19:46.630 --> 19:52.410] So these have been a revolution for pilots. As the name suggests, they replaced the large and [19:52.410 --> 20:00.670] cumbersome and often heavy bags which were used by pilots to carry paper-based manuals. [20:01.750 --> 20:09.910] These bags would often weigh more than 25 kilos, and as well as being difficult to maneuver, [20:09.910 --> 20:16.690] they also contributed to physical injuries of pilots as well. Moving those bags around the cabin, [20:16.690 --> 20:22.710] around the cabin, around the cockpit, sometimes led to shoulder injuries because of their weight. [20:24.690 --> 20:28.910] Depending on the type of EFB, they can perform a variety of functions, [20:28.910 --> 20:37.710] including a documentation reference library. A type B can perform what's known as performance [20:37.710 --> 20:44.170] calculations. These give V1, VR, V2 speeds, all that kind of stuff. These are important for pilots [20:44.170 --> 20:52.190] to know. Enroute navigation, if you have a GNSS feed into the EFB. And if you have the relevant [20:52.190 --> 20:58.070] connections, access to NOTAMs, weather information, and the ability to do fuel calculations as well. [20:58.990 --> 21:05.310] Some operators also include bespoke applications that sit on the EFB, and these might be used to [21:05.310 --> 21:12.430] complement airline operation systems, so long as they reach the relevant approvals. But they will [21:12.430 --> 21:21.350] also help achieve the overall goal of EFBs, which is not just a reduction of paper inside the cockpit, [21:21.350 --> 21:26.870] but also faster access to information, which helps lower turnaround times and reduce workload [21:26.870 --> 21:34.510] in the cockpit. And non-pilots may not understand the importance of that last part. [21:34.570 --> 21:40.810] Many incidents of pilot error cite cockpit workload as either the main or as a contributing [21:40.810 --> 21:47.970] factor. So this makes EFBs not just an effective tool in reducing costs, but they also help you [21:47.970 --> 21:56.090] fly safely. Hardware categories have different names, depending on which regulator you sit under [21:56.090 --> 22:03.430] and how long you've been in the business. They're often used together, so I've included both here [22:03.430 --> 22:10.650] as some general characteristics. So a Class 1 or portable EFBs, they're often small devices [22:11.510 --> 22:19.790] and double up as corporate devices at the same time. Think of a small EFB, a small iPad with [22:19.790 --> 22:25.170] no connectivity to the aircraft. They're then considered like a paired personal electronic [22:25.170 --> 22:33.370] device and as such they must be stowed to take off, taxi and land. Class 2, these can be [22:33.370 --> 22:42.630] pilots or plane attached EFBs. These connect to the AISD with usually a one-way feed of data from [22:42.630 --> 22:49.450] the avionics. They can be integrated with the cockpit displays and their build is the responsibility [22:49.450 --> 22:56.850] of the operator. Quite often they are small laptops with operating systems such as Windows [22:57.450 --> 23:02.510] and then the manufacturer will provide the software which runs on top of that [23:02.510 --> 23:10.150] and connects the systems on board the AISD. It's worth mentioning that Class 2 EFBs have [23:10.150 --> 23:15.710] very different threat profiles depending on whether they are plane or pilot attached. [23:16.630 --> 23:21.590] So while plane attached EFBs are considered part of the minimum equipment list or NEL [23:22.190 --> 23:27.350] and tracked as an aircraft part, they're always under the control of the airline with coordinated [23:27.350 --> 23:34.870] and tracked movements between locations. Pilot attached EFBs are not. They enter and exit the [23:34.870 --> 23:40.090] cockpit when the pilot enters or leaves the aircraft. They are very likely to connect to [23:40.090 --> 23:47.030] all sorts of networks in hotels, cafes and airports so that the pilot can update software, [23:47.030 --> 23:51.970] navigation databases, notams, read corporate emails or even surf the internet. [23:54.150 --> 24:02.510] So you can see how the plane attached EFB has a very different threat matrix to that of a [24:02.510 --> 24:07.490] pilot attached one who may be anywhere in the world using insecure Wi-Fi. [24:10.060 --> 24:18.760] And then finally, I've included Class 3 for completeness because Class 3 don't really form [24:18.760 --> 24:24.360] part of the AISD, but they are an EFB. So they are integrated into the aircraft control domain [24:24.920 --> 24:32.000] and they have no connectivity outside of that. The build is the responsibility of the manufacturer, [24:32.000 --> 24:35.480] but it is maintained by the operator. And what I mean by that is [24:35.480 --> 24:41.280] that the hardware is fixed. The hardware cannot be changed. There may be software updates over [24:41.280 --> 24:46.780] time, but these are provided to the operator who then have the responsibility of maintaining [24:46.780 --> 24:54.660] the vibration. Class 3 EFBs are certified as part of the avionics. So the operator has next to no [24:54.660 --> 24:59.640] ability to make changes unless they wish to go through the trouble and expense of recertifying. [24:59.640 --> 25:06.600] And even though EFBs, Class 3 EFBs sit in the AISD, the ones I've seen are logically separated [25:06.600 --> 25:11.480] from the core avionics. And you have to interface through many different modules before you can [25:11.480 --> 25:18.840] bridge a gap between the control surfaces and the EFB. So attacking a Class 3 EFB to affect [25:18.840 --> 25:23.120] an aircraft in flight is still not that straightforward. [25:25.340 --> 25:31.000] Software categories. So Type A, really simple. They're just used for the storage and display [25:31.000 --> 25:36.920] of documents only. And like I said, these are typically Class 1. Class is PEDs and they get [25:36.920 --> 25:44.720] put away during the critical phases of flight. Type B applications, this is where it starts [25:44.720 --> 25:53.100] getting more fun. So like I said, they can perform performance calculations and they may actually [25:53.100 --> 26:00.400] access the internet on the ground and in flight. And they may be able to receive one-way data [26:00.400 --> 26:05.540] from the avionics. They are also the most common EFB software type I have seen. [26:07.180 --> 26:14.620] It's worth mentioning that Class 1 and Class 2 EFBs are built by the operator. And as such, [26:14.620 --> 26:19.700] they are not the responsibility of the manufacturer. Even though they may provide [26:19.700 --> 26:25.480] some or all of the software that runs on the device, it is up to the operator to ensure that [26:25.480 --> 26:31.780] they are working securely. For EFBs running Type B software, this is where things can get a bit [26:31.780 --> 26:37.980] blurred. According to regulations, any vulnerabilities in the software that could affect [26:37.980 --> 26:44.100] the operation of EFB software, regardless of who coded it, is the responsibility of the operator [26:44.100 --> 26:50.860] to mitigate. At the same time, details of any vulnerabilities do not seem to be passed on to [26:50.860 --> 26:58.320] the operator, just a series of recommendations for EFB security. Now these recommendations are [26:58.320 --> 27:08.000] really good, but as we'll come on to later, I don't feel they go far enough. Type C applications can affect [27:08.000 --> 27:14.880] the control of the aircraft in flight. So this is the really juicy part. Essentially, they can send [27:14.880 --> 27:24.780] data to the avionics. However, at the moment of going to press with this presentation, there are [27:24.780 --> 27:31.180] no current approvals that exist for Type C applications that I am aware of. I have seen [27:31.180 --> 27:39.060] future offerings from some manufacturers about having a bi-directional connection between the EFB [27:39.060 --> 27:45.600] and the flight management system which sits in the avionics. However, I have not enough detail there [27:45.600 --> 27:56.590] to give you the information about it. As I touched on on a previous slide, regulators provide operators [27:56.590 --> 28:03.570] with cyber security recommendations. Recommendations are also given by the manufacturers, but I feel [28:03.570 --> 28:10.470] that even when you combine these two sources, this advice does not go far enough. By that, I mean that [28:10.470 --> 28:16.530] there is a lack of detail in what to consider and measures to take. When it comes to regulatory [28:16.530 --> 28:21.610] documentation, security appears to be the poor cousin, with the majority of the document dedicated [28:21.610 --> 28:29.050] for physical characteristics and user interface design. The wording is also quite willowy and [28:29.050 --> 28:33.850] lacking in detail. It is certainly an area where I think there is a lot of room for improvement. [28:36.840 --> 28:43.340] Also, because implementing EFB security is the responsibility of the operator, some manufacturers [28:43.880 --> 28:49.700] appear to use this as a green light for poor implementations of technology, which on their own [28:49.700 --> 28:56.800] would be considered zero security by design. Instead, the security is designed to be assured [28:56.800 --> 29:01.360] by the inherent assumption that the operator's networks will never be compromised, [29:01.360 --> 29:08.080] or that malware will never find its way onto an EFB. Kind of like passing the security hot potato. [29:10.080 --> 29:16.320] At the same time, operators are not directly informed of any vulnerabilities, instead given [29:16.480 --> 29:23.680] a set of recommendations to implement. Unless the operator discovers any weaknesses, they would be [29:23.680 --> 29:31.380] unaware of the risks involved. And if they were aware of the risks, I'm more than certain that [29:31.380 --> 29:42.630] they would have targeted controls to them based on what they knew. Overall though, [29:43.290 --> 29:50.870] the recommendations given by some manufacturers are pretty good, although I feel there could be [29:50.870 --> 29:56.910] more detail in certain areas. I would like to share the document names and references with you. [29:56.910 --> 30:03.250] However, I am heavily constrained by NDA, as well as manufacturer efforts to protect IP. So I'm not [30:03.250 --> 30:09.110] allowed to give you these names, even though doing so would be for the benefit of any operators [30:09.110 --> 30:18.960] watching. And I cannot move on without briefly talking about class three or integrated EFBs. [30:18.960 --> 30:25.740] And even though they don't form part of the AISD, there are some use cases here which [30:25.740 --> 30:32.900] highlight a really important issue when it comes to technical debt. [30:33.600 --> 30:38.600] So like I said before, the hardware is fixed and the software updates come from the manufacturer. [30:38.760 --> 30:45.360] So to an operator, it may seem a very attractive prospect in terms of time and cost to get an EFB [30:45.360 --> 30:53.000] running. However, this category of EFB is not without its issues. And an example is an aircraft [30:53.000 --> 31:00.820] which I love, which is the Dreamliner. Having flown it many, many times, albeit not that long [31:00.820 --> 31:06.220] ago, I only started flying it about three years ago, I actually adore this aircraft. It is great [31:06.220 --> 31:14.260] to fly on as a passenger. But many Dreamliners have, especially the ones that first were [31:15.360 --> 31:22.300] brought to market, have Windows XP operating system integrated in the EFB which sits in the [31:22.300 --> 31:28.920] avionics. And this is a fact which gets a lot of surprise look from InterSec and IT professionals. [31:29.480 --> 31:40.760] But hang on. Remember, the 787 was designed in 2002-2003. Back then XP was king and would be for [31:40.760 --> 31:46.960] many years to come. The type approval and first flight for this aircraft was in 2009. [31:47.880 --> 31:55.180] Vista was available, but come on, Vista? Who would have changed? So when that aircraft was first [31:55.180 --> 32:03.160] went to market, it was delivered with EFP-EP4, developed using Windows XP. [32:04.740 --> 32:11.380] EP5 is available now, which uses Windows 10. However, not only do the upgrades come with a [32:11.380 --> 32:18.180] huge cost in terms of the units, but also a huge cost in terms of downtime and recertification of [32:18.180 --> 32:25.990] the avionics because it's a hardware change as well as a software change. So this kind of explains [32:25.990 --> 32:35.630] the issue of technical debt using more modern examples. Of course, we all think that an EFP [32:35.630 --> 32:44.190] on board a brand new modern state-of-the-art aircraft should be the most recent stable version [32:44.190 --> 32:49.410] of an operating system. But even in the timelines that we're talking about here, which are very [32:49.410 --> 32:58.290] small, we're seeing out-of-date operating systems being used in critical systems because of these [32:58.290 --> 33:04.630] timelines. And this issue is not limited to one manufacturer. I just brought up Boeing because of [33:04.630 --> 33:12.750] the knowledge I have of the BP-4, BP-5 versions and the operating systems. And it's not even [33:12.750 --> 33:18.010] limited to EFBs. It is all across the aircraft. I just wanted to discuss the technology trap. So [33:18.010 --> 33:23.890] those who may not fully understand why we see old tech in these brand new modern state-of-the-art [33:23.890 --> 33:32.910] aircraft. But it is interesting to think that the first Boeing 787s still have 20 years of life [33:32.910 --> 33:40.810] left in them or more. And when they come to end of life, will they still be running BP-4 with XP? [33:40.810 --> 33:48.410] I think some will. And we'll see. If Ken is still... Ken from Pentest Partners is still [33:48.410 --> 33:55.290] climbing around aircraft in breakers yards in 2040, then he may come across Windows XP [33:55.290 --> 34:02.050] inside the avionics, which will be a really, really cool thing to see him play with. [34:03.830 --> 34:08.610] But if you haven't seen their videos, they have some great walkthrough talkthroughs on 747s, [34:08.610 --> 34:12.970] which are going through the scrapyard today. And they also have older videos on their blog [34:13.490 --> 34:21.330] about dismantling old IFE systems a couple of years ago, which have 386 hardware inside them. [34:21.370 --> 34:24.510] And these are aircraft that were only dismantled a few years ago. [34:26.210 --> 34:30.950] So remember I said that in-air aircraft are flying data centers with half of it on the ground? [34:30.950 --> 34:37.470] Well, this is the other half. Ground systems. And they're used for keying and re-keying the PKI [34:37.470 --> 34:43.670] on the aircraft. They're used, like I said, for the key thing is the uploading of LSAPs and FLS [34:44.160 --> 34:51.050] to upgrade software modules on board the aircraft. A major, major time saver. But they also use for [34:51.050 --> 34:58.330] configuration changes, downloading of logs, and as a conduit for ESP connections. And this is done [34:58.330 --> 35:05.190] with some software provided by the manufacturer in a client-server relationship. The idea is that the [35:05.190 --> 35:10.990] operator would implement a Windows server, which runs the server software, and then the client [35:10.990 --> 35:19.980] would be installed on the engineer's laptop. The PKI on board the enabled aircraft is typically [35:19.980 --> 35:25.800] used to protect the VPN connection between the aircraft and the ground systems. It is also used [35:25.800 --> 35:32.020] to digitally sign the software that gets uploaded. So integrity checks can be done before it is [35:32.020 --> 35:39.040] installed in the aircraft. And this is one area that manufacturers seem to have gotten right with [35:39.040 --> 35:43.280] the latest enabled aircraft. At least the two main manufacturers in the world. [35:44.300 --> 35:49.400] While I do not have a PhD in cryptography, or anything higher than a BSc in any subject for [35:49.400 --> 35:54.820] that matter, the PKI implementations I have seen are simply excellent. And that shows the [35:54.820 --> 36:03.890] manufacturers are learning from previous issues. And that's great to see. As well as EFBs, I think [36:03.890 --> 36:09.330] ground systems require special consideration when it comes to security control implementation. [36:11.010 --> 36:16.610] The E-enabled aircraft being sold on the market today are truly excellent. Whether you're a pilot [36:16.610 --> 36:21.290] or a passenger, they are fantastic creations and a true credit to the teams involved in their [36:21.290 --> 36:27.310] development and manufacture. However, the same cannot be said of some of the supporting software. [36:28.090 --> 36:33.090] Some of the software distributed with modern aircraft is quite old, and they were likely [36:33.090 --> 36:37.230] coded at a time when there was very little consideration given to secure DevOps, or even [36:37.870 --> 36:44.910] cybersecurity at all. It seems that the approach back then was, so long as it works, it's fine. [36:46.090 --> 36:54.770] And that has led to some very insecure software being used with modern day aircraft. [36:55.650 --> 37:00.970] However, I'm seeing positive movements in this area. There are new versions of EFB and ground [37:00.970 --> 37:05.950] system software being developed today, which should be available in a few years' time, [37:05.950 --> 37:10.990] and that is going through what appears to be a sensible and secure approach to software development. [37:11.350 --> 37:14.990] So time will tell what comes out from that, but again, it's another positive move. [37:17.720 --> 37:22.620] As with EFB software, how many operators have looked at the ground system software [37:23.620 --> 37:29.760] from an attacker's perspective? Have they looked for weaknesses? Have they found any, [37:29.760 --> 37:34.500] and then combined this with the threat model and overlaid on the existing network architecture? [37:34.940 --> 37:42.920] Remember, like I said, a lot of airline networks have any, if at all, any segregation. So [37:43.520 --> 37:49.140] if the corporate network was compromised, could someone pivot into the ground systems and put [37:49.140 --> 37:57.240] your aircraft at risk? Also, conversely, could this software, at any weaknesses you identify, [37:58.400 --> 38:05.020] introduce new attack vectors or vulnerabilities in your systems, which could then be used [38:05.020 --> 38:10.940] to pivot into the corporate network? These are things that operators really need to consider and look at. [38:12.520 --> 38:17.900] Now, I have seen some manufacturers and third parties offer ground systems, [38:18.180 --> 38:24.540] a ground system service hosted in the cloud. And now, while I understand moving to the cloud is not [38:24.540 --> 38:28.940] the silver side of the bullet for any organization, although some seem to think it is, [38:28.940 --> 38:34.300] from my experience, these cloud solutions are normally put together very well from a security [38:34.300 --> 38:41.440] perspective. They also permit creative design in methods to mitigate weaknesses in the software. [38:41.920 --> 38:48.380] So, for example, if you had issues with the client software that would sit on the [38:49.560 --> 38:56.020] engineer's laptop, and you didn't want that interaction with the server going across the [38:56.020 --> 39:02.600] network, then what you could look at is putting both the server and the clients in separate [39:02.600 --> 39:09.620] lockdown enclaves inside a cloud solution, then implement a VDI to host the client's interface [39:09.620 --> 39:16.200] through a secure HTML5 web front end. And that gives you lots of opportunities to customize the [39:16.200 --> 39:22.680] security according to your threats and risks, and all sorts of other opportunities as well. [39:22.980 --> 39:29.480] So, these are certainly ideas that we're looking at, because the software that's available today [39:29.480 --> 39:34.960] doesn't seem to be that good, but some of the cloud's offerings are. [39:38.540 --> 39:45.300] Flight attendant panels. So, these are interesting from a cyber perspective. So, [39:45.300 --> 39:51.520] anyone that deals with industrial control systems will know that these are essentially [39:51.520 --> 39:58.000] what's known as a HMI, a human-machine interface. And these are used for lighting, air control, [39:58.000 --> 40:03.760] announcements, door status, lighting, emergency buttons, and they might also have bespoke [40:03.760 --> 40:09.580] features that the airline will implement. They can also be used for maintenance and [40:10.860 --> 40:22.430] for uploading FLS, LSAPs, and for downloading logs if the maintenance port is unavailable. [40:24.110 --> 40:33.480] So, why do FAPs have a security focus? Well, like any HMI, especially those ICS implementations, [40:33.480 --> 40:38.340] they're typically an easy target, especially those with a USB port. [40:40.820 --> 40:46.500] I did some research on FAPs, and while some are directly connected to both the AISD [40:46.500 --> 40:51.220] and the PIESD in e-enabled aircraft, there are none which have a connection [40:52.140 --> 41:00.520] to the ACD or avionics anymore. Not that I can see anyway. That said, I did raise concern [41:00.520 --> 41:06.000] about the possibility of a passenger inserting a USB stick loaded with malware [41:06.600 --> 41:10.440] into the FAP USB port, and what that would mean. [41:12.160 --> 41:16.900] So, the team I was in started asking the manufacturer some very probing questions, [41:16.900 --> 41:21.520] and to their credit, the manufacturer provided a highly detailed and impressive response, [41:21.520 --> 41:26.740] and it was actually done in person due to the sensitivity of the content. But what they showed [41:26.740 --> 41:32.900] us were that the technical controls to protect the ACD from the FAP were very robust. However, [41:32.900 --> 41:38.380] when asked the further questions, it seemed that the AISD was considered almost expendable [41:38.380 --> 41:44.400] in the malware onboard scenario. When asked about that, the response was that the AISD [41:45.240 --> 41:50.780] can be entirely functioning and it will not affect the airworthiness, which can be interpreted as [41:50.780 --> 41:55.700] the AISD can be riddled with malware, and the aircraft can still be operated legally. [41:56.800 --> 42:03.780] Fine, I thought. However, that got me thinking to the operational side, and I wondered how many [42:03.780 --> 42:08.960] pilots, knowing that an aircraft is infected with malware, yet still legal to fly, would actually [42:08.960 --> 42:15.280] fly it. What if, as an attacker, my goal was not to take control of the aircraft, but to affect [42:15.280 --> 42:25.140] the operations of an airline as a coordinated extortion or blackmail attack? Now, everyone in [42:25.140 --> 42:35.320] industry knows, regardless of the airline, that this USB port is off-limits, even to crew. Yet, [42:35.320 --> 42:40.080] I have spoken to Cabot crew from multiple airlines, and they have confirmed that they are told this [42:40.080 --> 42:46.140] in training. However, everyone in the industry also knows that this port is used extensively [42:46.710 --> 42:51.800] to charge crew devices, both official and personal, in spite of the rules. [42:52.360 --> 42:57.480] I have also seen passenger devices being charged in the FAP as the USB port in their seat wasn't [42:57.480 --> 43:02.320] working, and it was actually the crew who had done this as a courtesy to the passenger. [43:03.660 --> 43:09.200] So, what is clear from this is that, while people know there is a risk, [43:09.200 --> 43:13.480] it is clear the awareness training isn't working. Not all the time, anyway. [43:16.620 --> 43:22.880] I thought it important to also include some detail on some of the more general issues I have found, [43:22.880 --> 43:29.760] and I must state again, I am heavily bound by NDA, but I have reached out for advice [43:29.760 --> 43:35.440] and agreed parameters of what I can divulge here prior to this talk. [43:37.160 --> 43:44.040] So, one team I was in had been working on the security design of their ESDs, [43:44.040 --> 43:48.900] and we had planned project milestones to ensure that build documentation was accurate, [43:48.900 --> 43:55.220] and the device was built according to design. A lot of work had gone into locking the operating [43:55.220 --> 44:00.840] system down. It was Windows-based, and this is where I had a lot of extensive experience [44:00.840 --> 44:06.460] and knowledge. So, this is where I focused my attention. I knew that we had a pen tester who [44:06.460 --> 44:10.420] was going to look at it from the perspective of an ass hacker, and oversee my work, [44:10.420 --> 44:15.500] so I left the software alone. This is the manufacturer-provided software. [44:16.060 --> 44:24.500] I had naively assumed that this software would be fine, or at least not too bad. [44:26.300 --> 44:31.220] When it came to the pen test, I knew the build was solid, so I was surprised when on day two [44:31.220 --> 44:38.560] of the test, day two of the five-day test, Andrew, the pen tester, called. Now, anyone that deals with [44:38.560 --> 44:43.620] pen tests know that if they call you prior to the planned end date and it isn't a question, [44:43.620 --> 44:50.760] then it's bad juju. Andrew had not only found an API that was completely unprotected, [44:50.760 --> 44:55.820] there was no authentication, there was no encryption, but had written some code, [44:55.820 --> 45:03.140] but also written some code to exploit it. I was quite shocked, so I sent a message to the [45:03.140 --> 45:08.140] manufacturer straight away, and received a response that this was not a vulnerability, [45:08.140 --> 45:17.970] but in fact a feature. All I can say is that when I repeated this response to my colleagues, [45:17.970 --> 45:24.330] jaws across the room dropped to the floor. I took a step back and realized that in order to make [45:24.330 --> 45:29.090] the manufacturer understand, I had to do more analysis. Now, back when I was in the British [45:29.090 --> 45:35.010] army, I was taught to analyze attack scenarios by asking, so what, until you reach the answer. [45:35.410 --> 45:39.150] So I took the same approach with Andrew's code and turned the dial to 11. [45:40.610 --> 45:43.830] I found every single parameter I could. [45:44.750 --> 45:51.270] At the end, it would not have taken much to turn that resulting code into a very feasible malware [45:51.270 --> 45:58.610] for EFBs. I spoke with flight operations, pilots, and InfoSec, and demonstrated the rather trivial [45:58.610 --> 46:09.500] attack. Everyone I spoke to agreed that this was bad. So, despite this feedback, which included a [46:09.500 --> 46:15.560] dossier of potential outcomes which I had compiled from pilots and operations feedback, [46:15.560 --> 46:20.860] the only action taken by the manufacturer was to reduce the attack surface. [46:21.920 --> 46:26.880] They replied, in their opinion, the scenarios I had described were not feasible, [46:26.880 --> 46:32.680] and the whole vulnerability was dismissed. Now, it wasn't like I was proposing aliens would come [46:32.680 --> 46:38.680] down and attack planet Earth, although 2020 isn't over yet. One threat which they dismissed as [46:38.680 --> 46:45.960] unrealistic was the insider threat. Now, I found that really strange because this threat was on [46:45.960 --> 46:50.580] the operator's risk register, and I had been asked specifically to consider this threat [46:50.580 --> 46:55.280] when giving my updates to high-level security boards. [46:58.440 --> 47:05.440] Consequently, sometime later, however, I was informed that the software in question was [47:05.440 --> 47:11.520] going through a complete lifecycle upgrade, and that the project would include not just a secure [47:11.520 --> 47:17.920] DevOps approach, but security milestones with qualifiers as well. Now, I cannot take full credit [47:17.920 --> 47:24.560] for that change because I know that somebody had moved into a new role covering the security of [47:24.560 --> 47:31.440] such software, which means that they had already knew that there were issues, and that they were [47:31.440 --> 47:39.020] moving to close the gap when I had spoken about this issue with the API. And I know this person [47:39.020 --> 47:42.640] from my dealings with the manufacturer, and I'm very confident he will do good work. [47:46.130 --> 47:50.570] Further investigations I've made on other aircraft have uncovered examples of the same [47:51.390 --> 47:58.690] unprotected API. Different APIs, but unprotected all the same. And these are inside the AISD, [47:59.750 --> 48:04.710] so they are accessible from the EFB, they're accessible from other systems on board. [48:05.490 --> 48:09.690] And despite going through the responsible disclosure route as an independent researcher, [48:09.690 --> 48:15.230] I was not only dismissed for making unrealistic assumptions, but I had to fight for updates. [48:16.330 --> 48:21.390] Now, the assumption I made was based on a proposed commercial offering from the manufacturer, [48:21.390 --> 48:25.410] coupled with their own API documentation, detailing how it would work. [48:26.990 --> 48:32.770] Yet it was still considered unrealistic. Now, they may have made a separate assessment themselves, [48:32.770 --> 48:38.230] and started going down a different, more secure pathway for the release of this new functionality, [48:38.230 --> 48:43.390] which would be great. But I was not made privy to the details, so I have to say that for now, [48:43.390 --> 48:47.910] I don't know. If I do find out more, I will certainly update you. [48:49.910 --> 48:55.190] So hopefully that has given you a sufficient introduction into a network domain that is often [48:55.190 --> 49:00.630] overlooked by security researchers, but which has a lot of juicy issues that need to be addressed. [49:01.030 --> 49:06.590] Like I said, attacks on the avionics are really interesting, but getting access to them to [49:06.590 --> 49:13.270] exploit vulnerabilities is pretty difficult. While the AISD may not be as sexy or interesting [49:13.270 --> 49:17.130] on the surface, when you scratch a bit deeper, there's a lot to decipher. [49:18.890 --> 49:22.410] Touchpoints, while still quite difficult to exploit, are more accessible, [49:23.050 --> 49:27.830] considered more traditional to an attacker. And this means everyone from cabin crew, [49:27.830 --> 49:32.270] to engineers, flight ops, and infrasec, all have an important role to play [49:32.270 --> 49:35.810] in securing e-enabled aircraft at the operator level. [49:38.430 --> 49:45.810] Some advice I'd give to operators is, do not take the security of provided software for granted. [49:46.250 --> 49:49.210] Now, so I'm not talking about FLS and LSAPs here, what I'm talking about [49:49.210 --> 49:55.770] is the software that is provided to connect to your aircraft, so the EFBs, the ground systems, etc. [49:57.150 --> 50:01.910] Even the most modern aircraft today have some very basic vulnerabilities in the code. [50:02.170 --> 50:07.550] What is more worrying for me is that this software will achieve some kind of approval, [50:07.550 --> 50:15.950] in spite of these weaknesses. So don't assume because they have approvals that they are 100% [50:15.950 --> 50:22.450] secure. Make sure you perform some kind of assurance on software and systems, either [50:22.450 --> 50:27.630] using your internal teams, or if you don't have the skills in-house, hire an external [50:28.190 --> 50:34.230] expert or pen tester. It may be costly, but having an aircraft AOG for several weeks while you [50:34.230 --> 50:41.070] investigate a cyber attack, and have to replace all the onboard FLS or LSAPs, could probably cost [50:41.070 --> 50:48.870] you a lot more. Security in the operations is not the realm of one department alone. [50:49.350 --> 50:53.690] The multiple business areas that make up the operations require that InfoSec understand [50:53.690 --> 50:59.790] aviation and what cyber risks actually mean to aircraft. InfoSec also need to make sure [50:59.790 --> 51:07.110] that engineers and other business areas understand the risk context. It is a two-way street. [51:07.610 --> 51:11.530] I've seen that some operators have implemented a multi-discipline groupings, [51:11.530 --> 51:17.130] which handle these challenges. They're often called a cyber computer cell, which is a really [51:17.130 --> 51:26.030] cool name to have on your CV, just a little hint there. So these groupings often have at least [51:26.030 --> 51:31.330] one board member, and they combine knowledge and experience from multiple departments, [51:31.330 --> 51:34.950] and they ensure that issues are tackled in the best possible way for the business. [51:35.210 --> 51:38.790] From what I hear, they are extremely effective, and I would certainly recommend [51:38.790 --> 51:42.610] that you, if you don't have one already implemented in your business, [51:42.610 --> 51:45.450] and you operate a unit of aircraft, that you certainly look into it. [51:46.910 --> 51:50.790] And I suppose it finally goes without saying that you must involve your regulators as much as you [51:50.790 --> 51:57.410] can. They have access to the right people, the information, and the frameworks, with the right [51:57.410 --> 52:03.090] advice and the right guidance to guide you through difficult scenarios. So make sure you engage them [52:03.090 --> 52:07.360] as much as you can. And if you don't get satisfactory results from your regulators, [52:08.870 --> 52:14.410] sure, pop me a line. I can certainly help where I can. But finally, I'll sign off with a small [52:14.410 --> 52:20.010] piece of advice for operators. If you have someone in your organization who is as effective and [52:20.010 --> 52:26.210] competent an engineer as they are with InfoSec and cybersecurity, my advice would be to make [52:26.210 --> 52:31.530] sure that person never leaves your business. I'm not an engineer. I was lucky I had access to [52:32.170 --> 52:40.290] excellent engineers who were able to communicate to me exactly what the problems were, [52:40.290 --> 52:47.410] and to better understand systems so I could evaluate the risk. At the same time, these [52:47.410 --> 52:53.090] engineers were... they have a high level of intelligence engineers, so they could understand [52:53.090 --> 52:57.250] what I was telling them. And together we worked really well. But if you can incorporate that into [52:57.250 --> 53:05.030] one person, that's a very valuable asset indeed. So that's the end of your presentation. Hopefully [53:05.030 --> 53:11.170] that's enough information to whet your appetites in the AISD. There is a lot more there. I have to [53:11.170 --> 53:17.410] cram it into 50 minutes. So I will be available for questions in a session in the Discord channel [53:17.410 --> 53:22.450] from where you linked to this presentation. Please head over there and join in the discussion. [53:22.750 --> 53:27.970] Alternatively, you can grab me on Twitter or my website. There's an email link you can get on me. [53:27.970 --> 53:31.610] And I hope to speak to you all soon. Take care.