WEBVTT 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:17.560 MITM, the mystery in the middle. 00:17.560 --> 00:30.120 My name is Matthew Gaffney and I'll be taking you through an introductory level talk about the Aircraft Information Systems Domain, also known as the AISD. 00:31.240 --> 00:42.860 We'll be covering through these topics throughout the 50 minutes or so talk today, covering most of it on EFBs, if I'm honest. 00:43.720 --> 00:46.780 So, why the mystery? 00:47.480 --> 01:03.960 So, the reason I call it the mystery in the middle was due to the lack of public information I could find about the AISD when I started my journey into aviation cybersecurity several years ago. 01:04.140 --> 01:13.700 I could find lots out about hacking avionics systems, IFE and all about their weaknesses, but very little about the AISD. 01:14.300 --> 01:26.980 So, that's the reason, the main reason for the talk today is to try and improve knowledge and awareness of this part of the aircraft and generate the healthy discussion about security within. 01:27.960 --> 01:40.460 So, logically, the AISD sits in between the Aircraft Control Domain and the Passenger 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:59.120 And E-enabled means that it will integrate, the aircraft will integrate with the airline IT systems to provide significant cost savings to the business. 01:59.560 --> 02:16.800 What it does is it allows remote maintenance and uploading of software updates, which is a key time saver, especially when you consider that previously, if you wanted to update the firmware on a module, you'd have to remove it, send it away, in the meantime, 02:16.800 --> 02:22.400 put in a replacement, then get the old unit back with the new firmware and swap it over. 02:24.280 --> 02:37.080 So, being able to upload new software remotely without having to remove modules or LRUs, 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.740 So, for airlines, the AISD is the most important part to get right for the business. 02:53.740 --> 02:55.420 At least, that's my view of it. 02:55.520 --> 03:00.680 An airline cannot have much influence on how the ACD is constructed. 03:00.680 --> 03:05.460 Maybe a small amount of customization, but not very much at all. 03:05.520 --> 03:14.140 It's heavily regulated, 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:24.460 But there's lots of challenges in doing that. 03:24.980 --> 03:32.500 There's, across all aviation, not just enabled aircraft, there's a lot of older technology that gets reused. 03:32.820 --> 03:40.300 And it's not really a surprise, because if it works and it meets the requirements, why change it? 03:41.080 --> 03:45.380 Certifying new modules is expensive and time consuming as well. 03:45.380 --> 03:55.300 So, the older modules that are still fit for purpose will be reused a lot, because it's cheaper to modify them or to use the old ones. 03:55.880 --> 04:07.040 What this also means, though, is that when threats change over time, these older modules can be attacked in new ways nobody thought about when they were conceived. 04:07.260 --> 04:18.640 We're seeing this with avionics hardware today, but we are not really thinking about this when it comes to the AISD, and maybe we should. 04:19.900 --> 04:28.800 When I say we have new risks to manage, what I mean is, engineering now needs to consider cyber and infosec risks. 04:29.540 --> 04:33.280 Infosec teams now need to understand and consider engineering. 04:33.620 --> 04:37.680 Traditionally, these are two areas of the business that have been completely isolated. 04:38.140 --> 04:48.840 And it has allowed engineering to operate in its own little bubble, which has led to engineering not following infosec policy 100%. 04:48.840 --> 05:07.460 And you see examples of bad practice, such as post-it notes with passwords, or even passwords being written into procedure documentation, because it's easier to operate that way when you're an engineer than it is to use a password manager or to remember the password off by heart. 05:07.780 --> 05:16.420 At the same time, IT and infosec are implementing systems for engineers to use without fully understanding the constraints of engineering. 05:16.420 --> 05:21.360 They don't always have really good 3G connection on board an aircraft. 05:21.360 --> 05:27.220 They don't always have time to be able to learn new systems in depth. 05:27.220 --> 05:41.980 What they do have is very pressured time constraints in order to get aircraft back on the line, because all the time spent being fixed is money. 05:42.940 --> 05:57.420 But when IT comes along and comes along and implements a new IT system, say for example they don't have single sign-on, all of a sudden that engineer, instead of 20 passwords to remember, they now have 21. 05:57.560 --> 06:00.180 And then we ask the question, why are they writing down passwords? 06:00.800 --> 06:09.160 So understanding the constraints and the difficulty of engineering can go a long way to improving the security posture of an airline. 06:12.150 --> 06:15.810 And operators really need to get these departments working together in harmony. 06:17.250 --> 06:25.250 When dealing with engineering and e-operations, you cannot bring the corporate information or cyber security mentality and templates to the party. 06:25.250 --> 06:26.870 They just won't work. 06:27.510 --> 06:32.330 You're dealing with an area of the business which historically has not been great with cyber. 06:32.550 --> 06:34.230 So you have to go slow. 06:34.650 --> 06:42.070 One thing that's on your side though, as an InfoSec person, is that aircraft engineers love processes and procedures. 06:42.370 --> 06:43.930 Oh boy, do they love it. 06:44.750 --> 06:54.170 Before you can even touch an aircraft on the ground, you must have a job card which outlines the steps engineers must take for each task. 06:54.690 --> 07:01.350 So if you can bring influence to these procedures to improve security, that's half the battle won. 07:02.850 --> 07:08.010 And then finally, I should probably explain that last comment on the slide. 07:08.070 --> 07:17.990 This is my humble opinion and I know many would disagree, but I feel that when looking at aviation security, hackers should not focus entirely on avionics. 07:19.010 --> 07:31.150 Although the ACV and the avionics have a number of well-documented and technical weaknesses, it does have a very effective physical security model. 07:31.330 --> 07:34.490 You can only access the avionics bay from outside the aircraft. 07:34.490 --> 07:38.390 So when the aircraft is in flight, not even the pilots can get to it. 07:38.450 --> 07:41.870 So only the engineers on the ground can do that. 07:41.870 --> 07:50.330 And if you're going to try to get access airside for legitimate reasons, you know how difficult it would be to get airside for illegitimate reasons. 07:54.490 --> 08:06.410 Also, there's usually only one network interface between the ACV and the AISD, and I'm talking about aircraft that are fully compliant with ARINC 821 here. 08:06.570 --> 08:13.190 But this separation is normally implemented with protections such as a firewall or even a data diode. 08:13.630 --> 08:20.690 And sometimes we also base that network communication on proprietary protocols, not on TCPIP. 08:21.450 --> 08:30.930 So if you can get into the ACV, yes, you can inflict a lot of damage, but gaining that access either through physical or technological means would be extremely difficult. 08:31.130 --> 08:39.790 And if you can go to that level, if you can get physical access to an aircraft, why go hacking? 08:39.790 --> 08:48.850 You know, you can do something much more nefarious with a much greater guarantee of success if that's what you wanted to do. 08:49.830 --> 09:01.230 So for me, instead, the aircraft information systems domain has multiple touch points ranging from the airline network, Wi-Fi, even the internet and the cabin. 09:01.670 --> 09:05.890 And these attack scenarios are much more traditional and realistic for hacking. 09:05.910 --> 09:07.550 Okay, it's not sexy. 09:07.550 --> 09:14.170 You can't control the aircraft control services from the AISD. 09:14.170 --> 09:19.450 You can have other effects on the aircraft, effects which may impact operations. 09:19.450 --> 09:25.990 And if you know what you were doing, you could modify some of the data presented to pilots. 09:29.700 --> 09:29.920 So 09:33.000 --> 09:34.800 manufacturer challenges. 09:34.820 --> 09:38.180 So I explained the challenge about technical debt. 09:38.260 --> 09:42.680 And the reason for that is that airworthiness timescales are huge. 09:42.680 --> 09:58.000 And they encourage, or they almost force manufacturers to really think about what they're going to reuse and what they have to rebuild from scratch. 09:58.000 --> 10:02.120 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:18.000 The key one is they have zero visibility of the manufacturer's risk assessment. 10:18.020 --> 10:29.610 So when the manufacturer is designing and building an aircraft, they perform extensive and detailed risk assessments to mitigate system vulnerabilities. 10:32.180 --> 10:39.740 They will mitigate many of these issues themselves, but they will also transfer some to the operators. 10:40.960 --> 10:49.880 And this is communicated in a number of ways, such as security handbooks or ANSOGs, depending on which manufacturer you're dealing with. 10:50.220 --> 10:56.980 But no operator will get to see details of the original vulnerability or the risk assessment. 10:57.840 --> 11:11.280 So despite the quality of this manufacturer guidance, these recommendations which come down, there's no real mechanism for the operator to assess the effectiveness of implemented controls. 11:11.720 --> 11:22.240 And this can, and from what I've seen, probably does lead to gaps in the cybersecurity protections of e-enabled aircraft at the operator level. 11:24.340 --> 11:30.380 When you think about it, airlines are heavily reliant on legacy IT systems. 11:30.440 --> 11:39.820 For example, many use at the core of their business, a TPF system, which handles all of the real-time transactions. 11:40.020 --> 11:42.500 It's not a traditional operating system. 11:42.500 --> 11:46.900 It is based on technology that was released in 1979. 11:46.940 --> 11:51.160 To program it, it's done in hexadecimal. 11:51.160 --> 11:58.800 It's just not what we would, people of my generation, would consider a traditional operating system. 11:58.800 --> 12:06.740 But it handles transaction messages one-to-one at an extremely high volume and extremely high speed. 12:07.320 --> 12:14.100 And what that does is make sure that the same seat isn't booked twice by separate transactions milliseconds apart. 12:14.680 --> 12:19.920 And there's nothing out there on the market that can really replicate that right now. 12:21.940 --> 12:29.840 Also, airlines, over time, have grown and have added new systems on top of the old systems. 12:30.460 --> 12:37.460 And until quite recently, this may have been done without consideration of all the risks. 12:37.480 --> 12:41.820 In fact, some of them would have been done before cybersecurity was really a thing. 12:43.520 --> 12:49.140 So some may not have followed good practice, such as network segregation. 12:51.560 --> 12:54.260 Airlines also operate 24-7. 12:54.380 --> 12:56.780 And that means that outages are very costly. 12:58.200 --> 13:03.120 When an airline IT system goes down, aircraft stop. 13:03.120 --> 13:09.360 They just cannot take off because they 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:21.080 risk managed to the nth degree. 13:21.080 --> 13:26.160 And there's a lot of risk avoidance going on when these new systems are put in place. 13:26.380 --> 13:37.160 Either that, or you just throw resources at it to make sure that if something does go wrong when you introduce a new system, that the impacts are mitigated as much as possible. 13:38.700 --> 13:44.540 What it does mean is that over time, airlines can become quite flat in their networks. 13:44.540 --> 13:52.260 And what that means is if the perimeter is at a breach, it's very easy for an attacker to then pivot inside the networks. 13:54.980 --> 13:57.120 So where regulators fit in. 13:57.120 --> 14:11.000 So speaking from a European perspective, there's some really positive steps going on right now in the critical national infrastructure sphere of which aviation forms a part. 14:11.440 --> 14:19.740 And maturity in cyber security, aviation cyber security is growing slowly and gathering momentum. 14:19.740 --> 14:21.320 Or at least it was before COVID. 14:21.320 --> 14:23.500 It was the last time I was really involved. 14:24.540 --> 14:33.180 From what I've seen, the UK CAA is growing the cyber oversight function in a very positive way. 14:33.180 --> 14:45.980 And rather than just setting out a framework and directing airlines to comply, they are working closely with operators instead, 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:11.540 Maybe some trusted government bodies could be given more details on the risks and help guide operators on the effectiveness of their controls without passing on that sensitive detail. 15:12.460 --> 15:16.600 If we can't trust the government, what about the aviation ISAC? 15:16.960 --> 15:23.120 Although they are a member organization, most of the large operators and manufacturers are members. 15:23.420 --> 15:27.240 Could this be another suitable mechanism to do the same thing? 15:27.760 --> 15:31.420 Whatever happens, I feel something does need to be done. 15:31.420 --> 15:36.000 Otherwise, pardon the pun, airlines could be flying blind. 15:38.930 --> 15:45.510 So here is a rather simplified overview of a E-enabled aircraft. 15:45.510 --> 15:50.720 This diagram is based on compliance to the ARIC-821 protocol. 15:51.670 --> 16:03.360 And as you can see, we've got the three main domains, the aircraft control domain, the aircraft information systems domain, and the passenger information and entertainment systems domain. 16:04.720 --> 16:15.740 The AISD, as well as being a main communications hub or hosting a main communications hub, will host the electronic flight bag if it's a class two. 16:15.760 --> 16:19.380 If it's a class two, the EFB will sit in the avionics. 16:19.380 --> 16:20.820 More on that later. 16:21.400 --> 16:26.600 Some aircraft have their flight standard panel, or FAP, connected in the AISD. 16:27.180 --> 16:44.180 And there's also occasionally printers, maintenance terminals, which can be USB or Ethernet port, depending on what kind of device you're using, if you're using just a straight up USB as a tool, or if you're using a portable data loader. 16:45.340 --> 16:54.600 And those maintenance ports are used as a backup for the IPSET panels that sit between the aircraft and the ground system. 16:55.020 --> 17:02.020 So these IPSET tunnels are really well... the security is excellent. 17:02.100 --> 17:10.840 So they are managed from mostly on board, but the ground systems are involved in the keying of the aircraft. 17:11.560 --> 17:16.140 And there's... I'll talk a bit more about PKI later on. 17:16.440 --> 17:44.620 What we do have is the EFBs, if they are connected to the AISD, they will often route traffic to the internet through the IPSET panel, through the DMZ and out into the internet, which is usually for software updates, and it's usually a very restricted set of websites where the EFBs can go. 17:45.480 --> 17:59.680 That is usually done on the ground as well, because if you imagine, if this is happening during the flight phase, you have the latency of the SATCOM connection down to the ground systems through the DMZ and out to the internet. 17:59.760 --> 18:08.580 So the response time on that in flight would be pretty long, but on the ground it's manageable. 18:11.080 --> 18:29.840 One thing to note as well is sometimes in enabled aircraft, instead of having a SATCOM in the AISD, there is an option whereby the manufacturer offers the operator the ability to use the passenger SATCOM connection. 18:29.840 --> 18:39.540 Remember, this SATCOM connection, the passenger name, does not go through this IPSET panel here, it goes off through the service provider's network. 18:40.840 --> 19:00.520 And one option that some manufacturers are offering to operators is that the information system domain here can connect to the ground systems, but through the same SATCOM here, and that is quite advantageous in terms of cost. 19:00.640 --> 19:04.260 The more you use SATCOM, the cheaper it is. 19:04.260 --> 19:08.640 So if you have two connections, that's going to cost you quite a bit of money. 19:08.640 --> 19:17.800 If you have one, yes, you're going to be paying for more data, but because prices come down with volume, you'll actually pay less overall. 19:18.460 --> 19:31.000 What I have seen though is quite promising that when this is implemented, the connection from the AISD into the SATCOM is through a separate VLAN. 19:31.000 --> 19:39.280 So essentially that's a mini network segregation on its own there, and that data is not accessible from the IFE or the cabin Wi-Fi. 19:42.250 --> 19:46.010 So moving on to my favorite subjects, electronic flight bags. 19:46.630 --> 19:49.310 So these have been a revolution for pilots. 19:49.370 --> 20:00.670 As the name suggests, they replaced the large and cumbersome and often heavy bags which were used by pilots to carry paper-based manuals. 20:01.750 --> 20:14.710 These bags would often weigh more than 25 kilos, and as well as being difficult to maneuver, they also contributed to physical injuries of pilots as well. 20:15.110 --> 20:22.710 Moving those bags around the cabin, around the cabin, around the cockpit, sometimes led to shoulder injuries because of their weight. 20:24.690 --> 20:32.690 Depending on the type of EFB, they can perform a variety of functions, including a documentation reference library. 20:33.130 --> 20:38.970 A type B can perform what's known as performance calculations. 20:39.170 --> 20:43.070 These give V1, VR, V2 speeds, all that kind of stuff. 20:43.070 --> 20:45.130 These are important for pilots to know. 20:45.830 --> 20:49.470 Enroute navigation, if you have a GNSS feed into the EFB. 20:49.670 --> 20:58.070 And if you have the relevant connections, access to NOTAMs, weather information, and the ability to do fuel calculations as well. 20:58.990 --> 21:11.790 Some operators also include bespoke applications that sit on the EFB, and these might be used to complement airline operation systems, so long as they reach the relevant approvals. 21:11.790 --> 21:28.070 But they will also help achieve the overall goal of EFBs, which is not just a reduction of paper inside the cockpit, but also faster access to information, which helps lower turnaround times and reduce workload in the cockpit. 21:29.990 --> 21:34.510 And non-pilots may not understand the importance of that last part. 21:34.570 --> 21:41.990 Many incidents of pilot error cite cockpit workload as either the main or as a contributing factor. 21:42.370 --> 21:49.270 So this makes EFBs not just an effective tool in reducing costs, but they also help you fly safely. 21:51.290 --> 21:58.630 Hardware categories have different names, depending on which regulator you sit under and how long you've been in the business. 21:59.230 --> 22:05.190 They're often used together, so I've included both here as some general characteristics. 22:06.690 --> 22:15.310 So a Class 1 or portable EFBs, they're often small devices and double up as corporate devices at the same time. 22:15.310 --> 22:21.930 Think of a small EFB, a small iPad with no connectivity to the aircraft. 22:22.130 --> 22:29.330 They're then considered like a paired personal electronic device and as such they must be stowed to take off, taxi and land. 22:30.810 --> 22:36.310 Class 2, these can be pilots or plane attached EFBs. 22:36.450 --> 22:44.110 These connect to the AISD with usually a one-way feed of data from the avionics. 22:44.370 --> 22:50.990 They can be integrated with the cockpit displays and their build is the responsibility of the operator. 22:50.990 --> 23:06.170 Quite often they are small laptops with operating systems such as Windows and then the manufacturer will provide the software which runs on top of that and connects the systems on board the AISD. 23:07.450 --> 23:15.710 It's worth mentioning that Class 2 EFBs have very different threat profiles depending on whether they are plane or pilot attached. 23:16.630 --> 23:29.790 So while plane attached EFBs are considered part of the minimum equipment list or NEL and tracked as an aircraft part, they're always under the control of the airline with coordinated and tracked movements between locations. 23:30.470 --> 23:33.290 Pilot attached EFBs are not. 23:33.650 --> 23:37.790 They enter and exit the cockpit when the pilot enters or leaves the aircraft. 23:38.370 --> 23:51.970 They are very likely to connect to all sorts of networks in hotels, cafes and airports so that the pilot can update software, navigation databases, notams, read corporate emails or even surf the internet. 23:54.150 --> 24:07.490 So you can see how the plane attached EFB has a very different threat matrix to that of a pilot attached one who may be anywhere in the world using insecure Wi-Fi. 24:10.060 --> 24:21.560 And then finally, I've included Class 3 for completeness because Class 3 don't really form part of the AISD, but they are an EFB. 24:21.560 --> 24:28.160 So they are integrated into the aircraft control domain and they have no connectivity outside of that. 24:28.740 --> 24:34.460 The build is the responsibility of the manufacturer, but it is maintained by the operator. 24:34.460 --> 24:37.400 And what I mean by that is that the hardware is fixed. 24:37.400 --> 24:39.920 The hardware cannot be changed. 24:40.000 --> 24:47.900 There may be software updates over time, but these are provided to the operator who then have the responsibility of maintaining the vibration. 24:49.920 --> 24:53.240 Class 3 EFBs are certified as part of the avionics. 24:53.240 --> 24:59.640 So the operator has next to no ability to make changes unless they wish to go through the trouble and expense of recertifying. 24:59.640 --> 25:08.360 And even though EFBs, Class 3 EFBs sit in the AISD, the ones I've seen are logically separated from the core avionics. 25:08.360 --> 25:16.180 And you have to interface through many different modules before you can bridge a gap between the control surfaces and the EFB. 25:16.180 --> 25:23.120 So attacking a Class 3 EFB to affect an aircraft in flight is still not that straightforward. 25:25.340 --> 25:26.960 Software categories. 25:27.000 --> 25:29.240 So Type A, really simple. 25:29.240 --> 25:32.640 They're just used for the storage and display of documents only. 25:33.020 --> 25:35.040 And like I said, these are typically Class 1. 25:35.100 --> 25:40.740 Class is PEDs and they get put away during the critical phases of flight. 25:42.320 --> 25:46.020 Type B applications, this is where it starts getting more fun. 25:46.180 --> 25:56.740 So like I said, they can perform performance calculations and they may actually access the internet on the ground and in flight. 25:57.300 --> 26:01.500 And they may be able to receive one-way data from the avionics. 26:01.500 --> 26:05.540 They are also the most common EFB software type I have seen. 26:07.180 --> 26:13.520 It's worth mentioning that Class 1 and Class 2 EFBs are built by the operator. 26:13.520 --> 26:17.320 And as such, they are not the responsibility of the manufacturer. 26:17.700 --> 26:27.120 Even though they may provide some or all of the software that runs on the device, it is up to the operator to ensure that they are working securely. 26:27.700 --> 26:32.680 For EFBs running Type B software, this is where things can get a bit blurred. 26:33.020 --> 26:45.140 According to regulations, any vulnerabilities in the software that could affect the operation of EFB software, regardless of who coded it, is the responsibility of the operator to mitigate. 26:45.700 --> 26:55.680 At the same time, details of any vulnerabilities do not seem to be passed on to the operator, just a series of recommendations for EFB security. 26:56.340 --> 27:03.080 Now these recommendations are really good, but as we'll come on to later, I don't feel they go far enough. 27:04.820 --> 27:10.380 Type C applications can affect the control of the aircraft in flight. 27:10.820 --> 27:12.860 So this is the really juicy part. 27:13.460 --> 27:17.100 Essentially, they can send data to the avionics. 27:17.800 --> 27:30.220 However, at the moment of going to press with this presentation, there are no current approvals that exist for Type C applications that I am aware of. 27:30.280 --> 27:42.560 I have seen future offerings from some manufacturers about having a bi-directional connection between the EFB and the flight management system which sits in the avionics. 27:42.560 --> 27:47.860 However, I have not enough detail there to give you the information about it. 27:52.430 --> 27:59.010 As I touched on on a previous slide, regulators provide operators with cyber security recommendations. 27:59.310 --> 28:08.470 Recommendations are also given by the manufacturers, but I feel that even when you combine these two sources, this advice does not go far enough. 28:09.270 --> 28:14.750 By that, I mean that there is a lack of detail in what to consider and measures to take. 28:15.110 --> 28:25.450 When it comes to regulatory documentation, security appears to be the poor cousin, with the majority of the document dedicated for physical characteristics and user interface design. 28:26.550 --> 28:30.530 The wording is also quite willowy and lacking in detail. 28:30.570 --> 28:33.850 It is certainly an area where I think there is a lot of room for improvement. 28:36.840 --> 28:53.520 Also, because implementing EFB security is the responsibility of the operator, some manufacturers appear to use this as a green light for poor implementations of technology, which on their own would be considered zero security by design. 28:54.320 --> 29:05.020 Instead, the security is designed to be assured by the inherent assumption that the operator's networks will never be compromised, or that malware will never find its way onto an EFB. 29:05.020 --> 29:08.080 Kind of like passing the security hot potato. 29:10.080 --> 29:18.700 At the same time, operators are not directly informed of any vulnerabilities, instead given a set of recommendations to implement. 29:19.340 --> 29:26.720 Unless the operator discovers any weaknesses, they would be unaware of the risks involved. 29:27.220 --> 29:37.360 And if they were aware of the risks, I'm more than certain that they would have targeted controls to them based on what they knew. 29:40.690 --> 29:52.850 Overall though, the recommendations given by some manufacturers are pretty good, although I feel there could be more detail in certain areas. 29:53.350 --> 29:56.910 I would like to share the document names and references with you. 29:56.910 --> 30:02.790 However, I am heavily constrained by NDA, as well as manufacturer efforts to protect IP. 30:02.790 --> 30:09.990 So I'm not allowed to give you these names, even though doing so would be for the benefit of any operators watching. 30:13.860 --> 30:18.960 And I cannot move on without briefly talking about class three or integrated EFBs. 30:18.960 --> 30:32.900 And even though they don't form part of the AISD, there are some use cases here which 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:46.260 So to an operator, it may seem a very attractive prospect in terms of time and cost to get an EFB running. 30:46.760 --> 30:50.040 However, this category of EFB is not without its issues. 30:50.420 --> 30:56.100 And an example is an aircraft which I love, which is the Dreamliner. 30:56.560 --> 31:05.680 Having flown it many, many times, albeit not that long ago, I only started flying it about three years ago, I actually adore this aircraft. 31:05.680 --> 31:07.780 It is great to fly on as a passenger. 31:08.900 --> 31:23.520 But many Dreamliners have, especially the ones that first were brought to market, have Windows XP operating system integrated in the EFB which sits in the avionics. 31:24.100 --> 31:28.920 And this is a fact which gets a lot of surprise look from InterSec and IT professionals. 31:29.480 --> 31:30.640 But hang on. 31:31.620 --> 31:37.300 Remember, the 787 was designed in 2002-2003. 31:37.780 --> 31:42.500 Back then XP was king and would be for many years to come. 31:43.340 --> 31:46.960 The type approval and first flight for this aircraft was in 2009. 31:47.880 --> 31:50.900 Vista was available, but come on, Vista? 31:51.080 --> 31:52.620 Who would have changed? 31:53.360 --> 32:03.160 So when that aircraft was first went to market, it was delivered with EFP-EP4, developed using Windows XP. 32:04.740 --> 32:07.940 EP5 is available now, which uses Windows 10. 32:08.240 --> 32:22.000 However, not only do the upgrades come with a huge cost in terms of the units, but also a huge cost in terms of downtime and recertification of the avionics because it's a hardware change as well as a software change. 32:24.590 --> 32:31.650 So this kind of explains the issue of technical debt using more modern examples. 32:32.410 --> 32:45.890 Of course, we all think that an EFP on board a brand new modern state-of-the-art aircraft should be the most recent stable version of an operating system. 32:45.930 --> 32:59.350 But even in the timelines that we're talking about here, which are very small, we're seeing out-of-date operating systems being used in critical systems because of these timelines. 33:00.690 --> 33:03.070 And this issue is not limited to one manufacturer. 33:03.070 --> 33:11.070 I just brought up Boeing because of the knowledge I have of the BP-4, BP-5 versions and the operating systems. 33:11.490 --> 33:14.010 And it's not even limited to EFBs. 33:14.010 --> 33:15.610 It is all across the aircraft. 33:15.670 --> 33:17.890 I just wanted to discuss the technology trap. 33:17.890 --> 33:24.870 So those who may not fully understand why we see old tech in these brand new modern state-of-the-art aircraft. 33:26.390 --> 33:34.230 But it is interesting to think that the first Boeing 787s still have 20 years of life left in them or more. 33:35.410 --> 33:40.810 And when they come to end of life, will they still be running BP-4 with XP? 33:40.810 --> 33:42.670 I think some will. 33:42.670 --> 33:44.790 And we'll see. 33:44.910 --> 34:02.050 If Ken is still... Ken from Pentest Partners is still climbing around aircraft in breakers yards in 2040, then he may come across Windows XP inside the avionics, which will be a really, really cool thing to see him play with. 34:03.830 --> 34:10.590 But if you haven't seen their videos, they have some great walkthrough talkthroughs on 747s, which are going through the scrapyard today. 34:10.670 --> 34:21.330 And they also have older videos on their blog 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:32.250 Well, this is the other half. 34:32.250 --> 34:33.210 Ground systems. 34:33.690 --> 34:39.210 And they're used for keying and re-keying the PKI on the aircraft. 34:39.470 --> 34:47.150 They're used, like I said, for the key thing is the uploading of LSAPs and FLS to upgrade software modules on board the aircraft. 34:47.150 --> 34:49.550 A major, major time saver. 34:49.850 --> 34:56.830 But they also use for configuration changes, downloading of logs, and as a conduit for ESP connections. 34:57.490 --> 35:03.270 And this is done with some software provided by the manufacturer in a client-server relationship. 35:03.670 --> 35:13.390 The idea is that the operator would implement a Windows server, which runs the server software, and then the client would be installed on the engineer's laptop. 35:15.680 --> 35:24.360 The PKI on board the enabled aircraft is typically used to protect the VPN connection between the aircraft and the ground systems. 35:24.880 --> 35:28.900 It is also used to digitally sign the software that gets uploaded. 35:28.900 --> 35:34.120 So integrity checks can be done before it is installed in the aircraft. 35:35.140 --> 35:40.900 And this is one area that manufacturers seem to have gotten right with the latest enabled aircraft. 35:41.000 --> 35:43.280 At least the two main manufacturers in the world. 35:44.300 --> 35:53.880 While I do not have a PhD in cryptography, or anything higher than a BSc in any subject for that matter, the PKI implementations I have seen are simply excellent. 35:54.140 --> 35:56.940 And that shows the manufacturers are learning from previous issues. 35:56.940 --> 35:58.360 And that's great to see. 36:02.290 --> 36:09.330 As well as EFBs, I think ground systems require special consideration when it comes to security control implementation. 36:11.010 --> 36:15.350 The E-enabled aircraft being sold on the market today are truly excellent. 36:15.670 --> 36:22.910 Whether you're a pilot or a passenger, they are fantastic creations and a true credit to the teams involved in their development and manufacture. 36:23.130 --> 36:27.310 However, the same cannot be said of some of the supporting software. 36:28.090 --> 36:39.510 Some of the software distributed with modern aircraft is quite old, and they were likely coded at a time when there was very little consideration given to secure DevOps, or even cybersecurity at all. 36:40.290 --> 36:44.910 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 --> 36:58.370 However, I'm seeing positive movements in this area. 36:58.810 --> 37:10.990 There are new versions of EFB and ground system software being developed today, which should be available in a few years' time, 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:25.900 As with EFB software, how many operators have looked at the ground system software from an attacker's perspective? 37:26.640 --> 37:28.320 Have they looked for weaknesses? 37:28.640 --> 37:34.500 Have they found any, and then combined this with the threat model and overlaid on the existing network architecture? 37:34.940 --> 37:42.260 Remember, like I said, a lot of airline networks have any, if at all, any segregation. 37:42.660 --> 37:50.480 So if the corporate network was compromised, could someone pivot into the ground systems and put your aircraft at risk? 37:51.480 --> 38:07.300 Also, conversely, could this software, at any weaknesses you identify, introduce new attack vectors or vulnerabilities in your systems, which could then be used to pivot into the corporate network? 38:07.380 --> 38:10.940 These are things that operators really need to consider and look at. 38:12.520 --> 38:20.760 Now, I have seen some manufacturers and third parties offer ground systems, a ground system service hosted in the cloud. 38:21.280 --> 38:35.340 And now, while I understand moving to the cloud is not the silver side of the bullet for any organization, although some seem to think it is, from my experience, these cloud solutions are normally put together very well from a security perspective. 38:36.300 --> 38:41.440 They also permit creative design in methods to mitigate weaknesses in the software. 38:41.920 --> 39:05.680 So, for example, if you had issues with the client software that would sit on the engineer's laptop, and you didn't want that interaction with the server going across the network, then what you could look at is putting both the server and the clients in separate lockdown enclaves inside a cloud solution, 39:05.680 --> 39:12.360 then implement a VDI to host the client's interface through a secure HTML5 web front end. 39:12.360 --> 39:22.680 And that gives you lots of opportunities to customize the security according to your threats and risks, and all sorts of other opportunities as well. 39:22.980 --> 39:34.960 So, these are certainly ideas that we're looking at, because the software that's available today doesn't seem to be that good, but some of the cloud's offerings are. 39:38.540 --> 39:39.920 Flight attendant panels. 39:39.920 --> 39:44.700 So, these are interesting from a cyber perspective. 39:44.700 --> 39:54.540 So, anyone that deals with industrial control systems will know that these are essentially what's known as a HMI, a human-machine interface. 39:54.660 --> 40:06.180 And these are used for lighting, air control, announcements, door status, lighting, emergency buttons, and they might also have bespoke features that the airline will implement. 40:06.840 --> 40:22.430 They can also be used for maintenance and for uploading FLS, LSAPs, and for downloading logs if the maintenance port is unavailable. 40:24.110 --> 40:27.780 So, why do FAPs have a security focus? 40:27.780 --> 40:38.340 Well, like any HMI, especially those ICS implementations, they're typically an easy target, especially those with a USB port. 40:40.820 --> 40:55.660 I did some research on FAPs, and while some are directly connected to both the AISD and the PIESD in e-enabled aircraft, there are none which have a connection to the ACD or avionics anymore. 40:56.820 --> 40:58.860 Not that I can see anyway. 40:58.860 --> 41:10.440 That said, I did raise concern about the possibility of a passenger inserting a USB stick loaded with malware into the FAP USB port, and what that would mean. 41:12.160 --> 41:25.560 So, the team I was in started asking the manufacturer some very probing questions, and to their credit, the manufacturer provided a highly detailed and impressive response, and it was actually done in person due to the sensitivity of the content. 41:25.660 --> 41:31.580 But what they showed us were that the technical controls to protect the ACD from the FAP were very robust. 41:32.420 --> 41:40.480 However, when asked the further questions, it seemed that the AISD was considered almost expendable in the malware onboard scenario. 41:41.160 --> 41:55.700 When asked about that, the response was that the AISD can be entirely functioning and it will not affect the airworthiness, which can be interpreted as the AISD can be riddled with malware, and the aircraft can still be operated legally. 41:56.800 --> 41:57.860 Fine, I thought. 41:57.860 --> 42:10.020 However, that got me thinking to the operational side, and I wondered how many pilots, knowing that an aircraft is infected with malware, yet still legal to fly, would actually fly it. 42:10.940 --> 42:19.560 What if, as an attacker, my goal was not to take control of the aircraft, but to affect the operations of an airline as a coordinated extortion or blackmail attack? 42:22.640 --> 42:34.020 Now, everyone in industry knows, regardless of the airline, that this USB port is off-limits, even to crew. 42:34.840 --> 42:41.080 Yet, I have spoken to Cabot crew from multiple airlines, and they have confirmed that they are told this in training. 42:41.180 --> 42:51.800 However, everyone in the industry also knows that this port is used extensively to charge crew devices, both official and personal, in spite of the rules. 42:52.360 --> 43:02.320 I have also seen passenger devices being charged in the FAP as the USB port in their seat wasn't working, and it was actually the crew who had done this as a courtesy to the passenger. 43:03.660 --> 43:11.780 So, what is clear from this is that, while people know there is a risk, it is clear the awareness training isn't working. 43:12.000 --> 43:13.480 Not all the time, anyway. 43:16.620 --> 43:35.440 I thought it important to also include some detail on some of the more general issues I have found, and I must state again, I am heavily bound by NDA, but I have reached out for advice and agreed parameters of what I can divulge here prior to this talk. 43:37.160 --> 43:51.860 So, one team I was in had been working on the security design of their ESDs, and we had planned project milestones to ensure that build documentation was accurate, and the device was built according to design. 43:52.360 --> 43:56.420 A lot of work had gone into locking the operating system down. 43:56.420 --> 44:02.040 It was Windows-based, and this is where I had a lot of extensive experience and knowledge. 44:02.060 --> 44:04.220 So, this is where I focused my attention. 44:05.180 --> 44:12.280 I knew that we had a pen tester who was going to look at it from the perspective of an ass hacker, and oversee my work, so I left the software alone. 44:12.860 --> 44:15.500 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:36.520 When it came to the pen test, I knew the build was solid, so I was surprised when on day two of the test, day two of the five-day test, Andrew, the pen tester, called. 44:37.180 --> 44:45.700 Now, anyone that deals with pen tests know that if they call you prior to the planned end date and it isn't a question, then it's bad juju. 44:46.840 --> 44:57.780 Andrew had not only found an API that was completely unprotected, there was no authentication, there was no encryption, but had written some code, but also written some code to exploit it. 45:00.820 --> 45:09.500 I was quite shocked, so I sent a message to the manufacturer straight away, and received a response that this was not a vulnerability, but in fact a feature. 45:13.890 --> 45:21.030 All I can say is that when I repeated this response to my colleagues, jaws across the room dropped to the floor. 45:21.990 --> 45:27.250 I took a step back and realized that in order to make the manufacturer understand, I had to do more analysis. 45:27.970 --> 45:35.010 Now, back when I was in the British 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:52.750 At the end, it would not have taken much to turn that resulting code into a very feasible malware for EFBs. 45:53.450 --> 46:00.050 I spoke with flight operations, pilots, and InfoSec, and demonstrated the rather trivial attack. 46:00.330 --> 46:03.030 Everyone I spoke to agreed that this was bad. 46:05.600 --> 46:20.860 So, despite this feedback, which included a dossier of potential outcomes which I had compiled from pilots and operations feedback, the only action taken by the manufacturer was to reduce the attack surface. 46:21.920 --> 46:29.160 They replied, in their opinion, the scenarios I had described were not feasible, and the whole vulnerability was dismissed. 46:29.560 --> 46:36.900 Now, it wasn't like I was proposing aliens would come down and attack planet Earth, although 2020 isn't over yet. 46:37.020 --> 46:41.080 One threat which they dismissed as unrealistic was the insider threat. 46:42.340 --> 46:55.280 Now, I found that really strange because this threat was on the operator's risk register, and I had been asked specifically to consider this threat when giving my updates to high-level security boards. 46:58.440 --> 47:15.840 Consequently, sometime later, however, I was informed that the software in question was going through a complete lifecycle upgrade, and that the project would include not just a secure DevOps approach, but security milestones with qualifiers as well. 47:16.480 --> 47:37.600 Now, I cannot take full credit for that change because I know that somebody had moved into a new role covering the security of such software, which means that they had already knew that there were issues, and that they were moving to close the gap when I had spoken about this issue with the API. 47:37.600 --> 47:42.640 And I know this person from my dealings with the manufacturer, and I'm very confident he will do good work. 47:46.130 --> 47:52.830 Further investigations I've made on other aircraft have uncovered examples of the same unprotected API. 47:52.830 --> 47:55.730 Different APIs, but unprotected all the same. 47:55.870 --> 48:04.710 And these are inside the AISD, so they are accessible from the EFB, they're accessible from other systems on board. 48:05.490 --> 48:15.230 And despite going through the responsible disclosure route as an independent researcher, I was not only dismissed for making unrealistic assumptions, but I had to fight for updates. 48:16.330 --> 48:25.410 Now, the assumption I made was based on a proposed commercial offering from the manufacturer, coupled with their own API documentation, detailing how it would work. 48:26.990 --> 48:29.450 Yet it was still considered unrealistic. 48:29.790 --> 48:39.510 Now, they may have made a separate assessment themselves, and started going down a different, more secure pathway for the release of this new functionality, which would be great. 48:39.510 --> 48:44.570 But I was not made privy to the details, so I have to say that for now, I don't know. 48:44.870 --> 48:47.910 If I do find out more, I will certainly update you. 48:49.910 --> 49:00.630 So hopefully that has given you a sufficient introduction into a network domain that is often overlooked by security researchers, but which has a lot of juicy issues that need to be addressed. 49:01.030 --> 49:09.310 Like I said, attacks on the avionics are really interesting, but getting access to them to exploit vulnerabilities is pretty difficult. 49:10.330 --> 49:17.130 While the AISD may not be as sexy or interesting on the surface, when you scratch a bit deeper, there's a lot to decipher. 49:18.890 --> 49:25.290 Touchpoints, while still quite difficult to exploit, are more accessible, considered more traditional to an attacker. 49:25.470 --> 49:35.810 And this means everyone from cabin crew, to engineers, flight ops, and infrasec, all have an important role to play 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:55.770 Now, so I'm not talking about FLS and LSAPs here, what I'm talking about 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:09.430 What is more worrying for me is that this software will achieve some kind of approval, in spite of these weaknesses. 50:11.190 --> 50:17.150 So don't assume because they have approvals that they are 100% secure. 50:18.430 --> 50:29.890 Make sure you perform some kind of assurance on software and systems, either using your internal teams, or if you don't have the skills in-house, hire an external expert or pen tester. 50:30.050 --> 50:42.250 It may be costly, but having an aircraft AOG for several weeks while you investigate a cyber attack, and have to replace all the onboard FLS or LSAPs, could probably cost you a lot more. 50:45.130 --> 50:48.870 Security in the operations is not the realm of one department alone. 50:49.350 --> 50:57.750 The multiple business areas that make up the operations require that InfoSec understand aviation and what cyber risks actually mean to aircraft. 50:58.610 --> 51:04.410 InfoSec also need to make sure that engineers and other business areas understand the risk context. 51:05.130 --> 51:07.110 It is a two-way street. 51:07.610 --> 51:13.410 I've seen that some operators have implemented a multi-discipline groupings, which handle these challenges. 51:14.430 --> 51:20.990 They're often called a cyber computer cell, which is a really cool name to have on your CV, just a little hint there. 51:22.730 --> 51:34.950 So these groupings often have at least one board member, and they combine knowledge and experience from multiple departments, and they ensure that issues are tackled in the best possible way for the business. 51:35.210 --> 51:45.450 From what I hear, they are extremely effective, and I would certainly recommend that you, if you don't have one already implemented in your business, and you operate a unit of aircraft, that you certainly look into it. 51:46.910 --> 51:51.430 And I suppose it finally goes without saying that you must involve your regulators as much as you can. 51:51.830 --> 52:00.630 They have access to the right people, the information, and the frameworks, with the right advice and the right guidance to guide you through difficult scenarios. 52:01.130 --> 52:04.350 So make sure you engage them as much as you can. 52:04.410 --> 52:10.430 And if you don't get satisfactory results from your regulators, sure, pop me a line. 52:10.430 --> 52:12.130 I can certainly help where I can. 52:12.830 --> 52:15.810 But finally, I'll sign off with a small piece of advice for operators. 52:16.630 --> 52:28.170 If you have someone in your organization who is as effective and competent an engineer as they are with InfoSec and cybersecurity, my advice would be to make sure that person never leaves your business. 52:28.170 --> 52:29.530 I'm not an engineer. 52:29.530 --> 52:44.610 I was lucky I had access to excellent engineers who were able to communicate to me exactly what the problems were, and to better understand systems so I could evaluate the risk. 52:45.810 --> 52:54.450 At the same time, these engineers were... they have a high level of intelligence engineers, so they could understand what I was telling them. 52:54.570 --> 52:55.950 And together we worked really well. 52:55.950 --> 53:00.610 But if you can incorporate that into one person, that's a very valuable asset indeed. 53:02.950 --> 53:04.710 So that's the end of your presentation. 53:04.710 --> 53:09.090 Hopefully that's enough information to whet your appetites in the AISD. 53:09.090 --> 53:10.650 There is a lot more there. 53:10.650 --> 53:12.890 I have to cram it into 50 minutes. 53:13.390 --> 53:19.970 So I will be available for questions in a session in the Discord channel from where you linked to this presentation. 53:20.370 --> 53:22.450 Please head over there and join in the discussion. 53:22.750 --> 53:25.470 Alternatively, you can grab me on Twitter or my website. 53:25.470 --> 53:27.970 There's an email link you can get on me. 53:27.970 --> 53:30.690 And I hope to speak to you all soon. 53:30.930 --> 53:31.610 Take care.