[00:04.970 --> 00:10.270]  I'm Aaron Grelias. I'm a security researcher with Grimm. I'm on the cyber physical systems team.
[00:10.270 --> 00:17.870]  We work on improving the security of embedded devices everywhere. I've also got a background,
[00:18.570 --> 00:23.510]  a long background in embedded software development on critical systems,
[00:23.510 --> 00:29.310]  the telecom, aerospace, medical, and a bunch of different fields.
[00:30.550 --> 00:35.730]  My name is Tim Brown. I run the cyber physical systems team here at Grimm. I've been at Grimm
[00:35.730 --> 00:41.150]  for about five years now, hacking all sorts of different types of embedded systems from
[00:41.150 --> 00:45.230]  aerospace to automotive, heavy trucking, medical.
[00:46.710 --> 00:52.510]  And we're here today to talk about some of where cybersecurity meets aviation regulations.
[01:05.510 --> 01:10.890]  I'm going to start by talking about the current status of cybersecurity regulation.
[01:10.890 --> 01:16.570]  And more how software development happens in aerospace.
[01:18.270 --> 01:25.510]  The current process that we have descends from the, historically, how airlines have
[01:25.510 --> 01:31.650]  approached the topic of safety. Airlines have approached the topic of safety,
[01:31.650 --> 01:38.370]  usually, historically, from a purely mechanical standpoint. This part will last for about this
[01:38.370 --> 01:43.090]  long in airplanes. It has to be replaced every so often. There's maintenance procedures and
[01:43.990 --> 01:48.010]  airworthiness directives that talk about how often these parts need to be replaced based on
[01:48.010 --> 01:54.330]  how long it takes them to fail. There's things that they test, like anywhere you have stresses
[01:54.330 --> 01:59.890]  on a metal joint, you'll have testing done, both visual inspection and other types of testing,
[01:59.890 --> 02:04.150]  depending on circumstances, to see if it's starting to fail, if it's starting to get
[02:04.150 --> 02:10.650]  cracks forming in those areas. But it's really designed around this concept that
[02:11.330 --> 02:18.630]  once you make a part, it behaves in some sort of defined way that doesn't change. Once you design
[02:18.630 --> 02:24.370]  it, do all your fairly rigorous testing that they do in the airline, the aerospace industry,
[02:24.370 --> 02:29.750]  and install it, it will change in ways that are defined, essentially, by the physics of the
[02:29.750 --> 02:37.430]  situation. Stresses on metal, opening and closings of latches, and stuff like that,
[02:37.430 --> 02:43.770]  that have a defined physical characteristic. And you can define maintenance procedures that will
[02:43.770 --> 02:49.350]  detect all of these potential issues on the airplane. Maintenance procedures are defined
[02:49.350 --> 02:54.270]  to replace things that need to be replaced periodically. These maintenance procedures
[02:54.270 --> 03:03.190]  you can follow in the commercial aerospace world will be followed. They rely on that happening,
[03:03.190 --> 03:10.250]  that does happen. And they do it in places like this. They have drawers that have
[03:10.250 --> 03:17.970]  labeled places for every bit, every socket, every tool. It's access controlled. So you know that
[03:17.970 --> 03:23.490]  when you do your maintenance procedure, there's a procedure for using this size socket to remove
[03:23.490 --> 03:28.550]  these bolts and you put it back when you're done. So you don't wind up leaving a socket in an
[03:28.550 --> 03:34.310]  airplane. They have these fairly strictly defined procedures that you follow in order to make sure
[03:34.310 --> 03:45.430]  that all these maintenance is done correctly and done completely. So that's the kind of history
[03:45.430 --> 03:52.550]  of where we came from. As far as the current regulations that drive the software development
[03:52.550 --> 03:58.370]  process for modern aviation software, that's regulated at least in this country and many
[03:58.870 --> 04:05.930]  other ones by something called DO-178C. We're not going to go into this too deeply, but
[04:07.390 --> 04:13.970]  knowing how things work right now and how levels of safety are defined will help us think about
[04:13.970 --> 04:21.510]  cybersecurity and how to go forward with that. This is developed by RTCA. It stands for Radio
[04:21.510 --> 04:27.530]  Technical Commissions for Aeronautics, which I never actually knew until I looked that up.
[04:27.530 --> 04:31.850]  It's not super important. It's just an organization that develops a bunch of aviation standards.
[04:34.350 --> 04:41.190]  And again, these are adopted by FAA in the United States, Transport Canada, and European Aviation
[04:41.190 --> 04:51.110]  Safety Agency, EASA. So what is DO-178C? I like to summarize it this way. You basically tell
[04:51.110 --> 04:58.490]  the FAA... well, a DER is the designated representative that stands in for the FAA.
[04:58.490 --> 05:06.050]  Tell them how you plan on designing, creating, and testing your software. And then you go and
[05:06.050 --> 05:09.870]  follow your plan and do those things. And then you have to prove that you followed your plan.
[05:09.870 --> 05:16.050]  That's it in a nutshell. Now there's a lot more paperwork involved. There's a lot of checklists
[05:16.050 --> 05:21.090]  you do have to go through and make sure that your plan actually does identify all the areas of
[05:21.090 --> 05:29.870]  concern that DO-178C points out. And if the DER thinks that anything is lacking in your plan,
[05:29.870 --> 05:35.850]  they will tell you and help you make sure that it gets revised appropriately.
[05:36.010 --> 05:41.090]  That's the way things go forward right now. And as you can see, it's kind of a very
[05:41.090 --> 05:47.550]  waterfall-y based model where you do all your design up front, you create a design,
[05:47.550 --> 05:53.130]  you create a spec, the actual product that implements the design, then you do testing on it
[05:53.130 --> 06:02.350]  in order to make sure that the product design actually meets the requirements that
[06:02.350 --> 06:10.050]  the product was supposed to fulfill. That is a good point. The way this does work in practice,
[06:10.050 --> 06:16.110]  it is extremely waterfall. There have been attempts to try and figure out how to fit
[06:16.110 --> 06:23.210]  Agile methods into this, but it is very much plan, do, prove. Just pretty much in those steps.
[06:23.450 --> 06:28.530]  And this again comes from that historical background of making mostly mechanical
[06:28.530 --> 06:34.330]  components where that is how you design them. You don't do iterative development on,
[06:35.150 --> 06:39.970]  you know, a weight usually. I mean, if there's issues, you'll go back and fix them of course,
[06:39.970 --> 06:43.730]  but like you don't really do, you know, there is no fail fast on making a lot of these
[06:43.730 --> 06:48.730]  mechanical components. So it's trying to shoehorn software development
[06:49.250 --> 06:54.150]  into how they make mechanical components for these aircraft.
[06:54.370 --> 06:58.330]  And as anybody who's been in software development for a while knows that
[06:58.330 --> 07:06.650]  waterfall has been around for a long time. The DO-178C categorizes different levels of software
[07:07.330 --> 07:12.230]  according to the potential consequences of a failure of that software.
[07:13.090 --> 07:19.150]  So levels A through E, and basically A means that something catastrophic would happen
[07:19.150 --> 07:26.670]  if it fails. Level E means that nothing is going to happen safety wise, you know,
[07:26.670 --> 07:32.790]  maybe the passengers can't watch movies, right? That would be a level E software.
[07:33.530 --> 07:37.950]  The level A is also the highest cost. This is probably unsurprising.
[07:41.230 --> 07:47.990]  The last numbers I can find show that it's estimated to be about $100 per line of code
[07:47.990 --> 07:55.310]  for level A software. They're not all software on an airplane is level A. It's usually just as
[07:55.310 --> 08:00.970]  small percentage as possible because of the cost. But Boeing 787, for example,
[08:00.970 --> 08:06.490]  is estimated to have between 6 and 7 million lines of code. So even if it's a small percentage,
[08:06.490 --> 08:12.610]  just the level of certification alone of the software drives a great deal of cost.
[08:13.470 --> 08:18.950]  Basically, these go from different levels. So level A, catastrophic software, usually
[08:18.950 --> 08:25.530]  software that is level A rated will have autonomous control, which means that there's
[08:25.530 --> 08:32.430]  no way to intervene if something fails, hence why it's so expensive and so time consuming to develop.
[08:32.430 --> 08:38.350]  Then they go on both. Level B would be something where something hazardous could happen,
[08:38.350 --> 08:45.310]  but also level B will typically allow for pilot intervention. So it might be something that
[08:46.150 --> 08:50.650]  significantly increases the workload or the challenge of flying the aircraft,
[08:50.650 --> 08:56.250]  but it would be something that can be addressed by the pilot training.
[08:56.250 --> 09:03.830]  Level A and B is usually loss of life. A level A failure was likely to lead to loss of life.
[09:03.830 --> 09:10.450]  Level B failure is not likely to lead to loss of life or severe injury.
[09:11.030 --> 09:15.330]  Injury sustained in a level B failure should be minimal.
[09:17.130 --> 09:24.390]  And then it goes on down from there. C and D are major minor impacts to the flight of the aircraft.
[09:27.750 --> 09:32.950]  Also, so entertainment systems are going to be level E, means that there's
[09:33.530 --> 09:39.490]  lower, less regulations and less checklists, essentially. As you go down in level,
[09:39.490 --> 09:43.630]  you have to do less to prove in that proof step.
[09:47.100 --> 09:54.360]  In DO-178C, code is expensive. So stuff, especially if it's a level B or level A,
[09:54.360 --> 10:02.080]  very unlikely to have unused code in it or unnecessary code in it, like a shell onto a
[10:02.080 --> 10:17.280]  system. DO-178A, you're not allowed to have dead code in your design on the system.
[10:17.280 --> 10:21.540]  Because it's so expensive to develop the code, there's usually a minimal amount of code
[10:21.540 --> 10:28.640]  on these systems. There is extensive testing done for the higher certification levels.
[10:28.640 --> 10:35.600]  There's at least a significant quantity of testing done. Pilot training on how to use the software
[10:37.180 --> 10:42.040]  is... the systems are designed for redundancy and safety. So if you do have a failure,
[10:42.040 --> 10:48.600]  there should be a redundant system to back up that failure. Unless you have a 737 MAX,
[10:48.600 --> 10:56.120]  we won't talk about that right now. Very limited interfaces on these flight-critical systems.
[10:56.220 --> 11:03.200]  They use interfaces like RN429. RN429 is a UART-style bus. You're limited to sending
[11:04.120 --> 11:10.420]  32 bits of data at a time. There's not really room for buffer overflow here. You don't really
[11:10.420 --> 11:18.180]  have longer messages on top of RN429. These interfaces are very strictly defined and fairly
[11:18.600 --> 11:22.920]  provide very limited functionality beyond just sending the necessary critical data
[11:22.920 --> 11:29.320]  back and forth on the bus. There's a great deal of emphasis on determinism and reliability.
[11:34.300 --> 11:44.320]  So there's some bad things related to the current way software is defined and designed
[11:44.960 --> 11:51.560]  in aerospace. This is kind of... so as I said, you know, as we said, both Tim and I have worked
[11:51.560 --> 11:58.320]  in aerospace kind of on the development side of things and also on the cybersecurity testing side
[11:58.320 --> 12:06.000]  of things. The things that... I found many things frustrating when I was doing on the development
[12:06.000 --> 12:13.120]  side of things. This is kind of the... a piece of that list right here. Data validation is guarding
[12:13.120 --> 12:22.140]  against accidental data modification. The design of how software is made to be robust in aviation
[12:22.140 --> 12:31.220]  systems is guarding against like cosmic rate bit flips, single event upsets. So simple methods like
[12:31.220 --> 12:37.840]  CRCs and checksums are sufficient. And also the software that runs it is typically slower and
[12:37.840 --> 12:46.360]  older, more reliable, and therefore modern data validation methods are... can be very time consuming
[12:46.360 --> 12:52.320]  for those... for the hardware involved. There's very little code to guard against unexpected scenarios.
[12:52.320 --> 13:00.140]  If you don't... if it's... if every single line of code costs a hundred dollars approximately,
[13:00.140 --> 13:06.810]  probably more nowadays than it was when I found that statistic, then you're not going to have a
[13:06.810 --> 13:12.870]  code for guarding against things that the system designers say won't happen. In fact, as Tim says,
[13:12.870 --> 13:18.790]  dead code, code that is never expected to be executed, is not allowed in DO-178C.
[13:20.470 --> 13:25.130]  The... there's a lot of complacency. Because of the level of tests involved, because of the amount
[13:25.130 --> 13:31.410]  of work that goes into designing the software, there's a lot of point of view in the industry
[13:31.410 --> 13:38.430]  that the way we do things, the redundancies that we design into the system, protect us from bad
[13:38.430 --> 13:45.690]  things. And it protects against single event upsets. It doesn't protect against determined
[13:45.690 --> 13:54.790]  and directed attacks. One thing... one piece of software I was working on a while ago had a... just
[13:55.050 --> 14:01.110]  a straight-up buffer overflow attack against it. And I had to fight fairly hard to actually get it
[14:01.110 --> 14:09.010]  fixed, because the incoming data that hit that function with the buffer overflow could only come
[14:09.010 --> 14:16.350]  from a trusted source that would never send more than such amount of data. And if there was some
[14:16.350 --> 14:21.610]  sort of, like Aaron says, a single event upset, a sort of random bit flip that caused the length
[14:21.610 --> 14:27.310]  field to be longer than it was supposed to be, there's a CRC check that would have failed, and
[14:27.310 --> 14:31.390]  wouldn't have even processed the data at all. So they felt that they were completely protected
[14:31.390 --> 14:38.530]  against this scenario, because they just don't have this concept of an adversarial attacker with
[14:38.530 --> 14:44.750]  knowledge of the system being able to get data into this function. They believe that the only
[14:44.750 --> 14:51.630]  way for data to get into this function is from a source that they trust to not send data that's
[14:51.630 --> 14:57.830]  going to cause a buffer overflow. So Tim's kind of jumping ahead there. That last bullet point on
[14:57.830 --> 15:03.550]  this one is software is only tested against expected flight configurations. So you will only
[15:03.550 --> 15:08.570]  say, here's, you know, this is what we're going to do for this flight, and that's what we're testing,
[15:08.570 --> 15:13.670]  because testing is expensive. There's a lot of tests that are performed as part of this software
[15:13.670 --> 15:19.450]  certification process. You don't want to run more than necessary. What that means, though, is that
[15:20.230 --> 15:26.210]  software, aviation software, while robust in flight configurations, can be extremely brittle
[15:26.970 --> 15:33.510]  when it is put into conditions that it is not, that are not expected to happen.
[15:34.410 --> 15:38.510]  Some other things here, ground maintenance devices, so things that actually program
[15:38.510 --> 15:46.110]  the different flight devices, those are not D1C rated, because they're not flying, right?
[15:46.110 --> 15:50.830]  They just stay on the ground while the airplane flies. They're covered under some different
[15:50.830 --> 15:55.910]  guidelines about tool development, but you don't have to go, they're not even
[15:55.910 --> 16:02.410]  leveling certified, it's something different. Maintenance software, so on each box, there's
[16:02.410 --> 16:08.810]  typically a component that will help reprogram that device. That's considered to be deactivated,
[16:08.810 --> 16:15.610]  because when the airplane is in flight, you have a signal that says, are we, are the wheels on the
[16:15.610 --> 16:22.070]  ground or not? Sometimes it's called weight on wheels, sometimes it's called weight off wheels. Make sure you read your documentation very carefully.
[16:23.430 --> 16:33.890]  And whatever signal that is, indicates if the, that signal is then used in the startup process
[16:33.890 --> 16:39.290]  to make sure that the reprogramming software, that component, doesn't run. So this is considered to be
[16:39.290 --> 16:44.790]  deactivated. There's also frequently a physical switch on the piece of hardware they have to
[16:44.790 --> 16:50.570]  switch into some sort of boot mode, maintenance mode, programming mode. So you have to not only
[16:50.570 --> 16:55.950]  have the weight on wheels signal, but you also have to have this switch set in the
[16:56.710 --> 17:03.510]  activated position to boot the piece of hardware into the maintenance mode. And then the plane
[17:03.510 --> 17:09.010]  won't fly if that piece of hardware is in its maintenance mode or programming mode. You have to
[17:09.010 --> 17:14.430]  switch it back to flight mode before the plane will take off. Right, and it'll be like programmed
[17:14.430 --> 17:19.650]  sometimes that are built into the wiring harnesses themselves. So when you plug in the harness for
[17:20.270 --> 17:25.670]  reprogramming a box, that thing has a wire jumper in it that forces this type of mode.
[17:30.090 --> 17:36.830]  So there are some current cybersecurity documents out there, DO-326, which
[17:41.550 --> 17:53.550]  DO-326, which outlines the activities that should take place at a system and airframe
[17:53.550 --> 17:59.610]  levels. These are the type of security activities that you should do if you're developing either a
[17:59.610 --> 18:05.410]  system for an airplane or developing the entire airplane. These are the various testing activities
[18:05.410 --> 18:12.830]  and testing documents that you should create and how to create them. DO-356 goes a little bit more
[18:12.830 --> 18:20.070]  into the nuts and bolts of what testing should look like. Something I like about DO-356 is DO-356
[18:20.070 --> 18:27.390]  does make provisions for the more ad hoc pentest style testing that hackers tend to do. You know,
[18:27.390 --> 18:34.610]  the adversarial feeling around trying to see, you know, scan different systems, trying to find some
[18:34.610 --> 18:40.310]  way and some chink in the armor that you can then exploit into the system. This is a testing that's
[18:41.010 --> 18:47.470]  much... most testing that you see, especially the DO-178C type testing, is extremely formalized.
[18:47.470 --> 18:52.390]  Every test procedure is written down. You do this set of procedures. This is your test.
[18:52.390 --> 18:57.170]  That's going to... there's conditions to pass. There's conditions for... and if they don't meet
[18:57.170 --> 19:03.350]  the passing conditions, the test failed. DO-356 does provide those provisions for the more ad hoc
[19:03.350 --> 19:08.450]  style testing that can be much more useful for security testing. Provisions for things like
[19:08.450 --> 19:14.850]  fuzzing, which doesn't really have an analog in like DO-178C, but you can't really formalize a
[19:14.850 --> 19:25.450]  fuzzing procedure. So that's where we are right now. We've got some concerns with the current
[19:26.330 --> 19:32.990]  way aviation software is currently defined. What do we do? So what do we do about that? Well,
[19:32.990 --> 19:41.050]  Tim and I have a plan. First, you know, as with anything, we've got to figure out what our actual
[19:41.050 --> 19:47.830]  goals are for how to... what needs to be secured, what devices need to be secured, and come up with
[19:47.830 --> 19:52.010]  some examples, come up with some measures that we can use to reach those goals. It's all very well
[19:52.010 --> 19:58.610]  and good to say secure the system, but if you don't actually tell people how to go about doing that,
[19:58.610 --> 20:05.030]  you're going to end up with a large number of ways to do that, some of which may not be very effective.
[20:08.320 --> 20:16.120]  So the problem is up front here, everything is hackable, right? Give some... give enough access,
[20:16.120 --> 20:21.720]  motivation, time, and money. You can get into any type of device. You give us a piece of hardware,
[20:21.720 --> 20:27.660]  and we can get into it. There's a lot of measures you can use to make it more difficult,
[20:28.220 --> 20:36.240]  but depend... with a large enough playground, you can get into anything you want.
[20:42.270 --> 20:50.570]  So for goals here, we... so for goals here, we need to assume that attacker has all the necessary
[20:50.570 --> 20:55.650]  information and resources to do what they want to. If we're going to... if we're going to design
[20:56.450 --> 21:01.890]  an aircraft to be secure, we need to start from the assumption that the adversary knows
[21:01.890 --> 21:09.850]  what they need to know to get into it. We need to make sure that we have some way to prove beyond
[21:10.990 --> 21:18.850]  the most up-to-date way to prove that the software on a particular component is 100% correct. If you
[21:18.850 --> 21:26.210]  cannot prove that, then it's going to be impossible to figure out how to get to secure an aircraft.
[21:28.230 --> 21:33.790]  We need to prevent accidental transmission of something malicious. If you know that everything
[21:33.790 --> 21:38.030]  is secure at some point in time, you need to, you know, protect it from going forward,
[21:38.030 --> 21:42.250]  and then put multiple barriers in place also to all these different components.
[21:42.970 --> 21:49.850]  We know that given enough time and money and so on, anybody can get into a device if they want to.
[21:49.850 --> 21:58.050]  But it is possible to figure out how to prevent, make an attack practically impossible
[21:58.730 --> 22:03.290]  if you limit some of those things. So if you know when an airplane is on the ground,
[22:03.290 --> 22:08.710]  that it has all of the correct software and configurations in all of the different parts
[22:08.710 --> 22:14.710]  that are on the aircraft, then an attacker would have a limited time frame of the actual flight
[22:14.710 --> 22:20.350]  itself to perform an attack. So that's what we're aiming for.
[22:20.650 --> 22:31.470]  And also aiming to get the idea into aviation that a software component can go from good
[22:31.760 --> 22:39.350]  to bad very quickly. Just one exploit and all of a sudden this device that was working completely
[22:39.350 --> 22:45.650]  fine is now no longer working completely fine. And it's not based on some statistical
[22:46.610 --> 22:51.510]  degradation over time. Now that can just go be good and then be bad.
[22:55.910 --> 23:03.130]  So to define what is important to secure, here's my list. We have things that are important for
[23:03.130 --> 23:07.890]  flying an aircraft. And then we have things that are not important for flying the aircraft.
[23:07.890 --> 23:17.470]  These are two device categories. The level D-178C defines five different levels
[23:20.470 --> 23:25.370]  to how critical software is and the consequences of failures here.
[23:25.530 --> 23:31.450]  For us, there's really only two categories, important or not. Because if you leave something
[23:31.450 --> 23:36.790]  that has partial measures in place on the aircraft, then that is a potential point that
[23:36.790 --> 23:41.250]  an attacker could use to pivot to other parts of the aircraft.
[23:48.730 --> 23:54.570]  So flight devices are any component that's used to operate the aircraft.
[23:55.310 --> 24:01.450]  Any or any device that communicates with those components. We've seen instances where you have,
[24:01.450 --> 24:07.930]  you may have a level E hardware device that communicates in some way with even a level A
[24:07.930 --> 24:14.110]  hardware device. And this is allowed because that communication has been
[24:14.110 --> 24:19.690]  strictly defined and tested on the piece of hardware, the level A software, to make sure
[24:19.690 --> 24:27.910]  that it should reject any bad inputs with oftentimes not very robust checking on what
[24:27.910 --> 24:35.890]  these bad inputs actually are. But from a security context, anywhere that you can touch something
[24:35.890 --> 24:43.210]  important from, also needs to be secured. Because if you can, you know, have a lower functional,
[24:43.210 --> 24:47.650]  lower functioning device, lower classification, lower DO1s, then you see a DAL classification
[24:47.650 --> 24:55.130]  device that can maybe in some way disrupt a higher level, more critical device. And this
[24:55.130 --> 24:59.050]  is something that you have to think about from the security perspective as an attacker,
[24:59.050 --> 25:04.230]  using this as a potential pivot to get onto a more critical system.
[25:05.950 --> 25:10.610]  And also any device or software that interacts with these components, whether in the flight or
[25:10.610 --> 25:14.950]  on the ground, all your ground maintenance software, is now needs to be considered essentially
[25:14.950 --> 25:20.730]  from a security level, the same as a flight device. Because these are things that are designed to be
[25:20.730 --> 25:27.030]  able to modify the behavior of these pieces of hardware that are responsible for
[25:27.030 --> 25:33.850]  directly controlling the flight of the aircraft. I think that's an important point of what we're
[25:33.850 --> 25:39.970]  defining here. Things that we consider flight devices includes the things on the ground that
[25:39.970 --> 25:48.310]  program the device. Because those are very critical to making sure that the correct and
[25:48.310 --> 25:56.550]  only the correct components are programmed. You know, one thing also, Tim talked about the
[25:56.550 --> 26:02.550]  different components, different level of components talking together on the same bus.
[26:02.550 --> 26:10.050]  One very common level A software item on recent aircraft is an operating system
[26:10.510 --> 26:15.670]  running on a particular device. There is a standard called RX-653, which defines
[26:16.790 --> 26:22.990]  ways for a partitioned operating system that's effectively like a virtual machine,
[26:22.990 --> 26:30.530]  can have multiple different severity levels running on the same component.
[26:31.250 --> 26:37.430]  So as we all know, in security though, virtual machine escapes are definitely a thing. So if
[26:37.430 --> 26:41.890]  there was an attacker who was able to get into a lower level component, you know that they would
[26:41.890 --> 26:48.530]  be able to, from there, pivot into the operating system itself, or a more critical component if
[26:48.530 --> 26:59.280]  they wanted to. So that's our devices. How do we go about doing this? Well, we've got a couple
[26:59.280 --> 27:08.920]  different things here. So there's adversarial testing. I choose the word adversarial testing
[27:08.920 --> 27:12.200]  because I don't want to say pentesting, because pentesting means different things to different
[27:12.200 --> 27:21.380]  people. This is the idea of testing the system as an attacker would. You're no longer just
[27:21.380 --> 27:27.280]  strictly checking against a specification. You're actually looking at it from, if I'm an attacker,
[27:27.280 --> 27:31.920]  how could I leverage this system to do something? How could I use this protocol
[27:32.540 --> 27:37.700]  to do something? All the things that, you know, security professionals that we do in our jobs,
[27:37.700 --> 27:41.600]  how do we, you know, doing these things to now an airplane?
[27:43.180 --> 27:48.120]  Another method is some sort of pre-flight software and configuration authentication.
[27:48.840 --> 27:54.760]  If before every flight there was a way to go and check that the system is actually running
[27:54.760 --> 27:58.220]  the software that you think is going to be running, actually has a cryptographically
[27:58.220 --> 28:03.160]  secure method of validating that the software that's running is the software that's supposed
[28:03.160 --> 28:09.580]  to be running, that your configuration is correct. Other methods could include like
[28:09.580 --> 28:14.760]  physically incompatible interfaces on flight systems to make sure that no flight system,
[28:14.760 --> 28:21.440]  you can't just plug your iPad into a critical flight system, that there's the interface on
[28:21.440 --> 28:27.220]  these flight systems, just, you know, they don't speak these commodity protocols like USB or
[28:27.220 --> 28:32.720]  Bluetooth or Wi-Fi. We'll talk about this a little bit later. We also need to talk about
[28:33.280 --> 28:39.420]  air gaps. I know anybody in ICS is definitely laughing a little bit right now, but on an
[28:39.420 --> 28:45.240]  airplane with a strictly controlled configuration, you know, air gaps could certainly be a part of
[28:45.240 --> 28:51.140]  the solution for making sure that you can't jump from, you know, the non-flight critical portion
[28:51.140 --> 28:56.700]  of the aircraft to the flight critical portion of the aircraft, at least as a passenger sitting
[28:56.700 --> 29:04.600]  in the plane. Now the adversarial testing, you know, review and test all interfaces for
[29:04.600 --> 29:11.740]  vulnerabilities. You know, you have to, you can't trust, just blindly trust the external
[29:11.740 --> 29:16.980]  inputs into the system, even if they should only be coming from a system that's also been tested
[29:16.980 --> 29:23.260]  in the same level and should only be producing correct outputs for you to consume, you still
[29:23.260 --> 29:29.060]  can't trust this because you can't always trust that the system hasn't been compromised in some way.
[29:29.500 --> 29:37.080]  I'd like to give an example from automotive for that. If you have one component that tells you
[29:37.080 --> 29:42.600]  the brake is pressed and you make sure that the thing that actually generates the signal
[29:42.600 --> 29:46.620]  saying the brake is pressed works perfectly, can't be
[29:46.620 --> 29:50.860]  cracked, the thing that interprets that signal works perfectly, can't be cracked,
[29:50.860 --> 29:54.120]  it's all well and good, but if you then have an entertainment system on the same bus
[29:54.660 --> 30:01.480]  and that sends a message saying the brake is pressed, well, now you can't trust your inputs, can you?
[30:04.400 --> 30:08.680]  Yeah, and testing your protocol stacks and milestones for vulnerability. I mean, we've
[30:09.400 --> 30:14.760]  gotten a little bit better, but there's been lots of vulnerabilities found in TCP IP stacks and other
[30:14.760 --> 30:21.300]  network stacks over the years. Reviewing the software and compile code for vulnerabilities,
[30:21.300 --> 30:27.060]  making sure you're doing static analysis on the code, not a perfect solution, but it does catch
[30:27.060 --> 30:35.500]  some things. Secure boot is, I think, a fairly critical part of making sure that we can actually
[30:35.500 --> 30:43.180]  trust the software running on the systems. Having a good, secure boot platform set up could go a
[30:43.180 --> 30:50.120]  very long way to preventing at least an attacker from modifying the operating system that should
[30:50.120 --> 30:56.440]  then be modifying the software that runs on this platform because it should be detected.
[30:56.440 --> 31:01.860]  And, of course, having multiple layers of protection. Defense in depth has always been
[31:01.860 --> 31:07.520]  one of the strongest things you can do for the security posture of basically anything.
[31:09.120 --> 31:14.320]  The topic of secure boot is one that could be talked about for a long time and different people
[31:14.320 --> 31:21.960]  have different definitions of what secure boot means. At a simple level right now, I think what
[31:21.960 --> 31:26.520]  we mean is just that there's a way that the hardware has the ability to use cryptographically
[31:26.520 --> 31:35.120]  secure methods to ensure that only authorized software and components are installed and
[31:35.120 --> 31:44.060]  operating on that device. And a way to store the keys that should be immutable.
[31:45.220 --> 31:55.140]  Right. And also, once somebody gets in and pulls apart the hardware that they are not able to go in
[31:55.140 --> 32:03.220]  and break out, break the secure boot for all of the devices. Right. Something that is,
[32:03.780 --> 32:10.280]  uses perhaps asymmetric cryptography methods and secure hashing to be used for device.
[32:13.720 --> 32:17.980]  So pre-flight software authentication, talked about this a little bit earlier.
[32:17.980 --> 32:24.440]  We want to make sure that the before takeoff that everything on the aircraft is 100% correct
[32:24.440 --> 32:32.300]  and secure and authentic. So this would be some way, some centralized way to query every single
[32:32.300 --> 32:37.320]  device and find out what software and configuration are running on them. This is already somewhat
[32:37.880 --> 32:46.300]  in existing, you know, before an aircraft flies, this is already somewhat what happens, right? We
[32:46.300 --> 32:52.800]  need to make sure that only the correct software is on each component. So people who fly aircraft
[32:52.800 --> 32:57.900]  will already have a list of different software versions that should be running on each component
[32:57.900 --> 33:05.740]  of the aircraft. So this isn't as outlandish as it sounds. You can use cryptographic and secure
[33:05.740 --> 33:13.680]  algorithms, no CRCs, no checksums. You should be using something like SHA-2, SHA-3, something better.
[33:14.100 --> 33:19.220]  And there should be also the protocol, the way the centralized device queries every single
[33:19.220 --> 33:24.920]  component, there should be a challenge response protocol here. The protocol should also be tested
[33:24.920 --> 33:29.740]  adversarially to make sure there is something that cannot be spoofed. We need to make sure
[33:29.740 --> 33:35.740]  we can prevent replay attacks. So if there is some malicious software, malicious component on a box,
[33:35.740 --> 33:43.260]  it should be incapable of falsifying the authenticity of that software.
[33:43.260 --> 33:50.180]  You can also validate the entire range of memory and flash on each device. You want to make sure
[33:50.180 --> 33:55.480]  that you can't set the length to zero. You want to make sure that you don't have the correct software
[33:55.480 --> 33:59.860]  and the correct configuration and put some sort of mystery component in the middle and that
[33:59.860 --> 34:05.640]  that gap just isn't checked because it wasn't thought to be important, right? You need to
[34:05.640 --> 34:17.180]  make sure that the entire range is validated. Yeah, physically incompatible interfaces,
[34:17.810 --> 34:24.280]  you know, we're seeing that like the flight crews, they have the iPad devices that will be there,
[34:24.280 --> 34:32.020]  their flight book that has the flight information. One of the ways to make sure to, one order to help
[34:32.020 --> 34:36.460]  prevent malicious software from being loaded onto these flight critical systems is to make sure that
[34:36.460 --> 34:42.700]  there are physically incompatible interfaces between the non-flight systems and the flight
[34:42.700 --> 34:48.080]  capable systems. So your flight cable systems shouldn't have USB, they shouldn't have Bluetooth,
[34:48.080 --> 34:53.580]  they shouldn't have Wi-Fi, they shouldn't have these standardized protocols that everything
[34:53.580 --> 34:59.180]  speaks, you know, specialized hardwired connections like the connections we have a picture of here,
[34:59.180 --> 35:04.740]  very common in aerospace, just make it a lot harder for the flight crew to just plug their iPad
[35:04.740 --> 35:12.000]  into a flight critical system. And if you can see on these connectors, some of the important
[35:12.000 --> 35:16.620]  parts of them is that they've actually got different keying. So there's usually a bunch
[35:16.620 --> 35:21.240]  of different, you know, a bunch of different pins so that you have all the necessary signals that
[35:21.240 --> 35:26.020]  you need for a particular connector. But then you, there's a lot of different varieties of
[35:26.020 --> 35:30.460]  keying. Some have five slots, some have four, different widths, different positions.
[35:30.600 --> 35:35.820]  And the whole idea is that you want to make sure that you cannot connect a component wrong.
[35:35.820 --> 35:39.460]  This is already what's done on an aircraft for connecting all the different flight components.
[35:39.460 --> 35:45.940]  And this is something that we say is necessary when connecting anything to a flight system.
[35:50.040 --> 35:56.100]  So air gaps, as Tim said, everybody who's in ICS is probably laughing when we had that out
[35:56.100 --> 36:01.600]  there before. But the whole point is that an aircraft doesn't change. If it changes,
[36:01.600 --> 36:06.320]  it changes because the design of the aircraft changes. It changes because there was an actual
[36:06.320 --> 36:13.360]  documented and, you know, tested reason for doing so. So designing the system,
[36:13.360 --> 36:20.300]  you should make sure that the flight systems and the non-flight systems cannot talk at all.
[36:22.280 --> 36:27.900]  They should be physically separate. We, as I said, virtual machine escapes are definitely a thing.
[36:27.900 --> 36:32.020]  You should not be running on the same box. They should not be able to even talk on the same bus.
[36:33.300 --> 36:39.140]  So anything that needs, if somebody, you don't want to have to test everything on an aircraft,
[36:39.140 --> 36:47.560]  right? You want to make sure you can, you want to try and trim what you need to test because
[36:47.560 --> 36:53.200]  testing is expensive. So something like an entertainment system, maybe somebody doesn't
[36:53.200 --> 36:58.860]  want to go about testing that. Well, that's okay. If you can make sure that that entertainment
[36:58.860 --> 37:06.740]  system can never ever talk to a flight system, which means no common buses. It means that the
[37:06.740 --> 37:12.160]  only thing on the aircraft connected to that entertainment system from the flight components
[37:12.160 --> 37:18.180]  is power. If you need somebody to, if the crew needs to like disconnect a component, they would
[37:18.180 --> 37:24.440]  need to be able to, you know, toggle the power to that device instead of actually sending a message
[37:24.440 --> 37:39.510]  to shut down. So some examples of what we've got here. We're going to go through some different
[37:39.510 --> 37:44.850]  categories, three different types of systems and talk about how we would apply these things to
[37:44.850 --> 37:53.170]  ensure that they're secure. Maintenance. In these cover, this is pretty much the, you know, all the
[37:53.170 --> 37:58.010]  different types of devices that you would have on an aircraft, right? Passenger accessible systems,
[37:58.010 --> 38:08.620]  things that passengers can get access to and so on. So maintenance devices. These are the things
[38:08.620 --> 38:15.180]  that program the different components when the aircraft is on the ground. They're usually a fancy
[38:15.180 --> 38:20.440]  laptop, maybe a robust laptop with some sort of waterproof case and special cables and extra
[38:20.440 --> 38:30.180]  interfaces to talk to the aircraft parts. These need to be adversarially tested. This is, should
[38:30.180 --> 38:36.280]  be unsurprising to hear by now. Communications with the different flight devices should require
[38:36.280 --> 38:43.000]  full authentication and these devices should also have a plan and method to periodically validate
[38:43.000 --> 38:50.320]  that the device itself has not been compromised. As I said, they're typically a regular laptop
[38:50.320 --> 38:58.900]  or some sort of PC type device. So any of the standard ways to secure a PC, you know, a laptop
[38:58.900 --> 39:06.040]  should be used on these devices to make auditing. They should have auditing on, they should have
[39:06.830 --> 39:13.900]  all the different security protections in place. Programming other devices as well,
[39:13.900 --> 39:18.600]  as typically it can happen to, there is an ERIN standard for this as well, although it's optional.
[39:18.600 --> 39:24.880]  Not every device implements it. It's called ERIN 615 for data loading and that can happen over
[39:24.880 --> 39:33.320]  multiple types of device buses such as ERIN 429. These devices will then usually talk over that.
[39:33.320 --> 39:38.400]  It's kind of a double-edged sword. On one hand, it means you've got a standard way of doing things.
[39:38.400 --> 39:43.880]  On the other hand, it means that if somebody implements ERIN 429, you potentially be able
[39:43.880 --> 39:48.620]  to go up and program with an unauthenticated device, which is why communication with the
[39:48.620 --> 39:55.760]  flight device should require full back and forth challenge response authentication on both ends.
[39:55.940 --> 40:01.620]  The device should make sure that the device programming it is who it says it is and vice
[40:01.620 --> 40:07.800]  versa. Full mutual authentication. That's the term.
[40:11.040 --> 40:18.100]  So passenger accessible systems should either be incapable of connecting to aircraft systems,
[40:18.100 --> 40:25.120]  not physically connected in any way, not physically sharing any piece of hardware,
[40:27.400 --> 40:31.960]  ideally not even speaking the same sort of protocols so they couldn't even accidentally
[40:31.960 --> 40:37.360]  be connected together. You can't just plug USB into ERIN 429 and have it work.
[40:37.980 --> 40:44.040]  Or they need to be same as everything else adversarial tested and not have external
[40:44.040 --> 40:51.280]  connectivity that a normal passenger would be able to just plug into and use. If you have
[40:51.660 --> 40:55.300]  a USB for charging, it should only be for charging. Only the data lines should be
[40:55.300 --> 41:02.500]  connected. It shouldn't have any of the... you should be capable of passing data back and forth.
[41:05.320 --> 41:10.720]  The only case where there's an exception then is if this isn't a system, if the entertainment
[41:10.720 --> 41:16.760]  system is incapable of being connected to critical flight systems or to flight systems,
[41:17.900 --> 41:21.660]  then you could have a USB audio interface on it.
[41:21.660 --> 41:22.480]  Yes.
[41:22.740 --> 41:28.180]  But that's the only case where that would be allowed. You would need to make sure that this
[41:28.180 --> 41:32.380]  device cannot talk to anything else. And the whole goal here is to make sure that something
[41:32.380 --> 41:43.160]  can't be done, something cannot accidentally or through somebody dropping a bad cable somewhere
[41:43.160 --> 41:50.200]  near the airport, have somebody connect something that shouldn't be connected to the flight systems.
[41:50.200 --> 41:56.540]  That's the whole goal here. If somebody is going to try and attack an aircraft
[41:57.560 --> 42:01.940]  during that small, that limited window of the flight itself, we want to make sure
[42:01.940 --> 42:07.200]  that it is incredibly obvious that they're doing something that they shouldn't be doing.
[42:07.360 --> 42:13.620]  So just plugging the USB in is very benign. But if they're starting to rip up panels and trying
[42:13.620 --> 42:19.700]  to find the 429 bus somewhere down there, well, that should hopefully be obvious to
[42:19.700 --> 42:25.320]  some of the other passengers or the crew and corrective measures could take place.
[42:26.740 --> 42:29.840]  But that's the whole goal here. We want to make sure that it can't be done accidentally
[42:31.540 --> 42:35.540]  or on purpose without it being obvious.
[42:39.500 --> 42:43.420]  So the flight systems, the flight systems themselves, we've talked about these
[42:43.420 --> 42:47.960]  quite a bit already. These need to be adversarially tested, of course. We need
[42:47.960 --> 42:54.600]  to make sure that there's multiple levels of... there's multiple layers of protection
[42:54.600 --> 42:59.980]  in the way for anybody who is trying to attack a system that they would need to get through.
[43:00.260 --> 43:05.180]  No consumer interfaces. So all those flight systems, you need to make sure that you do not
[43:05.180 --> 43:13.840]  have the... you don't have the... you know, there's no USB in there. There's no Wi-Fi in there.
[43:13.840 --> 43:20.580]  So iPads as a flight bag are a thing now. And obviously, there's an appeal in terms of
[43:20.580 --> 43:26.380]  how easy it is to update. You don't have to carry around stacks and stacks of paper.
[43:26.860 --> 43:29.360]  There's... it's an easy way to store a lot of things.
[43:30.960 --> 43:36.260]  But that means you've now got a device which is in the cockpit, which is considered a flight
[43:36.260 --> 43:43.400]  critical system, which is a consumer device. And that gives me some concerns. So I think
[43:43.400 --> 43:49.640]  there needs to be some thought on how to secure that type of system. Maybe it just needs to be
[43:49.640 --> 43:53.980]  not an iPad. Maybe it can be a special purpose device. There's plenty of things out there with
[43:53.980 --> 44:01.980]  LCD. They can store maps and have a program in them. No consumer interfaces. Yeah, so no USB.
[44:01.980 --> 44:08.240]  You wouldn't be able to connect this. You don't want to have somebody accidentally plug in a USB
[44:08.240 --> 44:25.530]  as you're not supposed to, right? So just as a quick summary here. Again, our goals.
[44:26.450 --> 44:32.710]  These are the things that we want to achieve. And I think we have for what we've put
[44:32.710 --> 44:38.910]  in place. Making sure we still have to assume, again, that's up front. An attacker has everything,
[44:38.910 --> 44:45.050]  knows everything. We've talked about providing a way to make sure that the systems can be validated
[44:45.050 --> 44:50.350]  to be correct. That the software and configurations on the different components are correct
[44:50.350 --> 44:56.510]  when the aircraft, before the aircraft takes off. We want to limit that potential attack window.
[44:58.730 --> 45:04.670]  We've talked about the ways we can prevent accidental transmission of something malicious
[45:04.670 --> 45:13.650]  to the physical air gaps, physical disconnects, physical incompatible interfaces.
[45:14.810 --> 45:18.870]  And then, again, if this is all, the goal is to make multiple barriers there.
[45:19.650 --> 45:22.950]  Multiple barriers there an attacker would need to get through.
[45:27.200 --> 45:32.900]  Yeah, and then two device categories. There's stuff that can affect flight and stuff that can't
[45:32.900 --> 45:40.160]  affect flight. And can't affect flight does, in this case, mean physical, full physical isolation
[45:40.160 --> 45:42.180]  of anything flight critical.
[45:46.200 --> 45:52.040]  Methods. We've talked about these at length. Adversarial testing, I believe, is a big key part
[45:52.040 --> 45:59.080]  of this. One thing I guess we didn't really talk about is kind of design standards. It's something
[45:59.080 --> 46:05.640]  that could be addressed as well. Making sure that the software as it's developed complies with
[46:07.020 --> 46:13.640]  the different best practice recommendation of how to develop secure software in terms of
[46:14.340 --> 46:19.780]  functions that are allowed and such. That's another potential method. We are more looking
[46:19.780 --> 46:28.850]  at the fitting things on top of what was there already. But we still do have a few problems
[46:28.850 --> 46:34.150]  that we need to solve. We're not going to try and pretend that we solved everything here.
[46:34.150 --> 46:39.970]  We'd like to think that we solved a significant part of aviation cybersecurity just in this talk.
[46:40.830 --> 46:46.810]  But there's a few things that we need to think about going forward. Supply chain security is
[46:46.810 --> 46:54.010]  still a concern. Obviously, as I said, anything can be hacked. As the devices are sitting in
[46:54.010 --> 47:01.290]  storage, an attacker could go in and modify them. They've got plenty of time to go in and modify
[47:01.290 --> 47:06.670]  them, figure out how they work. Either modify the software or just physically. Physical
[47:06.670 --> 47:12.610]  modifications to the hardware. And how to make sure that that doesn't happen or can't happen
[47:13.190 --> 47:24.170]  is a challenge. RF communication is also another area that we can't really address. The airplane
[47:24.170 --> 47:33.490]  has a fair bit of RF communication. It has radio, ADS-B, weather, etc. This is also something that
[47:33.490 --> 47:43.250]  wasn't addressed by what we've presented here in this talk. The flight crew, the pilot's training
[47:44.120 --> 47:50.090]  is a significant part of that. If there's issues with communication between the aircraft and ground,
[47:50.090 --> 47:56.490]  that's something where training can kick in and deal with the situation. But it is still
[47:56.490 --> 48:02.650]  something that would improve matters if there was a way to secure the communications.
[48:05.750 --> 48:10.090]  Things that we might also want to think about in the future are how often, how much change
[48:10.090 --> 48:20.070]  would require something to be retested, more adversarial testing. What level of change,
[48:20.070 --> 48:27.870]  where different amounts of change are considered to be minor fixes, and they don't have to require
[48:28.130 --> 48:34.150]  a complete redesign of the system. But some level of change does require a complete redesign and
[48:34.150 --> 48:39.390]  retesting the system. So that's something that would need to be looked at in the future.
[48:42.200 --> 48:45.840]  And then there's also the maintenance devices themselves. We talked about how
[48:45.840 --> 48:50.240]  maintenance devices are used to program all the different components on an aircraft.
[48:50.240 --> 48:54.920]  This means that would be used to program both flight systems and these air-gapped non-flight
[48:54.920 --> 49:01.140]  systems. So maybe those need to have a slightly different category. You could
[49:01.140 --> 49:05.560]  argue, you can put together a committee meeting and argue about lots of this stuff for a while
[49:05.560 --> 49:13.260]  if you want to. But I think that what we've given here is a fairly complete approach
[49:13.260 --> 49:21.020]  to address cyber security. Any questions? We'll be in the discord for any questions.